ZTE Training Material

UMTS Interface Protocol

i

Contents

1 UTRAN System Architecture .................................................................................................................... 1

1.1 UTRAN Architecture ........................................................................................................................ 1

1.2 Explanation Related to RNS ............................................................................................................. 1

1.3 UTRAN Common Protocol model .................................................................................................... 2

2 UMTS Interface Hierarchy ....................................................................................................................... 7

2.1 Control Plane and User Plane ........................................................................................................... 7

2.2 Access Layer and Non-access Layer ................................................................................................. 7

3 Interface and Protocol ............................................................................................................................... 9

3.1 Protocol Overview ............................................................................................................................ 9

3.1.1 RRC Connection Setup .......................................................................................................... 9

3.1.2 Network Registration Process .............................................................................................. 10

3.1.3 Connection Release Process ................................................................................................. 12

3.2 Protocol Related to Interface Uu ..................................................................................................... 14

3.2.1 Uu Interface protocol architecture ........................................................................................ 14

3.2.2 Status of RRC Protocol ........................................................................................................ 21

3.2.3 Some Explanations ............................................................................................................... 22

3.3 Protocol related to Interface Iu ........................................................................................................ 23

3.3.1 IU interface architecture ....................................................................................................... 23

3.3.2 Protocol Structure of Iu Interface ......................................................................................... 24

3.3.3 Some Explanations ............................................................................................................... 28

3.3.4 RANAP Process ................................................................................................................... 30

3.4 Protocol related to Interface Iur ...................................................................................................... 31

3.4.1 Function and Structure of Interface Iur ................................................................................ 32

ii

3.4.2 DCH Frame Protocol of Interface Iur ................................................................................... 32

3.4.3 RNSAP Process .................................................................................................................... 33

3.5 Protocol Related to Interface Iub ..................................................................................................... 35

3.5.1 Node B Logic Model ............................................................................................................ 36

3.5.2 NBAP Process ....................................................................................................................... 36

1 UTRAN System Architecture

1.1 UTRAN Architecture

Figure 1 shows the overall architecture of UMTS UTRAN (UMTS Terrestrial Radio

Access Network) system of 3GPP R4.

RNS

RNC

RNS

RNC

Core Network

Node B Node B Node B Node B

Iu Iu

Iur

Iub Iub Iub Iub

UTRAN

Figure 1 Overall UTRAN Architecture

The interface between CN and UTRAN is Interface Iu.

Inside UTRAN, the interface between RNC and Node B is Interface Iub.

Inside UTRAN, the interface between RNCs is Interface Iur.

In addition, the interface between UTRAN and UE is Interface Uu.

1.2 Explanation Related to RNS

RNS (Radio Network Subsystem): The general name for one RNC and all Nodes B it

manages.

SRNC (Serving RNC): The RNS connecting with CN is called SRNS and the RNC of

RNS is called SRNC.

1

UMTS Signaling Flow

DRNC (Drift RNC): In the case of soft handover of UMTS, UE can use several

RNSs. Figure 2 shows the relation of SRNS and DRNS.

S R N S

C o re N etw o rk

Iu

D R N S Iu r

U E

C ells

Figure 2 SRNS and DRNS

Several links can exist inside one UE at the same time. The user data to access DRNS

is sent to SRNS from DRNS via Interface Iur. DRNC won’t process the data but

transmit it between Interface Iub and Interface Iur transparently. One UE can access

one or several DRNSs.

CRNC (Control RNC): When UE access one RNS, the RNC of the RNS is called

CRNC. Therefore, in Figure 2, both SRNC and DRNC are CRNC. CRNC manages the

resources of the whole cell. SRNC schedules data on user DCH and CRNC schedules

data on CCH.

For Source RNC (S-RNC) and Target RNC (T-RNC), refer to Chapter of Interface Iu.

1.3 UTRAN Common Protocol model

Figure 3 shows the general protocol model for UTRAN Interfaces, and described in

detail in the following subclauses. The structure is based on the principle that the layers

and planes are logically independent of each other. Therefore, as and when required,

the standardisation body can easily alter protocol stacks and planes to fit future

requirements.

2

Chapter Error! Use the Home tab to apply 标题 1 to the text that you want to appear here. Error! Use the Home tab to apply 标题 1 to the text that you want to appear here.

ApplicationProtocol

DataStream(s)

ALCAP(s)

TransportNetworkLayer

Physical Layer

SignallingBearer(s)

TransportUser

NetworkPlane

Control Plane User Plane

TransportUser

NetworkPlane

Transport NetworkControl Plane

RadioNetworkLayer

SignallingBearer(s)

DataBearer(s)

Figure 3 UTRAN Common Protocol Model

Horizontal, The Protocol Structure consists of two main layers, Radio Network Layer,

and Transport Network Layer. All UTRAN related issues are visible only in the Radio

Network Layer, and the Transport Network Layer represents standard transport

technology that is selected to be used for UTRAN, but without any UTRAN specific

requirements.

Vertical, UTRAn falls into the following 4 planes: control plane , user plane , TNL

control plane , TNL user plane.

Control plane：

The Control Plane Includes the Application Protocol, i.e. RANAP, RNSAP or NBAP,

and the Signalling Bearer for transporting the Application Protocol messages.

Among other things, the Application Protocol is used for setting up bearers for (i.e.

Radio Access Bearer or Radio Link) in the Radio Network Layer. In the three plane

structure the bearer parameters in the Application Protocol are not directly tied to the

User Plane technology, but are rather general bearer parameters.

The Signalling Bearer for the Application Protocol may or may not be of the same type

as the Signalling Protocol for the ALCAP. The Signalling Bearer is always set up by

O&M actions.

3

UMTS Signaling Flow

4

User plane：

The User Plane Includes the Data Stream(s) and the Data Bearer(s) for the Data

Stream(s). The Data Stream(s) is/are characterised by one or more frame protocols

specified for that interface.

TNL control plane：

The Transport Network Control Plane does not include any Radio Network Layer

information, and is completely in the Transport Layer. It includes the ALCAP

protocol(s) that is/are needed to set up the transport bearers (Data Bearer) for the User

Plane. It also includes the appropriate Signalling Bearer(s) needed for the ALCAP

protocol(s).

The Transport Network Control Plane is a plane that acts between the Control Plane

and the User Plane. The introduction of Transport Network Control Plane makes it

possible for the Application Protocol in the Radio Network Control Plane to be

completely independent of the technology selected for Data Bearer in the User Plane.

When Transport Network Control Plane is used, the transport bearers for the Data

Bearer in the User Plane are set up in the following fashion. First there is a signalling

transaction by the Application Protocol in the Control Plane, which triggers the set up

of the Data Bearer by the ALCAP protocol that is specific for the User Plane

technology.

The independence of Control Plane and User Plane assumes that ALCAP signalling

transaction takes place. It should be noted that ALCAP might not be used for all types

Data Bearers. If there is no ALCAP signalling transaction, the Transport Network

