TR 125 931 - V5.3.0

ETSI TR 125 931

V5.3.0

(2006-03)

Technical Report

Universal Mobile Telecommunications System (UMTS);

UTRAN functions, examples on signalling procedures

(3GPP TR 25.931 version 5.3.0 Release 5)

3GPP TR 25.931 version 5.3.0 Release 5 1

Reference

RTR/TSGR-0325931v530

Keywords

UMTS

ETSI TR 125 931 V5.3.0 (2006-03)

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la

Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from: http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.

Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2006.

All rights reserved.

DECT

TM

, PLUGTESTS

TM and UMTS

TM are Trade Marks of ETSI registered for the benefit of its Members.

TIPHON

TM

and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.

3GPP

TM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.

ETSI

3GPP TR 25.931 version 5.3.0 Release 5 2 ETSI TR 125 931 V5.3.0 (2006-03)

Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in

respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ( http://webapp.etsi.org/IPR/home.asp

).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword

This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or

GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp

.

ETSI


Contents

Intellectual Property Rights ................................................................................................................................2

Foreword.............................................................................................................................................................2

Foreword.............................................................................................................................................................5

1 Scope ........................................................................................................................................................6

2 References ................................................................................................................................................6

3 Definitions, abbreviations and notation....................................................................................................6

3.1 Definitions ..........................................................................................................................................................6

3.2 Abbreviations .....................................................................................................................................................7

3.3 Notation for the signalling procedures ...............................................................................................................9

4 UTRAN and UE protocol Architecture..................................................................................................10

Architecture .......................................................................................................................................10

4.2

4.3

4.4

4.5

RANAP Procedures & Messages .....................................................................................................................10

SABP Procedures & Messages.........................................................................................................................11

RNSAP Procedures & Messages......................................................................................................................11

NBAP Procedures & Messages ........................................................................................................................12

4.6 ALCAP.............................................................................................................................................................14

4.6.1 Q2630.2 (Q.AAL 2)....................................................................................................................................14

4.7

4.8

RRC Procedures & Messages...........................................................................................................................14

BMC Procedures & Messages..........................................................................................................................15

4.9

4.10

4.11

DCH Frame Protocol Messages .......................................................................................................................16

DSCH Frame Protocol Messages .....................................................................................................................16

USCH Frame Protocol Messages .....................................................................................................................16

5 UTRAN Signalling Procedures ..............................................................................................................16

6 Procedures not related to a specific UE (global procedures)..................................................................17

6.1 System Information Broadcasting ....................................................................................................................17

Broadcast ....................................................................................................................................17

7 Procedures related to a specific UE........................................................................................................18

7.1 Paging...............................................................................................................................................................18

7.1.1 Paging for a UE in RRC Idle Mode and RRC connected mode (CELL_PCH and URA_PCH states).......18

7.1.2

7.2

Paging for a UE in RRC Connected Mode (CELL_DCH and CELL_FACH states) .................................19

NAS Signalling Connection Establishment......................................................................................................20

7.3

7.3.3

7.4

7.4.2

RRC Connection Establishment .......................................................................................................................20

Establishment ....................................................................................................................................20

Establishment ......................................................................................................................22

DCH Establishment with Pre-emption........................................................................................................22

RRC Connection Release .................................................................................................................................24

Release ..............................................................................................................................................24

Common Transport Channel Release .........................................................................................................25

7.5

7.5.1.1

7.5.1.2

7.6

7.6.1

7.6.2

7.6.3

7.6.4

7.7

7.7.1

7.7.2

7.7.4

7.8

7.8.1

7.8.1.1

RRC Connection Re-establishment ..................................................................................................................25

Re-establishment ...............................................................................................................................25

RRC connection Re-establishment (Anchor approach) – DCH Re-establishment................................25

RRC Connection Re-establishment with SRNC Relocation - DCH Re-establishment .........................27

Radio Access Bearer Establishment .................................................................................................................28

DCH - DCH Establishment - Synchronised................................................................................................28

DCH - DCH Establishment - Unsynchronised ...........................................................................................30

RACH/FACH - DCH Establishment ..........................................................................................................32

RACH/FACH - RACH/FACH Establishment ............................................................................................33

Radio Access Bearer Release ...........................................................................................................................34

DCH - DCH Release - Synchronised ..........................................................................................................34

DCH - DCH Release - Unsynchronised......................................................................................................36

RACH/FACH - RACH/FACH Release ......................................................................................................37

Radio Access Bearer Modification...................................................................................................................38

DCCH on DCH - Synchronised ..................................................................................................................38

Synchronised DCH modification, Bandwidth increase.........................................................................39

ETSI


7.8.1.2

7.8.2

7.9.1

7.9.2

7.10

7.10.1

7.10.2

7.10.3

7.10.4

7.10.5

7.10.5.1

7.10.5.2

Synchronised DCH modification, Bandwidth decrease ........................................................................41

DCCH on RACH/FACH ............................................................................................................................42

Reconfiguration ...................................................................................................................43

Physical Channel Reconfiguration (DCH)..................................................................................................43

Physical Channel Reconfiguration (CRNC Controlled) .............................................................................45

Soft Handover (FDD) .......................................................................................................................................45

Radio Link Addition (Branch Addition) .....................................................................................................46

Radio link Deletion (Branch Deletion) .......................................................................................................47

Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously) .....................................48

DSCH Mobility Procedure in Soft Handover (Moving DSCH within the Active Set) ...............................49

HS-DSCH Mobility Procedures..................................................................................................................50

Intra-Node B synchronised serving HS-DSCH cell change ..................................................................50

Inter-Node B (intra DRNC) synchronised serving HS-DSCH cell change ...........................................51

7.11.1

7.11.1.1

7.11.1.2

7.11.1.3

7.11.1.3.1

7.11.1.3.2

7.11.2

7.11.2.1

7.11.2.2

7.11.2.3

7.11.2.4

7.12.1

7.12.2

Handover .................................................................................................................................................52

Backward Hard Handover ..........................................................................................................................52

Hard Handover via Iur (DCH State)......................................................................................................52

Hard Handover with switching in the CN (UE connected to two CN nodes, DCH state).....................56

Inter-Node B synchronised serving HS-DSCH cell change at hard handover ......................................59

Inter-Node B (intra DRNC) synchronised serving HS-DSCH cell change at hard handover..........59

Inter-Node B (inter DRNC) synchronised serving HS-DSCH cell change at hard handover..........62

Forward Hard Handover .............................................................................................................................64

Cell Update with SRNS relocation........................................................................................................64

Cell Update via Iur without SRNS relocation .......................................................................................65

Cell Update via Iur without SRNS relocation (with C-RNTI reallocation) ..........................................66

Cell Update via Iur with USCH/DSCH, without SRNS relocation.......................................................66

Update .....................................................................................................................................................68

Inter-RNS URA Update with SRNS Relocation.........................................................................................68

Inter-RNS URA Update via Iur without SRNS relocation .........................................................................69

7.12.3 SRNS Relocation (UE connected to two CN nodes) ..................................................................................70

7.13 HO & Cell Reselection between UTRAN and GSM/BSS ...............................................................................72

⇒ GSM/BSS................................................................................................................................72

7.13.1.2

⇒ GSM/BSS ..........................................................................................................................72

Service Based Intersystem Handover....................................................................................................74

7.14

7.14.1

7.14.1.1

Retry .......................................................................................................................................75

⇒ UTRAN................................................................................................................................76

⇒ UMTS Cell Reselection ..............................................................................................................77

⇒ GPRS Cell Reselection, UE Initiated.........................................................................................77

⇒ GPRS Cell Reselection, Network Initiated ................................................................................78

Transport Channel Reconfiguration (DCH to DCH)........................................................................................78

Synchronised Transport Channel Reconfiguration .....................................................................................78

Synchronised Reconfiguration, Q.2630.2 modification procedure not used .........................................79

7.14.1.2

7.14.1.3

7.14.2

7.14.2.1

7.14.2.2

7.14.2.3

7.15.1

7.15.2

7.16

7.17

7.17.1

7.17.2

7.18

7.18.2

7.18.3

Synchronised Reconfiguration, Bandwidth Increase with Q.2630.2 modification procedure...............80

Synchronised Reconfiguration, Bandwidth Decrease with Q.2630.2 modification procedure .............82

Unsynchronised Transport Channel Reconfiguration .................................................................................83

Unsynchronised Reconfiguration, Q.2630.2 modification procedure not used.....................................83

Unsynchronised Reconfiguration, Bandwidth Increase with Q.2630.2 modification procedure ..........84

Unsynchronised Reconfiguration, Bandwidth Decrease with Q.2630.2 modification procedure .........85

Transfer .................................................................................................................................................86

Uplink Direct Transfer................................................................................................................................86

Downlink Direct Transfer ...........................................................................................................................87

Downlink Power Control [FDD] ......................................................................................................................87

Shared Channels Configuration and Capacity Allocation ................................................................................88

USCH/DSCH Configuration and Capacity Allocation [TDD] ...................................................................88

HS-DSCH Configuration and Capacity Allocation ....................................................................................90

Channel and Mobile State Switching on Iur.....................................................................................................91

Description ....................................................................................................................................91

Switching from Cell_FACH to Cell_DCH State ........................................................................................91

Switching from Cell_DCH to Cell_FACH State ........................................................................................93

Annex A (informative): Change History ..............................................................................................96

History ..............................................................................................................................................................97

ETSI


Foreword

This Technical Report (TR) has been produced by the 3 rd

Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal

TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:

Version x.y.z where: x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.

ETSI


1 Scope

The present document describes the UTRAN functions by means of signalling procedure examples (Message Sequence

Charts). The signalling procedure examples show the interaction between the UE, the different UTRAN nodes and the

CN to perform system functions. This gives an overall understanding of how the UTRAN works in example scenarios.

[5]

[6]

[7]

[8]

[1]

[3]

[4]

[9]

[10]

[11]

[12]

[13]

2 References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

•

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

•

For a specific reference, subsequent revisions do not apply.

•

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same

Release as the present document.

[14]

[15]

3GPP TR 25.990: "Vocabulary for UTRAN". [2] TS 25.401: "UTRAN Overall Description".

3GPP TS 25.413: "UTRAN Iu Interface RANAP Signalling".

3GPP TS 25.423: "UTRAN Iur Interface RNSAP Signalling".

3GPP TS 25.433: "UTRAN Iub Interface NBAP Signalling".

3GPP TR 25.832: "Manifestations of Handover and SRNS Relocation".

3GPP TS 25.301: "Radio Interface Protocol Architecture".

3GPP TS 25.331: "RRC Protocol Specification".

3GPP TS 25.419: "UTRAN Iu Interface: Service Area Broadcast Protocol SABP".

3GPP TS 25.324: "Radio Interface for Broadcast/Multicast Services".

3GPP TR 25.925: "Radio Interface for Broadcast/Multicast Services".

3GPP TS 23.041: "Technical realisation of Cell Broadcast Service (CBS)".

3GPP TS 25.425: "UTRAN Iur Interface User Plane Protocols for Common Transport Channel

Data Streams".

3GPP TS 25.435: "UTRAN Iub Interface User Plane Protocols for Common Transport Channel

Data Streams".

3GPP TS 25.427: "UTRAN Iub/Iur Interface User Plane Protocol for DCH Data Streams".

3 Definitions, abbreviations and notation

3.1 Definitions

For the purposes of the present document, the terms and definitions given in [1], [2] and [4] apply.

ETSI


3.2 Abbreviations

For the purposes of the present document the following abbreviations apply:

NOTE: More extensive abbreviations on UMTS are provided in [1].

AAL2 ATM Adaptation Layer type 2

ACK Acknowledgement

AICH

ALCAP

Acquisition Indicator Channel

Access Link Control Application Part

ATM

BCCH

BCFE

BER

BLER

BSS

BSSMAP

CCPCH

CFN

CPICH

Asynchronous Transfer Mode

Broadcast Control Channel

Broadcast Control Functional Entity

Bit Error Rate

Block Error Rate

Base Station Sub-system

Base Station System Management Application Part

Common Control Physical Channel

Connection Frame Number

Common Pilot Channel

ETSI TR 125 931 V5.3.0 (2006-03)

DCA

DCCH

DCFE

Dynamic Channel Allocation

Dedicated Control Channel

Dedicated Control Functional Entity

DL Downlink

DPCCH Dedicated Physical Control Channel

DPCH Dedicated Physical Channel

DTCH

FAUSCH

FDD

FFS

Dedicated Traffic Channel

Fast Uplink Signalling Channel

Frequency Division Duplex

For Further Study

HS-DSCH

HS-PDSCH

HS-SCCH

High Speed Downlink Shared Channel

High Speed Physical Downlink Shared Channel

High Speed Shared Control Channel

ID Identifier

IMEI

IMSI

International Mobile Equipment Identity

International Mobile Subscriber Identity

ISCP Interference on Signal Code Power

ETSI

3GPP TR 25.931 version 5.3.0 Release 5

MAC

MAC-hs

MCC

Medium Access Control

8

Medium Access Control for HS-DSCH

Mobile Country Code

RNC

RNS

RNSAP

RNTI

RRC

RSCP

RSSI

SCCP

SCFE

SGSN

SHCCH

SIR

MSC

NAS

NBAP

Mobile services Switching Center

Non Access Stratum

Node B Application Protocol

NW Network

O Optional

ODMA

PCCH

Opportunity Driven Multiple Access

Paging Control Channel

PDCP

PDSCH

PDU

PLMN

PNFE

PRACH

Packet Data Convergence Protocol

Physical Downlink Shared Channel

Protocol Data Unit

Public Land Mobile Network

Paging and Notification control Functional Entity

Physical Random Access CHannel

P-TMSI

PUSCH

QoS

RAB

RACH

RANAP

RFE

Packet Temporary Mobile Subscriber Identity

Physical Uplink Shared Channel

Quality of Service

Radio Access Bearer

Random Access CHannel

Radio Access Network Application Part

Routing Functional Entity

Radio Network Controller

Radio Network Subsystem

Radio Network Subsystem Application Part

Radio Network Temporary Identifier

Radio Resource Control

Received Signal Code Power

Received Signal Strength Indicator

Signalling Connection Control Part

Shared Control Function Entity

Serving GPRS Support Node

Shared Control Channel

Signal to Interference Ratio

TDD Time Division Duplex

TFCI

TFCS

TFS

TME

Transport Format Combination Indicator

Transport Format Combination Set

Transport Format Set

Transfer Mode Entity

TMSI Temporary Mobile Subscriber Identity

Tr Transparent

ETSI

ETSI TR 125 931 V5.3.0 (2006-03)


Tx Transmission

UARFCN UMTS Absolute Radio Frequency Channel Number

UL Uplink

UMTS Universal Mobile Telecommunication System

UNACK Unacknowledgement

U-RNTI UTRAN-RNTI

USCH Uplink Shared Channel

UTRAN UMTS Terrestrial Radio Access Network

ETSI TR 125 931 V5.3.0 (2006-03)

3.3 Notation for the signalling procedures

Complex signalling procedures may involve several protocols in different nodes.

In order to facilitate the understanding of these procedures, the following rules in the drawing of Message Sequence

Chart (MSC) are applied:

−

Messages are always exchanged between nodes, i.e. the sender and the receiver of a message are nodes and not single protocol entities;

−

The protocol entity inside a node that is sending/receiving a message is represented by means of an ellipse, containing the protocol entity name;

−

Each message is numbered, so that a numbered list with explanations can be added below the figure;

−

Message parameters may be specified as shown in Figure 1 only when required for a clear understanding of the procedures;

−

Explicit signalling is represented by means of continuos arrows;

−

Inband signalling is represented by means of dotted arrows;

−

A description of the relevant actions may be included as shown in Figure 1;

−

The Setup and Release of Iub/Iur and Iu Data Transport Bearer with the ALCAP protocol is represented as shown in Figure 1;

−

The transport channel used by the MAC protocol or the logical channel used by the RLC and RRC protocols may be indicated before the message name as shown in figure 1

U E N od e B

D rift R N S

M A C

R RC

N B A P

N od e B

S e rvin g R N S

R N C

D rift

R N C

S erv in g

C N

1 . R A C H : M essa g e

[P a ra m e te rs]

A ction d escrip tion

M A C

N B A P

4 . M essa g e

[P a ra m eters]

2 . C C C H : M essa g e

[P a ra m eters]

3 . M essag e

[P a ra m e ters]

N B A P

R N S A P

6 . M essa g e


A L C A P Iu b B ea rer S etu p /R elea se A L C A P Iu r B ea rer S etu p

R R C

N B A P

R A N A P

5 . M essag e


R N S A P

R A N A P

Figure 1: Example of signalling procedure notation

ETSI


4

10 ETSI TR 125 931 V5.3.0 (2006-03)

UTRAN and UE protocol Architecture

For a detailed description of the Protocol Architecture and the Radio Protocol Architecture for the UTRAN and the UE refer to [2] and [7] respectively.

4.2 RANAP Procedures & Messages

For a detailed description of RANAP procedures and messages refer to [3]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

Table 1

Message Name

Direct Transfer

UTRAN Procedure

Uplink Direct Transfer

Downlink Direct Transfer

Initial UE Message

Iu Release Command

Iu Release Complete

Paging

NAS Signalling Connection Establishment

RRC Connection Release

Hard HO with switching in the CN

SRNS Relocation

UTRAN

⇒

GSM/BSS handover



SRNS Relocation

UTRAN

⇒

GSM/BSS handover

Paging for a UE in RRC Idle Mode

Paging for a UE in RRC Connected Mode

Radio Access Bearer Assignment Request Radio Access Bearer Establishment

Radio Access Bearer Release

Radio Access Bearer Modification

Radio Access Bearer Assignment

Response

Relocation Command

Relocation Complete

Relocation Detect

Relocation Failure

Relocation Request

Relocation Request Acknowledge

Relocation Required

RAB Release Request

Radio Access Bearer Establishment




SRNS Relocation

UTRAN

⇒

GSM/BSS handover


SRNS Relocation

GSM/BSS handover

⇒

UTRAN


SRNS Relocation

GSM/BSS handover

⇒

UTRAN

SRNS Relocation


SRNS Relocation

GSM/BSS handover

⇒

UTRAN


SRNS Relocation

GSM/BSS handover

⇒

UTRAN


SRNS Relocation

UTRAN

⇒

GSM/BSS handover

RRC Connection Establishment

Direction

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

RNC

⇒

CN

CN

⇒

RNC

RNC

⇒

CN

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

CN

⇒

RNC

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

RNC

⇒

CN

ETSI


4.3 SABP Procedures & Messages

For a detailed description of SABP procedures and messages refer to [9]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

Message Name

Write-replace

Write-replace Complete

Write-Replace Failure

Table 2

UTRAN Procedure

Service Area Broadcast



Direction

CN

⇒

RNC

RNC

⇒

CN

RNC

⇒

CN

4.4 RNSAP Procedures & Messages

For a detailed description of RNSAP procedures and messages refer to [4]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

ETSI


Table 3

Message Name

Common Transport Channel

Resources Release


Resources Initialisation Request


Resources Initialisation

Response

DL Power Control Request

Downlink Signalling Transfer

Request

Radio Link Deletion Request

Radio Link Deletion Response

Radio Link Failure Indication

Radio Link Reconfiguration

Request


Commit


Prepare


Ready


Response

Radio Link Restore Indication

Radio Link Setup Request

Radio Link Setup Response

Relocation Commit

Cell Update

Cell Update

Cell Update

UTRAN Procedure

Downlink Power Control

RRC Connection Re-establishment

URA Update


Soft Handover

Hard Handover


Soft Handover

Hard Handover

Hard Handover



Physical Channel Reconfiguration

Transport Channel Reconfiguration




















Soft Handover

Hard Handover

Channel and Mobile State Switching on Iur


Hard Handover

USCH/DSCH Configuration and Capacity Allocation [TDD]


Hard Handover


SRNS Relocation URA Update

Uplink Signalling Transfer

Indication


URA Update

Direction

SRNC

⇒

DRNC

SRNC

⇒

DRNC

DRNC

⇒

SRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

SRNC

⇒

DRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

Source RNC

⇒

Target RNC

DRNC

⇒

SRNC

DRNC

⇒

SRNC

4.5 NBAP Procedures & Messages

For a detailed description of NBAP procedures and messages refer to [5]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

ETSI


Table 4

Message Name

DL Power Control Request

Physical Shared Channel

Reconfiguration Request

Physical Shared Channel

Reconfiguration Response

Radio Link Deletion

UTRAN Procedure



Radio Link Deletion Response

Radio Link Failure Indication


Commit


Prepare


Ready


Request


Response

Radio Link Restore Indication

Radio Link Setup Request

Radio Link Setup Response

System Information Update

Request

System Information Update

Response

Radio Link Preemption Required

Indication



Hard Handover

Soft Handover



Hard Handover

Soft Handover

Hard Handover


























Soft Handover

Hard Handover

Channel and Mobile State Switching on Iur



Hard Handover

Soft Handover




Hard Handover

Soft Handover


System Information Broadcasting





Direction

RNC

⇒

Node B


RNC

⇒

Node B

Node B

⇒

RNC

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

RNC

⇒

Node B

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

RNC

⇒

Node B

RNC

⇒

Node B

Node B

⇒

RNC

Node B

⇒

RNC

Node B

⇒

RNC

ETSI


4.6 ALCAP

ALCAP is a generic name to indicate the protocol(s) used to establish data transport bearers on the Iu, Iur and Iub interfaces. Q.2630.2 (Q AAL2) is one of the selected protocols to be used as ALCAP. Q.2630.2 adds new optional capabilities to Q.2630.1.

The following should be noted:

• data transport bearers may be dynamically established using ALCAP or preconfigured;

• transport bearers may be established before or after allocation of radio resources.

4.6.1 Q2630.2 (Q.AAL 2)

The following figure is showing an example of use of Q.2630.2 in the UTRAN context, for the different interfaces.

UE Node B

Drift RNS

Node B

Serving RNS

Drift

RNC

Serving

RNC

CN

Q.aal2

Establish Request

Q.aal2

Q.aal2

Establish Confirm

Q.aal2

Q.aal2

Q.aal2

Establish Request

Q.aal2

Establish Confirm

Q.aal2

Q.aal2

Q.aal2

Establish Request

Establish Confirm

Q.aal2

Q.aal2

Q.aal2

Establish Request

Establish Confirm

Q.aal2

Q.aal2

Figure 2: Example on Q.2630.2

4.7 RRC Procedures & Messages

For a detailed description of RRC procedures and messages refer to [8]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

ETSI

Message Name

Active Set Update

Active Set Update Complete

Cell Update

Cell Update Confirm

Direct Transfer


Initial Direct Transfer

Measurement Control

Measurement Report

Paging Type 1

Paging Type 2



Allocation


Complete

PUSCH Capacity Request

RB Reconfiguration

RB Reconfiguration Complete

RB Release

RB Release Complete

RB Setup

RB Setup Complete


RRC Connection Release Complete

RRC Connection Request

RRC Connection Setup

RRC Connection Setup Complete

System Information



Complete

UE Capability Information


URA Update

URA Update Confirm

UTRAN Mobility Information Confirm

Handover from UTRAN Command

Handover to UTRAN Complete

Cell Change Order from UTRAN


Table 5

Soft Handover

Soft Handover


Cell Update


Cell Update

UTRAN Procedure

NAS Signalling Conn. Establishment


NAS Signalling Connection Establishment



Direction

RNC

⇒

UE

UE

⇒

RNC

UE

⇒

RNC

UE

⇒

