1. 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:[ ], FAX: [],
Re: [IEEE P g]
Abstract: [This document proposes an robust multi-channel adaptation for smart utility networks]
Purpose: [Discussion in g 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. Robust Multi-Channel Adaptation for Smart Utility Networks
CUNY, ETRI

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

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

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

6. 1. Asynchronous Approach

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

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

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

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

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

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

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

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

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

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

17. 2. Synchronous Approach
For details, refer to e-distributed-multi-channel-mesh-extension

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

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

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

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

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

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

24. 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)

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

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

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

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

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

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

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