Control Plane is not needed at all. This is the case when pre-configured Data Bearers

are used.

It should also be noted that the ALCAP protocol(s) in the Transport Network Control

Plane is/are not used for setting up the Signalling Bearer for the Application Protocol

or for the ALCAP during real time operation.

The Signalling Bearer for the ALCAP may or may not be of the same type as the

Signalling Bearer for the Application Protocol. The Signalling Bearer for ALCAP is

always set up by O&M actions.

TNL user plane


5

The Data Bearer(s) in the User Plane, and the Signalling Bearer(s) for Application

Protocol, belong also to Transport Network User Plane. As described in the previous

subclause, the Data Bearers in Transport Network User Plane are directly controlled by

Transport Network Control Plane during real time operation, but the control actions

required for setting up the Signalling Bearer(s) for Application Protocol are considered

O&M actions.

7

2 UMTS Interface Hierarchy

2.1 Control Plane and User Plane

Purpose of the control plane:

Control the radio access bearer and the connection between UE and the network;

Transmit messages of non-access layer transparently.

Purpose of user plane:

Transmit the user data via the access network.

In UTRAN, each interface of RNL has user plane and control plane.

The control plane protocols of each interface on RNL include:

Interface Iu: RANAP

Interface Iur: RANSAP

Interface Iub: NBAP

Interface :Uu: RRC protocol

The user plane data and control plane data of all RNL belong to TNL user plane. TNL

control plane protocol is ALCAP, belonging to SAAL (Signalling AAL) of ATM.

2.2 Access Layer and Non-access Layer

The concepts of access layer and non-access layer are related to the communication of

UE and CN. The access layer bears the upper layer services via the SAP (Service

Access Point), as shown in Figure 4.

UMTS Signaling Flow

UTRANUE CN Access Stratum

Non-Access Stratum

Radio (Uu)

Iu

Radio protocols (1)

Radio protocols (1)

Iu protocols (2)

Iu protocols (2)

Figure 4 Access Layer and Non-access Layer

Example for non-access layer:

In AMR voice telephone (the calling party), there are several UE-CN signaling, which

are the control plane signaling of non-access layer. These signaling are encapsulated in

RRC protocol first and then transmitted to RNC transparently. RNC decodes these

signaling out of RRC messages, encapsulates into RANAP, and then transmits to CN

transparently via RANAP.

UE RNC CM Service Request

RNC UE Authentication Request

UE RNC Authentication Response

RNC UE CM Service Accept

UE RNC SETUP

RNC UE Call Processing

RNC UE Alerting

RNC UE Connect

UE RNC Connect Acknowledge

8

3 Interface and Protocol

3.1 Protocol Overview

Besides the process that UE searches for the net, UE registration fall into 3 phases:

RRC connection setup

Network registration

Connection release

3.1.1 RRC Connection Setup

Figure 5 shows the flow of RRC connection setup.

5. Downlink Synchronisation

UE Node BServing RNS

ServingRNC

DCH-FPDCH-FP

Allocate RNTISelect L1 and L2

parameters

RRCRRC1. CCCH : RRC Connection Request

NBAPNBAP3. Radio Link Setup Response

NBAPNBAP2. Radio Link Setup Request

RRCRRC7. CCCH : RRC Connection Setup

Start RX

Start TX

4. ALCAP Iub Data Transport Bearer Setup

RRCRRC8. DCCH : RRC Connection Setup Complete

DCH-FPDCH-FP6. Uplink Synchronisation

Figure 5 RRC Connection Setup

Detailed descriptions:

At the beginning, UE does not have dedicated channel resources, so it sends the

message of RRC connection setup on CCCH (RACH).

9

UMTS Signaling Flow

10

RNC allocates RNTI and available resources to UE, decides to allocate DCH to UE,

and inform Node B to allocate DCH to UE with NBAP message of “Radio Link Setup

Request”.

Node B allocates resources to UE, starts to receive, and returns “Radio Link Setup

Response” to RNC.

At this time, there are no resources of the transmission network on Interface Iub, so

ALCAP of SRNC sends the message of ERQ (Establish Request). This message

contains AAL2 binding ID. This ID can help Node B to bind the data transmission

bearer on Interface Iub and DCH, and sends the message of ECF (Establish Confirm)

back to RNC.

Node B and SRNC perform the frame synchronization via “Downlink

Synchronization” and “Uplink. Synchronization” in DCH frame protocol, and then to

perform the DL transmission.

Although DCH resources on Interface Iub are ready, UE does not know it. Therefore,

SRNC sends the message of “RRC Connection Setup” to UE on CCCH (FACH), and

informs UE of related parameters.

According to related parameters in “RRC Connection Setup”, UE configures the

physical layer. Node B sets up DCH successfully and sends the message of “RRC

Connection Setup Complete” back to SRNC on DCH.

3.1.2 Network Registration Process

Figure 6 shows the flow of UE registration for CS domain.


Figure 6 UE Location Update


11

UMTS Signaling Flow

12

After RRC connection sets up, UE establishes DCH. UE needs to change information

with CN (this is signaling interaction of non-access layer and readers of non-access

layer signaling can refer to [3]), that is, to initiate the Location Update. This message is

encapsulated in the RRC message of Initial Direct Transfer, which is sent to RNC by

UE.

RRC of RNC receives the message of Initial Direct Transfer, decodes the high-layer

messages from it, and sends to RANAP entity. RANAP entity will encapsulate the

message of “Location Update” into Initial UE Message and sends it to CN through

SCCP entity. At this time, there is no signaling connection between RNC and CN, so

the message of “Initial UE Message” of RANAP is encapsulated into SCCP connection

setup massage (CR) and sent to CN.

SCCP entity of CN receives the SCCP connection setup request. It returns SCCP

connection setup message (CC) to RNC and sends the RANAP massage contained in

CR messages to RANAP entity. RANAP entity decodes the message of “Location

Update” of NAS layer and sends it to the related modules on NAS layer for processing.

After receiving the message of “Location Update” from UE, CN initiates the

authentication. The signalling during the authentication process is transmitted

transparently. RNC and Node B only transfer between UE and CN, but do not process

messages. Messages of “Authentication Request” and “Authentication Response” are

NAS messages, too. They are encapsulated into the message of “Direct Transfer” of

RANAP and RRC.

After the authentication check on UE is passed, CN initiates the security mode process.

It is to encrypt and protect the data and signaling of the air interface. Messages of

security mode are not transmitted transparently and it needs RNC processing.

After the authentication check is passed and the security mode is initiated, CN sends

the message of “Location Update Accept” to UE, informing that UE registration

succeeds. This message is transmitted transparently.

3.1.3 Connection Release Process

Figure 7 shows the connection release process.


Figure 7 RRC Connection Release


After Location Update completes, CN initiates Iu release process.

SRNC sends the message of RRC connection release to RRC.

UE sends the message of RRC connection release back to RNC.