RNC

RNC

⇒

UE

RNC

⇒

UE

UE

⇔

RNC

RNC

⇒

UE

UE

⇒

RNC

RNC

⇒

UE

UE

⇒

RNC

RNC

⇒

UE

Paging for a UE in RRC Idle Mode and RRC connected mode (CELL_PCH and URA_PCH states)Paging for a UE in

RRC Connected Mode

Paging for a UE in RRC Connected Mode (CELL_DCH and

RNC

⇒

UE

CELL_FACH states)


Hard Handover

RNC

⇒

UE

RNC

⇒

UE

USCH/DSCH Configuration and Capacity Allocation [TDD] RNC

⇒

UE


Hard Handover

UE

⇒

RNC

UE

⇒

RNC


UE

⇒

RNC

USCH/DSCH Configuration and Capacity Allocation [TDD] RNC

⇒

UE


UE

⇒

RNC


RNC

⇒

UE





UE

⇒

RNC

RNC

⇒

UE

UE

⇒

RNC

RNC

⇒

UE


RRC Connection Establishment.






UE

⇒

RNC

UE

⇒

RNC

RNC

⇒

UE

UE

⇒

RNC

Node B

⇒

UE

RNC

⇒

UE

UE

⇒

RNC

NAS Signalling Conn. Establishment.


Cell Update

Cell Update


Cell Update

URA Update

UTRAN to GSM/BSS handover

GSM /BSS to UTRAN handover

UMTS to GPRS Cell Reselection

UE

⇒

RNC

UE

⇒

RNC

UE

⇒

RNC

RNC

⇒

UE

UE

⇒

RNC

UE

⇒

RNC

UE

⇒

RNC

RNC

⇒

UE

UE

⇒

RNC

RNC

⇒

UE

4.8 BMC Procedures & Messages

For a detailed description of BMC procedures and messages refer to [11] and [12]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

ETSI


CBS Message

Message Name

16 ETSI TR 125 931 V5.3.0 (2006-03)

Table 6

UTRAN Procedure


Direction

Node B

⇒

UE

4.9 DCH Frame Protocol Messages

For a detailed description of DCH Frame protocol messages refer to [15]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

Table 7

Message Name UTRAN Procedure

Downlink Synchronisation RRC Connection Establishment


Soft Handover

Uplink Synchronisation RRC Connection Establishment


Soft Handover

Direction

SRNC

⇒

Node B

SRNC

⇒

Node B

SRNC

⇒

Node B

Node B

⇒

SRNC

Node B

⇒

SRNC

Node B

⇒

SRNC

4.10 DSCH Frame Protocol Messages

For a detailed description of DSCH Frame protocol messages refer to [13]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

Table 8

Message Name UTRAN Procedure

DSCH Capacity Allocation USCH/DSCH Configuration and Capacity Allocation [TDD]

DSCH Capacity Request USCH/DSCH Configuration and Capacity Allocation [TDD]

Direction

DRNC

⇒

SRNC

SRNC

⇒

DRNC

4.11 USCH Frame Protocol Messages

For a detailed description of DSCH Frame protocol messages refer to [14]. Only Messages mentioned in the present document are shown. For each message is also given the list of example procedures where the message is used, as provided by this document.

Message Name

Dynamic PUSCH Assign

Table 9

UTRAN Procedure


Direction

RNC

⇒

Node B

5 UTRAN Signalling Procedures

The signalling procedures shown in the following sections do not represent the complete set of possibilities, nor do they mandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which may be combined in different ways in an implementation. Therefore these sequences are merely examples of a typical implementation.

The list of parameters is not be complete, but should only be seen as help for the understanding of the examples.

ETSI


6 Procedures not related to a specific UE (global procedures)

This clause presents some signalling procedures not related to a specific UE.

6.1 System Information Broadcasting

This example shows an example of System Information broadcasting.

UE Node B RNC CN

NBAP

NBAP

1. System Information Update Request

2. System Information Update Response

NBAP

NBAP

RRC

RRC

3. BCCH: System Information


RRC

RRC

RRC


RRC

Figure 3: System Information Broadcasting

1. The RNC forwards the request to the pertinent node(s) B for via NBAP message System Information Update

Request.

Parameters: Master/Segment Information Block(s) (System information to be broadcasted), BCCH modification time.

2. The Node B confirms the ability to broadcast the information sending System Information Update Response message to the RNC via NBAP. (If the Node B can not Broadcast the information as requested, System

Information Update Failure is return to the RNC).

3./4./5. The information is broadcasted on the air interface by RRC message System Information.

Parameters: Master/Segment Information Block(s) (System information).

6.2 Service Area Broadcast

This example shows an example of broadcasting of Cell Information. UTRAN transports this broadcast information transparently.

ETSI


UE Node B

18 ETSI TR 125 931 V5.3.0 (2006-03)

RNC CN

BMC

BMC

BMC

3. CTCH: CBS Message



SABP

1. Write-replace

SABP

2. Write-replace Complete

SABP SABP

BMC

BMC

BMC

Figure 4: Service Area Broadcast

1. The CN asks the RNC for an information Broadcast via SABP message Write-replace.

Parameters: Broadcast-Message-Content, Service-Area-List.

2. The RNC confirm the ability to broadcast the information sending Write-Replace Complete message to the CN via SABP. (If the RNC can not Broadcast the information as requested, Write-replace Failure message is return to the CN).

3./4./5. The information is broadcasted on the air interface by BMC message CBS Message. carried over CTCH channel.

Parameters: Message ID, CB Data.

Note that the Node B is transparent to this messaging because (as mentioned in [10],[11] and [12]) the BMC protocol is terminated in RNC (see also [7]).

7 Procedures related to a specific UE

This clause presents a number of signalling procedures related to a specific UE.

7.1 Paging

This subclause presents two examples of Paging procedures for both the cases of a UE in RRC Idle Mode and RRC

Connected Mode.

7.1.1 Paging for a UE in RRC Idle Mode and RRC connected mode

(CELL_PCH and URA_PCH states)

This example shows how paging is performed for a UE in RRC Idle Mode. The UE may be paged for a CS or PS service. Since the UE is in RRC Idle Mode, the location is only known at CN level and therefore paging is distributed over a defined geographical area (e.g. LA).

NOTE: Example below illustrates scenario where LA spans across 2 RNCs.

ETSI


U E N od e B

1 .1

N od e B

2 .1

19

R N C

1

R A N A P

ETSI TR 125 931 V5.3.0 (2006-03)

R N C

2

R A N A P

1 . P a g in g

1 . Pa g in g

C N

R A N A P

R A N A P

2 . P C C H : P a g in g T yp e 1

3 . P C C H : P a g in g T yp e 1

Figure 5: Paging for a UE in RRC Idle Mode

1. CN initiates the paging of a UE over a LA spanning two RNCs (i.e. RNC1 and RNC2) via RANAP message

Paging.

Parameters: CN Domain Indicator, Permanent NAS UE Identity, Temporary UE Identity, Paging Cause.

2. Paging of UE performed by cell1 using Paging Type 1 message.

3. Paging of UE performed by cell2 using Paging Type 1 message.

The UE detects page message from RNC1 (as example) and the procedure for NAS signalling connection establishment follows. NAS message transfer can now be performed.

This procedure described for RRC idle mode, applies also to the RRC connected mode in the case of CELL_PCH and

URA_PCH states.

7.1.2 Paging for a UE in RRC Connected Mode (CELL_DCH and

CELL_FACH states)

This can occur in case of two core network domains, with the mobility management independent of each other. Two possible solutions exists:

•

The UTRAN coordinates the paging request with the existing RRC connection.

•

The UE coordinates the paging request with the existing RRC connection.

The following example shows how paging is performed for a UE in RRC Connected Mode (CELL_DCH and

CELL_FACH states) when the UTRAN coordinates the paging request with the existing RRC connection using DCCH.

U E S er vin g

R N C

C N

R A N A P

1 . P a g in g

R A N A P

2 . D C C H : P a g in g T yp e 2

R R C R R C

Figure 6: Paging for a UE in RRC Connected Mode (CELL_DCH and CELL_FACH states)

1. CN initiates the paging of a UE via RANAP message Paging.

Parameters: CN Domain Indicator, Permanent NAS UE Identity, Temporary UE Identity, Paging Cause.

2. SRNC sends RRC message Paging Type 2.

ETSI


7.2 NAS Signalling Connection Establishment

This example shows establishment of a NAS Signalling Connection.

This establishment could be request by the terminal by itself (for example to initiate a service) or could be stimulated by a paging from the CN.

U E S er vin g

R N C

C N

1. R R C C on n ection E sta blish m en t

2 . D C C H : In itia l D ir ect T ra n sfer

R R C

R R C

R A N A P

3 . In itia l U E M essa g e

R A N A P

Figure 7: NAS Signalling Connection Establishment

1. RRC Connection is established (see 7.3.1 or 7.3.2).

2. UE sends RRC Initial Direct Transfer to SRNC.

Parameters: Initial NAS Message (could for a GSM based CN be e.g. CM Service Request, Location Update

Request etc.) CN node indicator (it indicates the correct CN node into which the NAS message shall be forwarded).

3. SRNC initiates signalling connection to CN, and sends the RANAP message Initial UE Message.

Parameters: NAS PDU (could for a GSM based CN be e.g. CM Service Request, Location Update Request etc.),

CN domain indicator (indicating the CN domain towards which this message is sent).

The NAS signalling connection between UE and CN can now be used for NAS message transfer.

7.3 RRC Connection Establishment

The following examples show establishment of a RRC connection either in dedicated transport channel (DCH) state or in common transport channel (RACH/FACH) state.

This example shows establishment of an RRC connection in dedicated transport channel (DCH) state.

ETSI


U E

21 ETSI TR 125 931 V5.3.0 (2006-03)

N o d e B

S ervin g R N S

S erv in g

R N C

1 . C C C H : R R C C o nne ctio n R eq u est

R R C

R R C

A llo cate R N T I

S elect L 1 an d L 2 p aram e te rs

2 . R a d io L in k S etu p R eq u est

N B A P

S tart R X

N B A P

3 . R a d io L in k S etu p R esp o n se

N B A P N B A P

R R C

4 . A L C A P Iu b D ata T ran sp o rt B e are r S etu p

D C H -F P

D C H -F P

5 . D o w n lin k S y n ch ro n isatio n

6 . U p lin k S yn ch ro n isatio n

S tart T X

7 . C C C H : R R C C o n nectio n S etup

8 . R ad io L in k R e sto re In d ic atio n

N B A P

9 . D C C H : R R C C o n nectio n S etup C o m p lete

D C H -F P

D C H -F P

R R C

N B A P

R R C

R R C

Figure 8: RRC Connection Establishment - DCH Establishment

1. The UE initiates set-up of an RRC connection by sending RRC Connection Request message on CCCH.

Parameters: Initial UE Identity, Establishment cause.

2. The SRNC decides to use a DCH for this RRC connection, allocates U-RNTI and radio resources for the RRC connection. When a DCH is to be set-up, NBAP message Radio Link Setup Request is sent to Node B.

Parameters: Cell id, Transport Format Set, Transport Format Combination Set, frequency, UL scrambling code

(FDD only), Time Slots (TDD only), User Codes (TDD only), Power control information.

3. Node B allocates resources, starts PHY reception, and responds with NBAP message Radio Link Setup

Response.

Parameters: Signalling link termination, Transport layer addressing information (AAL2 address, AAL2 Binding

Identity) for the Iub Data Transport Bearer.

4. SRNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of Iub Data Transport bearer is acknowledged by Node B.

5./6.The Node B and SRNC establish synchronism for the Iub and Iur Data Transport Bearer by means of exchange of the appropriate DCH Frame Protocol frames Downlink Synchronisation and Uplink Synchronisation. Then

Node B starts DL transmission.

7. Message RRC Connection Setup is sent on CCCH from SRNC to UE.

Parameters: Initial UE Identity, U-RNTI, Capability update Requirement, Transport Format Set, Transport

Format Combination Set, frequency, DL scrambling code (FDD only), Time Slots (TDD only), User Codes

(TDD only), Power control information.

8. Node B achieves uplink sync and notifies SRNC with NBAP message Radio Link Restore Indication.

9. Message RRC Connection Setup Complete is sent on DCCH from UE to SRNC.

Parameters: Integrity information, ciphering information, UE radio access capability.

ETSI


This example shows establishment of an RRC connection on the RACH/FACH common transport channel. A prerequisite for this example is that the necessary Iub Data Transport bearer for the RACH/FACH is established prior to this procedure.

U E

N o d e B

S e rvin g R N S

S erving

R N C

1 . C C C H : R R C C o n nectio n R e q uest

R R C

R R C

R R C

2 . C C C H : R R C C o nne ctio n S e tup

3. D C C H : R R C C o n nectio n S etup C o m ple te

R R C

R R C

R R C

Figure 8b: RRC Connection Establishment – RACH/FACH Establishment

1. The UE initiates set-up of an RRC connection by sending RRC Connection Request message on CCCH.

Parameters: Initial UE Identity, Establishment cause.

2. The SRNC decides to use RACH/FACH for this RRC connection and allocates both U-RNTI and C-RNTI identifiers. Message RRC Connection Setup is sent on CCCH.

Parameters: Initial UE Identity, U-RNTI, C-RNTI, Capability update Requirement, frequency (optionally).

3. UE sends RRC Connection Setup Complete on a DCCH logical channel mapped on the RACH transport channel.

Parameters: Integrity information, ciphering information, UE radio access capability.

7.3.3 DCH Establishment with Pre-emption

This example shows the establishment of an RRC Connection in dedicated transport channel (DCH) state with preemption of resouces as a result of Node B Admission Control. This assumes that that the RL(s) pre-empted are the only

RL(s) for a RAB that is released.

ETSI


UE

Low Priority

UE

Hi Priority

RRC

23

Node B

Serving RNS

1. CCCH: RRC Connection Request

ETSI TR 125 931 V5.3.0 (2006-03)

CN Serving

RNC

RRC

RRC

RRC

RRC

2. Radio Link Setup Request

NBAP

Node B admission control threshold exceeded

3. Radio Link Preemption Required Indication

NBAP

8. RRC Connection Release

9. RRC Connection Release Complete

NBAP

NBAP

10. Radio Link Deletion Request

11. Radio Link Deletion Response

12. ALCAP Iub Bearer Release

13. Radio Link Setup Response

NBAP

14. ALCAP Iub Data Transport Bearer Setup

15. Downlink Synchronisation

DCH-FP

DCH-FP

Start TX

16. Uplink Synchronisation

17. CCCH: RRC Connection Set up

N B AP

NBAP

SRNC identifies that the

RAB needs to be released

RANAP

4. RAB Release Request

RANAP

5. Iu Release Command

RANAP

6. ALCAP Iu Bearer Release

RANAP

7. Iu Release Complete

RANAP RANAP

RRC

RRC

NBAP

NBAP

NBAP

DCH-FP

DCH-FP

RRC

18. Radio Link Restore Indication

NBAP

NBAP

RRC

19. DCCH : RRC Connection Setup Com plete

RRC

Figure 8c RRC Connection Establishment - DCH Establishment with pre-emption

1. See 7.3.1 Item 1.

2. When a DCH is to be set-up, NBAP message Radio Link Setup Request is sent to the Node B.

3. Node B attempts to allocate resources, but is unable to and responds with NBAP message Radio Link

Preemption Required Indication, and starts the T preempt

timer.

Parameters: RLInformation IE.

4. The SRNC pre-empts a RL and may send a RANAP message RAB Release Request to the CN.

Cause: RAB Pre-empted

5. If the CN agrees to the release of the dedicated Channel it sends the message Iu Release Command to the

SRNC.

6. The SRNC initiates release of the Iu Data Transport bearer using ALCAP protocol.

7. The SRNC confirms the release by sending a Iu Release Complete message to the CN.

8. Message RRC Connection Release from SRNC to UE intiates the RRC connection release.

Parameters: Release Cause - Pre-emptive release

9. Message RRC Connection Release Complete from the UE to SRNC to confirm the RRC connection release.

10. The SRNC initiates the release of the link by sending Radio Link Deletion to the Node B. The Node B stops the

T preempt

timer.

11. The Node B confirms the release of the link by sending the Radio Link Deletion Response to the SRNC

12. The Node B initiates release of the Iub Data Transport Bearer using ALCAP protocol.

ETSI


13. The Node B responds to Item 2 with NBAP message Radio Link Setup Response.

14-20 See 7.3.1 Items 4-9

7.4 RRC Connection Release

The following examples show RRC connection release either of a dedicated channel (DCH) or of a common transport channel (RACH/FACH).

This example shows RRC Connection release of a dedicated channel, in the case of macrodiversity on two nodes B, the first one connected to the Serving RNC, the second one to the Drift RNC.

U E

R R C

R R C

N o d e B

D rift R N S

N B A P

N B A P

N o d e B

Se rv in g R N S

D rift

R N C

S e rving

R N C

C N

R A N A P

1 . Iu R e le ase C o m m a nd

R A N A P

R A N A P

2 . Iu R e lea se C o m p let e

R A N A P

3 . A L C A P Iu B ea re r R e le a se

4 . R R C C o nnec tio n R e le ase

R R C

5 . R R C C o nnec tio n R e le ase C o m ple te

R R C

N B A P

6 . R a d io L ink D e letio n

R N S A P

N B A P

7 . R a dio L ink D e le tio n

R N S A P

8 . R a dio L ink D e letio n

N B A P

1 0 . R a dio L ink D e letio n R esp o nse

N B A P

9 . R a d io L ink D e le tio n R e sp o nse

N B A P

N B A P

1 1 . R a dio L ink D e letio n R esp o nse

R N S A P R N S A P

1 2. A L C A P Iu b B e a re r R e le ase

1 3 . A L C A P Iu b B ea re r R ele a se

A L C A P Iur B ea re r

R e le ase

Figure 9: RRC Connection release of a dedicated channel

1. The CN initiates the release of a dedicated Channel by sending the message Iu Release Command to the SRNC.

Parameters: Cause.


Parameters: Data volume Report (if data volume reporting to PS is required).

3. The SRNC initiates release of Iu Data Transport bearer using ALCAP protocol.

4. Message RRC Connection Release from SRNC to UE to initiate the RRC connection release.

Parameters: Cause.

5. Message RRC Connection Release Complete from UE to SRNC to confirm the RRC connection release.

6. The SRNC initiates the release of the link by sending the Radio Link Deletion to the Node B (SRNC).

7. The SRNC initiates the release of the link by sending the Radio Link Deletion to the Drift RNC.

8. The Drift RNC initiates the release of the link by sending the Radio Link Deletion to the Node B (Drift RNC).

9. The Node B (SRNC) confirms the release of the link by sending the Radio Link Deletion Response to the

SRNC.

ETSI


10. The Node B (Drift RNC) confirms the release of the link by sending the Radio Link Deletion Response to the

Drift RNC.

11. The Drift RNC confirms the release of the link by sending the Radio Link Deletion Response to the SRNC.

12. The Node B (SRNC) initiates release of Iub Data Transport bearer using ALCAP protocol.

13. The Node B (Drift RNC) initiates release of Iub Data Transport bearer using ALCAP protocol.

14. The Drift RNC initiates release of Iur Data Transport bearer using ALCAP protocol.

7.4.2 Common Transport Channel Release

This example shows RRC Connection release of a common transport channel.

U E N o de B

D rift R N S

N o de B

S erv in g R N S

D rift

R N C

Serv ing

R N C

R AN AP

1 . Iu R elease C o m m a nd

C N

R AN A P

R AN AP

2 . Iu R elease C o m pl ete

R AN A P

3 . ALC A P Iu B earer R elease

R R C

R R C

4 . R R C C o nnec tio n R e lease

5 . R R C C o n nectio n R eleas e C o m p lete

R R C

R R C

Figure 10: RRC Connection release of a common transport channel

1. The CN initiates the release of a dedicated Channel by sending the message Iu Release Command to the SRNC.

Parameters: Cause.


Parameters: Data volume Report (if data volume reporting to PS is required).

3. The SRNC initiates release of Iu Data Transport bearer using ALCAP protocol.

4. Message RRC Connection Release from SRNC to UE to initiate the RRC connection release.

Parameters: Cause.

5. Message RRC Connection Release Complete from UE to SRNC to confirm the RRC connection release.

7.5 RRC Connection Re-establishment

The following examples show re-establishment of a RRC connection either on a dedicated channel (DCH) Examples of

RRC Connection Re-establishment on a common channel (RACH/FACH) are found in the 'Cell Update' section of this document.

7.5.1.1 RRC connection Re-establishment (Anchor approach) – DCH Reestablishment

This example shows re-establishment of a RRC connection in dedicated transport channel (DCH) state.

ETSI


U E S -R N C

26 ETSI TR 125 931 V5.3.0 (2006-03)

O ld

D -R N C

O ld

N o d e B

N e w

D -R N C

1 . R e ce p tio n o f U u S ig n allin g

M e ssag e [ C C C H : C e ll U p d a te ]

N ew

N o d e B

R N S A P

2 . U p lin k S ig n a llin g T ran sfe r In d ic atio n

[ C e ll U p d a te ]

3 . R ad io L in k S e tu p R e q u e st

R N S A P

R N S A P

R N S A P

4 . R ad io L in k S e tu p R e q u e st

N B A P N B A P

5 . R a d io L in k S e tu p R e sp o n se

N B A P N B A P

6 . R a d io L in k S e tu p R e sp o n s e

R N S A P

7 . A L C A P Iu r B ea re r S e tu p

R N S A P

A L C A P Iu b

B ea re r S e tu p

8 . R a d io L in k D e letio n

R N S A P R N S A P

9 . R ad io L in k D e le tio n R e sp o n se

R N S A P R N S A P

1 0 . A L C A P Iu r

B e a re r R e lea se

1 1 R ad io L in k D ele tio n

N B A P N B A P

1 2 . R a d io L in k D e letio n R e sp o n se

N B A P N B A P

R N S A P

1 3 . A L C A P Iu b B e arer

R e lea se

1 4 . D o w n lin k S ig n allin g T ra n sfe r R e q u e st

[ C e ll U p d a te C o n firm ]

R N S A P

1 5 . T ra n sm issio n o f U u

S ig n a llin g M e ssa g e [ C e ll U p d a te

C o n firm ]

1 6 D C C H : U T R A N M o b ility In fo rm a tio n C o n firm

R R C R R C

Figure 11: RRC connection Re-establishment (Anchor approach) – DCH Re-establishment

1. The UE initiates the re-establishment of the RRC connection with the new cell by sending Cell Update message on CCCH.

2. The new RNC delivers this message transparently as Uplink Signalling Transfer Indication message to the serving RNC, the RNSAP delivers it to the RRC.

3. The serving RNC allocates radio resources for the RRC connection on Iur, and sends the RNSAP message

Radio Link Setup Request to the target RNC.

ETSI


4. The target RNC sends the NBAP message Radio Link Setup Request to the target Node B.

5. Node B allocates resources, and responds with NBAP message Radio Link Setup Response.

6. Target RNC responds with RNSAP message Radio Link Setup Response.

7. Serving RNC initiates set-up of Iur / Iub Data Transport bearer using ALCAP protocol. This request contains the

AAL2 Binding Identity to bind the Iur / Iub Data Transport Bearer to the DCH. The request for set-up of Iur /

Iub Data Transport bearer is acknowledged by target RNC / Node B.

8./9./10./11./12./13. The SRNC initiates release of Iur/Iub Data Transport bearer using ALCAP protocol and also release of Iur/Iub Radio resource using RNSAP / NBAP protocols.

