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:[+1-212-650-7219], FAX: [], E-Mail:[gahn@ccny.cuny.edu] Re: [IEEE P802.15.4e] Abstract: [This document proposes an enhancement to IEEE 802.15.4-2006 MAC Layer with distributed multi-channel mesh extension] Purpose: [Discussion in 802.15.4e Task Group] Notice: This document has been prepared to assist the IEEE P802.15. 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 P802.15.

A Joint Proposal for IEEE802. 15 A Joint Proposal for IEEE802.15.4e: 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**

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 802.15.4b

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

Superframe Structure for 15.4b doc.: IEEE 802.15-<15-08-0xxx-00-004e> 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>

Let’s Focus on a Simple Scenario doc.: IEEE 802.15-<15-08-0xxx-00-004e> 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

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

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>

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.

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

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

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

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

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

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 00000000 00000000 01000100 01000100 00001000 00000100 00000000 01000000 17

ABT sub-block … 00000000 00000000 00001000 00000100 00000000 01000000 00001000 00000000 01000100 00000100 10000000 01000000 01000100 01000100 10000000 00000000 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

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)

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.

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 {0000000000000000 0000100000000000 … 0000000000000000} 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 {0000000000000000 0000100000000000 … 0000000000000000} EGTS request, unicast Payload : Number of slots ABT sub-block {0000000000100000 0000000000000000 … 0000000000000000} Assuming slot (9,21) is already assigned from node 4 for transmitting frames to node 3 21

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.

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

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

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

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

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

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

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

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 = 122.88*9/16 + 122.88*3/16 = 92.16 (ms) 30

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 = 122.88 * 3 - 122.88 * 2/16 = 353.28 (ms) 31

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 = 122.88*9/16 + 122.88*(3+3)/16 = 115.2 (ms) < 122.88 (ms) 32

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

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.

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

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)

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]

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.

Enhancements

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.

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

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.

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.

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 802.15.4b

Summary (2) Also supported Network-wide Time Synchronization IEEE 802.15-08-0617-01-004e Quality of Service IEEE 802.15-08-0621-01-004e