RNC informs Node B to delete RL and after deleting RL, Node B replies to RNC.

RNC informs CN that returns Iu release completes via RANAP.

CN initiates to release SCCP link and RNC returns the message of SCCP release

confirmation.

RNC initiates to release the transmission resources on Interface Iub.

13

UMTS Signaling Flow

3.2 Protocol Related to Interface Uu

3.2.1 Uu Interface protocol architecture

Figure 8 shows the architecture of Uu Interface protocol.

L3

cont

rol

cont

rol

cont

rol

cont

rol

LogicalChannels

TransportChannels

C-plane signalling U-plane information

PHY

L2/MAC

L1

RLC

DCNtGC

L2/RLC

MAC

RLCRLC

RLCRLC

RLCRLC

RLC

Duplication avoidance

UuS boundary

BMC L2/BMC

control

PDCPPDCP L2/PDCP

DCNtGC

RadioBearers

RRC

Figure 8 Structure of RRC Protocol

The Uu interface is layered into three protocol layers:

the physical layer (L1);

the data link layer (L2);

network layer (L3).

Layer 2 is split into following sublayers: Medium Access Control (MAC), Radio Link

Control (RLC), Packet Data Convergence Protocol (PDCP) and Broadcast/Multicast

Control (BMC). Layer 3 and RLC are divided into Control (C-) and User (U-) planes.

PDCP and BMC exist in the U-plane only.

In the C-plane, Layer 3 is partitioned into sublayers where the lowest sublayer, denoted

14


15

as Radio Resource Control (RRC), interfaces with layer 2 and terminates in the

UTRAN. The next sublayer provides 'Duplication avoidance' functionality. It

terminates in the CN but is part of the Access Stratum; it provides the Access Stratum

Services to higher layers. The higher layer signalling such as Mobility Management

(MM) and Call Control (CC) is assumed to belong to the non-access stratum..

The functions of RLC:

The RLC sublayer provides ARQ functionality closely coupled with the radio

transmission technique used. There is no difference between RLC instances in C and U

planes.The UTRAN can be requested by the CN to prevent all loss of data (i.e.

independently of the handovers on the radio interface), as long as the Iu connection

point is not modified. This is a basic requirement to be fulfilled by the UTRAN

retransmission functionality as provided by the RLC sublayer.However, in case of the

Iu connection point is changed (e.g. SRNS relocation, streamlining), the prevention of

the loss of data may not be guaranteed autonomously by the UTRAN but relies on

'Duplication avoidance' functions in the CN.There are primarily two kinds of signalling

messages transported over the radio interface - RRC generated signalling messages and

NAS messages generated in the higher layers. On establishment of the signalling

connection between the peer RRC entities three or four UM/AM signalling radio

bearers may be set up. Two of these bearers are set up for transport of RRC generated

signalling messages - one for transferring messages through an unacknowledged mode

RLC entity and the other for transferring messages through an acknowledged mode

RLC entity.

The functions of MAC include:

Mapping between logical channels and transport channels. The MAC is

responsible for mapping of logical channel(s) onto the appropriate transport

channel(s).

Selection of appropriate Transport Format for each Transport Channel

depending on instantaneous source rate. Given the Transport Format

Combination Set assigned by RRC, MAC selects the appropriate transport format

within an assigned transport format set for each active transport channel

depending on source rate. The control of transport formats ensures efficient use of

transport channels.

Priority handling between data flows of one UE. When selecting between the

UMTS Signaling Flow

16

Transport Format Combinations in the given Transport Format Combination Set,

priorities of the data flows to be mapped onto the corresponding Transport

Channels can be taken into account. Priorities are e.g. given by attributes of Radio

Bearer services and RLC buffer status. The priority handling is achieved by

selecting a Transport Format Combination for which high priority data is mapped

onto L1 with a "high bit rate" Transport Format, at the same time letting lower

priority data be mapped with a "low bit rate" (could be zero bit rate) Transport

Format. Transport format selection may also take into account transmit power

indication from Layer 1.

Priority handling between UEs by means of dynamic scheduling. In order to

utilise the spectrum resources efficiently for bursty transfer, a dynamic scheduling

function may be applied. MAC realises priority handling on common and shared

transport channels. Note that for dedicated transport channels, the equivalent of

the dynamic scheduling function is implicitly included as part of the

reconfiguration function of the RRC sublayer.

Identification of UEs on common transport channels. When a particular UE is

addressed on a common downlink channel, or when a UE is using the RACH,

there is a need for inband identification of the UE. Since the MAC layer handles

the access to, and multiplexing onto, the transport channels, the identification

functionality is naturally also placed in MAC.

Multiplexing/demultiplexing of upper layer PDUs into/from transport blocks

delivered to/from the physical layer on common transport channels. MAC

should support service multiplexing for common transport channels, since the

physical layer does not support multiplexing of these channels.

Multiplexing/demultiplexing of upper layer PDUs into/from transport block

sets delivered to/from the physical layer on dedicated transport channels. The

MAC allows service multiplexing for dedicated transport channels. This function

can be utilised when several upper layer services (e.g. RLC instances) can be

mapped efficiently on the same transport channel. In this case the identification of

multiplexing is contained in the MAC protocol control information.

Traffic volume measurement. Measurement of traffic volume on logical

channels and reporting to RRC. Based on the reported traffic volume information,

RRC performs transport channel switching decisions.


17

Transport Channel type switching. Execution of the switching between

common and dedicated transport channels based on a switching decision derived

by RRC.

Ciphering. This function prevents unauthorised acquisition of data. Ciphering is

performed in the MAC layer for transparent RLC mode.

Access Service Class selection for RACH and CPCH transmission. The RACH

resources (i.e. access slots and preamble signatures) and CPCH resources (i.e.

access slots and preamble signatures) may be divided between different Access

Service Classes in order to provide different priorities of RACH and CPCH usage.

In addition it is possible for more than one ASC or for all ASCs to be assigned to

the same access slot/signature space. Each access service class will also have a set

of back-off parameters associated with it, some or all of which may be broadcast

by the network. The MAC function applies the appropriate back-off and indicates

to the PHY layer the RACH and CPCH partition associated to a given MAC PDU

transfer.

The functions of PDCP include:

Header compression and decompression. Header compression and

decompression of IP data streams (e.g., TCP/IP and RTP/UDP/IP headers) at the

transmitting and receiving entity, respectively. The header compression method is

specific to the particular network layer, transport layer or upper layer protocol

combinations e.g. TCP/IP and RTP/UDP/IP.

Transfer of user data. Transmission of user data means that PDCP receives

PDCP SDU from the NAS and forwards it to the RLC layer and vice versa.

Support for lossless SRNS relocation. Maintenance of PDCP sequence numbers

for radio bearers that are configured to support lossless SRNS relocation.

The functions of BMC include:

Storage of Cell Broadcast Messages.

The BMC stores the Cell Broadcast messages received over the CBC-RNC

