1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Distributed Multi-Channel Mesh Extension]
Date Submitted: [10 November, 2008]
Source: [G-S. Ahn, T. Park, Y. Kim, J. Yoon, R. Zhang, M. Lee, C-S. Shin, S-S. Joo, J-S. Chae]
Companies [CUNY, ETRI]
Address [140th St. and Convent Ave, New York, NY, USA]
Voice:[ ], FAX: [],
Re: [IEEE P e]
Abstract: [This document proposes an enhancement to IEEE MAC Layer with distributed multi-channel mesh extension]
Purpose: [Discussion in e Task Group]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

2. A Joint Proposal for IEEE802. 15
A Joint Proposal for IEEE e: Distributed Multi-Channel Mesh Extension
G-S Ahn*, T. Park*, Y. Kim*, J. Yoon*, R. Zhang*, M. Lee*
ChangSub Shin**, Seong-Soon Joo**, Jong-Suk Chae**
CUNY*, ETRI**

3. Objectives Solutions for Industrial and Commercial applications
Deterministic latency
Enhanced GTS time structure
Scalability
Distributed scheduling, EGTS extension,
High reliability
Adaptive channel diversity, Beacon scheduling, Tree & Mesh Extension
Low duty cycle
CAP reduction in multi-frame extension
Flexible superframe structure
Multi-superframe structure, Mesh Extension
Backward compatibility
Minimum changes to IEEE b

4. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
Two Modes for b
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>

5. Limitations of Superframe Structure
doc.: IEEE < xxx e>
Limitations of Superframe Structure
Beacon transmission time scheduling
Difficult in large scale networks
Beacon collision, service hole, …
Distributed Beacon scheduling
Guaranteed service
Only for one hop of PNC
EGTS three-way-handshake
Long latency
From long beacon interval
Flexible superframe structure:
Mesh extension, Multi-channel extension,
Multi-superframe extension
<Tae Rim Park>, <CUNY>

6. Superframe Structure for 15.4b
doc.: IEEE < xxx e>
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>

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

8. Allocated Time Slot

9. Latency Problem At each hop Long beacon interval (tBI) is expected
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

10. doc.: IEEE 802.15-<15-08-0xxx-00-004e>
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>

11. EGTS Mesh Extension EGTS allocation do not rely on PAN coordinator.
Multi-channel aspect is omitted in this figure for simplicity
EGTS allocation do not rely on PAN coordinator.
Allows EGTS for peer-to-peer connection.
Allows EGTS for nodes beyond one hop distance from PAN coordinator.

12. EGTS Multi-channel Extension
Common channel : Beacon and CAP use a fixed common channel for all nodes.
Multi-channel: EGTS uses multi-channel for a different set of source and destination.
EGTS slot = tuple (time slot, channel)
Allocates each link (Tx & Rx pair) with one or more slots.
When MO = SO (to be explained in the following),
112 slots (7 time slots * 16 channels) are available in a superframe.
EGTS 12

13. Flexible Multi-superframe (1)
Depending on the application requirement, use N multiple superframes as one Multi-superframe (MSF)
We define MO (multi-superframe order) such that N = 2(MO – SO).
MO should be greater than or equal to SO.
Multi-superframe Duration
MD = aBaseSuperframeDuration*2MO symbols
Number of slots in a multi-superframe
S = 16 channels * (7 *2(MO – SO)) time slots
The allocation pattern of these S slots is repeated every multi-superframe.
BO = 6, SO = 3, MO = 5 13

14. Flexible Multi-superframe (2)
Various combination of BO, SO, and MO can be set depending on the application requirement.
For high data rate : MO = SO
Each node can have only 7 slots because a node cannot Tx or Rx multiple channels at the same time slot
Hence, each node can have no more than 2 child
For scalability : MO > SO
Maximum data rate is bounded by MD.
Nodes can use multiple time slots for some of the paths that require high data rate.
BO = 6, SO = 3, MO = 5 14

15. Flexible Multi-superframe (3)
For low duty cycle : MO > SO
Active
Beacon, CAP
During EGTS time slots that are allocated to the node
Inactive
During EGTS time slots that are not allocated to the node
BLE in CAP periods
Beacon slot where none of the neighbors are transmitting a beacon.
Active / awake
Inactive / sleep
BO = 6, SO = 3, MO = 5
Node 15

16. CAP Period Reduction in MSF
Motivation: Lower duty cycle, more GTS slots.
Each multi-superframe (MSF) has only one CAP period.
Beacon indicates the next CAP period time.
Every node synchronizes the CAP period.
Number of slots in a multi-superframe
S = 16 channels * (7 + (2(MO – SO)-1) * 15) time slots
The allocation pattern of these S slots is repeated every multi-superframe.
BO = 6, SO = 3, MO = 5 16

17. EGTS Allocation Bitmap Table (ABT)
Each node maintains a Neighborhood Allocation Bitmap Table (ABT)
Example (MO = SO = 3)
ABT size = 14 bytes
0: Vacant, 1: Allocated (self or neighbors)
Row: time slot, Column: channel 17

