IEEE C802.16m-08/990
Project
Title
Date
Submitted
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Multi-radio Coexistence
Source(s)
Re:
Abstract
Purpose
Notice
Release
Patent
Policy
2008-09-05
Jin Lee, Ronny Yongho Kim, Kiseon Ryu and Youngsoo Yuk
LG Electronics
Voice: +82-31-450-1879
Email: {jins978, ronnykim, ksryu, sixs}@lge.com
MAC : Multi-Radio Coexistence; in response to the TGm Call for Contributions for Session 57
IEEE 802.16m Multi-Radio Coexistence protocol structure and time sharing scheduling
Discuss and adopt by TGm for Multi-radio coexistence SDD Text
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.
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.
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>.
Jin Lee, Ronny Yongho Kim, Kiseon Ryu and Youngsoo Yuk
LG Electronics
1. Introduction
IEEE 802.16m is required to support coexistence scenarios where non 802.16m systems operate in an unlicensed ISM band adjacent to
802.16m bands. As various radio technologies (e.g. 802.15.1, 802.11 and 802.16m) can be included in a same device, coexistence interference between adjacent bands can be occurred. For example, one device has a Bluetooth interface for wireless headset and also an 802.16m interface for cellular phone usage. Under the co-located coexistence circumstances, interference can be severely occurred between 802.16m interfaces operating at 2.3 -2.7GHz and BT/Wi-Fi interfaces operating at 2.4 GHz band.
This contribution proposes a multi-radio coexistence support protocol structure and shows how to efficiently support co-located coexistence with a minimum sacrifice of 802.16m Tx/Rx opportunity.
1

2. Co-located Multi-radio Coexistence
IEEE C802.16m-08/990
2.1 Protocol Structure
Protocol architecture to support multi-radio coexistence is shown in Figure 1. The co-existence function exists in the 802.16m MAC in order to control 802.16m radio interface for co-existence with multiple radios. The co-existence function transfers/receives information needed for co-located coexistence operation to/from C_SAP /M_SAP.
Further, the co-existence service is defined within the Network Control and Management Service (NCMS) in order to coordinate coexistence function. The co-existence service may define interfaces with other radios and this is outside the scope of 802.16m.
An 802.16m MS (co-existence Function) requests a co-existence mode to the current BS based on the information from the coexistence service. The BS responses to the MS to schedule time sharing corresponding to the requested coexistence types.
802.16m BS
802.15 Slave
802.16m MS
Multi-Radio
Co-existence
C_SAP
M_SAP
802.15 Master
Co-existence
Service
802.11 AP
802.11 STA
Figure 1. Multi-radio coexistence support protocol structure
2.2 Co-located coexistence support mechanism
2.2.1 Co-existence granularity and type
In 802.16e Rev2, power saving class is used for co-existence mode. 802.16e sleep mode allows sleep duration and partial listening interval to be utilized for co-existence operation. That is, one radio frame (5ms) is a basic unit but a 16m radio frame is divided into 8 sub-frames. This enables an 802.16m frame to be more flexible than legacy frame. Additionally, 802.11 Wi-Fi beacon (Type 2) is transmitted with 102.4ms period. One time slot is 625us duration in 802.15,1 eSCO (Type 1). Therefore, transmission may take less than a 5ms frame and granularity for co-existence duration is better to be narrowed down to sub-frame
Three co-existence types are considered. Table 1 shows classification of coexistence types based on non 16m traffic pattern.
Type Variable
Co-existence type 1 Bluetooth eSCO
Co-existence type 2 Wi-Fi Beacon
Co-existence type 3 Wi-Fi Data/Ack
Table 1. Co-existence type
1) Type 1, Bluetooth eSCO traffic has a predicted Tx/Rx pattern. Since Bluetooth is a Time Division Multiplexed (TDM)
2