interface for scheduled transmission.

Traffic volume monitoring and radio resource request for CBS.

At the UTRAN side, the BMC calculates the required transmission rate for Cell

Broadcast Service based on the messages received over the CBC-RNC interface,

UMTS Signaling Flow

18

and requests for appropriate CTCH/FACH resources from RRC.

Scheduling of BMC messages.

The BMC receives scheduling information together with each Cell Broadcast

message over the CBC-RNC-interface. Based on this scheduling information, at

the UTRAN side, BMC generates schedule messages and schedules BMC

message sequences accordingly. At the UE side, BMC evaluates the schedule

messages and indicates scheduling parameters to RRC, which are used by RRC to

configure the lower layers for CBS discontinuous reception.

Transmission of BMC messages to UE.

This function transmits the BMC messages (Scheduling and Cell Broadcast

messages) according to schedule.

Delivery of Cell Broadcast messages to upper layer (NAS).

This functions delivers the received Cell Broadcast messages to upper layer (NAS)

in the UE. Only non-corrupted Cell Broadcast messages are delivered.

The functions of RRC include:

The Radio Resource Control (RRC) layer handles the control plane signalling of Layer

3 between the UEs and UTRAN. The RRC performs the following functions:

Broadcast of information provided by the non-access stratum (Core

Network). The RRC layer performs system information broadcasting from the

network to all UEs. The system information is normally repeated on a regular

basis. The RRC layer performs the scheduling, segmentation and repetition. This

function supports broadcast of higher layer (above RRC) information. This

information may be cell specific or not. As an example RRC may broadcast Core

Network location service area information related to some specific cells.

Broadcast of information related to the access stratum. The RRC layer

performs system information broadcasting from the network to all UEs. The

system information is normally repeated on a regular basis. The RRC layer

performs the scheduling, segmentation and repetition. This function supports

broadcast of typically cell-specific information.

Establishment, re-establishment, maintenance and release of an RRC

connection between the UE and UTRAN. The establishment of an RRC

connection is initiated by a request from higher layers at the UE side to establish


19

the first Signalling Connection for the UE. The establishment of an RRC

connection includes an optional cell re-selection, an admission control, and a layer

2 signalling link establishment. The release of an RRC connection can be initiated

by a request from higher layers to release the last Signalling Connection for the

UE or by the RRC layer itself in case of RRC connection failure. In case of

connection loss, the UE requests re-establishment of the RRC connection. In case

of RRC connection failure, RRC releases resources associated with the RRC

connection.

Establishment, reconfiguration and release of Radio Bearers. The RRC layer

can, on request from higher layers, perform the establishment, reconfiguration and

release of Radio Bearers in the user plane. A number of Radio Bearers can be

established to an UE at the same time. At establishment and reconfiguration, the

RRC layer performs admission control and selects parameters describing the

Radio Bearer processing in layer 2 and layer 1, based on information from higher

layers.

Assignment, reconfiguration and release of radio resources for the RRC

connection. The RRC layer handles the assignment of radio resources (e.g. codes,

CPCH channels) needed for the RRC connection including needs from both the

control and user plane. The RRC layer may reconfigure radio resources during an

established RRC connection. This function includes coordination of the radio

resource allocation between multiple radio bearers related to the same RRC

connection. RRC controls the radio resources in the uplink and downlink such that

UE and UTRAN can communicate using unbalanced radio resources (asymmetric

uplink and downlink). RRC signals to the UE to indicate resource allocations for

purposes of handover to GSM or other radio systems.

RRC connection mobility functions. The RRC layer performs evaluation,

decision and execution related to RRC connection mobility during an established

RRC connection, such as handover, preparation of handover to GSM or other

systems, cell re-selection and cell/paging area update procedures, based on e.g.

measurements done by the UE.

Paging/notification. The RRC layer can broadcast paging information from the

network to selected UEs. Higher layers on the network side can request paging

and notification. The RRC layer can also initiate paging during an established

UMTS Signaling Flow

20

RRC connection.

Routing of higher layer PDUs. This function performs at the UE side routing of

higher layer PDUs to the correct higher layer entity, at the UTRAN side to the

correct RANAP entity.

Control of requested QoS. This function shall ensure that the QoS requested for

the Radio Bearers can be met. This includes the allocation of a sufficient number

of radio resources.

UE measurement reporting and control of the reporting. The measurements

performed by the UE are controlled by the RRC layer, in terms of what to measure,

when to measure and how to report, including both UMTS air interface and other

systems. The RRC layer also performs the reporting of the measurements from the

UE to the network.

Outer loop power control. The RRC layer controls setting of the target of the

closed loop power control.

Control of ciphering. The RRC layer provides procedures for setting of ciphering

(on/off) between the UE and UTRAN.

Arbitration of radio resources on uplink DCH. This function controls the

allocation of radio resources on uplink DCH on a fast basis, using a broadcast

channel to send control information to all involved users.This function is

implemented in the CRNC.

Initial cell selection and re-selection in idle mode. Selection of the most suitable

cell based on idle mode measurements and cell selection criteria.

Integrity protection. This function adds a Message Authentication Code (MAC-I)

to those RRC messages that are considered sensitive and/or contain sensitive

information.

Initial Configuration for CBS

This function performs the initial configuration of the BMC sublayer.

Allocation of radio resources for CBS

This function allocates radio resources for CBS based on traffic volume

requirements indicated by BMC. The radio resource allocation set by RRC (i.e.

the schedule for mapping of CTCH onto FACH/S-CCPCH) is indicated to BMC


to enable generation of schedule messages. The resource allocation for CBS shall

be broadcast as system information.

Configuration for CBS discontinuous reception

This function configures the lower layers (L1, L2) of the UE when it shall listen to

the resources allocated for CBS based on scheduling information received from

BMC.

3.2.2 Status of RRC Protocol

In UMTS, all statuses of UE are scheduled by RRC protocol. One UE has several RRC

statuses, such as, Idle and DCH. Figure 9 shows the status and status conversion

(containing GSM status).

Establish RRCConnection

Release RRCConnection

UTRA RRC Connected ModeUTRA:Inter-RATHandover

GSM:Handover

Establish RRCConnection

Release RRCConnection

URA_PCH CELL_PCH GSMConnected

Mode

Establish RRConnection

Release RRConnection

Idle Mode

Camping on a UTRAN cell1 Camping on a GSM / GPRS cell1

GPRS Packet Idle Mode1

GPRSPacket

TransferMode

Initiation oftemporaryblock flow

Release oftemporaryblock flow

Cell reselection

CELL_DCH out of service

in service

CELL_FACH

out of service

in service

out of service

in service

Figure 9 RRC Status and Status Conversion

UE status is defined by the channel that UE uses.

CELL_DCH status indicates that UE occupies the dedicated physical channel.

CELL_FACH status indicates that UE does not use any dedicated channel but uses the

common channel when the traffic is small. UL uses RACH and DL uses FACH. In this