14. The RRC in the serving RNC prepare a RRC Connection Re-establishment message and the RNSAP sends it in the transparent message Downlink Signalling Transfer Request to the new CRNC.

15. The New CRNC delivers the Cell Update Confirm message on CCCH.

16. Message UTRAN Mobility Information Confirm is sent on the new DCCH from the UE to the serving RNC.

7.5.1.2 RRC Connection Re-establishment with SRNC Relocation - DCH Reestablishment

This subclause shows an example for the RRC Connection Re-establishment procedure, in dedicated transport channel

(DCH) state.

It is assumed that a signalling link is available on the Iur, but no DCH is established on this interface.

U E N od e B

S erv in g

N o d e B

T arg e t

R N C

Serv in g

R N C

T a rge t

M S C

O ld

M S C

N e w

1 . R ecep tio n o f U u S ignalling M e ssa ge

C e ll U pd a te

R R C

R R C

A lloc a tio n o f

C R N T I a nd

D R N T I

R N S A P

2 . U p link S ign allin g

T ransfer Ind ica tio n

R N S A P

[C e ll U p da te ]

N B A P

N B A P

3 . R a d io L ink D e le tion

4 . R a d io L ink D e le tion R e sp o nse

N B A P

N B A P

5 . A L C A P Iub D a ta T ra nsp o rt B e a re r D e le tio n

6 . S R N C R e lo c a tio n

R e lease of C R N T I an d

D R N T I

A lloc a tio n o f S R N T I

N B A P

N B A P

7. R a d io L ink S e tup R e quest

8. R a d io L ink S e tup R e sp o nse

9 . A L C A P Iu b D a ta T ra nsp o rt B e a rer S e tup

10 . C C C H : C ell U p d ate C on firm

11 . R a d io L in k R e store Ind icatio n

N B A P

1 2 . D C C H : U T R A N M o b ility Inform ation C o nfirm

N B A P

N B A P

R R C

N B A P

R R C

Figure 12: RRC Connection Re-establishment with SRNC Relocation - DCH Re-establishment

ETSI


1. The UE initiates the re-establishment of the RRC connection with the new cell by sending Cell Update message on CCCH. The message is received by the Target RNC.

2. The target RNC delivers the received message transparently as Uplink Signalling Transfer Indication message to the serving RNC.

3. The Serving RNC sends NBAP message Radio Link Deletion to Node B.

Parameters: Cell id, Transport layer addressing information.

4. Node B deallocates radio resources. Successful outcome is reported in NBAP message Radio Link Deletion

Response.

5. The SRNC initiates release of Iub Data Transport bearer using ALCAP protocol.

6. SRNC relocation procedure is triggered by the reception of the message Cell Update embedded in the RNSAP

Uplink Signalling Transfer Indication message (relocation is performed in parallel with Radio Link release).

7. The target RNC (new SRNC) allocates RNTI and radio resources for the RRC connection, and sends the NBAP message Radio Link Setup Request to the target Node B.


(FDD only), Time Slots (TDD only), User Codes (TDD only), Power control information.

8. Target Node B allocates resources, starts PHY reception, and responses with NBAP message Radio Link Setup

Response.

Parameters: Signalling link termination, Transport layer addressing information for the Iub Data Transport

Bearer.

9. Target RNC (new SRNC) initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of

Iub Data Transport bearer is acknowledged by Node B.

10. Message Cell Update Confirm is sent on CCCH from target RNC (new SRNC) to UE.

Parameters: Old RNTI, New RNTI, Transport Format Set, Transport Format Combination Set, frequency, DL scrambling code (FDD only), Time Slots (TDD only), User Codes (TDD only)

11. Target Node B achieves uplink sync on the Uu and notifies SRNC with NBAP message Radio Link Restore

Indication.

12. Message UTRAN Mobility Info Confirm is sent on the new DCCH from the UE to the Target RNC (new

SRNC).

NOTE 1: SRNC Relocation execution is performed asynchronously with respect to the RL deletion procedure (step

3/4).

NOTE 2: Whether SRNC Relocation involves two MSCs (as depicted in the figure) or a single one, has no impact on the UTRAN message flow shown in this example.

7.6 Radio Access Bearer Establishment

The following examples show establishment of a radio access bearer on a dedicated channel (DCH) or on a common transport channel (RACH/FACH) when the RRC connection already support a radio access bearer either on a dedicated channel (DCH) or on a common transport channel (RACH/FACH).

7.6.1 DCH - DCH Establishment - Synchronised

This example shows establishment of a radio access bearer (DCH) in dedicated transport channel (DCH) RRC state.

[FDD-The UE communicates via two Nodes B. One Node B is controlled by SRNC, one Node B is controlled by

DRNC].

[TDD – The Nodes B shown in the figure are mutually exclusive in TDD mode.].

ETSI


U E N od e B

D rift R N S

N B A P

N B A P

N od e B

S e rv in g R N S

D rift

R N C

S er vin g

R N C

C N

R A N A P

1 . R A B A ss ig n m en t

R eq uest

R A N A P

[ E sta blish m e n t]

S elect L1 , L 2 a n d Iu D a ta

T r a n sp or t B ea rer p a r a m eters

4 . R a d io L in k R econ figu r a tion P r ep a r e

[D C H A d dition ]

2 . A L C A P Iu D a ta

T r a n spor t B ea r er S etu p

3. R a d io L in k R econ figu r a tion

R N S A P

P r epa r e

R N S A P

N ot re qu ire d to wa rds P S d o m a in

[D C H A d dition ]

N B A P

N B A P

5 . R a dio L in k R econ fig u ra tion P r epa r e

N B A P

[ D C H A d d itio n ]

6 R a dio L in k R econ fig u ra tion R ea d y

N B A P

7. R a d io L in k R econ fig u r a tion

R N S A P

R ea d y

R N S A P

8 . R a dio L in k R econ fig u ra tion R ea d y

N B A P

N B A P

9 . A L C A P Iub D a ta T r a n sp or t B ea r er S etu p A L C A P Iu r B ea rer S etu p

R R C

R R C

D C H -F P

D C H -F P

N B A P

10 . A L C A P Iu b D a ta T r a n sp or t B ea r er S etu p

1 1 . D ow n lin k S yn ch ron isa tion

D C H -F P

1 2 . D ow n lin k S yn ch ron isa tion

D C H -F P D C H -F P

13 . U p lin k S yn ch ron isa tion

D C H -F P

14 . U p lin k S yn ch r on isa tion

D C H -F P D C H -F P

1 5. R a d io L in k R econ figu r a tion

R N S A P

C om m it

R N S A P

16 . R a dio L in k R econ fig u ra tion C om m it

N B A P

N B A P

1 7. R a dio L in k R econ fig u r a tion C om m it

N B A P

1 8. D C C H : R a dio B ea r er S etu p

R R C

A p p ly n ew tr a n sp or t for m a t set

1 9. D C C H : R a dio B ea r er S etu p C om plete

R R C

R A N A P

2 0 . R A B A ssign m en t

R esp on se

R A N A P

Figure 13: Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronised

1. CN initiates establishment of the radio access bearer with RANAP message Radio Access Bearer Assignment

Request.

Parameters: Radio Access Bearer parameters, User Plane Mode, Transport Address, Iu Transport Association.

2. SRNC initiates set-up of Iu Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iu Data Transport Bearer to the Radio Access Bearer (this step is not required towards PS domain).

3. SRNC requests DRNC to prepare establishment of DCH to carry the radio access bearer (Radio Link

Reconfiguration Prepare).

Parameters: Transport Format Set, Transport Format Combination Set, Power control information, instructions for DCH mapping on Iub Data Transport Bearers.

