3rd technical specification group (tsg) ran; utran · pdf file · 1999-09-07rab...

TR 25.931 V<1.1.1> (<1999-06>)Technical Specification

3rd Generation Partnership Project (3GPP);Technical Specification Group (TSG) RAN;

UTRAN Functions, Examples on Signalling Procedures

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification isprovided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification. Specifications andreports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

Reference<Workitem> (<Shortfilename>.PDF)

Keywords<keyword[, keyword]>

3GPP

Postal address

Office address

[email protected]

Individual copies of this deliverablecan be downloaded fromhttp://www.3gpp.org

25.931 V1.1.1 1999-063

1 Contents1. Intellectual Property Rights ....................................................................................................................... 5

2. Foreword .................................................................................................................................................... 5

3. Scope.......................................................................................................................................................... 5

4. References.................................................................................................................................................. 5

5. Definitions, abbreviations and notation..................................................................................................... 65.1 Definitions.............................................................................................................................................................65.2 Abbreviations ........................................................................................................................................................65.3 Notation for the signalling procedures ..................................................................................................................6

6. UTRAN AND UE PROTOCOL ARCHITECTURE................................................................................. 86.1 Protocol Architecture ............................................................................................................................................86.2 RANAP Procedures & Messages ..........................................................................................................................96.3 RNSAP Procedures & Messages.........................................................................................................................106.4 NBAP Procedures & Messages...........................................................................................................................106.5 ALCAP ...............................................................................................................................................................116.5.1 Q2630.1 (Q.AAL 2) ...................................................................................................................................116.6 RRC Procedures & Messages .............................................................................................................................12

7. UTRAN Signaling Procedures................................................................................................................. 14

8. Procedures not related to a specific UE (global procedures)................................................................... 148.1 System Information Broadcasting .......................................................................................................................14

9. Procedures related to a specific UE ......................................................................................................... 149.1 Paging .................................................................................................................................................................149.1.1 Paging for a UE in RRC Idle Mode............................................................................................................149.1.2 Paging for a UE in RRC Connected Mode .................................................................................................159.2 NAS Signalling Connection Establishment.........................................................................................................169.2.1 UE Initiated Signalling Connection Establishment.....................................................................................169.2.2 CN Initiated Signalling Connection Establishment.....................................................................................169.3 RRC Connection Establishment ..........................................................................................................................179.3.1 DCH Establishment ....................................................................................................................................179.3.2 RACH/FACH Establishment ......................................................................................................................189.4 RRC Connection Release ....................................................................................................................................189.4.1 DCH Release ..............................................................................................................................................189.4.2 Common Transport Channel Release .........................................................................................................189.5 RRC Connection Re-establishment .....................................................................................................................199.5.1 DCH Re-establishment ...............................................................................................................................199.5.2 RACH/FACH Re-establishment .................................................................................................................209.6 Radio Access Bearer Establishment....................................................................................................................209.6.1 DCH - DCH Establishment - Synchronized................................................................................................209.6.2 DCH - DCH Establishment - Unsynchronized (PSTN/ISDN Core Network..............................................229.6.3 RACH/FACH - DCH Establishment ..........................................................................................................249.6.4 RACH/FACH - RACH/FACH Establishment ............................................................................................259.7 Radio Access Bearer Release..............................................................................................................................259.7.1 DCH - DCH Release - Synchronized..........................................................................................................259.7.2 DCH - DCH Release - Unsynchronized......................................................................................................279.7.3 DCH - RACH/FACH Release ....................................................................................................................299.7.4 RACH/FACH - RACH/FACH Release ......................................................................................................299.8 Radio Access Bearer Re-establishment...............................................................................................................299.8.1 DCH - DCH Re-establishment....................................................................................................................299.8.2 RACH/FACH - DCH Re-establishment .....................................................................................................299.8.3 RACH/FACH - RACH/FACH Re-establishment .......................................................................................29

25.931 V1.1.1 1999-064

9.9 Radio Access Bearer Modification .....................................................................................................................309.9.1 DCH to DCH Modification ........................................................................................................................319.9.2 RACH/FACH TO RACH/FACH Reconfiguration.....................................................................................329.9.3 RACH/FACH TO DCH Reconfiguration ...................................................................................................329.9.4 DCH TO RACH/FACH RECONFIGURATION .......................................................................................339.10 Physical Channel Reconfiguration ...................................................................................................................349.11 Channel Type Switching ..................................................................................................................................349.11.1 RACH/PCH to RACH/FACH.....................................................................................................................349.11.2 RACH/FACH to RACH/PCH.....................................................................................................................359.11.3 RACH/FACH to DCH................................................................................................................................359.11.4 DCH to RACH/FACH................................................................................................................................369.12 Soft Handover ..................................................................................................................................................369.12.1 Radio Link Addition (Branch Addition).....................................................................................................379.12.2 Radio link Deletion (Branch Deletion) .......................................................................................................389.12.3 Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously)......................................399.13 Hard Handover .................................................................................................................................................409.13.1 Backward Hard Handover ..........................................................................................................................409.13.2 Forward Hard Handover .............................................................................................................................469.14 URA Update.....................................................................................................................................................489.14.1 Inter-RNS URA Update with SRNS Relocation.........................................................................................489.14.2 Inter-RNS URA Update via Iur without SRNS relocation..........................................................................489.14.3 SRNS Relocation (UE connected to two CN nodes) ..................................................................................499.15 HO between UTRAN and GSM/BSS...............................................................................................................519.15.1 UTRAN � GSM/BSS................................................................................................................................519.15.2 GSM/BSS � UTRAN................................................................................................................................539.15.3 UTRAN � GPRS ......................................................................................................................................549.15.4 UTRAN � GSM/BSS................................................................. ｴﾗｰｴﾗｰｴﾗｰｴﾗｰ! ﾌﾞｯｸﾏｰｸが定義されていません。ﾌﾞｯｸﾏｰｸが定義されていません。ﾌﾞｯｸﾏｰｸが定義されていません。ﾌﾞｯｸﾏｰｸが定義されていません。9.16 Load Indication ................................................................................................................................................559.17 Ciphering..........................................................................................................................................................559.18 Transport CH Reconfiguration.........................................................................................................................569.18.1 Transport CH Reconfiguration (Dedicated CH to Dedicated CH) .............................................................569.18.2 Transport CH Reconfiguration (RACH/FACH to RACH/FACH)..............................................................579.18.3 Transport CH Reconfiguration (RACH/FACH to Dedicated CH) .............................................................589.18.4 Transport CH Reconfiguration (Dedicated CH to RACH/FACH) .............................................................599.19 Notification ......................................................................................................................................................609.20 DL Code Reconfiguration ................................................................................................................................619.21 Direct Transfer .................................................................................................................................................629.21.1 Uplink Direct Transfer................................................................................................................................629.21.2 Downlink Direct Transfer...........................................................................................................................639.22 Downlink Power Control..................................................................................................................................64

10. ANNEX: status of the document........................................................................................................... 69

25.931 V1.1.1 1999-065

2 Intellectual Property Rights

3 ForewordThe contents of the present document are subject to continuing work within the TSG and may change following formalTSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifyingchange of release date and an increase in version number as follows:

Version 3.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

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

4 ScopeThis 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 toperform system functions. This gives an overall understanding of how the UTRAN works in example scenarios

5 ReferencesReferences may be made to:

a) specific versions of publications (identified by date of publication, edition number, version number, etc.), inwhich case, subsequent revisions to the referenced document do not apply;

b) all versions up to and including the identified version (identified by "up to and including" before the versionidentity);

c) all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); or

d) publications without mention of a specific version, in which case the latest version applies.

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.

[5] 25.931UTRAN Overall Description

25.931 V1.1.1 1999-066

[6] 25.414 UTRAN Iu Interface RANAP Signalling

[7] 25.424 UTRAN Iur Interface RNSAP Signalling

[8] 25.434 UTRAN IubInterface NBAB Signalling

[9] 25.832 Manifestations of Handover and SRNS Relocation

[10] UMTS YY.01 MS-UTRAN Radio Interface Protocol Architecture

[14] UMTS YY.31 Description of RRC protocol

Editor note: reference [10] and [14] should be updated, the numbering will be updated when the list will be stable

6 Definitions, abbreviations and notation

6.1 DefinitionsRefer to [5].

6.2 AbbreviationsFor the purposes of this specification the following abbreviations apply.

ALCAP Access Link Control Application PartAS Access StratumBSSMAP Base Station System Management Application PartCN Core NetworkCRNC Controlling RNCDCH Dedicated ChannelDRNS Drift RNSL1 Layer 1MAC Medium Access ControlMSC Message Sequence ChartNAS Non Access StratumNBAP Node B Application ProtocolPCH Paging ChannelRAB Radio Access BearerRACH Random Access ChannelRANAP Radio Access Network Application PartRLC Radio Link ControlRNC Radio Network ControllerRNS Radio Network SubsystemRNSAP Radio Network Subsystem Application PartRRC Radio Resource ControlSRNS Serving RNSUE User EquipmentUMTS Universal Mobile Telecommunication SystemUTRAN UMTS Terrestrial Radio Access Network

6.3 Notation for the signalling proceduresComplex signalling procedures may involve several protocols in different nodes.

25.931 V1.1.1 1999-067

In order to facilitate the understanding of these procedures, the following rules in the drawing of Message SequenceChart (MSC) are applied:

• Messages are always exchanged between nodes, i.e. the sender and the receiver of a message are nodes and notsingle 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 theprocedures;

• 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 shownin Figure 1.

• The transport channel used by the MAC protocol or the logical channel used by the RLC and RRC protocols maybe indicated before the message name as shown in Figure 1.

UE N ode BD rift R N S

N ode BServing R N S

RN CD rift

RN CServ ing

C N

N BA P

M A C

N BAP

RA NA P RAN A P

RN SAP RNSA P

M A C1. R A C H : M essage

RRCRRC2. C C C H : M essage

3 . M essage

6. M essage

5. M essage

[Param eters]

[Param eters]

[Parameters]

[Param eters]

[Param eters]

A ction description

NBA PN BA P4. M essage

[Param eters]

A LC AP Iub Bearer Setup/Release A LC A P Iur Bearer Setup

D C H D SD C H D S7. DC H D ata Fram e

[Param eters]

Figure 1: Example of signalling procedure notation

25.931 V1.1.1 1999-068

7 UTRAN AND UE PROTOCOL ARCHITECTURE

7.1 Protocol ArchitectureThe complete UTRAN and UE protocol architecture for the control plane (including the transport layers) is shown inFigure 2 (idle mode) and Figure 3 (connected mode). For a detailed description of the UTRAN Protocol Architectureand of the Radio Protocol Architecture refer to [5] and [10] respectively.

RRC NBAP NBAP RANAP

UE Node B CRNC CNUu Iub Iu

Transport Layers Transport Layers

RANAP

Transport Layers

RRC

BCH, PCH

BCCH, PCCH

Figure 2: UTRAN and UE control plane protocol architecture (idle mode)

RRC NBAP NBAP

UE Node B SRNC CNUu Iub Iur Iu

Transport Layers Transport Layer Transport Layers

RRCRNSAP RANAPRANAP

Transport Layers

RNSAP

DRNC

DCH, RACH, FACH, DSCH

RACH, FACH

DCCH

CCCH, DCCH

Figure 3: UTRAN and UE control plane protocol architecture (connected mode)

25.931 V1.1.1 1999-069

7.2 RANAP Procedures & MessagesFor a detailed description of RANAP procedures and messages refer to [6].

Editor note: to be aligned with the protocol specification documents

Message Name UTRAN Procedure Direction

Initial UE Message NAS Signalling Connection Establish. Source RNC � CN

RAB Assignment Request RAB Establishment

RAB Release

Inter-RNS HO with switching in the CN

CN � Source RNC

CN � Source RNC

CN � Source RNC

RAB Assignment Complete RAB Establishment

RAB Release

Source RNC � CN

Source RNC � CN

Relocation Required Hard HO with switching in the CN

UTRAN � GSM/BSS handover

SRNS Relocation

Source RNC � CN

Source RNC � CN

Source RNC � CN

Relocation Request Hard HO with switching in the CN


GSM/BSS handover � UTRAN

SRNS Relocation

CN � Target RNC

CN � Source RNC

CN � Target RNC

CN � Target RNC

Relocation Request Acknowlede Hard HO with switching in the CN


SRNS Relocation

Target RNC � CN

Target RNC � CN

Target RNC � CN

Relocation Command Hard HO with switching in the CN

SRNS Relocation

CN � Source RNC

CN � Source RNC

Relocation Detect Hard HO with switching in the CN