18. ABT sub-block …
Entire bitmap may be too big to be transmitted by Beacon or EGTS command frames
Example (MO = 7, SO = 3)
ABT size = 224 bytes
0: Vacant, 1: Allocated.
Row: time slot, Column: channel
Solution:
Send a ABT sub-block (with an index indicating beginning & ending of a block)
Example: 28 bytes sub-block. 18

19. Three-way-handshake EGTS Allocation (1)
Source Requesting destination
Three command frames are transmitted during CAP period
EGTS request
Unicast from a source to a destination .
Providing locally available slots (28 byte ABT sub-block).
Required number of slots (depending on data rate).
EGTS reply
Broadcast from the destination.
Select appropriate slots in the sub-block and announce the assigned EGTS slots to all neighbors (28 byte ABT sub-block).
EGTS notify
Broadcast from the source
Announce the assigned EGTS slots to all neighbors (28 bytes ABT sub-block)

20. Three-way-handshake EGTS Allocation (2)
Source Requesting destination
Three command frames are transmitted during CAP period
EGTS request
EGTS reply
EGTS notify
Schedule Update
Those nodes who are reachable by EGTS Rep and EGTS Notify.
Beacons do not carry EGTS allocation information
Entire EGTS bitmap may be too big.
Periodically sending EGTS bitmap is energy consuming.

21. EGTS Allocation Example (from node 3)
Slot = tuple (time slot, channel)
MO = SO
Node 1 assigns slot (10,15) for Node 3
2. EGTS reply, broadcast
Payload :
Dst addr (3)
new allocated ABT sub-block { … }
Every node that hears the broadcasts updates its allocation bitmap table (ABT)
3. EGTS notify, broadcast
Payload :
Dst addr (1)
new allocated ABT sub-block { … }
EGTS request, unicast
Payload :
Number of slots
ABT sub-block { … }
Assuming slot (9,21) is
already assigned from node 4
for transmitting frames to node 3 21

22. EGTS Duplicated Allocation Notification
Duplicated allocation can happen
Some nodes may miss some of EGTS reply or notify. (Broadcast is not reliable)
New joining node requests a slot not knowing the slot allocation state in the area.
Send EGTS collision notification during CAP period
The existing owner of the slot detects duplicated allocation by hearing neighbor’s EGTS reply or notify.
EGTS duplicated allocation notification (Unicast) from the existing owner.
Duplicated slot id (time slot, channel).
ABT sub-block (28 bytes) around the colliding time slot.
Forces the source and the destination nodes to retry three-way-handshake EGTS allocation.

23. Hybrid Slot Allocation
Proactive: tree-based slot allocation
Tree establishment (Beacon scheduling) and slot allocation are arranged simultaneously
Reactive: mesh-based slot allocation
Assign slots on-demand basis
Path reliability: backup route in the face of route failure
Peer-to-peer communication

24. Tree-based Slot Allocation (1)
Tree establishment (Beacon scheduling) and slot allocation are arranged simultaneously.
Tree establishment (Beacon scheduling)
Option 1: Piggybacked in EGTS three-way-handshake
Option 2: Beacons provide two-hop information
EGTS Slot allocation
Assign Slot for every uplink from each node to the PAN Coordinator.
For downlink
Option 1: use the established link –some latency issue
Option 2: simultaneously establishing both uplink and downlink considering the direction of traffic.
Option 3: on-demand basis

25. TREE-Based Slot Allocation (2)
Slot = tuple (time slot, channel)
Default: 1 slot for each source
Optional: 1 slot for each link
If one slot can handle multiple packets.
If data aggregation is performed. 25

26. Tree-Based Slot Allocation (3)
MO = SO = 3, BO = 6
Multi-channel aspect is omitted in this figure for simplicity

27. Mesh-Based Slot Allocation (1)
Reactive (On-demand):
Assign slots for multihop mesh link only when necessary
Setup a backup route in the face of route failure
Peer-to-peer communication
Slot = tuple (time slot, channel) 27

28. Mesh-Based Slot Allocation
MO = SO = 3, BO = 6
Multi-channel aspect is simplified in this figure

29. Slot Allocation Rule Slot = tuple (time slot, channel)
First, randomly choose a time slot, which has at least one vacant channel.
Considering multihop delay (to be discussed in the following).
Then, choose a channel that is available in that time slot
Considering adjacent channel interference avoidance (to be discussed in the following). 29

30. Multihop Delay Consideration (best case)
Multihop Consideration to Minimize Delay
Choose the next available time slot
Then, choose a channel that is available in that time slot
If data is generated at time 0 in Dev. 4 (BO=6, MO=SO=3)
Minimum latency = tSD * 9/16 + tSD * hop / 16
= *9/ *3/16 = (ms) 30

