Guaranteed Services for Mesh

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>