IEEE C802.16m-09/1955
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Seamless HO Data Packet Retention
Date
Submitted
2009-08-28
Source(s)
Stavros Tzavidas
stavros.tzavidas@motorola.com
Motorola
Re:
LB30
Abstract
This contribution
Purpose
For review and adoption
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>.
Seamless HO Data Packet Retention
Stavros Tzavidas
Motorola
Introduction
In section 15.2.5.10.5.2 “Network Re-entry Procedure” of the current specification we have copied the seamless
handover procedures from section 6.3.21.2.11 “Seamless HO” in the existing spec.
There is one more issue that needs to be addressed. Specifically, when data packets are exchanged before the
RNG-REQ/RSP transaction takes place, the text correctly specifies the behavior that the receiver should follow
but it does not specify an important action that the sender should take.
More specifically, when data packets are exchanged before the RNG-REQ/RSP transaction takes place the
sender (AMS or ABS) cannot be certain that the other side is a legitimate 802.16e or 802.16m entity. For this
reason, any data packets transmitted to the other side should be stored by the sender until the identity of the
other side has been verified. The identity of the other side can be verified either by receiving (and successfully
decoding) an encrypted data packet or by receiving RNG-RSP that is signed with a valid CMAC tupple.
1
IEEE C802.16m-09/1955
This should be done to simply protect against the case that the other side proves to be NOT legitimate. In this
case the sender will have to re-transmit the packets to the legitimate other side when it establishes a connection
to it. For example, when the sender is the AMS, any UL data sent to an ABS whose identity fails to eventually
be verified will have to be retransmitted to another ABS. If the sender is the ABS then any DL data sent to an
AMS that eventually fails to be authenticated (or never shows up) will have to be retransmitted when the valid
AMS shows up.
2
IEEE C802.16m-09/1955
Text Proposal
In paragraph 15.2.5.10.5.2 “Network Re-entry Procedure”, insert new text after the first
paragraph following figure 407, as indicated below:
----------------------------------------------Start of the text proposal -----------------------------------------------------15.2.5.10.5.2 Network Re-entry Procedure
…
During network re-entry, the AMS is required to initiate the AAI_RNG-REQ/RSP message transaction by
sending an AAI_RNG-REQ message before the deadline specified by the "Ranging Initiation Deadline"
attribute included in AAI_HO-CMD message during handover preparation. The time is measured from the time
the AAI_HO-CMD message is transmitted. If the target ABS does not receive an AAI_RNG-REQ message
from the AMS within the deadline defined by the "HO Ranging Initiation Deadline" attribute, the target ABS
considers the HO as failed and stops allocating bandwidth to the AMS. It is recommended that the ABS allows
time equal to T3 timer (Table 553) before it reuses the STID that was allocated to the AMS. The AMS considers
the HO as failed if it does not transmit AAI_RNG-REQ message before the deadline. If the AMS transmits
3
IEEE C802.16m-09/1955
AAI_RNG-REQ within the deadline, it may still consider the HO as failed if it does not receive an AAI_RNGRSP within T3 after the last transmission or retransmission of AAI_RNG-REQ that was performed within the
deadline. When the AMS considers the HO as failed, it invalidates the pre-allocated STID. In all cases, even
when the AAI_RNG-REQ/RSP message transaction is initiated before the deadline, the HO is considered failed
if the AAI_RNG-REQ/RSP procedure fails.
If data packets are exchanged between AMS and target ABS before the AAI_RNG-REQ/RSP transaction is
completed, the recipient (AMS or target ABS) should store the received data packets and not release them to the
upper layers until the sender is authenticated. If the data packets belong to a service flow associated with an SA
that supports data authentication (as indicated by the data authentication algorithm identifier in the
cryptographic suite of the SA) the receiver can authenticate the sender by verifying that the ciphertext
authentication code included in each data packet was produced with the TEK associated with this SA. If the data
packets belong to a service flow associated with an SA that does not support data authentication the receiver can
authenticate the sender when the AAI_RNG-REQ/RSP transaction completes successfully. In all cases, if the
sender is authenticated, the decrypted data packets are released to the upper layer in the recipient, and if the
sender is not authenticated the data packets are discarded.
If data packets are exchanged between AMS and target ABS before the AAI_RNG-REQ/RSP transaction
is completed, the sender (AMS or target ABS) should store the sent data packets and not discard them
before the receiver is authenticated. If a service flow exists in the reverse direction and that service flow is
associated with an SA that supports data authentication (as indicated by the data authentication
algorithm identifier in the cryptographic suite of the SA), the sender can authenticate the other side (the
receiver) by verifying that a data packet received by the other side contains a ciphertext authentication
code that was produced with the TEK associated with this SA. Alternatively, the sender can authenticate
the other side (the receiver) when the AAI_RNG-REQ/RSP transaction completes successfully. In all
cases, if the sender fails to authenticate the other side, then it shall consider all sent packets as never
transmitted and retransmit them to a new ABS or AMS when a new connection is established.
The AAI_RNG-REQ/RSP transaction for HO is shown in Figure XX2. The AMS shall initiate the
AAI_RNG_REQ/RSP transaction by transmitting an AAI_RNG-REQ message to the target ABS before the
deadline specified by the "Ranging Initiation Deadline" attribute included in AAI_HO-CMD message during
handover preparation. The AAI_RNG-REQ message shall include STID, CMAC_KEY_COUNT and a CMAC
tuple, but not include AMS MAC address or previous serving ABSID. When ABS receives the AAI_RNG-REQ
message, the ABS shall respond to the AAI_RNG-REQ message by transmitting encrypted AAI_RNG-RSP
message. The AAI_RNG-RSP message shall be addressed to the AMS's STID.
-------------------------------------------------- End of the text proposal --------------------------------------------------
4