Doc.: IEEE 802.15-09-0306-01-004g Submission Myung Lee at al May 2009 Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Slides:



Advertisements
Similar presentations
Doc.: IEEE e Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Modifying.
Advertisements

IEEE r0 Submission July 2007 R. Zhang, H. Jung, E. Lee, M. Lee Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE e SubmissionSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Time.
Doc.: IEEE Submission May 10, 2006 Yongjun Liu,Na Shan, HuaweiSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE Submission ETRI May 2015 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
IEEE e Submission: Wireless Ping for Network Management 8 September 2008 Bhatti, Mitsubishi ElectricSlide 1 Project: IEEE P
Doc.: IEEE k Submission ETRI July 2011 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /272r0 Submission June 2001 Phil Jamieson, Philips SemiconductorsSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE /037r0 Submission January 2003 Ed Callaway, Motorola Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE Submission G. R Hiertz, Y. Zang, S. Max, H.-J. ReumermanSlide 1 Project: IEEE P Working Group for.
Doc.: e Submission Liang Li, J Shen,Betty ZhouSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE b Submission September 2004 Myung Lee, et al,Slide 1 NOTE: Update all red fields replacing with your information; they.
Doc.: IEEE e SubmissionSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [beacon.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
November 2011 doc.: IEEE k Rolfe, et al. BCASlide 1Submission Rolfe, et al. BCASlide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE e Submission May 2008 ETRISlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE k Submission ETRI Sep 2011 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE g Submission Myung Lee at al May 2009 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE g Submission Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Supporting.
e Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [The embedded.
Doc. Submission, Slide 1 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,
Submission Slide 1 doc.: IEEE e September 2009 [Lee, et al] Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.IEEE b Submission Nov 2004 Liang Li, WXZJ Inc. Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE g Submission [CUNY] [ETRI] May 2009 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE e Submission Jan, 2009 Ning Gu, Liang Zhang, Haito Lui Slide 1 Project: IEEE P Working Group for Wireless Personal.
TG4e doc.: IEEE e September 2008 W.-C. Jeong Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE COEX-02/004r0 Submission 23 January, 2001 James P. K. Gilb, Appairent Technologies Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE b Submission August 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi ElectricSlide 1 Project: IEEE P Working Group for.
Doc.: IEEE k Submission ETRI Sep 2011 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
November 2011 doc.: IEEE k Rolfe, et al. BCASlide 1Submission Rolfe, et al. BCASlide 1 Project: IEEE P Working Group for Wireless.
Doc.: IEEE /250r0 Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE Submission ETRI May 2015 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE ulp Submission Slide 1 July 2012 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /449r0 Submission November 2001 Ed Callaway, Motorola Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE m Submission ETRI July 2012 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE /yyyr0 Submission Aug 2001 Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE /440r2 Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE e Submission July 2009 Andy Summers, Skip Ashton, EmberSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE m SubmissionSlide 1 May 2012 Project: IEEE P Working Group for Wireless Personal Area Networks(WPANs) Submission.
<author>, <company>
Submission Title: [EGTS Subgroup Report for IEEE e]
May Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Introduction of MAC related proposals] Date.
<month year> doc.: IEEE < e > <Sep 2008>
November 2005 doc.: IEEE November 2005
doc.: IEEE <doc#>
<month year> doc.: IEEE July 2005
Date Submitted: [November 9, 2009]
doc.: IEEE <doc#>
Date Submitted: [November 9, 2009]
doc.: IEEE <doc#>
November 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Distributed channel hopping MAC for industrial.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Robust Multi-Channel Adaptation for Smart Utility Networks]
doc.: IEEE <doc#>
July 2008 doc.: IEEE July 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Out-of-band.
Submission Title: [Distributed Multi-Channel Mesh Extension]
doc.: IEEE <doc#>
<month year> doc.: IEEE <doc#>
14 July, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Distributed and beacon-enabled multiple.
<month year> doc.: IEEE e doc.: IEEE < e >
doc.: IEEE <doc#>
doc.: IEEE <doc#>
18 March 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Extending the MAC Superframe of
doc.: IEEE <doc#>
<month year> doc.: IEEE < e> doc.: IEEE < e>b
Guaranteed Services for Mesh
<month year> doc.: IEEE July 2007
Presentation transcript:

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 1 Project: IEEE P 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 [140 th 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 2 Robust Multi-Channel Adaptation for Smart Utility Networks CUNY, ETRI

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 3 Objectives MAC Modifications needed to support outdoor Low Data Rate Wireless Smart Metering Utility Network requirements –Robustness –Scalability –High reliability –Energy efficiency

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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. Concentration Point Smart Meter

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 5 Multi-channel Adaptation 1.Asynchronous approach –Non-beacon mode –Multi-channel Meshed Tree (15.5 based) 2.Synchronous approach –Beacon-enabled mode –EGTS: Enhanced Guaranteed Time Slots

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 6 1. Asynchronous Approach

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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. DAT A ACK Sender Receiver

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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. DAT A ACK Sender Receiver

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 9 Channel Selection A PAN can be configured to use a block of channels –C max channels among all C total 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 10 Multi-channel Active Scan Coordinator New Device Channel Association Response C4C4 C1C1 C2C2 C3C3 C3C3 C2C2 C1C1 C3C3 C2C2 C1C1 C4C4 C3C3 Beacon Request Beacon Association Request For example, C max = 4, Coordinator’s designated channel is C 4, New device’s good channel is C 3. T C4C4 C3C3 C4C4 C4C4 T A device perform active scan for all C max channels twice at worst case.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 11 Channel selection based on link quality (optional) Coordinator New Device Channel Association Response C4C4 C1C1 C2C2 C3C3 C3C3 C2C2 C1C1 C3C3 C2C2 C1C1 C4C4 C1C1 Beacon Request Beacon Association Request For example, C max = 4, Coordinator’s designated channel is C 4, New device’s good channel is C 1, C 3. T C4C4 C1C1 C4C4 C4C4 T A device perform active scan for all C max channels twice and choose the best RSSI among the received beacons.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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. Neighbor 1 New Device Channel C4C4 C1C1 C4C4 C3C3 C2C2 Two Neighbor Example: C max = 4, Coordinator’s designated channel is C 4, New device’s good channel is C 3. T C3C3 C2C2 Neighbor 2 Channel C3C3 C3C3 Hello Hello Reply C2C2 C4C4

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 13 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. (See the following slides). ? Concentration Point Smart Meter X X

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 14 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). Channel Probe Request RequesterNeighbor Channel Probe Reply Channel Probe

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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 X Concentration Point Smart Meter !

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 17 Remind: Multi-channel Adaptation 1.Asynchronous approach –Non-beacon mode –Multi-channel Meshed Tree (15.5 based) 2.Synchronous approach –Beacon-enabled mode –EGTS: Enhanced Guaranteed Time Slots

