Security Level:

Introduction to WiMAX Handovers

Issue 1.0

March 21, 2008

www.huawei.com
WiMAX Network Planning Dept.
Course Objectives

After studying the course, you should be able to

 Understand the types and basic concepts of WiMAX

handovers

 Understand WiMAX handover scenarios and procedures

Page 2
Contents

Chapter 1 Overview of WiMAX handovers

Chapter 2 WiMAX handover procedures

Page 3
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 4
Handover Scenarios
CSN

I-CN(R3) I-CN(R3)

GW GW Gate Way
I-BSSN(R4)

I-BB(R6) I-BB(R6) I-BB(R6)

I-BB(R6)
2

2
BS

BS
5

5
BS

BS
BS

BS
BS

BS
3

3
6

6
Int
ra

BS1 BS4 BS1 BS4

GW

I-MS BS(R1)
I-MS BS(R1) Intra GW Inter GW
Moving Moving
MS MS MS

Page 5
Contents

Chapter 1 Overview of WiMAX handovers

Chapter 2 WiMAX handover procedures

Page 6
 Handover Flow Chart

Serving BS Target BS The target BS

MS ME RRM SIG R6M GW R6M ME SIG RRM determines whether
to permit handover
Currently the serving BS does according to the
MOB_MSHO_REQ MOB_MSHO_REQ The GW determines whether to agree to
not filter the list selected by the information of the MS
handover according to the subscription
MS but the BsIndex of the BS RRM_JudgeBsTable and returns
information, filters the BSs according to
list in the message needs to be information indicating
opt CCM_LCM_ME_SCN_CFG_STOP_IND R6M_CCM_HO_REQ the load condition, and then distributes
converted into BsId. HO Request whether to permit
the HO Request message.
The GW summarizes HO HO Request R6M_CCM_HO_REQ handover. If the BS
The MOB_MSHO RSP message carries an option indicating Response messages to permits handover,
whether to retain information for the MS. Temporarily the SIG RRM_CCM_AllocHoId
form the recommended list. RRM_CCM_JudgeSfLevel the MS sets up the
determines whether to reserve resources for the MS. CB, saves the
HO Response HO Response R6M_CCM_HO_RSP RRM_CCM_HoRspPara
R6M_CCM_HO_RSP information, and
MOB_BSHO_RSP
MOB_BSHO_RSP returns a message
MOB_HO_IND MOB_HO_IND carrying parameters
R6M_CCM_HO_CNF HO Confirm such as HOID and
(Release) (Release) HO Confirm
R6M_CCM_HO_CFM
PreambleIndex to the
CID scheduling except for BC is CCM_LCM_ME_HO_STOP_SCH_IND Start the resource hold timer target BS.
stopped, but the mechanism needs to and release the resource The gateway calculates the AK
LCM_CCM_ME_HO_STOP_SCH_RSP Context and sends the
guarantee that Grant No Signal does when the timer expires.
not cause the counter to overflow. CMAC_KEY_COUNT maintained
by the Authenticator to the BS.
MS reentry

R6M_CCM_HO_CPL
HO Complete
HO Complete
R6M_CCM_HO_CPL
The message carries the
R6M_CCM_HO_ACK HO ACK latest CMAC_KEY_COUNT
HO ACK R6M_CCM_HO_ACK and is sent to the GW.
Release
MS context deletion procedure

Page 7
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 8
Handover Procedure — Scanning

The Serving BS sends MOB_NBR-ADV.

The MS scans the neighboring BSs.

Page 9
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 10
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 11
MOB_NBR-ADV Message

Page 12
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 13
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 14
MOB_SCN-REQ Message

Page 15
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 16
MOB_SCN-RSP
When the scan duration is set to 0, the BS denies the MS’ request for starting the scanning process.

Page 17
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 18
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 19
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 20
MS Scanning Process 1
MS S BS BS1 BS 2

MS-initiated

Page 21
MS Scanning Process 2

BS-initiated

Page 22
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 23
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 24
 Preparation for the MS-Initiated Handover

Serving Serving/Target Target Target

MS
BS GW BS1 BS 2...x
MOB_MSHO-REQ
HO-Request
(MS ID, capabilities,Target BS list[Signal Quality])
A HO-Request
(MS ID, connection params, capabilities,required BW and QoS)
HO--Response B
(Result f lag, MS ID, Serv ice lev el prediction, HO optimization f lag, HO_authorization_policy _support, HO ID, HOAction 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 ])
MOB_BSHO_RSP
(RecommendedBS=BS#2
serv ice lev el prediction=2)

MOB_HO_Indication
HO_IND_ty pe0b00:
serv ing BS release

Page 25
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 26
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 27
HO Response
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 　

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 28
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 29
Handover Implementation

Page 30
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_indication 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 31
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 32
Handover Procedure — Reentry
MS TBS GW

DL_MAP/UL_MAP/DCD/UCD

CDMA Code
Loop
MOB_RNG-RSP (continue)

CDMA Code

MOB_RNG-RSP (success)

CDMA_Allocation_IE

MOB_RNG-REQ

Context Request Handover

when the
Context Report/HO_Confirm target BS is
not ready

MOB_RNG-RSP

DataPathRegistrationReq
Handover
DataPathRegistrationRsp when the
target BS is
not ready
DataPathRegistrationAck

MOB_SBC-RSP (optional)

MS reentry authentication (optional)

MOB_REG-RSP (optional)

BR/Data

Page 33
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 34
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 35
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 36
Signaling Release Procedure

MS ME RRM SIG R6M GW

R6M_CCM_MSG_MS_INFO_REQ MS-INFO-REQ

R6M_CCM_MSG_MS_INFO_RSP MS-INFO-RSP

DREG_CMD(ActionCode=0x00)

DREG_REQ(DeRegistrationRequestCode=0X02)

Ref CCM_SsmRelSsResource

 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.

Page 37
Signaling Release Procedure

MS OM ME RRM SIG R6M

DREG_REQ(DeRegistrationRequestCode=0X00)

DREG_CMD(ActionCode=0x04)

Ref CCM_SsmRelSsResource

 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.

Page 38
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

Page 39
 Security Level:

Thank You

www.huawei.com