31. Multihop Delay Consideration (worst case)
In worst case, slots may be allocated in opposite order due to lack of resources (available slots)
If data is generated at time 0 in Dev. 4 (BO=6, MO=SO=3)
Maximum latency = tSD * hop - tSD * 2/16
= * * 2/16 = (ms) 31

32. Multihop Delay Consideration (usual case)
In most cases, enough time slots are available for a multihop path
Choose next available time slot
Then, choose a channel that is available with the time slot
If data is generated at time 0 in Dev. 4 (BO=6, MO=SO=3)
Latency = tSD * 9/16 + tSD *(hop + gap)/16 < tSD
= *9/ *(3+3)/16 = (ms) < (ms) 32

33. Adaptive Channel Diversity
Link Condition Estimation
Packet Loss Rate = 1- (The number of Acks received / The number of transmitted frames).
RSSI, LQI
If detected a bad channel
Send EGTS request with a (bad) flag set.
EGTS reply with a flag : select a channel that is the most far from the current, and then select a available slot
EGTS notify with a flag. 33

34. Adjacent Channel Interference (ACI) Avoidance
Passive Scanning
RSSI of neighborhood nodes
ACI detection and avoidance
Detection method: RSSI and rejection comparison
Avoidance method:
Each node performs ACI detection before allocating an adjacent slot.
If the possibility of ACI is detected, the node avoids allocating the adjacent slot.

35. Rejection Performance
from CC 2420 datasheet
Channel Frequency
[MHz]
Rejection
Rejection = Interferer level – Transmitter signal level [dB], when PER is 1% (in view of a receiver)
ACI happens when Interferer level – Transmitter signal level > Rejection [dB] .

36. Passive Scanning
Get RSSI when listening to Beacon, EGTS signals (Req, Rep, Notify), Data packets
Neighbor RSSI Table
Example: at node 3 :
Blacklist of neighbors
Those nodes that have RSSI greater than (Receiver Sensitivity Threshold + Adjacent Channel Rejection)
Node ID
RSSI 1
-60 dBm 2
-40 dBm 4
-70 dBm
Node ID
RSSI
Allocated Slot 2
-40 dBm
(9,21), (12,15)

37. ACI Detection (Example)
Transmitter signal
Transmitter channel
Interferer signal
Interferer channel
Interferer signal – transmitter signal
Rejection
Result
-80 [dB] 16
-70 [dB] 17
(+5 MHz)
10 [dB]
35 [dB] (+5MHz) OK
-40 [dB]
40 [dB]
ACI 18
(+10 MHz)
55 [dB]
(+10MHz)
-20 [dB]
60 [dB]

38. Discussion Centralized vs. Distributed Allocation
Centralized Allocation
Allocation done by PAN Coordinator, Gateway, or Routers.
Global allocation information is accessible from the central entity.
Longer paths for control packets to/from central entity
Lack of local channel condition information.
Vulnerable to the single point of failure.
Limited flexibility: inability to local dynamics.
Distributed Allocation
Scalability: allocation done by local nodes (source/destination pair)
Adaptive to local channel conditions.
Resilient and flexible.

39. Enhancements

40. Common Channel Frequency Hopping
Common Channels: Beacon, CAP
Objective: Reliable communication in the face of time-varying and
frequency-dependant radio conditions.
Pre-defined hopping sequence: Example: 15 → 20 → 25 → 15 → …
Trade-off is longer scanning time for new joining nodes.

41. Bitmap assisted beacon scheduling (1/3)
Beacon scheduling method
New joining node(D) listen neighbor’s beacons during maximum BI
Select blank SD(2) in two hop boundary from beacon’ bitmap info.
Node D notify allocation SD information to its neighbor nodes during CAP
Node D transmit own beacon in blank SD(2)
Neighbor nodes(A, C, E) update bitmap info from node D’s beacon

42. Bitmap assisted beacon scheduling (2/3)
Beacon slot collision prevention method
Node D, E select same blank SD(2) at the same time
Node D, E try to transmit allocation-notify command frame in blank CAP
First, node D broadcast allocation-notify command frame
Second, node E broadcast allocation-notify command frame
If a node(A) receive both allocation-notify commands, it transmits deallocation-notify command frame to the latter requesting node(E).
Node D allocate blank SD(2) as own beacon slot.

43. Bitmap assisted beacon scheduling (3/3)
Beacon collision detection method
If there are beacon collisions several times, Node A notifies the collision to neighbor nodes with CAP or Beacon.
If nodes(D, E) listen collision information, try to select other blank SD.
Nodes (D, E) retry for a new allocation.

44. Summary (1) Deterministic latency Scalability High reliability
Enhanced GTS time structure
Scalability
EGTS extension, Distributed scheduling
High reliability
Adaptive channel diversity, Beacon scheduling, Tree & Mesh Extension
Low duty cycle
CAP reduction in multi-frame extension
Flexible superframe structure
Multi-superframe structure, Mesh Extension
Backward compatibility
Minimum changes to IEEE b

45. Summary (2) Also supported Network-wide Time Synchronization
IEEE e
Quality of Service
IEEE e