wcdma ran srns relocation

7/24/2019 Wcdma Ran Srns Relocation

http://slidepdf.com/reader/full/wcdma-ran-srns-relocation 1/54

WCDMA RAN, Rel. RU30,

Operating Documentation,

Issue 13

WCDMA RAN SRNS Relocation

DN0494337

Issue 07D

Approval Date 2012-06-22

Confidential



2 DN0494337

Issue 07D


Id:0900d8058093df31

Confidential

The information in this document is subject to change without notice and describes only the

product defined in the introduction of this documentation. This documentation is intended for the

use of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted

in any form or means without the prior written permission of Nokia Siemens Networks. The

documentation has been prepared to be used by professional and properly trained personnel,

and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes

customer comments as part of the process of continuous development and improvement of the

documentation.

The information or statements given in this documentation concerning the suitability, capacity,

or performance of the mentioned hardware or software products are given "as is" and all liability

arising in connection with such hardware or software products shall be defined conclusively and

finally in a separate agreement between Nokia Siemens Networks and the customer. However,

Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions

contained in the document are adequate and free of material errors and omissions. Nokia

Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which

may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO

EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED

TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY

OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION

IN IT.

This documentation and the product it describes are considered protected by copyrights and

other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark

of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2012. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources

of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle

this product and only after having carefully read the safety information applicable to this

product.

The safety information is provided in the Safety Information section in the “Legal, Safety

and Environmental Information” part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder

andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch

geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,

Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-

satzes.



DN0494337 3


Id:0900d8058093df31

Confidential

Table of contentsThis document has 54 pages.

Summary of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Description of SRNS relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Relocation for circuit-switched services. . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 UE-not-involved relocation for circuit-switched services . . . . . . . . . . . . . 9

