IEEE C80216maint-08/223r2
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Solution for handling the loss of response messages from BS during network entry
Date
Submitted
2008-05-12
Source(s)
Li Wang
Voice:
E-mail: wangli@zte.com.cn
Hongyun Qu
*<http://standards.ieee.org/faqs/affiliationFAQ.html>
ZTE Corporation
Re:
IEEE 802.16Rev2/D4, Letter Ballot 26c. Technical Comments
Abstract
This contribution proposed a solution for handling the loss of response messages from BS during
network entry.
Purpose
Accept the proposed specification changes into IEEE 802.16Rev2.
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>.
Solution for handling the loss of response messages from BS during network entry
Li Wang, Hongyun Qu
ZTE Corporation
Problem description
In the current standard IEEE 802.16 Rev2 D4, for the OFDMA PHY, after completion of contentionbased initial ranging during network entry, BS shall send a CDMA allocation IE to MS, and then MS
shall send a RNG-REQ message to BS. When BS receives the RNG-REQ message, it shall
respond with a RNG-RSP (with matching MAC address) message. If RNG-RSP (with matching
MAC address) message is lost, T3 of MS will expire, and MS shall perform contention-based initial
ranging again.
Collisions may occur during contention-based initial ranging. So it will take a long time to recover
from the loss of RNG-RSP (with matching MAC address), and it wastes air resources to repeat
contention-based initial ranging and RNG-REQ retransmission.
1
IEEE C80216maint-08/223r2
Actually, it’s not necessary to do contention-based initial ranging and RNG-REQ retransmission when
RNG-RSP (with matching MAC address) message is lost. We should ONLY do RNG-RSP (with
matching MAC address) message retransmission by BS.
The similar problem exists in the procedure of negotiating basic capabilities during network entry in
the current standard. If SBC-RSP message is lost, T18 of MS will expire and MS shall send a SBCREQ message to BS again. In fact, it’s not necessary to do SBC-REQ retransmission when SBCRSP message is lost. We should ONLY do SBC-RSP retransmission by BS.
Similiarly in the register procedure, it’s not necessary to do REG-REQ retransmission by MS when
REG-RSP message is lost. We should ONLY do REG-RSP retransmission by BS.
In handover case, if RNG-RSP message is lost when MS is performing network reentry to target BS,
it will incur a longer interruption and data loss. So it’s required to do RNG-RSP retransmission by BS.
Proposed solutions
We propose that it shall perform the following operations in sequence during network entry:

MS sends a REQm message to BS;

BS responds with a RSPm message to MS, and sets a timer Tn for waiting for the next message
REQm+1 from MS;

If BS receives REQm+1 from MS before Tn expires, BS shall stop the Tn, and respond with RSPm+1
message and set a timer Tn+1;

If Tn expires and the RSPm message retries are not exhausted, BS shall resend RSP m message
to MS and set Tn again;

