DOC

jinlei60020191@huaweicom

By Ana Hernandez,2014-06-15 23:37
11 views 0
WiMAX DL throughput (Mbps)<5<2.5<2.5<1WiMAX UL throughput (Mbps)<1.5<0.75<0.75<0.75WiMAX DL connect delay add-on...

     IEEE C802.16maint-08/035r3

    IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>

    声明:

    本文档由

    山东电建(s

    ddianjian)

    上传到豆

    丁网(docin

    .com),若

    有侵害您

    的权益,

    请发站内

    消息。

    Project

    Title Sleep Mode Timing Amendment Proposal Date 2008-01-22

    Submitted

    Voice: +86 755 28970192 Source(s) Jin Lei, Yang Yunsong, Wu Xuyong E-mail: Huawei Technologies jinlei60020191@huawei.com; Huawei Industry Base, Bantian, Shenzhen yunsongyang@huawei.com Shenzhen, Guangdong, P. R. China wuxuyong@huawei.com 518129

    Jonathan.Segev@comsysmobile.com Jonathan SegevYaron.Alpert yaron.alpert@comsysmobile.com Comsys Mobile

    Yigal@altair-semi.com Yigal BitranItay Lusky

    Itay@altair-semi.com Altair Semiconductor

    jgosteau@sequans.com Jérémy Gosteau, Jérome Bertorelle

    jerome@sequans.com SEQUANS Communications

    Re: IEEE 802.16 Working Group Letter Ballot Recirc #26a Abstract This contribution address the absence of compliance with the resource assignment in current

    sleep mode timing and provide the amendment proposal Purpose Consolidate the sleep mode timing to be compliant with the resource assignment

    This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It Notice 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

     1

     IEEE C802.16maint-08/035r3

    contained herein.

    The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, Release 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: Patent <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and

    <http://standards.ieee.org/guides/opman/sect6.html#6.3>. Policy Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and

    <http://standards.ieee.org/board/pat>.

     2

     IEEE C802.16maint-08/035r3

    Sleep Mode Timing Amendment Proposal

    Jin Lei, Yang Yunsong, Wu Xuyong, Huawei Technologies

    Jonathan Segev, Yaron Alpert Comsys Mobile

    Yigal Bitran, Itay Lusky, Altair Semiconductor

    Jérémy Gosteau, Jérome Bertorelle, SEQUANS Communications Motivation

    To use listening windows to carry data traffic during sleep mode

    Although we have TTWF flag in the standard, the timing of sleep mode in current standard fit for the cases to

    carry data traffic within listening windows without deactivating the PSC. This contribution is to show the

    problem of sleep mode timing in such cases, and provide solution by addressing an optional feature in the sleep

    mode as compensation.

    Example of such usage

    We have lots of possible reason to carry data traffic in listening window without stopping sleep mode, here is

    just an example:

    In many cases SS and MS implementation includes another Radio Access Technology (RAT) such as Bluetooth,

    WiFi and others.

    Due to the short proximity of 802.16 and the other RAT radios co-located, a method for co-existence of the

    802.16 and other RATs is required otherwise receiver blinding of either technologies is very likely, degrading

    the performance of all RATs involved.

    The natural method to perform this is through the usage of 802.16 sleep mechanism that enables a generic

    method (not dependent on other RATs involved) to negotiate agreed absences periods of MS from ASN.

    Due to the fact that the sleep mechanism was originally created to support power saving some modifications are

    required.

Current timing structure of sleep mode

    [1]In P802.16Rev2_D2, we have the sleep mode timing structure all based on timing unit of T, as the figure 1a f & figure.1b below:

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure1a. Sleep mode example in TDD system

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure1b. Sleep mode example in FDD system

     3

     IEEE C802.16maint-08/035r3

Current Map relevance for OFDMA PHY

    Allocation Start Time shall be subject to the following limitations:

     Minimum value: Allocation Start Time >= Tf

     Maximum value: Allocation Start Time < 2 × Tf In the UL subframe for which the MS fails to receive the relevant UL MAP, the MS shall not send data bursts.

     [1]While the Map relevance rules above stated in 6.3.7.5.4 Map relevance and synchronization provide us a

    resource allocation scheme based on the frame control as sketch below. The resource assigned by frame control

    in one frame is the DL subframe in this frame and the UL subframe in the next frame.

    Frame n+2Frame n-1Frame nFrame n+1

    DL-MAP n+2DL-MAP nDL-MAP n-1DL-MAP n+1UL-MAP n+2UL-MAP nUL-MAP n-1UL-MAP n+1

    Frame Control

    DL Subframe

    UL Subframe

    Figure2a. TDD Map relevance for OFDMA PHY

    Frame n+2Frame n-1Frame nFrame n+1

    DL-MAP n+2DL-MAP nDL-MAP n-1DL-MAP n+1UL-MAP n+2UL-MAP nUL-MAP n-1UL-MAP n+1

    Frame Control

    DL Subframe

    UL Subframe

    Figure2b. FDD Map relevance for OFDMA PHY