Target RNC � CN

Target RNC � CN

Relocation Complete Hard HO with switching in the CN


SRNS Relocation

Target RNC � CN

Target RNC � CN

Target RNC � CN

Relocation Failure SRNS Relocation RNC � CN

Iu Release Command Hard HO with switching in the CN

SRNS Relocation


CN � Source RNC

CN � Source RNC

CN � Source RNC

Iu Release Complete Hard HO with switching in the CN Source RNC � CN

25.931 V1.1.1 1999-0610

SRNS Relocation


Source RNC � CN

Source RNC � CN

Paging Paging CN � SRNC

7.3 RNSAP Procedures & MessagesFor a detailed description of RNSAP procedures and messages refer to [7].



Radio Link ReconfigurationPrepare

RAB Establishment

RAB Release

SRNC � DRNC

SRNC � DRNC

Radio Link Reconfiguration Ready RAB Establishment

RAB Release

DRNC � SRNC

DRNC � SRNC

Radio Link Reconfiguration RAB Establishment

RAB Release

SRNC � DRNC

SRNC � DRNC

Radio Link ReconfigurationResponse

RAB Establishment

RAB Release

DRNC � SRNC

DRNC � SRNC

Radio Link ReconfigurationCommit

RAB Establishment

RAB Release

SRNC � DRNC

SRNC � DRNC

Radio Link Addition Soft Handover SRNC � DRNC

Radio Link Addition Response Soft Handover DRNC � SRNC

Radio Link Deletion Soft Handover SRNC � DRNC

Radio Link Deletion Response Soft Handover DRNC � SRNC

SRNS Relocation Commit SRNS Relocation Source RNC � TargetRNC

7.4 NBAP Procedures & MessagesFor a detailed description of NBAP procedures and messages refer to [8].



Radio Link Setup RRC Connection Establishment RNC � Node B

25.931 V1.1.1 1999-0611

Hard Handover

Soft Handover

RNC � Node B

RNC � Node B

Radio Link Setup Respose RRC Connection Establishment

Hard Handover

Soft Handover

Node B � RNC

Node B � RNC

Node B � RNC

Radio Link Addition Soft Handover RNC � Node B

Radio Link Addition Response Soft Handover RNC � Node B

Radio Link Deletion RRC Connection Release

Hard Handover

Soft Handover

RNC � Node B

RNC � Node B

RNC � Node B

Radio Link Deletion Response RRC Connection Release

Hard Handover

Soft Handover

Node B � RNC

Node B � RNC

Node B � RNC

Radio Link ReconfigurationPrepare

RAB Establishment

RAB Release

RNC � Node B

RNC � Node B

Radio Link Reconfiguration Ready RAB Establishment

RAB Release

Node B � RNC

Node B � RNC

Radio Link ReconfigurationCommit

RAB Establishment

RAB Release

RNC � Node B

RNC � Node B

Paging Paging RNC � Node B

7.5 ALCAPALCAP is a generic name to indicate the protocol(s) used to establish data transport bearers on the Iu, Iur and Iubinterfaces. Q.2630.1 (Q AAL2) is one of the selected protocol to be used as ALCAP.

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.

7.5.1 Q2630.1 (Q.AAL 2)Editor note: the exact procedures are needed to be derived from the reccomandation, therefore the following sectionshould b intended as example. Contribution invited.

25.931 V1.1.1 1999-0612

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

UE Node BDrift RNS

Node BServing RNS

DriftRNC

ServingRNC

CN

11.

Establish RequestQ.aal2 Q.aal2

Q.aal2Q.aal2 Establish Confirm

9Establish Request Q.aal2Q.aal2

Q.aal2 Q.aal2Establish Confirm

Establish Request Q.aal2Q.aal2


Establish Request Q.aal2Q.aal2


7.6 RRC Procedures & MessagesFor a detailed description of RRC procedures and messages refer to [14].


Message Name UTRAN Procedure Direction Logical Channel

UE Capability Information NAS Signalling Conn. Est. UE � SRNC DCCH

Direct Transfer NAS Signalling Conn. Est. UE ⇔ SRNC DCCH

RRC Connection Request RRC Connection Est. UE � SRNC CCCH

RRC Connection Setup RRC Connection Est. SRNC � UE CCCH

RAB Setup RAB Establishment SRNC � UE DCCH

RAB Setup Complete RAB Establishment UE � SRNC DCCH

RAB Release RAB Release SRNC � UE DCCH

RAB Release Complete RAB Release UE � SRNC DCCH

Handover Command

Hard Handover SRNC � UE

DCCH

25.931 V1.1.1 1999-0613

Handover Complete

Hard Handover UE � SRNC

DCCH

Active Set Update Soft Handover SRNC � UE DCCH

Active Set Update Complete Soft Handover UE � SRNC DCCH

Paging Paging for a UE in RRC ConnectedMode

SRNC � UE DCCH

25.931 V1.1.1 1999-0614

8 UTRAN Signaling ProceduresThe signalling procedures shown in the following sections do not represent the complete set of possibilities, nor do theymandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which maybe combined in different ways in an implementation. Therefore these sequences are merely examples of a typicalimplementation.

Furthermore the list of parameters may not be complete, but should only be seen as examples of possible informationcarried by the messages.

NOTE: the use of Radio Bearer Setup or Radio Bearer Assignement is FFS. This note is valid for all the document

9 Procedures not related to a specific UE (globalprocedures)

This section presents a number of signaling procedures not related to a specific UE. The protocol stack involved duringthese procedures is the one shown in Figure 2.

9.1 System Information BroadcastingThis example shows an example of System Information broadcasting.

Cell Broadcast

This example shows an example of broadcasting of User Information.

10 Procedures related to a specific UEThis section presents a number of signaling procedures related to a specific UE. The protocol stack involved duringthese procedures is the one shown in Figure 3, with the exception of Paging for a UE in RRC Idle Mode that makes useof the protocol stack shown in Figure 2.

10.1 PagingThis section presents two examples of Paging procedures for both the cases of a UE in RRC Idle Mode and RRCConnected Mode.

10.1.1 Paging for a UE in RRC Idle ModeThis 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 adefined geographical area (e.g. LA).

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

25.931 V1.1.1 1999-0615

UE N ode B1.1

N ode B2.1

RN C1

RN C2

C N

RA N A PRA N A P 1. Pagin g

N BA PN BA P2. Pagin g

3. PC C H : Pagin g

RA N A P RA N AP1. Paging

N BA PN BA P2. Pagin g

4. PC C H : Pagin g

5 . N A S Sign alling C onn ection E stablishm en t

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: UE identifier, Paging Type.

2. RNC1 and RNC2 forward Paging message via NBAP to corresponding Nodes B (for example Node B 1.1, Node B2.1).

Parameters: UE identifier.

3. Paging of UE performed by cell1

4. Paging of UE performed by cell2

5. UE detects page message from RNC1 and the procedure for NAS signalling connection establishment is followed

NAS message transfer over established signalling connection can now be performed.

10.1.2 Paging for a UE in RRC Connected ModeThis can occur in case of two core network domains, with the mobility management independent of each other. Twopossible 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 when the UTRANcoordinates the paging request with the existing RRC connection using DCCH.

UE Servin gRN C

C N

RRCRRC2. D C C H : Pagin g

RA N A P RA N A P1. Pagin g

25.931 V1.1.1 1999-0616

Paging for a UE in RRC Connected Mode when the UTRAN coordinates the paging request with the existingRRC connection using DCCH

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

Parameters: UE identifier, Paging Type.

2. SRNC sends RRC message Paging .

Parameters: Paging Type.

10.2 NAS Signalling Connection EstablishmentThe following examples show establishment of a Signalling Connection either by the UE or by the CN.

10.2.1 UE Initiated Signalling Connection EstablishmentThis example shows establishment of a UE originated NAS Signalling Connection Establishment.

UE Servin gRN C

C N

1. RRC Con n ection E stablish m en t

RRCRRC2. D CC H : UE C apability In form ation

RRCRRC3. D C C H : D irect T ran sfer

RA N A P RA N A P4. In itia l UE M essage

NAS Signalling Connection Establishment

1. RRC Connection is established (see 9.3.1 or 9.3.2).

2. UE sends RRC message UE Capability Information to SRNC.Parameters: UE Radio Capability (e.g. maximum number of simultaneous radio links, maximum TX powercapability, supported radio access types).

Note: To speed up the transfer of the initial NAS message the RRC message UE Capability Information could betransferred after the initial NAS message (step 3). This issue is FFS.

3. UE sends RRC Direct Transfer to SRNC.Parameters: Initial NAS Message (could for a GSM based CN be e.g. CM Service Request, Location UpdateRequest etc.) CN node indicator (it indicates the correct CN node into which the NAS message shall be forwarded).

4. SRNC initiates signalling connection to CN, and sends the RANAP message Initial UE Message.Parameters: Initial NAS Message (could for a GSM based CN be e.g. CM Service Request, Location UpdateRequest etc.).

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

10.2.2 CN Initiated Signalling Connection EstablishmentThis example shows establishment of a CN originated NAS Signalling Connection Establishment.

25.931 V1.1.1 1999-0617

10.3 RRC Connection EstablishmentThe following examples show establishment of a RRC connection either on a dedicated channel (DCH) or on a commontransport channel

10.3.1 DCH EstablishmentThis example shows establishment of an RRC connection on a dedicated channel (DCH).

UE N ode BServing R N S

Servin gRN C

5. N odeB-SRN C D ata T ran spor t Bearer Syn c(FD D on ly)

A lloca te RN T ISelect L1 an d L2

param eters

RRCRRC1. CC C H : RRC C on n ection Request

N BA PN BA P3. Radio Lin k Setup Respon se

N BA PN BA P2. Radio Lin k Setup

RRCRRC6. C C CH : RRC C on n ection Setup

Start RX

Start T X

4. A LCA P Iub D ata T ran sport Bearer Setup

RRC Connection Establishment - DCH Establishment

1. The UE initiates set-up of an RRC connection by sending RRC message Connection Request on CCCH.Parameters: UE identification, reason for RRC connection.Note: Type of UE identification and Layer 1 Node B Acknowledge on RACH (CCCH) are FFS.

2. The SRNC decides to use a DCH for this RRC connection, allocates RNTI and radio resources for the RRCconnection. When a DCH is to be set-up, NBAP message Radio Link Setup is sent to Node B.Parameters: Cell id, Transport Format Set, Transport Format Combination Set, frequency, UL scramblingcode(FDD only), Time Slots (TDD only), User Codes (TDD only),DL channelisation code, Power controlinformation.