status, UE can initiate cell reselection process and UTRAN can determine which cell

UE locates in.

CELL_PCH status indicates that UE only intercepts PCH and BCH. In this status, UE

21

UMTS Signaling Flow

22

can reselect the cell. During the reselection, it converts into CELL_FACH status, the

cell update initiates, and it returns to CELL_PCH status. The network can determine

the cell which the UE locates in.

URA_PCH status is similar to CELL_PCH status. The network can only determine the

URA cell which the UE locates in.

The introduction of CELL_PCH status and URA_PCH status is to keep UE always in

online status in order not to waster radio resources.

3.2.3 Some Explanations

In CELL_PCH, URA_PCH or Idle status, UE can intercept PCH and BCH, and can

receive the message of Paging. In CELL_DCH or CELL_FACH status, UE cannot

intercept PCH and BCH. Paging Type 2 is introduced to page UE in these two statuses.

Usually, the permanent ID information of UE (such as, IMSI) will not be saved in RNC.

When UE is making a call, CN informs RNC of the IMSI of the UE with the message

of Command ID of RANAP. When CN requires RNC to page a specific UE, RNC will

judge which RRC status the IMSI to page is in, to decide the paging type (Paging Type

1 or Paging Type 2).


3.3 Protocol related to Interface Iu

3.3.1 IU interface architecture

Core Network (CN)UTRAN

Node B

Node B

Node B

Node B

RNC

Iu Interface

“Iu-BC”

“Iu-CS”

BCDomain

CSDomain

PSDomain

“Iu-PS”

RNC

The Iu interface is specified at the boundary between the Core Network and UTRAN.

Figure depicts the logical division of the Iu interface. From the Iu perspective, the

UTRAN access point is an RNC. The Iu interface towards the PS-domain of the core

network is called Iu-PS, and the Iu interface towards the CS-domain is called Iu-CS.

The differences between Iu-CS and Iu-PS are treated elsewhere in the present

document. The Iu interface to the Broadcast domain is called Iu-BC.

There shall not be more than one Iu interface (Iu-PS) towards the PS-domain from any

one RNC. Each RNC shall not have more than one Iu interface (Iu-CS) towards its

default CN node within the CS domain, but may also have further Iu interfaces (Iu-CS)

towards other CN nodes within the CS domain. (See [6] for definition of Default CN

node.) These further Iu interfaces (Iu-CS) shall only be used as a result of intra-MSC

inter-system handover or SRNS relocation, in the case the anchor CN node directly

connects to the target RNC. There shall not be more than one Iu interface (Iu-BC) from

an RNC towards the Broadcast domain.

In the separated core network architecture, this means that there shall be separate

signalling and user data connections towards the PS and CS domains – this applies in

both transport and radio network layers.

23

UMTS Signaling Flow

In the combined architecture, there shall be separate connections in the user plane

towards the PS and CS domains (in both transport and radio network layers). In the

control plane, there shall be separate SCCP connections to the two logical domains.

In either architecture, there can be several RNCs within UTRAN and so UTRAN may

have several Iu access points towards the Core Network. As a minimum, each Iu access

point (in UTRAN or CN) shall independently fulfil the requirements of the relevant Iu

specifications

3.3.2 Protocol Structure of Iu Interface

Figure 10 shows the structure of Interface Iu-CS protocol and Figure 11 shows the

structure of Interface Iu-PS protocol.

Q.2150.1

Q.2630.1

RANAP Iu UP ProtocolLayer

TransportNetwork

Layer

Physical Layer

TransportUser

NetworkPlane


TransportUser

NetworkPlane


RadioNetwork

Layer

ATM

SSCOP

AAL5

SSCOP

SSCF-NNI

AAL2AAL5

MTP3bMTP3b

SCCP

SSCF-NNI

Figure 10 Structure of Iu-CS Protocol

24


SSCF-NNI

SSCOP

AAL5

IP

SCTP

SCCP

SSCF-NNI

MTP3-BM3UA

RANAPIu UP Protocol

Layer

TransportNetwork

Layer

Physical Layer

TransportUser

NetworkPlane


TransportUser

NetworkPlane


RadioNetwork

Layer

ATM

AAL5

IP

UDP

GTP-U

Physical Layer

ATM

Figure 11 Structure of Interface Iu-PS Protocol

RANAP: user plane application protocol. It provides the signalling service between

UTRAN and CN that is required to fulfil the RANAP functions. RANAP protocol has

the following functions:

Relocating serving RNC. This function enables to change the serving RNC

functionality as well as the related Iu resources (RAB(s) and Signalling

connection) from one RNC to another.

Overall RAB management. This function is responsible for setting up, modifying

and releasing RABs.

Queuing the setup of RAB. The purpose of this function is to allow placing some

requested RABs into a queue, and indicate the peer entity about the queuing.

Requesting RAB release. While the overall RAB management is a function of the

CN, the RNC has the capability to request the release of RAB.

Release of all Iu connection resources. This function is used to explicitly release

all resources related to one Iu connection.

25

UMTS Signaling Flow

26

Requesting the release of all Iu connection resources. While the Iu release is

managed from the CN, the RNC has the capability to request the release of all Iu

connection resources from the corresponding Iu connection.

SRNS context forwarding function. This function is responsible for transferring

SRNS context from the RNC to the CN for intersystem change in case of packet

forwarding.

Controlling overload in the Iu interface. This function allows adjusting the load in

the Iu interface.

Resetting the Iu. This function is used for resetting an Iu interface.

Sending the UE Common ID (permanent NAS UE identity) to the RNC. This

function makes the RNC aware of the UE's Common ID.

Paging the user. This function provides the CN for capability to page the UE.

Controlling the tracing of the UE activity. This function allows setting the trace

mode for a given UE. This function also allows the deactivation of a previously

established trace.

Transport of NAS information between UE and CN (see [8]).

This function has two sub-classes:

1. Transport of the initial NAS signalling message from the UE to CN. This function

transfers transparently the NAS information. As a consequence also the Iu signalling

connection is set up.

2. Transport of NAS signalling messages between UE and CN, This function

transfers transparently the NAS signalling messages on the existing Iu signalling

connection. It also includes a specific service to handle signalling messages differently.

Controlling the security mode in the UTRAN. This function is used to send the

security keys (ciphering and integrity protection) to the UTRAN, and setting the

operation mode for security functions.

Controlling location reporting. This function allows the CN to operate the mode in

which the UTRAN reports the location of the UE.

Location reporting. This function is used for transferring the actual location

information from RNC to the CN.


27

Data volume reporting function. This function is responsible for reporting

unsuccessfully transmitted DL data volume over UTRAN for specific RABs.

Reporting general error situations. This function allows reporting of general error

situations, for which function specific error messages have not been defined.

Location related data. This function allows the CN to either retrieve from the RNC

deciphering keys (to be forwarded to the UE) for the broadcasted assistance data,

or request the RNC to deliver dedicated assistance data to the UE.