IEEE C802.16m-08/990 system, master always reserves a slot for slave to transmit. Single time slot is 625us duration and we can ensure BT Tx/Rx duration within a certain amount of time.
2) Type 2, Wi-Fi Beacon traffic has a periodic Rx pattern. A cycle can be anticipated but MS can not control transmission time of Beacon message. That is, type 2 is passive and periodic traffic from an MS’s point of view.
3) Type 3, Wi-Fi Data/Ack (or Bluetooth ACL) has a variable and unpredictable pattern. Since Wi-Fi is a collision avoidance system, data transmission time can not be predictable.
2.2.2 Co-existence control signaling
An MS requests co-existence mode with co-existence type information A BS allocates a different time sharing pattern for the MS. New
MAC messages are created in order for an MS to enter/exit co-existence mode or to update a time sharing pattern (see section 2.2.3).
This independent signaling can escalate complexity but obvious coexistence process for time sharing needs to be defined.
2.2.3 Co-existence time sharing pattern example
In section 2.2.1, we categorized co-existence mode into three cases based on non 802.16m traffic features. One of the advantages is the possibility to distinguish co-existence duration and cycle in each co-existence type. This pre-defined time sharing can make the best use of categorized co-existence types for fast mode switching (from/to 802.16m).
The following three examples show how co-existence mode can be processed based on the classified co-existence types.
1) Type 1 (Bluetooth eSCO)
As we mentioned in 2.2.1, BT eSCO transmission is done at regular intervals (625us) so that we can predict when BT transmission is finished. This enables to use pre-determined time sharing pattern for Type 1.
Figure 2 describes a single slot Bluetooth Tx/Rx within 802.16m frame duration. BT master (16m multi-radio MS) can adapt BT transmission start offset to every 4 th 802.16m sub-frame start. (According to BT operation, BT master is in control, deciding what to transmit and when to transmit it.) And a BS does not transmit 802.16m DL traffic and does not expect UL traffic from 4 th to 6 th subframe duration. That is, three sub-frame durations is occupied for BT transmission. Since three sub-frame durations is suitable for at least one BT Tx/Rx, time sharing pattern below can be used for a single BT eSCO type. We do not limit only this pattern for type 1 but recommend it in that well coordinated time sharing pattern between 802.16m and Bluetooth a single eSCO. (Ratio of 802.16m to
Bluetooth is 5 to 3 subframe)
BT Succesful eSCO Tx/Rx
802.16m-BT
Time Sharing
802.16m
Active /InActive
R
X
DL
Desco
Offset
T
X
DL
Active
R
X
DL
T
X
T
X
R
X
R
X
Tesco
T
X
InActive
R
X
UL
T
X
UL
R
X
DL
Active
T
X
DL
R
X
DL
Tesco
T
X
T
X
R
X
R
X
T
X
InActive
R
X
UL
T
X
UL
Tesco
R
X
DL
Active
T
X
DL
R
X
DL
T
X
T
X
R
X
R
X
T
X
InActive
Tesco
R
X
UL
T
X
UL
R
X
DL
Active
T
X
DL
R
X
DL
T
X
T
X
R
X
Tesco
R
X
T
X
InActive
R
X
UL
T
X
UL
Active
R
X
Figure 2. Type 1 time sharing pattern (Single slot, Tesco 6, Wesco 4)
2) Type 2
Wi-Fi beacon message is broadcast periodically but each AP may transmit beacon at a different time. If we take this hint, a BS can give an MS periodic beacon Rx opportunity. The MS may indicate TBTT (Target beacon transmission time) when the request for the coexistence mode entrance is made. (Assume that TBTT value can be translated appropriately for 802.16m BS, outside scope of this contribution.) One difference with Type 1 is that an MS can not control beacon transmission time. The periodic time allocation will be continued until MS terminates co-existence type 2. If we follow this time sharing pattern for Type 2, we can almost guarantee
3