4. DRNC requests its Node B to prepare establishment of DCH to carry the radio access bearer (Radio Link


Parameters: Transport Format Set, Transport Format Combination Set, Power control information.

5. SRNC requests its Node B to prepare establishment of DCH to carry the radio access bearer (Radio Link


ETSI


Parameters: Transport Format Set, Transport Format Combination Set, Power control information, Time Slots

(TDD only), User Codes (TDD only).

6. Node B allocates resources and notifies DRNC that the preparation is ready (Radio Link Reconfiguration

Ready).

Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iub Data Transport

Bearer.

7. DRNC notifies SRNC that the preparation is ready (Radio Link Reconfiguration Ready).


Bearer.

8. Node B allocates resources and notifies SRNC that the preparation is ready (Radio Link Reconfiguration

Ready).


Bearer.

9. SRNC initiates setup of Iur/Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH.

10. SRNC initiates setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iub Data Transport Bearer to DCH.

11./12./13./14. The Nodes B and SRNC establish synchronism for the Iub and Iur Data Transport Bearer by means of exchange of the appropriate DCH Frame Protocol frames Downlink Synchronisation and Uplink

Synchronisation.

15. RNSAP message Radio Link Reconfiguration Commit is sent from SRNC to DRNC.

Parameters:

16. NBAP message Radio Link Reconfiguration Commit is sent from DRNC to Node B.

Parameters:

17. NBAP message Radio Link Reconfiguration Commit is sent from SRNC to Node B.

Parameters:

18. RRC message Radio Access Bearer Setup is sent by SRNC to UE.

Parameters: Transport Format Set, Transport Format Combination Set, Time Slots (TDD only), User Codes

(TDD only).

19. UE sends RRC message Radio Access Bearer Setup Complete to SRNC.

20. SRNC sends RANAP message Radio Access Bearer Assignment Response to CN.

7.6.2 DCH - DCH Establishment - Unsynchronised

This example shows the establishment of a radio access bearer (DCH) in dedicated transport channel (DCH) RRC state.

The UE communicates via two Nodes B. One Node B is controlled by SRNC, one Node B is controlled by DRNC. The reconfiguration time does not require to be synchronised among Node-Bs, SRNC and UE.

ETSI


UE Node B

Drift RNS

NBAP

NBAP

Node B

Serving RNS

4. RL Reconfiguration Request

[DCH Addition]

NBAP

6. Radio Link Reconfiguration Response

Drift

RNC

Serving

RNC

CN

RANAP

1. RAB Assignment

Request

RANAP

Select L1, L2 and Iu Data

Transport Bearer parameters

2. ALCAP Iu Data Transport Bearer Setup

RNSAP


RNSAP

[DCH Addition]

NBAP

5. Radio Link Reconfiguration

[DCH Addition]

NBAP

Not required towards

PS domain

NBAP

RNSAP

7. RL Reconfiguration

Response

RNSAP

8. ALCAP Iur Data Transport Bearer Setup


RRC

RRC

DCH-FP

DCH-FP

10.


NBAP





DCH-FP

DCH-FP

17. DCCH: Radio Bearer Setup


Apply new transport format set

18. DCCH: Radio Bearer Setup Complete

NBAP

DCH-FP

DCH-FP

DCH-FP

DCH-FP

RRC

RRC

RANAP

19. RAB Assignment

Response

RANAP

Figure 14: Radio Access Bearer Establishment - DCH - DCH Establishment – Unsynchronised

1. CN initiates establishment of the radio access bearer with RANAP Radio Access Bearer Assignment Request message.

Parameters: radio access bearer parameters, User Plane Mode, Transport Address, Iu Transport Association.

2. SRNC performs mapping of the radio access bearer QoS parameters to AAL2 link characteristics and initiates set-up of Iu Data Transport bearer using ALCAP protocol (this step is not required towards PS domain).

Parameters: Served User Generated Reference, AAL2 link characteristics …

3. SRNC decided that there are no need for a synchronous RL reconfiguration, and requests DRNC to setup a new

DCH sending the RL Reconfiguration Request message. The modification shall be done immediately without waiting for the command message.

Parameters: Bearer ID, Transport Format Set, Transport Format Combination Set, Power control information.

ETSI


4. DRNC requests its Node B to establish of a new DCH in the existing Radio Link sending the RL

Reconfiguration Request message.


5. SRNC requests its Node B setup a new DCH in the existing Radio Link sending the RL Reconfiguration

Request message.


6. Node B allocates resources and notifies DRNC that the setup is done sending the RL Reconfiguration

Response message.


Bearer.

7. DRNC notifies SRNC that the setup is done sending the RL Reconfiguration Response message.


Bearer.

8. SRNC initiates setup of Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur Data Transport Bearer to DCH.



10. DRNC performs bridging of Iub and Iur Data Transport bearers.

11. Node B allocates resources and notifies SRNC that the setup is sending the RL Reconfiguration Response.


Bearer.



13./14./15./16. The Nodes B and SRNC establish synchronism for the Iub and Iur Data Transport Bearer by means of exchange of the appropriate DCH Frame Protocol frames Downlink Synchronisation and Uplink

Synchronisation.

17. RRC message Radio Bearer Setup is sent by SRNC to UE.

Parameters: Transport Format Set, Transport Format Combination Set.

18. UE sends RRC message Radio Bearer Setup Complete to SRNC.

19. SRNC sends RANAP message Radio Access Bearer Assignment Response to CN.

Parameters: Transport Address (Always for PS domain; for CS domain only if modified), Iu Transport

Association (Always for PS domain; for CS domain only if modified).

7.6.3 RACH/FACH - DCH Establishment

This example shows the establishment of a radio access bearer (DCH) in common transport channel (RACH/FACH)

RRC State.

ETSI


UE Node B

Drift RNS

Node B

Serving RNS

NBAP

NBAP

Drift

RNC



Serving

RNC

CN

RANAP

1. RAB Assignment

Request

[Establishment]

RANAP

NBAP

NBAP


RRC

RRC


NBAP

8. DCCH: Radio Bearer Setup Complete



not required towards PS domain

RRC

NBAP

RRC

RANAP

9. RAB Assignment

Response

RANAP

Figure 15: Radio Access Bearer Establishment – RACH/FACH - DCH Establishment –

Unsynchronised

1. CN initiates establishment of the radio access bearer with RANAP

Radio Access Bearer Assignment Request

message.


2. DRNC requests its Node B to establish of a new DCH in the existing Radio Link sending the

Radio Link Setup

Request

message.

Parameters: Transport Format Set, Transport Format Combination Set, Power control information.

3. Node B allocates resources and notifies SRNC that the setup is sending the

Radio Link Setup Response

.


Bearer.



5. SRNC performs mapping of the radio access bearer QoS parameters to AAL2 link characteristics and initiates set-up of Iu Data Transport bearer using ALCAP protocol (this step is not required towards PS domain)

Radio Bearer

Setup is sent by SRNC to UE.


7. Node B achieves uplink sync and notifies SRNC with NBAP message

Radio Link Restore Indication

.

8. UE sends RRC message

Radio Bearer Setup Complete

to SRNC.

9. SRNC sends RANAP message

Radio Access Bearer Assignment Response

to CN.

7.6.4 RACH/FACH - RACH/FACH Establishment

This example shows the establishment of a radio access bearer (RACH/FACH) in common transport channel

(RACH/FACH) RRC state.

ETSI


UE Node B

Drift RNS

Node B

Serving RNS

Drift

RNC

Serving

RNC

CN

RRC


RANAP

1. RAB Assignment

Request

[Establishment]

RANAP



RRC

48. DCCH: Radio Bearer Setup Complete

RRC

RRC

RANAP

5. RAB Assignment

Response

RANAP

Figure 16: Radio Access Bearer Establishment – RACH/FACH – RACH/FACH Establishment –

Unsynchronised

1. CN initiates establishment of the radio access bearer with RANAP


message.


2. SRNC performs mapping of the radio access bearer QoS parameters to AAL2 link characteristics and initiates set-up of Iu Data Transport bearer using ALCAP protocol (this step is not required towards PS domain).

Radio Bearer

Setup is sent by SRNC to UE.




to SRNC.

5. SRNC sends RANAP message


to CN.

7.7 Radio Access Bearer Release

The following examples show release of a radio access bearer either on a dedicated channel (DCH) or on a common transport channel (RACH/FACH) when the RRC connection already uses a dedicated channel (DCH) or a common transport channel (RACH/FACH).

7.7.1 DCH - DCH Release - Synchronised

This example shows release of a radio access bearer on a dedicated channel (DCH) when the RRC connection still uses a dedicated channel (DCH) after the release.

[FDD - The UE communicates via two Nodes B. One Node B is controlled by SRNC, one Node B is controlled by

DRNC.]

[TDD – The Nodes B shown in the figure are mutually exclusive in TDD mode.]

ETSI


U E

R R C

R R C

N o d e B

D rift R N S

N B A P

N B A P

N B A P

N o d e B

S e rv in g R N S

D rift

R N C

S e rv in g

R N C

C N

R A N A P

1 . R A B A ssig n m e n t

R e q u e st

[R e le a se ]

R A N A P

4 . R a d io L in k R e c o n fig ur a tio n P r e p a r e

3 . R a d io L in k R e c o n fig ur a tio n

R N S A P

P re p a re

R N S A P

[ D C H D e le tio n ]

2 . A L C A P Iu D a ta T ra n sp o rt

B e a re r R e le a se

n o t re q u ire d to w a rd s P S d o m a in

N B A P

[D C H D e le tio n ]

5 . R a d io L in k R e c o n fig ur a tio n P r e p a r e

N B A P

[D C H D e le tio n ]

6 . R a d io L in k R e c o n fig ur a tio n R e a d y

N B A P

N B A P

N B A P


R N S A P

R e a d y

R N S A P

8 . R a d io L in k R e c o nfig u ra tio n R e a d y

N B A P


R N S A P

C o m m it

R N S A P

1 0 . R a d io L in k R e c o n figu ra tio n C o m m it

N B A P

N B A P

1 1 . R a d io L ink R e c o n fig ur a tio n C o m m it

N B A P

1 2 . D C C H : R a d io B e a re r R e le a se

R R C

A p p ly n e w tr a n sp o r t fo r m a t se t

1 3 . D C C H : R a d io B e a re r R e le a se C o m p le te

R R C

1 4 . A L C A P Iu b D a ta T ra n sp o rt B e a r e r R e le a se A L C A P Iu r B e a re r R e le a se

1 5 . A L C A P Iu b D a ta T r a n sp o r t B e a r e r R e le a se

R A N A P

1 6 . R A B A ssig n m e n t

R e sp o n se

R A N A P

Figure 17: Radio Access Bearer Release - DCH - DCH Release - Synchronised

1. CN initiates release of the radio access bearer with RANAP message

Radio Access Bearer Assignment

Request

.

2. SRNC initiates release of the Iu Data Transport bearer between the CN and the SRNC using the ALCAP protocol (this step is not required towards PS domain).

3. SRNC requests DRNC to prepare release of DCH carrying the radio access bearer (

Radio Link

Reconfiguration Prepare

).

Parameters: Transport Format Combination Set, UL scrambling code.

4. DRNC requests its Node B to prepare release of DCH carrying the radio access bearer (

Radio Link


).

Parameters: Transport Format Combination Set, UL scrambling code.

5. SRNC requests its Node B to prepare release of DCH carrying the radio access bearer (

Radio Link


).

Parameters: Transport Format Combination Set, UL scrambling code (FDD only), Time Slots (TDD only), User

Codes (TDD only).

6. Node B notifies DRNC that release preparation is ready (

Radio Link Reconfiguration Ready

).

7. DRNC notifies SRNC that release preparation is ready (

Radio Link Reconfiguration ready

).

8. Node B notifies SRNC that release preparation is ready (


).

Radio Link Reconfiguration Commit

is sent from SRNC to DRNC.

10. NBAP message


is sent from DRNC to Node B.

ETSI


11. NBAP message


is sent from SRNC to Node B.

12. RRC message

Radio Bearer Release

is sent by SRNC to UE.

Parameters: Transport Format Set, Transport Format Combination Set, Time Slots (TDD only), User Codes

(TDD only).


Radio Bearer Release Complete

to SRNC.

14. Not used resources in DRNC and Node B (Drift RNS) are released. DRNC initiates release of Iur and Iub (Drift

RNS) Data Transport bearer using ALCAP protocol.

15. Not used resources in SRNC and Node B (Serving RNS, if any) are released. SRNC initiates release of Iub

(Serving RNS) Data Transport bearer using ALCAP protocol.

16. SRNC acknowledges the release of radio access bearer (


). Note:

This message may be sent any time after step 1 provided the RNC is prepared to receive new establishment request of a radio access bearer identified by the same radio access bearer identifier.

7.7.2 DCH - DCH Release - Unsynchronised

This example shows release of a radio access bearer on a dedicated channel (DCH) when the RRC connection still uses a dedicated channel (DCH) after the release. The UE communicates via two Nodes B. One Node B is controlled the

SRNC, one Node B is controlled by DRNC. The reconfiguration does not require to be synchronised among Node-Bs,

SRNC and UE.

UE Node B

Drift RNS

RRC

RRC

NBAP

NBAP

Node B

Serving RNS

Drift

RNC

Serving

RNC

CN

RANAP

1. RAB Assignment

Request

[Release]

RANAP

2. DCCH Radio Bearer Release

RRC

3. DCCH Radio Bearer Release Complete

RRC

RNSAP


Request

[DCH Deletion]


NBAP

[DCH Deletion]

NBAP


[DCH Deletion]


NBAP

RNSAP


Response

RNSAP

NBAP

RNSAP

4. ALCAP Iu Data

Transport Bearer Release



NBAP

NBAP

11. ALCAP Iub Data Transport Bearer Release ALCAP Iur Bearer Release

12. ALCAP Iub Data Transport Bearer Release

RANAP

13. RAB Assignment

Response

RANAP

Figure 18: Radio Access Bearer Release - DCH - DCH Release - Unsynchronised

1. CN initiates release of the radio access bearer with RANAP Radio Access Bearer Assignment Request message.

2. RRC message Radio Bearer Release is sent by SRNC to UE.

3. UE sends RRC message Radio Bearer Release Complete to SRNC.

ETSI



5. SRNC requests DRNC to release of DCH carrying the radio access bearer.

Parameters: DCH ID, TFCS.

6. DRNC requests its Node B to release of DCH carrying the radio access bearer.


7. SRNC requests its Node B to prepare release of DCH carrying the radio access bearer.


8. Node B acknowledges DRNC.

9. DRNC acknowledges SRNC.

10. Node B acknowledges SRNC.

11. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. Note: the release of the Iur link may be done before step 9

12. SRNC initiates release of Iub Data Transport bearer using ALCAP protocol. Note: the release of the Iub link may be done before step 9.

13. SRNC acknowledges the release of radio access bearer to CN. Note: This message may be sent any time after step 3 provided the RNC is prepared to receive new establishment request of a radio access bearer identified by the same radio access bearer identifier.

7.7.4 RACH/FACH - RACH/FACH Release

This example shows release of a radio access bearer on a common transport channel (RACH/FACH) when the RRC connection still uses a common transport channel (RACH/FACH) after the release (RACH/FACH to RACH/FACH).

UE Node B

Drift RNS

Node B

Serving RNS

Drift

RNC

Serving

RNC

CN

RANAP

1. RAB Assignment

Request

[Release]

RANAP

2. DCCH Radio Bearer Release

RRC

RRC

3. DCCH Radio Bearer Release Complete

RRC

RRC

RANAP

4. RAB Assignment

Response

RANAP

5. ALCAP Iu Data



Figure 19: Radio Access Bearer Release - RACH/FACH - RACH/FACH Release

1. CN initiates release of the radio access bearer with RANAP


message.

Radio Bearer Release



Radio Bearer Release Complete

to SRNC.

4. SRNC acknowledges the release of radio access bearer to CN.


ETSI


7.8 Radio Access Bearer Modification

The following examples show modification of a radio access bearer established either on a dedicated channel (DCH) or on a common transport channel (RACH/FACH). The procedure starts from a radio access bearer assignment because does not exist a special message to modify a radio access bearer, instead an 'assignment' message is used.

7.8.1 DCCH on DCH - Synchronised

This example shows modification of a radio access bearer established on a dedicated channel (DCH) with UE in macrodiversity between two RNCs. A NSAP synchronised procedure is used and a successful case is shown. For an unsuccessful case it"s important to note that a failure message can be sent in any point of the Message Sequence Chart

(MSC); in particular could be in RRC reconfiguration response.

A radio access bearer modification procedure (via radio access bearer assignment message) is shown with mapping to

Radio Bearer reconfiguration. Note that this is not possible if the used transport channel or logical channel is changed because the Radio Bearer reconfiguration does not permit a change in type of channel (see [8]).

ETSI


7.8.1.1

U E

39 ETSI TR 125 931 V5.3.0 (2006-03)

Synchronised DCH modification, Bandwidth increase

N o d e B

D rift R N S

N o d e B

S e rv in g

D rift

R N C

S e rvin g

R N C

C N

R A N A P


R e q u est

R A N A P

6 . A L C A P Iu b D a ta T ra nsp o rt B e are r M o d ify

2 . S e le c t L 1 , L 2 a n d Iu D a ta

T ra n sp o rt B e a re r p a ra m e ters

(e .g . fo r R a d io B e are r

3 . A L C A P Iu D ata

T ra n sp o rt B e a re r M o d ify

4 . A L C A P Iu r D ata T ra n sp o rt

B e a re r m o d ify

5 . R a d io L in k R e co n fig u ra tio n

R N S A P

P rep a re

R N S A P

N B A P

7 . R a d io L in k R ec o n figu ra tio n P rep a re

N B A P

8 . A L C A P Iu b D a ta T ra n sp o rt B e a re r M o d ify

R R C

N B A P

N B A P

N B A P

9 . R a d io L in k R ec o n fig u ra tio n P rep a re

1 0 . R a d io L in k R ec o n figu ra tio n R e a d y

N B A P

N B A P

1 1 . R a d io L in k R ec o n fig u ra tio n

R N S A P

R e a d y

R N S A P

N B A P

1 2 . R ad io L in k R e c o n fig u ratio n R ea d y

N B A P

1 3 . R ad io L in k R e c o n fig u ratio n

R N S A P

C o m m it

R N S A P

1 4 . R a d io L in k R e co n fig ura tio n C o m m it

N B A P

N B A P

1 5 . R ad io L in k R e c o nfig u ra tio n C o m m it

N B A P

1 6 . R a d io B ea re r R e c o nfig u ra tio n (D C C H )

R R C

1 7 . A c tu aliz ing R a d io B e a re r m o d ific a tio n (e .g . A p p ly n e w tran sp o rt fo rm at se t)

1 8 . R a d io B e a re r R e c o n fig u ra tio n C o m p le te (D C C H )

R R C

R R C

1 9 . R A B A ssig n m en t

R e sp o n se

R A N A P R A N A P

Figure 20: Radio Access Bearer Modification, Synchronised DCH modification, Bandwidth increase

1. CN initiates modification of the radio access bearer with RANAP message Radio Access Bearer Assignment

Request.

Parameters: parameters to be modified at lower level e.g. Maximum Bit Rate.

2. Interworking functions. SRNC chooses which parameters (lower level) ought to be modified and what kind of procedure has to start up (i.e Radio Bearer Reconfiguration for RRC).

3. SRNC starts an Iu Data Transport Bearer Modification between the CN and the SRNC using the ALCAP protocol with AAL2 bindings carried by radio access bearer assignment message (this step is not required towards PS domain). This has to be done before Radio Reconfiguration itself because the transport channel must be ready when the radio channel will be ready.

4. SRNC initiates modify of Iur (Serving RNS) Data Transport bearer. In the case that ALCAP is implemented by

Q.AAL2 (Q.2630.2 but without modification) it implies the release of the existing bearer and the establishment of a new one.

ETSI


5. SRNC requests DRNC to prepare modification of DCH carrying the radio access bearer (

Radio Link


).

Parameters: Transport Format Combination Set, UL scrambling code, Transport Bearer Request Indicator, etc.

6. DRNC initiates modify of Iub Data Transport bearer. In the case that ALCAP is implemented by Q.AAL2

(Q.2630.2 but without modification procedure) it implies the release of the existing bearer and the establishment of a new one.

7. DRNC requests its Node B to prepare modification of DCH related to the radio access bearer (

Radio Link


).

8. SRNC initiates modify of Iub (Serving RNS) Data Transport bearer. In the case that ALCAP is implemented by

Q.AAL2 (Q.2630.2 but without modification procedure) it implies the release of the existing bearer and the establishment of a new one.

9. SRNC requests its Node B to prepare modification of DCH carrying the radio access bearer (

Radio Link


).


Codes (TDD only), Transport Bearer Request Indicator.

10. Node B (drift) notifies DRNC that modification preparation is ready (


).

11. DRNC notifies SRNC that modification preparation is ready (


).

12. Node B (serving) notifies SRNC that modification preparation is ready (


).

Note: here a

Radio Link Reconfiguration Failure

could occur.

13. RNSAP message



14. NBAP message


is sent from DRNC to Node B (drift).

15. NBAP message


is sent from SRNC to Node B (serving).

16. RRC message

Radio Bearer Reconfiguration

is sent by controlling RNC (here SRNC) to UE.

17. Both UE and Nodes B actualise modification of DCH (i.e. applying a new transport format).


Radio Bearer Reconfiguration Complete

to SRNC.

19. SRNC acknowledges the modification of radio access bearer (


) towards CN.

ETSI


7.8.1.2

U E

R R C

R R C

41 ETSI TR 125 931 V5.3.0 (2006-03)

Synchronised DCH modification, Bandwidth decrease

N o d e B

D rift R N S

N o d e B

S e rv in g

D rift

R N C

S e rvin g

R N C

C N

R A N A P


R e q u est

R A N A P

2 . S e le c t L 1 , L 2 a n d Iu D a ta

T ra n sp o rt B e a re r p a ra m e ters

(e .g . fo r R a d io B e are r

N B A P

N B A P

4 . R a d io L in k R e c o nfig u ra tio n P re p a re

3 . R a d io L in k R e co n fig ura tio n

R N S A P

P re p a re

R N S A P

N B A P

N B A P

5 . R a d io L in k R e co n fig ura tio n P rep a re

6 . R a d io L in k R ec o n fig u ra tio n R e ad y

N B A P

N B A P

7 . R ad io L in k R e c o nfig u ratio n

R N S A P

R e a d y

R N S A P

N B A P

N B A P

8 . R a d io L in k R e c o n fig u ra tio n R ea d y

N B A P

9 . R a d io L in k R ec o n fig u ra tio n

R N S A P

C o m m it

R N S A P

1 0 . R a d io L in k R e c o nfig u ra tio n C o m m it

N B A P

N B A P

1 1 . R a d io L in k R e c o n fig u ra tio n C o m m it

N B A P

1 2 . R a d io B e are r R ec o n figu ra tio n (D C C H )

R R C

1 3 . A c tu a liz in g R a d io B ea re r m o d ifica tio n (e .g . A p p ly n e w tra n sp o rt fo rm a t se t)

1 4 . R a d io B ea re r R e c o nfig u ra tio n C o m p le te (D C C H )

1 5 . A L C A P Iu b D a ta T ra n sp o rt B e a re r M o d ify

R R C

1 5 . A L C A P Iu b D a ta T ra n sp o rt B e a re r M o d ify

1 5 . A L C A P Iu r D a ta T ran sp o rt

B e are r m o d ify

1 6 . A L C A P Iu D a ta

T ra nsp o rt B e are r M o d ify

1 7 . R A B A ssig n m en t

R e sp o n se

R A N A P R A N A P

Figure 20a: Radio Access Bearer Modification, Synchronised DCH Modification, Bandwidth decrease


Request.

Parameters: parameters to be modified at lower level e.g. Maximum Bit Rate.


3. SRNC requests DRNC to prepare modification of DCH carrying the radio access bearer (

Radio Link


).

Parameters: Transport Format Combination Set, UL scrambling code, Transport Bearer Request Indicator, etc.

4. DRNC requests its Node B to prepare modification of DCH related to the radio access bearer (

Radio Link


).

5. SRNC requests its Node B to prepare modification of DCH carrying the radio access bearer (

Radio Link


).

ETSI



Codes (TDD only), Transport Bearer Request Indicator.

6. Node B (drift) notifies DRNC that modification preparation is ready (


).

7. DRNC notifies SRNC that modification preparation is ready (


).

8. Node B (serving) notifies SRNC that modification preparation is ready (


).

Note: here a

Radio Link Reconfiguration Failure

could occur.



10. NBAP message


is sent from DRNC to Node B (drift).

11. NBAP message


is sent from SRNC to Node B (serving).

12. RRC message


is sent by controlling RNC (here SRNC) to UE.




to SRNC.

15. SRNC initiates modify of Iub (Serving RNS) Data Transport bearer. The same does DRNC with its own Iub.

SRNC initiates modify of Iur (Serving RNS) Data Transport bearer. In the case that ALCAP is implemented by

Q.AAL2 (Q.2630.2 but without modification procedure) it implies the release of the existing bearer and the establishment of a new one.

16. SRNC starts an Iu Data Transport Bearer Modification between the CN and the SRNC using the ALCAP protocol with AAL2 bindings carried by radio access bearer assignment message (this step is not required towards PS domain). This has to be done after the initialisation of the user plane mode.

17. SRNC acknowledges the modification of radio access bearer (


) towards CN.

7.8.2 DCCH on RACH/FACH

This example shows reconfiguration of a radio access bearer using a common transport channel (RACH/FACH). The difference with respect to the previous example is that here there is no macrodiversity because with a physical common channel (e.g. PRACH) it"s impossible to be on macrodiversity

ETSI


U E N o d e B R N C C N

1 . R A B A ssig n m en t

R eq u est

R A N A P

2 . S elect L 1 , L 2 a n d Iu D a ta

T ra n sp or t B ea rer p a ra m eter s

(e.g . R a d io B ea rer recon fig .)

3 . A L C A P Iu D a ta T r an sp ort

B ea rer M od ify

R A N A P

4 . R ad io B ea rer R econ fig u r a tion

R R C R R C

5 . A ctu a lizin g R a d io B ea rer m od ifica tio n (e.g . A p p ly n ew tr an sp o rt for m a t set)

6 . R a d io B ea rer R econ fig u ra tion

C om p lete

R R C R R C

7 . R A B A ssig n m en t

R esp on se

R A N A P R A N A P

.

Figure 21: Radio Access Bearer Modification – RACH/FACH Modification


Request.


3. RNC starts an Iu Data Transport Bearer Modification between the CN and the RNC using the ALCAP protocol with AAL2 bindings carried by radio access bearer assignment message (this step is not required towards PS domain). This has to be done before Radio Reconfiguration itself because the transport channel must be ready when the radio channel will be ready.


is sent by controlling RNC (here RNC) to UE. UE actualises modification of common transport channel (e.g. applying a new transport format).




to RNC.

7. RNC acknowledges the modification of radio access bearer (


) towards CN.

A radio access bearer modification procedure (via radio access bearer assignment message) is mapped with Radio

Bearer reconfiguration. Note that this is not possible if we want to change what transport channel or logical channel you use, because Radio Bearer reconfiguration does not permit a change in type of channel (see [8]).

7.9 Physical Channel Reconfiguration

7.9.1 Physical Channel Reconfiguration (DCH)

The following example shows an example for the Physical Channel Reconfiguration in dedicated channel (DCH) RRC state.

This procedure can be used, for example, to change the UL scrambling code of a UE.

ETSI


U E N od e B

D rift R N S

N B A P

N B A P

N B A P

N od e B

S erv in g R N S

D rift

R N C

S er vin g

R N C

1 . R a d io L in k R econ fig u r ation

R N S A P

P rep a r e

R N S A P

2 . R ad io L in k R econ fig u r a tion P r ep a re

N B A P

N B A P

3 . R a d io L in k R econ fig u r a tion P r ep a re

N B A P

4 . R ad io L in k R econ fig u r a tion R ea d y

N B A P

5 . R a d io L in k R econ fig u ra tion

R N S A P

R ea d y

R N S A P

N B A P

6 . R a d io L in k R econ fig u ra tion R ead y

N B A P

7 . R a d io L in k R econ fig u r ation

R N S A P

C om m it

R N S A P

8 . R a d io L in k R econ fig u r a tion C om m it

N B A P

9 . R a d io L in k R econ fig u r ation C om m it

N B A P

N B A P

1 0 . D C C H : P h ysica l C h a n n el R eco n fig u ra tio n

R R C

C N

R R C

1 1 . A ctu a liz in g m od ifica tio n

1 2 . D C C H : P h ysica l C h a n n el R eco n fig u ra tio n C om p lete

R R C

R R C

Figure 22: Physical Channel Reconfiguration (DCH)

1. SRNC decided that there is a need for a Physical Channel Reconfiguration and requests DRNC to prepare reconfiguration of DCH (Radio Link Reconfiguration Prepare).

Parameters: UL scrambling code (FDD only), Power control information.

2. DRNC requests its Node B to prepare reconfiguration of physical channel (

Radio Link Reconfiguration

Prepare

).

Parameters: Power control information, UL scrambling code (FDD only), Time Slots (TDD only), User Codes

(TDD only).

3. SRNC requests its Node B to prepare reconfiguration of physical channel (


Prepare

).

Parameters: Power control information, UL scrambling code (FDD only), Time Slots (TDD only), User Codes

(TDD only).

4. Node B allocates resources and notifies DRNC that the reconfiguration is ready (


Ready

).


Bearer.

5. DRNC notifies SRNC that the reconfiguration is ready (


).

Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iur Data Transport

Bearer.

6. Node B allocates resources and notifies SRNC that the reconfiguration is ready (


Ready

).


Bearer.

Parameters: CFN.





Parameters: CFN.



Parameters: CFN.

ETSI


10. RRC message

Physical Channel Reconfiguration


Parameters: UL scrambling code (FDD only), Time Slots (TDD only), User Codes (TDD only), CFN.

11. Both UE and Nodes B actualise modification of the physical channel.


Physical Channel Reconfiguration Complete

to SRNC.

7.9.2 Physical Channel Reconfiguration (CRNC Controlled)

This procedure shall be used to reconfigure the Physical Channel in the CRNC; in case of FDD it corresponds to the

Down Link Code Reconfiguration Procedure, while in TDD it allows to change either TS or User Code.

U E

R R C

N od e B

D rift R N S

N B A P

N B A P

N B A P

N od e B

S e rv in g R N S

D rift

R N C

S er vin g

R N C

1 . R a d io L in k Recon fig u r a tion P r ep a r e

N B A P

2 . Ra d io L in k R econ fig u r a tion Rea d y

N B A P

3 . P h ysica l C h an n el R econ fig u r atio n

R N S A P

R eq u est

RN S A P

4 . P h ysical C h a n n el R econ fig u r a tion

RN S A P

C om m an d

R N S A P

5 . R a d io L in k R econ fig u r a tion C om m it

N B A P

6 . D C C H : P h ysica l C h a n n el R econ fig u r ation

R RC

C N

7 . A ctu a liz in g m od ifica tion

8 . D C C H : P h ysica l C h an n el R econ fig u r atio n C om p lete

R R C

R RC

Figure 23: Physical Channel Reconfiguration (CRNC Controlled)

1. DRNC requests its Node B to reconfigure the physical channel (

Radio Link Reconfiguration Prepare

)

.

Parameters: Power control information, Time Slots (TDD only), User Codes (TDD only).



Ready

).


Bearer.

3. DRNC decides that a Physical Channel Reconfiguration is needed and sends the RNSAP message

Physical

Channel Reconfiguration Request

to the SRNC.

4. SRNC determines the CFN in which to perform the physical channel reconfiguration and sends the message

Physical Channel Reconfiguration Command.



Parameters: CFN.



Parameters: Time Slots (TDD only), User Codes (TDD only), CFN.

7. Both UE and Nodes B actualise modification of the physical channel.

8. After the reconfiguration, the UE sends RRC message


to SRNC.

This subclause presents some examples of soft handover procedures. The following cases are considered:

ETSI


•

Radio Link Addition (Branch Addition);

•

Radio link Deletion (Branch Deletion);

•

Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously).

Soft Handover applies only to FDD mode.

7.10.1 Radio Link Addition (Branch Addition)

This example shows establishment of a radio link via a Node B controlled by another RNC than the serving RNC. This is the first radio link to be established via this RNS, thus macro-diversity combining/splitting with already existing radio links within DRNS is not possible.

UE

Node B

Drift RNS

Drift

RNC

Serving

RNC

NBAP

2. Radio Link Setup

Request

Start RX description

NBAP

3. Radio Link Setup

Response

Decision to setup new RL

RNSAP

1. Radio Li nk Setup

Request

RNSAP

NBAP

NBAP

RNSAP

4. Radio Link Setup

Response

RN SAP

5. ALCAP Iub Bearer Setup ALCAP Iur Bearer Setup

NBAP

DCH FP

6. Radio Link Restore

Indication

NBAP

RNSAP



Indication

RNSAP

DCH FP


DCH FP DCH FP

Start TX description

10.

DCCH

: Active Set Update

[Radio Link Addition]

11.

DCCH

: Active Set Update Complete

RRC

RRC

RRC

RRC

Figure 24: Soft Handover - Radio Link Addition (Branch Addition)

1. SRNC decides to setup a radio link via a new cell controlled by another RNC. SRNC requests DRNC for radio resources by sending RNSAP message

Radio Link Setup Request

. If this is the first radio link via the DRNC for this UE, a new Iur signalling connection is established. This Iur signalling connection will be used for all

RNSAP signalling related to this UE.

Parameters: Cell id, Transport Format Set per DCH, Transport Format Combination Set, frequency, UL scrambling code.

2. If requested resources are available, DRNC sends NBAP message


to Node B.

Parameters: Cell id, Transport Format Set per DCH, Transport Format Combination Set, frequency, UL

ETSI


scrambling code.

Then Node B starts the UL reception.

3. Node B allocates requested resources. Successful outcome is reported in NBAP message


Response

.


Identitie(s)) for Data Transport Bearer(s).

4. DRNC sends RNSAP message


to SRNC.

Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Identity) for Data Transport

Bearer(s), Neighbouring cell information.

5. SRNC initiates setup of Iur/Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2


This may be repeated for each Iur/Iub Data Transport Bearer to be setup.

6./7. Node B achieves uplink sync on the Uu and notifies DRNC with NBAP message

Radio Link Restore

Indication

. In its turn DRNC notifies SRNC with RNSAP message

Radio Link Restore Indication.

8./9. Node B and SRNC establish synchronism for the Data Transport Bearer(s) by means of exchange of the appropriate DCH Frame Protocol frames

Downlink Synchronisation

and

Uplink Synchronisation

, relative already existing radio link(s). Then Node B starts DL transmission.

10. SRNC sends RRC message

Active Set Update

(Radio Link Addition) to UE on DCCH.

Parameters: Update type, Cell id, DL scrambling code, Power control information, Ncell information.

11. UE acknowledges with RRC message

Active Set Update Complete

.

NOTE: The order of transmission of


messages (steps 6 and 7) is not necessarily identical to that shown in the example. These messages could be sent before the ALCAP bearer setup

(step 5) or after the transport bearer synchronisation (steps 8 and 9).

7.10.2 Radio link Deletion (Branch Deletion)

This example shows deletion of a radio link belonging to a Node B controlled by another RNC than the serving RNC.

ETSI


U E

R R C

R R C

48 ETSI TR 125 931 V5.3.0 (2006-03)

N o d e B

D rift R N S

D rift

R N C

S erv in g

R N C

D e cisio n to d elete o ld R L

1 . D C C H : A ctiv e S et U p d ate

[R a d io L in k D eletio n ]

R R C

2 . D C C H : A c tiv e S e t U p d ate C o m p le te

R R C

N B A P

R N S A P

4 . R ad io L in k D eletio n

R e q u e st

N B A P

3 . R ad io L in k D e le tio n

R eq u est

R N S A P

S to p R X a nd T X

N B A P

5 . R ad io L in k D eletio n

R esp o n se

N B A P

R N S A P

6 . R a d io L in k D e le tio n

R e sp o n se

R N S A P

7 . A L C A P Iub B eare r R e le ase A L C A P Iu r B e arer R elea se

Figure 25: Soft Handover - Radio Link Deletion (Branch Deletion)

1. SRNC decides to remove a radio link via an old cell controlled by another RNC. SRNC sends RRC message


(Radio Link Deletion) to UE on DCCH.

Parameters: Update type, Cell id.

2. UE deactivates DL reception via old branch, and acknowledges with RRC message


Complete

.

3. SRNC requests DRNC to deallocate radio resources by sending RNSAP message

Radio Link Deletion

Request

.


4. DRNC sends NBAP message

Radio Link Deletion Request

to Node B.


5. Node B deallocates radio resources. Successful outcome is reported in NBAP message


Response

.


Radio Link Deletion Response

to SRNC.

7. SRNC initiates release of Iur/Iub Data Transport Bearer using ALCAP protocol.

7.10.3 Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously)

This example shows simultaneous deletion of a radio link belonging to a Node B controlled by the serving RNC and the establishment of a radio link via a Node B controlled by another RNC than the serving RNC. This is the first radio link to be established via this RNS, thus macro-diversity combining/splitting with already existing radio links within DRNS is not possible.

This procedure is needed when the maximum number of branches allowed for the macrodiversity set has already been reached.

ETSI


U E N o d e B

D r ift R N S

49 ETSI TR 125 931 V5.3.0 (2006-03)

N o d e B

S e r v in g R N S

D rift

R N C

S e rv in g

R N C

2 . R a d io L in k S e tu p R e q u e st

D e c is io n to se tu p n e w R L a n d re le a se o ld R L

R N S A P

1 . R a d io L in k S e tu p

R e q u e st

R N S A P

N B A P N B A P

S ta rt R X

N B A P

3 . R a d io L in k S e tu p R e sp o n se

N B A P

R N S A P

4 . R a d io L in k S e tu p

R e sp o n se

R N S A P

N B A P

D C H -F P

D C H -F P

5 . A L C A P Iu b D a ta T ra n sp o rt B e a re r S e tu p A L C A P Iu r B e a re r S e tu p

6 . R a d io L in k R e sto re In d ic a tio n

N B A P

R N S A P

7 . R a d io L in k R e sto re

In d ic a tio n

R N S A P

8 . D o w n lin k S y n c h ro n isa tio n

9 . U p lin k S yn c h ro n isa tio n

D C H -F P

D C H -F P

S ta rt T X

R R C

R R C

1 0 . D C C H : A c tiv e S e t U p d a te C o m m a n d

[ R a d io L in k A d d itio n & D e le tio n ]

1 1 . D C C H : A c tiv e S e t U p d a te C o m p le te

1 2 . R a d io L in k D e le tio n R e q u e s t

N B A P

S to p R X a n d T X

N B A P

1 3 . R a d io L in k R e le a se R e sp o n se

R R C

R R C

N B A P

N B A P

1 4 . A L C A P Iu b D a ta T ra n sp o rt B e a re r R e le a se

Figure 26: Soft Handover - Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously)

1.

⇒

9. See description 1.

⇒

9. in subclause 7.10.1.



(Radio Link Addition & Deletion) to UE on DCCH.


