Post on 27-Mar-2015
www.huawei.com
Security Level:
Introduction to WiMAX Handovers
Issue 1.0
March 21, 2008
WiMAX Network Planning Dept.
Page 2
Course Objectives
Understand the types and basic concepts of WiMAX
handovers
Understand WiMAX handover scenarios and procedures
After studying the course, you should be able to
Page 3
ContentsContents
Chapter 1 Overview of WiMAX handovers
Chapter 2 WiMAX handover procedures
Page 4
Types of WiMAX 16e Handovers
To obtain better signal quality, a moving MS needs to switch between BTSs. In a WiMAX system, handovers are classified into
three types: hard handovers (HHO), macro diversity handovers (MDHO), and fast base station switching (FBSS). The
MDHO is similar to the soft handover. FBSS is a type of hard handovers, except that FBSS is completed within a shorter time.
The three types of handovers have the following features:
1. HHO causes short-time service interruption. The MS cannot simultaneously communicate with multiple BSs.
2. The most distinctive feature of MDHO is that the MS can simultaneously communicate with multiple BSs and thus services
are not interrupted in the handover process. Many resources, however, are occupied in MDHO.
3. In FBSS, the MS communicates with the anchor BS only. Therefore, services are interrupted in the handover process but the
handover is fast completed.
Handovers are classified by handover scenarios into intra-BTS handovers, inter-BTS handovers, intra-GW handovers, and inter-
GW handovers.
Currently, version V21 provides HHO only and does not support MDHO and FBSS. Therefore, this document focuses on HHO.
Page 5
Handover Scenarios
BS1
BS2 BS
3
BS4
BS5 BS
6
GW
MS
I-MS BS(R1)
I-BB(R6)I-BB(R6)
BS1BS
2 BS3
BS4
BS5 BS
6
GW
MS
I-MS BS(R1)
CSN
I-BSSN(R4)
I-CN(R3) I-CN(R3)
Intra GW
Intra GW
Inter GW
I-BB(R6) I-BB(R6)
MSMoving Moving
Gate Way
Page 6
ContentsContents
Chapter 1 Overview of WiMAX handovers
Chapter 2 WiMAX handover procedures
Page 7
Handover Flow Chart
MOB_MSHO_REQ MOB_MSHO_REQ
R6M_CCM_HO_REQ HO Request
HO Request R6M_CCM_HO_REQ
R6M_CCM_HO_RSPHO ResponseHO ResponseR6M_CCM_HO_RSP
The GW determines whether to agree to handover according to the subscription information, filters the BSs according to the load condition, and then distributes the HO Request message.
The GW summarizes HO Response messages to form the recommended list.
MOB_BSHO_RSPMOB_BSHO_RSP
MOB_HO_IND MOB_HO_IND R6M_CCM_HO_CNF HO Confirm HO Confirm R6M_CCM_HO_CFM
CCM_LCM_ME_HO_STOP_SCH_IND
LCM_CCM_ME_HO_STOP_SCH_RSP
MS reentry
Serving BS Target BS
Start the resource hold timer and release the resource when the timer expires.
R6M_CCM_HO_CPLHO Complete
HO CompleteR6M_CCM_HO_CPL
Release
CID scheduling except for BC is stopped, but the mechanism needs to guarantee that Grant No Signal does not cause the counter to overflow.
MS ME SIG R6M GW R6M ME SIG RRM
RRM_CCM_AllocHoId
The target BS determines whether to permit handover according to the information of the MS and returns information indicating whether to permit handover. If the BS permits handover, the MS sets up the CB, saves the information, and returns a message carrying parameters such as HOID and PreambleIndex to the target BS.
(Release) (Release)
The MOB_MSHO RSP message carries an option indicating whether to retain information for the MS. Temporarily the SIG
determines whether to reserve resources for the MS.
RRM
RRM_JudgeBsTable
Currently the serving BS does not filter the list selected by the MS but the BsIndex of the BS list in the message needs to be converted into BsId.
R6M_CCM_HO_ACK HO ACK HO ACK R6M_CCM_HO_ACK
The gateway calculates the AK Context and sends the CMAC_KEY_COUNT maintained by the Authenticator to the BS.
opt CCM_LCM_ME_SCN_CFG_STOP_IND
RRM_CCM_JudgeSfLevelRRM_CCM_HoRspPara
The message carries the latest CMAC_KEY_COUNT and is sent to the GW.
MS context deletion procedure
Page 8
Overview of Handovers
As shown in the handover flow chart, the handover procedure consists of three phases: scanning,
handover preparation, and handover implementation.
The MS-initiated handover procedure consists of three phases: scanning, handover preparation,
and handover implementation.
In the scanning phase, the signal quality of the neighboring BSs is scanned to provide a criterion for
handover decision-making. In the handover preparation phase, the MS sends a handover request
and the appropriate target BS is ultimately determined after negotiation with the target BS and the
calculation by the MS. In the handover implementation phase, the target BS obtains all the context
information of the MS, the MS reenters the network through the target BS, and other operations are
performed till the target BS receives the BR from the MS.
Page 9
Handover Procedure — Scanning
The Serving BS sends MOB_NBR-ADV.
The MS scans the neighboring BSs.
Page 10
Scanning Trigger
According to the protocols, the MS resolves the Trigger field in the DCD or NBR-ADV
message and then triggers the scanning and handover according to the Trigger field. In
version V2.1, all handover-related algorithms are implemented by the MS.
Take GCT terminals that are well commercialized as an example. Although GCT terminals
support triggering a handover according to message indication, the BS of version v2.1 does
not support the Trigger. Therefore, a handover is triggered and implemented by setting an
absolute scanning threshold and a relative handover threshold in the MS.
Page 11
MOB_NBR-ADV
The MOB_NBR-ADV message is used in a handover to notify the neighboring cell information and neighboring cell channel parameters of the serving BS to the MS, so that the MS can timely originate a scanning request, a handover request, or other requests.
The serving BS sends the MOB_NBR-ADV message according to the broadcast CID or the primary management CID.
The serving BS obtains the neighboring BS information from the GW over the R6 interface.
The MOB_NBR-ADV message may also include handover trigger information indicating when the MS should initiate a scanning request, a scanning result report, a handover request, and other relevant actions.
The MOB_NBR-ADV message may include the following key
information on each neighboring cell: PHY Profile, FA Index,
BS-ERIP, Neighbor BSID, and Preamble Index. Such information helps the MS better search neighboring BSs and register itself to the network through the target neighboring BS.
Page 12
MOB_NBR-ADV Message
Page 13
Functions of the MOB_NBR-ADV Message
To facilitate the synchronization between the MS and a neighboring BS, the
MS no longer needs to monitor broadcast messages such as DCD/UCD from
the neighbor BS, except when the MS is powered on. To compress the
neighbor BSID in the MOB_SCN-REQ message and the MOB_MSHO-REQ
message, the serving BS can create a mapping between the neighboring BS’
MAC address and the neighboring BS index in the MOB_NBR-ADV message.
Page 14
Types of Scanning
Scanning at power-on (not the scanning before the handover)
The MS finds the BS of its own network service provider (NSP), and registers itself in the network. If the
registration fails, the MS continues to synchronize with other BSs till finding the BS of its own NSP and
successfully registering itself in the network.
Scanning in special modes
The scanning of the MS in idle or sleep mode is similar to the scanning at power-on of the MS.
Triggered scanning
BS-initiated
MS-initiated
Page 15
MOB_SCN-REQ Message
Page 16
Key Parameters of the MOB_SCN-REQ Message
Scan duration
The serving BS allocates a time interval to the MS. At this time interval the MS searches neighboring BSs and
finds an appropriate neighboring BS as the target BS. This time interval is called the scan duration.
Interleaving interval
This parameter identifies the interleaving interval between normal operations.
Scan iteration
The MS can request multiple scanning intervals at a time to scan multiple neighboring BSs.
N Recommended_BS_Index
This parameter identifies the neighboring BS list in the NBR-ADV message.
N Recommended_BS_Full
This parameter identifies the BSs not included in the NBR-ADV message. Such BSs are identified by BSIDs.
Scanning type
This parameter identifies whether to associate with a neighboring BS and the associated level.
Page 17
MOB_SCN-RSPWhen the scan duration is set to 0, the BS denies the MS’ request for starting the scanning process.
Page 18
MOB_SCN-RSP
Start frame
The scanning is started N frames after the receipt of the xxx message.
Interleaving interval
This parameter identifies the interleaving interval between normal operations.
Scan iteration
The MS can request multiple scanning intervals at a time to scan multiple neighboring BSs
Page 19
Scanning Process Initiating a scanning request
The MS obtains a Scan Duration with the MOB_SCN_REQ message to initiate a scanning request, and then waits for an
MOB_SCN_RSP message from the serving BS. According to the current implementation, the serving BS may also initiate an
MOB_SCN_RSP message to request the MS to perform scanning.
In the MOB_SCN_RSP message returned by the BS, the Scan Duration must be greater than or equal to the Scan Duration
requested by the MS (the maximum value of Scan Duration is determined by Max_Dir_Scan_Time). Otherwise, the BS returns a
Scan Duration with value 0 to deny the MS’ request.
Scanning in progress
Starting from the Start Frame specified by the BS, the MS attempts to synchronize with each neighboring BS and evaluate
the physical channel quality of the neighboring BSs.
Ending the scanning
The MS can send an MAC PDU in the scan duration to end the scanning process.
The MS can send an MOB_SCN_REQ message at the interleaving interval to end the scanning process.
The BS can send an MOB_SCN_RSP message at the interleaving interval to end the scanning process.
Scanning report (MOB_SCN-REP)
The MS can report the scanning results in the MOB_SCN_REP message to the serving BS (this is not yet implemented).
Page 20
Functions of Scanning
The MS sends a scanning request to the serving BS.
The scanning process does not involve the scanning of the serving BS’ downlink channel
quality.
In general, the MS scans the BSs in the neighboring BS list in the NBR-ADV broadcast
message. The MS can also send a request to scan BSs not included in the NBR-ADV broadcast
message. Such BSs are identified by BSIDs.
The scanning process does not affect the existing traffic between the MS and the serving BS.
According to the protocols, a BS is allowed to preset a certain buffer space to store downlink service
data when an MS performs scanning.
Page 21
MS Scanning Process 1
MS S BS BS1 BS 2
MS-initiated
Page 22
MS Scanning Process 2
BS-initiated
Page 23
Handover Procedure — Handover Preparation
A process in which the GW performs capability negotiation with the potential target BSs
Preparation for the MS-initiated handover
Preparation for the serving BS-initiated handover (not realized and thus not discussed)
Preparation for the serving GW-initiated handover (not realized and thus not discussed)
Page 24
HO Triggering Procedure
After scanning all neighboring BSs, the MS determines whether to initiate the handover procedure according
to the handover threshold. If the handover is necessary, the MS triggers the handover. If the handover is
unnecessary, the MS returns to the normal state.
The precondition for an MS-initiated handover is that the MS has performed scanning at least once . If the
MS has never performed scanning (except the scanning at power-on), the MS cannot trigger the handover
procedure, because the MS does not know the status of the neighboring BSs but knows only the status of
the serving BS. If the channel quality of the serving BS is good, a handover is not required . Otherwise, a
scanning request is sent and then a handover is performed.
Three HO trigger procedures
MS-initiated HO
The downlink quality deteriorates to a value lower than the HO threshold.
Serving BS-initiated HO (not realized and thus not further discussed)
The uplink quality deteriorates to a value lower than the HO threshold.
Serving GW-initiated HO (not realized and thus not further discussed)
To balance the load, resource maintenance is provided by the resource management function entity of the GW.
Page 25
Preparation for the MS-Initiated Handover
MSServingBS
Serving/TargetGW
TargetBS1
TargetBS 2...x
MOB_BSHO_RSP
MOB_HO_Indication
HO-Request
HO-Request
HO--Response
(MS ID, connection params, capabilities,required BW and QoS)
A
(Result f lag, MS ID, Serv ice lev el prediction, HO optimization f lag, HO_authorization_policy _support, HO ID, HO Action time)
Make a decision
HO-Response(MS ID, Target BS List [Serv ice lev el prediction, HO optimization f lag, HO_authorization_policy _support, HO ID, HO Action time ])
B
MOB_MSHO-REQ
(Recommended BS=BS#2serv ice lev el prediction=2)
HO_IND_ty pe 0b00:serv ing BS release
(MS ID, capabilities,Target BS list[Signal Quality])
Page 26
Preparation for the MS-Initiated HO After receiving the MSHO-REQ message, the serving BS forwards the MSHO-REQ message to the GW. The GW simply
makes a decision based on two criteria:
1) The neighboring BS list in the message is sorted.
2) The GW knows the load information about the neighboring BSs.
The GW determines to send the MSHO-REQ message to the neighboring BSs so as to prepare for the handover. In addition, the GW needs to collect the HO-Response messages from multiple neighboring BSs and send them to the serving BS in the handover preparation phase.
TBS admission criteria (V21)
Whether the number of MSs accessing the current carrier reaches the maximum number (500);
Whether the total number of MSs accessing the BS reaches the maximum number (1500);
Maximum number of connections (10k) set up in each sector;
Whether the total number of connections set up in the BS reaches the maximum number (30k);
Whether the CPU is overloaded;
The remaining bandwidth of existing UL and DL channels is sufficient for the new MS to occupy the air interface bandwidth (the access of the MS is admitted only when both the remaining uplink bandwidth and the remaining downlink bandwidth meet the requirements).
Page 27
HO Response
IE/Group Name Type Presence Length Semantics Description
BS ID Binary M 6
MS ID Binary M 6 MAC address of the MS
HO Type Binary M 1 Currently only HHO is realized
Number of Candidate Neighbor BS Binary M 1 Number of candidate BSs
Only one candidate BS exists from the Target BS to the GW
Multiple candidate BSs may exist from the GW to the serving BS
For (j =0; j < Number of Candidate Neighbor BS;j++)
{
Candidate Neighbor BSID Binary M 6 Candidate BS ID
Preamble Index / Sub-channel Index Binary M 1 Preamble Index / Sub-channel Index code
Info_Support_HO_Optimization Binary M 1 Handover optimization
HO_ID Binary O 1 Handover ID
Service Level Prediction Binary M 1 0: No service possible for this MS
1: Some service is available for one or several service flows authorized for the
MS.
2: For each authorized service flow, a MAC connection can be established with
QoS specified by the AuthorizedQoSParamSet.
3: No service level prediction available.
Page 28
IE/Group Name Type Presence Length Semantics Description
HO_authorizaiton_policy_support Binary M 1 Bit #0: RSA authorization
Bit #1: EAP authorization
Bit #2: Authenticated-EAP authorization
Bit #3: HMAC supported
Bit #4: CMAC supported
Bit #5: 64-bit Short-HMAC
Bit #6: 80-bit Short-HMAC
Bit #7: 96-bit Short-HMAC
HO Action Time Binary O 1 Time allocated by the BS for Fast Ranging IE during the
handover
Result Code Binary M 2 0: Handover is allowed
Others: Handover denial cause code
}
Resource Retain Type O 1 0: Release connection information
1: Retain connection information
Resource Retain Time O 1
HO Response
At the end of the handover preparation phase, the MS sends an HO indication to the BS to indicate whether the MS agrees to the handover. If the
MS agrees to the handover, the HO indicator is set to Release, and then the handover implementation phase continues.
Page 29
Handover Procedure — Handover Implementation
After receiving an MOB_HO-IND message from an MS, the serving BS sends a
HO_Confirm message to the serving or target GW, indicating that an MS has
started a handover. This message should comprise the following parameters:
MS ID, CID&SFID, SAID/TEK, Target BSs ID etc.Serving/Target GW
After receiving the HO_Confirm message, the target GW obtains the AK and AK
context from the Anchor Authenticator (GW&3A).
The target GW adds the AK and AK context to the HO Confirm message, and sends
the message to the target BS. The HO Confirm message carries the MS session
context information transmitted by the serving BS.
The target BS waits for an RNG-REQ message to be sent on the contention-based
timeslot.
Page 30
Handover Implementation
Page 31
HO Confirm
IE/Group Name Type Presence Length Semantics description
Serving BSID Binary M 6
Target BSID Binary M 6 ID of the target BS
MS ID Binary M 6 MAC address of the MS
Ranging_Params_valid_indicati
on
Binary M 1 Currently it is set to 0 by default
Indicator that shows whether ranging parameters acquired by the MS during preceding
Association
with selected Target BS are still valid. This indicator may be used by Target BS in decision to
allocate dedicated transmission opportunity by Fast Ranging IE.
0b00: No indication. BS ignores this field (Default)
0b01: MS ranging parameters for Target BS, which is specified in this message are valid
0b10: MS has no valid ranging parameters for Target BS, which is specified in this message
0b11: Reserved
HO_IND_Type Binary M 1 0: Confirm the handover
1: Cancel
2: Deny the handover
3: Reserved
MS Information Binary O Variable
Page 32
AK Request
IE/Group Name Type and Range Presence Length (bytes) Semantics Description
BS ID M 6 ID of the BS
MS ID M 6 ID of the MS
Anchor Authenticator ID O 4 If the Anchor
Authenticator ID is
maintained by the BS,
this IE must be carried
in the AK request
message.
Page 33
MS TBS GW
DL_MAP/UL_MAP/DCD/UCD
CDMA Code
MOB_RNG-RSP (continue)Loop
CDMA Code
MOB_RNG-RSP (success)
CDMA_Allocation_IE
MOB_RNG-REQ
MOB_RNG-RSP
Context Request
Context Report/HO_Confirm
Handover when the
target BS is not ready
DataPathRegistrationReq
DataPathRegistrationRsp
DataPathRegistrationAck
Handover when the
target BS is not ready
BR/Data
MS reentry authentication (optional)
MOB_SBC-RSP (optional)
MOB_REG-RSP (optional)
Handover Procedure — Reentry
Page 34
MS Reentry
Handover scenarios when the target BS is not ready
Due to network delay, the target BS does not yet receive the HO_Confirm message from the GW
when it receives the RNG-REQ message from the MS.
After receiving the HO_Req message, the Target BS does not allow the MS to hand off to itself or
does not keep the MS’ information due to exceptions. The MS, however, still determines to hand off to
the BS.
After processing the HO_Req message, the target BS does not receive the HO_Confirm message
within the effective time but discards the MS information previously saved.
The MS does not send the HO REQ message.
The handover delay is larger for the handover when the target BS is not ready.
If exceptions occur during the reentry process, the MS may trigger the handover cancellation
procedure or deregister itself from the network.
Page 35
MS Reentry
Handover optimization policies for MS reentry
The target BS checks the MS context information in the HO_Confirm or Context_Rpt message to determine the
handover optimization policy.
The RNG-REQ message affects the handover optimization policy in the authentication procedure.
The target BS indicates the handover optimization procedure for subsequent MS reentry in the RNG-RSP
message.
Possible combinations of handover optimization in version V21
(1) Complete optimization
(2) Re-authentication
(3) The BS initiatively sends an REG-RSP message
(4) The BS initiatively sends an SBC-RSP message and an REG-RSP message
(5) The SBC procedure is omitted but the REG procedure is not omitted
(6) No optimization at all
Page 36
Release Procedures
MS deregistration scenarios
GW-initiated deregistration
Deregistration manually initiated through the BS command line
BS-initiated deregistration upon procedural exceptions
Deregistration initiated when a carrier sector is removed
Deregistration initiated when exceptions occur to an MS
Deregistration initiated when the MS drops from the network
MS-initiated deregistration
Release in the handover procedure
Page 37
Signaling Release Procedure
GW-initiated deregistration
The GW sends an MS_Info message to instruct an MS to deregister from the network.
If the BS has allocated a Basic ID to the MS, a DREG_CMD message is sent to instruct the MS to deregister from the
network. Otherwise, an RNG_RSP (abort-040102) message is sent to instruct the MS to deregister from the network.
MS ME RRM SIG R6M
R6M_CCM_MSG_MS_INFO_REQ
R6M_CCM_MSG_MS_INFO_RSP
DREG_REQ(DeRegistrationRequestCode=0X02)
DREG_CMD(ActionCode=0x00)
GW
MS-INFO-REQ
MS-INFO-RSP
CCM_SsmRelSsResourceRef
Page 38
Signaling Release Procedure
MS-initiated deregistration
Receiving a DEREG_REQ message from the MS.
Releasing all the resources and deleting the data path with the GW after returning a DEREG_CMD message to the
MS.
MS ME RRM SIGOM R6M
DREG_REQ(DeRegistrationRequestCode=0X00)
DREG_CMD(ActionCode=0x04)
CCM_SsmRelSsResourceRef
Page 39
Signaling Release Procedure
The BS deletes a carrier sector
The BS removes all the MSs one by one from this carrier sector and then sends an RNG-RSP (abort) message to each MS.
Release an MS through the command line
Send an RNG-RSP (abort) message to the MS.
The MS deregisters itself from the network due to exceptions of BS processing
The BS sends an RNG-RSP (abort) message to the MS.
Release procedure after the handover ends
The same as the common release procedure
www.huawei.com
Security Level:
Thank You