IEEE C802.16m-09/0564 Project Title

advertisement
IEEE C802.16m-09/0564
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Co-Located Multi-Radio Coexistence Control for IEEE 802.16m
Date
Submitted
2009-03-02
Source(s)
Chi-Chen Lee, I-Kang Fu, Chih-Hao Yeh, chichen.lee@mediatek.com
Jiun-Jang Su, Kyle Hsu, Li-Chun Ko, Paul IK.Fu@mediatek.com
Cheng
MediaTek
Re:
IEEE 802.16m-09/0012, “Call for Contributions on Project 802.16m Amendment Working
Document (AWD) Content.” – New Topic for 802.16m AWD based on SDD Section 8
Abstract
According to P802.16m SDD Section 8.1.4, multi-radio coexistence support is expected to
provide protocol support to allow AMS request BS not to schedule data transmission/reception
opportunities in specific time. This contribution suggests having such control mechanism with
resolution in sub-frame level and proposes preliminary text proposal to initiate further
harmonization.
Purpose
For member’s review and adoption into P802.16m Amendment Working Document (AWD)
Notice
Release
Patent
Policy
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>.
1
IEEE C802.16m-09/0564
Co-Located Multi-Radio Coexistence Control for IEEE 802.16m
Chi-Chen Lee, I-Kang Fu, Kyle Hsu, Li-Chun Ko, Chih-Hao Yeh, Jiun-Jang Su, Paul Cheng
MediaTek
I. Introduction
In the current consumer electronic markets, multiple air interfaces can be easily found on the same user
device. For example, WiMAX devices may also equip with IEEE 802.11 and IEEE 802.15.1 interfaces. But
when those standards developed a few years ago, people did not expect it will be so popular to integrate
those different interfaces on the same device and the mutual interference problem resulted by this.
Although the WiMAX signals are separated from IEEE 802.11 and IEEE 802.15.1 signals in frequency
domain, the duplexing interference is still very significant since their transmitters and receivers are located
on the same device within a very close distance. For example, WiMAX module may be in receiving mode
while the IEEE 802.11 module is in transmitting mode. Even the transmitting power of IEEE 802.11 signal
is much lower than WiMAX, but the transmitted IEEE 802.11 signal can still be much higher than the
“received” WiMAX signal at receiver side. Even after the filering, the received signal quality of WiMAX
signal will still be unacceptable and the received data will be undecodable.
Therefore, the fundamental way to avoid the mutual interference from the co-located transceivers is to
define proper signaling and protocol support in air interface for multi-radio device to recommend the
transmission opportunities to BS. Because the multi-radio device has the best knowledge on the activity of
each of its air interfaces, so that it can passively recommend WiMAX BS to avoid interference or it can
also aggressively coordinate the transmission activities among each interface for higher efficiency.
This contribution first review the problems in current mechanism defined in IEEE 802.16 Rev2 standard,
and then proposes the proper protocol and mechanism based on current SDD text to enable more efficient
co-located multi-radio coexistence control for IEEE 802.16m.
II. Problems in Co-Located Coexistence Mechanism defined in IEEE 802.16
Revision 2 Standard
Problem#1: Additional scheduling constraints and queuing delay in MAC layer
Example: 802.16 + 802.15.1 VoIP call (e.g. WiMAX device + BT ear phone)
Consider the case that the listening window and sleep window of 802.16 are both 2 frames. The better
situation is that 802.16 BS perform DL transmission at the first frame during the listening interval as much
as possible. But even for this case, the 802.15.1 transmission interferes with the IEEE 802.16’s reception.
For this example, a reasonable approach is for the BS not to perform UL transmission during the first frame
within the listening interval. But the 802.16 transmission may still interferes with IEEE 802.15.1;s
reception during the second frame within the listening interval.
2
IEEE C802.16m-09/0564
15 ms
3.75 ms
625 us
802.15.1
frame
M
Tx
16e frame
structure
S
M
S
M
S
M
S
M
S
M
S
Rx
DL
UL
DL
UL
DL
UL
2 frame listening window (10 ms)
DL
UL
2 frame sleep window (10 ms)
Fig.1 Example of co-located coexistence problem between WiMAX and BT
Based on the co-located coexistence mechanism defined in 802.16 Rev2 standard, enabling the mode 2
should be the only choice for this example. However, this will result in more constraints and more delay for
HARQ retransmission. The basic idea is described in Figure 2.
DL HARQ retransmission can
only happen in the first frame
16e frame
structure
DL
UL
DL HARQ
ACK/NACK
DL
UL HARQ retransmission can only
happen in the second frame
UL
DL
UL
DL
UL
Difficult to adjust the UL allocation
to reduce application to air delay
2 frame listening window (10 ms)
2 frame sleep window (10 ms)
Fig. 2 Problems when utilizing mode 2 coexistence mechanism defined in IEEE 802.16 Rev2 to mitigate
the interference between WiMAX and BT
The current Rev2 standard states “The BS should populate the DL subframe the way that DL allocations
for all MS with active Co-located-Coexistence- Enabled PSCs precede in time the allocations for other
MS.”. Therefore, DL HARQ retransmission can only be sent in the first frame of the listening interval and
the UL HARQ retransmission can only be sent in the second frame of the listening interval. In addition,
this will result in about 5~10ms extra delay in DL and 10ms extra delay in UL. Meanwhile, adjusting UL
transmission to reduce transmission delay is difficult in this case since the MS may be in sleep mode.
Therefore, utilizing mode 2 results in more constraints for scheduler and additional queuing delay at MAC
layer.
Problem#2: Contradiction with the MAP NAK design in persistent allocation
Figure 3 illustrates the basic idea of the MAP NAK design for persistence allocation defined in IEEE
802.16 Rev2 standard.
3
IEEE C802.16m-09/0564
Listening window
Sleep window
Listening window
Mode 1
Listening window
Mode 2
Sleep window
Fig. 3 Basic idea of the MAP NAK design for persistence allocation defined in Rev2 standard
Take the coexistence between WiMAX and IEEE 802.15.1 for example, BS may need to de-allocate and
re-allocate persistence allocation once the co-located coexistence radio at the MS is activated. In addition,
BS may also need to adjust persistence allocation for normal sleep mode based on power saving pattern.
Figure 4 illustrate the basic problematic scenario for this example.
DL
1 frame listening window (5 ms)
UL
DL
1 frame sleep window (5 ms)
UL
DL
1 frame listening window (5 ms)
UL
DL
UL
1 frame sleep window (5 ms)
Enable sleep mode with co-located
coexistence mode 1
Persistent allocation
before entering
sleep mode
DL
UL
DL
UL
UL
DL
2 frame listening window (10 ms)
UL
DL
UL
DL
UL
Enable sleep mode with co-located
coexistence mode 2
If coexistence mode 2
DL
DL
UL
DL
UL
2 frame sleep window (10 ms)
Fig. 4 Problems to persistence allocation operation due to co-located coexistence operation defined in
Rev2 standard
This document’s concerns on current co-located coexistence mechanism defined in IEEE 802.16 Rev2
standard can be summarized as following:
Efficiency
- Fame level granularity is not enough. Finer granularity, e.g. less than one frame, can improve
the overall radio performance by increasing the time domain utilization.
4
IEEE C802.16m-09/0564
- Co-located coexistence radio characteristics are not available. Some information such as Tx
power level, operating frequency and channel bandwidth may be helpful to decide the
interference level.
- Avoid Tx/Rx at the same time is the only solution. Through inter-radio interference
measurement, some moderate interference can be solved by changing carrier frequency, using
more robust MCS (Modulation and Coding Scheme), power boosting, power control and
HARQ.
- MS can measure the interference level, e.g. using effective CINR, of potential collision duration
and report to BS, let BS decide whether or not to allocate DL burst during the potential collision
duration.
- More delay on HARQ retransmission and more queuing delay at MAC layer
- Unnecessarily de-allocate and re-allocate the persistent allocation when enter sleep mode
Flexibility
- MS must enter sleep mode to enable co-located coexistence radio
- MS may not be able to enter sleep mode for some application scenarios (e.g. Wireless Gateway)
- Strong restriction at BS, BS can only accept MS request.
Scalability
- Difficult to extend the current design to support new technology and multiple active co-located
coexisting radios.
Compatibility
- Normal power save operation is disabled when PSC is used for co-located coexistence radio.
- MAP NACK channel design conflicts with current co-located coexistence mode 1 and mode 2.
III. Current Description in P802.16m SDD
The following text had already been accepted into P802.16m SDD during Session#57.
---------------------------------------------------------------------------------------------------------------------------------------8.1.4 Multi-Radio Coexistence Support Protocol Structure
Fig.8 shows an example of multi-radio device with co-located IEEE 802.16m MS, IEEE 802.11 STA, and
IEEE 802.15.1 device. The multi-radio coexistence functional block of the IEEE 802.16m MS obtains the
information about other co-located radio’s activities, such as time characteristics, via inter-radio interface,
which is internal to multi-radio device and out of the scope of IEEE 802.16m.
IEEE 802.16m provides protocols for the multi-radio coexistence functional blocks of MS and BS to
communicate with each other via air interface. MS generates management messages to report the
information about its co-located radio activities obtained from inter-radio interface, and BS generates
management messages to respond with the corresponding actions to support multi-radio coexistence
operation. Furthermore, the multi-radio coexistence functional block at BS communicates with the
scheduler functional block to operate properly according to the reported co-located coexistence activities.
The multi-radio coexistence function can be used independently from sleep mode operation to enable
optimal power efficiency with a high level of coexistence support. However, when sleep mode provides
sufficient co-located coexistence support, the multi-radio coexistence function may not be used.
5
IEEE C802.16m-09/0564
IEEE
802.16m BS
air interface
Multi-Radio Device
IEEE
802.15.1
device
IEEE
802.15.1
device
IEEE
802.16m
MS
IEEE
802.11
STA
IEEE 802.11
STA
inter-radio interface
Fig.13 Example of Multi-Radio Device with Co-Located IEEE 802.16m MS, IEEE 802.11 STA, and IEEE
802.15.1 device
---------------------------------------------------------------------------------------------------------------------------------------Based on the general ideas and architecture agreed in SDD, this contribution proposes the following text
input for P802.16m Amendment Working Document for enabling the sub-frame based co-located multiradio coexistence mechanism for IEEE 802.16m.
IV. Proposed Text Modification to P802.16m Amendment Working Document
---------------------------------------------------------Start of the Text----------------------------------------------------------[Add the following text into P802.16m AWD (IEEE 802.16m-09/0010)]
X. Co-Located Coexistence Support
ABS and AMS shall support the Co-Located Coexistence (CLC) operation to control the interference from colocated radio transceiver compliant with non IEEE 802.16m standards. From AMS perspective, the CLC
operation includes two phases: 1) learning phase and 2) negotiation phase.
During the learning phase, AMS should learn the characteristics of other activated co-located radio transceivers.
A proprietary PTA interface inside the AMS device may help learning operation, but it is beyond the scope the
document. During the learning phase, AMS may send MOB_CLC-REQ message (x.x.x) to serving ABS for
requesting a recognition period with no DL data transmission. The granted time period will be replied through
MOB_CLC-RSP message (x.x.x+1). AMS should learn the Tx power, Rx sensitivity and the traffic pattern of
the activated co-located radio transceivers during the learning phase. If the AMS cannot obtain enough
information during the granted recognition period, it can send out the MOB_CLC-REQ again to extend the
period or request another period to obtain the necessary information.
After the learning phase, AMS will then enter the negotiation phase. AMS shall first send MOB_CLC-REQ
message to recommend the DL and UL traffic patterns to serving ABS during the negotiation phase. The
recommended traffic pattern is in unit of sub-frame according to the binary indicator depicted in MOB_CLCREQ message. ABS should prevent scheduling the data be transmitted to/from the AMS at the forbidden subframes depicted in the MOB_CLC-REQ message. If the data scheduling over those sub-frames cannot be
6
IEEE C802.16m-09/0564
prevent, AMS should schedule the data be transmitted by the most robust MCS over those sub-frames.
Y. 1 MOB_CLC-REQ (Co-Located Coexistence control request) message
[TBD]
Y. 2 MOB_CLC-RSP (Co-Located Coexistence control response) message
[TBD]
----------------------------------------------------------End of the Text-----------------------------------------------------------
7
Download