Timing problems in current sleep mode

    If we do not make use of the UL subframe in the listening windows for data traffic, there may be no problems,

    however, in some case (e.g. for WiMAX coexistence with other radio in one device, or for other stable low

    throughput usage with power saving requirement), the listening windows are to be used for data transceiving:

    Main Problems:

    1) For MS in activated PSC type I, when Traffic triggered wakening flag and TRF-IND_Required is set to 0,

    the MS can use the UL allocation to transmit any data traffic, while in the first frame in listening windows,

    there is no MAP received relevance to this UL subframe;

     4

     IEEE C802.16maint-08/035r3

2) For MS in activated PSC type II, during listening windows the MS may send or receive any MAC SDUs or

    their fragments, while there is no MAP relevance for the UL subframe of the first frame in listening

    windows.

    [*The data traffic in description above do not include CQICH, CQICH Allocation IE may still make use of the first frame

    in the listening window (see PICS item table A.300).]

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure3a. Main Problems for UL allocation in listening window TDD

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure3b. Main Problems for UL allocation in listening window FDD

Minor Problems:

    1) For MS in activated PSC type III, in the first frame after the sleep windows, the UL subframe have no UL

    allocation assignment; and in the first frame during the sleep windows, the UL subframe may get UL

    allocation from the frame before but not allow to transmit in sleep windows;

    2) For MS in activated PSC type II, in the first frame during the sleep windows, the UL subframe may get UL

    allocation from the last frame in listening windows but the MS is not allow to transmit;

    3) For MS in activated PSC type I, when Traffic triggered wakening flag and TRF-IND_Required is set to 0, in

    the first frame during the sleep windows, the UL subframe may get UL allocation from the frame before but

    not allow to transmit in sleep windows;

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure4a. Minor Problems for UL allocation in listening window TDD

     5

     IEEE C802.16maint-08/035r3

    Listen intervalSleep intervalListen intervalSleep interval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DL SubframeDLDLDLDLDLDLDLDLDL

    UL SubframeULULULULULULULULUL

    Figure4b. Minor Problems for UL allocation in listening window FDD

Impact of these problems:

    For those MSs which use the listening window for data transceiving:

    1) Longer Listening-Sleep Duty Cycle make QOS harder: For the MS in sleep mode which use listening

    windows for UL traffic, the listening windows can not be less than 2 frames, otherwise, no UL allocation can

    be made in such cases. Therefore to get a certain throughput in DL or get certain rate of power down time,

    we need double the size of listening-sleep cycle, negatively impact other QoS parameters and possibly

    making support of QOS parameter much harder.

    2) UL resource wastage and lower throughput: The first UL allocation in the listening windows can never be

    used to allocate UL traffic, which lower the available throughput capability upper limit, and limits the BS

    scheduling flexibility of UL resources and possibly leading to waste of UL BW;

    3) Risking unmatched frame control for sleep mode: The BS should be responsible not to allocate UL

    allocation in sleep windows, which is not automatically matched in the MAP relevance.

    For those MSs which use PSC for multi-RAT coexistence within the same device, there may be some additional

    shortage:

    4) Sleep mode parameters modifications: Since originally created for power saving the BS is misled to

    believe MS actual needs are power derived thus possibly modifying the sleep mode parameters requested by

    the MS (e.g. start frame) making it impossible for the MS to synchronize its 802.16 MAC activities with its

    other RAT.

Reference:

    [1]IEEE P80216Rev2/D2: Revision of IEEE Std 802.16-2004, under development by Maintenance Task Group). (2007-12-13)

    [2]Summary from the Ad Hoc CC: WiMAX-WiFi Coexistence Enhancement. (Martin.Lorenz 2007/11/26)

    [3] Proposal for WiMAX-Bluetooth and WiMAX-WiFi Coexistence. (Floyd Simpson, Henri Moelard, Gerrit Hiddink, Motorola, Inc. 2007/09/20)

    [4] WiWi MMSD Coexistence Requirement Proposal.(Xuyong Wu, Lei Jin, Shanna, Juejun Liu, Allan Xu Huawei, Tech. 2007-11-23)

