Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Robust Multi-Channel Adaptation for Smart Utility Networks] Date Submitted: [8 May, 2009] Source: [Gahng-seop Ahn, Junsun Ryu, Myung Lee, ChangSub Shin, Seong-soon Joo] 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, junsun.ryu@gmail.com, lee@ccny.cuny.edu, shincs@etri.re.kr, ssjoo@etri.re.kr] Re: [IEEE P802.15.4g] Abstract: [This document proposes an robust multi-channel adaptation for smart utility networks] Purpose: [Discussion in 802.15.4g 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.

Robust Multi-Channel Adaptation for Smart Utility Networks CUNY, ETRI

Objectives MAC Modifications needed to support outdoor Low Data Rate Wireless Smart Metering Utility Network requirements Robustness Scalability High reliability Energy efficiency

Motivation Densely deployed large scale network in geographically large area The variance of channel condition is large. Channel Asymmetry. Common channel approach is limited Therefore, multi-channel adaptation is required. Smart Meter Smart Meter Smart Meter Concentration Point Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter

Multi-channel Adaptation Asynchronous approach Non-beacon mode Multi-channel Meshed Tree (15.5 based) Synchronous approach Beacon-enabled mode EGTS: Enhanced Guaranteed Time Slots

1. Asynchronous Approach

Receiver-based Channel Use (1) Each device is listening to its designated channel. The sender device switch to the channel of the receiver device and transmit a DATA frame. The sender device switch back to its own channel. The receiver device switch to the channel of the sender device and transmit a ACK frame (if requested). The receiver device switch back to its own channel. DATA Sender Receiver ACK

Receiver-based Channel Use (2) If the sender knows that it can hear receiver’s channel as well. (The sender can find out whether it can hear the receiver’s channel during association or by performing multi-channel probing.) Each device is listening to its designated channel. The sender device switch to the channel of the receiver device and transmit a DATA frame with a flag indicating that the sender can hear receiver’s channel. The receiver device transmit a ACK frame (if requested) using receiver’s channel. The sender device switch back to its own channel after it receives the ACK. DATA Sender Receiver ACK

Channel Selection A PAN can be configured to use a block of channels Cmax channels among all Ctotal channels. Motivation: to reduce the active scanning time. Considering adjacent channel interference and coherent bandwidth. For example, if there are 16 channels (channel 11 to channel 26): PAN1 uses channel 11, 17, 23. PAN2 uses channel 13, 19, 25. PAN3 uses channel 15, 21.

Multi-channel Active Scan A device perform active scan for all Cmax channels twice at worst case. For example, Cmax = 4, Coordinator’s designated channel is C4, New device’s good channel is C3. Channel C4 C1 C2 C3 C4 C3 C4 Coordinator T T New Device Channel C1 C2 C3 C4 C1 C2 C3 C4 C3 Beacon Request Beacon Association Request Association Response

Channel selection based on link quality (optional) A device perform active scan for all Cmax channels twice and choose the best RSSI among the received beacons. For example, Cmax = 4, Coordinator’s designated channel is C4, New device’s good channel is C1, C3 . Channel C4 C1 C2 C3 C4 C1 C4 Coordinator T T New Device Channel C1 C2 C3 C4 C1 C2 C3 C4 C1 Beacon Request Beacon Association Request Association Response

Multi-channel Hello A device can send a multi-channel hello message to its one-hop neighbors to inform its designated channel. The device should send the same hello message on each channel sequentially starting from its designated channel. Optional: The device can request hello reply by setting a flag in the hello message. Two Neighbor Example: Cmax = 4, Coordinator’s designated channel is C4, New device’s good channel is C3. Channel C4 C3 C4 Neighbor 1 T New Device Channel C3 C4 C1 C2 C3 Hello Hello Reply Neighbor 2 C2 C3 C2 Channel

Three-way Handshake Channel Probing The requesting device sends a channel probe request frame to one of its neighbors on the designated channel of the neighbor (e.g., brown) indicating the channel to probe (e.g., red). The neighbor sends a channel probe reply frame back on the requester’s channel (e.g., green). The neighbor sends a channel probe frame using the channel indicated in the probe request (e.g., red). Requester Neighbor Channel Probe Request Channel Probe Reply Channel Probe

Recovery from Bad Channel Condition Recovery from the case when the designated channel of a device has gone bad The neighboring devices can immediately find a backup route bypassing the device (for example, using the feature of 15.5 meshed tree). The device can check the condition of its designated channel and switch to a better channel. (Using the channel probing). Smart Meter Smart Meter ? X X Concentration Point Smart Meter

Channel Adaptation The device can check the condition of its designated channel using three-way handshake channel probing with one of its neighbors. If the channel condition is bad, the device can probe other channels and switch to a better channel. After switching the channel, the device shall broadcast a multi-channel hello to its one-hop neighbors. ? Concentration Point Smart Meter X Smart Meter Smart Meter ! Concentration Point Smart Meter

Optimizing the Channel Diversity Channel diversity has its cost. The device have to switch its channels frequently if each neighbors are using a different channel. To minimize the number of diverse channels, Among the good channels, choose the channel that is being used by the majority of its neighbors. Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter Smart Meter

2. Synchronous Approach For details, refer to 15-08-0775-01-004e-distributed-multi-channel-mesh-extension

EGTS: Enhanced Guaranteed Time Slots Beacon-enabled mode Robust and reliable communication Multi-channel support for GTS (Guaranteed Time Slot). Co-channel interference avoidance (EGTS three-way handshake). Adjacent channel interference avoidance (Passive RSSI monitoring). Dynamic channel diversity Detection of bad channel condition and reallocation of the slot to a better channel. Beacon collision avoidance Bit-map assisted beacon scheduling.

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 19

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.

Flexible Multi-superframe For low duty cycle 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 21

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 22

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 23

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)

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 25

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

Discussion: Issue of EGTS in 15.4g EGTS set up (as proposed in 15.4e) is still based on common channel approach! 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 28

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

2. Beacon Frequency Hopping No common channel: Each node is listening to its designated channel. Each node broadcast beacons on each available channel sequentially. Objective: Robust communication in the face of asymmetric channel conditions. Pre-defined hopping sequence: Example: 15 → 20 → 25 → 15 → … Trade-off is longer scanning time for new joining nodes.

We are open to further collaborations with 4g members! Thank you! We are open to further collaborations with 4g members!