1 / 24

Guaranteed Services for Mesh

Guaranteed Services for Mesh. Tae Rim Park 1 , Yang G. Kim 1, Myung J. Lee 1 and Jong-suk Chae 2 1 City University of New York, USA 2 Electronics and Telecommunications Research Institute, Korea. Motivation. Can the current standard provide guaranteed services for mesh networks?. NO !!.

mnina
Download Presentation

Guaranteed Services for Mesh

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. Guaranteed Services for Mesh Tae Rim Park1, Yang G. Kim1, Myung J. Lee1 and Jong-suk Chae2 1 City University of New York, USA 2 Electronics and Telecommunications Research Institute, Korea <Tae Rim Park>, <CUNY>

  2. Motivation • Can the current standard provide guaranteed services for mesh networks? NO !! <Tae Rim Park>, <CUNY>

  3. Two Modes for15.4b • Non-beacon mode • No structure for guaranteed time service • Beacon mode • Superframe structure • Guaranteed time services • Efficient indirect communication • Energy saving <Tae Rim Park>, <CUNY>

  4. Limitations of Superframe Structure • Beacon transmission time scheduling • Difficult in large scale networks • Beacon collision, service hole, … • Out of scope • Possible approaches: Chlamtac’s, two hop neighbor table exchange, random… • Mesh path selection • Difficult to discover neighbors (broadcasting is difficult)  Common active time with neighbors • Guaranteed service • Only for one hop of PNC • New way with new command frames • Long latency • From long beacon interval  New structure <Tae Rim Park>, <CUNY>

  5. Two approaches • Define whole new time structure? • Enhance existing superframe structure? Answer may vary depending on Target applications & Implementation complexity We prefer this ! <Tae Rim Park>, <CUNY>

  6. Superframe Structure for 15.4b 0 • Scheduling OSD in the inactive period of parent’s • Terms for simplicity • OSD (Outgoing Superframe Duration) • Superframe defined by own beacon transmission (outgoing beacon) • Device stays awake for children • ISD (Incoming Superframe Duration) • Superframe defined by an beacon from a parent (incoming beacon) • Device may sleep after receiving the beacon 1 2 <Tae Rim Park>, <CUNY>

  7. Example of a Beacon Scheduling Algorithm • Chlamtac’s* Algorithm • Although it may not be perfect… • Topology should be set before running the algorithm • Service hole (blind point) can not resolved • Two rules • (c.1) u’s time-slot must be different from u’s parent’s time-slot. • (c.2) u’s time-slot must not be the time-slot of the parent of anyone of u’s neighbors, excluding u’s own children *I. Chlamtac and S. Kutten, “Tree-based broadcasting in multihop radio networks,” IEEE Trans. Comput., 1987 <Tae Rim Park>, <CUNY>

  8. Example Scenario with Chlamtac’s 0 1 2 3 4 5 6 7 Outgoing superframe timeline 0 2 5 9 0 1 0 2 1 3 2 3 1 4 8 12 4 5 1 3 0 2 6 7 3 7 11 14 8 9 2 3 0 1 10 11 6 10 13 15 12 13 0 1 2 3 14 15 <Tae Rim Park>, <CUNY>

  9. Let’s Focus on a Simple Scenario • Beacon mode • Guaranteed time service from node 4 to node 0 <Tae Rim Park>, <CUNY>

  10. Allocated Time Slot <Tae Rim Park>, <CUNY>

  11. Latency Problem • At each hop • Any type transmission (either CAP or CFP) in superframe, a node has to wait for the superframe of the next hop (tBI/2 on average) • Long beacon interval (tBI) is expected • 1) to facilitate beacon scheduling • 2) to save energy • Ex. From node 4 to 0 (3 hops), when BO=6 (0.983s) • If the data is generated at time 0 • (3/8 + 6/8 + 7/8)*0.983 = 1.966s • On average with h hops: (tBI /2)*h =1.474s • Excessive latency makes GTS enhancement useless <Tae Rim Park>, <CUNY>

  12. Proposed Mesh Enhancement for Guaranteed Service <Tae Rim Park>, <CUNY>

  13. Enhancement for Mesh • Enhanced structure • Common active duration(superframe) among neighbors for discovery using broadcast • Repeated active duration(superframe) in a beacon interval to reduce latency • Guaranteed service • Link-by-link guarantee for mesh paths • Contention free slot among neighbors • Hidden terminal free slot <Tae Rim Park>, <CUNY>

  14. Proposed Structure • Precondition • Slotted scheduling of superframe durations • Superframe scheduling algorithm for 802.15.4-2006 • Shared superframe • Superframe to share an active duration together with neighbors • Create ‘superframe image’ using the same superframe • Fill a beacon interval with an outgoing superframe, an incoming superframe and shared superframes • Three-way-handshake GTS allocation • Distributed allocation with GTS request/response/notify frames • Superframe Aware data transmission • Enhanced data transmission for backward compatibility and power saving <Tae Rim Park>, <CUNY>

  15. Shared Superframe Duration • During SSD (Shared Superframe duration) and ISD, devices have to stay awake <Tae Rim Park>, <CUNY>

  16. Data Transmission • Among 4e devices • All devices ready to receive • General frame: directly transmission • GTS frame: using TxOption of GTS transmission • To legacy 15.4b devices • If 4b dev is a child • Option1) Indirect communication • Option2) Wait and transmit at OSD of the child • If 4b dev is a parent or a neighbor • Same as Option2)  Superframe Aware Transmission (backward compatibility and power saving) <Tae Rim Park>, <CUNY>

  17. Superframe Aware Transmission • Scan or new discovery methodto detect superframes of neighbors • Structure for storing time information of outgoing superframe • New TxOption in of MCPS-DATA.request • SAT (Superframe Aware Transmission) • Keeping the data in the queue • Transmitting at appropriate superframe • Different handles (queues) for different neighbors <Tae Rim Park>, <CUNY>

  18. Guaranteed Time Services for Mesh • Three-way-handshake allocation • Source Requesting destination • Three command frames • EGTS request • Unicast from a source to a destination • Providing available time slots • EGTS reply • Broadcast from the destination • Selecting and providing an GTS slot number to all neighbors  CTS • EGTS notify • Broadcast from the source • Providing the assigned GTS slot  RTS • Schedule notification • With beacons of the source and the destination <Tae Rim Park>, <CUNY>

  19. GTS Allocation Example (from dev 3) 2. EGTS reply, Payload : Dst addr (3) new allocated slot number: 2 Allocated GTS slots (0b0100000) • EGTS request, • Payload : • Available GTS slots • (0b1000000) 3. EGTS notify, Payload : Allocated GTS slots (0b1100000) Assuming the first slot is already assigned from dev 4 to transmit frames to dev 3 <Tae Rim Park>, <CUNY>

  20. Two Examples • If data is generated at time 0 in Dev. 4 • Minimum latency; tSD*9/16 + tSD/16*2 = 69.12+15.36= 84.48 ms • Maximum latency; tSD*15/16*3 = 345.6 ms • Cf. it was 1,966 ms before! <Tae Rim Park>, <CUNY>

  21. Potential Enhancement <Tae Rim Park>, <CUNY>

  22. 1. Better Beacon Services • Efficient beacon scheduling can reduce latency associated with beacons • Ex. Association, indirect transmission <Tae Rim Park>, <CUNY>

  23. 2. Energy Saving • Minimum set of shared superframes • Wake up only at neighbors’ OSDs, transmit to the device <Tae Rim Park>, <CUNY>

  24. Advantages & Summary • Three proposals for mesh communication 1. Enhanced superframe structure • Little change to 4b (mostly proven and easy algorithms) • Applicable with existing upper layer scheduling algorithms • Enabling discovery using broadcast • Reducing latency 2. Superframe Aware transmission • Enabling communication with neighbors (even non-tree devices) • Enabling co-existence with 15.4b • Enabling energy saving 3. Distributed GTS allocation • Extending service range (not only around PAN coordinator) • Dynamically allocate/deallocate GTS slots for mesh networks <Tae Rim Park>, <CUNY>

More Related