Proposal

    For support of co-existence in OFDMA PHY, we propose the following:

     6

     IEEE C802.16maint-08/035r3

a) Enable (per MS request) the possibility of relevance between UL and DL sub-frames availability based on

    existing MAP relevance in all existing PSC support, instead of relevance based on frame number. During DL

    available interval, MS is required to decode the UL-MAP and transmit if required during the UL sub-frame in

    the according frame.

    b) For such PSC request (by indication in the MOB_SLP-REQ), the BS should either approve or reject it (if it

    cannot be supported) but not modify it.

Here is some example for such scheme

Example 1:

    1 DL & 1 UL subframe available in 2 frames duty cycle with shift of 1 frame.

    By requests using following definition in MOB_SLP-REQ for PSC and having the UL subframe allocation and

    behavior shifted by one frame:

    Start frame number = 100 (or any other as you like).

    Definition = True (1)

    Direction = DL (0b01)

    Number of CID = ALL DL CID. (0)

    TRF-IND_Required = 0

    TTWF=0

    initial-sleep window = 1

    listening-window = 1

    final-sleep window base = 1

    final-sleep window exponent = 0

    This setting implies that “Start frame number = 101” for the UL subframe (an offset of 1 frame compared to the DL subframe).

In such a way, see figure5, we vacate half of the time fully available for other radio simultaneous operation in

    adjacent channel.

    1) In other radio point of view, at least 1 frame duration out of 2 frames can be used for data

    transaction(Tx/Rx). If allowing parallel receiving operation, more time can be used for data reception (Rx).

    2) In WiMAX point of view, 1 DL and 1 UL sub-frame out of 2 frames duration can be effectively used for

    carrying data, this will enable much better QOS aspect than deploying PSC using 4 frames duty cycle.

    Listen sleep Listen sleep Listen sleep Listen sleep intervalintervalintervalintervalintervalintervalintervalintervalFrame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DLDL SubframeDLDLDLDLDLDLDLDL

    ULUL SubframeULULULULULULULUL

    WiFi/BT WiFi/BT WiFi/BT WiFi/BT Tx Avl Tx Avl Tx Avl Tx Avl Available time for WiFi/BT Rx Avl WiFi/BT Rx Avl WiFi/BT Rx Avl WiFi/BT Tx/RxWiFi/BT Rx Avl

     7

     IEEE C802.16maint-08/035r3

    Figure 5: PSC using listening/sleep window 1/1 for dual frame cycle sleep mode usage

Example 2:

    1 DL & 1 UL sub-frame available in 4 frames duty cycle with shift of 1 frame.

    By requests using following definition in MOB_SLP-REQ for the PSC and having the UL subframe allocation

    and behavior shifted by one frame:

    Start frame number = 100 (or any other as you like).

    Definition = True (1)

    Direction = DL (0b01)

    Number of CID = ALL DL CID. (0)

    TRF-IND_Required = 0

    TTWF=0

    initial-sleep window = 3

    listening-window = 1

    final-sleep window base = 3

    final-sleep window exponent = 1

    The implies that “Start frame number = 101for the UL subframe (an offset of 1 frame compared to the DL subframe).

In such a way, see figure6, we vacate 3/4 of the time fully available for other radio simultaneous operation in

    adjacent channel.

    1) In other radio point of view, at least 3 frame durations out of 4 (separated into 1+2) can be used for data

    transaction. Allowing parallel receiving operation, more time can be used for data receiving.

    2) In WiMAX point of view, 1 DL and 1 UL sub-frame out of 4 frames can be effectively used for carrying data,

    this will enable much rather low power consumption when deploying low QOS usage in WiMAX with other

    radio parallel operation in adjacent channel.

    Listen sleep Listen sleep intervalintervalintervalinterval

    Frame n-1Frame nFrame n+1Frame n+2Frame n+3Frame n+4Frame n+5Frame n+6Frame n+7

    DLDL SubframeDLDLDLDLDLDLDLDL

    ULUL SubframeULULULULULULULUL

    WiFi/BT WiFi/BT WiFi/BT Tx Avl WiFi/BT Tx Avl WiFi/BT Tx Avl Tx Avl Tx Avl Available time for WiFi/BT Rx Avl WiFi/BT Rx Avl WiFi/BT Rx Avl WiFi/BT Tx/Rx

    Figure 6: PSC using listening/sleep window 1/3

