Doc. <15-08-0594-00-004e>

Submission

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 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

Doc. <15-08-0594-00-004e>

Submission

Motivation

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 2

• Can the current standard provide guaranteed services for mesh networks?

NO !!

Doc. <15-08-0594-00-004e>

Submission

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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 3

Doc. <15-08-0594-00-004e>

Submission

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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 4

Doc. <15-08-0594-00-004e>

Submission

Two approaches

• Define whole new time structure?• Enhance existing superframe structure?

Answer may vary depending on

Target applications & Implementation complexity

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 5

We prefer this !

Doc. <15-08-0594-00-004e>

Submission

Superframe Structure for 15.4b

• 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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 6

0

1

2

Doc. <15-08-0594-00-004e>

Submission

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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 7

Doc. <15-08-0594-00-004e>

Submission

Example Scenario with Chlamtac’s

Outgoing superframe timeline

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 8

6

0

1

2

3

4

5 9

128

7

10

11

13

14

15

0 2 1 3

1 3 0 2

2 3 0 1

0 1 2 3

0 1 2 3 4 5 6 7

0123456789

101112131415

Doc. <15-08-0594-00-004e>

Submission

Let’s Focus on a Simple Scenario

• Beacon mode• Guaranteed time service

from node 4 to node 0

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 9

Doc. <15-08-0594-00-004e>

Submission

Allocated Time Slot

10

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

Latency Problem

11

<Sept 2008>

<Tae Rim Park>, <CUNY>

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

Doc. <15-08-0594-00-004e>

Submission

Proposed Mesh Enhancement for Guaranteed Service

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 12

Doc. <15-08-0594-00-004e>

Submission

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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 13

Doc. <15-08-0594-00-004e>

Submission

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

Proposed Structure

14

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

• During SSD (Shared Superframe duration) and ISD, devices have to stay awake

Shared Superframe Duration

15

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

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)

Data Transmission

16

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

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

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 17

Doc. <15-08-0594-00-004e>

Submission

• 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

Guaranteed Time Services for Mesh

18

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

GTS Allocation Example (from dev 3)2. EGTS reply, Payload : Dst addr (3) new allocated slot number: 2 Allocated GTS slots (0b0100000)

3. EGTS notify, Payload : Allocated GTS slots (0b1100000)

19

<Sept 2008>

<Tae Rim Park>, <CUNY>

1. EGTS request, Payload : Available GTS slots (0b1000000)

Assuming the first slot is already assigned from dev 4 to transmit frames to dev 3

Doc. <15-08-0594-00-004e>

Submission

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

Two Examples

20

<Sept 2008>

<Tae Rim Park>, <CUNY>

Cf. it was 1,966 ms before!

Doc. <15-08-0594-00-004e>

Submission

Potential Enhancement

<Sept 2008>

<Tae Rim Park>, <CUNY>Slide 21

Doc. <15-08-0594-00-004e>

Submission

• Efficient beacon scheduling can reduce latency associated with beacons – Ex. Association, indirect transmission

1. Better Beacon Services

22

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

• Minimum set of shared superframes – Wake up only at neighbors’ OSDs, transmit to the device

2. Energy Saving

23

<Sept 2008>

<Tae Rim Park>, <CUNY>

Doc. <15-08-0594-00-004e>

Submission

Three proposals for mesh communication1. 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

Advantages & Summary

24

<Sept 2008>

<Tae Rim Park>, <CUNY>