11. UE deactivates DL reception via old branch, activates DL reception via new branch and acknowledges with RRC message

Active Set Update Complete

.

12.

⇒

14. See description 3.

⇒

7. in subclause 7.10.2.

7.10.4 DSCH Mobility Procedure in Soft Handover (Moving DSCH within the Active Set)

Void.

ETSI


7.10.5 HS-DSCH Mobility Procedures

7.10.5.1 Intra-Node B synchronised serving HS-DSCH cell change

This subclause shows an example of an intra-Node B serving HS-DSCH cell change while keeping the dedicated physical channel configuration and the active set.

UE

Serving

Node B

Drift

RNC

Serving

RNC

RRC

RRC

NBAP

2. Radio Link

Reconfiguration Prepare

RNSAP

1. Radio Link

Prepare

NBAP

NBAP

3. Radio Link

Reconfiguration Ready

NBAP

4. Radio Link

Ready

RNSAP

RNSAP

RNSAP

NBAP

6. Radio Link

Reconfiguration Commit

5. Radio Link

Commit

RNSAP

NBAP

7. Physical Channel Reconfiguration

8. Physical Channel Reconfiguration Complete

RNSAP

RRC

RRC

Figure 26b: Intra-Node B synchronised serving HS-DSCH cell change

1.

The SRNC decides there is a need for a serving HS-DSCH cell change and prepares a RNSAP message

Radio

Link Reconfiguration Prepare

which is transmitted to the DRNC.

Parameters: a SRNC selected HS-PDSCH RL ID.

2.

In this case, both the source and target HS-DSCH cells are controlled by the same Node B. The DRNC requests the serving HS-DSCH Node B to perform a synchronised radio link reconfiguration using the NBAP message

Radio


. The reconfiguration comprises a transfer of the HS-DSCH resources from the source HS-DSCH radio link to the target HS-DSCH radio link.

Parameters: a DRNC selected HS-DSCH RNTI and the HS-PDSCH RL ID.

3.

The serving HS-DSCH Node B returns a NBAP message


.

Parameters: HS-DSCH Information Response.

4.

The DRNC returns a RNSAP message


to the SRNC.

Parameters: HS-DSCH Information Response and the DRNC selected HS-DSCH-RNTI.

5.

The SRNC now proceeds by transmitting RNSAP message


to the DRNC.

Parameters: SRNC selected activation time in the form of a CFN.

6.

The DRNC transmits a NBAP message


to the serving HS-DSCH Node B.

At the indicated activation time the serving HS-DSCH Node B stops HS-DSCH transmission to the UE in the source HS-DSCH cell and starts HS-DSCH transmission to the UE in the target HS-DSCH cell.


7.

The SRNC transmits a RRC message


to the UE.

Parameters: activation time, MAC-hs reset indicator, serving HS-DSCH radio link indicator, HS-SCCH set info and H-RNTI.

ETSI


8.

At the indicated activation time the UE, stops receiving HS-DSCH in the source HS-DSCH cell and starts HS-

DSCH reception in the target HS-DSCH cell. The UE then returns a RRC message

Physical Channel

Reconfiguration Complete

to the SRNC.

7.10.5.2 Inter-Node B (intra DRNC) synchronised serving HS-DSCH cell change

This subclause shows an ATM example of an inter-Node B serving HS-DSCH cell change while keeping the dedicated physical channel configuration and active set.

UE

RRC

RRC

Target

Node B

Source

Node B

Drift

RNC

Serving

RNC

NBAP

NBAP

NBAP

2. Radio Link

Reconfiguration Prepare

3. Radio Link

Reconfiguration Ready

NBAP

RNSAP


Prepare

RNSAP

NBAP

NBAP

4. Radio Link Reconfiguration Prepare

5. Radio Link Reconfiguration Ready

NBAP

NBAP

RNSAP


Ready

RNSAP

7. ALCAP Iub Data Transport Bearer Setup (HS-DSCH)

8. ALCAP Iur Data Transport

Bearer Setup (HS-DSCH)

NBAP

10. Radio Link

Reconfiguration Commit


Commit

RNSAP

RNSAP

NBAP

11. Radio Link Reconfiguration Commit

NBAP

NBAP


RRC

13. Physical Channel Reconfiguration Complete


Bearer Release (HS-DSCH)

RRC


Bearer Release (HS-DSCH)

Figure 26c: Inter-Node B (intra-DRNC) synchronised serving HS-DSCH cell change

1.

The SRNC decides there is a need for a serving HS-DSCH cell change and prepares the RNSAP message

Radio


which is transmitted to the DRNC. Parameters: a SRNC selected HS-PDSCH RL

ID.

2.

In this case, the source and target HS-DSCH cells are controlled by different Node Bs. The DRNC requests the source HS-DSCH Node B to perform a synchronised radio link reconfiguration using the NBAP message

Radio


, removing its HS-DSCH resources for the source HS-DSCH radio link.

Parameters: HS-DSCH MAC-d Flows To Delete.

3.

The source HS-DSCH Node B returns a NBAP message


.

Parameters:no HSDPA-specific parameters.

4.

The DRNC requests the target HS-DSCH Node B to perform a synchronised radio link reconfiguration using the

NBAP message


, adding HS-DSCH resources for the target HS-DSCH radio link.

Parameters: HS-DSCH Information, a DRNC selected HS-DSCH RNTI and the HS-PDSCH RL ID.

ETSI


5.

The target HS-DSCH Node B returns the NBAP message


.


6.

The DRNC returns the RNSAP message


to the SRNC.


7.

The DRNC initiates set-up of a new Iub Data Transport Bearers using ALCAP protocol. This request contains the

AAL2 Binding Identity to bind the Iub Data Transport Bearer to the HS-DSCH.

8.

The SRNC may initiate set-up of a new Iur Data Transport bearer using ALCAP protocol. This request contains the

AAL2 Binding Identity to bind the Iur Data Transport Bearer to the HS-DSCH.

9.

The HS-DSCH transport bearer to the target HS-DSCH Node B is established. The SRNC proceeds by transmitting the RNSAP message


to the DRNC.


10.

The DRNC transmits the NBAP message


to the source HS-DSCH Node B including the activation time. At the indicated activation time the source HS-DSCH Node B stops and the target

HS-DSCH Node B starts transmitting on the HS-DSCH to the UE.


11.



to the target HS-DSCH Node B including the activation time. At the indicated activation time the source HS-DSCH Node B stops and the target


Parameters: SRNC selected activation time in form of a CFN.

12.

The SRNC also transmits a RRC message


to the UE.

Parameters: activation time, MAC-hs reset indicator, serving HS-DSCH radio link indicator, HS-SCCH set info and H-RNTI.

13.

At the indicated activation time the UE stops receiving HS-DSCH in the source HS-DSCH cell and starts HS-

DSCH reception in the target HS-DSCH cell. The UE returns a RRC message


Complete

to the SRNC.

14.

The DRNC initiates release of the old Iub Data Transport bearer using ALCAP protocol.

15.

If a new Iur Data Transport Bearer was set up in 8. then the SRNC initiates release of the old Iur Data Transport bearer using ALCAP protocol.

This subclause presents some examples of hard handover procedures. These procedures are for both dedicated and common channels and may be applied in the following cases:

• intra-frequency Hard Handover (TDD mode);

• inter-frequency Hard Handover (FDD and TDD mode).

7.11.1 Backward Hard Handover

This subclause shows some examples of hard handover in the case of network initiated backward handovers.

7.11.1.1 Hard Handover via Iur (DCH State)

This subclause shows an example of Hard Handover via Iur, when the mobile is in DCH state, for both successful and unsuccessful cases. The text enclosed in brackets refers to the case when the UE has a DSCH (TDD).

ETSI


UE

RRC

RRC

53 ETSI TR 125 931 V5.3.0 (2006-03)

Node B

Source

NBAP

NBAP

NBAP

Node B

Target

SRNC

RNSAP

NBAP

1. Radio Link

Setup Request

Note 1

RNSAP

NBAP


NBAP


NBAP


RNSAP

5. RL Setup

Response

Note 1

RNSAP

7. DCCH : Physical Channel Reconfiguration

Note 3

8. Radio Link Failure Indication

NBAP

RNSAP

NBAP



Note 2

RNSAP

NBAP

RNSAP

11. RL Restore

Indication

Note 1

RNSAP

12. DCCH : Physical Channel Reconfiguration Complete

Note 3

6. ALCAP Iur Data

Transport Bearer Setup

Note 1

RRC

RNS AP 13. Radio Link Deletion Request

Note 2

RRC

RNSAP


NBAP


NBAP


RNC

Source

RNC

target

RNSAP


Note 2

18. ALCAP Iur Data


Note 2

RNSAP

Figure 27: Hard Handover via Iur (DCH on Iur) – successful case


message to the target RNC.

Parameters: target RNC identifier, s-RNTI, Cell id, Transport Format Set, Transport Format Combination Set,

[DSCH information (TDD only)]. (see note 1).

2. The target RNC allocates RNTI and radio resources for the RRC connection and the Radio Link(s) (if possible), and sends the NBAP message


to the target Node-B.


(FDD only), Time Slots (TDD only), User Codes (TDD only), Power control information, [DSCH information

(TDD only)] etc.

ETSI


3. Node B allocates resources, starts PHY reception, and responds with NBAP message


Response

.


Bearer, [DSCH information response (TDD only).].

4. Target RNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the

AAL2 Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of Iub Data

Transport bearer is acknowledged by Node B. [A separate transport bearer is established for the DSCH.]

5. When the Target RNC has completed preparation phase,


is sent to the SRNC (see note 1

).

[The message includes the DSCH information parameter (TDD only).]

6. SRNC initiates set-up of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur Data Transport Bearer to the DCH. The request for set-up of Iur Data Transport bearer is acknowledged by Target RNC (see note 1

).

[A separate transport bearer is established for the DSCH

(TDD only).]

7. SRNC sends a RRC message


to the UE.

8. When the UE switches from the old RL to the new RL, the source Node B detects a failure on its RL and sends a

NBAP message

Radio Link Failure Indication

to the source RNC.

9. The source RNC sends a RNSAP message


to the SRNC (see note 2

).

10. Target Node B achieves uplink sync on the Uu and notifies target RNC with NBAP message

Radio Link

Restore Indication

.

11. Target RNC sends RNSAP message


to notify SRNC (see note 2

)

that uplink sync has been achieved on the Uu.

12. When the RRC connection is established with the target RNC and necessary radio resources have been allocated, the UE sends RRC message


to the SRNC.

13. The SRNC sends a RNSAP message


to the source RNC (see note 2

).

14. The source RNC sends NBAP message


to the source Node B.


15. The source Node B de-allocates radio resources. Successful outcome is reported in NBAP message

Radio Link

Deletion Response

.

16. The source RNC initiates release of Iub Data Transport bearer using ALCAP protocol. [The DSCH transport bearer is released as well (TDD only).]

17. When the source RNC has completed the release the RNSAP message Radio Link Deletion Response is sent to the SRNC (see note 2

).

18. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur Data Transport Bearer to the DCH. The request for release of Iur Data Transport bearer is acknowledged by the Source RNC

(

see note 2

).

[The DSCH transport bearer is also released (TDD only).]

NOTE 1: This message is not necessary when the target RNC is the SRNC.

NOTE 2: This message is not necessary when the source RNC is the SRNC.

NOTE 3: The messages used are only one example of the various messages which can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in the

RRC specification (25.331), subclause 8.3.5.2.

ETSI


UE

RRC

RRC

Node B

Source

NBAP

NBAP

Node B

Target

RNC

Source

The first 6 steps are the same of the previous example

7. DCCH : Physical Channel Reconfiguration

Note 3

RNC

target

SRNC

RRC



NBAP

RNSAP

NBAP


Note 2

RNSAP

RNSAP

12. DCCH : Physical Channel Reconfiguration Failure

Note 3


Note 2

RNSAP

RRC

RNSAP

13. Radio Link

Deletion Request

Note 1

RNSAP

NBAP

14. Radio Link Deletion

NBAP


NBAP NBAP


RNSAP

17. Radio Link

Deletion Response

Note 1

RNSAP

18. ALCAP Iur Data


Note 1

Figure 28: Hard Handover via Iur (DCH on Iur) – unsuccessful case.

The first 6 steps are the same of the previous example.

7. SRNC sends a RRC message


to the UE.

8. When the UE switch from the old RL to the new RL, the source Node B detect a failure on its RL and send a

NBAP message


to the source RNC.



to the source RNC (see note 2)

.

10. UE cannot access the target cell and switch back to the old one. The source Node B detects a RL restoration and send a NBAP message

Radio Link Restoration Indication

to the source RNC.


Radio Link Restoration Indication


.

12. When the RRC connection is re-established with the source RNC the UE sends RRC message


Reconfiguration Failure

to the SRNC.



to the target RNC (see note 1).

14. The target RNC sends NBAP message


to the target Node B.


ETSI


15. The target Node B de-allocates radio resources. Successful outcome is reported in NBAP message

Radio Link


.

16. The target RNC initiates release of Iub Data Transport bearer using ALCAP protocol. [The DSCH transport bearer is released as well (TDD only).]

17. When the target RNC has completed the release the RNSAP message


is sent to the SRNC (see note 1).

18. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur Data Transport Bearer to the DCH. The Target RNC acknowledges the request for release of Iur Data Transport bearer (see note 1). [The DSCH transport bearer is also released (TDD only).]

NOTE 1: This message is not necessary when the target RNC is the SRNC.

NOTE 2: This message is not necessary when the source RNC is the SRNC.

NOTE 3: The messages used are only one example of the various messages which can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in the

RRC specification (25.331), clause 8.3.5.2.

7.11.1.2 Hard Handover with switching in the CN (UE connected to two CN nodes,

DCH state)

This example shows Inter-RNS Hard Handover with switch in CN, in a situation in which the UE is connected to two

CN nodes simultaneously node and will be using one node B directly under the target RNC after the hard handover.

ETSI


U E N o d e B

S o u rc e

N o d e B

T a rg et

R N C

S o u rc e

R N C

T a rg et

M S C /S G S N

R A N A P

R A N A P

1 . R e lo ca tio n R eq u ired

2 . R elo ca tio n R eq u ire d

R A N A P

R A N A P

3 . R e lo ca tio n R eq u es t

R A N A P

4 . R elo c atio n R e q u e st

R A N A P

S G S N /M S C

R A N A P

R A N A P

R R C

R R C

N B A P

6 . R a d io L in k S e tu p R eq u es t


T ran s p o rt B e are r S etu p

N B A P

7 . R ad io L in k S etu p R e sp o n s e

N B A P N B A P

8 . A L C A P Iu b D a ta T ran s p o rt B e are r S etu p

9 . R elo ca tio n R eq u es t

R A N A P

A c k n o w led g e

R A N A P

R A N A P

1 0 . R elo ca tio n R eq u es t

A c k n o w le d g e

R A N A P

R A N A P

1 3 . D C C H : P h ys ica l C h a n n el R ec o n fig u ratio n N o te 1

R R C

1 4 . R ad io L in k R es to re In d ica tio n

N B A P

1 1 . R e lo c a tio n C o m m an d

R A N A P

1 2 . R elo c atio n C o m m a n d

N B A P

R A N A P

1 5 . R e lo c atio n

D e tec t

R A N A P

1 6 . R e lo ca tio n D ete ct

R A N A P

1 7 . R ad io L in k F a ilu re In d ic atio n

N B A P N B A P

1 8 . D C C H : P h ys ica l C h a n n el R ec o n fig u ratio n C o m p lete N o te 1

R R C

R A N A P

R A N A P

1 9 . R elo c atio n

C o m p lete

R A N A P

2 0 . R e lo c atio n C o m p le te

R A N A P

R A N A P

2 1 . Iu R e le as e C o m m an d

2 2 . Iu R e lea se C o m m an d

R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

2 3 . A L C A P Iu D ata T ra n s p o rt B ea rer

R e lea se

2 4 . Iu R e le as e C o m p le te

R A N A P R A N A P

2 5 . Iu R ele as e C o m p le te

R A N A P R A N A P

Figure 29: Hard Handover with switching in the CN (UE connected to two CN nodes, DCH state)

Serving RNC makes the decision to perform the Hard Handover via CN. Serving RNC also decides into which RNC

(Target RNC) the Serving RNC functionality is to be relocated.

Relocation Required

messages to both CN nodes.

Parameters: target RNC identifier, Information field transparent to the CN node and to be transmitted to the target

RNC.

Upon reception of


message CN element prepares itself for the switch and may also suspend data traffic between UE and itself for some bearers.

3./4. When CN is aware of preparation, CN node conveys a

Relocation Request

message to the target RNC to allocate resources.

Parameters: bearer ID's requested to be rerouted towards the CN node, from which the


originated.

CN indicates in the message whether it prefers point to multipoint type of connections within CN or hard switch in CN. In this example the latter is assumed.

ETSI


Target RNC allocates necessary resources within the UTRAN to support the radio links to be used after completion of the Hard Handover procedure.

5. Target RNC and CN node establish the new Iu transport bearers for each Radio Access Bearer related to the CN node.

6./7./8. The target RNC allocates RNTI and radio resources for the RRC connection and the Radio Link, then sends the NBAP message




(FDD only), Time Slots (TDD only), User Codes (TDD only), Power control information etc.

Node B allocates resources, starts PHY reception, and responds with NBAP message


Response

. Target RNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to the DCH.

9./10. When RNC has completed preparation phase,

Relocation Request Acknowledge

is sent to the CN elements.

Parameters: transparent field to the CN that is to be transmitted to the Source RNS.

11./12. When CN is ready for the change of SRNC, CN node sends a

Relocation Command

to the RNC. Message contains the transparent field provided by Target RNC.

Parameters: information provided in the Information field from the target RNC.

13. Source RNC sends a RRC message


to the UE.

14. Target Node B achieves uplink sync on the Uu and notifies target RNC with NBAP message

Radio Link

Restore Indication

.

15./16. When target RNC has detected the UE, Relocation Detect message is sent to the CN nodesTarget RNC switches also the connection towards the new Iu, when UE is detected. After the switch UL traffic from node-B's is routed via the newly established MDC to the new MAC/RLC entities and finally to the correct Iu transport bearer. DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to the

MD-splitter and Nodes B

17. When the UE switch from the old RL to the new RL, the source Node B detect a failure on its RL and send a

NBAP message


to the source RNC.

18. When the RRC connection is established with the target RNC and necessary radio resources have been allocated the UE sends RRC message


to the target RNC.

19./20 After a successful switch and resource allocation at target RNC, RNC sends

Relocation Complete

messages to the involved CN nodes.

At any phase, before the


message is sent, the old communication link between the CN and

UE is all the time existing and working and the procedure execution can be stopped and original configuration easily restored. If any such unexceptional thing occurs a

Relocation Failure

message may be sent instead of any message numbered 3-10 and 13-15 described in this above.

21./22. The CN node initiates the release of the Iu connections to the source RNC by sending RANAP message

Iu

Release Command

.

23. Upon reception of the release requests from the CN nodes the old SRNC executes all necessary procedures to release all visible UTRAN resources that were related to the RRC connection in question.

24./25. SRNC confirm the IU release to the CN nodes sending the message

Iu Release Complete.

NOTE 1: The messages used are only one example of the various messages which can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in the RRC specification (25.331), subclause 8.3.5.2.

ETSI


7.11.1.3 Inter-Node B synchronised serving HS-DSCH cell change at hard handover

This subclause shows ATM examples of hard handover combined with an inter-Node B serving HS-DSCH cell change.

7.11.1.3.1 Inter-Node B (intra DRNC) synchronised serving HS-DSCH cell change at hard handover

In the following example the HS-DSCH mobility procedure is performed in two steps: the first step consists of establishing a new radio link without the HS-DSCH resources; the next step is a transfer of the HS-DSCH resources to this new radio link followed by a release of the old radio link. In the radio interface, a combined procedure is used.

ETSI


UE Node B

Target

Node B

Source

Drift

RNC

Ser ving

RNC

2. R adio Link Setup Reque st

RNSAP

1. R adio Link Addition

Request

RNSAP

NBAP NBAP

NBAP

3. R adio Link Setup Response

NBAP

RNSAP

4. R adio Link Addition

Response

RNSAP

RRC

RRC

5. ALCAP Iub Data Transport Beare r Setup (DCH)


Bea rer S etup (DCH)

7. R adio Link Rec onfiguration

Pre par e

RNSAP

RNSAP

NBAP

NBAP

NBAP

NBAP

8. R adio Link

Rec onfiguration P repare

9. R adio Link

Rec onfiguration R eady

10. R adio Link Rec onfiguration P repare

11. Radio Link Reconfiguration Rea dy

NBAP

NBAP

NBAP

NBAP


Rea dy

RNSAP

RNSAP

13. ALC AP Iub Data Tra nsport B earer Setup ( HS- DSC H)


Bea rer S etup (HS-DSCH)


Comm it

RNSAP

RNSAP

NBAP

16. Radio Link

Rec onfiguration C om mit

NBAP

17. R adio Link Rec onfiguration C om mit

NBAP

NBAP

18. P hysica l Cha nnel Rec onfiguration

19. P hysica l Cha nnel Rec onfiguration C om plete

RRC

RRC

20. ALC AP Iub Data Tra nsport

Bea rer R ele ase (HS-DSCH)

23. Radio Link

Deletion Reque st

21. ALC AP Iur Data Transport

Bea rer R ele ase (HS-DSCH)

RNSAP

22. Radio Link De letion

Request

RNSAP

NBAP

NBAP

24. Radio Link

Deletion Response

NBAP

NBAP

RNSAP

25. Radio Link De letion

Response

RNSAP

26. ALC AP Iub Data Tra nsport

Bea rer R ele ase (DCH)

27. ALC AP Iur Data Transport

Bea rer R ele ase (DCH)

Figure 29a: Inter-Node B (intra DRNC) synchronised serving HS-DSCH cell change at hard handover

1.

The SRNC decides that there is a need for a hard handover combined with a serving HS-DSCH cell change. It prepares a RNSAP message

Radio Link Addition Request

, which is transmitted to the DRNC.

Parameters: target cell ID.

2.

The DRNC allocates radio resources for the new radio link and requests the target Node B to establish a new radio link by transmitting a NBAP message

Radio Link Setup Request.

Parameters: no HSDPA-specific parameters.

ETSI


3.

The target Node B allocates resources, starts physical layer reception on the DPCH on the new radio link and responds with the NBAP message


.


4.

The DRNC responds to the SRNC with the RNSAP message

Radio Link Addition Response

and the DCH transport bearer is established.

5.


AAL2 Binding Identity to bind the Iub Data Transport Bearer to the DCH.

6.

In case of no combination in the DRNC, the SRNC initiates set-up of a new Iur Data Transport Bearer using

ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur Data Transport Bearer to the

DCH.

7.

As the next step, the SRNC prepares the RNSAP message


which is transmitted to the DRNC.

Parameters: SRNC selected HS-PDSCH RL ID.

8.

The DRNC requests the source HS-DSCH Node B to perform a synchronised radio link reconfiguration using the

NBAP message


, removing its HS-DSCH resources for the source HS-

DSCH radio link.

Parameters: HS-DSCH MAC-d Flows To Delete.

9.

The source HS-DSCH Node B returns the NBAP message


.


10.

The DRNC requests the target HS-DSCH Node B to perform a synchronised radio link reconfiguration using the

NBAP message


, adding HS-DSCH resources for the target HS-DSCH radio link.