Specific Text Changes in IEEE802.16Rev2

    [To add an optional timing scheme for the sleep mode which is according to the MAP relevance between DL

    subframe and UL subframe. So the listening window in any PSC can support continuous transaction without

    deactivating the PSC. When set the listening window to 1, it will enhance coexistence performance for

    WiMAX MS using other radio in adjacent channel in same device at the same time.

     8

     IEEE C802.16maint-08/035r3

The authors want to highlight the fact that these proposed text changes come as complement to contribution

    C80216maint-08_008.doc related to another comment for LB26a. In order not to interfere with contribution

    C80216maint-08_008.doc, what follows takes 802.16Rev2D2 as baseline. The goal behind this new

    contribution is to provide alternative support for co-located coexistence cases that may not be covered by

    C80216maint-08_008.doc and that, according to the simulations provided further down this document, bring

    some performance enhancement.

    Note also that, to avoid mandating usage of the features described below, the Co-located-Coexistence-

    Enabled TLV in the MOB_SLP-REQ proposed in C80216maint-08_008.doc, is not used in the current

    proposal. Instead of that, the “Extended capability” TLV in SBC-REQ/RSP is used for the MS and BS to

    advertise their support of PSC performed according to the MAP relevance between DL and UL subframes.

    In addition to this signaling, the option that minimizes the standard changes is that when a PSC is defined

    both MS and BS shall shift the UL subframe by one frame such as to be compliant with the MAP relevance,

    as indicated in Figures 5 or 6. It can be done by using a bit definition (previously reserved) in MOB_SLP-

    REQ/RSP. This is not strictly related to co-located coexistence support (in such a way that it would imply

    strong relationship between PSC negotiation and co-location with another technology), but supporting the

    proposed changes would bring, as simulations show, specific performance advantage in the co-located

    coexistence scenarios]

    [Proposal: (optional feature to support allocating the listening/sleep interval according to MAP relevance):]

    [Modify description in 6.3.2.3.40 MOB_SLP-REQ (sleep request) message and 6.3.2.3.41 MOB_SLP-RSP

    (sleep response) message as indicate:]

     6.3.2.3.40 MOB_SLP-REQ (sleep request) message

    ……

    MAP relevance

    1 = The listening and sleep intervals follow the MAP relevance (e.g. the UL subframe is shifted compared to the DL

    subframe)

    0 = The listening and sleep intervals are aligned on the same frame number for the UL and the DL subframes

    ……

    Direction

    Defined the directions of the class’s CIDs

    0b00 = Unspecified. Each CID has its own direction assign in its connection creation. Can be DL, UL, or both

    0b01 = DL direction only. When MAP relevance is set to 1, this encoding indicates that only DL sub-frame is available for data

    traffic in listening interval.

    0b10 = UL direction only. When MAP relevance is set to 1, this encoding indicates that only UL sub-frame is available for data

    traffic in listening interval.

    0b11 = Reserved.

    ……

    Syntax Size (bit) Notes

    …… …… ……

    1 Traffic_triggered_wakening_flag

    1 MAP relevance When this bit is set to 1, the BS should either approve or

    reject this sleep request but not modify it.

    Reserved 21

     initial-sleep window

    …… …… ……

     9

     IEEE C802.16maint-08/035r3

6.3.2.3.41 MOB_SLP-RSP (sleep response) message

    ……

    MAP relevance

    1 = The listening and sleep intervals follow the MAP relevance (e.g. the UL subframe is shifted compared to the DL

    subframe)

    0 = The listening and sleep intervals are aligned on the same frame number for the UL and the DL sub-frames

    ……

    Direction

    Defined the directions of the class’s CIDs

    0b00 = Unspecified. Each CID has its own direction assign in its connection creation. Can be DL, UL, or both

    0b01 = DL direction only. When MAP relevance is set to 1, this encoding indicates that only DL sub-frame is available for data

    traffic in listening interval.

    0b10 = UL direction only. When MAP relevance is set to 1, this encoding indicates that only UL sub-frame is available for data

    traffic in listening interval.

    0b11 = Reserved.

    ……

    Syntax Size(bit) Notes

    …… …… ……

    1 Traffic_triggered_wakening_flag

    1 MAP relevance

    Reserved 1

    4 Number_of_CIDs

    …… …… ……

11.8.15 Extended capability

    The extended capability field specifies extended capability support for the specified features.

    Name Type Length Value Scope

    Extended capability 184 1 Bit 0: This bit describes the capability to support ARQ Map SBC-RSP

    Last Bit concept and the optimized Sequence Block as SBC-REQ defined in Table 167. The feature is enabled only in case

    both MS and BS support it.

    Bit 1: MOB-SLP_REQ/RSP with “MAP relevance” bit

    supported.

    Bits 12-7: Reserved, set to zero.

     1

    0

Report this document

For any questions or suggestions please email
cust-service@docsford.com