SCCP: The SCCP is used to support signalling messages between the CNs and the

RNC. One user function of the SCCP, called Radio Access Network Application Part

(RANAP), is defined. The RANAP uses one signalling connection per active UE and

CN for the transfer of layer 3 messages. RANAP may use SSN, SPC and/or GT and

any combination of them as addressing schemes for the SCCP. Which of the available

addressing scheme to use for the SCCP is an operator matter. A new SCCP

connection is established when information related to the communication between a

UE and the network has to be exchanged between RNC and CN, and no SCCP

connection exists between the CN and the RNC involved, for the concerned UE.

MTP3B: provides message routing, discrimination and distribution (for point-to-point

link only), signaling link management load sharing and changeover/back between link

within one link-set. The need for multiple link-sets is precluded.

SAAL-NNI: SAAL-NNI [1] consists of the following sub-layers: - SSCF [3], - SSCOP

[2] and – AAL5 [6]. The SSCF maps the requirements of the layer above to the

requirements of SSCOP. Also SAAL connection management, link status and remote

processor status mechanisms are provided. SSCOP provides mechanisms for the

establishment and release of connections and the reliable exchange of signalling

information between signalling entities. Adapts the upper layer protocol to the

requirements of the Lower ATM cells.

IUUP: user plane protocol.

GTP-U: GTP-U is used as the user data bearer towards the PS domain.RANAP

Signalling is used to establish, modify and release the GTP-U tunnels towards the PS

domain.

AAL2: AAL2 is used as the user data bearer towards the CS domain.Q.2630.2 is used

as the protocol for dynamically setup AAL-2 connections over Iu towards the CS

UMTS Signaling Flow

domain. Q.2630.2 adds new optional capabilities to Q.2630.1.

3.3.3 Some Explanations

3.3.3.1 SRNS Relocation

One case:

UE crosses 2 RNSs during the move, as shown in Figure 12.

Figure 12 SRNS Relocation (I)

One UE can use 2 RNSs at the same time. The data can be sent on two RLs. In addition,

the data that UE sends to DRNC is sent to SRNC via Interface Iur, and SRNC will

combine them and send to CN.

If UE continues to move, the RL deterioration of UE on SRNS cannot be used again,

which will cause the following case.

28


Figure 13 SRNS relocation (II)

UE and SRNC have no direct contact, but all data still pass SRNC and reach CN via

Interface Iur. It will cause the waste of resources. Therefore, SRNS relocation should

be initiated, which can move Interface Iu from SRNC to DRNC. In the course of

SRNC relocation, SRNC (Serving RNC) is also called Source RNC and DRNC is also

called Target RNC. Figure 14 shows the result after the relocation completes.

Figure 14 SRNS Relocation (III)

29

UMTS Signaling Flow

30

SRNS relocation is the process to move Interface Iu from Source RNC to Target RNC.

3.3.4 RANAP Process

Table 1 Class 1

Elementary

Procedure Initiating Message

Successful Outcome Unsuccessful Outcome

Response message Response message

Iu Release IU RELEASE

COMMAND

IU RELEASE

COMPLETE

Relocation

Preparation

RELOCATION

REQUIRED

RELOCATION

COMMAND

RELOCATION

PREPARATION

FAILURE

Relocation

Resource

Allocation

RELOCATION

REQUEST

RELOCATION

REQUEST

ACKNOWLEDGE

RELOCATION

FAILURE

Relocation Cancel RELOCATION

CANCEL

RELOCATION

CANCEL

ACKNOWLEDGE

SRNS Context

Transfer

SRNS CONTEXT

REQUEST

SRNS CONTEXT

RESPONSE

Security Mode

Control

SECURITY MODE

COMMAND

SECURITY MODE

COMPLETE

SECURITY MODE

REJECT

Data Volume

Report

DATA VOLUME

REPORT REQUEST

DATA VOLUME

REPORT

Reset RESET RESET

ACKNOWLEDGE

Reset Resource RESET RESOURCE RESET RESOURCE

ACKNOWLEDGE

Location related

Data

LOCATION

RELATED DATA

REQUEST

LOCATION

RELATED DATA

RESPONSE

LOCATION RELATED

DATA FAILURE

Table 2 Class 2

Elementary Procedure Message

RAB Modification Request RAB MODIFY REQUEST

RAB Release Request RAB RELEASE REQUEST

Iu Release Request IU RELEASE REQUEST

Relocation Detect RELOCATION DETECT

Relocation Complete RELOCATION COMPLETE


31


SRNS Data Forwarding Initiation SRNS DATA FORWARD

COMMAND

SRNS Context Forwarding from Source RNC to CN FORWARD SRNS CONTEXT

SRNS Context Forwarding to Target RNC from CN FORWARD SRNS CONTEXT

Paging PAGING

Common ID COMMON ID

CN Invoke Trace CN INVOKE TRACE

CN Deactivate Trace CN DEACTIVATE TRACE

Location Reporting Control LOCATION REPORTING

CONTROL

Location Report LOCATION REPORT

Initial UE Message INITIAL UE MESSAGE

Direct Transfer DIRECT TRANSFER

Overload Control OVERLOAD

Error Indication ERROR INDICATION

Table 3 Class 3

Elementary Procedure Initiating Message Response Message

RAB Assignment RAB ASSIGNMENT

REQUEST

RAB ASSIGNMENT

RESPONSE x N (N>=1)

3.4 Protocol related to Interface Iur

The highest layer protocol of Interface Iur control plane is RANSAP. Figure 15 shows

the structure of Interface Iur protocol.

UMTS Signaling Flow

SSCF-NNI

SSCOP

MTP3-B

AAL5

IP

SCTP

SCCP

AAL5

SSCF-NNI

STC (Q.2150.1)

RNSAP Iur DataStream(s)

TransportNetworkLayer

Physical Layer

TransportUser

NetworkPlane


TransportUser

NetworkPlane


RadioNetworkLayer

ATM

ALCAP(Q.2630.1)

AAL2

SSCF-NNI

SSCOP

MTP3-B

IP

SCTPSSCF-NNI

M3UA M3UA

Figure 15 Structure of Interface Iur Protocol

The protocol structure of Interface Iur control plane (including RNL and TNL) is same

as that of Interface Iu control plane.

3.4.1 Function and Structure of Interface Iur

Interface Iur is to transmit data when UE performs the soft handover between adjacent

RNCs.

3GPP prescribes that Interface Iur is a logic entity. That is, Interface Iur and Interface

Iu can either share one channel for the transmission or connect via independent

physical interface.

3.4.2 DCH Frame Protocol of Interface Iur

As shown in Figure,when UE crosses RNSs, DRNC can forward DCH data to SRNC

via Interface Iur. DRNC does not process DCH data but directly send DCH data at

Interface Iub to Interface Iur. DCH frames of Interface Iur and Interface Iub keep

consistent, to greatly reduce DCH data processing by DRNC.

32


33