Parameters: HS-DSCH information including an HS-PDSCH RL ID and a DRNC selected HS-DSCH RNTI.

11.

The target HS-DSCH Node B returns the NBAP message


.


12.



to the SRNC.

Parameters: HS-DSCH information response and the DRNC selected HS-DSCH-RNTI.

13.


AAL2 Binding Identity to bind the Iub Data Transport Bearer to the HS-DSCH.

14.

The SRNC may initiate set-up of a new Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur Data Transport Bearer to the HS-DSCH.

15.

The HS-DSCH transport bearer to the target HS-DSCH Node B is established. The SRNC proceeds by transmitting the RNSAP message


to the DRNC including an SRNC selected activation time in the form of a CFN.


16.



to the source HS-DSCH Node B including the activation time. At the indicated activation time the source HS-DSCH Node B stops and the target



17.



to the target HS-DSCH Node B including the activation time. At the indicated activation time the source HS-DSCH Node B stops and the target


Parameters: SRNC selected activation time in the form of a CFN

18.

The SRNC also transmits a RRC message


to the UE.

Parameters: activation time, DPCH information for the target cell, MAC-hs reset indicator, serving HS-DSCH radio link indicator, HS-SCCH set info and H-RNTI.

19.

At the indicated activation time the UE abandons the current active set and initiates establishment of the DPCH in the target cell. When physical layer synchronisation is established in the target cell, it starts DPCH reception and

ETSI


transmission and HS-DSCH reception in the target cell. The UE returns the RRC message



to the SRNC.

20.

The DRNC initiates release of the old Iub Data Transport bearer to the source HS-DSCH Node B using ALCAP protocol.

21.

If a new Iur Data Transport Bearer was set up in 14. then the SRNC initiates release of the old Iur Data Transport bearer using ALCAP protocol.

22.

The SRNC then finalises the procedure by transmitting the RNSAP message


to the

DRNC.

In the message the source cell to be deleted is identified.

Parameters: RL ID.

23.




Parameters: RL ID.

24.

The source Node B releases resources for the source radio link and returns the NBAP message

Radio Link


to the DRNC.

25.



to the SRNC.

26.

The DRNC initiates release of the old Iub DCH Transport bearer to the source HS-DSCH Node B using ALCAP protocol.

27.

If a new Iur Data Transport Bearer was set up in 6. then the SRNC initiates release of the old Iur DCH Transport bearer using ALCAP protocol.

7.11.1.3.2 Inter-Node B (inter DRNC) synchronised serving HS-DSCH cell change at hard handover

In this second example the source Node B and the target Node B are controlled by two different DRNCs, referred to as source DRNC and target DRNC, respectively. In this case the HS-DSCH mobility procedure is performed in a single step.

ETSI


UE

RRC

RRC

Node B

Source

NBAP

NBAP

Node B

Target

RNC

Source

RNC

Target

SRNC


RNSAP

1. Radio Link

Setup Request

RNSAP

NBAP NBAP

NBAP

3. Radio Link Setup R esponse

5. ALCAP Iub Dat a Transport Bearer Setup (DCH +HS-DSCH)

NBAP

RNSAP

4. RL Setup

Response

6. ALCAP Iur Data


(DCH +HS-DSCH)

RNSAP


8. Physical Channel Reconfiguration C omplet e

RR C

RRC

9. Radio Link Del etion R equest

RNSAP

RNSAP

10. Radio Link Del etion Request

NBAP

11. Radio Link Del etion R espons e

NBAP

RNSAP

12. Radio Link Del etion Respons e

RNSAP

13. ALCAP Iub Dat a Transport Bearer Release (DCH +HS-DSCH)

14. ALCAP Iur Data

Transport Bearer R elease (DC H + HS-DSC H)

Figure 29b: Inter-Node B (inter DRNC) synchronised serving HS-DSCH cell change at hard handover

1.

The SRNC decides that there is a need for hard handover combined with serving HS-DSCH cell change. It prepares the RNSAP message


, which is transmitted to the target DRNC.

Parameters: HS-DSCH information and HS-PDSCH RL ID.

2.

The target DRNC allocates radio resources for the new radio link and requests the target Node B to establish a new radio link by transmitting the NBAP message


.

Parameters: HS-DSCH information, HS-DSCH-RNTI and HS-PDSCH RL ID.

3.

The target Node B allocates resources, starts physical layer reception on the DPCH on the new radio link and responds with the NBAP message


.


4.

The target DRNC responds to the SRNC with the RNSAP message


.

Parameters: HS-DSCH Information Response and HS-DSCH-RNTI.

5.

The DRNC initiates the setup of Iub DCH and HS-DSCH Data Transport bearers to the target HS-DSCH Node B using ALCAP protocol.

6.

The SRNC initiates the setup of Iur DCH and HS-DSCH Data Transport bearers.

7.

The SRNC transmits the RRC message


to the UE.

Parameters: activation time, DPCH information for the target cell, MAC-hs reset indicator, serving HS-DSCH radio link indicator, HS-SCCH set info and H-RNTI.

8.

At the indicated activation time the UE abandons the current active set and initiates establishment of the DPCH in the target cell. When physical layer synchronisation is established in the target cell, it starts DPCH reception and

ETSI


transmission and HS-DSCH reception in the target cell. The UE returns the RRC message



to the SRNC.

9.

The SRNC then finalises the procedure by transmitting the RNSAP message


to the source DRNC.

In the message the source cell to be deleted is identified.

Parameters: RL ID.

10.

The source DRNC transmits the NBAP message



Parameters: RL ID.

11.

The source Node B releases resources for the source radio link and returns the NBAP message

Radio Link


to the source DRNC.

12.

The source DRNC returns the RNSAP message


to the SRNC.

13.

The DRNC initiates the release of the old Iub DCH and HS-DSCH Data Transport bearers to the target HS-DSCH

Node B using ALCAP protocol.

14.

The SRNC initiates the release of the old Iur DCH and HS-DSCH Data Transport bearers.

7.11.2 Forward Hard Handover

This subclauses shows some examples of hard handover in the case of mobile initiated forward handovers.

Some examples of Cell Update procedures are shown, i.e. those procedures that update the position of the UE when a

RRC connection exists and the position of the UE is known on cell level in the UTRAN. The UE is in CELL_PCH or

CELL_FACH.

7.11.2.1 Cell Update with SRNS relocation

This example shows Inter-RNS Cell Update with switching in the CN (therefore with SRNS relocation) and RNTI reallocation.

UE

RRC

1.

CCCH:

Cell Update

[Cell Update Cause,U RNTI,

Measured results on PRACH]

Target RNC

Source RNC

RRC relay

RNSAP

2. Uplink Signalling

Transfer Indicatio

n

RNSAP

[new C RNTI, D RNTI,

UL message]

CN

3. Serving RNC Relocation

RRC

4.

DCCH:

Cell Update Confirm

[S RNTI, SRNC ID, new S RNTI,

new SRNC ID, new C RNTI]

RRC

5.

DCCH

: UTRAN Mobility Information Confirm

RRC

RRC

Figure 30: Cell Update with SRNS Relocation

1. UE sends a RRC message Cell Update to the UTRAN, after having made cell re-selection. Upon reception of a

CCCH message from a UE, target RNC allocates a C-RNTI for the UE.

ETSI


2. Controlling target RNC forward the received message (on CCCH) via

Uplink Signalling Transfer Indication

RNSAP message towards the SRNC. Message includes, besides target RNC-ID, also the allocated C-RNTI, which is to be used as UE identification within the C-RNC, and the D-RNTI. Upon reception of the RNSAP message SRNC decides to perform SRNS Relocation towards the target RNC.

3. Serving RNC relocation procedure is executed as defined in subclause "SRNS Relocation Relocation (UE connected to a single CN node)". After completing SRNS Relocation, target RNC allocates new S-RNTI for the

UE, becoming the new serving RNC.

4. Target RNC responds to UE by RRC

Cell Update Confirm

, including old S-RNTI and SRNC ID as UE identifiers. Message contains also the new S-RNTI, SRNC-ID and C-RNTI.

5. UE acknowledges the RNTI reallocation by sending the RRC message

UTRAN Mobility Information

Confirm

.

7.11.2.2 Cell Update via Iur without SRNS relocation

This example shows an Inter RNS cell update in DRNS without SRNS relocation when no Iur RACH/FACH transport bearer exists. In this example target DRNS, source DRNS and serving RNS are all located separately from each other.

Other scenarios can be easily derived from this most comprehensive signalling procedure.

UE DRNC source

1. CCCH: Cell Update

DRNC target

SRNC

RRC

RRC-relay

RNSAP

2. Uplink Signalling Transfer

Indication

[new C-RNTI,D-RNTI,

UL message]

RNSAP

3. Common Transp. Channel Resources

Initialization Request

RNSAP RNSAP


Initialization Response

RNSAP RNSAP

RRC

RRC

6. DCCH: Cell Update Confirm

7. DCCH: UTRAN Mobility Information Confirm

5. ALCAP Iur bearer setup

RRC

RRC

RNSAP

8. Common Transp. Channel Resources Release

RNSAP

Figure 31: Cell Update via Iur without SRNS Relocation

1. UE sends an RRC message Cell Update to the UTRAN (Target DRNC), after having made cell re-selection.

2. Upon reception of a CCCH message from a UE, the target DRNC decodes the SRNC-ID and the S-RNTI. The

UE is not registered in the target DRNC, thus the target DRNC allocates C-RNTI and D-RNTI for the UE. The target DRNC forwards the received uplink CCCH message towards the SRNC in the RNSAP

Uplink Signalling

ETSI


Transfer Indication

message. The Uplink Signalling Transfer message includes also the cell-ID of the cell from which the CCCH message was received, the D-RNC ID and the allocated C-RNTI and D-RNTI.

3. Upon reception of the Uplink Signalling Transfer message the SRNC decides not to perform an SRNS

Relocation towards the target RNC. The SRNC initialises the UE context in the target RNC with the

RNSAP

Common Transport Channel Resources Initialisation Request

message. The message includes the D-RNTI and the cell identity previously received in the Uplink Signalling Transfer indication message, as well as a request for transport layer address and binding identity if there exists no appropriate Iur transport bearer to be used for the UE.

4. The target DRNC sends the transport layer address, binding identity and optionally PHY parameters (FACH code, ) to the SRNC with the RNSAP

Common Transport Channel Resources Initialisation Response

message

5. If there does not already exist an appropriate Iur transport bearer to be used for the UE, a transport bearer is established from the SRNC.

6. The SRNC sends RRC


to the UE. The message is sent in the Iur user plane. It will be sent by the target DRNC to the UE on the FACH coupled to the RACH. Subsequent FACH data may be sent on a different FACH if so decided by the target DRNC.



Confirm

.

8. The SRNC releases the UE context in the source DRNC by sending a

Common Transport Channel Resources

Release

message. The source DRNC releases the D-RNTI.

7.11.2.3 Cell Update via Iur without SRNS relocation (with C-RNTI reallocation)

This example is similar to the previous one (7.11.2.2) with minor changes. It shows a cell update in DRNS without

SRNS relocation when an Iur RACH/FACH transport bearer exists and the UE is already known in the DRNS. The

DRNC decides to allocate a new C-RNTI for the UE but not a new D-RNTI because D-RNC does not change.

Therefore the two columns DRNC of picture 31 merge themselves to represent this case.

7.11.2.4 Cell Update via Iur with USCH/DSCH, without SRNS relocation

This example shows an inter-RNS cell update without SRNS relocation, when the UE is in Cell_FACH state and has been allocated DSCH and USCH (TDD) before the Cell Update and when no Iur RACH/FACH transport bearer exists.

In this example target RNS, source RNS and serving RNS are all located separately from each other. The procedure includes an implicit release of the USCH and DSCH, which includes release of the Radio Link in the old cell. A potential restoration of USCH and DSCH after the cell update, triggered by the SRNC, is not shown.

ETSI


UE

RRC

RRC

RRC

Node B

Source

NBAP

Node B

Target

1.

CCCH

: Cell Update

DRNC

Source

DRNC

target

SRNC

6.

DCCH

: Cell Update Confirm

RRC

Decoding of RNC ID from the UL message and allocation of C RNTI + D RNTI

RNSAP

2. Uplink Signaling

Transfer Indication

RNSAP

RNS AP

3. Common

Transport Channel

Resources Request

RNSAP

4. Common

Transport Channel

Resources Response

RNSAP

RNSAP

5. ALCAP Iur Data


Note 1

RRC

7.

DCCH

: UTRAN Mobility Information Confirm


RNSAP

RNSAP


Note 2

9. Common Trans. Channel Resource Release

Note 2

NBAP

RRC

RNSAP

RNSAP

NBAP


NBAP

12. ALCAP Iub Data Tran sport Bearer Release

RNSAP 13. Radio Link Deletion Response

Note 2

14. ALCAP Iur Data


Note 2

RNSAP

NOTE 1: These messages are not necessary if the Target RNC and the SRNC are identical.

NOTE 2: These messages are not necessary if the Source RNC and the SRNC are identical.

Figure 32: Backward Cell Update via Iur (Cell_FACH State with USCH/DSCH) – successful case.

1. When the UE decides that a cell update is necessary, it sends an RRC message

Cell Update

to the Target RNC.

This is a

CCCH

message carried on the

RACH

in the new cell. Upon reception of a CCCH message from a UE, the target DRNC decodes the SRNC ID and the S-RNTI. Supposing that the UE is not registered in the target

DRNC (RNC ID and SRNTI unknown), the target DRNC allocates a C-RNTI and a D-RNTI for the UE.

2. The Target RNC forwards the

Cell Update

to the SRNC via an RNSAP

Uplink Signaling Transfer

message

(see note 1). The Uplink Signalling Transfer message includes also the cell-ID of the cell from which the CCCH message was received, the D-RNTI and the allocated C-RNTI. Upon reception of the Uplink Signalling Transfer message the SRNC decides not to perform a SRNS Relocation towards the target RNC.

3. The SRNC initialises the UE context in the target RNC with the

RNSAP Common Transport Channel

Resource Request

message. The message includes the D-RNTI and the cell identity previously received in the

Uplink Signalling Transfer indication message, as well as a request for transport layer address and binding identity if there exists no appropriate Iur transport bearer to be used for the UE (see note 1)

ETSI


4. The Target RNC responds with an RNSAP message

Common Transport Channel Resources Response

including the transport layer address, binding identity and optionally PHY parameters (FACH code, ..) (see note

1).

5. If there does not already exist an appropriate Iur transport bearer to be used for the UE, a transport bearer is established from the SRNC (see note 1).

6. The SRNC sends an RRC message


within the

DCCH

on

FACH

to the UE. The message is sent in the Iur user plane. It will be sent by the target DRNC to the UE on the FACH coupled to the RACH.

Subsequent FACH data may be sent on a different FACH if so decided by the target DRNC.



Confirm

.

8. The SRNC releases the UE context in the source DRNC by sending a

Common Transport Channel Resource

Release

message. The source DRNC releases the D-RNTI (see note 2)

.

9. The SRNC sends an RNSAP message



.

10. The source RNC sends NBAP message




11. The source Node B deletes the previous Radio link and the Communication Context. Successful outcome is reported in NBAP message


.

12. The source RNC initiates release of the corresponding Iub Data Transport bearers using ALCAP protocol.

13. When the source RNC has completed the release, the RNSAP message


is sent to the SRNC (see note 2)

.

14. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. The request for release of Iur Data

Transport bearer is acknowledged by the Source RNC (see note 2)

.

This subclause presents some examples of URA Update procedures, i.e. those procedures that update the UTRAN registration area of a UE when a RRC connection exists and the position of the UE is known on URA level in the

UTRAN.

7.12.1 Inter-RNS URA Update with SRNS Relocation

This example shows Inter-RNS URA Update with switching in the CN (SRNS relocation).

ETSI


UE

Target

RNC

Serving

RNC

1.CCCH: URA Update

RRC

[U-RNTI, URA update cause]

RRC-relay

2. Uplink Signalling Transfer Indication

RNSAP RNSAP

[C-RNTI,D-RNTI, UL message]

ETSI TR 125 931 V5.3.0 (2006-03)

CN

3. Serving RNC Relocation

RRC

4.CCCH: URA Update Confirm

[S-RNTI, SRNC-ID, new S-RNTI, new SRNC-ID]

RRC

RRC

5.DCCH: UTRAN Mobility Information Confirm

RRC

Figure 33: Inter RNS URA Update with switching in CN.

1. UE sends a RRC message URA Update to the UTRAN, after having made cell re-selection. Upon reception of a

CCCH message from an unknown UE, the target RNC becomes a controlling RNC and it allocates a new C-

RNTI and a new D-RNTI for the UE.

2. The target RNC forwards the received uplink CCCH message towards the SRNC by RNSAP

Uplink Signalling

Transfer Indication

message to the old Source/Controller RNC. Message includes, besides target RNC-ID, also the allocated C-RNTI, which is to be used as UE identification within the C-RNC, and the D-RNTI. Upon reception of the RNSAP message SRNC decides to perform SRNS Relocation towards the target RNC.

3. Serving RNC relocation procedure is executed as defined in subclause 'SRNS Relocation (UE connected to a single CN node)'. After having completed SRNS Relocation, target RNC allocates new S-RNTI for the UE becoming the new serving RNC. New SRNC also deletes the allocated C-RNTI, since it is not needed for an UE in URA_PCH state.

4. Serving RNC acknowledges the message by RRC

URA Update Confirm

, including old S-RNTI and SRNC ID as UE identifiers. Message contains also the new S-RNTI and RNC-ID.


UTRAN Mobility Information Confirm

on DCCH.

7.12.2 Inter-RNS URA Update via Iur without SRNS relocation

This example shows an Inter RNS URA update in DRNS without SRNS relocation. In this example target RNS, source

RNS and serving RNS are all located separately from each other. Other scenarios can be easily derived from this most comprehensive signalling procedure.

Please note that this example shows the case when no ciphering is required; for this case no channels on Iur are required and therefore the message flow 5 (Cell Update Confirm) is sent on CCCH. In the case that ciphering is required, that message must be sent on the DCCH (ciphering is performed at MAC-d level) and the flow becomes similar to the one shown for the Cell Update in section "Cell Update via Iur without RNS relocation".

ETSI


UE

RRC

70

Source

RNC

1.CCCH: URA Update

[U-RNTI, URA update cause]

ETSI TR 125 931 V5.3.0 (2006-03)

Target

RNC

Serving

RNC

RRC-relay

2. Uplink Signalling Transfer Indication

RNSAP RNSAP

[new C-RNTI,D-RNTI, UL message]

3. Decision Not to perform SRNS relocation

RNSAP

4. Downlink Signalling Transfer Request

RNSAP

5.CCCH: URA Update Confirm

RRC RRC-relay

Figure 34: Inter-RNS URA Update via Iur without SRNS relocation

1. UE sends a RRC message URA Update to the UTRAN, after having made cell re-selection and URA has changed.

2. Upon reception of the message from a UE, Target RNC decodes the RNC ID and the S-RNTI. The UE is not registered in the target RNC (RNC ID and SRNTI unknown), thus RNC allocates C-RNTI and D-RNTI for the

UE. The Target RNC forward the received Uu signalling message towards the SRNC by RNSAP

Uplink

Signalling Transfer Indication

message. The message includes also the cell-ID from which the message was received and the allocated C-RNTI and D-RNTI.

3. Upon reception of the RNSAP message SRNC decides not to perform an SRNS relocation towards the target

RNC. The target RNC become C-RNC while SRNC remains unchanged.

4. SRNC delivers to Target RNC information upon, eventually new, RNTIs via a

Downlink Signalling Transfer

Request

, transporting a URA Update Confirm.

URA Update Confirm

is forwarded to the UE (via CCCH with new RNTIs) from the target RNC.

7.12.3 SRNS Relocation (UE connected to two CN nodes)

This example show SRNS Relocation, in situation in which the UE is connected to two CN nodes simultaneously (this means that RNC is connected to a SGSN and a MSC). It is assumed that:

• all cells in the active set are in one DRNC;

• the CN performs hard switching of the user traffic.

ETSI


U E N o d e B

71 ETSI TR 125 931 V5.3.0 (2006-03)

R N C

S o u rc e

R A N A P

R A N A P

R N C

T a rg e t

M S C /S G S N

1 . R e lo c a tio n R e q u ire d

2 . R e lo c a tio n R e q u ire d

R A N A P

R A N A P 3 . R e lo c a tio n R e q ue st

R A N A P

4 . R e lo c a tio n R e q ue st

R A N A P

S G S N /M S C

R A N A P

R A N A P


T ra nsp o rt B e a re r S e tup

R A N A P

6 . R e lo c a tio n

R e q ue st A c k.

R A N A P

7 . R e lo c a tio n R e q u e st A c k.

R A N A P

8 . R e lo c a tio n C o m m a nd

R A N A P

R A N A P

R N S A P

1 0 . R e lo c a tio n

C o m m it

9 . R e lo c a tio n C o m m a nd

R N S A P

R A N A P

1 1 . R e lo c a tio n D e te c t

R A N A P

R A N A P

1 2 . R e lo c a tio n D e te c t

R A N A P

1 3 . R e lo c a tio n C o m p le te

R A N A P

1 4 . R e lo c a tio n

C o m p le te

R A N A P

1 5 . Iu R e le a se C o m m a nd

R A N A P

R A N A P

1 6 . Iu R e le a se C o m m a nd

R A N A P R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

R A N A P

1 7 . A L C A P Iu D a ta T ra n sp o rt B e a re r R e le la se

1 8 . Iu R e le a se C o m p le te

1 9 . Iu R e le a se C o m p le te

R A N A P

R A N A P

Figure 35: SRNS Relocation (UE connected to two CN nodes)

Note that the SRNC makes the decision to perform the Serving RNC relocation procedure. The Serving RNC also decides into which RNC (Target RNC) the Serving RNC functionality is to be relocated.

1./2. The source SRNC sends


messages to both CN nodes.

Parameters: target RNC identifier, Information field that the CN node(s) shall pass transparently to the target

RNC. This transparent field contains the UE identifier, number of CN nodes and other data.

Upon reception of


message the CN element prepares itself for the switch and may also suspend user data traffic and/or signalling between UE and itself for some bearers.

3./4. When preparation is completed the CN node conveys a


message to the target RNC.

Parameters: indication of which bearers should be routed towards this CN node, transparent information field sent by the source RNC, UE identifier.

The target RNC uses the UE identifier to link the requests from multiple CN nodes to each other and to the resources (e.g. Iub links) that the UE is currently using.

5. The targets RNC and CN node establish the new Iu transport bearers for each Radio Access Bearer related to that CN node.

ETSI


6./7. When the source RNC and the target RNC have completed its preparation phase,


Acknowledge

message is sent to CN.

8./9. When the CN node is ready for the SRNC move, the CN node indicates the completion of preparation phase at the CN side for the SRNS Relocation by sending the


message to the source RNC.

10. When the source RNC has received


messages from all the CN nodes, the source RNC sends a

Relocation Commit

message to the target RNC to request the target RNC to proceed with the

Relocation.

11./12. The target RNC sends the

Relocation Detect

message to the involved CN nodes and also executes both the

DL and UL switch for all bearers at the earliest suitable time instance.

After the switch UL traffic from Node B's is routed via the newly established Macro Diversity Combiner to the new MAC/RLC entities and finally to the correct Iu transport bearer. UL data transmission to the old Iur transport bearer is ceased. Upon reception of Relocation Detect message, the CN may switch the user plane from the source RNC to the target RNC.

DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to the