doc.: IEEE g Submission Myung Lee at al May 2009 Slide Synchronous Approach

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 19 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 20 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 21 EGTS Mesh Extension 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. Multi-channel aspect is omitted in this figure for simplicity

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 22 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*2 MO 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 23 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 Flexible Multi-superframe (2)

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 24 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. BO = 6, SO = 3, MO = 5 Inactive / sleep Active / awake Node Flexible Multi-superframe (3)

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 25 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 26 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 27 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. … …

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 28 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)

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 29 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 30 EGTS Allocation Example (from node 3) 2. EGTS reply, broadcast Payload : Dst addr (3) new allocated ABT sub-block { … } 1.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 Slot = tuple (time slot, channel) MO = SO Node 1 assigns slot (10,15) for Node 3 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 { … }

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 31 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 32 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 33 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 34 TREE-Based Slot Allocation (2) Optional: 1 slot for each link Default: 1 slot for each source Slot = tuple (time slot, channel) If one slot can handle multiple packets. If data aggregation is performed.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 35 Tree-Based Slot Allocation (3) MO = SO = 3, BO = 6 Multi-channel aspect is omitted in this figure for simplicity

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 36 Mesh-Based Slot Allocation (1) Slot = tuple (time slot, channel) Reactive (On-demand): Assign slots for multihop mesh link only when necessary (1)Setup a backup route in the face of route failure (2)Peer-to-peer communication

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 37 Mesh-Based Slot Allocation MO = SO = 3, BO = 6 Multi-channel aspect is simplified in this figure

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 38 Slot Allocation Rule Slot = tuple (time slot, channel) First, randomly choose a time slot, which has at least one vacant channel. Then, choose a channel that is available in that time slot –Considering adjacent channel interference avoidance (to be discussed in the following).

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 39 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 40 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 41 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].

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 42 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) –Example: at node 3 : Node IDRSSI 1-60 dBm 2-40 dBm 4-70 dBm Node IDRSSIAllocated Slot 2-40 dBm (9,21), (12,15)

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 43 ACI Detection (Example) Transmitter signal Transmitter channel Interferer signal Interferer channel Interferer signal – transmitter signal RejectionResult -80 [dB]16-70 [dB]17 (+5 MHz) 10 [dB]35 [dB] (+5MHz) OK -80 [dB]16-40 [dB]17 (+5 MHz) 40 [dB]35 [dB] (+5MHz) ACI -80 [dB]16-40 [dB]18 (+10 MHz) 40 [dB]55 [dB] (+10MHz) OK -80 [dB]16-20 [dB]18 (+10 MHz) 60 [dB]55 [dB] (+10MHz) ACI

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 44 Bitmap assisted beacon scheduling (1/3) Beacon scheduling method 1.New joining node(D) listen neighbor’s beacons during maximum BI 2.Select blank SD(2) in two hop boundary from beacon’ bitmap info. 3.Node D notify allocation SD information to its neighbor nodes during CAP 4.Node D transmit own beacon in blank SD(2) 5.Neighbor nodes(A, C, E) update bitmap info from node D’s beacon

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 45 Bitmap assisted beacon scheduling (2/3) Beacon slot collision prevention method 1.Node D, E select same blank SD(2) at the same time 2.Node D, E try to transmit allocation-notify command frame in blank CAP 3.First, node D broadcast allocation-notify command frame 4.Second, node E broadcast allocation-notify command frame 5.If a node(A) receive both allocation-notify commands, it transmits deallocation-notify command frame to the latter requesting node(E). 6.Node D allocate blank SD(2) as own beacon slot.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 46 Bitmap assisted beacon scheduling (3/3) Beacon collision detection method 1.If there are beacon collisions several times, Node A notifies the collision to neighbor nodes with CAP or Beacon. 2.If nodes(D, E) listen collision information, try to select other blank SD. 3.Nodes (D, E) retry for a new allocation.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 47 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

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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.

doc.: IEEE g Submission Myung Lee at al May 2009 Slide 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.