guaranteed services for mesh n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Guaranteed Services for Mesh PowerPoint Presentation
Download Presentation
Guaranteed Services for Mesh

Loading in 2 Seconds...

play fullscreen
1 / 24

Guaranteed Services for Mesh - PowerPoint PPT Presentation


  • 128 Views
  • Uploaded on

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 !!.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Guaranteed Services for Mesh' - jackie


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
guaranteed services for mesh

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>

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

NO !!

<Tae Rim Park>, <CUNY>

two modes for15 4b
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>

limitations of superframe structure
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>

two approaches
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>

superframe structure for 15 4b
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>

example of a beacon scheduling algorithm
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>

example scenario with chlamtac s
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>

let s focus on a simple scenario
Let’s Focus on a Simple Scenario
  • Beacon mode
  • Guaranteed time service from node 4 to node 0

<Tae Rim Park>, <CUNY>

allocated time slot
Allocated Time Slot

<Tae Rim Park>, <CUNY>

latency problem
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>

enhancement for mesh
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>

proposed structure
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>

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

<Tae Rim Park>, <CUNY>

data transmission
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>

superframe aware transmission
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>

guaranteed time services for mesh
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>

gts allocation example from dev 3
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>

two examples
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>

potential enhancement

Potential Enhancement

<Tae Rim Park>, <CUNY>

1 better beacon services
1. Better Beacon Services
  • Efficient beacon scheduling can reduce latency associated with beacons
    • Ex. Association, indirect transmission

<Tae Rim Park>, <CUNY>

2 energy saving
2. Energy Saving
  • Minimum set of shared superframes
    • Wake up only at neighbors’ OSDs, transmit to the device

<Tae Rim Park>, <CUNY>

advantages summary
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>