If Tn expires and the RSPm message retries are exhausted, BS shall not resend RSP m message
to MS and shall send RNG-RSP(abort) message to MS.
As we know, when MS sends a request message to BS, it shall wait for a response message from
BS. The timer value of MS for waiting for a response message has to be long because BS needs to
communicate with core network to exchange security information or registration information, etc. and
has to handle a lot of MS simultaneously. The process time of BS is long and not predictable. On
the other hand, MS just needs to read configuration table in itself and perform simple operations after
it receives a response message from BS, and then it could perform the next step to send the next
request message to BS. So the timer value of BS for waiting for the next request message from MS
is much shorter within just several frames. The proposed timer T n is predictable and short in different
phases of network entry including ranging, negotiating basic capabilities and registration. Therefore,
with the use of Tn of BS and RSPm message retransmission, it could recover network entry process
quickly from losing the RSPm message of BS.
For performing ranging phase:
When BS receives a RNG-REQ message from MS, it shall respond with a RNG-RSP(with matching
MAC address) message and set timer T60 for waiting for a SBC-REQ message from MS. BS should
stop T60 when it receives a SBC-REQ from MS. If T60 expires and RNG-RSP retries are not
exhausted, BS shall send a RNG-RSP(with matching MAC address) message to MS and set timer
T60 again. If T60 expires and RNG-RSP retries are exhausted, BS shall not resend a RNG-RSP(with
matching MAC address) message, and shall send a RNG-RSP(abort) message to MS.
2
IEEE C80216maint-08/223r2
For negotiating basic capabilities phase:
When BS receives a SBC-REQ message from MS, it shall respond with a SBC-RSP message and
set timer T61 for waiting for a REG-REQ(authentication not supported) or an authenticating message
from MS. BS shall stop T61 when it receives a REG-REQ or an authenticating message from MS. If
T61 expires and SBC-RSP retries are not exhausted, BS shall send a SBC-RSP message to MS and
set T61 again. If T61 expires and SBC-RSP retries are exhausted, BS shall not resend a SBC-RSP
message, and shall send a RNG-RSP(abort) message to MS.
For performing register phase:
When BS receives a REG-REQ message from MS, it shall respond with a REG-RSP message and
set timer T62 for waiting for a TFTP-CPLT or establish connection message from MS. BS shall stop
T62 when it receives a TFTP-CPLT or establish connection message from MS. If T62 expires and
REG-RSP retries are not exhausted, BS shall send a REG-RSP message to MS and set T62 again.
If T62 expires and REG-RSP retries are exhausted, BS shall not resend a REG-RSP message, and
shall send a RNG-RSP(abort) message to MS.
For MS reentry to target BS at handover:
When target BS receives a RNG-REQ message from MS, it shall respond with a RNG-RSP(with
matching MAC address) message and set timer T60 for waiting for a next message from MS. BS
shall stop T60 when it receives a next message from MS. If T60 expires and RNG-RSP retries are
not exhausted, BS shall send a RNG-RSP(with matching MAC address) message to MS and set
timer T60 again. If T60 expires and RNG-RSP retries are exhausted, BS shall not resend a RNGRSP(with matching MAC address) message.
Proposed content changed in standard
Replace the figure 85 in section 6.3.9 of P802.16 Rev2 D4 with the following figure:
3
IEEE C80216maint-08/223r2
Got CDMA initial ranging code/
Handle CDMA initial ranging code
( send RNG -R SP ( continue ))
*Wait for
CDMA initial
Ranging code
*Got CDMA Initial ranging code/
Handle CDMA Initial ranging code
( send RSP ( abort ))
Got CDMA initial ranging code /
Handle CDMA initial ranging code
( send RNG - RSP ( success ) or
CDMA Allocation IE)
*SS Ranging Response
Processing time passed
Wait for
RNG - REQ
Got RNG-REQ/
Handle RNG-REQ
(send RNG-RSP(success))
Got RNG - REQ / Handle
RNG - REQ retransmission
( send RNG - RSP ( success ))
Wait for
SBC - REQ
Auth . Supported
Got SBC - REQ
Handle SBC - REQ
Auth. Not supported
Got SBC-REQ
Handle SBC-REQ
Got SBC - REQ /
Handle SBC - REQ
retransmission
(T9 expires)Send RNG-RSP(Abort)
or
Got RNG-REQ/Handle RNG-REQ
retransmission Send RNG-RSP(Abort)
T60 expires and
have more retries/
Send RNG-RSP(success)
END
(T17 expires or auth. Fail)
Send RNG-RSP(Abort)
SS
Authentication
and Key
exchange
T 61 expires and have
more retries / Send
SBC - RSP
T17 expires/
Send RNG-RSP(Abort)
Or RES-CMD
Authenticated
from PKM
Auth . not supported
Got SBC - REQ /
Handle SBC - REQ
retransmission
Wait for
REG - REQ
Auth. Not supported
T61 expires and have more retries
/Send SBC-RSP
Got REG - REQ /
Handle REG - REQ
Got REG - REQ /
Handle REG - REQ
retransmission
Establish
connections /
TFTP
T 62 expires and have
more retries / Send
REG - RSP
T13 expires/
Send RNG-RSP(Abort)
Or DREG-CMD
Or RES-CMD
Replace the figure 80 in section 6.3.9 of P802.16 Rev2 D4 with the following figure:
4
IEEE C80216maint-08/223r2
Wait for
SBC-REQ
SBC-REQ
T60
expired
Stop T9 and
T60
RNG-RSP retries
exhausted
Determine and
enable ss
capabilities
Y
N
SBC-RSP
Resend
RNG-RSP
start/reset T17
Start T60
Authorization
policy support?
SS authorization
and key exchange
Y
N
Wait for
REG-REQ
Wait for
SBC-REQ
End
Replace the figure 84 in section 6.3.9 of P802.16 Rev2 D4 with the following figure:
5
IEEE C80216maint-08/223r2
Wait for
REG-REQ
REG-REQ
T61 expired
Stop T17 and T61
SBC-RSP retries
exhaused？
Authorization
Policy
support?
N
Y
N
Y
Resend
SBC-RSP
Caculate
CMAC/HMAC over
REG-REQ
Start T61
REG-RSP with
response = 1(message
auth. fail)
N
HMAC/
CMAC Valid？
Y
Wait for
REG-REQ
Set ss capabilities
supported in REGRSP
N
Managed SS？
Y
REG-RSP with
response =0(OK)
REG-RSP with
response =0(OK)
Start T13 and T62
Start T62
Establish
provisioned
connections
Wait for
TFTP-CPLT
Wait for
REG-REQ
Add the following definition at the end of table 544 in section 10 of P802.16 Rev2 D4:
6
End
IEEE C80216maint-08/223r2
System
Name
Time reference
BS
T60
BS
T61
BS
T62
BS
RNG-RSP
Retries
SBC-RSP
Retries
REG-RSP
Retries
SBC-REQ reception timeout
following the transmission
of a RNG-RSP
REG-REQ reception
timeout following the
transmission of a SBC-RSP
Establish-connections REQ
reception timeout following
the transmission of a REGRSP
Number of retries on RNGRSP
Number of retries on SBCRSP
Number of retries on REGRSP
BS
BS
Minimum
Value
Default
Value
Maximum
Value
10ms
20ms
10ms
20ms
10ms
20ms
3
3
16
3
3
16
3
3
16
References
IEEE Std 802.16Rev2-D4 (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), “IEEE Standard for Local and Metropolitan Area
Networks - Part 16: Air Interface for Broadband Wireless Access Systems,” April,
2008
7