3.4.3 RNSAP Process

Table 4 Class 1 Elementary Procedures

Elementary




Radio Link

Setup

RADIO LINK

SETUP

REQUEST

RADIO LINK

SETUP RESPONSE

RADIO LINK SETUP

FAILURE

Radio Link

Addition

RADIO LINK

ADDITION

REQUEST

RADIO LINK

ADDITION

RESPONSE

RADIO LINK

ADDITION FAILURE

Radio Link

Deletion

RADIO LINK

DELETION

REQUEST

RADIO LINK

DELETION

RESPONSE

Synchronised

Radio Link

Reconfigurati

on Preparation

RADIO LINK

RECONFIGURAT

ION PREPARE

RADIO LINK

RECONFIGURATI

ON READY

RADIO LINK

RECONFIGURATIO

N FAILURE

Unsynchronis

ed Radio Link

Reconfigurati

on

RADIO LINK

RECONFIGURAT

ION REQUEST

RADIO LINK

RECONFIGURATI

ON RESPONSE

RADIO LINK

RECONFIGURATIO

N FAILURE

Physical

Channel

Reconfigurati

on

PHYSICAL

CHANNEL

RECONFIGURAT

ION REQUEST

PHYSICAL

CHANNEL

RECONFIGURATI

ON COMMAND

PHYSICAL

CHANNEL

RECONFIGURATIO

N FAILURE

Dedicated

Measurement

Initiation

DEDICATED

MEASUREMENT

INITIATION

REQUEST

DEDICATED

MEASUREMENT

INITIATION

RESPONSE

DEDICATED

MEASUREMENT

INITIATION

FAILURE

Common

Transport

Channel

Resources

Initialisation

COMMON

TRANSPORT

CHANNEL

RESOURCES

REQUEST

COMMON

TRANSPORT

CHANNEL

RESOURCES

RESPONSE

COMMON

TRANSPORT

CHANNEL

RESOURCES

FAILURE

Common

Measurement

Initiation

COMMON

MEASUREMENT

INITIATION

REQUEST

COMMON

MEASUREMENT

INITIATION

RESPONSE

COMMON

MEASUREMENT

INITIATION

FAILURE

UMTS Signaling Flow

34

Elementary




Information

Exchange

Initiation

INFORMATION

EXCHANGE

INITIATION

REQUEST

INFORMATION

EXCHANGE

INITIATION

RESPONSE

INFORMATION

EXCHANGE

INITIATION

FAILURE

Table 5 Class 2 Elementary Procedures

Elementary Procedure Initiating Message

Uplink Signalling Transfer UPLINK SIGNALLING TRANSFER

INDICATION

Downlink Signalling Transfer DOWNLINK SIGNALLING TRANSFER

REQUEST

Relocation Commit RELOCATION COMMIT

Paging PAGING REQUEST

Synchronised Radio Link

Reconfiguration Commit

RADIO LINK RECONFIGURATION

COMMIT


Reconfiguration Cancellation


CANCEL

Radio Link Failure RADIO LINK FAILURE INDICATION

Radio Link Restoration RADIO LINK RESTORE INDICATION

Dedicated Measurement Reporting DEDICATED MEASUREMENT REPORT

Dedicated Measurement

Termination

DEDICATED MEASUREMENT

TERMINATION REQUEST

Dedicated Measurement Failure DEDICATED MEASUREMENT FAILURE

INDICATION

Downlink Power Control [FDD] DL POWER CONTROL REQUEST

Compressed Mode Command

[FDD]

COMPRESSED MODE COMMAND

Common Transport Channel

Resources Release

COMMON TRANSPORT CHANNEL

RESOURCES RELEASE REQUEST


Downlink Power Timeslot Control

[TDD]

DL POWER TIMESLOT CONTROL

REQUEST

Radio Link Pre-emption RADIO LINK PREEMPTION REQUIRED

INDICATION

Radio Link Congestion RADIO LINK CONGESTION INDICATION

Common Measurement Reporting COMMON MEASUREMENT REPORT

Common Measurement Termination COMMON MEASUREMENT

TERMINATION REQUEST


Elementary Procedure Initiating Message

Common Measurement Failure COMMON MEASUREMENT FAILURE

INDICATION

Information Reporting INFORMATION REPORT

Information Exchange Termination INFORMATION EXCHANGE

TERMINATION REQUEST

Information Exchange Failure INFORMATION EXCHANGE FAILURE

INDICATION

3.5 Protocol Related to Interface Iub

The high layer protocol of Interface Iub control plane is NBAP. The user plane consists

of several frame protocols. Figure 16 shows the structure of protocols.

Node BApplication Part

(NBAP)

AAL Type 2

ALCAP

TransportLayer

Physical Layer

RadioNetworkLayer

Radio NetworkControl Plane

TransportNetwork

Control Plane

DCH

FP

RAC

HFP

ATM

DSCH

FP

AAL Type 5

User Plane

SSCF-UNI

SSCOP

AAL Type 5

SSCF-UNI

SSCOP

Q.2630.1

Q.2150.2

FAC

HFP

PCH

FP

USCH

FP

CPCH FP

Figure 16 Structure of Interface Iub Protocol

NBAP includes Node B logic O&M and dedicated NBAP.

35

UMTS Signaling Flow

3.5.1 Node B Logic Model ... ...

Node B

...Cell Cell Cell Cell CellCell

Node B Communication Contexts,with attributes

Common Transport Channels,with attributes

Node BControlPort

IubRACHDataport

IubFACHDataport

IubPCHDataport

Controlling RNC

IubFDD

CPCHDataport

Traffic termination point

CommunicationControlPort

IubTDD USCH

Dataport

IubDCHDataport

IubDSCHDataport

IubFDD TFCI2

Dataport

Traffic termination point

CommunicationControlPort

IubTDD USCH

Dataport

IubDCHDataport

IubDSCHDataport

IubFDD TFCI2

DataPort

Figure 17 Node B Logic Model

Node B logic model consists of cell, common transmission channel/port, Node B

communication context, and the corresponding DSCH/DCH. Node B controls NCP and

the communication controls port CCP, etc.

Node B communication context and the corresponding DSCH/DCH port are related to

dedicated user services.

Node B communication context is corresponding to CRNC communication context.

Node B communication context is identifies by Node B Communication Text ID,

containing necessary information to communicate with UE. It is established when RL

is setup and deleted when RL is deleted.

There is only one NCP link on one Node B. RNC sends all Node B common control

signaling from NCP. NCP link must be setup before operating, maintaining, and

controlling Node B.

There can be several CCP links on one Node B. RNC sends all Node B dedicated

control signaling from CCP link. Usually, one cell inside Node B can be configured

with one CCP (it is just a routine, not certain.)

3.5.2 NBAP Process

36


37

Table 6 Class 1

Elementar

y

Procedure

Message Successful Outcome

Unsuccessful

Outcome


Cell Setup CELL SETUP

REQUEST

