Collocated Multi-Radio Coexistence for 802.16m – Considerations and Proposals
IEEE 802.16 Presentation Submission Template (Rev. 9)
Document Number:
C80216m-08/1083r1
Date Submitted:
2008-09-05
Source:
Shashikant Maheshwari, Yousuf Saifullah
Nokia Siemens Networks
Jan Suumaki, Andrea Bacioccola
Nokia
Email:
shashi.maheshwari@nsn.com
Email:
jan.suumaki@nokia.com
Venue:
IEEE 802.16m-08/033, “Call for Comments and Contributions on Project 802.16m System Description Document (SDD)”.
Target topic: “Multi-Radio Coexistence” ; MAC related
Base Contribution:
This is the base contribution.
Purpose:
To be discussed and adopted by TGm for the 802.16m SDD
Notice:
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in
the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material
contained herein.
Release:
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an
IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s
sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this
contribution may be made public by IEEE 802.16.
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.
Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.
Outline
•
•
•
•
•
Background
802.16e/Rev2 analysis
Considerations and goals of .16m coexistence
Proposals
Proposed Text for SDD
Background
• Collocated coexistence is used to reduce interference between
WiMAX and BT/WiFi within one device.
– Simultaneous WiMAX Tx – BT/WiFi Tx -> No interference (if
separate antennas)
• However, WiMAX Tx may cause some interference to non-collocated
device like BT headset if it is in close range
– Simultaneous WiMAX Rx – BT/WiFi Rx -> No interference (if
separate antennas)
– Simultaneous WiMAX Tx – BT/WiFi Rx -> Major interference to
BT/WiFi reception, coexistence solution needed to prevent this.
– Simultaneous WiMAX Rx – BT/WiFi Tx -> Some interference to
WiMAX reception, coexistence solution needed to prevent this.
802.16e/Rev2 solutions
•
Currently in Rev2 the following four methods have been defined for coexistence
(WiMAX-BT/WiFi):
1. Collocated coexistence mode 1: BS shall obey all parameters requested by MS for Sleep
Mode to enable coexistence. BS shall neither deactivate Sleep Mode.
2. Collocated coexistence mode 2: In addition of mode 1 rules,
• BS should use the first frame in listening window for DL transmission
• BS should make DL allocations for coexistence terminals before other terminals
 Basically mode 1 is purposed for WiMAX-WiFi coexistence and mode 2 for WiMAXBT coexistence. Both mode 1 & 2 reduces interference in time domain.
3. UL band AMC sub-channels: By using AMC mode, BS may populate frequencies which
are far from BT/WiFi frequencies.
 This can be used with/without collocated coexistence mode 1 or 2. This reduces
interference in frequency domain.
4. MAP relevance: This changes the rules of the UL MAP relevance when using sleep
mode. Normally, UL MAP cannot be in the last frame of listening window, because it
would refer to the frame in sleep window. When using this feature, UL MAP in the last
frame of the listening window is allowed. MS shall just wake-up for UL sub-frame in the
sleep window. This mode can be used only with collocated coexistence mode 1.
 This won’t reduce interference as such, but increases possible UL resource allocations.
