Introduction to WiMAX Handovers 20070521 a 1_0

www.huawei.com

Security Level:

Introduction to WiMAX Handovers

Issue 1.0

March 21, 2008

WiMAX Network Planning Dept.

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

ContentsContents

Chapter 1 Overview of WiMAX handovers

Chapter 2 WiMAX handover procedures

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.

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

ContentsContents

Chapter 1 Overview of WiMAX handovers

Chapter 2 WiMAX handover procedures

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

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.

Handover Procedure — Scanning

The Serving BS sends MOB_NBR-ADV.

The MS scans the neighboring BSs.

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.

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.

MOB_NBR-ADV Message

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.

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

MOB_SCN-REQ Message

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.

MOB_SCN-RSPWhen the scan duration is set to 0, the BS denies the MS’ request for starting the scanning process.

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

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

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.

MS Scanning Process 1

MS S BS BS1 BS 2

MS-initiated

MS Scanning Process 2

BS-initiated

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)

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.

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])

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

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.

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



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.

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.

Handover Implementation

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

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.

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

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.

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

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

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


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


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

Introduction to WiMAX Handovers 20070521 a 1_0

Documents

Transcript of Introduction to WiMAX Handovers 20070521 a 1_0