Macro Diversity Splitter and Nodes B. The DL data received from the old Iur is discarded.

13./14. Immediately after a successful switch at RNC, target RNC (=SRNC) sends


messages to the involved CN nodes.

If the User plane has not been switched at Relocation Detect, the CN switches from the old Iu transport bearers to the new ones.

15./16. After a successful switch at the CN node, the CN node initiates the release of the Iu connection to the source

RNC by sending the RANAP message

Iu Release Command

.

17 Upon reception of the release requests from the CN nodes the old SRNC executes all necessary procedures to release all visible UTRAN resources that were related to the RRC connection in question.

18./19. SRNC confirm the IU release to the CN nodes sending the message

Iu Release Complete.

At any phase, before the


message is sent, the old communication link between the CN and UE is all the time existing and working and the procedure execution can be stopped and original configuration easily restored.

If any such abnormal thing occurs a

Relocation Failure

may be sent instead of any message numbered 3-13 described.

7.13 HO & Cell Reselection between UTRAN and GSM/BSS

This subclause presents some examples of handover procedure from UTRAN to GSM/BSS and vice versa.

The case of a UTRAN connected to UMTS CN connected to a 2G-MSC (i.e. via MAP/E interface) is shown. The case of an UTRAN connected a GSM CN trough an IWF (where RANAP is interworked with BSSMAP) is not shown, because is equivalent from the point of view of the UTRAN.

The case of HO between UTRAN and GPRS and vice versa is also considered.

7.13.1 UTRAN GSM/BSS

This example shows how handover (Hard Handover) is performed from UTRAN to GSM/BSS between a UMTS CN and a 2G-MSC.

NOTE: Procedures between CN and MSC, and between MSC and BSC are out of the scope of WG3, and are only included for clarity.

ETSI


U E N o d e B R N C

S erv in g

R A N A P

1 . R elo ca tio n

R e q uire d

C N

R A N A P

M S C

B S C

M A P /E

M A P /E

2 . P rep a re

H an d o v e r

5 . P rep are

H an d o v e r

R esp o n se

M A P /E

B S S M A P

3 . H a n d o v er

R eq u est

B S SM A P

B S S M A P

4 . H an d o v e r

R e q u e st A c k

B S SM A P

M A P /E

6 . R e lo ca tio n

C o m m a n d

R A N A P R A N A P

B T S

7 . D C C H : H an d o v e r fro m U T R A N

C o m m a n d

R R C R R C

R R

B S S M A P

8 . H a nd o v e r

D e tec t

B S SM A P

9 . H a n d o v er C o m p lete

M A P /E

B S S M A P

R R

1 0 . H a n d o v er

C o m p le te

B S SM A P

1 1 . S en d E n d

S ig n a l

R eq u est

M A P /E

1 2 . Iu R e le ase

R A N A P

1 3 . Iu R e le ase

C o m p lete

R A N A P

M A P /E

1 4 . S en d E n d

S ig n a l R e sp o n se

M A P /E

Figure 36: UTRAN

⇒

GSM/BSS handover

1. Upon detection of a trigger SRNC sends RANAP message


to the CN.

2. The UMTS CN will forward this request to the GSM MSC (indicated in the received message) over the MAP/E interface (MAP message

Prepare Handover

).

Steps 3 & 4 follow the normal GSM procedures and are shown only for clarity.

5. Once initial procedures are complete in GSM MSC/BSS the MSC returns MAP/E message


Response

.

6. CN responds to the initial request from SRNC by sending RANAP message


to the

SRNC.

7. Via existing RRC connection, SRNC sends RRC message Handover from UTRAN command to the UE One or several message from the other system can be included in this message.

Procedures related to synchronisation etc. to GSM BSS are not shown.

Steps 8 & 10 follow normal GSM procedures and are shown only for clarity.

11. Detection of the UE within the GSM coverage results in the MSC sending MAP/E message

Send End Signal

Request

to the CN.

12. CN initiates release of resources allocated by the former SRNC (

Iu Release Command

).

13. Previously allocated bearer resources are released within UMTS (e.g. using RANAP and ALCAP protocols

[ALCAP not shown]) (Iu Release Complete).

ETSI


14. Procedure is concluded from UMTS point of view by CN sending MAP/E message Send End Signal Response

(this message is not sent until the end of the call).

7.13.1.2 Service Based Intersystem Handover

If the

Service Handover

IE is included in the RAB ASSIGNMENT REQUEST message, the service based intersystem handover from UMTS to GSM can be performed. The following example shows the signalling flow.

UE RNC 3G MSC 2G MSC BSC

RANAP

[Service Handover]

RANAP

2. RB setup

RRC

RRC

3. RB response

RRC

RRC

RANAP

4. RAB Assignment Response

RANAP

5. RNC decides to make handover

RRC

RANAP

6. Relocation Required

RANAP

7. Prepare Handover

MAP/E

MAP/E

BSSMAP

MAP/E

BSSMAP

10. Prepare Handover Response

MAP/E

8. Handover Request

BSSMAP

9. Handover request Ack

BSSMAP

11. Relocation Command

RANAP

RANAP

12. Handover from UTRAN Command

RRC

Radio link failure on UTRAN and radio link establishment in GSM/BSS

RR

BSSMAP

14. Handover Complete

MAP/E

BSSMAP

16. Send End Signal Request

MAP/E

17. Iu Release Command

RANAP

RANAP

18. Iu Release Complete

RANAP

RANAP

MAP/E

19. Send End Signal Response

MAP/E

13. Handover Detect

BSSMAP

RR


BSSMAP

Figure 36a: Service based UTRAN to GSM/BSS Intersystem Handover

1. CN initiates establishment of the radio access bearer with RANAP message


Request

.

Parameters: Service Handover.

Radio Bearer Setup

is sent by RNC to UE.

3 UE sends RRC message


to RNC.

4 RNC sends RANAP message


to CN.

ETSI


5 Being based on the value assumed from

Service Handover

IE, the RNC decides to perform handover towards

GSM.

6 RNC sends RANAP message


to the CN.

Steps 7 to 19 are the same as 2 to 14 in subclause 7.13.1.1.

Directed retry could be used to avoid the assignment phase, allowing direct assignment of resources on GSM system by

CN. The following figure shows the signalling flow.

UE 2G MSC BSC RNC

RANAP

1. RAB Assignment Request

3G MSC

RANAP

2. RNC decides to perform Relocation

(Directed Retry)

RRC

RANAP

3. RAB Assignment Response

[cause: directed retry]

RANAP

4. Relocation Required

[cause: directed retry]

RANAP

RANAP

RANAP

10. Handover from UTRAN Command

RRC

9. Relocation Command

MAP/E

5. Prepare Handover

MAP/E

BSSMAP

6. Handover Request

BSSMAP

7. Handover request Ack

BSSMAP

BSSMAP

MAP/E

8. Prepare Handover Response

MAP/E

RANAP

Radio link failure on UTRAN and radio link establishment in GSM/BSS

RR

BSSMAP


MAP/E

BSSMAP

14. Send End Signal Request

MAP/E

15. Iu Release Command

RANAP

RANAP

16. Iu Release Complete

RANAP

RANAP

MAP/E

17. Send End Signal Response

MAP/E

11. Handover Detect

BSSMAP

RR


BSSMAP

Figure 36b: Directed Retry

1. CN initiates establishment of the radio access bearer with RANAP message


Request

.

2. RNC decides to perform relocated avoiding the Radio Bearer Setup phase.

3. RNC sends RANAP message


to CN with the RAB ID included in the list of RABs failed to setup and a cause value of "Directed Retry".

ETSI


4. RNC sends RANAP message


with cause value "Directed Retry".

Steps 5 to 17 are the same as 2 to 14 in subclause 7.13.1.1.

7.13.2 GSM/BSS UTRAN

This example shows how handover (Hard Handover) is performed from GSM/BSS to UMTS between a UMTS CN and a 2G-MSC.

NOTE: Procedures between CN and MSC, and between MSC and BSC are out of the scope of WG3, and are only included for clarity.

U E N o d e B R N C

T a rg e t

C N

M S C

B S C B T S

R R

M A P /E

2 . P rep a re

H and o ve r

B S S M A P

1 . H a nd o v er

R eq u ired

B S S M A P

M A P /E

R A N A P

3 . R elo catio n

R eq u est

4 . R elo catio n

R eq u est A c k.

R A N A P

R A N A P

R A N A P

M A P /E

5 . P rep a re H an d o v er

R esp o n se

M A P /E

B S S M A P

6 . H an d o ve r

C o m m a nd

B S S M A P

R A N A P

8 . R elo ca tio n

D e te ct

7 . H an d o ve r C o m m a nd

R A N A P

R R

9 . D C C H : H an d o ve r to U T R A N C o m p lete

R R C R R C

1 0 . R elo catio n C o m p lete

R A N A P R A N A P

M A P /E

1 1 . S en d E nd S ign al

R eq u est

M A P /E

B S S M A P

1 2 . C lea r

C o m m a nd

1 3 . C le ar

C o m p lete

M A P /E

1 4 . S en d E nd S ign al

R esp o n se

B S S M A P

M A P /E

B S S M A P

B S S M A P

Figure 37: GSM/BSS

⇒

UTRAN handover

1. The BSC sends

Handover Required

message to the GSM MSC.

2. The MSC sends MAP/E message


to the UMTS CN.

3. The CN sends RANAP message


to the Target RNC.

Relocation Request Acknowledge

is returned to the CN by the target RNC via RANAP.

5. MAP/E message

Handover Response

is sent by the UMTS CN to the MSC.

Steps 6 and 7 follow normal GSM procedures and are shown only for clarity.

8. When target RNC has detected the UE,

Relocation Detect

message is sent to the CN node.

9. When the RRC connection is established with the target RNC and necessary radio resources have been allocated the UE sends RRC message

Handover to UTRAN Complete

to the target RNC.

10. Once complete the target RNC sends RANAP message


to the CN.

ETSI


11. CN sends MAP/E message

Send End Signal Request

to the MSC.

12. The MSC sends

Clear Command

message to the BSC.

13. The BSC responds with

Clear Complete

message to the GSM

15. The MSC sends MAP/E message

Send End Signal Response

to the UMTS CN to conclude the procedure (this message is not sent until the end of the call).

7.13.3 GPRS UMTS Cell Reselection

This subclause shows UTRAN signalling procedures for GPRS to UTRAN Cell Reselection.

U E

S e rv in g

R N C

C N

1 . U E in itiate d sig n a llin g c o n n e c tio n e sta b lish m e n t

2 . D ire c t T ra n sfe r

3 . R a d io A c ce ss B e a rer E stab lish m en t

Figure 38

1. The UE selects a UTRAN cell, reads system information, and initiates establishment of a NAS signalling connection.

See section UE Initiated Signalling Connection Establishment.

2. The NAS signalling connection between UE and CN can now be used for NAS message transfer (e.g. execution of security functions).

See section Direct Transfer.

3. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates establishment of radio access bearer(s).

See section Radio Access Bearer Establishment.

7.13.4 UMTS GPRS Cell Reselection, UE Initiated

This subclause shows UTRAN signalling procedures for UTRAN to GPRS cell reselection initiated by UE..

U E

S e rving

R N C

C N

1. C e ll R ese lectio n trig ge red

R A N A P

R A N A P

2. Iu R ele ase C o m m and

2 . Iu R e lea se C o m ple te

R A N A P

R A N A P

Figure: 39

1. The UE selects a GPRS cell, reads system information, and initiates establishment of UE-GPRS connection.

ETSI


2. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates release of Iu connection. SRNC releases the RRC connection.

7.13.5 UMTS GPRS Cell Reselection, Network Initiated

This subclause shows UTRAN signalling procedures for UTRAN to GPRS Cell Reselection triggered by Serving RNC.

NOTE: This case can only supported if the RNC could generate GSM messages.

U E

S e rv in g

R N C

C N

R R C

1 . C ell C h an g e O rd e r fro m

U T R A N

R R C

R A N A P

2 . Iu R e le a se C o m m a n d

R A N A P

R A N A P

3 . Iu R e lea se C o m p lete

R A N A P

Figure 40: UTRAN to GPRS Cell Reselection

1. Based on UE measurements, SRNC triggers the handover to a GPRS cell by sending a Cell Change order from

UTRAN to the UE. The UE initiates establishment of UE-GPRS connection.

2. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates release of the RRC connection.

3. SRNC releases all resources reserved for the UE.

7.14 Transport Channel Reconfiguration (DCH to DCH)

7.14.1 Synchronised Transport Channel Reconfiguration

The procedure can be applied when the reconfiguration time requires being synchronised among Node-Bs, SRNC and

UE.

ETSI


7.14.1.1

U E

79 ETSI TR 125 931 V5.3.0 (2006-03)

Synchronised Reconfiguration, Q.2630.2 modification procedure not used

N od e B

D rift R N S

N B A P

N B A P

N od e B

S e rv in g R N S

D rift

R N C

S er vin g

R N C

1 . Ra d io L in k R econ fig u r a tion

RN S A P

P rep a r e

R N S A P

2 . R a d io L in k R eco n fig u r a tion P r ep a r e

N B A P

N B A P

3 . R a d io L in k R econ fig u r atio n P r ep a r e

N B A P

4 . Ra d io L in k R econ fig u r a tion Rea d y

N B A P

N BA P

5 . R a d io L in k R eco n fig u r a tion

R N S A P

R ea d y

R N SA P

6 . R a d io L in k R econ fig u r ation R ea d y

N B A P

7 . A L C A P Iu b D a ta T r a n sp or t B ea r er S et-u p A L C A P Iu r Bea r er S et-u p

C N

R RC

R RC

8 . A L C A P Iu b D a ta T r a n sp or t Bea r er S et-u p

N B A P

9 . Ra d io L in k R econ fig u r a tion

R N S A P

C om m it

R N SA P

1 0 . R a d io L in k R eco n fig u r a tion C o m m it

N B A P

1 1 . Ra d io L in k Recon fig u r a tion C om m it

N B A P

N B A P

1 2 . D C C H : T r an sp or t C h a n n el R econ fig u r a tion

R R C

1 3 . D C C H : T r an sp or t C h a n n el R econ fig u r a tion C om p lete

R R C

1 4 . A L C A P Iu b D a ta T ra n sp or t B ea r er R elea se A L C A P Iu r B ear er R elea se

1 5 . A L C A P Iu b D a ta T r a n sp or t B ea r er R elea se

Figure 41: Synchronised Transport Channel Reconfiguration

1. SRNC decided that there is a need for a synchronous Transport Channel Reconfiguration and requests DRNC to prepare reconfiguration of DCH


).



2. DRNC requests its Node B to prepare reconfiguration of DCH to carry the radio access bearer (

Radio Link


).

Parameters: Transport Format Set, Transport Format Combination Set, Power control information Time Slots


3. SRNC requests its Node B to prepare reconfiguration of DCH (


).





Ready

).


Bearer.



).


Bearer.



Ready

).


Bearer.

ETSI


7. SRNC initiates (if needed) establishment of new Iur/Iub Data Transport Bearers using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH.

8. SRNC initiates (if needed) establishment of new Iub Data Transport Bearers using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH.



10. NBAP message



11. NBAP message



12. RRC message

Transport Channel Reconfiguration



Transport Channel Reconfiguration Complete

to SRNC.



15. Not used resources in SRNC and Node B (Serving RNS) are released. SRNC initiates release of Iub (Serving


7.14.1.2 Synchronised Reconfiguration, Bandwidth Increase with Q.2630.2 modification procedure

U E C N

R R C

R R C

N o d e B

D rift R N S

N o d e B

S erv in g R N S

D rift

R N C

S erv ing

R N C

1 .A L C A P Iu r B eare r M o d ifica tio n

1 . A L C A P Iu b D ata T ran sp o rt B ea rer M o d ificatio n

2 . R ad io L in k R eco nfigu ratio n

R N S A P

P re p are

R N S A P

3 . A L C A P Iu b D ata T ran sp o rt B earer M o d ificatio n

N B A P

N B A P

4 . R ad io L in k R eco nfigu ratio n P rep are

N B A P

5 . R ad io L in k R ec o n fig uratio n P rep are

N B A P

N B A P

6 . R a d io L ink R eco nfigu ratio n R e ad y

N B A P

N B A P

7 . R ad io L in k R ec o n fig uratio n

R N S A P

R ead y

R N S A P

8 . R ad io L in k R eco nfigu ratio n R e ad y

N B A P

N B A P

9 . R a d io L ink R eco n figu ratio n

R N S A P

C o m m it

R N S A P

1 0 . R ad io L in k R e co n fig u ratio n C o m m it

N B A P

1 1 . R ad io L in k R eco nfigu ratio n C o m m it

N B A P

N B A P

1 2 . D C C H : T ra nsp o rt C ha nn el R e co n fig u ratio n

R R C

1 3 . D C C H : T ran sp o rt C h an n el R eco nfigu ratio n C o m p lete

R R C

Figure 41a: Synchronised Transport Channel Reconfiguration, Bandwidth Increase

ETSI


1. SRNC decides that there is a need for synchronous Transport Channel Reconfiguration and initiates transport bearer modification of the Transport Bearer(s), if LC modification is enabled over the connection(s).

2. SRNC requests DRNC to prepare reconfiguration of DCH (


).


(TDD only), User Codes (TDD only), the flag 'Transport Bearer Request Indicator' shall be set to BEARER

NOT REQUESTED.

3. DRNC initiates transport bearer modification on Iub connection.

4. DRNC requests its Node B to prepare reconfiguration of DCH to carry the radio access bearer (

Radio Link


).



NOT REQUESTED.



).



NOT REQUESTED.



Ready

).



).



Ready

).

Parameters: CFN



10. NBAP message



Parameters: CFN

11. NBAP message



Parameters: CFN

12. RRC message





to SRNC.

ETSI


7.14.1.3

U E

R R C

R R C

82 ETSI TR 125 931 V5.3.0 (2006-03)

Synchronised Reconfiguration, Bandwidth Decrease with Q.2630.2 modification procedure

N o d e B

D rift R N S

N B A P

N B A P

N o d e B

S e rv in g R N S

D rift

R N C

S e rv ing

R N C

1 . R a d io L ink R e c o n fig ura tio n

R N S A P

P re p a re

R N S A P

2 . R a d io L in k R e c o nfigu ra tio n P re p a re

N B A P

N B A P

3 . R a d io L in k R e c o nfigu ra tio n P re p a re

N B A P

4 . R a d io L ink R e c o n fig ur atio n R e a d y

N B A P

N B A P

5 . R a d io L in k R e c o nfigu ra tio n

R N S A P

R e a d y

R N S A P

6 . R a d io L in k R e c o n fig ura tio n R e a d y

N B A P

N B A P

7 . R a d io L ink R e c o n fig ura tio n

R N S A P

C o m m it

R N S A P

8 . R a d io L in k R e c o nfigu ra tio n C o m m it

N B A P

9 . R a d io L ink R e c o n fig ura tio n C o m m it

N B A P

N B A P

1 0 . D C C H : T ra nsp o r t C ha n ne l R ec o nfigu ra tio n

R R C

1 1 . D C C H : T ra n sp o rt C h a nn e l R e c o n fig ur a tio n C o m p le te

R R C

C N

1 2 . A L C A P Iu b D a ta T ra n sp o rt B e a re r M o d ific a tio n A L C A P I ur B e a re r M o d ific a tio n

1 2 . A L C A P Iub D a ta T ra n sp o rt B e a re r M o d ific a tio n

Figure 41b: Synchronised Transport Channel Reconfiguration, Bandwidth Decrease

1. SRNC decides that there is a need for a synchronous Transport Channel Reconfiguration and this procedure is initiated, if LC modification is enabled over the Transport Bearer(s). SRNC requests

DRNC to prepare reconfiguration of DCH (Radio Link Reconfiguration Prepare).



NOT REQUESTED.

2. DRNC requests the Node B to prepare reconfiguration of DCH to carry the radio access bearer (

Radio Link


).



NOT REQUESTED.



).



NOT REQUESTED.



Ready

).



).



Ready

).

Parameters: CFN.



ETSI



is sent from DRNC to Node B

Parameters: CFN.



Parameters: CFN.

10. RRC message





to SRNC.

12. SRNC initiates a transport bearer modification for the Transport Bearer(s).

7.14.2 Unsynchronised Transport Channel Reconfiguration

The procedure can be applied when the reconfiguration time does not require being synchronised among Node-Bs,

SRNC and UE.

7.14.2.1 Unsynchronised Reconfiguration, Q.2630.2 modification procedure not used

U E

R RC

R RC

N od e B

D rift R N S

N B A P

N B A P

N od e B

S e rv in g R N S

D rift

R N C

S er vin g

R N C

1 . Ra d io L in k Recon fig u r a tion

RN S A P

R eq u est

R N S A P

2 . R a d io L in k R econ fig u r atio n R eq u est

N B A P

N B A P

3 . R a d io L in k Recon fig u r a tion R eq u est

N B A P

4 . Ra d io L in k Recon fig u r a tion R esp on se

N B A P

N B A P

5 . R a d io L in k R eco n fig u r a tion

R N S A P

R esp on se

R N SA P

6 . R a d io L in k R econ fig u r a tion R esp on se

N B A P

7 . A L C A P Iu b D a ta T r a n sp or t B ea r er S et-u p A L C A P Iu r Bea r er S et-u p

8 . A L C A P Iu b D a ta T r a n sp or t B ea r er S et-u p

9 . D C C H : T r a n sp or t C h a n n el R econ fig u r a tion

1 0 . D C C H : T r an sp or t C h a n n el R econ fig u r a tion C om p lete

R R C

R R C

1 1 . A L C A P Iu b D ata T ra n sp or t B ea r er R elea se A L C A P Iu r B ea r er R elea se

C N

1 2 . A L C A P Iu b D a ta T r a n sp or t B ea r er R elea se

Figure 42: Unsynchronised Transport Channel Reconfiguration

1. SRNC decided that there are no need for a synchronised Transport Channel Reconfiguration, and requests

DRNC to reconfigure the DCH. It includes in the message

Radio Link Reconfiguration Request

that the modification shall be done immediately without waiting for the commit message.



2. DRNC requests its Node B to reconfigure the DCH in the existing Radio Link (


Request

)

.



3. SRNC requests its Node B to reconfigure the DCH in the existing Radio Link (


Request

)

.



ETSI


4. Node B of the DRNC allocates resources and notifies DRNC that the reconfiguration is done (

Radio Link

Reconfiguration Response

).


Bearer.

5. DRNC notifies SRNC that the reconfiguration is done (

Radio Link Reconfiguration Response

).


Bearer.

6. Node B of the SRNC allocates resources and notifies DRNC that the reconfiguration is done (

Radio Link


).


Bearer.

7. SRNC initiates (if needed) establishment of new Iur/Iub Data Transport Bearers using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH.

8. SRNC initiates (if needed) establishment of new Iub Data Transport Bearers using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH.





to SRNC.


RNS) Data Transport bearer using ALCAP protocol

