1 / 7

ROLL working group

draft-vanderstok-roll-mcreq-02 Multicast Requirements for LLN in Buildings. ROLL working group. Peter van der Stok. August 3,2012. Multicast in Building Control. Multicast purposes : Sending messages with bounded delay to set of (nearby) receivers

hetal
Download Presentation

ROLL working group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-vanderstok-roll-mcreq-02 Multicast Requirements for LLN in Buildings ROLL working group Peter van der Stok August 3,2012

  2. Multicast in Building Control • Multicast purposes: • Sending messages with bounded delay to set of (nearby) receivers • No response required (this presentation) • Service discovery (mDNS) for stand-alone network • Response required

  3. Typical network configuration Node; X indicates the number of hops a node is away from the ER (i.e. the rank of the node in the ER-rooted DAG) x

  4. Operational characteristics • Central requirements: • Agreement • Timeliness (200 ms); occasionally a messagetakes 1-2 seconds • Variable network density: node every 30 - 100 cm • In general multicast ranges over one office (6*6 m) or one floor

  5. Simulation configuration 10x10 mesh IEEE 802.15.4 (0,0) (9,9) Sender (0,0) sends message every 2 seconds Observe e2e delay at (9,9)

  6. E2E Delay as function of distance sec max sec max avg avg min min Inter-node distance Inter-node distance K=1 K=5 50-100 neighbors 2-4 neighbors 2-4 neighbors 50-100 neighbors 100ms < Imax < 500ms 10ms < Imin < 30ms

  7. Suggestions to trickle multicast forwarding draft • Window per sender necessary solution. • Sending ICMP messages reduces overhead with multiple sources • BUT, relation between forwarding and ICMP message not clear • With one sender, ICMP message creates unnecessary overhead • Suggestion: • ICMP optional per node • Consider receivers which do not forward but send their status • Suggestion: • Forwarding optional • Reduce delay of missing messages • Suggestion: • c-counter per messageand source

More Related