2.2 UE-involved relocation for circuit-switched services (combined inter-RNC

HHO and SRNS relocation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Relocation for NRT PS services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 UE-not-involved relocation for packet-switched services. . . . . . . . . . . . 13

3.2 UE-involved relocation for packet-switched services (combined inter-RNC

HHO and SRNS relocation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Relocation for NRT PS services started by the Cel l/URA Update message

from target RNC (CELL_FACH state relocation) . . . . . . . . . . . . . . . . . . 20

4.1 No Iur in use between source RNC and target RNC . . . . . . . . . . . . . . . 22

5 Relocation for RT PS services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Support for I-HSPA Sharing and Iur Mobility Enhancements (RAN1759) .

25

6.1 I-HSPA Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Iur Mobility Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Support for Inter-RAT handover for packet-switched services from E-

UTRAN (RAN2176) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 RNC anchoring for RT (and NRT in Cell_DCH state) data services . . . 30

8.1 Anchoring for PS NRT (and PS RT) services . . . . . . . . . . . . . . . . . . . . 32

9 HSDPA Inter-RNC Inter-Frequency Cel l Change procedure (RAN1276)33

10 HSPA Inter-RNC Intra-Frequency Cell Change procedure for NRT services

(RAN1515) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

11 Location Services with SRNS relocation and anchoring . . . . . . . . . . . . 37

11.1 LCS in the SRNC relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

11.2 LCS in anchoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

12 Optional functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

13 Features per release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

14 Management data for SRNS relocation . . . . . . . . . . . . . . . . . . . . . . . . . 40

14.1 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

14.2 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

14.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

15 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54



4 DN0494337


Id:0900d8058093df31

Confidential

List of figuresFigure 1 Normal situation: UE is located in RNC1 area, and the connection is main-

tained through handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 2 UE-not-involved relocation for CS RT services. . . . . . . . . . . . . . . . . . . . 10

Figure 3 Combined hard handover and SRNS relocation procedure . . . . . . . . . . 12

Figure 4 Situation before relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 5 Data forwarding during relocation (“non-lossless” relocation) - phase 1. 14

Figure 6 U-plane switching during relocation (“non-lossless” relocation) - phase 2 .

15

Figure 7 Situation after relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 8 UE not involved SRNS relocation for PS NRT services . . . . . . . . . . . . . 16

Figure 9 Situation before relocation when no Iur is available . . . . . . . . . . . . . . . . 17

Figure 10 Data forwarding during relocation when no Iur is available . . . . . . . . . . 18

Figure 11 Situation after relocation when no Iur is available. . . . . . . . . . . . . . . . . . 18

Figure 12 Combined hard handover and SRNS relocation. . . . . . . . . . . . . . . . . . . 19

Figure 13 Combined Cell/URA update and SRNS relocation procedure . . . . . . . . 21

Figure 14 Directed signalling connection re-establishment initiated by the target RNC

22

Figure 15 PS packet flows during an as-seamless-as-possible relocation . . . . . . . 24

Figure 16 Basic I-HSPA Adapter Sharing CS RAB setup scenario . . . . . . . . . . . . 27

Figure 17 PS packet flows during as seamless as possible relocation. . . . . . . . . . 29

Figure 18 Principles of the Anchoring RNC functionality . . . . . . . . . . . . . . . . . . . . 31

Figure 19 Successful Inter-RNC Hard Handover . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 20 Successful HSPA Inter-RNC RNC Intra-frequency Serving Cell Change. .

36



DN0494337 5


Id:0900d8058093df31

Confidential

List of tablesTable 1 Services of the RNC and I-HSPA Adapter in different roles . . . . . . . . . 26

Table 2 Features related to SRNS relocation . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Table 3 RAN 1.011: MS Location Management with Handover procedures . . . 40

Table 4 RAN 1.5010: Inter Frequency HHO . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Table 5 RAN 1.5010: Inter Frequency HHO/ RAN 1.5009 : WCDMA - GSM Inter

System Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Table 6 RAN 1.010 : RAN Radio Access Bearer Services . . . . . . . . . . . . . . . . 51

Table 7 RAN 1.011: MS Location Management with Handover procedures . . . 52

Table 8 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements 53



6 DN0494337


Id:0900d8058093df2f

Confidential

Summary of Changes

Summary of Changes Changes between document issues are cumulative. Therefore, the latest document

issue contains all changes made to previous issues.

Changes between issues 07C (2011-02-26, RU30) and 07D (2012-06-22, RU30)

RNC anchoring for RT (and NRT in Cell_DCH state) data services (8)

• Information on Inter-system handovers during RNC anchoring has been updated.

Changes between issues 07B (2011-09-01, RU30) and 07C (2012-02-26, RU30)

Management data for SRNS relocation (14)

• Parameters related to feature RAN1759: Support for I-HSPA Sharing and Iur

Mobility Enhancements have been added to section Parameters.

Changes between issues 07A (2011-06-10, WCDMA RAN and I-HSPA RU30) and

07B (2011-09-01, WCDMA RAN and I-HSPA RU30)

Support for I-HSPA Sharing and Iur Mobility Enhancements (RAN1759) (6)

• Information on I-HSPA Sharing and Iur Mobility Enhancements has been updated.

Sections I-HSPA Sharing and Iur Mobility Enhancements have been added.



DN0494337 7

WCDMA RAN SRNS Relocation Description of SRNS relocation

Id:0900d805807a4dd4

Confidential

1 Description of SRNS relocationThe SRNS relocation is used for moving the SRNC functionality from one RNC to

another RNC closer to the User Equipment (UE) if the UE moves during the communi-

cation. Both the radio access network (RAN) and the core network are involved.

This section handles the SRNS relocation procedures while there are dedicated channel

resources, that is, radio link(s) allocated for the UE and the handover control algorithm

of the serving RNC is controlling the mobility procedures of the RRC connection. Only

SRNS relocation procedures in CELL_DCH state are handled here, that is, from a data

forwarding point of view. Mobility management during the other RRC states

(Cell_FACH, Cell_PCH or URA_PCH) is based on cell reselections performed by the

UE and Cell/URA Update procedures. When a Cell/URA Update is received through the

Iur interface from the neighbouring RNC (DRNC), the RRC entity of the SRNC initiates

a SRNS relocation procedure for packet-switched non-real time service (if SRNS relo-

cation is supported by the peer elements).

Each RNC is able to control hundreds of BTSs. The vast majority of handovers in the

WCDMA domain occurs inside one RNC area, that is, between cells controlled by one

RNC, and this way causes no SRNS relocation. On the other hand, in addition to normal

intra-WCDMA SRNS relocations, inter-system handovers between UTRAN and GERAN

and from E-UTRAN to UTRAN can occur.

For detailed information about different handover procedures, see Sections Functional-

ity of intra-frequency handover , Functionality of inter-frequency handover , Functionality

of inter-system handover and Functionality of inter-frequency handover over Iur in

WCDMA RAN RRM Handover Control .

Handovers and SRNS relocation

The main purpose of handovers is to maintain the traffic connection between the UE and

the RNC when the UE is moving from the coverage area (cell) of one BTS to that of

another BTS. The reason for the handover is that the signal of the new BTS becomes

better. Besides pure mobility management concerns, handovers are performed for

capacity reasons, that is, to minimise interference.

Regarding the UEs mobility it is really the handovers that count. The SRNS relocation

procedures can be seen as a subset for handover procedures: there are handovers

without SRNS relocation but no SRNS relocations without handovers.

Since an RNC can have thousands of BTSs in its area, SRNS relocations are much

more infrequent than handovers. On the other hand, a handover is always performed

before or during an SRNS relocation. It should be noted, however, that unnecessaryrelocations can be avoided through smart radio network planning and optimization.

Some evident benefits of SRNS relocation

• Radio resource optimisation is done in the RNC that has the best inputs for the algo-

rithms (for example handover decision).

• Transmission route is always optimised - every RNC does not have to be configured

as a neighbour RNC for other RNCs.

• Iur interface is not critical: congestion or failure situations do not affect UE mobility

since handovers can be done without Iur interface (hard handover)

• Iur interface dimensioning is easier.

•Lost calls can be avoided.

http://general_glossary.pdf/













http://fad_handover_control.pdf/



























8 DN0494337


Id:0900d805807a4dd4

Confidential

Description of SRNS relocation

• Excessive traffic load in hot spot RNCs (for example railway stations, airports and

subway stations) can be avoided.



DN0494337 9

WCDMA RAN SRNS Relocation Relocation for circuit-switched services

Id:0900d8058085eecd

Confidential

2 Relocation for circuit-switched servicesSRNS relocation procedures are described here while there are dedicated channel

resources, that is, radio link(s) allocated for the UE and the handover control algorithm

of the serving RNC is controlling the mobility procedures of the RRC connection.

2.1 UE-not-involved relocation for circuit-switched services

SRNS relocation is started when the current active set only comprises cells belonging

to the drifting RNC (DRNC, target RNC). The relocation procedure is initiated by the

serving RNC (SRNC, source RNC) which sends a RANAP: RELOCATION REQUIRED

message to the MSC. MSC then checks if the requested relocation is possible.

Figure 1 Normal situation: UE is located in RNC1 area, and the connection is main-

tained through handovers

If the relocation is possible, MSC sends a RANAP: RELOCATION REQUEST to the

target RNC. After receiving the RANAP: RELOCATION REQUEST message, the target

RNC begins the setup of new Iu links. The target RNC sends a RANAP: RELOCATION

REQUEST ACKNOWLEDGE message to the MSC. After receiving the RANAP: RELO-

CATION REQUEST ACKNOWLEDGE, the MSC sends a RANAP: RELOCATION

COMMAND message to the source RNC.

After receiving the RANAP: RELOCATION COMMAND message from the MSC, the

source RNC sends the RNSAP: RELOCATION COMMIT message to the target RNC.The target RNC performs the downlink and uplink switch. The target RNC starts acting

as a serving RNC and sends the RANAP: RELOCATION DETECT message to the

MSC, which also performs the DL/UL switch for the user plane. The target RNC informs

the UE about the performed relocation (by using a RRC: UTRAN mobility information

procedure). The UE sends the RRC: UTRAN MOBILITY INFORMATION CONFIRM

message to the target RNC (although this is a case where the UE is not involved). The

target RNC then sends the RANAP: RELOCATION COMPLETE message to the MSC.

The MSC releases all Iu-related resources towards the source RNC, and all user data

flow occurs over the new Iu link through the target RNC to or from the UE. In this

example, the MSC is not changed; if the MSC changes, it is still invisible to the RNCs.

SGSNRNC 2

RNC 1

GGSNBTS

UE

MSC GMSC















10 DN0494337


Id:0900d8058085eecd

Confidential

Relocation for circuit-switched services

Figure 2 UE-not-involved relocation for CS RT services

SRNS relocation decision in the source RNC

When the UE is moving from one RNC area to another, the serving RNC (SRNC) may

end up in a situation where it no longer controls the radio links with its own base stations

through the Iub interface. Although the source RNC could remain as a "controlling" node

for the radio links in the target RNC area, there would be an unnecessary data streamover the Iur interface, which could result in Iur congestion. Also, the Iu path from the core

network to the controlling RNC should be as short as possible. This is the point where

SRNS relocation is needed.

The following timers are used for supervising the RANAP signalling sequence described

above during the SRNS relocation procedure:

• T RelocPrep (TRelocPrep)

The timer T RelocPrep (TRelocPrep) specifies the maximum time for the relocation

preparation procedure in the source RNC. The timer is set when a RANAP: RELO-

CATION REQUIRED message is sent. The timer is stopped when a RANAP: RELO-

CATION COMMAND or a RELOCATION PREPARATION FAILURE message is

received. If there is no response from the CN to the RANAP: RELOCATION

Source RNC CN Target RNC UE

RANAP: RelocationRequired

RANAP: RelocationRequest

Resources allocation

RANAP: RelocationCommand

RANAP: RelocationRequest Acknowledged

User plane setup

RNSAP: RelocationCommit

SRNC operation start

RANAP: RelocationDetect

UP switching

User plane release

RANAP: IU ReleaseCommand

RANAP: RelocationComplete

RRC: UTRAN MobilityInfomation

RRC: UTRAN MobilityInformation Confirm

RANAP: IU ReleaseComplete



DN0494337 11

WCDMA RAN SRNS Relocation Relocation for circuit-switched services

Id:0900d8058085eecd

Confidential

REQUIRED message before the RANAP timer T RelocPrep (TRelocPrep) expires,

the source RNC cancels the RANAP: RELOCATION PREPARATION procedure by

initiating the RANAP: RELOCATION CANCEL procedure with a cause value 'T

RelocPrep expiry'.

• T RelocOverall (TRelocOverall)

T RelocOverall (TRelocOverall) timer is used in both source and target RNC. T Relo-

cOverall (TRelocOverall) specifies the maximum time for the protection of overall

Relocation procedure in the source RNC. The timer is set in the source RNC when

a RANAP: RELOCATION COMMAND message is received. The timer is stopped

when a RANAP: IU RELEASE COMMAND is received, or the relocation procedure

is cancelled. The timer is set in the target RNC when a RANAP: RELOCATION

REQUEST ACKNOWLEDGE message is sent. The timer is stopped when a

RANAP: RELOCATION COMPLETE message is sent or the relocation procedure is

cancelled.

After the expiry of the T RelocOverall (TRelocOverall), the source RNC initiates the

Iu Release Request procedure. If the RANAP timer T RelocOverall (TRelocOverall)expires in the target RNC, it sends RANAP: IU RELEASE REQUEST message with

a cause value "Relocation Failure in Target CN/RNC or Target System" to all

affected CNs.

2.2 UE-involved relocation for circuit-switched services (com-

bined inter-RNC HHO and SRNS relocation)

The combined inter-RNC HHO and SRNS relocation procedure is "UE involved", since

the UE is ordered to switch to another carrier frequency or to replace the whole active

set by sending a HHO command to the UE during the relocation procedure. The follow-

ing different reasons can be separated for inter-RNC HHO:

• Inter-frequency HHO is needed and the target cell is located in the DRNS.

• No U-plane is available (the inter-RNC SHO is not possible) between the source

RNC and the target RNC because of malfunction or congestion in the Iur connection.

• No Iur interface is configured between the neighbour RNCs.

Because there is no Iur interface available between the source RNC and the target RNC,

combined hard handover and SRNS relocation are done before the UE is completely

under the target RNC. The procedure is continued as described in UE not involved relo-

cation for circuit-switched services until RANAP: RELOCATION COMMAND message

is received in SRNC. The only difference is that when SRNS relocation is started with

RANAP: RELOCATION REQUIRED message, the Relocation Type IE is set to "UE

involved in relocation of SRNS".

Instead of RNSAP: RELOCATION COMMIT message, the serving RNC sends a RRC:

PHYSICAL CHANNEL RECONFIGURATION message to the UE, after which the UE

stops transmitting and receiving on the old radio links and starts on the new radio link,

see Figure 3 Combined hard handover and SRNS relocation procedure.

The RNSAP: RELOCATION COMMIT procedure can be used for speeding up the U-

plane switching procedure in the target RNC. There, however, is also a drawback when

using the commit procedure in the inter-RNC HHO for CS services, since the MSC uses

RANAP:RELOCATION DETECT message as a trigger for U-plane switching from

source-RNC to the target-RNC. If the UE with CS service or CS/PS multi-service is not

able to synchronise in the physical channel assigned in the HHO command, the UE isnot allowed to return back to the old channel after an unsuccessful HHO attempt (the





12 DN0494337


Id:0900d8058085eecd

Confidential

Relocation for circuit-switched services

MSC has already switched the U-plane towards the target RNC). The commit procedure

in the inter-RNC HHO is controlled by the management parameter Usage of Relocation

Commit procedure in inter RNC HHO (RelocComm_in_InterRNC_HHO). This parame-

ter controls the use of RNSAP: Relocation Commit procedure during the Inter-RNC hard

handover execution.

For a UE with PS(only) service, SGSN re-routes the U-plane connection from source-

RNC towards the target-RNC based on the RANAP:RELOCATION COMPLETE

message received from the target-RNC, and thus there is no need for prohibiting the

usage of Relocation Commit procedure in inter-RNC HHO for PS(only) services.

Figure 3 Combined hard handover and SRNS relocation procedure

Target RNCUE Source RNC

1. Decision to perform UEinvolved SRNS relocation

2. Relocation Required

3. Relocation Request

Resourceallocation

MSC

3. Relocation Request Acknowledge

User plane setup

4. Relocation Command

5. PhyCh Reconf.

L1 Sync. Establishedbetween BTS and UE

7. Relocation Detect

5. Physical Channel Reconfig. CompleteUP

Switching

8. Relocation Complete

9. Iu Release Command

9. Iu Release Complete



DN0494337 13

WCDMA RAN SRNS Relocation Relocation for NRT PS services

Id:0900d8058085eed5

Confidential

3 Relocation for NRT PS servicesThe signalling (RANAP/RNSAP messages) is the same as in relocation for circuit-

switched services described in Section Relocation for circuit-switched services.

g The examples given here are inter-SGSN relocations where the SGSN nodes are

changed during the SRNS relocation procedure. However, this is not directly visible to

the RAN.

3.1 UE-not-involved relocation for packet-switched services

The UE is connected to two RNCs, but no relocation is required yet (for example, in sit-

uations when the UE is connected to cells under different RNCs and is stationary).

Figure 4 Situation before relocation

When the last radio link to the source RNC stands to be deleted, the DRNC needs to

adopt the role of the SRNC. During the SRNS relocation, interruptions to the data flow

are minimized, and in practice unnoticeable. The relocation procedure is started after

the last cell under the SRNC has been deleted from the UE's active set. The SRNC func-

tionality of a specific RRC connection is relocated from one RNC to another without

changing the radio resources or even interrupting the user data flow.

Before initiating the relocation procedure for the packet-switched service, the timerTimer T(Reloc_Inhibit_NRT) is started in the source RNC to verify whether the U-plane

data continues to flow after the relocation. If the timer Timer T(Reloc_Inhibit_NRT) is set

to zero, the relocation is started immediately. If inactivity is detected in the NRT radio

bearer(s), the (Cell_DCH state) relocation is not triggered and the UE is switched to the

Cell_FACH state. If the inactivity occurs during the relocation, the relocation procedure

must be interrupted since the transport channel configuration is not allowed to change

during the relocation procedure.

SGSNTarget RNC

SGSNSource RNC

GGSNlur

Bothcells in

active set

BTS

UE ismoving UE

BTS















14 DN0494337


Id:0900d8058085eed5

Confidential

Relocation for NRT PS services

Figure 5 Data forwarding during relocation (“non-lossless” relocation) - phase 1

1. PDU delivery through Iur towards the target RNC continues, no requirement for

lossless relocation exists (as seamless as possible SRNS relocation).

2. PDUs are duplicated and forwarded towards the target RNC through the Iu-PS GTP

tunnel after a Relocation Command (or SRNS DATA FORWARD COMMAND)

message is received in the SRNC.

In phase 2, the source RNC starts time supervision for the data forwarding procedure.This is controlled by the following management parameter:

• T DATAfwd (TDataFwd)

The source RNC starts the timer when it receives a RANAP: RELOCATION

COMMAND message (or a RANAP: SRNS DATA FORWARD COMMAND

message) from the SGSN. The source RNC stops the timer when it releases all

related RAB resources, and data forwarding is stopped (or vice versa, expiration of

the timer stops the data forwarding). If the RNC receives an Iu Release Command

from the SGSN during T DATAfwd (TDataFwd), it sends an IU RELEASE

COMPLETE message to the SGSN immediately. Data forwarding, however, cannot

be disturbed, but it can continue until the expiry of T DATAfwd (TDataFwd).

For a description of the parameter, see the WCDMA RAN Radio Network Configu-ration Parameters.

SGSNTarget RNC

SGSNSource RNC

GGSNlur

BTS

UE

BTS

1

2




http://wcdma_param.pdf/









DN0494337 15


Id:0900d8058085eed5

Confidential

Figure 6 U-plane switching during relocation (“non-lossless” relocation) - phase 2

1. The source RNC sends a RELOCATION COMMIT message to the target RNC.

2. The target RNC rejects data from Iur and starts to receive (use) data from the data

forwarding tunnel.

3. The target RNC sends a RELOCATION DETECT message to the SGSN. The target

RNC completes the relocation signalling with the UE and sends a RELOCATION

COMPLETE message to the SGSN.4. The SGSN forwards the switching information to the GGSN.

5. The GGSN directs the U-plane towards the target RNC. The target RNC starts to

receive data from the SGSN.

Figure 7 Situation after relocation

To avoid frequent back-and-forth relocations in the RNC border area, the target RNC

starts a short supervision timer of 10 seconds after the relocation procedure is com-pleted. During this time supervision, the SRNS relocation procedure is not initiated.

SGSNTarget RNC

SGSNSource RNC

GGSNlur

BTS

UE

BTS

1

2

3 4

5

SGSNTarget RNC

SGSNSource RNC

GGSNlur

BTS

UE

BTS



16 DN0494337


Id:0900d8058085eed5

Confidential


Note, however, that the radio network planning (inter-RNC neighbour cell definitions in

the RNC border area) should make the back-and-forth relocations between the neigh-

bouring RNCs improbable.

The signalling of the SGSN-controlled serving RNC relocation is generally the same asin an UE not involved CS RT SRNS relocation, except the use of data forwarding pro-

cedure and potential RANAP: SRNS DATA FORWARD COMMAND instead of RANAP:

RELOCATION COMMAND.

Figure 8 UE not involved SRNS relocation for PS NRT services

UE Source

RNCTargetRNC

SGSN

1. Decision to performSRNS relocation


Establishment of Radio Access Bearers




5.Relocation Commit

6. Forwarding of Data


8. UTRAN Mobility Information

8. UTRAN Mobility Information Confirm




11. Routing Area Update



DN0494337 17


Id:0900d8058085eed5

Confidential

3.2 UE-involved relocation for packet-switched services

(combined inter-RNC HHO and SRNS relocation)

gThe example given here includes the different "Iur not available cases" described inSection UE involved relocation for circuit-switched services (combined inter-RNC HHO

and SRNS relocation). The RANAP messages are the same as in Section UE-not-

involved relocation for circuit-switched services except for the RANAP: FORWARD

SRNS CONTEXT procedure (instead of RNSAP: RELOCATION COMMIT over Iur),

which can be used for forwarding the PDCP sequence numbers from source RNC to

target RNC through the SGSN(s).

PDCP sequence numbers are not sent from source RNC to target RNC in RU10.

Figure 9 Situation before relocation when no Iur is available

1. If Iur is not available, only cells under the SRNC can belong to the active set. If the

signal gets weaker, the SRNC looks up neighbour cells in its database and orders

measurements.

2. If relocation is imminent (that is, measurements indicate that the cell under the target

RNC would be better), the source RNC requests SRNS relocation from the CN and

the target RNC.

3. Only the source RNC cell is in the active set.

4. Signal of the target RNC cell is good.

SGSNTarget RNC

SGSNSource RNC

GGSNNO lur

available

BTS

UE

BTS

12

3

4





18 DN0494337


Id:0900d8058085eed5

Confidential


Figure 10 Data forwarding during relocation when no Iur is available

1. UE is still connected to source RNC.

2. Signal of the target RNC cell is good.

3. During relocation (before the HHO command has been sent to the UE), the UE is

still connected to the source RNC but data is also forwarded towards the target RNC

through the Iu-PS GTP tunnel.

Figure 11 Situation after relocation when no Iur is available

1. HHO is executed. UE has no connection to source RNC any longer.

2. Target RNC cell is in the active set.

See the Figure 12 Combined hard handover and SRNS relocation for a presentation of

signalling in combined hard handover and SRNS relocation.

SGSNTarget RNC

SGSNSource RNC

GGSNNO lur

available

BTS

UE

BTS

2

1

3

SGSNTarget RNC

SGSNSource RNC

GGSNNO lur

available

BTS

UE

BTS

2

1



DN0494337 19


Id:0900d8058085eed5

Confidential

Figure 12 Combined hard handover and SRNS relocation

UE Source

RNCTargetRNC

SGSN





6. Forward SRNS Context

8. Relocation Detect5. Physical ChannelReconfiguration Complete




11. Routing Area Update

1. Decision to perform SRNSRelocation UE Involved

5. Physical Channel Reconfiguration

6. Forward SRNS Context

UE detected by target RNC

7. Forwarding of Data

Establishment of Radio Access Bearers



20 DN0494337


Id:0900d805807a4ddd

Confidential

Relocation for NRT PS services started by theCell/URA Update message from target RNC

4 Relocation for NRT PS services started by

the Cell/URA Update message from target

RNC (CELL_FACH state relocation)Mobility management during the other RRC states (Cell_FACH, Cell_PCH or

URA_PCH) is based on cell reselections performed by the UE and Cell/URA update pro-

cedures. When a Cell/URA Update is received through the Iur interface from the neigh-

bouring RNC (DRNC), the RRC entity of the SRNC initiates a SRNS relocation

procedure for packet-switched non-real time service (if SRNS relocation or Cell_FACH

state SRNS relocation is supported by the peer elements).

If SRNS relocation (normal relocation) is not supported by the peer elements, the

Cell_FACH state support needs to be checked.

In CELL_FACH state relocations, the RRC entity of SRNC makes a decision whether to

initiate the Cell_FACH state SRNS relocation or not. The decision is based on thesupport indicator information. The following management parameters in the source RNC

are used for predefined support indication information (the "own" CN nodes and the

target RNC/CN nodes of the target RNC) of the SRNS relocation procedure:

• Cell_FACH state Serving RNC Relocation Support of neighbour RNC (CellFACH-

nRncRelocSupport)

The Cell_FACH state serving RNC Relocation Support of the neighbouring RNC

contains combined support information whether a particular neighbouring RNC

node and the CN nodes are connected to this RNC support Cell_FACH state SRNS

relocation. If all network nodes involved do not support the Cell_FACH state SRNS

relocation procedure, the Cell_FACH state relocation procedure is not started and

the SRNC initiates a directed signalling connection re-establishment by sending anRRC: RRC CONNECTION RELEASE message with a cause value "Directed Sig-

nalling Connection Re-establishment" to the UE via the Iur and the DRNS.

• Cell_FACH state Serving RNC Relocation Support (CellFACHrelocSupport)

The Cell_FACH state serving RNC Relocation Support contains information on

whether the PS-CN node connected to the SRNC supports the SRNS relocation pro-

cedure.

If none of the network nodes involved support the SRNS relocation procedure or the

Cell_FACH state SRNS relocation procedure, the RRC layer of the source RNC initiates

an RRC connection release procedure over the Iur interface (regardless of the cause

value for Cell/URA update) to force the UE to perform a call re-establishment via the

target RNS.

To initiate the directed signalling connection re-establishment procedure, the source

RNC releases the RRC connection to the UE by sending an RRC CONNECTION

RELEASE message with a cause value "Directed Signalling Connection Re-establish-

ment" via Iur and the target RNC to the UE.

If there is no Iur signalling connection available between the target RNC and the source

RNC, the target RNC must initiate a directed signalling connection re-establishment pro-

cedure by itself.















DN0494337 21

WCDMA RAN SRNS Relocation Relocation for NRT PS services started by theCell/URA Update message from target RNC

Id:0900d805807a4ddd

Confidential

Figure 13 Combined Cell/URA update and SRNS relocation procedureThe SRNS relocation procedure is started when an RRC: CELL UPDATE or RRC: URA

UPDATE message is received by the source RNC inside an RNSAP: UPLINK SIGNAL-

LING TRANSFER INDICATION message. If there is no response from the CN to the

RANAP: RELOCATION REQUIRED message before the RANAP timer T RelocPrep

(TRelocPrep) expires, the source RNC cancels the RANAP: RELOCATION PREPARA-

TION procedure by initiating the RANAP: RELOCATION CANCEL procedure with a

cause value 'TRELOCprep expiry'.

After this, the source RNC can reinitiate the SRNS relocation procedure or a call re-

establishment by sending an RRC: RRC CONNECTION RELEASE message with a

'Directed Signalling Connection Re-establishment' cause value to the UE.

2. Decision to performSRNS Relocation

User plane setup

UPSwitching

UE Source

RNCTarget

RNC SGSN

1. Cell / URA Update

1. Uplink Signalling Transfer Indication[ Cell / URA Update ]



Resourceallocation



5. Relocation Commit


7. Cell / URA Update Confirm

7. UTRAN Mobility Information Confirm








22 DN0494337


Id:0900d805807a4ddd

Confidential

Relocation for NRT PS services started by theCell/URA Update message from target RNC

Cell_FACH state SRNS relocation triggered during the signalling connection

establishment towards the CS-CN

If there is a CELL UPDATE received over Iur after the RANAP: INITIAL UE MESSAGE

has been sent to the CS-CN, the RRC entity buffers all DL DIRECT TRANSFERmessages and sends a RANAP: RELOCATION REQUIRED message to both CNs.

If there is an RAB Assignment (setup) received from the CS-CN after the receipt of the

Cell Update, the RAB setup is rejected by using the cause value 'Unable to Establish

During Relocation'.

4.1 No Iur in use between source RNC and target RNC

When the target RNC receives an RRC: CELL/URA UPDATE message from the UE

identifying a different RNC (U-RNTI IE in the received message), normally the RNSAP:

UPLINK SIGNALLING TRANSFER procedure is used to convey this information to the

source RNC.

Figure 14 Directed signalling connection re-establishment initiated by the target RNC

If RNSAP procedures are not available, it is not possible to perform SRNS relocation

procedure because of cell or URA update to another RNC. In this case the target RNC

forces the UE to initiate a call re-establishment procedure (and to perform a RA update)

towards the PS CN by sending an RRC: RRC CONNECTION RELEASE message with

the cause value ''Directed Signalling Connection Re-establishment" to the UE.

Directed signalling connection re-establishment is a basic procedure needed also if the

UE makes a cell reselection to a cell not controlled by the SRNC and if there is no Iur.

When the UE in the CELL_FACH or CELL_PCH state performs a cell reselection to the

cell controlled by the target RNC, the UE initiates an RRC: CELL UPDATE procedure.

If the UE was in the URA_PCH state, the initiated RRC procedure is URA update.

UE DRNC SRNC

UE in CELL_FACH, CELL_PCH,or URA_PCH state and it makes

cell re-selection.

UE starts Cell / URA Updateprocedure and transfers to

the CELL_FACH state.

RRC: Cell / URA Update

No RNSAPProcedures available

RRC: RRC Connection Release

(cause: Directed SignallingConnectionRe-establishment)





DN0494337 23

WCDMA RAN SRNS Relocation Relocation for RT PS services

Id:0900d8058085eecf

Confidential

5 Relocation for RT PS servicesFor the present (if RT-PS-RABs are allowed in general), the relocation of PS domain

RT-RAB does not differ from the relocation of NRT-RABs, which means that there are

no special arrangements for the RT-PS-RABs.

The PS domain handover for real-time services requires an as-seamless-as-possible

relocation of the SRNS. An as-seamless-as-possible relocation of the SRNS means that

the interruptions to the data stream flow are minimised and are basically unnoticeable

by the users. Some data loss can be accepted, but there cannot be much buffering nor

retransmits because of maximum delay requirements used with real-time bearers.

Note that as-seamless-as-possible is not an official term but it can be seen as "non-loss-

less" when we know that "lossless non-real time" means that PDCP sequence number-

ing (if the UE is capable) with AM - RLC and PDU buffering and Iur suspension must be

used in order to eliminate packet loss and packet duplicates during the lossless SRNS

relocation.The signalling messages (RANAP) for packet-switched services are the same as those

for circuit-switched services described in section Relocation for circuit-switched services

in this document. The basic principle of the PS domain handover for real-time services

is as follows:

• After receiving the RANAP: RELOCATION COMMAND, the source RNC starts to

duplicate downlink GTP-PDUs: local PDCP/RLC/MAC processing (over the Iur)

continues and another copy is forwarded to the target RNC through Iu-PS GTP

tunnel. Iur is not suspended as in a lossless case.

• Target RNC discards all forwarded GTP-PDUs arriving to target RNC until Serving

RNC operation is started (RNSAP Relocation Commit). There is no buffering as in

a lossless case. • When target RNC takes over the serving RNC role, it starts to process the arriving

(Iu-PS) downlink GTP-PDUs and send downlink data to the UE. The uplink flow is

routed as in lossless relocation of SRNC.

1. Copies of DL GTP PDUs forwarded to target RNC

2. DL processing continues

SGSN

SGSN

RABDownlink

RABUplink

SourceRNC

Node B

TargetRNC

RABDownlink

RABUplinkRAB Downlink

RAB Uplink

UE

5

Pkt

Pkt

3

4

2

1

Packet flow downlinkPacket flow uplink

GGSN













24 DN0494337


Id:0900d8058085eecf

Confidential

Relocation for RT PS services

3. Target discards DL PDUs until it becomes serving RNC

4. Target RNC starts DL processing when it becomes serving RNC

5. DL flow through target SGSN after relocation

Figure 15 PS packet flows during an as-seamless-as-possible relocation



DN0494337 25

WCDMA RAN SRNS Relocation Support for I-HSPA Sharing and Iur Mobility Enhance-ments (RAN1759)

Id:0900d805808bcfc7

Confidential

6 Support for I-HSPA Sharing and Iur Mobility

Enhancements (RAN1759)

The optional Support for I-HSPA Sharing and Iur Mobility Enhancements featurecontains two parts:

• I-HSPA Sharing feature, which is needed only when using I-HSPA Rel.2 Adapter.

g I-HSPA Rel.3 Adapter and newer supports CS services and I-HSPA Sharing is not

required.

• Iur Mobility Enhancements feature, which makes the following possible:

– DCH scheduling during anchoring

– Inter-system handover (ISHO) during anchoring

Both features are controlled by the same RNC level license key. The license key is

“ON/OFF” type.

g Note that Iur Mobility Enhancements can be used also in the RNC without I-HSPA

Adapters in the network.

6.1 I-HSPA Sharing

I-HSPA Sharing feature can be optionally enabled or disabled in the SRNC using a

separate feature enabling parameters when the license key is in ON state.

The value of IBTSSharing parameters can be set to "Supported" only if the state of the

I-HSPA Sharing license is ON.

The I-HSPA Sharing feature shares BTS resources between WCDMA services and I-HSPA services. The same resources are used for CS (and CS + PS multi RAB) services

over Iur and directly by I-HSPA Adapter for PS (only) services.

The I-HSPA Adapter can be imagined as a small RNC (one BTS with RNC functionality)

with limited support of services (starting from I-HSPA release 4, there is no limitation).

The I-HSPA release 1 and 2 Adapter supports only PS services (I-HSPA release 3

Adapter or newer can support also CS services) and needs I-HSPA Sharing functionality

to provide CS services. Towards CS CN, I-HSPA Adapter supports only the signaling

traffic. For all CS services, which need a RAB, the UE-involved SRNS relocation is per-

formed before the RAB is set up in the I-HSPA Adapter.

The I-HSPA Adapter sharing solution allows to install one card to the existing BTS and

take the I-HSPA traffic directly out from the base station. The I-HSPA Adapter supportsall the services within the following functional split:

• RNC supports CS and CS + PS multiRAB services

• I-HSPA Adapter (card inside the BTS) supports PS Rel99 and HSPA services

This feature automatically shares all BTS resources.

SRNS relocation is required between the I-HSPA Adapter and the RNC because Iu-CS

interface including both the control plane and the user plane is supported in RNC only.

Support for I-HSPA Sharing feature is based on the idea that the serving RNC (SRNC)

functionality is switched between the RNC and the I-HSPA Adapter based on the

services the user wants.



26 DN0494337


Id:0900d805808bcfc7

Confidential

Support for I-HSPA Sharing and Iur Mobility Enhance-ments (RAN1759)

The I-HSPA Adapter sharing is standardized in 3GPP to be implemented as the UE-

involved relocation with combined HHO. This relocation results in the radio links created

over Iur between the RNC (acting as SRNC) and the Adapter (acting as DRNC+CRNC).

After the relocation the CS call setup continues with RNC in anchoring mode.

Because RNC WBTS and I-HSPA Adapter share one common carrier, mobility between

the I-HSPA Adapter cell and WBTS cell must be supported. RNC supports both SRNC

and DRNC functionalities. When I-HSPA Adapter is SRNC, the mobility between I-

HSPA Adapter cell and WBTS cell is based on the HSPA Inter-RNC Cell Change feature(RAN1515). Iur interface is configured between I-HSPA Adapter and RNC - standard-

ized as a part of 3GPP Rel7.

The Figure 16 Basic I-HSPA Adapter Sharing CS RAB setup scenario illustrates CS

RAB setup case when UE sends the RRC Connection request to the I-HSPA Adapter

cell. The I-HSPA Adapter starts UE-involved SRNS relocation towards the RNC after it

has detected that CS RAB is needed.

Services SRNC functionality CRNC and DRNC functionality

CS, CS+PS(Rel99) RNC I-HSDPA Adapter, RNC

PS(Rel99), PS(HSPA) I-HSDPA Adapter I-HSDPA Adapter, RNC

Table 1 Services of the RNC and I-HSPA Adapter in different roles



DN0494337 27

WCDMA RAN SRNS Relocation Support for I-HSPA Sharing and Iur Mobility Enhance-ments (RAN1759)

Id:0900d805808bcfc7

Confidential

Figure 16 Basic I-HSPA Adapter Sharing CS RAB setup scenario

6.2 Iur Mobility Enhancements

During anchoring the following functionalities are supported with Iur Mobility Enhance-

ments feature:

• DCH scheduling

•Inter-system handover (ISHO)

UE I - BTS RNC MSS

RRC Connection request

Initial Direct Transfer

Initial UE Message

RRC Connection Setup

SCCP : CC (opt. RANAP message)

Based on MM message CS RAB needed,

UE Involved SRNS Relocation to RNC

initiated . UE in Cell:DCH state.

Relocation Required

Relocation request ( no RABs)

Target Cell under I-BTS, RL Setup over Iur

required. DCH allocated for SRB. Direct to

anchoring mode during relocation. New

3 GPP rel 7 functionality.

Radio Link Setup

Radio Link Setup Response

Relocation Request Ack ( HHO message)

Relocation Command

Radio Bearer Reconfiguration

Radio Bearer Reconfiguration Complete

Radio Link Restoration

(Relocation Commit)

Relocation Detect ( after Commit, if received)

Relocation Complete

Call setup continues

in RNC

Iu Release

(Security procedure)

RAB Assignment request (CS RAB setup)

Radio Link Reconfiguration Prepare

Radio Link Reconfiguration Ready

IP transmission “setup” over Iur for CS RAB

Radio Link Reconfiguration Commit

Radio Bearer Setup

Radio Bearer Setup CompleteRAB Assignment Response

HHO message for SRB

CS RAB setup in anchoring

UTRAN Mobility Information (timers and constant parameters) / Confirm

Security procedure



28 DN0494337


Id:0900d805808bcfc7

Confidential

Support for I-HSPA Sharing and Iur Mobility Enhance-ments (RAN1759)

ISHO during anchoring and DCH Scheduling can be optionally enabled or disabled in

the SRNC using a separate feature enabling parameters when the license key is in ON

state.

The DCHScheOverIur and ISHOInIurMobility parameters can be set to "Sup-ported" only if the state of the I-HSPA Sharing license is ON.



DN0494337 29

WCDMA RAN SRNS Relocation Support for Inter-RAT handover for packet-switchedservices from E-UTRAN (RAN2176)

Id:0900d8058085b842

Confidential

7 Support for Inter-RAT handover for packet-

switched services from E-UTRAN (RAN2176)

LTE system can trigger Inter-RAT handover to UTRAN for packet-switched (PS) calls.The RAN2176: LTE PS Handover feature supports the incoming Inter-RAT PS

handover from LTE.

Inter-system handover of PS services between E-UTRAN and UTRAN is based on the

UE-involved SRNS relocation procedure.

The figure PS packet flows during as seamless as possible relocation illustrates a sig-

naling flow of E-UTRAN to UTRAN PS ISHO procedure.

Figure 17 PS packet flows during as seamless as possible relocation



30 DN0494337


Id:0900d8058093df35

Confidential

RNC anchoring for RT (and NRT in Cell_DCH state)data services

8 RNC anchoring for RT (and NRT in Cell_DCH

state) data services

When the neighboring RNC or CN nodes involved do not support the SRNS relocation,the SRNC must continue anchoring the connection.

Anchoring is supported in Nokia SRNC for CS RT services, for PS RT data services, and

for PS NRT data services in CELL_DCH state only. However, in case of PS NRT ser-

vices, there is no user-plane allocation unless the DCH scheduling over Iur, available in

feature RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements, is

enabled. For more information, see chapter Support for I-HSPA Sharing and Iur Mobility

Enhancements (RAN1759).

In case of partial support for SRNS relocation procedure for PS-NRT services (that is,

only the Cell_FACH state procedure is supported), the SRNC first switches the UE to

Cell_FACH state when:

• There is no CS service keeping UE in Cell_DCH state and inactivity of PS-NRT RB

is detected.

• CS service keeping UE in Cell_DCH state has been released and there is/are

inactive PS-NRT RAB(s) without DCH-allocation.

After the UE has been switched to Cell_FACH state and there is a Cell Update message

received from the DRNC, the SRNC initiates an SRNS relocation procedure as

described in Section Relocation for NRT PS services started by the Cell/URA Update

message from target RNC (CELL_FACH state relocation).

If the target RNC or MSC does not support SRNS relocation, the Nokia SRNC starts to

act as an anchoring point for this RRC connection (as long as there are dedicated

channel resources reserved for the UE, that is, the UE is in CELL_DCH state).

After this, the radio link(s) in the active set of the UE are located in the DRNS and all

user plane traffic between the DRNS and CN is transferred through Iur and the SRNC.

All the reserved radio interface related resources are released from the SRNS, but the

SRNC continues acting as a serving node of this RRC connection through the Iur and

DRNS. Handling of the location management procedures in the anchoring RNC

depends on a service used by the UE (RT, NRT, or RT/NRT multiservice).

Inactive NRT RB(s)/RAB(s) are not released during the anchoring caused by the

ongoing RT service. After the RT service has ended and there is no NRT-RB with a DCH

allocation, the RRC entity initiates the DSCR-procedure by sending an RRC: RRC CON-

NECTION RELEASE message to the UE and starts waiting for the Iu Release

Command (or Data Forwarding request) from the PS-CN.



















DN0494337 31

WCDMA RAN SRNS Relocation RNC anchoring for RT (and NRT in Cell_DCH state)data services

Id:0900d8058093df35

Confidential

Figure 18 Principles of the Anchoring RNC functionality

In all CELL_DCH state relocations, the handover control of SRNC makes a decision

whether to initiate the SRNS relocation or not. The decision is based on the support indi-

cator information. The following management parameters in the source RNC are used

for predefined support indication information (the "own" CN nodes and the target

RNC/CN nodes of the target RNC) of the SRNS relocation procedure:

•Serving RNC Relocation Support of neighbor RNC (NRncRelocationSupport)The serving RNC Relocation Support of the neighboring RNC contains combined

support information whether a particular neighboring RNC node and the CN nodes

connected to this RNC support SRNS relocation. If all involved network nodes do

not support the SRNS relocation procedure, the relocation procedure is not started

and the SRNC starts to act as an anchoring point for this RRC connection. If the UE

moves further to the area of a neighboring RNC supporting the SRNS Relocation

procedure during anchoring, the SRNS Relocation procedure is started after the

normal (relocation) criterion is fulfilled.

• Serving RNC Relocation Support (RelocationSupport)

The serving RNC Relocation Support contains information on whether all CN nodes

(CS and PS) connected to the SRNC support the SRNS relocation procedure.

RNC2SRNS relocation

not supported

RNC4No Iur connection.SRNS relocation

support not knownby the SRNC

RNC1(Source RNC for the

RRC connection) Anchoring RNC

RNC3

SRNS relocationsupported

Iur Connection & knownrelocation support information

Iur Connection & knownrelocation support information

UE moves to the area controlledby the DRNC RNC3. The SRNSrelocation criteria fulfilled. RNC3supports relocation procedure.

If the UE moves to the areaof RNC4:- SHO is impossible- RNC1 intiates a 'blind'

SRNS relocation attempttowards the relocation target

UE moves to the area controlledby the RNC2. The SRNS relocationcriteria fulfilled. RNC2 (DRNC) doesnot support SRNS relocationprocedure. SRNC starts actingas an Anchoring RNC.

UE mobility mangementhandled by SHO branchaddition / deletionprocedures via the Iur



32 DN0494337


Id:0900d8058093df35

Confidential

RNC anchoring for RT (and NRT in Cell_DCH state)data services

UE moves out from the neighboring RNC area of the anchoring RNC

• Hard handover attempt after an unsuccessful SHO branch addition procedure.

There can only be a limited number of neighboring RNCs configured to the SRNC.

If the UE moves to the area of an RNC not present in the neighbor RNC list of theSRNC, a soft handover branch allocation is not possible. The SRNC can try to

initiate a hard handover procedure (in this case, the involved CN nodes must

support the SRNS relocation procedure) by sending a RANAP: RELOCATION

REQUIRED message to the CN. If the target RNC does not support the relocation

procedure, the relocation attempt is rejected.

• RRC connection release due to unsuccessful SHO branch addition procedure

If the non-neighboring target RNC rejects the SRNS relocation attempt and the

criteria of an RRC connection release due to an unsuccessful SHO are fulfilled, the

RRC connection is released and a RANAP: IU RELEASE REQUEST message with

the cause value "Relocation not supported in Target RNC or Target system" is sent

to the CN.

• RNC anchoring during an emergency call

Emergency calls are allowed to continue as long as possible, even though there is

a considerable risk that the connection in question causes a lot of extra interference.

After the UE has moved out from the area of the DRNS (the last RL in the DRNS is

dropped), the DRNC sends a radio link failure indication (concerning this last RL in

the active set of the UE) and the reserved resources are released by the SRNC

(anchor). A RANAP: IU RELEASE REQUEST message with the cause value "Radio

Connection with the UE lost" is sent to the CN(s).

g If optional feature RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhance-

ments is activated, the Inter-system handovers are possible during anchoring.

8.1 Anchoring for PS NRT (and PS RT) services

The RNC anchoring for NRT service in CELL_DCH state is handled as described in

Anchoring for CS RT services. The anchoring RNC functionality is maintained for the UE

using only NRT RABs as long as there is a RAB using the DCH or HS-DSCH. When the

RRC state of the UE is changed from CELL_DCH to CELL_FACH due to inactivity of

NRT radio bearer(s), or if the criterion for service disconnection described in Anchoring

for CS RT services are fulfilled, the anchoring RNC initiates a directed signalling con-

nection re-establishment by sending an RRC: RRC CONNECTION RELEASE message

with a cause value "Directed Signalling Connection Re-establishment" to the UE

through the Iur and the DRNS.

When there is a RAB Assignment Request received from the CN, the RAB setup can be

acknowledged also during anchoring. The individual RABs or RBs allocations are not

released during anchoring. When all U-plane bearers and the signalling link are inactive,

the RRC entity shall initiate the DSCR procedure for the UE.

After reception of an RRC connection release from the source RNC, the UE transfers to

the idle mode. After this, the UE immediately initiates an RRC connection establishment

procedure and re-establishes a signalling connection to the CN through the target RNC.





DN0494337 33

WCDMA RAN SRNS Relocation HSDPA Inter-RNC Inter-Frequency Cell Change proce-dure (RAN1276)

Id:0900d805807a4dec

Confidential

9 HSDPA Inter-RNC Inter-Frequency Cell

Change procedure (RAN1276)

The optional HSDPA Inter-RNC Inter-frequency Cell Change feature (RAN1276 HSDPAIFHO) improves end user performance by maintaining the high data rate of HSDPA

service during inter-RNC mobility.

When inter-frequency measurements indicate that the strongest cell in the active set is

located under the DRNC, HSDPA Inter-RNC Inter-frequency Cell Change is executed.

HSDPA Inter-RNC Inter-frequency Cell Change utilizes SRNS relocation with UE

involvement, that is the UE is reconfigured according to the target RNC resources during

SRNS relocation. HSPA Inter-RNC Cell Change is a hard handover by nature.

Target RNC allocates resources on best effort basis, that is, even though HSDPA is pri-

marily allocated, also DCH can be allocated when HSDPA is not available. Source RNC

deletes old configuration after successful SRNS relocation. HSDPA serving cell change(serving HS-DSCH/DCH cell change) is combined with inter-RNC cell change.

Because HSUPA IFHO is not supported, if UL has been mapped to E-DCH, it is

switched to DCH before relocation. Successful Inter-RNC Inter-frequency serving cell

change is presented in figure Successful Inter-RNC Hard Handover .



34 DN0494337


Id:0900d805807a4dec

Confidential

HSDPA Inter-RNC Inter-Frequency Cell Change proce-dure (RAN1276)

Figure 19 Successful Inter-RNC Hard Handover

UE Target

RNC CN

Target-Node B

RRC: Measure-ment Report

RANAP: Re-location Required

RANAP: Re-location Request

RRC: TransportChannel

Reconfiguration

RANAP:Relocation Detect

RRC: TransportChannel

ReconfigurationComplete

NBAP: RADIOLINK RESTORE

INDICATION OR

RANAP: Re-location Complete

RANAP: lu Re-lease Command

RRC: UTRAN Mo-bility Information

RRC: UTRAN Mo-bility Information

Confirm RANAP: lu Re-lease Complete

Active serving HSPA Radio LinkE-DCH is switched to DHC

Active Drift Radio Link (SRB-DCH + ULreturn channel for HS-DSCH)

HC decides to start IFHO

RANAP:Relocation

Request Ack

RANAP: Re-location Command

NBAP:Radio Link Setup procedure (for HHO)

Request acceptable and at leastSRB-DCH + DCH 0/0 can be allocated =>

target-RNC continues SRNS relocation

RNSAP: Re-location Commit

If RNSAPprocedures

can be usedTarget RNC starts

acting as a new SRNC RANAP: Re-location Detect

New active (serving-HSPA) Radio Link L2 configuration OK (this isused for trigger Relocation

Complete when Commit notreceived)

NBAP: RL Deletion procedure (old serving-HSPA Radio Link)

Source RNC starts CM measurement

RNSAP: RL Deletion procedure (Drift RL)

NBAP: RL Deletion procedure (Drift RL)

SourceRNC

Serving -Node B



DN0494337 35

WCDMA RAN SRNS Relocation HSPA Inter-RNC Intra-Frequency Cell Change proce-dure for NRT services (RAN1515)

Id:0900d8058085eed1

Confidential

10 HSPA Inter-RNC Intra-Frequency Cell

Change procedure for NRT services

(RAN1515)

g HSPA Inter-RNC Intra-frequency Cell Change procedure can be used if the optional

HSPA over Iur (RAN1231) feature is not activated. If the HSPA over Iur feature is acti-

vated, then HS-DSCH/E-DCH flows over Iur can be setup, and the UE-not-involved

SRNS relocation can be used.

The HSPA Inter-RNC Cell Change (RAN1515) feature improves end user performance

by maintaining the high data rate HSPA service during Inter-RNC mobility for NRT ser-

vices. If the UE has any RT services, all the services are switched from HS-DSCH/E-

DCH to DCH/DCH before the Inter-RNC HHO is performed.

In HSDPA Inter-frequency Cell Change functionality, the UE-involved SRNS relocationis used also with the HSPA Inter-RNC Intra-frequency Cell Change feature.

However, there are some differences between the two procedures. When HSDPA Inter-

frequency Cell Change (RAN1276) feature is used:

• There is no need to switch from E-DCH to DCH for NRT services.

• If the UE has any RT services, all services are switched from HS-DSCH/E-DCH to

DCH/DCH before the Inter-RNC HHO is performed.

• When SRNC receives the RANAP:RELOCATION COMMAND message from the

SGSN, it removes the target-cell of the hard handover procedure from UEs Active

Set. Immediately after the target-cell has been removed, the SRNC transparently

conveys the received hard handover command to the UE for HHO execution.

Successful Inter-RNC Intra-frequency serving cell change is presented in Figure

20 Successful HSPA Inter-RNC RNC Intra-frequency Serving Cell Change.



36 DN0494337


Id:0900d8058085eed1

Confidential

HSPA Inter-RNC Intra-Frequency Cell Change proce-dure for NRT services (RAN1515)

Figure 20 Successful HSPA Inter-RNC RNC Intra-frequency Serving Cell Change

UE Serving - Node B Target - Node B Target RNC Source RNC CN

Active serving -HSPA Radio Link

Active Drift Radio Link ( SRB -DCH

:

+

UL return channel for HS -DSCH ) SRNC decides to start HO

RRC: Measurement Report

RANAP: Relocation Required

RANAP: Relocation Request

Request acceptable and at least SRB-DCH +

DCH 0/0 can be allocated = > target -RNC

continues SRNS relocation

NBAP: Radio Link Setup procedure

(for HHO )

RANAP:

:Relocation Command

RRC :

RNSAP: Relocation Commit

Target RNC starts acting as a new

SRNC

RANAP : Relocation Detect

If RNSAP procedures

can be used

RRC :

NBAP:

New active ( serving - HSPA ) Radio Link

L2 configuration OK (this is used for

trigger Relocation Complete when

Commit not received)

RANAP :

:

RANAP : Iu Release Complete

RRC :

RRC:

NBAP: RL Deletion procedure (old serving - HSPA Radio Link )

RNSAP :RL Deletion procedure

( Drift RL )

NBAP: RL Deletion procedure

(Drift RL )

RRC : Active Set Update

RRC :

Relocation Request Ack

Radio Bearer Reconfiguration

Radio Bearer Reconfiguration Complete

RADIO LINK RESTORE INDICATION

RANAP Iu Release CommandUTRAN Mobility Information

UTRAN Mobility Information Confirm

Active Set Update Complete

RANAP

Relocation Complete

RANAP: Relocation Detect



DN0494337 37

WCDMA RAN SRNS Relocation Location Services with SRNS relocation and anchoring

Id:0900d8058089b5bb

Confidential

11 Location Services with SRNS relocation and

anchoring

LCS is a feature which provides the operators with mechanisms to locate the mobilesubscribers and this way enabling the provision of location applications.

11.1 LCS in the SRNC relocation

If there is a positioning procedure going on in order to estimate the position of the UE

(e.g. in case of periodic reporting) and an SRNS relocation occurs, the positioning pro-

cedure shall be stopped in the old SRNC. If an SAS is used in the positioning procedure,

the SRNC shall send an Abort message to the SAS over the Iupc interface. After SRNS

relocation, it is under the responsibility of the MSC, MSC Server or SGSN to restart an

Iu aborted positioning procedure.

11.2 LCS in anchoring

If there is an anchoring ongoing and the SRNC does not have WLCSE elements for the

DRNC cells in the active set, the SRNC can serve the location request with the help of

the feature LCS support in Drift RNC (RAN1185).

This feature introduces positioning information transfer over the Iur in the RNSAP radio

link handling response messages: Radio Link Setup Response, Radio Link Addition

Response, Radio Link Setup Failure and Radio Link Addition Failure. These messages

allow transfer of Cell Geographical Area Identity (Cell GAI), which may be composed of

one or several coordinates. The drift RNC sends a coordinate corresponding to the

centre of the cell to the serving RNC, which can utilize the information in the responseto the location request if needed later. The centre of the cell is calculated based on the

BTS coordinates and cell mathematical model stored in the controlling RNC.



38 DN0494337


Id:0900d8058081625a

Confidential

Optional functionality

12 Optional functionality

• RAN1276: HSDPA Inter-Frequency Handover

•RAN1185: LCS Support in Drift RNC

• RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements

• RAN1515: HSPA Inter-RNC Cell Change

• RAN1231: HSPA over Iur (On Top)

• common license key with RAN1515: HSPA Inter-RNC Cell Change

• RAN2176: LTE PS Handover



DN0494337 39

WCDMA RAN SRNS Relocation Features per release

Id:0900d805808979ff

Confidential

13 Features per releaseThe following table list the features related to this functional area. The features are

arranged according to the release in which they were introduced. Note that a feature

may belong to more than one functional area.

RU20

RAN2176: LTE PS Handover (On Top)

RAN2067: LTE Interworking (On Top)

RAN1231: HSPA over Iur (On Top)

RU10

RAN833: PS UE States-URA_PCH

RAN1276: HSDPA Inter-frequency Handover

RAN1185: LCS Support in Drift RNC

RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements

RAS06

RAN1515: HSPA Inter-RNC Cell Change

RAS04

RAN1.010: RAN Radio Access Bearer Services

RAN1.011: MS Location Management with Handover procedures

RAN1.5009: WCDMA - GSM Inter System Handover

RAN1.5010: Inter Frequency HHO

Table 2 Features related to SRNS relocation



40 DN0494337


Id:0900d80580907133

Confidential

Management data for SRNS relocation

14 Management data for SRNS relocation

14.1 AlarmsThere are no alarms related to this functionality.

14.2 Counters

This section lists the counters per feature. For more information, see the Reference

Information Service in NOLS. See also RNC Counters – RNW Part in WCDMA RAN

System.

PI ID Counter name

M1009C0 RELOC COMMIT IN SOURCE RN

M1009C1 RELOC COMMIT IN TARGET RN

M1009C2 SRNS RELOC OUT PREP REQ CONTR BY MSC

M1009C3 SRNS RELOC OUT PREP REQ CONTR BY SGSN

M1009C4 SRNS RELOC OUT PREP REQ CONTR BY 2CN

M1009C5 SRNS RELOC OUT PREP SUCC CONTR BY MSC

M1009C6 SRNS RELOC OUT PREP SUCC CONTR BY SGSN

M1009C7 SRNS RELOC OUT PREP SUCC CONTR BY 2CN

M1009C8 SRNS RELOC OUT PREP UNSUCC CONTR BY MSC DUE TO

RN LAYER CAUSE


TR LAYER CAUSE


NAS CAUSE


PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C14 SRNS RELOC OUT PREP UNSUCC CONTR BY SGSN DUE TORN LAYER CAUSE

M1009C15 SRNS RELOC OUT PREP UNSUCC CONTR BY SGSN DUE TO

TR LAYER CAUSE


NAS CAUSE


PROT CAUSE


MISC CAUSE

Table 3 RAN 1.011: MS Location Management with Handover procedures

http://count_rnc_count_rnw_part.pdf/

http://count_rnc_count_rnw_part.pdf/



DN0494337 41

WCDMA RAN SRNS Relocation Management data for SRNS relocation

Id:0900d80580907133

Confidential


NON STAN CAUSE

M1009C20 SRNS RELOC OUT PREP UNSUCC CONTR BY 2CN DUE TORN LAYER CAUSE

M1009C21 SRNS RELOC OUT PREP UNSUCC CONTR BY 2CN DUE TO

TR LAYER CAUSE


NAS CAUSE


PROT CAUSE

M1009C24 SRNS RELOC OUT PREP UNSUCC CONTR BY 2CN REC

FROM SGSN DUE MISC CAUSE

M1009C25 SRNS RELOC OUT PREP UNSUCC CONTR BY 2CN DUE NON

STAN CAUSE

M1009C26 SRNS RELOC IN PREP REQ CONTR BY MSC

M1009C27 SRNS RELOC IN PREP REQ CONTR BY SGSN

M1009C28 SRNS RELOC IN PREP REQ CONTR BY 2CN

M1009C29 SRNS RELOC IN PREP SUCC CONTR BY MSC

M1009C30 SRNS RELOC IN PREP SUCC CONTR BY SGSN

M1009C31 SRNS RELOC IN PREP SUCC CONTR BY 2CN

M1009C32 SRNS RELOC IN PREP UNSUCC CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C33 SRNS RELOC IN PREP UNSUCC CONTR BY MSC DUE TO TR

CAUSE

M1009C34 SRNS RELOC IN PREP UNSUCC CONTR BY MSC DUE TO NAS

CAUSE

M1009C35 SRNS RELOC IN PREP UNSUCC CONTR BY MSC DUE TO

PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C38 SRNS RELOC IN PREP UNSUCC CONTR BY SGSN DUE TO RN

LAYER CAUSE

M1009C39 SRNS RELOC IN PREP UNSUCC CONTR BY SGSN DUE TO TR

CAUSE

M1009C40 SRNS RELOC IN PREP UNSUCC CONTR BY SGSN DUE TO

NAS CAUSE


PROT CAUSE


MISC CAUSE

PI ID Counter name

Table 3 RAN 1.011: MS Location Management with Handover procedures (Cont.)



42 DN0494337


Id:0900d80580907133

Confidential



NON STAN CAUSE

M1009C44 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO RNLAYER CAUSE

M1009C45 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO TR

CAUSE

M1009C46 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO NAS

CAUSE

M1009C47 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO

PROT CAUSE

M1009C48 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO

MISC CAUSE

M1009C49 SRNS RELOC IN PREP UNSUCC CONTR BY 2CN DUE TO NON

STAN CAUSE

M1009C50 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C51 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO RELOC

OVE TIM EXP

M1009C52 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO RELOC

PREP TIM EXP

M1009C53 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO TR

CAUSE

M1009C54 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO NAS

CAUSEM1009C55 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO PROT

CAUSE

M1009C56 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO MISC

CAUSE

M1009C57 SRNS RELOC OUT CANCEL CONTR BY MSC DUE TO NON

STAN CAUSE

M1009C58 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO RN

LAYER CAUSE

M1009C59 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO RELOC

OVE TIM EXP

M1009C60 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO RELOC

PREP TIM EXP

M1009C61 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO TR

CAUSE

M1009C62 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO NAS

CAUSE

M1009C63 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO PROT

CAUSE

M1009C64 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO MISC

CAUSE

PI ID Counter name




DN0494337 43


Id:0900d80580907133

Confidential

M1009C65 SRNS RELOC OUT CANCEL CONTR BY SGSN DUE TO NON

STAN CAUSE

M1009C66 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO RNLAYER CAUSE

M1009C67 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO RELOC

OVE TIM EXP

M1009C68 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO RELOC

PREP TIM EXP

M1009C69 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO TR

CAUSE

M1009C70 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO NAS

CAUSE

M1009C71 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO PROT

CAUSE

M1009C72 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO MISC

CAUSE

M1009C73 SRNS RELOC OUT CANCEL CONTR BY 2CN DUE TO NON

STAN CAUSE

M1009C74 SRNS RELOC DET IN TARGET RNC CONTR BY MSC

M1009C75 SRNS RELOC DET IN TARGET RNC CONTR BY SGSN

M1009C76 SRNS RELOC DET IN TARGET RNC CONTR BY 2CN

M1009C77 SRNS RELOC COMPL IN TARGET RNC CONTR BY MSC

M1009C78 SRNS RELOC COMPL IN TARGET RNC CONTR BY SGSN

M1009C79 SRNS RELOC COMPL IN TARGET RNC CONTR BY 2CN

M1009C80 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO RN LAYER

CAUSE

M1009C81 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO TR CAUSE

M1009C82 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO NAS

CAUSE

M1009C83 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO PROT

CAUSE

M1009C84 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO MISC

CAUSE

M1009C85 SRNS RELOC IU REL OUT CONTR BY MSC DUE TO NON

STAN CAUSE

M1009C86 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO RN

LAYER CAUSE

M1009C87 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO TR

CAUSE

M1009C88 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO NAS

CAUSE

M1009C89 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO PROT

CAUSE

PI ID Counter name




44 DN0494337


Id:0900d80580907133

Confidential


M1009C90 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO MISC

CAUSE

M1009C91 SRNS RELOC IU REL OUT CONTR BY SGSN DUE TO NONSTAN CAUSE

M1009C92 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO RN LAYER

CAUSE

M1009C93 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO TR CAUSE

M1009C94 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO NAS

CAUSE

M1009C95 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO PROT

CAUSE

M1009C96 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO MISC

CAUSE

M1009C97 SRNS RELOC IU REL OUT CONTR BY 2CN DUE TO NON STAN

CAUSE

M1009C98 SRNS RELOC IU REL IN CONTR BY MSC DUE TO RN LAYER

CAUSE

M1009C99 SRNS RELOC IU REL IN CONTR BY MSC DUE TO TR CAUSE

M1009C100 SRNS RELOC IU REL IN CONTR BY MSC DUE TO NAS CAUSE

M1009C101 SRNS RELOC IU REL IN CONTR BY MSC DUE TO PROT

CAUSE

M1009C102 SRNS RELOC IU REL IN CONTR BY MSC DUE TO MISC CAUSE

M1009C103 SRNS RELOC IU REL IN CONTR BY MSC DUE TO NON STANCAUSE

M1009C104 SRNS RELOC IU REL IN CONTR BY SGSN DUE TO RN LAYER

CAUSE

M1009C105 SRNS RELOC IU REL IN CONTR BY SGSN DUE TO TR CAUSE

M1009C106 SRNS RELOC IU REL IN CONTR BY SGSN DUE TO NAS

CAUSE

M1009C107 SRNS RELOC IU REL IN CONTR BY SGSN DUE TO PROT

CAUSE

M1009C108 SRNS RELOC IU REL IN CONTR BY SGSN DUE TO MISC

CAUSE

M1009C109 SRNS RELOC IU REL IN CONTR BY SGSNDUE TO NON STAN

CAUSE

M1009C110 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO RN LAYER

CAUSE

M1009C111 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO TR CAUSE

M1009C112 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO NAS CAUSE

M1009C113 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO PROT

CAUSE

M1009C114 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO MISC CAUSE

PI ID Counter name




DN0494337 45


Id:0900d80580907133

Confidential

M1009C115 SRNS RELOC IU REL IN CONTR BY 2CN DUE TO NON STAN

CAUSE

PI ID Counter name

M1009C116 INTER RNC HHO COMMIT IN SOURCE RNC

M1009C117 INTER RNC HHO COMMIT IN TARGET RNC

M1009C118 INTER RNC HHO OUT PREP REQ CONTR BY MSC

M1009C119 INTER RNC HHO OUT PREP REQ CONTR BY SGSN

M1009C120 INTER RNC HHO OUT PREP REQ CONTR BY 2CN

M1009C121 INTER RNC HHO OUT PREP SUCC CONTR BY MSC

M1009C122 INTER RNC HHO OUT PREP SUCC CONTR BY SGSN

M1009C123 INTER RNC HHO OUT PREP SUCC CONTR BY 2CN

M1009C124 INTER RNC HHO OUT PREP UNSUCC CONTR BY MSC DUE

TO RN LAYER CAUSE


TO TR LAYER CAUSE


TO NAS CAUSE


TO PROT CAUSE


TO MISC CAUSE


TO NON STAN CAUSE

M1009C130 INTER RNC HHO OUT PREP UNSUCC CONTR BY SGSN DUE

TO RN LAYER CAUSE


TO TR LAYER CAUSE


TO NAS CAUSE


TO PROT CAUSE


TO MISC CAUSE


TO NON STAN CAUSE

M1009C136 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TO

RN LAYER CAUSE


TR LAYER CAUSE

Table 4 RAN 1.5010: Inter Frequency HHO

PI ID Counter name




46 DN0494337


Id:0900d80580907133

Confidential



NAS CAUSE

M1009C139 INTER RNC HHO OUT PREP UNSUCC CONTR BY 2CN DUE TOPROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C142 INTER RNC HHO IN PREP REQ CONTR BY MSC

M1009C143 INTER RNC HHO IN PREP REQ CONTR BY SGSN

M1009C144 INTER RNC HHO IN PREP REQ CONTR BY 2CN

M1009C145 INTER RNC HHO IN PREP SUCC CONTR BY MSC

M1009C146 INTER RNC HHO IN PREP SUCC CONTR BY SGSN

M1009C147 INTER RNC HHO IN PREP SUCC CONTR BY 2CN

M1009C148 INTER RNC HHO IN PREP UNSUCC CONTR BY MSC DUE TO

RN LAYER CAUSE


TR LAYER CAUSE


NAS CAUSE


PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C154 INTER RNC HHO IN PREP UNSUCC CONTR BY SGSN DUE TO

RN LAYER CAUSE


TR LAYER CAUSE


NAS CAUSE


PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C160 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TO

RN LAYER CAUSE


TR LAYER CAUSE

PI ID Counter name

Table 4 RAN 1.5010: Inter Frequency HHO (Cont.)



DN0494337 47


Id:0900d80580907133

Confidential


NAS CAUSE

M1009C163 INTER RNC HHO IN PREP UNSUCC CONTR BY 2CN DUE TOPROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C166 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C167 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO

RELOC OVE TIM EXP


RELOC PREP TIM EXP

M1009C169 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO TR

CAUSE

M1009C170 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO NAS

CAUSE


PROT CAUSE

M1009C172 INTER RNC HHO OUT CANCEL CONTR BYMSC DUE TO MISC

CAUSE

M1009C173 INTER RNC HHO OUT CANCEL CONTR BY MSC DUE TO NON

STAN CAUSEM1009C174 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO RN

LAYER CAUSE

M1009C175 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO

RELOC OVE TIM EXP


RELOC PREP TIM EXP

M1009C177 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO TR

CAUSE

M1009C178 INTER RNC HHO OUT CANCEL CONTR BY SGSN DUE TO NAS

CAUSE


PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C182 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO RN

LAYER CAUSE

M1009C183 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO

RELOC OVE TIM EXP

PI ID Counter name




48 DN0494337


Id:0900d80580907133

Confidential


M1009C184 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO

RELOC PREP TIM EXP

M1009C185 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO TRCAUSE

M1009C186 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO NAS

CAUSE

M1009C187 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO PROT

CAUSE

M1009C188 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO MISC

CAUSE

M1009C189 INTER RNC HHO OUT CANCEL CONTR BY 2CN DUE TO NON

STAN CAUSE

M1009C190 INTER HHO DETECT IN TARGET RNC CONTR BY MSC

M1009C191 INTER HHO DET IN TARGET RNC CONTR BY SGSN

M1009C192 INTER HHO DETECT IN TARGET RNC CONTR BY 2CN

M1009C193 INTER HHO COMPL IN TARGET RNC CONTR BY MSC

M1009C194 INTER HHO COMPL IN TARGET RNC CONTR BY SGSN

M1009C195 INTER HHO COMPL IN TARGET RNC CONTR BY 2CN

M1009C196 INTER HHO IU REL OUT CONTR BY MSC DUE TO RN LAYER

CAUSE

M1009C197 INTER HHO IU REL OUT CONTR BY MSC DUE TO TR CAUSE

M1009C198 INTER HHO IU REL OUT CONTR BY MSC DUE TO NAS CAUSE

M1009C199 INTER HHO IU REL OUT CONTR BY MSC DUE TO PROT

CAUSE

M1009C200 INTER HHO IU REL OUT CONTR BY MSC DUE TO MISC

CAUSE

M1009C201 INTER HHO IU REL OUT CONTR BY MSC DUE TO NON STAN

CAUSE

M1009C202 INTER HHO IU REL OUT CONTR BY SGSN DUE TO RN LAYER

CAUSE

M1009C203 INTER HHO IU REL OUT CONTR BY SGSN DUE TO TR CAUSE

M1009C204 INTER HHO IU REL OUT CONTR BY SGSN DUE TO NAS

CAUSE

M1009C205 INTER HHO IU REL OUT CONTR BY SGSN DUE TO PROT

CAUSE

M1009C206 INTER HHO IU REL OUT CONTR BY SGSN DUE TO MISC

CAUSE

M1009C207 INTER HHO IU REL OUT CONTR BY SGSN DUE TO NON STAN

CAUSE

M1009C208 INTER HHO IU REL OUT CONTR BY 2CN DUE TO RN LAYER

CAUSE

M1009C209 INTER HHO IU REL OUT CONTR BY 2CN DUE TO TR CAUSE

PI ID Counter name




DN0494337 49


Id:0900d80580907133

Confidential

M1009C210 INTER HHO IU REL OUT CONTR BY 2CN DUE TO NAS CAUSE

M1009C211 INTER HHO IU REL OUT CONTR BY 2CN DUE TO PROT

CAUSE

M1009C212 INTER HHO IU REL OUT CONTR BY 2CN DUE TO MISC CAUSE

M1009C213 INTER HHO IU REL OUT CONTR BY 2CN DUE TO NON STAN

CAUSE

M1009C214 INTER HHO IU REL IN CONTR BY MSC DUE TO RN LAYER

CAUSE

M1009C215 INTER HHO IU REL IN CONTR BY MSC DUE TO TR CAUSE

M1009C216 INTER HHO IU REL IN CONTR BY MSC DUE TO NAS CAUSE

M1009C217 INTER HHO IU REL IN CONTR BY MSC DUE TO PROT CAUSE

M1009C218 INTER HHO IU REL IN CONTR BY MSC DUE TO MISC CAUSE

M1009C219 INTER HHO IU REL IN CONTR BY MSC DUE TO NON STAN

CAUSE

M1009C220 INTER HHO IU REL IN CONTR BY SGSN DUE TO RN LAYER

CAUSE

M1009C221 INTER HHO IU REL IN CONTR BY SGSN DUE TO TR CAUSE

M1009C222 INTER HHO IU REL IN CONTR BY SGSN DUE TO NAS CAUSE

M1009C223 INTER HHO IU REL IN CONTR BY SGSN DUE TO PROT CAUSE

M1009C224 INTER HHO IU REL IN CONTR BY SGSN DUE TO MISC CAUSE

M1009C225 INTER HHO IU REL IN CONTR BY SGSN DUE TO NON STAN

CAUSE

M1009C226 INTER HHO IU REL IN CONTR BY 2CN DUE TO RN LAYER

CAUSE

M1009C227 INTER HHO IU REL IN CONTR BY 2CN DUE TO TR CAUSE

M1009C228 INTER HHO IU REL IN CONTR BY 2CN DUE TO NAS CAUSE

M1009C229 INTER HHO IU REL IN CONTR BY 2CN DUE TO PROT CAUSE

M1009C230 INTER HHO IU REL IN CONTR BY 2CN DUE TO MISC CAUSE

M1009C231 INTER HHO IU REL IN CONTR BY 2CN DUE TO NON STAN

CAUSE

M1009C232 STA FORW DATA IN SOURCE RNC ON IUR

M1009C233 FORW SRNS CON OUT

M1009C234 FORW SRNS CON IN

M1009C235 INTER SYST HHO OUT PREP REQ CONTR BY MSC

M1009C236 INTER SYST HHO OUT PREP SUCC CONTR BY MSC

M1009C237 INTER SYST HHO OUT PREP UNSUCC CONTR BY MSC DUE

TO RN LAYER CAUSE

M1009C238 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO TR

CAUSE

PI ID Counter name




50 DN0494337


Id:0900d80580907133

Confidential


M1009C239 INTER SYST HHO OUT PREP UNSUCC CONTR BY MSC DUE

TO NAS CAUSE

M1009C240 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TOPROT CAUSE

M1009C241 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO

MISC CAUSE

M1009C242 INTER SYST HHO PREP UNSUCC CONTR BY MSC DUE TO

NON STAN CAUSE

M1009C243 INTER SYST HHO IN PREP REQ CONTR BY MSC

M1009C244 INTER SYST HHO IN PREP SUCC CONTR BY MSC

M1009C245 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TO

RN LAYER CAUSE

M1009C246 INTER SYST HHO IN PREP UNSUCC CONTR BY MSC DUE TOTR CAUSE


NAS CAUSE


PROT CAUSE


MISC CAUSE


NON STAN CAUSE

M1009C251 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C252 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO

RELOC OVE TIM EXP


RELOC PREP TIMEXP

M1009C254 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO TR

CAUSE

M1009C255 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO NAS

CAUSE


PROT CAUSE


MISC CAUSE

M1009C258 INTER SYST HHO OUT CANCEL CONTR BY MSC DUE TO NON

STAN CAUSE

M1009C259 INTER SYST COMPL IN TARGET RNC CONTR BY MSC

M1009C260 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C261 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO TR

CAUSE

PI ID Counter name




DN0494337 51


Id:0900d80580907133

Confidential

M1009C262 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO NAS

CAUSE

M1009C263 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO PROTCAUSE

M1009C264 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO MISC

CAUSE

M1009C265 INTER SYST HHO IU REL OUT CONTR BY MSC DUE TO NON

STAN CAUSE

M1009C266 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO RN

LAYER CAUSE

M1009C267 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO TR

CAUSE

M1009C268 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO NAS

CAUSE

M1009C269 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO PROT

CAUSE

M1009C270 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO MISC

CAUSE

M1009C271 INTER SYST HHO IU REL IN CONTR BY MSC DUE TO NON

STAN CAUSE

PI ID Counter name

M1009C272 STA FORW DATA IN SOURCE RNC ON IU

M1009C273 SRNS CON REQ IN

M1009C274 SRNS CON RES OUT

M1009C275 SRNS DATA FRW COM IN

Table 5 RAN 1.5010: Inter Frequency HHO/ RAN 1.5009 : WCDMA - GSM Inter

System Handover

PI ID Counter name

M1001C13 RRC ACTIVE REL DUE TO SRNC RELOC

M1001C62 NUMBER OF SRNC RELOCATION ATTEMPTS

M1001C63 NUMBER OF UNSUCCESSFUL SRNC RELOCATION

ATTEMPTS

M1001C64 NUMBER OF INTER-RNC INTRA FREQ HHO ATTEMPTS

M1001C65 NUMBER OF UNSUCCESSFUL INTER RNC INTRA FREQ HHO

ATTEMPTS

M1001C143 RAB ACTIVE RELEASES DUE TO SRNC RELOC FOR CS

VOICE

Table 6 RAN 1.010 : RAN Radio Access Bearer Services

PI ID Counter name




52 DN0494337


Id:0900d80580907133

Confidential


14.3 Parameters

This section introduces management parameters that can be used to control the

function of SRNS relocation.

For more information, see WCDMA RAN Radio Network Configuration Parameters in

WCDMA RAN System Library. See also the Reference Information Service in NOLS

M1001C151 RAB ACTIVE RELEASES DUE TO SRNC RELOC FOR CS DATA

CONV

M1001C153 RAB ACTIVE RELEASES DUE TO SRNC RELOC FOR CS DATASTREAM

M1001C167 RAB ACTIVE RELEASES DUE TO SRNC RELOC FOR PS DATA

CONV


STREAM


INTERA


BACKG

PI ID Counter name

Table 6 RAN 1.010 : RAN Radio Access Bearer Services (Cont.)

Parameter name Modifiable/system-defined Object

T RelocPrep Modifiable RNCT RelocOverall Modifiable RNC

T DATAfwd Modifiable RNC

Time supervision for releasing Iu-PS

connection

Modifiable RNC

Serving RNC Relocation Support Modifiable RNC

Serving RNC Relocation Support of

neighbour RNC

Modifiable RNC

Cell_FACH state Serving RNC Reloca-

tion Support (CellFACHrelocSupport)

Modifiable RNC

Cell_FACH state Serving RNC Reloca-tion Support ((CellFACHnRncReloc-

Support

Modifiable RNC

Usage of Relocation Commit proce-

dure in inter RNC HHO

Modifiable WCELL

Table 7 RAN 1.011: MS Location Management with Handover procedures





DN0494337 53


Id:0900d80580907133

Confidential

Parameter name Modifiable/system-defined Object

DCH Scheduling Over Iur (DCH-

ScheOverIur)

Modifiable RNC

ISHO In Iur Mobility (ISHOInIur-

Mobility)

Modifiable RNC

IBTS Sharing (IBTSSharing) Modifiable IUR

Table 8 RAN1759: Support for I-HSPA Sharing and Iur Mobility Enhancements



WCDMA RAN SRNS RelocationLimitations and restrictions

15 Limitations and restrictionsThis functionality has no limitations or restrictions.

wcdma ran srns relocation

Documents