CELL SETUP

RESPONSE

CELL SETUP

FAILURE

Cell

Reconfigu

ration

CELL

RECONFIGURATIO

N REQUEST

CELL

RECONFIGURATIO

N RESPONSE

CELL

RECONFIGURATIO

N FAILURE

Cell

Deletion

CELL DELETION

REQUEST

CELL DELETION

RESPONSE

Common

Transport

Channel

Setup

COMMON

TRANSPORT

CHANNEL SETUP

REQUEST

COMMON

TRANSPORT

CHANNEL SETUP

RESPONSE

COMMON

TRANSPORT

CHANNEL SETUP

FAILURE

Common

Transport

Channel

Reconfigu

ration

COMMON

TRANSPORT

CHANNEL

RECONFIGURATIO

N REQUEST

COMMON

TRANSPORT

CHANNEL

RECONFIGURATIO

N RESPONSE

COMMON

TRANSPORT

CHANNEL

RECONFIGURATIO

N FAILURE

Common

Transport

Channel

Deletion

COMMON

TRANSPORT

CHANNEL

DELETION

REQUEST

COMMON

TRANSPORT

CHANNEL

DELETION

RESPONSE

Physical

Shared

Channel

Reconfigu

re [TDD]

PHYSICAL SHARED

CHANNEL

RECONFIGURATIO

N REQUEST

PHYSICAL

SHARED CHANNEL

RECONFIGURATIO

N RESPONSE

PHYSICAL

SHARED CHANNEL

RECONFIGURATIO

N FAILURE

Audit AUDIT REQUEST AUDIT RESPONSE AUDIT FAILURE

Block

Resource

BLOCK RESOURCE

REQUEST

BLOCK RESOURCE

RESPONSE

BLOCK RESOURCE

FAILURE

Radio

Link

Setup

RADIO LINK SETUP

REQUEST

RADIO LINK

SETUP RESPONSE

RADIO LINK

SETUP FAILURE

System

Informatio

n Update

SYSTEM

INFORMATION

UPDATE REQUEST

SYSTEM

INFORMATION

UPDATE

RESPONSE

SYSTEM

INFORMATION

UPDATE FAILURE

UMTS Signaling Flow

38

Elementar

y

Procedure


Unsuccessful

Outcome


Common

Measurem

ent

Initiation

COMMON

MEASUREMENT

INITIATION

REQUEST

COMMON

MEASUREMENT

INITIATION

RESPONSE

COMMON

MEASUREMENT

INITIATION

FAILURE

Radio

Link

Addition

RADIO LINK

ADDITION

REQUEST

RADIO LINK

ADDITION

RESPONSE

RADIO LINK

ADDITION

FAILURE

Radio

Link

Deletion

RADIO LINK

DELETION

REQUEST

RADIO LINK

DELETION

RESPONSE

Synchroni

sed Radio

Link

Reconfigu

ration

Preparatio

n

RADIO LINK

RECONFIGURATIO

N PREPARE

RADIO LINK

RECONFIGURATIO

N READY

RADIO LINK

RECONFIGURATIO

N FAILURE

Unsynchr

onised

Radio

Link

Reconfigu

ration

RADIO LINK

RECONFIGURATIO

N REQUEST

RADIO LINK

RECONFIGURATIO

N RESPONSE

RADIO LINK

RECONFIGURATIO

N FAILURE

Dedicated

Measurem

ent

Initiation

DEDICATED

MEASUREMENT

INITIATION

REQUEST

DEDICATED

MEASUREMENT

INITIATION

RESPONSE

DEDICATED

MEASUREMENT

INITIATION

FAILURE

Reset RESET REQUEST RESET RESPONSE

Cell

Synchroni

sation

Initiation

[3.84Mcps

TDD]

CELL

SYNCHRONISATIO

N INITIATION

REQUEST

CELL

SYNCHRONISATIO

N INITIATION

RESPONSE

CELL

SYNCHRONISATIO

N INITIATION

FAILURE


39

Elementar

y

Procedure


Unsuccessful

Outcome


Cell

Synchroni

sation

Reconfigu

ration

[3.84

Mcps

TDD]

CELL

SYNCHRONISATIO

N

RECONFIGURATIO

N REQUEST

CELL

SYNCHRONISATIO

N

RECONFIGURATIO

N RESPONSE

CELL

SYNCHRONISATIO

N

RECONFIGURATIO

N FAILURE

Cell

Synchroni

sation

Adjustme

nt

[3.84Mcps

TDD]

CELL

SYNCHRONISATIO

N ADJUSTMENT

REQUEST

CELL

SYNCHRONISATIO

N ADJUSTMENT

RESPONSE

CELL

SYNCHRONISATIO

N ADJUSTMENT

FAILURE

Informatio

n

Exchange

Initiation

INFORMATION

EXCHANGE

INITIATION

REQUEST

INFORMATION

EXCHANGE

INITIATION

RESPONSE

INFORMATION

EXCHANGE

INITIATION

FAILURE

Table 7 Class 2


Resource Status Indication RESOURCE STATUS INDICATION

Audit Required AUDIT REQUIRED INDICATION

Common Measurement Reporting COMMON MEASUREMENT REPORT

Common Measurement Termination COMMON MEASUREMENT

TERMINATION REQUEST

Common Measurement Failure COMMON MEASUREMENT FAILURE

INDICATION


Reconfiguration Commit


COMMIT


Reconfiguration Cancellation


CANCEL

Radio Link Failure RADIO LINK FAILURE INDICATION

Radio Link Restoration RADIO LINK RESTORE INDICATION

Dedicated Measurement Reporting DEDICATED MEASUREMENT REPORT

UMTS Signaling Flow

40


Dedicated Measurement

Termination

DEDICATED MEASUREMENT

TERMINATION REQUEST

Dedicated Measurement Failure DEDICATED MEASUREMENT FAILURE

INDICATION

Downlink Power Control [FDD] DL POWER CONTROL REQUEST

Compressed Mode Command

[FDD]

COMPRESSED MODE COMMAND

Unblock Resource UNBLOCK RESOURCE INDICATION


Downlink Power Timeslot Control

[TDD]

DL POWER TIMESLOT CONTROL

REQUEST

Radio Link Pre-emption RADIO LINK PREEMPTION REQUIRED

INDICATION

Cell Synchronisation Reporting

[3.84Mcps TDD]

CELL SYNCHRONISATION REPORT

Cell Synchronisation Termination

[3.84Mcps TDD]

CELL SYNCHRONISATION TERMINATION

REQUEST

Cell Synchronisation Failure

[3.84Mcps TDD]

CELL SYNCHRONISATION FAILURE

INDICATION

Information Reporting INFORMATION REPORT

Information Exchange Termination INFORMATION EXCHANGE

TERMINATION REQUEST

Information Exchange Failure INFORMATION EXCHANGE FAILURE

INDICATION

ZTE Training Material

Documents

Transcript of ZTE Training Material