Project



|Project |IEEE 802.16 Broadband Wireless Access Working Group |

|Title |Clarification of retransmission of DSC-ACK based on T10 timer in response to DSC-RSP |

|Date Submitted |2008-05-14 |

|Source(s) |Yeongmoon Son, |Voice: +82-31-279-5845 |

| |Geunhwi Lim, |E-mail: ym1004.son @ |

| |Brian Shim | |

| |Samsung Electronics | |

| | | |

| |Giovanni Maggi | |

| |Nokia Siemens Networks | |

| | | |

| |Rucy Pollak |E-mail : giovanni.maggi.ext@ |

| |Altair Semiconductor | |

| | | |

| | | |

| | |E-mail: lucy.pollak@altair- |

| | | |

| | | |

| | |* |

|Re: |LB26c |

|Abstract |This contribution clarifies DSC operation based on T10 timer |

|Purpose |Accept the proposed specification changes on IEEE P802.16Rev2/D4. |

|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: |

| | and . |

| |Further information is located at and . |

Clarification of retransmission of DSC-ACK based on T10 timer in response to DSC-RSP

Yeongmoon Son, Geunhwi Lim, Brian Shim

Samsung Electronics

Giovanni Maggi

Nokia Siemens Networks

Rucy Pollak

Altair Semiconductor

Problem description

As you can know in the figure 130 on page 397, if an MS or a BS receives a DSC-RSP message from a counter after transmission of DSC-REQ message, it shall perform the following operations in sequence

• It shall update the service flow by using new SF parameters (i.e. ‘DSC successful’ in the state diagram).

• It shall send DSC-ACK message to remote side.

• It shall start T10 timer.

• It shall save DSC-ACK.

• Afterward, it transits to DSC-Local Holding Down state.

If we can guess from the figure 131 on page 398, when the MS or the BS internally finishes changing the service flow, it stops T10 timer and enters ‘DSC-Local End’ state. It means that the MS or the BS terminates DSC transaction and it removes ‘Saved DSC-ACK’ as well as T10 timer. Nevertheless, the figure 131 shows when the MS or the BS receives the DSC-RSP message again from remote side due to no reception of DSC-ACK message in the remote side, it still sends DSC-ACK message by referring to the ghost ‘Saved DSC-ACK’ which has been already deleted. Therefore, we need to clarify retransmission of DSC-ACK based on T10 timer in response to a retransmitted DSC-RSP message.

T10 timer is time required for a whole DSx transaction as shown in the following table. Therefore, information of the service flow should be kept during T10 timer for DSx transaction in order to prepare the retransmission of DSx-RSP message in future.

[pic]

Even though a service flow is changed due to DSC-RSP message, an MS or a BS should keep at least ‘saved DSC-ACK’ in order for retransmission in future until T10 timer expires.

Proposed Changes

[Modify the figure 131 on page 398, as follows]

[pic]

[pic]

In addition to the proposal in C802.16maint-08/197, NSN suggested providing a guideline (i.e. minimum value) for T10 timer. If T10 timer is too short, MS or BS may not respond to the counter part with saved DSD-RSP message because the service flow has been deleted due to expiration of T10 timer. Therefore, we propose the minimum value for the T10 timer as follows

[Modify the table 544 on page 1100, as follows]

|Table 544—Parameters and constants (continued) |

|System |Name |Time reference |Minimum |Default |Maximum |

| | | |value |value |value |

|SS, BS |T10 |Wait for Transaction End |DSx Request Retries * Maximum value of T7, in |— |3 s |

| | |timeout |case of sending DSx-RSP | | |

| | | | | | |

| | | |DSx Response Retries * Maximum value of T8, in | | |

| | | |case of sending DSx-ACK | | |

| | | | | | |

| | | |—, in other cases | | |

In addition to the proposal in C802.16maint-08/197, Altair suggested fixing another figure (i.e. fig. 117) for a complete modification related to T10 timer.

[Modify the figure 117 on page 379, as follows]

[pic]

References

[IEEE802.16-Rev2/D4] IEEE Computer Society and IEEE Microwave Theory and Techniques Society, “DRAFT Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Broadband Wireless Access Systems”, P802.16Rev2/D4 (April 2008). Revision of IEEE Std 802.16-2004 and consolidates material from IEEE Std 802.16e-2005, IEEE Std 802.16-2004/Cor1-2005, IEEE Std 802.16f-2005 and IEEE Std802.16g-2007.

-----------------------

1

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download