IEEE C802.16m-08/990 successful beacon Rx but 802.16m Tx/Rx has to be re-scheduled irregularly based on TBTT. How BS indicates and handles this occasional time sharing pattern shall be defined afterwards.
TBTT
Beacon Interval
UL UL UL DL DL DL DL DL UL UL UL … DL DL DL
BS
CoEX REQ
(Action: Initiate, Type 2)
CoEX RSP
(Start Frame M)
Unsolicited CoEX RSP
MS
Frame M
DL
TBTT
DL UL UL UL DL DL
Beacon Interval
DL DL DL UL UL
Unsolicited CoEX RSP
UL
...
TBTT
DL DL DL DL DL UL UL UL ……
UL UL UL DL DL DL DL DL UL UL UL
…
DL DL DL
802.11
Beacon
UL UL DL DL DL DL DL UL UL UL
...
DL
802.11
Beacon
DL UL UL UL
……
Figure xx. Type 2 time sharing pattern
3) Type 3
Figure xx shows time sharing for unpredictable Type 3. Wi-Fi data traffic can not be guaranteed within the certain amount of time. The only thing an MS can inform BS is the intention of co-existence type 3. An MS may notify BS of anticipated duration of Wi-Fi data/Ack so that the duration makes reference for BS to allocate co-existence mode duration. When an MS requests co-existence type 3, a BS assigns opportunity for type 3. If a BS allocates definite duration periodically, an MS may transmit fragmented data in each cycle.
……
BS
……
CoEX REQ
(Action: Initiate, Type 3)
MS
……
UL
UL
UL
UL
UL
UL
DL
DL
DL
DL
DL DL DL UL
CeEX RSP
(Start Frame M,
Period P)
DL DL DL UL
UL
UL
UL
UL
… DL
Frame M
…
DL DL DL DL UL
802.11 Data/Ack
UL UL DL
DL
DL
DL
DL
DL
DL
DL
DL
CoEX REQ
DL
UL
UL
UL
UL
UL
Frame M+P*
UL
...
...
DL
CoEX RSP
DL DL DL DL UL
802.11 Data/Ack
UL UL
……
Figure xx. Type 3 time sharing pattern
3. Proposed Text
------------------------------------------------- Start of Text Proposal ----------------------------------------------------------
8.1.4 Multi-radio coexistence support protocol structure
Protocol architecture to support multi-radio coexistence is shown in Figure xx. The co-existence Function is defined in the 802.16m
MAC in order to coordinate co-existence with multiple radios. The co-existence Function transfers/receives information needed for colocated coexistence operation to/from C_SAP /M_SAP.
The co-existence service is defined within the Network Control and Management Service (NCMS) in order to coordinate co-existence
Functions. IEEE 802.16m only defines the co-existence Function in order to control 802.16m radio interface for co-existence and the co-existence service which may define interfaces with other radios is outside the scope of 802.16m.
An 802.16m MS (co-existence Function) requests a co-existence mode to the current BS based on the information from the coexistence service. The BS responses to the MS to schedule time sharing corresponding to the requested coexistence types.
4

IEEE C802.16m-08/990
802.16m BS
802.15 Slave
802.16m MS
Multi-Radio
Co-existence
C_SAP
M_SAP
802.15 Master
Co-existence
Service
802.11 AP
802.11 STA
Figure xx. Multi-radio coexistence support protocol structure
17. Solutions for Co-deployment and Co-existence
17.1 Co-located coexistence
IEEE 802.16m systems provide a mechanism for a multi-radio MS to operate in 802.16m band supporting minimal interruption with other-radios which are adjacent to the 802.16m band. Minimal interruption is achieved in a time sharing scheduling manner with consideration of operating other radio traffic pattern. A unit of scheduling is a sub-frame. IEEE 802.16m systems categorize coexistence types based on non 802.16m traffic patterns and apply different time sharing patterns corresponding to the coexistence types. Time sharing patterns with periodicity are pre-defined in order to minimize signaling overhead. Time sharing pattern can be amended in case of non 802.16m traffic change events. Time sharing patterns without periodicity can be requested on demand by an
MS. This mechanism should consider cooperation with 802.16m HARQ and transmission of resource scheduling information.
------------------------------------------------- End of Text Proposal ----------------------------------------------------------
Reference:
[1] IEEE 802.16Rev2/D5, June 2008
[2] IEEE 802 Co-existence tutorial, November 2007
[3] IEEE 802.15.2 Coexistence of wireless PAN networks with other wireless devices, 2003
[4] IEEE 802.11Wireless LAN MAC and PHY Specification, 2007
5