Also this method enables listening window of 1 frame (without this minimum listening
window size is 2 frames)
Note! If sleep interval is 2 or longer, then this method increases wake-up points ->
optimal only when sleep interval is 1 frame.
Problems with Rev2 solutions
• Collocated coexistence mode 1 (WiFi-WiMAX coexistence):
– Sleep and listening intervals are fixed lengths, i.e. similar to PSC Type
II. However, this method is not optimal from power consumption point
of view in certain traffic / use case scenarios like Web-browsing (power
consumption could be several times higher compared PSC Type I)
– This does not solve problem with reception of WiFi Beacon. Beacon is
sent periodically 102.4ms and contains critical system data for WiFi.
Beacon interval cannot be aligned with WiMAX.
-> Beacon reception cannot protected with Rev2 methods, and thus
WiFi performance may degrade. Especially if WiFi power saving (e.g.
Legacy PS) is enabled, the losing of the Beacon is very harmful
because Beacon triggers data transmission in DL direction (Beacon has
TIM field to indicate pending downlink data. If there is pending data,
MS shall poll WiFi AP. This polling only then triggers actual downlink
data transmission)
Problems with Rev2 solutions
• Collocated coexistence mode 2 (BT-WiMAX
coexistence):
– Similarly than in mode 1, power efficiency is not optimal in
certain traffic / use case scenarios (e.g. Web browsing with
PSC Type I would consume a lot less power)
– Limited scheduling possibilities -> may become problem if
several collocated coexistence mode 2 terminals are
attached to the same BS (due rule: DL traffic should locate
in the beginning of first frame of listening window)
– Does not fully guarantee that BT and WiMAX radio
transmission/reception would not collide (e.g. if BS is not
able to schedule data enough early location in DL subframe).
Problems with Rev2 solutions
• UL band AMC sub-channels (WiFi/BTWiMAX coexistence):
– This mode reduces mobility because frequency
diversity is not used. Thus AMC is not optimal for
fast moving terminals.
– Interference reduction is limited. Current guard
bands in ISM channel are 10/16 MHz. AMC mode
could move center frequency with few MHz.
Problems with Rev2 solutions
• MAP relevance (WiFi-WiMAX coexistence):
– This enables listening interval of 1 frame
– But if sleep interval is two frames or longer, then
UL MAP in last frame of listening interval would
trigger additional wake-up point -> power
consumption increases.
– Also this is limited to collocated coexistence mode
1, i.e. WiFi-WiMAX coexistence.
=> Benefits to this mode are quite questionable from
coexistence point of view.
If using Rev2 methods in .16m
• Rev2 coexistence methods usage in .16m:
1. Collocated coexistence mode 1: If Sleep Mode in .16m is similar to
.16e, then this method should be applicable as such. WiFi transmission
is so flexible that possible differences in .16m frame structure / frame
usage (MAP locations, MAP relevancies, …) does not matter.
However, the same problems exists as in Rev2.
2. Collocated coexistence mode 2: Basic idea behind this mode should be
applicable to .16m, but specific rules for DL / UL allocations depends
on .16m frame structure / frame usage (MAP locations, MAP
relevancies, …). However, the same problems exists as in Rev2.
3. UL band AMC sub-channels: 16m has also adjacent channel allocation
(called ‘Localized Resource Unit’ in .16m). Interference reduction is
limited as in Rev2.
4. MAP relevance. Usability of this method depends on .16m frame
structure / frame usage (MAP locations, MAP relevancies, …). This
method is optimal only when UL allocation (during sleep window) is
followed immediately by listening window. Benefits of this mode are
questionable.
Considerations of .16m coexistence
• BT slot length is .625ms which is basically the same as proposed .16m subframe length
-> This enables more possibilities for .16m WiMAX-BT coexistence
compared to .16e.
• .16m super frame concept does not suit well to coexistence, because the
length is 20ms which cannot be aligned directly to the most common BT
hands-free profile interval (SCO-HV3). Also super frame header reception
shall be protected to enable reliable operation during super frame (this
problem does not exist in .16e)
• WiMAX and WiFi radios may co-locate also in Gateway type of device,
where Gateway acts as a WiFi AP and WiMAX SS/MS. In this case, no
standardized coexistence support needed, but only implementation specific
timing control between WiMAX and WiFi radios.
Goals of .16m coexistence solutions
•
Solutions should enable all current and future coexistence scenarios.
– Solutions should support multiple simultaneous coexistence scenarios, e.g.
BT+WiFi+WiMAX
– Solutions should support also other current & future technologies
•
-> Solutions should be enough generic and flexible
- Enough detailed granularity
- Rx and Tx separation in coexistence solution
Solutions should support efficient power saving mechanisms.
– No compromises to Sleep Mode functionality due coexistence
•
-> Solutions should be independent to power saving mechanisms
Mobility should not degrade significantly coexistence performance
– Handover should not cause too much collocated interference
•
-> Coexistence should be considered also in handover / network entry
design
BS Scheduling should not be increased too much due coexistence
– Scheduling complexity should be in reasonable level
-> Scheduling should be considered in coexistence solutions.
Coexistence categories
• Collocated coexistence could be divided into three categories
– Type I: BT SCO/eSCO. Fixed or semi-fixed transmission pattern and
interval with high coexistence support (=protection) need. WiMAX
should adapt to BT transmission patterns to enable reliable BT
transmission.
– Type II: WiFi Beacon. Fixed interval, but cannot aligned with WiMAX
transmission. Beacon interval is 102.4ms. Note! Beacon skipping may
multiply this interval, i.e. MS is not need to receive every Beacon.
– Type III: WiFi Data, BT ACL. Adaptive / variable transmission pattern.
WiMAX does not need to adapt transmission pattern, but just give
enough air interface resources for other radios.
• However, special needs of WiFi/BT transmission shall be supported in
WiMAX coexistence support for optimal performance/behavior. For
example: WiFi power saving methods would work more optimally if
immediately after WiFi Tx (UL) enough long period is given for WiFi Rx
(DL)
Solution proposals - general
• Dedicated messages to configure coexistence (instead of Sleep Mode
messages)
• Broadcast message to inform capabilities supported by serving BS (and
possibly neighbor BSs).
– Supported coexistence types
– Generic limitations for coexistence support
-> If neighbor BS coexistence capability information is available, it could be used
also in HO decision.
• MS coexistence capabilities indicated during registration
• WiFi: In normal operation mode, MS cannot affect to timing of DL data
transmission, so resources should be allocated based on statistics to enable
appropriate WiFi performance. However, if WiFi power saving method
(Legacy / U-APSD) is used, then MS could have some control for DL
timing -> WiMAX coexistence support should be aligned with WiFi
transmission pattern / behavior.
• WiMAX should avoid scanning and measuring during blocked sub-frames /
frames due high probability of collocated interference (scanning/measuring
results may be inaccurate)
Solution proposals for coexistence type I
• MS defines coexistence parameters and sends request
– Coexistence type: Type I (SCO/eSCO)
– Adjustable timing: MS defines whether it is able to adjust timing of BT
transmission
– Start frame: Requested start frame for collocated coexistence.
– Bit-pattern: Defining blocked .16m sub-frames:
• 2-bits / sub-frame – own values for
–
–
–
–
non-blocked sub-frame
blocked sub-frame - static Master slot
blocked sub-frame - static Slave slot
retransmission window slot (eSCO only)
• SCO-HV3: Static Master and Slave slots, BT period = 6 slots / sub-frames (12bit bitpattern). Other SCO packet types might not be feasible for coexistence at all.
• eSCO-EVx: Static Master and Slave slots + retransmission window = 4-12 slots /
sub-frames.
• BS responds
– Status: Accept/Reject
– Reason (optional): The reason for the rejection
– Start frame (optional – may exist only if adjustable timing is supported):
Negotiated start frame.
– Bit-pattern (optional): Adjusting retransmission window in eSCO case
• eSCO: Location of allowed retransmission slots during retransmission window
configured by MS. -> This could be used to optimize WiMAX BS scheduling
Solution proposals for coexistence type I
• Additional rules & recommendations:
– In case of adjustable timing is supported:
• MS should try adjust BT transmission so that static BT Tx slot does not
overlap any SFH, i.e. using odd sub-frame numbers for Master slot (Tx).
• BT and WiMAX clocks should be synchronized and clock drifting avoided
(BT slot starting time aligned with WiMAX sub-frame starting time)
– If UL MAP overlaps BT Tx, then BS shall not provide any UL
allocations even actual UL resource region is not blocked.
– If DL MAP overlaps BT Tx, then BS shall not provide any DL
allocations even actual DL resource region is not blocked.
– In eSCO case, 8-slot frame interval is recommended if used BT profile
allows it.
– In eSCO case, BS shall configure at least two adjacent slots for
retransmission where the Master slot is the first one.
• Summary: Bit-pattern defines blocked .16m sub-frames to give
interference free resources for BT transmission.
Solution proposals for coexistence type II
• MS defines coexistence parameters and sends request
–
–
–
–
Coexistence type: Type II (WiFi Beacon reception)
Start frame: Start frame of collocated coexistence.
Initial timer: Time difference between start frame and next Beacon.
Timer interval: Beacon interval length – this could be also multiple of
102.4ms Beacon intervals.
• BS responds
– Status: Accept/Reject
– Reason (optional): The reason for the rejection
• Additional rules & recommendations:
– BS shall avoid relevant MAP sending and any UL/DL allocation during
Beacon reception.
– If Beacon interval changes (e.g. due AP roaming) or BS makes
allocation during Beacon reception (this is sign that BS blocking
interval is not anymore aligned with Beacon interval), MS should send
reconfiguration.
• Summary: Timer based Beacon protection in BS
Solution proposals for coexistence type III
• MS defines coexistence parameters and sends request
– Coexistence type: Type III (BT ACL, WiFi data)
– Resource request: Requested amount of resources for WiFi / BT ACL
data transmission, unit could be percentage (e.g. 25%, 50%,...)
-> Needed resource amount depends on use case scenario
• BS responds
–
–
–
–
Status: Accept/Reject
Reason (optional): The reason for the rejection
Start frame: Negotiated start frame.
Bit-pattern: Defining blocked .16m frames
-> Due bursty nature of BT ACL / WiFi data the sub-frame granularity
would be too fine.
• Additional rules & recommendations:
– Block sequence, i.e. bit-pattern may consist multiple super-frames.
– First frame in super frame should not be blocked due SFH.
– WiFi power saving methods are recommend to use.
• Summary: Bit-pattern defines blocked .16m frames to give
interference free resources to BT/WiFi transmission.
Proposed Text for SDD
Insert the following text into Chapter 10:
10.X Collocated Multi-Radio Coexistence
Collocated multi-radio coexistence function is used to
reduce interference between IEEE 802.16m and other
radio technologies (like IEEE 802.11 or IEEE
802.15.1) co-located in the MS.
Collocated multi-radio coexistence can be used
independently from sleep mode operation to enable
optimal power efficiency with a high level of
coexistence support.