3. Node B allocates resources, starts PHY reception, and responses with NBAP message Radio Link Setup Response.Parameters: Signalling link termination, , DL channelisation code (FDD only), Transport layer addressinginformation (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 AAL2Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of Iub Data Transportbearer is acknowledged by Node B.

5. Node B and SRNC establish synchronism for the Iub Data Transport Bearer. Then Node B starts DL transmission.(FDD only)

6. Message RRC Connection Setup is sent on CCCH from SRNC to UE.Parameters: UE identification, RNTI, Transport Format Set, Transport Format Combination Set, frequency, DLscrambling code (FDD only), Time Slots (TDD only), User Codes (TDD only), DL channelisation code(FDD only),Power control information.

25.931 V1.1.1 1999-0618

10.3.2 RACH/FACH EstablishmentThe procedure for establishment of an RRC connection on a common transport channel (RACH/FACH) is described in[Editor note: appropriate reference to the WG2 documentation is needed]. A prerequisite for this example is that thenecessary Iub Data Transport bearer for the RACH/FACH is established prior to this procedure.

10.4 RRC Connection ReleaseThe following examples show RRC connection release either of a dedicated channel (DCH) or of a common transportchannel (RACH/FACH).

10.4.1 DCH ReleaseThis example shows RRC Connection release of a dedicated channel.

2. Iu R ELEA SE C O M PLETE

1. Iu R ELEA SE C OM M A N D

10. R A D IO LIN K D ELE TIO N R ESPO N SE( Iub)

8. R A D IO LIN K D ELETIO N ( Iub)

9. R AD IO LIN K D ELETIO N R ES PO N SE( Iu b)

6. R A D IO LIN K D ELE TIO N (Iu b)

5. R R C C O N N EC TIO N R ELEA SE C O M PLETE (F FS)

4. R R C C ON N EC TIO N R ELEA SE

11. R A D IO LIN K D EL ETIO NR ESPO N SE( Iu r)

7. R A D IO L IN K D ELETIO N( Iu r)

UE N o de BD rift RN S

N o de BServing RN S

D riftR N C

ServingR N C

C N

R R CR R C

R R CR R C

N B A PN BA P

N B A PN BA P

R N S A PR N SA P

N BA PN BA P

N BA PN BA P

R N S A PR N SA P

R A N A PR A N AP

R A N A PR A N AP

3. A LC A P Iu BearerR ELEA SE

A LC A P Iu r BEA R ERR ELEA SE

13. A LC A P Iub BEA R ER R ELEA S E

12. A LC A P Iub BEA R E R R ELE A SE

RRC Connection release of a dedicated channel

10.4.2 Common Transport Channel ReleaseThis example shows RRC Connection release of a common transport channel.

2 . Iu R ELEASE C OM PLETE

1 . Iu R ELEASE C O M M AN D

5 . R R C C ON N EC TION R ELEASE C O M P LETE (FF S)

4 . R R C C ON NE C TIO N R ELEASE

U E N o de BDrift R NS

N o de BS ervin g R N S

D riftR N C

ServingR N C

C N

R R CR R C

R R CR R C

R ANAPR ANAP

R ANAPR ANAP

3 . ALC AP Iu B EAR ERR ELEASE

25.931 V1.1.1 1999-0619

RRC Connection release of a common transport channel

10.5 RRC Connection Re-establishmentThe following examples show re-establishment of a RRC connection either on a dedicated channel (DCH) or on acommon transport channel.

10.5.1 DCH Re-establishmentThis example shows re-establishment of a RRC connection on a dedicated channel (DCH).

16 D C C H: RRC C on n ection Re-establish m en tC om plete

14. D own lin k T ran sfer

12 . Radio Lin k Setup Respon se

11 . Radio Lin k Setup Respon se

10. Radio Lin k Setup

9. Radio Lin k Setup

2. Uplin k T ran sferR N SAP R N SAP

R N SAP R N SAP

N BA P N BA P

N BA P N BA P

R N SAPR N SAP

R N SAP R N SAP

15. T ran sm ission ofUu Sign allin g

M essage

RRC RRC

1. Reception of UuSign allin g M essage

A LC A P IubBearer Setup13 . A LC A P Iur Bearer Setup

8. A LC A P Iub BearerRelease

5 . A LC A P IurBearer Release

4. Radio Lin k D eletion Respon se

RN SA P RN SA P

RN SA P RN SA P

3. Radio Lin k D elition

7 Radio Lin k D eletion Respon se

N BA P N BA P

N BA P N BA P

6 Radio Lin k D elition

UE S-RN C O ldD -RN C

O ldN ode B

N ewD -RN C

N ewN ode B

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 RRCConnection Re-establishment Request message on CCCH.

25.931 V1.1.1 1999-0620

2. The new RNC delivers this message transparently as Uplink Transfer message to the serving RNC.

3./4./5./6./7./8. The SRNC initiates release of Iur/Iub Data Transport bearer using ALCAP protocol and alsorelease of Iur/Iub Radio resource using RNSAP / NBAP protocols.

9. The serving RNC allocates new RNTI and radio resources for the RRC connection on Iur, and sends theRNSAP message Radio Link Setup to the target RNC.

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

11. Node B allocates resources, and responses with NBAP message Radio Link Setup Response.

12. Target RNC responses with RNSAP message Radio Link Setup Response.

13. Serving RNC initiates set-up of Iur / Iub Data Transport bearer using ALCAP protocol. This requestcontains the AAL2 Binding Identity to bind the Iur / Iub Data Transport Bearer to the DCH. The request forset-up of Iur / Iub Data Transport bearer is acknowledged by target RNC / Node B.

14. The serving RNC sends the transparent RNSAP message Downlink transfer to the new CRNC.

15. The New CRNC delivers this message as RRC Connection Re-establishment message on CCCH.

16. Message RRC Connection Re-establishment Complete is sent on the new DCCH from the UE to theserving RNC.

10.5.2 RACH/FACH Re-establishmentThis example shows re-establishment of a RRC connection on a common transport channel .

10.6 Radio Access Bearer EstablishmentThe following examples show establishment of a radio access bearer on a dedicated channel (DCH) or on a commontransport channel (RACH/FACH) when the RRC connection already support a radio access bearer either on a dedicatedchannel (DCH) or on a common transport channel (RACH/FACH).

10.6.1 DCH - DCH Establishment - SynchronizedThis example shows establishment of a radio access bearer on a dedicated channel (DCH) when the RRC connectionalready uses a dedicated channel (DCH).

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

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

25.931 V1.1.1 1999-0621



D riftRN C

Servin gRN C

C N

RN SA P RNSA P7. Rad io L in k Recon figuration

Ready

RRCRRC16. D C C H : Rad io A ccess Bearer Setup C om plete

N BA PN BA P8. Radio Link Recon figuration Ready

N BA PN BA P6 Radio Link Reconfigura tion Ready

11. N odeB-SRN C Data T ranspor t Bearer Sync.

N BA PN BA P 14. Rad io L in k Recon figu ra tion C om m it

RN SA P RNSA P12. Radio Link Reconfigura tion

C om m it

N BA PN BA P13. Rad io L in k Recon figuration C om m it

RRCRRC15. D C C H : Rad io A ccess Bearer Setup

A pply new transport form at set

Select L1, L2 an d Iu D ataTran spor t Bearer param eters

RA N A P RA N AP

17 . RA B A ssignm en tC om plete

10. ALC A P Iub D ata Tran sport Bearer Setup

2. A LC AP Iu D ataT ransport Bearer Setup

RA N A P RA N AP

1. RA B A ssignm en tRequest

[Establishm ent]

RN SA P RN SA P3. Radio Link Reconfiguration

Prepare

[D C H A ddition]N BA PN BA P

4. Radio Lin k Reconfigura tion Prepare

[DC H Add ition]

N BA PN BA P5. Radio Lin k Reconfigura tion Prepare

[DC H Add ition]

A LC A P Iur Bearer Setup9 . A LC A P Iub Data T ranspor t Bearer Setup

Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronized

1. CN initiates establishment of the radio access bearer with RANAP message RAB Assignment Request.Parameters: RAB QoS parameters, Transport layer addressing information (AAL2 address, AAL2 Binding Identity)for Iu Data Transport Bearer SRNC decides the requirements on L1, L2 and Iu Data Transport Bearer.

2. SRNC initiates set-up of Iu Data Transport bearer using ALCAP protocol. This request contains the AAL2 BindingIdentity to bind the Iu Data Transport Bearer to the Radio Access Bearer.

3. SRNC requests DRNC to prepare establishment of DCH to carry the RAB (Radio Link Reconfiguration Prepare).Parameters: Transport Format Set, Transport Format Combination Set, Power control information, instructions forDCH mapping on Iub Data Transport Bearers.This step is applicableonly when more Nodes B are involved.

4. DRNC requests its Node B to prepare establishment of DCH to carry the RAB (Radio Link ReconfigurationPrepare).Parameters: Transport Format Set, Transport Format Combination Set, Power control information, , DLchannelisation code.This step is applicableonly when more Nodes B are involved.

5. SRNC requests its Node B to prepare establishment of DCH to carry the RAB (Radio Link ReconfigurationPrepare).

25.931 V1.1.1 1999-0622

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 TransportBearer.This step is applicableonly when more Nodes B are involved.

7. DRNC notifies SRNC that the preparation is ready (Radio Link Reconfiguration Ready).Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iub Data TransportBearer.This step is applicableonly when more Nodes B are involved.

8. Node B allocates resources and notifies SRNC that the preparation is ready (Radio Link Reconfiguration Ready).Parameters: DL channelisation code Per Cell (FDD only), Transport layer addressing information (AAL2 address,AAL2 Binding Id) for Iub Data Transport Bearer.

9. SRNC initiates setup of Iur/Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH.This step is applicableonly when more Nodes B are involved.

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

11. The Nodes B and SRNC establish synchronism for the Iub and Iur Data Transport Bearer.This step is applicableonly for the FDD case..

12. RNSAP message Radio Link Reconfiguration Commit is sent from SRNC to DRNC.Parameters:This step is applicableonly when more Nodes B are involved.

13. NBAP message Radio Link Reconfiguration Commit is sent from DRNC to Node B.Parameters:This step is applicableonly when more Nodes B are involved.

14. NBAP message Radio Link Reconfiguration Commit is sent from SRNC to Node B.Parameters:

15. RRC message Radio Access Bearer Setup is sent by SRNC to UE.Parameters: Transport Format Set, Transport Format Combination Set, DL channelisation code per cell(FDD only),Time Slots (TDD only), User Codes (TDD only).

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

17. SRNC sends RANAP message RAB Assignment Complete to CN.

10.6.2 DCH - DCH Establishment - Unsynchronized (PSTN/ISDN CoreNetwork

This example shows an establishment of a radio access bearer on a dedicated channel (DCH) when the RRC connectionalready uses a dedicated channel (DCH). 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.

25.931 V1.1.1 1999-0623

UE Node BDrift RNS

Node BServing RNS

DriftRNC

ServingRNC

CN

RNSAP RNSAP8. RL Reconfiguration

Response

RRCRRC16. Radio Access Bearer Setup Complete

NBAPNBAP 12. Radio Link Reconfiguration Response

NBAPNBAP7. Radio Link Reconfiguration Response

14. NodeB-SRNC Data Transport Bearer Sync.

RRCRRC15. Radio Access Bearer Setup

Apply new transport format set

Select L1, L2 and Iu DataTransport Bearer parameters

RANAP RANAP

17. RAB AssignmentComplete

2. Establish Request

RANAP RANAP

1. RAB AssignmentRequest

[Establishment]


[DCH Addition]NBAPNBAP 4. Radio Link Reconfiguration

[DCH Addition]

NBAPNBAP5. Radio Link Reconfiguration

[DCH Addition]

Q.aal2 Q.aal2

Q.aal2Q.aal2 6. Establish Confirm

11.

9. ALCAP Iur Data Transport Bearer Setup

10. ALCAP Iub Data Transport Bearer Setup


Radio Access Bearer Establishment - DCH - DCH Establishment – Unsynchronised

1. CN initiates establishment of the radio access bearer with RANAP Radio Access Bearer Assignment Requestmessage.Parameters: RAB QoS parameters, AAL2 binding Identity

2. SRNC performs mapping of the RAB QoS parameters to AAL2 link characteristics and initiates set-up of Iu DataTransport bearer with Q.aal2 Establish Request message.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 newDCH. It include in the message that the modification shall be done immediately without waiting for the commandmessage.

25.931 V1.1.1 1999-0624

Parameters: Bearer ID, Mode= Unsynchronised, Transport Format Set, Transport Format Combination Set, Powercontrol information

4. DRNC requests its Node B to establish of a new DCH in the existing Radio Link.Parameters: Bearer ID, Mode= Unsynchronised, Transport Format Set, Transport Format Combination Set, Powercontrol information.

5. SRNC requests its Node B setup a new DCH in the existing Radio Link.Parameters: Bearer ID, Mode= Unsynchronised, Transport Format Set, Transport Format Combination Set, Powercontrol information

6. CN confirms the establishment of the transport bearer and binds it to the radio network layer.

7. Node B allocates resources and notifies DRNC that the setup is done.Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iub Data TransportBearer.

8. DRNC notifies SRNC that the setup is done.Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iub Data TransportBearer.

9. SRNC initiates setup of Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2 BindingIdentity to bind the Iur Data Transport Bearer to DCH.


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

12. Node B allocates resources and notifies SRNC that the setup is done.Parameters: Transport layer addressing information (AAL2 address, AAL2 Binding Id) for Iub Data TransportBearer.


14. The Nodes B and SRNC establish frame synchronism for the Iub and Iur Data Transport Bearer.

15. RRC message Radio Access Bearer Setup is sent by SRNC to UE.Parameters: Transport Format Set, Transport Format Combination Set.

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

17. SRNC sends RANAP message Radio Access Bearer Assignment Complete to CN.Parameters: Binding ID

10.6.3 RACH/FACH - DCH EstablishmentThis example shows establishment of a radio access bearer on a dedicated channel (DCH) when the RRC connectionalready uses a common transport channel (RACH/FACH).

8. RA B SE T UP RE SPO N SE

7. RA D IO A CC E SS BE A RE R SE T UP C O M PLE T E

6. RA D IO A CC E SS BE A RE R SE T UP

1. RA B SE T UP

3. RA D IO LIN K SE T UPRE SPO N SE (Iub)

2 . RA D IO LIN K SE T UP(Iub)


Servin gRN C

C N

RA N A P RA N A P

N BA PN BA P

N BA PN BA P

RRCRRC

RRCRRC

RA N A P RA N A P

4. A LC A P Iub BE A RE R SE T UP

5. A LC A P Iu BE A RE RSE T UP

25.931 V1.1.1 1999-0625

10.6.4 RACH/FACH - RACH/FACH EstablishmentThis example shows establishment of a radio access bearer on a common transport channel (RACH/FACH) when theRRC connection already uses a common transport channel (RACH/FACH).

10.7 Radio Access Bearer ReleaseThe following examples show release of a radio access bearer either on a dedicated channel (DCH) or on a commontransport channel (RACH/FACH) when the RRC connection already uses a dedicated channel (DCH) or a commontransport channel (RACH/FACH).

10.7.1 DCH - DCH Release - SynchronizedThis example shows release of a radio access bearer on a dedicated channel (DCH) when the RRCconnection still uses adedicated 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 byDRNC.]

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

5. RA B SE T UP RE SPO N SE

4. RA D IO A CC E SS BE A RE R SE T UP C O M PLE T E

3. RA D IO A CC E SS BE A RE R SE T UP

1. RA B SE T UP


Servin gRN C

C N

RRCRRC

RRCRRC

RA N A P RA N A P

RA N A P RA N A P

2. A LC A P Iu BE A RE RSE T UP

25.931 V1.1.1 1999-0626


N ode BServ ing R N S

D riftR N C

ServingRN C

C N

RN SA P RN S A P8. R adio L in k Recon figura tion

R eady

RRCRR C14. D C C H : R adio A ccess Bearer Release C om plete

N BA PN BA P9. Radio L in k R econfiguration Ready

N BA PN B A P7. R ad io L in k Recon figura tion R eady

N BA PN BA P12. Radio Lin k R econ figuration C om m it

RN SA P RN S A P10 . Radio L ink Recon figura tion

C om m it

RRCRR C13. D C C H : Radio A ccess B earer Release

A pply new tran spor t form at set

RA N A P RA N A P

2. R A B A ssignm en tC om plete

N BA PN B A P11 . R ad io L in k Recon figura tion C om m it

16 . A LC A P Iub D ata T ran spor t Bearer Release

3 . A LC A P Iu D ataT ransport B earer Release

RA N A P RA N A P1. R A B A ssignm en t

Request[R elease]

RN SA P RN SA P4. R adio L in k Recon figura tion

Prepare[D C H D eletion]

N BA PN B A P5. Radio L ink Recon figura tion Prepare

[D C H D ele tion]

N BA PN BA P6. Rad io Lin k Recon figura tion Prepare

[D C H D ele tion]

A LC A P Iu r Bearer Release15 . A LC A P Iub D ata T ransport B earer Release

Radio Access Bearer Release - DCH - DCH Release - Synchronized

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

2. SRNC acknowledges the release of radio access bearer (RAB Assignment Complete).

3. SRNC initiates release of the Iu Data Transport bearer between the CN and the SRNC using the ALCAP protocol.

4. SRNC requests DRNC to prepare release of DCH carrying the RAB (Radio Link Reconfiguration Request).Parameters: Transport Format Combination Set, UL scrambling code.This step is applicableonly when more Nodes B are involved.

5. DRNC requests its Node B to prepare release of DCH carrying the RAB (Radio Link Reconfiguration Prepare).Parameters: Transport Format Combination Set, UL scrambling code, DL channelisation code.This step is applicableonly when more Nodes B are involved.

6. SRNC requests its Node B to prepare release of DCH carrying the RAB (Radio Link Reconfiguration Prepare).Parameters: Transport Format Combination Set, UL scrambling code (FDD only), Time Slots (TDD only), UserCodes (TDD only).

7. Node B notifies DRNC that release preparation is ready (Radio Link Reconfiguration Ready).This step is applicableonly when more Nodes B are involved.

8. DRNC notifies SRNC that release preparation is ready (Radio Link Reconfiguration Proceed).This step is applicableonly when more Nodes B are involved.

25.931 V1.1.1 1999-0627

9. Node B notifies SRNC that release preparation is ready (Radio Link Reconfiguration Ready).Parameters: DL channelisation code per cell (FDD only).

10. RNSAP message Radio Link Reconfiguration Commit is sent from SRNC to DRNC.This step is applicableonly when more Nodes B are involved.

11. NBAP message Radio Link Reconfiguration Commit is sent from DRNC to Node B.This step is applicableonly when more Nodes B are involved.

12. NBAP message Radio Link Reconfiguration Commit is sent from SRNC to Node B.Parameters:

13. RRC message Radio Access Bearer Release is sent by SRNC to UE.Parameters: Transport Format Set, Transport Format Combination Set, DL channelisation code per cell. (FDD only),Time Slots (TDD only), User Codes (TDD only).

14. UE sends RRC message Radio Access Bearer Release Complete to SRNC.

15. Not used resources in DRNC and NodeB (Drift RNS) are released. DRNC initiates release of Iur and Iub (DriftRNS) Data Transport bearer using ALCAP protocolThis step is applicableonly when more Nodes B are involved.

16. Not used resources in SRNC and NodeB (Serving RNS, if any) are released. SRNC initiates release of Iub (ServingRNS) Data Transport bearer using ALCAP protocol.

10.7.2 DCH - DCH Release - UnsynchronizedThis example shows release of a radio access bearer on a dedicated channel (DCH) when the RRC connection still usesa dedicated channel (DCH) after the release. The UE communicates via two Nodes B. One Node B is controlled theSRNC, one Node B is controlled by DRNC. The reconfiguration does not require to be synchronised among Node-Bs,SRNC and UE.

25.931 V1.1.1 1999-0628

UE Node BDrift RNS

Node BServing RNS

DriftRNC

ServingRNC

CN


Response

RRCRRC3. Radio Access Bearer Release Complete



RRCRRC2. Radio Access Bearer Release

RANAP RANAP

4. RAB AssignmentComplete

12. ALCAP Iub Data Transport Bearer Release

5. ALCAP Iu DataTransport Bearer Release

RANAP RANAP1. RAB Assignment

Request[Release]

RNSAP RNSAP

6. RL Reconfiguration

[DCH Deletion]


[DCH Deletion]


[DCH Deletion]

ALCAP Iur Bearer Release11. ALCAP Iub Data Transport Bearer Release

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 Access Bearer Release is sent by SRNC to UE.

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

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

5. SRNC initiates release of the Iu Data Transport bearer between the CN and the SRNC using the ALCAPprotocol.

6. SRNC requests DRNC to release of DCH carrying the RAB.Parameters: Bearer ID, Unsynchronised, TFCS

7. DRNC requests its Node B to release of DCH carrying the RAB.Parameters: Bearer ID, Unsynchronised, TFCS

8. SRNC requests its Node B to prepare release of DCH carrying the RAB.Parameters: Bearer ID, Unsynchronised, TFCS

9. Node B acknowledges DRNC.

10. DRNC acknowledges SRNC.

11. Node B acknowledges SRNC

25.931 V1.1.1 1999-0629

12. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. Note: the release of the Iur link maybe done before step 10.

10.7.3 DCH - RACH/FACH ReleaseThis example shows release of a radio access bearer on a Dedicated channel (DCH) when the RRC connection still usesa Common transport channel (RACH/FACH) after the release (DCH to RACH/FACH).

Note this example shows case where the SRNC decides to perform SRNS Relocation directly at the channel switching.

NOTE: This procedure is FFS

10.7.4 RACH/FACH - RACH/FACH ReleaseThis example shows release of a radio access bearer on a common transport channel (RACH/FACH) when the RRCconnection still uses a common transport channel (RACH/FACH) after the release (RACH/FACH to RACH/FACH.

10.8 Radio Access Bearer Re-establishmentThe following examples show re-establishment of a radio access bearer either on a dedicated channel (DCH) or on acommon transport channel (RACH/FACH) when the RRC connection already uses a dedicated channel (DCH) or acommon transport channel (RACH/FACH).

10.8.1 DCH - DCH Re-establishmentThis example shows re-establishment of a radio access bearer on a dedicated channel (RACH/FACH) when the RRCconnection already uses a dedicated channel (DCH).

10.8.2 RACH/FACH - DCH Re-establishmentThis example shows re-establishment of a radio access bearer on a dedicated channel (RACH/FACH) when the RRCconnection already uses a common transport channel (RACH/FACH).

10.8.3 RACH/FACH - RACH/FACH Re-establishmentThis example shows re-establishment of a radio access bearer on a common transport channel (RACH/FACH) when theRRC connection already uses a common transport channel (RACH/FACH).

4. RA D IO A CC E SS BE A RE R RE LE A SE

5. RA D IO A CC E SS BE A RE R RE LE A SE C O M PLE T E

2. RA B RE LE A SERE SPO N SE

1. RA B RE LE A SE



D riftRN C

Servin gRN C

C N

RA N A P RA N A P

RRCRRC

RRCRRC

RA N A P RA N A P

3. A LC A P IuBE A RE R RE LE A SE

25.931 V1.1.1 1999-0630

10.9 Radio Access Bearer ModificationThe following examples show modification of a radio access bearer established either on a dedicated channel (DCH) oron a common transport channel (RACH/FACH).

25.931 V1.1.1 1999-0631

10.9.1 DCH to DCH ModificationThis example shows modification of a radio access bearer on a dedicated channel (DCH)

25.931 V1.1.1 1999-0632

10.9.2 RACH/FACH TO RACH/FACH ReconfigurationThis example shows reconfiguration of a radio access bearer on a common transport channel (RAH/FACH toRACH/FACH) .

This procedure is FFS. It is not yet clear if the Bearer should be effectively reconfigured of should be removed and setup again

10.9.3 RACH/FACH TO DCH ReconfigurationThis example shows reconfiguration of a radio access bearer on a common transport channel (RACH/FACH to DCH)

This procedure is FFS. It is not yet clear if the Bearer should be effectively reconfigured of should be removed and set

up again

x

1. RA B RE C O N FIG URA T IO N

5. RA B RE C O N FIG URA T IO NRE SPO N SE

4. RA D IO A C C E SS BE A RE R RE CO N FIG URA T IO N C O M PLE T E

3. RA D IO A C C E SS BE A RE R RE C O N FIG URA T IO N


Servin gRN C

C N

RA N A P RA N A P

RRCRRC

RRCRRC

RA N A P RA N A P

2. A LC A P Iu BE A RE RRE C O N FIG URA T IO N

6. RA D IO A C C E SS BE A RE R RE C O N FIG U RA T IO N C O M PLE T E


7. RA B RE C O N FIG URA T IO NRE SPO N SE



2. RA D IO LIN K SE T UP(Iub)

UE N ode BSe rving R N S

Servin gRN C

C N

N BA PN BA P

N BA PN BA P

RRCRRC

RRCRRC

RA N A P RA N A P

RA N A P RA N A P


25.931 V1.1.1 1999-0633

10.9.4 DCH TO RACH/FACH RECONFIGURATIONThis example shows reconfiguration of a radio access bearer on a dedicated channel (DCH to RACH/FACH).

Note: this example shows the case where the SRNC decides to perform SRNS Relocation immediatly after the channelswitching.

This procedure is FFS.


4. RA D IO A C CE SS BE A RE R RE C O N FIG URA T IO NC O M PLE T E


8. RA D IO LIN K D E LE T IO NRE SPO N SE (Iur)

5 . RA D IO LIN K D E LE T IO N(Iur)

7 . RA D IO LIN K D E LE T IO NRE SPO N SE (Iub)

6 . RA D IO LIN K D E LE T IO N (Iub)



D riftRN C

Servin gRN C

C N

RA N A P RA N A P

RRCRRC

RRCRRC

RN SA PRN SA P

N BA PN BA P

N BA PN BA P

RN SA PRN SA P

C ell U pdate P rocedure + Stream lining

(FFS)

A LC A P Iur BE A RE R RE LE A SE9. A LC A P Iub BE A RE R RE LE A SE


25.931 V1.1.1 1999-0634

10.10 Physical Channel ReconfigurationThe following example show the reconfiguration from one channel type to another(DCH to DCH)

10.11 Channel Type SwitchingThe following examples show switching from one channel type to another.

10.11.1 RACH/PCH to RACH/FACHThis example shows channel switching from RACH/PCH to RACH/FACH (URA connected to CELL Connected).

Note: The case showed is for when SRNS decides to perform an SRNS relocation immediately after a channel typeswitching.

NOTE: The first and the second transition are included when the procedure is intitiated by UTRAN

2. PA G IN G


Servin gRN C

C N

RRCRRC

C ell U pdate P rocedure + S tream lining

C ase1

1 . PA G IN G N BA PN BA P

25.931 V1.1.1 1999-0635

10.11.2 RACH/FACH to RACH/PCHThe procedure for channel switching from RACH/FACH to RACH/PCH (Cell Connected to URA connected)) isdescribed in [Editor note: appropriate reference to the WG2 documentation is needed].

10.11.3 RACH/FACH to DCHThis example shows channel switching from RACH/FACH to DCH.

5. A C T IV E SE T U PD A T E C O M PL E T E

4. A C T IV E SE T UPD A T E


1. RA D IO LIN K SE T UP(Iub)

UE N ode BSe rving R N S

Servin gRN C

C N

N BA PN BA P

N BA PN BA P

RRCRRC

RRCRRC


25.931 V1.1.1 1999-0636

10.11.4 DCH to RACH/FACHThis example shows channel switching from DCH to RACH/FACH.

10.11.4.1 DCH to RACH/FACH (SRNS Relocation)

The case showed is for when SRNS decides to perform an SRNS relocation immediately after a channel type switching.

10.11.4.2 DCH to RACH/FACH (without SRNS Relocation)

10.12 Soft HandoverThis section presents some examples of soft handover procedures. The following cases are considered:

• Radio Link Addition (Branch Addition);

• Radio link Deletion (Branch Deletion);

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

Note that Soft Handover applies only to FDD mode.

2. PHY SIC A L C HA N N E L RE C O N FIG URA T IO N C O M PLE T E

1. PHY SIC A L C HA N N E L RE C O N FIG URA T IO N


3. RA D IO LIN K D E LE T IO N(Iur)

5. RA D IO LIN K D E LE T IO NRE SPO N SE (Iub)

4 . RA D IO LIN K D E LE T IO N (Iub)

UE N ode BD rift R NS

N ode BServing R NS

D riftRN C

Servin gRN C

CN

RRCRRC

RRCRRC

RN SA PRN SA P

N BA PN BA P

N BA PN BA P

RN SA PRN SA P

C ell U pdate P rocedure + Stream lining

(FFS)

A LCA P Iur BE A RE R RE LE A SE7. A LC A P Iub BE A RE R RE LE A SE

25.931 V1.1.1 1999-0637

10.12.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. Thisis the first radio link to be established via this RNS, thus macro-diversity combining/splitting with already existing radiolinks within DRNS is not possible.


D riftRN C

Servin gRN C

6. N odeB-SRN C D ata T ran sport Bearer Syn c.

RN SA P RN SA P

1. Radio Lin k A ddition

S tart T X

N BA P N BA P2. Radio Lin k Setup

RN SA P RN SA P

4. Radio Lin k A dditionRespon se

N BA P N BA P

3. Radio Lin k SetupRespose

Start RX

D ecision to setupn ew RL

RRCRRC8. D CC H : A ctive Set Update Com plete

RRCRRC7. D C C H : A ctive Set Update

[R adio L ink A ddition]

A LC A P Iur Bearer Setup5. A LC A P Iub Bearer Setup

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 radioresources by sending RNSAP message Radio Link Addition. If this is the first radio link via the DRNC for thisUE, a new Iur signalling connection is established. This Iur signalling connection will be used for all RNSAPsignalling related to this UE.Parameters: Cell id, Transport Format Set per DCH, Transport Format Combination Set, frequency, UL scramblingcode.

2. If requested resources are available, DRNC sends NBAP message Radio Link Setup to Node B.Parameters: Cell id, Transport Format Set per DCH, Transport Format Combination Set, frequency, UL scramblingcode, DL channelisation code.

3. Node B allocates requested resources. Successful outcome is reported in NBAP message Radio Link SetupResponse.Parameters: Signalling link termination, Transport layer addressing information (AAL2 address, AAL2 BindingIdentitie(s)) for Data Transport Bearer(s).

Then Node B starts the UL reception.

4. DRNC sends RNSAP message Radio Link Addition Response to SRNC.Parameters: DL channelisation code, Transport layer addressing information (AAL2 address, AAL2 BindingIdentity) 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 AAL2Binding Identity to bind the Iub Data Transport Bearer to DCH.This may be repeated for each Iur/Iub Data Transport Bearer to be setup.

25.931 V1.1.1 1999-0638

6. Node B and SRNC establish synchronism for the Data Transport Bearer(s), relative already existing radio link(s).Then Node B starts DL transmission.

7. SRNC sends RRC message Active Set Update (Radio Link Addition) to UE on DCCH.Parameters: Update type, Cell id, DL scrambling code, DL channelisation code, Power control information, Ncellinformation.

8. UE acknowledges with RRC message Active Set Update Complete.

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


D riftRN C

Servin gRN C

RRCRRC2. D CC H : A ctive Set Update Com plete

D ecision to deleteold RL

RN SA P RN SA P

3. Radio Lin k D eletion

N BA P N BA P

4. Radio Lin k D eletion

RN SA P RN SA P

6. Radio Lin k D eletionRespon se

N BA P N BA P

5. Radio Lin k D eletionRespon se

Stop RX an d T X

RRCRRC1. D C C H : A ctive Set Update

[R adio L ink D ele tion]

A LC A P Iur Bearer Release7. A LCA P Iub Bearer Release

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 ActiveSet Update (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 Active Set Update Complete.

3. SRNC requests DRNC to deallocate radio resources by sending RNSAP message Radio Link Deletion.Parameters: Cell id, Transport layer addressing information.

4. DRNC sends NBAP message Radio Link Deletionto Node B.Parameters: Cell id, Transport layer addressing information.

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

6. DRNC sends RNSAP message Radio Link Deletion Response to SRNC.

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

25.931 V1.1.1 1999-0639

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

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

This procedures is needed when the maximum number of branches allowed for the macrodiversity set has already beenreached.

6. N odeB-SRN C D ata T ran sport Bearer Syn c.

RN SA P RN SA P

1. Radio Lin k A ddition

Sta rt T X

RN SA P RN SA P

4. Radio Lin k A dditionRespon se

N BA P N BA P2. Radio Lin k Setup

N BA P N BA P3. Radio Lin k Setup Respon se

S tar t RX

D ecision to setupn ew RL an d

release old RL

N BA P 9 . Radio Lin k Release

N BA P N BA P10. Radio Lin k Release Proceed

Stop RX an d T X

11. A LC A P Iub D a ta T ran spor t Bearer Release

RRCRRC8. D C C H : A ctive Set Update C om plete

RRCRRC7. D C C H : A ctive Set Update C om m an d

[R adio L ink A ddition & D e letion]

N BA P



D riftRN C

Servin gRN C

A LC A P Iur Bearer Setup5. A LC A P Iub D a ta T ran spor t Bearer Setup

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

1. � 6. See description 1. � 6. in Section 9.12.1.

7. SRNC sends RRC message Active Set Update (Radio Link Addition & Deletion) to UE on DCCH.Parameters:Update type, Cell id, DL scrambling code, DL channelisation code, Power control information, Ncellinformation.

8. UE disactivates DL reception via old branch, activates DL reception via new branch and acknowledges with RRCmessage Active Set Update Complete.

9. � 11. See description 3. � 7. in Section 9.12.2

25.931 V1.1.1 1999-0640

10.13 Hard HandoverThis section presents some examples of hard handover procedures. These ls procedures are for both dedicated andcommon channells and may be applied in the following cases:

• intra-frequency Hard Handover (TDD mode);

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

10.13.1 Backward Hard HandoverThis sections shows some examples of hard handover in the case of network initiated backward handovers

25.931 V1.1.1 1999-0641

10.13.1.1 Intra Node B Hard Handover (DCH State)

9. R A D IO LIN K D E LET IO N (Iub)

12 . R A D IO LIN K D ELET IO N R E SP O N SE(Iub)

14 . R A D IO LIN K D ELE T IO NR ES PO N SE (Iur)

10 . R A D IO LIN K D ELE T IO N(Iur)

11 . R A D IO LIN K D ELET IO N (Iub)

13 . R A D IO LIN K D ELE T IO NR E SP O N S E(Iub)

3 . R A D IO LIN K AD D IT IO N (Iub)

1. R A D IO LIN K A D D IT IO N (Iub)

7. H A N D O V E R C O M M A N D

8. H A N D O V ER C O M P LET E

6. R A D IO LIN K A D D IT IO NR ES PO N SE (Iur)

5. R AD IO LIN K A D D IT IO NR E SP O N S E(Iub)

4 . R AD IO LIN K A D D IT IO NR ES PO N SE (Iub)

2. R A D IO LIN K A D D IT IO N(Iur)

U E N ode BD rift RN S

N ode BServing RN S

D riftR N C

ServingR N C

C N

N B A PN B A P

N B A PN B AP

R N SA PR N SA P

R R CR R C

R R CR R C

N B A PN B A P

N B A PN B A P

R N SA PR N S AP

N B A PN B A P

N B A PN B A P

R N SA PR N SA P

N B A PN B A P

N B A PN B A P

R N SA PR N SA P

25.931 V1.1.1 1999-0642

10.13.1.2 Hard Handover via Iur (DSCH/DCH State)

This section shows an example of Hard Handover via Iur.

Note: this procedure is for FFS.

4. H andover C om m andW hether this m essage is RN SA P or no it

is FFS

D CH :M easurem ents

U E C RN CSource

C RN CTarget

SR N C

T im e during whichd ata transm ission andreception is susp ended

M SC/SG SNTarget

R RC

4. H ando ver Com m and

O n m easurem ents results,RN C decid es to initiate aH ard H andover

2. Com m on Channels are established on Iur(FFS)

R RC5. D C H : H andover

C om plete

RRC7. C CT H Release R equest

RRC

RRC8. C CT H Release Com plete

(FFS if needed) RRC

6.-H ando ver Com p leteW hether th is m essage is RN SA P or no it is

FFS

Hard Handover via Iur

10.13.1.3 Hard Handover via Iur (DCH State)

This section shows an example of Hard Handover via Iur, when themobile is in DCH state

25.931 V1.1.1 1999-0643

RNSAPRNSAP

1. Radio LinkSetup Request

Note 1

UE Node BSource

Node BTarget

RNCSource

RNCtarget

SRNC

RRC RRC8. DCCH : Handover Complete

RNSAP

5. RL SetupResponse

Note 1

RRC7. DCCH : Handover Command

RRC[Hard Handover]

6. ALCAP Iur DataTransport Bearer Setup

Note 1

NBAP NBAP2. Radio Link Setup

NBAP NBAP3. Radio Link Setup Response

NBAP NBAP10. Radio Link Deletion

NBAP NBAP11. Radio Link Deletion Response


12. ALCAP Iub Data Transport Bearer Release

RNSAP RNSAP

RNSAP RNSAP

9. Radio Link DeletionNote 2

13. Radio LinkDeletion Response

Note 2

14. ALCAP Iur DataTransport Bearer Release

Note 2

RNSAP

Hard Handover via Iur (DCH on Iur)

1. SRNC sends Radio Link Setup Request message to the target RNC.Parameters: target RNC identifier, s-RNTI, Cell id, Transport Format Set, Transport Format Combination Set. Note1: This message is not necessary when the target RNC is the SRNC.

2. The target RNC allocates RNTI and radio resources for the RRC connection (if possible), and sends the NBAPmessage Radio Link Setup to the target Node-B. Parameters: Cell id, Transport Format Set, Transport FormatCombination Set, frequency, UL scrambling code (FDD only), Time Slots (TDD only), User Codes (TDD only),DL channelisation code (FDD only), Power control information.

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

4. Target RNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the AAL2Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of Iub Data Transportbearer is acknowledged by Node B.

25.931 V1.1.1 1999-0644

5. When the Target RNC has completed preparation phase, Radio Link Setup Response is sent to the SRNC. Note 1:This message is not necessary when the target RNC is the SRNC.

6. SRNC initiates set-up of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2 BindingIdentity to bind the Iur Data Transport Bearer to the DCH. The request for set-up of Iur Data Transport bearer isacknowledged by Target RNC. Note 1: This message is not necessary when the target RNC is the SRNC

7. SRNC sends a RRC message Handover Command to the UE.

8. When the RRC connection is established with the target RNC and necessary radio resources have been allocated theUE sends RRC message Handover Complete to the SRNC.

9. The SRNC sends a RNSAP message Radio Link Deletion to the source RNC. Note 2: This message is notnecessary when the source RNC is the SRNC.

10. The source RNC sends NBAP message Radio Link Deletion to the source Node B.Parameters: Cell id, Transport layer addressing information.

11. The source Node B de-allocates radio resources. Successful outcome is reported in NBAP message Radio LinkDeletion Response.

12. The source RNC initiates release of Iub Data Transport bearer using ALCAP protocol.

13. When the source RNC has completed the release the RNSAP message Radio Link Deletion Response is sent to theSRNC. Note 2: This message is not necessary when the source RNC is the SRNC.

14. SRNC initiates release of Iur Data Transport bearer using ALCAP protocol. This request contains the AAL2Binding Identity to bind the Iur Data Transport Bearer to the DCH. The request for release of Iur Data Transportbearer is acknowledged by the Source RNC. Note 2: This message is not necessary when the source RNC is theSRNC.

10.13.1.4 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 twoCN nodes simultaneously node and will be using one node B directly under the target RNC after the hard handover.

25.931 V1.1.1 1999-0645

2 . Reloca tion Requ iredRA N A P RA N A P

RA N A P RA N A P3. Relocation

Request

RA N A P RA N A P

6. RelocationRequest

A cknowledge

RA N A P RA N A P1. Reloca tion Required

UE N ode BTarget

RN CSource

RN C target M SC /SG SN SG SN /M SC

RA N A P RA N A P4. Reloca tion Request

RA N A P RA N A P7. Reloca tion Request A cknow ledge

RA N A P RA N A P

14. RelocationC om plete

RA N A P RA N A P15. Relocation C om plete

RA N A P RA N A P8. Relocation C om m and

RA N A P9. Reloca tion C om m an d

RA N A P

RRC RRC13. D CC H : Handover C om plete

RA N A P RA N A P

11. RelocationD etect

RA N A PRA N A P12. Reloca tion D etect

RRC10. D C CH : Handover C om m and

RRC[H ard H andover]

RA N A P16. Iu Release C om m an d

RA N A P

RA N A P17. Iu Release C om m an d

RA N A P

5. A L CA P Iu D ataT ran spor t Bearer Setup

18. A LC A P Iu D ata T ranspor t Bearer Release

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.

1./2. SRNC sends Relocation Required messages to both CN nodes.Parameters: target RNC identifier, Information field transparent to the CN node and to be transmitted to thetarget RNC.Upon reception of Relocation Required message CN element prepares itself for the switch and may alsosuspend data traffic between UE and itself for some bearers.

3./4. When preparation is completed CN node conveys a Relocation Request message to the target RNC.Parameters: bearer ID's requested to be rerouted towards the CN node, from which the Relocation Requestoriginated.CN indicates in the message whether it prefers point to multipoint type of connections within CN or hardswitch in CN. In this example the latter is assumed.

Target RNC allocates necessary resources within the UTRAN to support the radio links to be used aftercompletion of the Hard Handover procedure.

5./6./7 Target RNC and CN node establish the new Iu transport bearers for each Radio Access Bearer related to theCN node. When RNC has completed preparation phase, Relocation Request Acknowledge is sent to the CNelement.Parameters: transparent field to the CN which is to be transmitted to the Source RNS.

25.931 V1.1.1 1999-0646

.8./9. When CN is ready for the change of SRNC, CN node sends a Relocation Command to the RNC. Messagecontains the transparent field provided by Target RNC.Parameters: information provided in the Information field from the target RNC.

9. Source RNC sends a RRC message Handover Command (Hard Handover) to the UE.Parameters: Handover type.

11./12. When target RNC has detected the UE, Relocation Detect message is sent to the CN nodes.Target RNC switches also the connection towards the new Iu, when UE is detected. After the switch ULtraffic from node-B's is routed via the newly established MDC to the new MAC/RLC entities and finally tothe correct Iu transport bearer.DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to theMD-splitter and Nodes B.

13. When the RRC connection is established with the target RNC and necessary radio resources have beenallocated the UE sends RRC message Handover complete to the target RNC.

14./15 After a succesful switch and resource allocation at target RNC, RNC sends Relocation Complete messagesto the involved CN nodes.

At any phase, before the Relocation Complete message is sent, the old communication link between the CNand UE is all the time existing and working and the procedure execution can be stopped and originalconfiguration easily restored. If any such unexpectional thing occurs a Relocation Failure message may besent instead of any message numbered 3-10 and 13-14 described in this above.

16./17. The CN nodes initiates the release of the Iu connections to the source RNC by sending RANAP message IuRelease Command.

18. Upon reception of the release requests from the CN nodes the old SRNC executes all necessary procedures torelease all visible UTRAN resources that were related to the RRC connection in question.

10.13.2 Forward Hard HandoverThis sections 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 aRRC connection exists and the position of the UE is known on cell level in the UTRAN.

10.13.2.1 Cell Update with with SRNS relocation

This example shows Inter-RNS Cell Update with switching in the CN (with SRNS relocation).

UE Servin gRN C

RN SA P

4.C C C H : C ell U pdate C onfirm

[S-R N TI, SR N C -ID , new S-R N TI, new SR N C -ID , new C -R N TI]

T argetRN C

RN SA P2. U plink S ignalling Transfer

C N

3. Servin g RN C Relocation

A llocate C- RN T I

RRCRRC

D ecision to performSRN C relocation

A llocate S- RN T I,SRN C -ID

[C -R N TI, U L m essage]

Reception of ULCC C H m essage.

D ecodin g of RN C-IDfrom th e UL m essage

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 aCCCH message from a UE, controlling RNC allocates a C-RNTI for the UE.

25.931 V1.1.1 1999-0647

2. Controlling RNC forward the received uplink CCCH message towards the SRNC by RNSAP Cell/URA UpdateIndication message. C-RNC includes the allocated C-RNTI to the RNSAP message, which is used as a UEidentification within the C-RNC. Upon reception of the RNSAP message SRNC decides to perform a SRNSRelocation towards the target RNC.

3. Serving RNC relocation procedure is executed as defined in Chapter SRNS Relocation (UE connected to a singleCN node). After completing SRNS Relocation, target RNC allocates new S-RNTI for the UE.

4. Serving RNC responds to UE by RRC Cell Update Confirm, including old S-RNTI and SRNC ID as UEidentifiers. Message contains also the new S-RNTI, SRNC-ID and C-RNTI.

It is ffs. whether a Cell Update Complete is needed to confirm the successful reception of Cell Update Confirm. Thedecision is to be made by 3GPP RAN WG2.

10.13.2.2 Cell Update via Iur without SRNS relocation

This example shows an Inter RNS cell update in DRNS without SRNS relocation. In this example target RNS, sourceRNS and serving RNS are all located separately from each other. Other scenarios can be easily derived from this mostcomprehensive signalling procedure.

UE DRNCSource

DRNCTarget

SRNC MSC/SGSN

RNSAP RNSAP8. c-RNTI Release

3. Allocate C- RNTI

5. Decision: Not to perform

SRNC relocation

RNSAPRNSAP4. Uplink Signalling Transfer

[C-RNTI, UL message]

1. Reception of ULDCCH/CCCH message.

2. Decoding of RNC-IDfrom the UL message

RNSAPRNSAP6. Downlink Signalling Transfer

Release C- RNTI

7. Sending DLDCCH/CCCH

message

Cell Update via Iur without SRNS Relocation

1. UE sends a RRC message Cell Update to the UTRAN, after having made cell re-selection.

2. Upon reception of a CCCH/DCHT message from a UE, controlling RNC decodes the RNC ID and the S-RNTI.

3. The UE is not registered in the CRNC (RNC ID and SRNTI unknown), thus CRNC allocates C-RNTI for the UE.

4. Controlling RNC forward the received uplink CCCH/DCCH message towards the SRNC by RNSAP UPLINKSIGNALLING TRANSFER message. Messages includes also the cell-ID of the cell from which the message wasreceived and the allocated C-RNTI.

5. Upon reception of the RNSAP message SRNC decides not to perform a SRNS Relocation towards the targetRNC.

6. SRNC replies with the RNSAP DOWNLINK SIGNALLING TRANSFER message containing the DL RRCmessage to be sent to UE. Message includes also the C-RNTI and the Cell-ID indicated in the proceeding CTCHIndication message.

25.931 V1.1.1 1999-0648

7. The Cell Update Confirm is sent to the UE

8. SRNC send the C-RNTI Release to source RNC. Source RNC releases the C-RNTI.

Note: It is ffs. whether a Cell Update Complete is needed to confirm the successful reception of Cell Update Confirm.The decision is to be made by 3GPP RAN WG2.

10.14 URA UpdateThis section presents some examples of URA Update procedures, i.e. those procedures that update the UTRANregistration area of a UE when a RRC connection exists and the position of the UE is known on URA level in theUTRAN.

10.14.1 Inter-RNS URA Update with SRNS RelocationThis example shows Inter-RNS URA Update with switching in the CN.

UE Servin gRN C

RN SA P

4.C CC H: URA Update Con firm

[S-R N TI, SR N C -ID ,new S-R NTI, new SR NC -ID ]

T argetRN C

RN SA P2. U plin k S ign allin g T ran sfer

C N

3. Servin g RN C Relocation

A llocate C- RN T I

RRCRRC

D ecision to performSRN C reloca tion

A llocateS- RN T I,SRN C -ID ,

D elete C -RN T I

[C -R N TI, U L m essage]

Reception of ULC C C H m essage

D ecodin g of RN C-IDfrom th e UL m essage

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 aCCCH message from an unknown UE, controlling RNC allocates a new C-RNTI for the UE.

2. Controlling RNC forwards the received uplink CCCH message towards the SRNC by RNSAP by RNSAPUPLINK SIGNALLING TRANSFER message. Message includes also C-RNC includes the allocated C-RNTI,which is to be used as a UE identification within the C-RNC. Upon reception of the RNSAP message SRNCdecides to perform a SRNS Relocation towards the target RNC.

3. Serving RNC relocation procedure is executed as defined in Chapter 'SRNS Relocation (UE connected to asingle CN node)'. After having completed SRNS Relocation, target RNC allocates new S-RNTI for the UE. NewSRNC also deletes the allocated C-RNTI, since it is not needed for an UE in RACH/PCH state.

4. Serving RNC acknowledges the message by RRC URA Update Confirm, including old S-RNTI and SRNC ID asUE identifiers. Message contains also the new S-RNTI and RNC-ID.

It is ffs. whether a URA Update Complete is needed to confirm the successful reception of URA Update Confirm. Thedecision is to be made by 3GPP RAN WG2.

10.14.2 Inter-RNS URA Update via Iur without SRNS relocationThis example shows an Inter RNS URA update in DRNS without SRNS relocation. In this example target RNS, sourceRNS and serving RNS are all located separately from each other. Other scenarios can be easily derived from this mostcomprehensive signalling procedure.

25.931 V1.1.1 1999-0649

UE DRNCSource

DRNCTarget

SRNC MSC/SGSN

3. Allocate C- RNTI

5. Decision: Not to perform

SRNC relocation

RNSAPRNSAP4. Uplink Signalling Trasfer

[C-RNTI,Uu Signalling Message ]

1. Reception of UuSignalling Message

2. Decoding of RNC-IDfrom the UL message

RNSAPRNSAP

6. Downlink SignallingTransfer

7. Transmission ofUu Signalling Message

8. Release of C- RNTI

[C-RNTI,Uu Signalling Message ]

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

2. Upon reception of the message from a UE, controlling RNC decodes the RNC ID and the S-RNTI.

3. The UE is not registered in the CRNC (RNC ID and SRNTI unknown), thus CRNC allocates C-RNTI for the UE.

4. Controlling RNC forward the received Uu signalling message towards the SRNC by RNSAP UPLINKSIGNALLING TRANSFER message. Messages includes also the cell-ID from which the message was receivedand the allocated C-RNTI.

5. Upon reception of the RNSAP message SRNC decides not to perform a SRNS relocation towards the target RNC.

6. SRNC replies with the RNSAP DOWNLINK SIGNALLING TRANSFER message containing the DL Uusignalling message to be sent to UE. Message includes also the C-RNTI and the Cell-ID indicated in thepreceeding UPLINK SIGNALLING TRANSFER message.

7. The URA Update Confirm is sent to the UE

8. DRNC releases the allocated C-RNTI.

10.14.3 SRNS Relocation (UE connected to two CN nodes)This example shows SRNS Relocation, in situation in which the UE is connected to two CN nodes simultaneously. It isassumed that:

• all cells in the active set are in one DRNC;

• the CN performs hard switching of the user traffic.

25.931 V1.1.1 1999-0650

2. Relocation RequiredRA N A P RA N A P

RA N A P RA N A P

6. RelocationRequest A ck.

RA N A P RA N A P1. Relocation Requ ired

UE N ode B RN CSource

RN CTarget

M SC /SG SN SG SN /M SC

RA N A P RA N A P4. Relocation Request

RA N A P RA N A P3. Relocation Request

RA N A P RA N A P7. Relocation Request A ck .

RA N A P RA N A P9. Relocation C om m and

RA N A P RA N A P8. Relocation C om m an d

RA N A P RA N A P

12. RelocationC om plete

RA N A P RA N A P11. Relocation C om plete

RN SA P RN SA P

10. SRN C RelocationC om m it

RA N A P13. Iu Release C om m and

RA N A P

RA N A P14. Iu Release C om m and

RA N A P

5. A LC A P Iu D ataTranspor t Bearer Setup

15. A LC A P Iu D ata T ran sport Bearer Relelase

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 alsodecides into which RNC (Target RNC) the Serving RNC functionality is to be relocated.

1./2. The source SRNC sends Relocation Required messages to both CN nodes.

Parameters: target RNC identifier, Information field that the CN node(s) shall pass transparently to the targetRNC. This transparent field contains the UE identifier, number of CN nodes and other TBD data.Upon reception of Relocation Required message the CN element prepares itself for the switch and may alsosuspend user data traffic and/or signalling between UE and itself for some bearers.

3./4. When preparation is completed the CN node conveys a Relocation Request message to the target RNC.

Parameters: indication of which bearers should be routed towards this CN node, transparent information fieldsent 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 theresources (e.g. Iub links) that the UE is currently using.FFS: The target RNC allocates necessary Iur branches to be used after the SRNS Relocation switch will bemade.

5. The target RNC and CN node establish the new Iu transport bearers for each Radio Access Bearer related tothat CN node.

6./7. When the source RNC and the target RNC have completed its preparation phase, Relocation RequestAcknowledge message is sent to CN.

25.931 V1.1.1 1999-0651

8./9. When the CN node is ready for the SRNC move, the CN node indicates the completion of preparation phase atthe CN side for the SRNS Relocation by sending the Relocation Command message. To the source RNC andthe target RNC.

10. When the source RNC has received Relocation Command messages from all the CN nodes, the source RNCsends a Relocation Commit message to the target RNC. The target RNC executes both the DL and UL switchfor 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 thenew MAC/RLC entities and finally to the correct Iu transport bearer. UL data transmission to the old Iurtransport bearer is ceased.DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to theMacro Diversity Splitter and Nodes B. The DL data received from the old Iur is discarded.

11./12. Immediately after a succesfull switch at RNC, target RNC (=SRNC) sends Relocation Complete messages tothe involved CN nodes.

Upon reception of messages 9 and 10, the CN switches from the old Iu transport bearers to the new ones.

13./14. After a successful switch at the CN node, the CN node initiates the release of the Iu connection to the sourceRNC by sending the RANAP message Iu Release Command.

15 Upon reception of the release requests from the CN nodes the old SRNC executes all necessary procedures torelease all visible UTRAN resources that were related to the RRC connection in question.

At any phase, before the SRNS Relocation Complete message is sent, the old communication link between the CN andUE is all the time existing and working and the procedure execution can be stopped and original configuration easilyrestored. If any such abnormal thing occurs a SRNS Relocation Failure may be sent instead of any message numbered3-11 described.

10.15 HO between UTRAN and GSM/BSSThis section 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, while thecase of an UTRAN connected .a GSM CN trough an IWF (where RANAP is interworked with BSSMAP) is not shownbecause is equivalent from the point of view of the UTRAN.

The case of HO between UTRAN and GPRS and viceversa are also considered.

11.

10.15.1 UTRAN � GSM/BSSThis example shows how handover (Hard Handover) is performed from UTRAN to GSM/BSS between a UMTS CNand a 2G-MSC.

Note: Procedures between CN and MSC, and between MSC and BSC are out of the scope of WG3, and are onlyincluded for clarity.

25.931 V1.1.1 1999-0652

M AP/E M A P/E

2. PrepareHandover

BSSM AP BSSM A P

4. HandoverRequest Ack

RA NA P RAN AP

13. Iu ReleaseC om plete

BSSM AP BSSM A P3. Han dover

Request

M AP/E M A P/E

5. PrepareHandoverRespon se

RA NA P RAN AP

6. RelocationCom m an d

BSSM A P BSSM AP

8. Han doverD etect

BSSM AP BSSM A P

10. HandoverCom plete

M AP/E M A P/E

11. Send E n dSigna l

Request

M AP/E M AP/E

14. Send E n dSigna l Respon se

RA NA P RAN AP

1. Reloca tionRequired

UE Node B RN CServ ing

C N M SC BSC BT S

RRC7. D CCH : Handover Com m an d

RRC[Hard H andover]

RR9. Han dover Com plete

RR

RAN AP RA NA P12. Iu Release

Com m an d

UTRAN �� GSM/BSS handover

1. Upon detection of a trigger SRNC sends RANAP message Relocation Required to the CN.

2. The UMTS CN will forward this request to the GSM MSC (indicated in the received message) over the MAP/Einterface (MAP message Prepare Handover).

Note: 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 Prepare Handover.

6. CN responds to the initial request from SRNC by sending RANAP message Relocation Command to the SRNC.

7. Via existing RRC connection, SRNC sends RRC message Handover Command (Hard Handover) to the UE.

Parameters: Handover type.

Note: Procedures related to synchronisation etc. to GSM BSS are not shown.

Note: Step 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 SignalRequest to the CN.

25.931 V1.1.1 1999-0653

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

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

10.15.2 GSM/BSS � UTRANThis example shows how handover (Hard Handover) is performed from GSM/BSS to UMTS between a UMTS CN anda 2G-MSC.

Note: Procedures between CN and MSC, and between MSC and BSC are out of the scope of WG3, and are onlyincluded for clarity.

RA N A P RA N A P3. Relocation

Request

BSSM A P BSSM A P

1. HandoverRequired

RA N A P RA N A P

4. RelocationRequest A ck.

M A P/E M A P/E5 . Prepare Han dover

Response

M A P/E M A P/E

2. PrepareHandover

BSSM A P BSSM A P6. Handover

C om m and

M A P/E M A P/E11. Sen d En d Sign al

Request

BSSM A P BSSM A P12. ClearC om m and

BSSM A P BSSM A P

13. C learC om plete

RA N A P RA N A P

10. Relocation Com plete

UE N ode B RN CTarget

CN M SC BSC BT S

M A P/E M A P/E14. Sen d En d Sign al

Response

RRC 9. D C C H : Handover C om plete RRC

RR7. Handover C om m and

RR

RA N A P RA N A P

8. RelocationD etect

GSM/BSS �� UTRAN handover

1. The BSC sends Handover Required message to the GSM MSC.2. The MSC sends MAP/E message Prepare Handover to the UMTS CN.

3. The CN sends RANAP message Relocation Request to the Target RNC.

4. Response Relocation Request Acknowledge is returned to the CN by the target RNC via RANAP.

25.931 V1.1.1 1999-0654

5. MAP/E message Prepare Handover Response is sent by the UMTS CN to the MSC.

Note: Step 6&7 follow normal GSM procedures and are shown only for clarity.

8. When target RNC has detected the UE, RelocationDetect 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 theUE sends RRC message Handover complete to the target RNC.

10. Once complete the target RNC sends RANAP message Relocation Complete to the CN.

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 (thismessage is not sent until the end of the call).

Note: The possibility to perform handover from GSM/BSS=>UMTS going directly in macrodiversity state(i.e.establishing directly multiple macrodiversity paths) is FFS

10.15.3 GPRS � UTRANThis section shows UTRAN signalling procedures for GPRS to UTRAN handover.

U E Serv ingR N C

1. U E initiated signalling connection estab lishm ent

C N

2. D irect Transfer

3. R ad io A ccess B earer Estab lishm ent

1. The UE selects a UTRAN cell, reads system information, and initiates establishment of a NAS signallingconnection.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 ofsecurity functions).See section Direct Transfer.

3. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates establishment ofRAB(s).See section Radio Access Bearer Establishment.

25.931 V1.1.1 1999-0655

10.15.4 UTRAN � GPRS, UE InitiatedThis section shows UTRAN signalling procedures for UTRAN to GPRS handover initiated by UE cell reselection.

U E C N

1. C ell R eselectio ntriggered

ServingR N C

R AN AP R AN AP2. Iu R elease C o mm and

R AN AP R AN AP2. Iu R elease C o m plete

1. The UE selects a GPRS cell, reads system information, and initiates establishment of UE-GPRS connection.

2. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates release of Iuconnection. SRNC releases the RRC connection.

10.15.5 UTRAN � GPRS, Network InitiatedThis section shows UTRAN signalling procedures for UTRAN to GPRS handover triggered by Serving RNC.

U E C NServingR N C

R AN AP R AN AP2. Iu R elease C o mm and

R AN AP R AN AP3. Iu R elease C o m plete

R R C R R C1. H ando ver C o mm and

1. Based on UE measurements, SRNC triggers the handover to a GPRS cell by sending a Handover Command to theUE. UE initiates establishment of UE-GPRS connection.

2. After necessary CN-GPRS preparations (e.g. UE context information retrieval), CN initiates release of the RRCconnection.

3. SRNC releases all resources reserved for the UE.

10.16 Load IndicationThis section shows examples of load indication reporting.

10.17 CipheringThis example shows ciphering procedure.

25.931 V1.1.1 1999-0656

10.18 Transport CH Reconfiguration

10.18.1 Transport CH Reconfiguration (Dedicated CH to Dedicated CH)

13 . T RA N SPO RT C HA N N E L RE C O N FIG URA T IO N C O M PLE T E

12. T R A N SP O RT C HA N N E L R E C O N FIG UR A T IO N

10. R A D IO LIN K RE C O N FIG URA T IO N C O M M IT (Iu r)

11.RA D IO LIN K RE C O N FIG UR A T IO NC O M M IT (Iub)

9 . RA D IO LIN K R E C O N FIG UR A T IO N C O M M IT (Iub)

6 . RA D IO LIN K RE C O N FIG UR A T IO NR E A D Y (Iur)

2. R A D IO LIN K RE C O N FIG URA T IO NP RE PA RE (Iu r)

5 . RA D IO LIN K R E C O N F IG UR A T IO NR E A D Y (Iub)

3. RA D IO LIN K RE C O N FIG U RA T IO NPRE P A RE (Iub)

4. R A D IO LIN K RE C O N FIG URA T IO NR E A D Y (Iub)

1. RA D IO LIN K RE C O N FIG U RA T IO NPRE P A RE (Iub)


N ode BServ ing R N S

D riftR N C

S ervin gRN C

C N

N B A PN B A P

N B A PN B A P

R N SA PRN SA P

N BA PN B A P

N BA PN B A P

R N SA PRN SA P

N B A PN B A P

R N SA PRN SA P

N BA PN B A P

R RCR RC

R RCR RC

A LC A P Iu rBE A R E R SE T UP



A LC A P Iu rBE A RE R R E LE A SE

15 . A LC A P Iub B E A R E R RE LE A S E

14 . A LC A P Iub B E A R E R R E LE A SE

25.931 V1.1.1 1999-0657

10.18.2 Transport CH Reconfiguration (RACH/FACH to RACH/FACH)

Note : this procedure is FFS

2. T R A N SP O R T C H AN N E L R E C O N FIG U R A T IO N C O M PLE T E

1. T R A N SP O R T C H A N N EL R EC O N FIG U R A T IO N

U E N ode BServing RN S

ServingR N C

C N

R R CR R C

R R CR R C

25.931 V1.1.1 1999-0658

10.18.3 Transport CH Reconfiguration (RACH/FACH to Dedicated CH)

5 . T RA N SPO RT C H A N N E L RE C O N FIG URA T IO N C O M PLE T E

4. T RA N SPO RT C H A N N E L RE C O N FIG URA T IO N


1 . RA D IO LIN K SE T U P(Iub)


Servin gRN C

C N

N BA PN BA P

N BA PN BA P

RRCRRC

RRCRRC

3. A L C A P Iub BE A RE R SE T UP

25.931 V1.1.1 1999-0659

10.18.4 Transport CH Reconfiguration (Dedicated CH to RACH/FACH)

Note: this example shows the case of Transport CH Reconfiguration (Dedicated CH to RACH/FACH) combined with aSRNS relocation

2. T RA N SPO RT C HA N N E L RE C O N FIG URA T IO N C O M PLE T E

1. T RA N SPO RT CHA N N E L RE C O N FIG URA T IO N


3 . RA D IO LIN K D E LE T IO N(Iur)

5 . RA D IO LIN K D E LE T IO NRE SPO N SE (Iub)

4. RA D IO LIN K D E LE T IO N (Iub)



D riftRN C

Servin gRN C

C N

RRCRRC

RRCRRC

RN SA PRN SA P

N BA PN BA P

N BA PN BA P

RN SA PRN SA P

C ell U pdate P rocedure + S tream lining

(FFS)

A LC A P IurBE A RE R RE LE A SE

7. A LC A P Iub BE A RE R RE LE A SE

25.931 V1.1.1 1999-0660

10.19 NotificationNOTE: The whole procedure is FFS.

1. N O T IFIC A T IO N (FF S)

3. N O T IFIC AT IO N

2. N O T IFIC AT IO N (Iub) (FFS )


ServingR N C

C N

N B A PN B A P

R R CR R C

R A N A PR AN A P

25.931 V1.1.1 1999-0661

10.20 DL Code ReconfigurationNOTE: The whole procedure is FFS.

2. D L C O D E R EC O N FIG U R A T IO NR EQ U E ST (Iur)

1. D L C O D E R EC O N FIG U R AT IO NR EQ U ES T (Iub)


N ode BServing RN S

D riftR N C

ServingR N C

C N

R N SA PR N SA P

N B A PN B A P

25.931 V1.1.1 1999-0662

10.21 Direct Transfer

10.21.1 Uplink Direct Transfer

2. D IR EC T T R A N S FER

1. D IR EC T T R AN SFER


ServingR N C

C N

R R C R R C

R A N A PR AN AP

25.931 V1.1.1 1999-0663

10.21.2 Downlink Direct Transfer

2 . D IR EC T T R AN SFER

1. D IR EC T T R A N S FER


ServingR N C

C N

R R C

R AN AP R A N A P

R R C

25.931 V1.1.1 1999-0664

10.22 Downlink Power Control

3 . P O W E R C O N T R O L(Iub)

2. P O W ER C O N T R O L(Iur)

1 . PO W ER C O N T R O L(Iub)


N ode BServing RN S

D riftR N C

ServingR N C

C N

N B A PN B A P

R N SA PR N SA P

N B A PN B A P

25.931 V1.1.1 1999-0665

Document history

Date Version Comment

23 June 1999 1.1.1 Noted by TSG-RAN

2 June 1999 1.1.0 Same as version 1.0.2, revisions accepted

30 May 1999 1.0.2 This version presents some editorial updated and some proposals tocope with the decision taken at the last meeting (kawasaki, April 99).

Major changes are derscribed in the following list:

• Updated figure for the protocol stack section 6.1

• Updated message list for section 6.2

• Modified figure and text in sections in order to allign it to theRANAP unified HO and SRNS relocation procedures agreeded atthe Kawasaki meeting (april 99)9.13.1.3 Hard HO with switching in the CN9.14.3 SRNS Relocation9.15.1 UTRAN => GSM/BSS HO9.15.2 GSM/BSS => UTRAN HO

25.931 V1.1.1 1999-0666

24 May 1999 1.0.1 This version includes the modification agreed at the TSG-RAN WG3#3 in Kawasaki (Apr 99).

The following three changes are not introduced, they will be presntedas editor proposals:

• A new section for Q.AAL example into a new section 6.4.

• A new figure in the protocol stack section 6.1

• The name of the messages for HO should be modified in order tocope with the unified procedures decided at the last eeting

Major introduced changes are listed below (number referred to oldnumbering)

• Q.aal2 flows were removed and the ALCAP boxes were put again inscenario 9.4.1

• Section 6.6 and 6.7 were removed due to the fact that these sectionsare only related to WG2 issues.

• ommon channel and CCH were replaced with common transportchannel and FACH/RACH

• The term SRNC Relocation was replaced SRNS Relocation

• Section 9.3.2 and 9.11.2 were replaced by a reference to the properWG2 documents, due to the fact that these sections are only relatedto WG2 issues (Correct reference to be filled)

• The section 9.13 was restructured and renamed (bawckward HO)and merged with 9.14 (cell update is forward HO).

• Section 9.14.2 was replaced with the content od Tdoc 355 fromNokia, updated accordly with the modification decided at themeeting

• Section 9.17 was restructure and new section for HO betweenUMTS and GPRS were introduced

• Section 9.25 was removed (inband mechnism, example not needed)

• A temporary annex was added to summarize the status of thereccomandation.

April 99 1.0.0 Agreeded at TSG RAN April 99 and promoted to version 1.0.0 (thesame as 0.1.0

April 16th 1999 0.1.0 Same as version 0.0.5, revision marks accepted

This version was sent to TSG RAN April 1999 meeting for approval

25.931 V1.1.1 1999-0667

April 16th 1999 0.0.5 This version contains mainly editorial enhancements. Major changesare listed below

• Section 6.1 SRNC Relocation Commit message was added

• Section 9.17.2 Release Complete message was added

• Section 9.2.1 Link Establishment and.Link EstablishmentAcknowledge messages were added

April 6tth 1999 0.0.4 This version contains mainly editorial enhancements. Major changesare listed below:

• section 7.1 and 7.2 were promoted to section 8 and 9 in order tolimit the deep in the subsection numbering; subsection werepromoted accordingly

• Figure numberig was incomplete and also produces unclearrevision marks due to a bug of word; Only the numbering of thefirst figures was left

• Styles were aligned to make the document consistant

• Hard Handover Proceeding 2 message was removed foralignement with RNSAP procedures (section 9.17.4)

April 6tth 1999 0.0.3 This version includes also the modification agreed at the TSG-RANWG3 march 1999 meeting. Major changes summary follows:

• section 7.2.13.2.1 (Inter-RNS hard HO with switching in the CN-single CN) was removed

• section 7.2.14.2 (Inter-RNS cell Update via Iur) was added

• section 7.2.15.2.1 (Inter-RNS URA Update via Iur) was added

• section 7.2.13.2 (Inter-RNS Hard HO via Iur) was re-integratedand filled with new contributions

March 1st 1999 0.0.2 The correct first pages common for 3GPP were introduced (first page,copyright, etc)

Revision marks are referred to the modification introduced to thedocument AFTER the TSG-RAN WG3 first meeting – Bon February99, based on the minor comments received in line with the decision ofthe previous meeting, (i.e. comments to the first draft merged versionare identified)

In this version the revision mark referred to version 0.0.0 wereaccepted

25.931 V1.1.1 1999-0668

February 15th 1999 0.0.1 This version includes also the modification agreed at the TSG-RANWG3 first meeting based on new contributions

Notes

• The general information dealing with references and copyrights arenot updated to the 3GPP ones (To be introduced when available)

• The graphical look of the parts included from the TTC/ARIBdocument still to be aligned by the editor to the rest of the document(the content is supposed to be aligned)

February 4th 1999 0.0.0 First draft version based on merge of the corresponding ETSI andTTC/ARIB document as agreed at the TSG-RAN WG3 first meeting –Bon February 99. (Revision marks are referred to the ETSI one).

This version includes also the modification agreed at the TSG-RAN WG3first meeting based on new contributions (except document 54 and 55,from which is expected an electronic version with the agreedmodifications from the authors)

Notes

• The general information dealing with references and copyrights arenot updated to the 3GPP ones (To be introduced when available)

• Alignment of names of messages respect to the Iur and IubETSI/ARIB merged interfaces is not complete. (To beintroduced/checked later when the correspondent documents will beavailable in order to limit misalignment)

• The graphical look of the parts included from the TTC/ARIBdocument still to be aligned by the editor to the rest of the document(the content is supposed to be aligned)

Reporter for I3.01 is:

Enrico ScarroneCSELTTel. : +39 011 228 7084Fax : +39 011 228 5520Email : [email protected]

This document is written in Microsoft Word version 97.

25.931 V1.1.1 1999-0669

11 ANNEX: status of the document1. Intellectual Property Rights TO BE FILLED (BY STAFF?)

2. Foreword TO BE FILLED (BY STAFF?)

3. Scope TO BE UPDATED? (PRESENTLY IT IS A VERY SHORTDESCRIPTION)

4. References TO BE UPDATED

5. Definitions, abbreviations and notation TO BE UPDATED

5.3 Notation for the signalling procedures COMPLETED

6. UTRAN AND UE PROTOCOL ARC… TO BE UPDATED

7. UTRAN Signaling Procedures TO BE UPDATED (iT IS ONLY A FOREWORD FOR THE NEXTTWO CHAPTER)

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

8.1 System Information Broadcasting STABLE,MISSING TEXT (CONTRIBUTION INVITED)

8.2 Cell Broadcast NOT STABLE (CONTRIBUTION INVITED)

9. Procedures related to a specific UE

9.1 Paging

9.1.1 Paging for a UE in RRC Idle ModeSTABLE

9.1.2 Paging for a UE in RRC Conn… STABLE

9.2 NAS Signalling Connection Establishment

9.2.1 UE Initiated Signalling Connection Est.. STABLE

9.2.2 CN Initiated Signalling Connection Est.. NOT STABLE,MISSING FLOW AND TEXT(CONTRIBUTION INVITED)

9.3 RRC Connection Establishment

9.3.1 DCH Establishment STABLE

9.3.2 RACH/FACH Establishment STABLE (MISSING REFERENCE)

9.4 RRC Connection Release

9.4.1 DCH Release STABLE,MISSING TEXT (CONTRIBUTION INVITED)

9.4.2 Common Transport Channel Release STABLE,MISSING TEXT (CONTRIBUTION INVITED)

9.5 RRC Connection Re-establishment

9.5.1 DCH Re-establishment NOT STABLE (CONTRIBUTION INVITED)

9.5.2 RACH/FACH Re-establishment NOT STABLE (CONTRIBUTION INVITED)

9.6 Radio Access Bearer Establishment

9.6.1 DCH - DCH Establishment – Sync.. STABLE

9.6.2 DCH - DCH Establishment – Unsyn.. STABLE

9.6.3 RACH/FACH - DCH Establishment STABLE,MISSING TEXT (CONTRIBUTION INVITED)

25.931 V1.1.1 1999-0670

9.6.4 RACH/FACH - RACH/FACH Est.. STABLE,MISSING TEXT (CONTRIBUTION INVITED)

9.7 Radio Access Bearer Release

9.7.1 DCH - DCH Release - Synchronized SABLE

9.7.2 DCH - DCH Release - Unsynchronized STABLE

9.7.3 DCH - RACH/FACH Release NOT STABLE (CONTRIBUTION INVITED)

9.7.4 RACH/FACH - RACH/FACH ReleaseSTABLE,MISSING TEXT (CONTRIBUTION INVITED)

9.8 Radio Access Bearer Re-establishment NOT STABLE (CONTRIBUTION INVITED)

9.9 Radio Access Bearer Modification NOT STABLE (CONTRIBUTION INVITED)

9.10 Physical Channel Reconfiguration NOT STABLE (CONTRIBUTION INVITED)

9.11 Channel Type Switching

9.11.1 RACH/PCH to RACH/FACH STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.11.2 RACH/FACH to RACH/PCH STABLE (MISSING REFERENCE)

9.11.3 RACH/FACH to DCH STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.11.4 DCH to RACH/FACH NOT STABLE(CONTRIBUTION INVITED)

9.12 Soft Handover STABLE

9.13 Hard Handover

9.13.1 Backward Handover

9.13.1.1 Intra Node B Hard Handover STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.13.1.2 Hard Handover via .. NOT STABLE(CONTRIBUTION INVITED)

9.13.1.3 Hard Handover with switc.. NOT STABLE(CONTRIBUTION INVITED)

9.13.2 Forward Handover NOT STABLE(CONTRIBUTION INVITED)

9.15 HO between UTRAN and GSM/BSS

9.15.1 UTRAN Þ GSM/BSS STABLE

9.15.2 GSM/BSS Þ UTRAN STABLE

9.15.3 UTRAN Þ GPRS NOT STABLE(CONTRIBUTION INVITED)

9.15.4 UTRAN Þ GSM/BSS NOT STABLE(CONTRIBUTION INVITED)

9.16 Load Indication NOT STABLE(CONTRIBUTION INVITED)

9.17 Ciphering NOT STABLE(CONTRIBUTION INVITED)

9.18 Transport CH Reconfiguration

9.18.1 Transport CH Reconfiguration.. STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.18.2 Transport CH Reconfiguration.. NOT STABLE (CONTRIBUTION INVITED)

9.18.3 Transport CH Reconfiguration.. STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.18.4 Transport CH Reconfiguratio.. NOT STABLE (CONTRIBUTION INVITED)

9.19 Notification NOT STABLE (CONTRIBUTION INVITED)

25.931 V1.1.1 1999-0671

9.20 DL Code Reconfiguration NOT STABLE (CONTRIBUTION INVITED)

9.21 Direct Transfer STABLE, MISSING TEXT (CONTRIBUTION INVITED)

9.22 Downlink Power Control STABLE, MISSING TEXT (CONTRIBUTION INVITED)

3rd technical specification group (tsg) ran; utran · pdf file · 1999-09-07rab...

Documents