1. Guaranteed Services for Mesh
doc.: IEEE < xxx e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

2. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
<Sept 2008>
Motivation
Can the current standard provide guaranteed services for mesh networks?
NO !!
<Tae Rim Park>, <CUNY>
<Tae Rim Park>, <CUNY>

3. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

4. Limitations of Superframe Structure
doc.: IEEE < xxx e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

5. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

6. Superframe Structure for 15.4b
doc.: IEEE < xxx e>
<Sept 2008>
Superframe Structure for 15.4b 1 2
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
<Tae Rim Park>, <CUNY>
<Tae Rim Park>, <CUNY>

7. Example of a Beacon Scheduling Algorithm
doc.: IEEE < xxx e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

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

9. Let’s Focus on a Simple Scenario
doc.: IEEE < xxx e>
<Sept 2008>
Let’s Focus on a Simple Scenario
Beacon mode
Guaranteed time service from node 4 to node 0
<Tae Rim Park>, <CUNY>
<Tae Rim Park>, <CUNY>

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

11. Latency Problem At each hop Long beacon interval (tBI) is expected
<Sept 2008>
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
<Sept 2008>
Proposed Mesh Enhancement for Guaranteed Service
<Tae Rim Park>, <CUNY>

13. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
<Sept 2008>
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>
<Tae Rim Park>, <CUNY>

14. Proposed Structure Precondition Shared superframe
<Sept 2008>
Proposed Structure
Precondition
Slotted scheduling of superframe durations
Superframe scheduling algorithm for
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
<Sept 2008>
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 To legacy 15.4b devices
<Sept 2008>
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
doc.: IEEE < xxx e>
<Sept 2008>
Superframe Aware Transmission
Scan or new discovery method to 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>
<Tae Rim Park>, <CUNY>

18. Guaranteed Time Services for Mesh
<Sept 2008>
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)
<Sept 2008>
GTS Allocation Example (from dev 3)
2. EGTS reply,
Payload :
Dst addr (3)
new allocated slot number: 2
Allocated GTS slots (0b )
3. EGTS notify,
Payload :
Allocated GTS slots
(0b )
EGTS request,
Payload :
Available GTS slots
(0b )
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
<Sept 2008>
Two Examples
If data is generated at time 0 in Dev. 4
Minimum latency; tSD*9/16 + tSD/16*2 = = ms
Maximum latency; tSD*15/16*3 = ms
Cf. it was 1,966 ms before!
<Tae Rim Park>, <CUNY>

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

22. 1. Better Beacon Services
<Sept 2008>
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
<Sept 2008>
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
<Sept 2008>
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>