12. Not used resources in SRNC and Node B (Serving RNS) are released. SRNC initiates release of Iub (Serving


7.14.2.2 Unsynchronised Reconfiguration, Bandwidth Increase with Q.2630.2 modification procedure

U E

R R C

R R C

N o d e B

D rift R N S

N o d e B

S erv in g R N S

D rift

R N C

S erv in g

R N C

1 . A L C A P Iur B ea rer M o d ificatio n

1 . A L C A P Iu b D ata T ran sp o rt B earer M o d ific atio n

2 . R ad io L in k R ec o n fig uratio n

R N S A P

R eq u est

R N S A P

3 . A L C A P Iu b D ata T ran sp o rt B ea rer M o d ificatio n

N B A P

N B A P

4 . R ad io L ink R eco nfigu ratio n R eq u est

N B A P

N B A P

5 . R a d io L ink R eco n fig u ra tio n R eq ue st

N B A P

6 . R a d io L ink R eco n figu ra tio n R esp o n se

N B A P

N B A P

7 . R ad io L in k R eco n fig u ratio n

R N S A P

R esp o n se

R N S A P

8 . R ad io L in k R eco nfigu ratio n R e sp o n se

N B A P

9 . D C C H : T ra nsp o rt C ha nn el R e co n fig u ratio n

1 0 . D C C H : T ran sp o rt C h an n el R eco n fig uratio n C o m p lete

R R C

R R C

C N

Figure 42a: Unsynchronised Transport Channel Reconfiguration, Bandwidth Increase

ETSI


1. SRNC decides that there is no need for a synchronised Transport Channel Reconfiguration and initiates the transport bearer modification of the Transport Bearer(s), if LC modification is supported over the Transport

Bearer(s).

2. SRNC requests DRNC to reconfigure the DCH. It includes in the message


Request

that the modification shall be done immediately without waiting for the commit message.



NOT REQUESTED.

3. DRNC initates transport bearer modification, if LC modification is supported over the bearer.



Request

)

.


(TDD only), User Codes (TDD only). The flag 'Transport Bearer Request Indicator' shall be set to BEARER

NOT REQUESTED.



Request

)

.



NOT REQUESTED.


Radio Link


).



).


Radio Link


).





to SRNC.

7.14.2.3 Unsynchronised Reconfiguration, Bandwidth Decrease with Q.2630.2 modification procedure

U E

R R C

R R C

N o d e B

D rift R N S

N B A P

N B A P

N o d e B

S erv in g R N S

D rift

R N C

S erv in g

R N C

1 . R a d io L ink R eco n fig u ra tio n

R N S A P

R e q u est

R N S A P

2 . R a d io L ink R eco n fig u ra tio n R eq ue st

N B A P

N B A P

3 . R ad io L in k R ec o n fig uratio n R eq u est

N B A P

4 . R a d io L ink R eco n fig u ra tio n R esp o n se

N B A P

5 . R ad io L in k R e co n fig u ratio n

R N S A P

R esp o n se

R N S A P

N B A P

6 . R ad io L in k R eco n fig u ratio n R esp o n se

N B A P

7 . D C C H : T ra nsp o rt C ha nn el R ec o n fig uratio n

R R C

8 . D C C H : T ran sp o rt C h an n el R eco nfigu ratio n C o m p lete

R R C

9 . A L C A P Iub D ata T ran sp o rt B earer M o d ifica tio n A L C A P Iu r B earer M o d ificatio n

9 . A L C A P Iub D ata T ran sp o rt B earer M o d ifica tio n

C N

Figure 42b: Unsynchronised Transport Channel Reconfiguration, Bandwidth Decrease

ETSI


1. SRNC decided that there are no need for a synchronised Transport Channel Reconfiguration, and requests

DRNC to reconfigure the DCH. It includes in the message Radio Link Reconfiguration Request that the modification shall be done immediately without waiting for the commit message.



NOT REQUESTED.



Request

)

.



NOT REQUESTED.



Request

)

.



NOT REQUESTED.


Radio Link


).



).


Radio Link


).





to SRNC.

9. SRNC initiates transport bearer modification of Iub/iur Data Transport Bearers using ALCAP protocol.

7.15.1 Uplink Direct Transfer

This example applies to the transportation of a NAS message through UTRAN. This flow applies when the terminal is in connected mode.

UE

Node B

Serving RNS

Serving

RNC

CN

RRC 1. DCCH: Uplink Direct Transfer RRC

RANAP

2. Direct Transfer

RANAP

Figure 43: Uplink Direct Transfer

Uplink Direct Transfer Message

to SRNC.

Parameters: NAS Message.

2. SRNC sends the RANAP message

Direct Transfer

to the CN.

Parameters: NAS PDU.

The NAS message is transported transparently by the UTRAN.

ETSI


7.15.2 Downlink Direct Transfer

This example applies to the transportation of a NAS message through UTRAN.

ETSI TR 125 931 V5.3.0 (2006-03)

UE Node B

Serving RNS

Serving

RNC

CN

RANAP

1. Direct Transfer

RANAP

2. DCCH: Downlink Direct Transfer

RRC RRC

Figure 44: Downlink Direct Transfer

1. CN sends the RANAP message

Direct Transfer

to the SRNC.

Parameters: NAS PDU, CN domain Identity.

2. SRNC sends RRC

Downlink Direct Transfer Message

to UE.

Parameters: NAS Message.

The NAS message is transported transparently by the UTRAN.

7.16 Downlink Power Control [FDD]

UE Node B

Drift RNS

Node B

Serving RNS

1. Measurement control

Drift

RNC

Serving

RNC

CN

RRC RRC

2. Measurement report

RRC RRC

NBAP

3. Decision to perform power control

4. DL Power Control Request

NBAP

RNSAP

5. DL Power Control

Request

RNSAP

6. DL Power Control Request

NBAP NBAP

Figure 45: Downlink Power Control

1. SRNC send to UE a RRC Measurement Control message to setup a quality measure.

Parameters: Measurement ID number, Measurement type, Measurement command; This message is optional in the described flow.

2. UE after having performed the measure, send towards CRNC the report in Measurement Report.

3. CRNC decides to request NodeBs lower level (L1) to change power in DL.

4. SRNC sends the NBAP message

DL Power Control Request

to the controlled Node B

Parameters: RL ID, RL Reference power, Max Adjustment Step, Adjustment Period, Adjustment Ratio.

ETSI


5. SRNC sends the RNSAP message


to the DRNC


6. DRNC sends the NBAP message


to the controlled Node B


7.17 Shared Channels Configuration and Capacity Allocation

7.17.1 USCH/DSCH Configuration and Capacity Allocation [TDD]

This subclause shows an example of USCH/DSCH configuration and capacity allocation.

It is assumed that no RL has been already established for the considered RRC connection on the serving cell (i.e. the UE is in cell_FACH state without USCH/DSCH) and that only standalone USCH/DSCH are going to be configured. In case the UE is in cell_DCH state or in cell_FACH state with USCH/DSCH, the Radio Link Reconfiguration procedure is used in steps 1-4-5-6 instead of the Radio Link Setup procedure.

UE

RRC

RRC

RRC

RRC

Node B CRNC SRNC

RNSAP

1. RL Setup Request

RNSAP

NBAP 2. Phy.Shar.Ch.Rec.Req.

NBAP

NBAP

3. Phy.Shar.Ch.Rec.Resp.

NBAP

NBAP

4. RL Setup Request

NBAP

5. RL Setup Response

NBAP

NBAP

RNSAP

6. RL Setup Response

RNSAP

7. ALCAP Iub Trans. Bearer Setup

ALCAP Iur Transp. Bearer Setup

8. DCCH : Radio Bearer Reconfiguration

9. DCCH : Radio Bearer Reconfiguration Complete

RRC

RRC

10. SHCCH : PUSCH Capacity Request

RRC

11. SHCCH : Physical Shared Channel Allocation

RRC

12. Dynamic PUSCH Assign

USCH FP USCH FP

13. Data transfer

DSCH FP

14. DSCH Capacity Req

DSCH FP

DSCH FP

15. DSCH Capacity Alloc

DSCH FP

16. SHCCH : Physical Shared Channel Allocation

RRC RRC



Figure 45a USCH/DSCH Configuration and Capacity Allocation

1. In case no RL has already been established on the RNC controlling the serving cell, the SRNC sends the RNSAP message


to the target RNC.

Parameters: target RNC identifier, s-RNTI, Cell id, Transport Format Set (for DSCHs and USCHs), Transport

Format Combination Set.

ETSI


2. If necessary, the CRNC sends to the Node B the NBAP message

Physical Shared Channel Reconfiguration

Request

in order to add, modify or delete any PDSCH Sets and PUSCH Sets in the Common Transport Channel data base.

Parameters: PDSCH Info (to add, modify or delete), PUSCH Info (to add, modify or delete).

3. The Node B updates the PDSCH and PUSCH Sets in the Common Transport Channel data base and makes them available to all the current and future DSCH and USCH transport channels. Then it responds with the NBAP message

Physical Shared Channel Reconfiguration Response

.

4. The RNC sends the NBAP message



Parameters: Cell id, Transport Format Set (for DSCHs and USCHs), Transport Format Combination Set, Power control information, etc.

5. Node B configures resources for USCHs and DSCHs and responds with NBAP message


Response

.


Bearer.

6. When the Target RNC has completed preparation phase, the RNSAP message


is sent to the SRNC.

7. Target RNC initiates set-up of Iub Data Transport bearer using ALCAP protocol while the SRNC initiates set-up of Iur Data Transport bearer. These requests contain the AAL2 Binding Identity to bind the Iub/Iur Data

Transport Bearers to the DSCHs/USCHs. The request for set-up of Iub Data Transport bearer is acknowledged by Node B, while the request for set-up of Iur Data Transport bearer is acknowledged by Target RNC.

8. The SRNC sends the RRC message


to establish the requested USCHs and

DSCHs.

Parameters: Radio Bearer information.

9. The UE replies with the RRC message


.

10. As soon as the RRC in the UE detects the necessity to sends UL data on one USCH, it sends the RRC message

PUSCH Capacity Request

to obtain allocation of PUSCH resources from the CRNC.

Parameters: C-RNTI, Radio Bearer ID, RLC buffer info.

11. The CRNC determines which PUSCH Set to allocate to the USCH and sends a

Physical Shared Channel

Allocation

message to the UE.

Parameters: C-RNTI, Allocation Period info (Activation CFN, Duration), PUSCH info.

12. The CRNC signals the allocation of PUSCH resources for a given UE to the Node B by means of a Dynamic

PUSCH Assignment control frame.

Parameters: PUSCH Set Id, Activation CFN, and Duration.

13. At the scheduled CFN the UE may start transmitting UL data on the USCH for the assigned allocation period.

UL data are forwarded by the CRNC to the SRNC.

14. As soon as the SRNC detects the necessity to sends DL data on one DSCH, it sends a DSCH Capacity Request control frame to the CRNC.

Parameters: Common Transport Channel Priority Indicator, User buffer size.

15. The CRNC determines the amount of data (credits) that can be transmitted on the DSCH and reports this information back to the SRNC by means of DSCH Capacity Allocation control message.

Parameters: Common Transport Channel Priority Indicator, Max MACc-sh SDU Length, Credits, Interval, and

Repetition Period.

16. The CRNC determines which PDSCH Set to allocate to the DSCH and sends a RRC message

Physical Shared

Channel Allocation

to the UE.

Parameters: C-RNTI, Allocation Period info (Activation CFN, Duration), PDSCH info.

17. The SRNC starts sending DL data to the CRNC.

18. The CRNC schedules the DL transmission of DL data on DSCH according to the allocation of PDSCH resources.

ETSI


7.17.2 HS-DSCH Configuration and Capacity Allocation

The following ATM example shows a sequence chart explaining the setup of HS-DSCH. It is assumed that the UE is in cell_DCH state. In case no RL has already been established, the Radio Link Setup procedure is used instead of the

Radio Link Reconfiguration procedure.

UE

Node B

NBAP

NBAP

NBAP

Drift

RNC

RNSAP

1. Radio Link

Reconfig Prepare

2. Radio Link

Reconfig Prepare

3. Radio Link

Reconfig Ready

NBAP

NBAP

RNSAP

4. Radio Link

Reconfig Ready

5. Radio Link

Reconfig Commit

Serving

RNC

RNSAP

RNSAP

RNSAP

RNSAP

6. Radio Link

Reconfig Commit

NBAP

RRC

RRC

7 ALCAP Iub Trans. Bearer Setup 8 ALCAP Iur Trans. Bearer Setup

9. DCCH: Radio Bearer Reconfiguration

RRC

10. DCCH: Radio Bearer Reconfiguration Complete

RRC

11. HS-DSCH:

Capacity Request

HS-DSCH-FP

HS-DSCH-FP

13. HS-DSCH:

Capacity Allocation

12. HS-DSCH:

Capacity Request

HS-DSCH-FP HS-DSCH FP

HS-DSCH-FP

14. HS-DSCH:

Capacity Allocation

HS-DSCH-FP

15. Data transfer

MAC-hs

16. HS-SCCH

MAC-hs

17. Data transfer

Figure 45b: HS-DSCH Configuration and Capacity Allocation

1.

In order to channel-switch to the HS-DSCH, the radio link which shall carry the HS-DSCH has to be reconfigured.

The SRNC initiates a Radio Link Reconfiguration by sending the RNSAP message


Prepare

to DRNC.

Parameters: HS-DSCH information and a SRNC selected HS-PDSCH RL ID.

2.

The DRNC requests the respective Node B to prepare the synchronised RL reconfiguration by sending the NBAP message


.

Parameters: HS-DSCH Information, a DRNC selected HS-DSCH RNTI and the HS-PDSCH RL ID.

3.

Node B configures resources for the HS-DSCH and responds with the NBAP message

Radio Link

Reconfiguration Ready

.


ETSI


4.

When the DRNC has completed the preparation phase, the RNSAP message


is sent to the SRNC.


5.

The RNSAP message



6.

The NBAP message



7.

The DRNC initiates set-up of Iub Data Transport Bearers using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iub Data Transport Bearer to the HS-DSCH.

8.

The SRNC initiates set-up of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2

Binding Identity to bind the Iur Data Transport Bearer to the HS-DSCH.

9.

The SRNC sends the RRC message


to the UE to establish the requested HS-

DSCH.

10.

The UE replies with the RRC message


. At this point in time, the HS-

DSCH Transport Channel has been set up, and it is assumed that the MAC-hs in the Node B has already been configured earlier to have access to a pool of HS-PDSCH resources for HS-DSCH scheduling.

11.

As soon as the SRNC detects the necessity to send HS-DL data on one HS-DSCH, it sends an HS-DSCH

Capacity

Request

control frame within the HS-DSCH Frame Protocol to the CRNC.

Parameters: Common Transport Channel Priority Indicator and User Buffer Size.

12.

The CRNC forwards this message (HS-DSCH

Capacity Request

control frame) to the Node B. So in this example sequence, the CRNC does not interfere with the HS-DSCH scheduling.

Parameters: Common Transport Channel Priority Indicator and User Buffer Size.

13.

The Node B determines the amount of data (credits) that can be transmitted on the HS-DSCH and reports this information back to the DRNC in a HS-DSCH

Capacity Allocation

control frame in the HS-DSCH Frame

Protocol.

Parameters: Common Transport Channel Priority Indicator, HS-DSCH Credits, HS-DSCH Interval, HS-DSCH

Repetition period, Maximum MAC-d PDU length.

14.

The DRNC sends the HS-DSCH

Capacity Allocation

control frame to SRNC. So again, the DRNC does not react itself to that message in this example.

Parameters: Common Transport Channel Priority Indicator, HS-DSCH Credits, HS-DSCH Interval, HS-DSCH

Repetition period, Maximum MAC-d PDU length.

15.

The SRNC starts sending DL data to the Node B. This is done via the two HS-DSCH Frame Protocol "hops" on Iur and Iub interface. The Node B schedules the DL transmission of DL data on HS-DSCH which includes allocation of PDSCH resources.

16.

The Node B transmits the control information for the concerned UE using the HS-SCCH.

17.

The Node B sends the HS-DSCH data to the UE on the HS-PDSCH(s).

7.18 Channel and Mobile State Switching on Iur

This subclause shows an example of switching of a mobile protocol state to another, which Iur is used, thus involving

RNSAP procedure.

7.18.2 Switching from Cell_FACH to Cell_DCH State

The following examples show switching of protocol state from Cell_FACH to Cell_DCH providing UE with information on RACH/FACH flows and involving DRNC and Iur.

The resulting sequence is the following:

ETSI


UE

RRC

RRC

Node B

Drift RNS

Drift

RNC

Serving

RNC

Decision to switch to

Cell_DCH state

RNSAP

1. Radio Link Setup

Request

RNSAP

NBAP

2. Radio Link Setup

Request

NBAP

3. Radio Link Setup

Response

NBAP

NBAP

Start RX description

5. ALCAP Iub Bearer Setup

RNSAP

4. Radio Link Setup

Response

ALCAP Iur Bearer Setup

6. NodeB SRNC Data Transport Bearer Sync.

RNSAP

Start TX description

7.

DCCH

: Physical Channel Reconfiguration

NBAP


Indication

NBAP

RNSAP


Indication

RRC

RNSAP

10.

DCCH

: Physical Channel Reconfiguration Complete

RRC

11. Common Transp. Channel

RNSAP

Resources Release Request

RNSAP

Figure 45b Switching from Cell_FACH to Cell_DCH State via Iur

1. SRNC decides to switch to CELL_DCH state, setting up a new radio link via a new cell controlled by DRNC.

SRNC requests DRNC for radio resources by sending RNSAP message


. If this is the first radio link via the DRNC for this UE, a new Iur signalling connection is established. This Iur signalling connection will be used for all RNSAP signalling related to this UE.




to Node B.


3. Successful outcome is reported in NBAP message


.


Identitie(s)) for Data Transport Bearer(s).

Then Node B starts the UL reception.



to SRNC.

Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Identity) for Data Transport

Bearer(s), Neighbouring cell information.

5. SRNC initiates setup of Iur, while DRNC is in charge to setup Iub, Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH.

Note: there is not a time relation between set up of Iur and Iub. Both must be carried out before next step.

ETSI


6. Node B and SRNC establish synchronism for the Data Transport Bearer by means of exchange of the appropriate

DCH Frame Protocol frames via

Downlink Synchronisation

and

Uplink Synchronisation

, relative to already existing radio link(s).

Then Node B starts DL transmission.



to UE on DCCH.


8. Node B achieves uplink sync on the Uu and notifies DRNC with NBAP message

Radio Link Restore

Indication

.



to notify SRNC that uplink sync has been achieved on the Uu.



to SRNC.

11. The SRNC releases the UE context for CELL_FACH state in the source DRNC by sending a

Common

Transport Channel Resources Release

message.

7.18.3 Switching from Cell_DCH to Cell_FACH State

In the this scenario the SRNC needs to get the C-RNTI from DRNC to be able to indicate to the UE a new C-RNTI and which cell it is valid in (given by the Primary Scrambling Code).

The SRNC also needs to get either:

1.

information in the RACH and/or FACH to be used (if the DRNC selects RACH and/or FACH in a different way than the UE would do based on broadcast information) including User Plane flow control information for the Iur

FACH FP.

2.

User Plane flow control information for the FACH (Secondary CCPCH) that the UE selects if no Secondary

CCPCH information is provide to the UE in the RRC Physical Channel Reconfiguration message

If receiving the C-ID the DRNC shall allocate a C-RNTI and provide it together with the Primary CPICH information to the SRNC. Further more, if the DRNC would like to select another RACH and/or FACH than the UE would select based on the broadcast information the DRNC also provides information on the DRNC Selected RACH and/or FACH

(alternative 1). If the DRNC does not select any FACH the DRNC shall provide the user plane flow control information

(alternative 2).

The above solution would result in the following sequence:

ETSI


UE Node B

94

DRNC

ETSI TR 125 931 V5.3.0 (2006-03)

SRNC

RRC

RRC

Decision to switch to Cell_FACH state


Initialization Request

RNSAP RNSAP

RNSAP


Initialization Response

RNSAP

3. ALCAP Iur bearer setup

(if needed)

4. DCCH : Physical Channel Reconfiguration

[C-RNTI, Primary CPICH Info [FDD], optional: Secondary CCPCH Info, PRACH Info]

5. DCCH : Physical Channel Reconfiguration Complete

RRC

RRC

RNSAP


RNSAP

NBAP


NBAP

NBAP


NBAP

RNSAP


RNSAP

10. ALCAP Iub bearer release ALCAP Iur bearer release

Figure 45c Switching from Cell_DCH to Cell_FACH State via Iur

1. SRNC decides to switch to CELL_FACH state, releasing its present radio link via a cell controlled by DRNC.

The SRNC decides to setup a common channel for the UE via DRNC, informing DRNC with C-ID IE of the UE in order to obtain C-RNTI (allocated in the next step by DRNC) needed for RRC messages. This setup is done with the RNSAP

Common Transport Channel Resources Initialisation Request

message.

2. The target DRNC sends the transport layer address, binding identity and C-RNTI to the SRNC with the RNSAP

Common Transport Channel Resources Initialisation Response

message

3. SRNC initiates setup of Iur/Iub Data Transport Bearer (if needed) using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer



to UE on DCCH, with new C-RNTI and identification of the cell where it is valid.



to SRNC.


6. SRNC releases DRNC for radio resources allocated for DCH by sending RNSAP message


Request


ETSI




to Node B.

8. Successful outcome is reported in NBAP message


.

DRNC sends RNSAP message


to SRNC.

9. Not used resources in DRNC and Node B (Drift RNS) are released. DRNC initiates release of Iub and SRNC of

Iur Data Transport bearer using ALCAP protocol.

NOTE: there is not a time relation between set up of Iur and Iub. Both must be carried out before next step.

ETSI


Annex A (informative):

Change History

TSG RAN# Version CR Tdoc RAN

RAN_08 - - RP-000256

RAN_09 3.0.0 001

002

RAN_10 3.1.0

003

004 RP-000633

RAN_11 3.2.0 008 RP-010130

Change history

New

Version

3.0.0

3.1.0

Subject/Comment

Approved at TSG RAN #8 and placed under Change Control

Approved at TSG RAN #9

3.2.0

3.3.0



Change history

Date TSG # TSG Doc. CR Rev Subject/Comment

March 01 11 RP-010163 006 Approved at TSG RAN #11 and placed under Change Control

March 01 11

March 01 12

RP-010162 007

RP-010387 010

Approved at TSG RAN #11 and placed under Change Control


12/2001 14

03/2002 15

03/2002 15

RP-010868 012 1 Obsolete or Missing Messages

RP-020177 015 Corrections and updates

RP-020177 017 1 DSCH-related additions to Handover scenarios

03/2002 15

06/2002 16

06/2002 16

06/2005 28

06/2005 28

06/2005 28

06/2005 28

06/2005 28

03/2006 31

- - Approved at TSG RAN #15 and placed under Change Control

RP-020422 018 1 HSDPA Additions for Example Procedures

RP-020415 021 Addition of pre-emption signalling sequences

RP-050217 26 1 HS-DSCH Mobility procedures

RP-050223 28

RP-050219 32

RP-050225 35

RP-050222 37

RP-060059 40

Feature Cleanup: Removal of DRAC

Feature Clean-up: Removal of SSDT

Feature Cleanup: Removal of CPCH

Feature clean-up: Removal of DSCH (FDD mode)

SRNS Relocation example correction

Old New

- 4.0.0

- 4.0.0

4.0.0 4.1.0

4.1.0 4.2.0

4.2.0 4.3.0

4.2.0 4.3.0

4.3.0 5.0.0

5.0.0 5.1.0

5.0.0 5.1.0

5.1.0 5.2.0

5.1.0 5.2.0

5.1.0 5.2.0

5.1.0 5.2.0

5.1.0 5.2.0

5.2.0 5.3.0

ETSI


History

97

Document history

ETSI TR 125 931 V5.3.0 (2006-03)

ETSI

No results