UTRAN and UMTS Signalling Protocols

I. UMTS Architecture

1 UTRAN and UMTS Radio Protocols

UMTS Architecture Module Objectives:

• Introduction to UTRAN, • UTRAN Identifiers (RNTI),

• UTRAN Functionalities,

• UTRAN Protocol Models and Protocol Stacks.


UTRAN and UMTS Radio Protocols 2



1 UMTS Network Architecture, Definitions



1.1 UMTS Network Domains With the success of GSM and the increasing demand for pure data transmission services, a new mobile communication system was necessary to support services with higher needs for network resources. For the ETSI (European Telecommunication Standards Institute) UMTS shall fulfill these demands. UMTS (Universal Mobile Telecommunication System) can be considered to be the successor of GSM/GPRS. As GSM also UMTS follows the basic structure of all communication networks. They can be divided into three parts: • User Equipment (UE) : The user equipment consists of mobile equipment plus the

hard- and software that is necessary to provide services. The mobile equipment itself mainly has the task to provide access and transport services to the network.

• Access Network (AN) : The Access Network is part of the fixed network. Any access

network AN has two tasks. First the AN is responsible to enable the UE (user equipment) to access the network (e.g. establishing radio links between AN and UE). The second task is to transparently transport information between UE and CN (core network). In UMTS the AN has a special name : UTRAN (UMTS Terrestrial Radio Access Network) .

• Core Network (CN) : The Core Network CN is the second big part of the fixed

network. The CN is the network that is responsible for the basic telecommunication service. This can be switching of circuits or routing of packets. The applications itself can reside within the core network, but can also be in an external network (e.g. a server in the internet).



UTRAN UTRANCN

User Data User Data

Access / TransportSignalling




Non Access Signalling Non Access Signalling

Application Data (User Data)

Menu

UE

M enu

UE

figure 1 Top level design of mobile communication network UMTS and types of information.



In this course we will deal with UMTS Release 3 (corresponds to UMTS Release 1999). In this case the CN (core network) is taken from GSM/GPRS. This means the core network of UMTS Release 3 contains a CS–CN–Domain (Circuit Switched Core Network Domain) , which is in fact a standard GSM network, and a PS–CN–Domain (Packet Switched Core Network Domain) , formed by the GSM–GPRS network part (SGSN, GGSN). These two parts, PS- and CS–CN–Domain, are independent of each other. For the UTRAN this will mean that it has to serve two core networks.



InternetCNServer

UTRAN

Video/Telephony

CS-CN

Internet Session PS-CN

Menu

UE 1

Menu

UE 2

Menu

UE 3

figure 2 Core network domains and co rresponding services provided by UMTS.



To provide a consistent set of term definitions, the 3GPP/ETSI made the following definition, that can be found in TS 23.101. These definitions divide the different network blocks according to their function with respect to a provided service. We have the following so called domains: • User Equipment Domain : The user equipment domain is the mobile part of the

network. It represents the UE as physical entity. There are two sub-domains inside:

USIM domain : The USIM (User Services Identity Module) is the entity that contains the user identity and the user specific settings.

Mobile Equipment domain : This domain is the hard- and software in the

mobile phone, necessary to get access to the network and to support the core network services.

• Infrastructure domain : The infrastructure domain covers the fixed network part of

UMTS, that means all physical entities controlled by the network operators. There are two sub- domains:

Access Network domain : The access network domain is the UTRAN that

serves the user.

Core Network domain : The core network domain represent that part of the fixed network, that is responsible for the basic services (switching, routing, SMS). The core network itself is a physical entity. According to their function for a running service, the following logical domains can be distinguished:

o Serving CN domain : The serving CN domain represent that part of the

CN, that is currently serving the user.

o Home CN domain : The home CN domain is that part of the CN, the home operator of the subscriber controls. In the home CN domain the permanent subscriber data base for the user can be found (HLR).

o Transit CN domain : The transit CN domain covers all CN parts that do

not belong to the serving CN domain, but are used to transport user data.



USIM

MobileEquipment

Cu

UE UTRAN CN

Uu Iu ServingNetwork

UTRAN

TransitNetwork

HomeNetwork

Yu

Zu

Infrastructure

figure 3 Network functional domains of UMTS.



1.2 Communication between Network Functional Domains – Strata

The communication between the different domains can be divided according to their task. In this course we will restrict ourselves to the point of concern, UTRAN. As already mentioned UTRAN has to tasks : • access between UE and UTRAN, • transparent transport of signaling messages (not related to access) between UE

and CN. Therefore we can distinguish three types of signaling between UE, UTRAN and CN: • access stratum (AS) : The access stratum covers all signaling exchange used to

control the access of an UE to the network. Access stratum messages occur between UE and UTRAN and between UTRAN and CN. The difference between the access stratum UE-UTRAN and UTRAN-CN is, that the UTRAN-CN access stratum shall be independent of the radio technology used in UTRAN. This enables the CN to use several different radio access technologies.

• transport stratum : The transport stratum protocols and messages have the task to

transport higher layer PDUs (protocol data units) and user data. Because UTRAN has the task to transparently transport data between UE and CN, there will be transport stratum messages between UE and UTRAN and between UTRAN and CN.

• non- access stra tum (NAS) : The non-access stratum covers all messages of

higher layers and user data, that do not deal with access or transport tasks. This covers pure application control (application stratum), service request and control (serving stratum), handling of subscription data and subscriber specific services (home stratum).

The strata are exactly defined in TS 23.101. It has to be noted, that a single protocol can belong to different strata (e.g. RRC belongs to AS and transport stratum).



Transport Stratum

UE UTRAN CN

Access Stratum Access Stratum

Transport StratumTransport Stratum

Non Access Stratum (NAS)

figure 4 Network strata relevant for UTRAN



2 UTRAN Architecture and UTRAN Identifiers



2.1 UTRAN Network Architecture and Entities The radio technology WCDMA, that is used in UMTS, in contained in the UMTS Terrestrial Radio Access Network UTRAN. Now UTRAN is a cellular radio system like GSM. This means that every coverage area of UTRAN is divided into cells. Every cell is served by an antenna providing radio coverage of this cell. The UTRAN architecture is strictly hierarchical. Every cell is served by one and only one so called Node B . The task of the Node B is to control the antennae of every cell and to perform the lowest layer tasks. This means the Node B handles the WCDMA physics. One Node B can handle several cells. The higher access and transport tasks of UTRAN are performed by a RNC (Radio Network Controller) . Every Node B is connected to one and only one RNC. Again one RNC can support several Node Bs. The RNC provides for all cells of all connected Node Bs the access and transport tasks between UE and UTRAN, and the RNC is responsible to control the connection to the CN for the UE. One RNC together with all its Node Bs and their cells form a RNS (Radio Network Subsystem) . The UTRAN itself consists of one or more RNS. UTRAN knows the following interfaces: • Uu : Interface between UE and Node B (cell). • Iub : Interface between Node B and its controlling RNC. • Iur : Interface between two RNC. This interface is optional, it is necessary to support

soft handover. The Iur interface can be implemented via virtual channels. • Iu : Interface between RNC and CN. In fact one RNC can have at most one Iu

interface to a SGSN (PS-CN domain), one Iu interface to a MSC (CS-CN domain), there can be multiple Iu interfaces to a broadcast domain (e.g. for cell broadcasting).



cell cell cellcellcell cellcell

Node B Node B

RNCRNS

Node B

RNC

Node B

RNS

IurIub Iub

Iub Iub

CS-CN PS-CN BC-CNCN

Iu

figure 5 UTRAN Architecture und functional entities.



2.2 Serving, Controlling and Drift RNC There is a very strict management principle in UTRAN. Together with these principles three terms, indicating the RNC functionality, are connected to. Every RNC can support all three different functionality. It depends on the situation, which functionality has to be applied. The first term, that is going to be discussed, is controlling RNC (C-RNC) . Every cell has one and only one C-RNC. The C-RNC of a cell is exactly the RNC that is connected with the Node B serving the cell. The tasks of the controlling RNC covers the following areas: • admission control based on UL interference level and DL transmission power, • system information broadcasting, • allocation / de-allocation of radio bearers, • data transmission and reception. This means the controlling RNC of a cell is responsible for all lower layer functions related to the radio technology.



cell

Iub

Controlling RNC

-admission control

- system information broadcasting

- radio bearer allocation / release( code allocation / release)

- data transmission and reception

C-RNC

Node B

figure 6 Controlling RNC functionality.



For UTRAN the following principle is applied. An UE that is attached to an UTRAN is served by one and only one RNC. This RNC is called the serving RNC (S-RNC) . The existence of a serving RNC does not imply that the UE is camped on a cell belonging to the S-RNC. The serving RNC handles all higher layer functions related to radio access and information transport through UTRAN. In detail the S-RNC performs the following functions: • the S-RNC handles the Iu interface towards the CN for this UE, • the S-RNC handles the complete radio resource control for this UE, • location / mobility handling, • ciphering, • backward error correction (layer 2 functionality). In UMTS it is possible that one UE is connected to more than one cell, or connected to a cell, that does not belong to the S-RNC. This means the UE is connected with a cell controlled by a RNC different to the S-RNC. This foreign RNC is called drift RNC (D-RNC). In principle the D-RNC is the C-RNC of a cell the UE is connected to, but its not the S-RNC. Therefore the D-RNC performs the C-RNC functions for the cells not controlled by the S-RNC. When a D-RNC is involved for a UE, then the data streams between UE and UTRAN and UE-CN always pass the S-RNC. In the downlink the S-RNC sends the data to own cells and to the D-RNC (soft handover), this is called splitting . The UE receives all the data streams from the cells, it is connected to, and adds them together (RAKE receiver). In the uplink the S-RNC receives data from the own cells and from the D-RNC. Here the S-RNC combines the data streams. This combination is performed by the S-RNC in the following way : the S-RNC takes only the data frame with the smallest bit error rate, all other data frames will be discarded. The usage of a D-RNC requires a Iur interface between D-RNC and S-RNC. Because the implementation of an Iur interface is optional, it is a matter of network planning, whether the usage of D-RNC is allowed or not. The interface itself does not need to be a physical line, it can be implemented via virtual paths or virtual channels.



Iub

Serving RNC

-Iu interface controlling

- radio resource control

- location / mobility handling

- encryption / integrity check

- backward error correction

- combining / splitting of datastreams

Iub

CN

Iur

Iu

D-RNC S-RNC

Node B Node B

Menu

UE

figure 7 Serving RNC functionality.



2.3 Geographical and Entity Identifier As in GSM there is a need to address different physical, geographical or logical entities within UMTS. Here first of all the geographical and physical entities of UTRAN will be described. 1. PLMN Id :

The PLMN-ID is used to address a PLMN in a world wide unique manner. As in GSM the PLMN-ID consist of a MCC (mobile country code) and a MNC (mobile network code). MCC and MNC are allocated by ITU-T and are specified within ITU-T E.212.

PLMN-ID = MCC + MNC.

2. CN-Domain Ids : CS- and PS core network introduce their own regional area concept. This is the concept of Location Area for CS and the concept of Routing Area for PS. This exactly the same as in GSM/GPRS. We have:

LAI = PLMN-ID + LAC (Location Area Identity/Code) RAI = PLMN-ID + LAC + RAC (Routing Area Identity/Code)

3. RNC Id: Every RNC node has to be uniquely identified within UTRAN. Therefore every RNC gets a RNC-ID. Together with the PLMN-ID the RNC-ID is unique world wide. The RNC-ID will be used to address a RNC via Iu, Iur and Iub interface. For the serving RNC the identifier is called S-RNC-ID, for the drift RNC it is denoted as D-RNC-ID and the controlling RNC has a C-RNC-ID. For one RNC node these identifiers are always the same. The RNC identifier itself is allocated by O&M. Global RNC-ID = PLMN-ID + RNC-ID

4. Cell Id and UTRAN Cell Id: The cell ID C-ID is used to address a cell within a RNS. The cell ID is set by O&M in the C-RNC. Together with the RNC-ID the cell ID forms the UTRAN cell ID UC-Id. UC-ID = RNC-ID + C-ID

5. Local Cell Identifier The local cell identifier is used in the Node B to identify resources. There is a unique relation UC-Id to local cell identifier.



6. Service Area Id : Several cells of one location area can be defined to form a service area. Such a service area is identified with a SAI (service area id) : SAI = PLMN-ID + LAC + SAC It can be used to support location based services.

7. URA ID : The UTRAN introduces its own are concept next to LA and RA. This is the UTRAN registration area

MNC2 6 2 0 1MCC

PLMN-ID

LAI PLMN-ID LAC (2byte)

RAI PLMN-ID LAC (2byte) RAC (1byte)

GlobalRNC-ID PLMN-ID RNC-ID (12 bit)

UC-ID CRNC-ID (12 bit) C-ID (28 bit)

SAI PLMN-ID LAC SAC (2 byte)

URA-ID URA ID (2 byte)

Location Area

Routing Area

RNC

UTRAN cell ID

Service Area

UTRAN registrationarea

Public LandMobile Network

figure 8 UTRAN identifiers for geographical areas and UTRAN entities.



2.4 UTRAN specific UE Identifiers The UE and the subscriber can have several identifiers for the PLMN. Typically we can distinguish two types of identifiers according to the point of generation of the identifier: • NAS (non access stratum ) identifiers : These identifiers are allocated by the core

network. In detail there are IMSI, TMSI and P-TMSI (and IMEI). • UTRAN identifiers : UTRAN identifiers are always temporary. This means they are

allocated to the UE for the time of the need. After the last procedure the last procedure the identifiers are released.

In this chapter only the UTRAN identifier are of interest. It is a typical principle in communication and computing systems that every entity working on a specific task, allocates its own identifier and handler. This is also the case for UTRAN. Every UTRAN entity like RNC and Node B will provide their special identifier for the UE. These identifiers are called Radio Network Temporary Identifier (RNTI) . There are four types of RNTI:

• s-RNTI : The s-RNTI is allocated by the serving RNC. The S-RNC uses the s-RNTI

to address the UE. The D-RNC uses the s-RNTI to identify the UE to the S-RNC. The s-RNTI uniquely addresses the UE in the S-RNC.

• d-RNTI : The d-RNTI is allocated by a D-RNC, but the d-RNTI is never used on the

air interface Uu. Instead the S-RNC uses the d-RNTI to identify the UE to the D-RNC. The d-RNTI uniquely identifies the UE in the D-RNC.

• c-RNTI : The c-RNTI is allocated by a controlling RNC when the UE accesses a new

cell of this C-RNC. The c-RNTI is unique in the cell. The corresponding C-RNC shall be able to translate the c-RNTI into s-RNTI (if C-RNC=S-RNC) or into d-RNTI (if C-RNC=D-RNC). The c-RNTI is used by UE to identify itself to the C-RNC, and is used by the C-RNC to address the UE.

• u-RNTI : The u-RNTI (UTRAN – RNTI) consist of RNC-Id and s-RNTI

u-RNTI = RNC-ID + s-RNTI .

So the u-RNTI is unique world wide. The u-RNTI will be used by UE and S-RNC to identify the UE on common radio channels and during paging and cell access.



IubIub

CN

Iur

Iu

D-RNC S-RNC

Node B Node B

Menu

UE

RNTI

- allocated by RNCs

- 16 bit length (u-RNTI 32 bit)

- used within UTRANand on Uu only

s-RNTI

d-RNTI

u-RNTI orc-RNTI B, C

u-RNTI orc-RNTI A

s-RNTId-RNTI

c-RNTI B, Cd-RNTIs-RNTI

c-RNTI A

figure 9 Radio Network Temporary Identifiers RNTI and their usage and allocation.



3 UMTS Protocol Stacks – Overview



3.1 Protocols UE – UTRAN – CN for CS Domain In this section the protocol stack used for circuit switched services is discussed. The protocols between UE – UTRAN and UTRAN – CN for the control plane are shown in the first figure. There are the following important protocol layer : • Physical Layer (PHY) : The physical layer on the air interface provides access to the

WCDMA radio interface. Therefore it performs spreading, scrambling, modulation, channel coding, rate matching, … .

• Medium Access Control (MAC) : The MAC protocol belongs to layer 2. The tasks of

MAC are the control of random access and the multiplexing/de-multiplexing of different UE onto shared radio resources.

• Radio Link Control (RLC) : As MAC also the RLC protocol is a layer 2 protocol.

RLC provides three reliability modes for every radio bearer. These modes are : Acknowledged (AM), Unacknowledged (UM) and Transparent (TM).

• Radio Resource Control (RRC) : The RRC protocol is the first protocol of layer 3.

The RRC protocol performs all higher layer tasks related to the access stratum on the air interface (e.g. radio bearer setup).

• NAS Protocol : On top of RRC there are the control protocols for the non access

stratum (NAS). For the circuit switched services these are : MM (mobility management), CC (Call Control), SS (Supplementary Services) and SMS (Short Message Service), if it is not provided by the packet switched protocol stack.

• Radio Access Network Application Part (RANAP) : RANAP is between UTRAN

and CN. It performs all tasks related to transport stratum for control signaling and access stratum between UTRAN and CN. It is the counterpart to RRC.

• Signaling Connection Control Part (SCCP) : The SCCP has mainly transport

tasks. It is used to establish a signaling connection for a UE. So the UE can then be identified by the signaling connection and not by an explicit identifier.

• MTP3B, SAAL, AAL5, ATM : These protocols belong to the transport network

(ATM). They provide a signaling bearer to transport SCCP and RANAP.



RNS MSC

PHY

MAC

RLC

RRC

MM, CC, SS, SMS

PHY

MAC

RLC

RRC

SAAL / AAL5

MTP 3 B

SCCP

RANAP

ATM

Layer 1

Relay

SAAL / AAL5

MTP 3 B

SCCP

RANAP

ATM

Layer 1

MM, CC, SS, SMS

UE

SAAL : Signalling ATM Adaptation LayerATM : Asynchronous Transfer ModeAAL 5 : ATM Adaptation Layer type 5MTP 3B : Message Transfer Part level 3 for Broadband

figure 10 Control protocols between UE-UTRAN-CN for CS domain.



The control plane discussed before is used to exchange signaling for access, transport and service related control. Like all modern communication system also UMTS transports the control signaling and the user data over the same transport network. This immediately implies, that there have to be protocols supporting the user data transfer. In the next figure the protocols used for this purpose are shown. In the lowest layers there are the same protocols as for the control plane. This results from the fact, that user data and control signaling use the same transport system. In detail there are the following protocols involved into the user data transport: • PHY, MAC, RLC : The air interface transport system is built out of PHY, MAC and

RLC as for the control plane. The same basic stack is used for the user plane. • user data stream : The user data streams are generated by the applications using

the circuit switched core network services (switched channels). These data streams are directly input to the RLC.

• ATM: The transport system for the Iu interface between UTRAN and CN is again

ATM. • AAL 2 : To provide a circuit switched like transport bearer on Iu, the AAL 2 protocol

is used. This adaptation layer provides a bearer channel (virtual channel of AAL type 2) with certain QoS guarantees. Additionally the any AAL 2 virtual channel includes time stamps in the transport frames. This allows synchronization and timing control between sender and receiver.

• Iu User Plane protocol (Iu UP) : The Iu User Plane protocol is on top of AAL2. This

protocol can provide different stages of user data stream support. So the Iu UP protocol can perform backward error correction, data rate controlling and can be used to optimize the buffer sizes for transmission to minimize the delay jitter. This protocol transports the user data and can create own signaling messages. The signaling messages of Iu UP protocols are transmitted as in-band signaling within the AAL 2 virtual channels used for the user data.



RNS

MSC

PHY

MAC

RLC

PHY

MAC

RLC

Relay

SAAL / AAL5

MTP 3 B

SCCP

RANAP

ATM

Layer 1

MM, CC, SS, SMS

UE RNS MSC

PHY

MAC

RLC

PHY

MAC

RLC

AAL 2

ATM

Layer 1

Relay

AAL 2

Iu UP

ATM

Layer 1

UE

Iu UP

User datastreams

User datastreams

figure 11 User plane protocols between UE-UTRAN-CN for CS domain.



3.2 Protocols UE-UTRAN-CN for PS Domain For packet switched service there are different procedures. So there is a need for special protocols for packet switched services. In fact these special protocols are on the higher layers, so that the lower layer will prove to be the same as for the circuit switched services. The packet switched control plane consists of: • PHY, MAC, RLC, RRC : The transport and access stratum protocols on the air

interface are the same for PS and CS. UMTS has been designed to support both types of services, so that there are no special protocols.

• ATM, AAL 5, SAAL, MTP 3B : Also the transport and access stratum on the Iu-PS

interface is similar to the Iu interface towards the MSC. • SCCP, RANAP : SCCP and RANAP are the same as for CS. The SCCP is mainly

used to set up a signaling connection to the SGSN in the core network. RANAP handles all signaling transport and access related tasks.

• NAS protocols : The only special protocols for the packet switched service are the

non access stratum protocols. Because there are essential differences how to handle a packet switched service request, the PS core network has its own mobility management GMM (GPRS Mobility Management). To set up a data session the SM (Session Management) protocol is used. The SMS is in fact the same as for CS.



RNS SGSN

PHY

MAC

RLC

RRC

GMM, SM, SMS

PHY

MAC

RLC

RRC

SAAL / AAL5

MTP 3 B

SCCP

RANAP

ATM

Layer 1

Relay

SAAL / AAL5

MTP 3 B

SCCP

RANAP

ATM

Layer 1

GMM, SM, SMS

UE

SAAL : Signalling ATM Adaptation LayerATM : Asynchronous Transfer ModeAAL 5 : ATM Adaptation Layer type 5MTP 3B : Message Transfer Part level 3 for Broadband

figure 12 Control protocols between UE-UTRAN-CN for PS domain.



In contrast to the control planes, that look very similar for PS and CS, the user plane has important differences. This is clear, because circuit switched data needs other transport mechanisms (switching) as packet switched data (routing). In detail there are the following protocols involved: • user data : The user data for packet switched services is usually dedicated to

external packet data networks (e.g. internet). These external data network have their own special network protocols (e.g. TCP/IP). When a UMTS user wants to be connected with such an external network, the UE has to send packets of this special network protocol, for the UMTS network this is only data. But because of its special role, the network protocol of the external network is called Packet Data Protocol (PDP). It is the task of the UMTS network to provide a tunnel (PDP context) for transparent transport of the PDP packets.

• Packet Data Convergence Protocol (PDCP) : This protocol performs header

compression of the PDP packet header. This shall increase the efficiency of the air interface usage.

• RLC, MAC, PHY : The transport layers are the same as for control plane. • GPRS Tunneling Protocol User plane (GTP-U) : The PDP packets are transported

in a GTP-U frame on Iu. GTP-U organizes addressing and identification of the originator and destination of the data between RNC and SGSN.

• UDP / IP: To route from RNC to SGSN the standard UDP / IP protocol stack is used.

This is a connection less, unreliable transport service. In principle only routing is performed with UDP / IP.

• AAL 5 / ATM : The UDP / IP datagrammes (packets) are transmitted on ATM using

the adaptation layer 5.



RNS SGSN

PHY

MAC

RLC

PDCP

Application,PDP

PHY

MAC

RLC

PDCP

AAL5

IP

UDP

GTP - U

ATM

Layer 1

Relay

AAL5

IP

UDP

GTP – U

ATM

Layer 1

UE

figure 13 User plane protocols between UE-UTRAN-CN for PS domain.



4 UTRAN Protocol Model and Protocols



4.1 UTRAN Protocol Model for Iu Interfaces The transport system used within UTRAN is ATM. There is an essential difference between the usage of ATM and the use of PCM lines in a GSM – BSS. ATM supports different types of bearer service labeled AAL type 1, AAL type 2, AAL type 3/4 and AAL type 5. In UTRAN only AAL type 2 and AAL type 5 are used. Bearers of AAL type 2 have to be set up with explicit signaling. This means before a AAL type 2 virtual channel can be used, there has to be signaling between the corresponding ATM switches. This behavior results in a new protocol model, where protocols for user bearer set up and release occur. The model is built out of two layers: • Transport Network Layer : The transport network layer consists of all protocols

used for the transport network solution. This includes the physical layer and its transport frame layer, also the bearer service protocols are included.

• Radio Network Layer : The radio network layer contains all protocols, that are

specific to the radio access and transport stratum. Also all other data streams, to be transported through UTRAN, belong to this layer.

This division into layers is also called horizontal structure. There is also a vertical structure. The elements of this vertical structure are planes . A plane is principle nothing else than a protocol stack. More than one plane can coexist next to each other. In detail there are the following planes: • Control Plane : The control plane consists of all application protocols that are used

for radio network controlling. To transport the messages of an application protocol, one or several signaling bearers, provided by the transport network, are necessary.

• User Plane : The user plane supports the data streams for user data. Therefore the

data streams are packed into frame protocols. These frame protocols will be transmitted via data bearers. In contrast to the signaling bearers of the control plane, the data bearers can require to be set up with explicit signaling.

• Transport Network Control Plane : The transport network control plane contains

the ALCAP (Access Link Control Application Part). The ALCAP protocols are used to set up and release the data bearers of the user plane. Also ALCAP messages require a signaling bearer for transmission. It is not necessary to use the ALCAP for



all data bearers. Especially the transport network control plane is not necessary, when pre-configured bearers only are used.

Transport Frame and Physical Layer

SignallingBearer

SignallingBearer

DataBearer

ALCAP

ApplicationProtocols

DataStreams

ControlPlane

UserPlane

Transport NetworkControl Plane

TransportNetwork

Layer

RadioNetwork

Layer

figure 14 UTRAN protocol model for Iu, Iub and Iur interfaces.



The use of the ALCAP is dependent on the type of bearer to be used. The signaling bearers are usually pre-configured. This means there is no dynamical set up and release for signaling bearers. Data bearers have to be set up and released with ALCAP, when they are not pre-configured. In this case the set up runs in the following manner: 1. The set up or release of a bearer is always controlled by an application protocol.

But to avoid the restriction to a single transport system, the application protocols shall not be specific to a certain transport solution. Therefore the application protocol can control the bearer via abstract parameters (QoS parameters) only. This principle is the same as for BICC (Bearer Independent Call Control). To trigger the set up of a bearer first the application protocol starts a procedure to the destination node.

2. After the application protocol triggered the procedure, the ALCAP, that is specific to

the bearer to be set up, performs all necessary procedures to configure the bearer. 3. When the application part receives the notification of a successful bearer set up, the

application protocol procedure can be finished, and the application can be informed to start the data stream transmission.



Transport Frame and Physical Layer

SignallingBearer

SignallingBearer

DataBearer

ALCAP

ApplicationProtocols

DataStreams

Application Protocol : Bearer Setup Request

ALCAP : Bearer Establishment Request

ALCAP : Bearer Establishment Confirmed

Application Protocol : Bearer Setup Complete

1a

1b

2a

2c

2b

3a

3b

NetworkElement A

NetworkElement B

figure 15 Inter- working between control, network control and user plane in UTRAN protocol model.



4.2 Iur Interface Protocols between S-RNC and D-RNC The discussed protocol model is applied to the UTRAN interfaces Iur, Iub and Iu. The application protocol on the Iur interface between two RNCs is the RNSAP (Radio Network Subsystem Application Part) . All in all there are the following protocols on the control plane: • RNSAP (Radio Network Subs ystem Application Part) : The RNSAP protocol is

responsible for the communication between S-RNC and D-RNC. This covers resource allocation for a UE in a cell of the D-RNC, soft handover procedures and procedures to transfer the S-RNC functionality to a D-RNC (SRNS relocation).

• SCCP (Signaling Conn ection Control Part) : The SCCP is used to set up a

signaling connection between S-RNC and D-RNC for the UE. This means the S-RNC sets up one SCCP signaling connection for every D-RNC and UE. The signaling connection will be used for fast identification of the UE in signaling messages.

• MTP 3B, SAAL, AAL 5, ATM : These protocols form the signaling bearer used for

the RNSAP protocol messages. The user plane of the Iur interface has the tasks to transport uplink and downlink data for the UE connected to a drift RNC. This tasks requires the following protocols: • Frame Protocols : The data to and from the UE will be encapsulated into a frame.

These frames are defined by so called frame protocols. These frame protocols also allow traffic management with in-band signaling.

• AAL 2, ATM : The frame protocols, that encapsulate the UE data, are transported

over AAL 2 virtual channels of ATM. These AAL 2 virtual channels have to be set up first.

Because the AAL 2 virtual channels require a dynamical set up, there is a need for a transport network control plane. This plane contains the following protocols: • AAL type 2 signaling protocol : This protocol is an ITU-T protocol, used to set up,

release and modify AAL 2 virtual channels. This is the Iur ALCAP.



• STC, MTP 3B, SAAL, AAL 5, ATM : These protocols provide the signaling bearer for the AAL type 2 signaling protocol. The STC (Signaling Transport Converter) provides functionality for congestion handling and load control. The protocol suite MTP 3B, SAAL, AAL5 and ATM can be shared with the signaling bearer of RNSAP of the control plane.

The physical layer used for to transport the ATM cells on Iur is not specified. It is up to the operator to choose an appropriate physical transmission system (e.g. STM-1, STM-4 or SONET).

Physical Layer

ATM

AAL 5 AAL 5 AAL 2

SAAL

MTP 3-B

SCCP

SAAL

MTP 3-B

STC

AAL type 2 SP

RNSAP Frame Protocols

figure 16 Iur protocol stack.



4.3 Iub Interface Protocols between Node B and C-RNC

The second UTRAN internal interface is the Iub interface between Node B and its controlling RNC. Also on this interface ATM with AAL 2 virtual channels is used. Therefore the transport network control plane is necessary again. The control plane of the Iub interface contains the following protocols: • NBAP (Node B Application Part) : The NBAP protocol is the application protocol of

the Iub interface. It organizes all controlling tasks between RNC and Node B (e.g. code allocation, transceiver configuration).

• SAAL, AAL 5, ATM : These protocols constitute the signaling bearer for the NBAP

messages. The user plane of the Iub interface has to transfer the downlink and uplink data to and from the UE. Therefore different frames are defined in the same way as on the Iur interface. In detail the user plane consists of: • Frame Protocols : The Frame Protocols encapsulate the UE data (down- and

uplink) on the Iub interface. • AAL 2, ATM : The frame protocol packets are transmitted via Iub using AAL 2 virtual

channels. So AAL 2, ATM form the data bearer on the Iub interface. As on the Iur interface the Iub interface uses AAL 2 virtual channels for data stream transport. This means that the transport network control plane is necessary for set up, release and modification of AAL 2 virtual channels. The Iub transport network control plane looks similar to Iur: • AAL type 2 signaling protocol : The AAL type 2 SP provides the messages and

function to set up, release and modify AAL 2 virtual channels. • STC, SAAL, AAL 5, ATM : The STC (Signaling Transport Converter), SAAL, AAL 5

and ATM provide the signaling bearer for the AAL type 2 signaling protocol. (Note: The STC here is different to the STC on Iur.)



The physical layer is not standardized. It is up to the operator and vendor to choose an appropriate physical transmission system.

Physical Layer

ATM

AAL 5 AAL 5 AAL 2

SAAL SAAL

STC

AAL type 2 SP

NBAP Frame Protocols

figure 17 Iub interface protocol stack between controlling RNC and Node B.



4.4 Iu-CS Interface Protocols between S-RNC and MSC

In the last section the protocol model for Iur and Iub interface has been discussed. The Iu interface, connecting UTRAN and CN, is also built according to this model. But there are differences between Iu-CS towards the CS- core network domain and Iu-PS towards the PS- core network domain. The control plane for Iu-CS is formed out of the following protocols: • RANAP (Radio Access Network Application Part) : The RANAP protocol is

responsible for all access and signaling transport related tasks. It is the application protocol of the Iu-CS interface.

• SCCP (Signaling Conn ection Control Part) : The SCCP is used to set up signaling

connection between RNC and MSC. There will be one and only one SCCP connection UTRAN-MSC for every UE using circuit switched services.

• MTP 3B, SAAL, AAL 5, ATM : These protocols provide the signaling bearer for

RANAP/SCCP messages. The user plane on Iu-CS has to support the transfer of real time circuit switched data streams. Therefore the Iu-CS user plane has the following protocols: • Iu UP (User Plane) protocol : The Iu UP protocol is used to provide additional

support functions for CS data streams on Iu. These functions can be : timing control, data rate control, backward error correction.

• AAL 2, ATM : For the data bearers to transport the data streams the AAL 2 virtual

channels are used. Again the transport network control plane is necessary, because AAL 2 virtual channels need to be set up and released. So the protocol suite on the transport network control plane is the already known stack, consisting of: • AAL type 2 signaling protocol : Used to set up, modify and release AAL 2 virtual

channels.



• STC, MTP 3B, SAAL, AAL 5, ATM : These protocols provide the signaling bearer for

the AAL type 2 signaling protocol messages. The physical layer is not standardized.

Physical Layer

ATM

AAL 5 AAL 5 AAL 2

SAAL

MTP 3-B

SCCP

SAAL

MTP 3-B

STC

AAL type 2 SP

RANAP Iu UP protocol

figure 18 Iu-CS protocol mode l between serving RNC and MSC.



4.5 Iu-PS Interface Protocols between S-RNC and SGSN

The Iu-PS interface is the interface between RNC and SGSN. The control plane of Iu-PS is similar to the Iu-CS control plane. It consists of: • RANAP : The application protocol for Iu-CS and Iu-PS. • SCCP: Provides signaling connection on Iu-PS. There will be one and only one

SCCP connection between RNC and SGSN for every UE using packet switched service. SCCP connections on Iu-PS and Iu-CS do not affect each other.

• MTP 3B, SAAL, AAL5, ATM : The signaling bearer for SCCP/RANAP. The user plane on Iu-PS is completely different to the user plane of Iu-CS. This is because the traffic to and from SGSN is packet switched, so routing layer are necessary. The UTRAN provides the following protocols on the Iu-PS user plane : • Iu UP protocol : As for Iu-CS the Iu UP protocol can provide additional support

functions for the data stream. In the moment (2001) the packet switched services do not use this protocol.

• GTP-U (GPRS Tunneling Protocol - User plane) : GTP-U provides a frame for the

user data to be transported. In a GTP-U frame UE identifiers (IMSI) and other reference number and sequence numbers are contained.

• UDP / IP: The UDP / IP protocol suite is used as network layer between RNC and

SGSN. The main task of these protocols is to route from RNC to SGSN and vice versa.

• AAL 5, ATM : The ATM adaptation layer of type 5 (connection less, variable bit rate,

no synchronization support) is used as bearer for the packets of IP / UDP / GTP-U. The AAL 5 virtual channels do not need to be set up in a dynamical manner. Rather the operator is expected to pre-configure the AAL 5 bearer to be used for the packet transfer. Therefore on Iu-PS there is no need for a transport network control plane, no



bearer set up with explicit signaling is necessary.

Physical Layer

ATM

AAL 5

IP

AAL 5

SAAL

MTP 3-B

SCCP

UDP

GTP-U

RANAP Iu UP protocol

NoTransportNetworkControlPlane

figure 19 Iu-PS protocol stack between serving RNC and SGSN.



5 Protocol Standardization



5.1 Protocol Specifications UMTS and UTRAN is specified by 3GPP (third Generation Partnership Project), which is a project group of ETSI (European Telecommunication Standards Institute). All protocols will be standardized in a set of technical specifications TS available from 3GPP (ftp://ftp.3GPP.org/Specs) or from ETSI – CD – ROMs. For the UTRAN related protocols the 3GPP working group RAN (Radio Access Network) is responsible. The following set of recommendations are interesting for this course :

Topic

3GPP recommendation number

UTRAN General overview TS 25.401 WCDMA physics TS 25.2xx Radio interface protocols TS 25.3xx Iu interface TS 25.41x Iur interface TS 25.42x Iub interface TS 25.43x The non access stratum (NAS) protocols GMM, MM, CC and SM can be found in the recommendation TS 24.008. The recommendation TS 24.007 contains an overview about the protocol stack and the inter-working between NAS protocols and the radio protocols.



Menu

UE

UTRAN CN

Radio ProtocolsTS 25.3xx

Iu InterfaceTS 25.41x

Iur InterfaceTS 25.42x

Iub InterfaceTS 25.43x

NAS protocols (GMM, SM, MM, CC)TS 24.007, TS 24.008

figure 20 Radio and NAS protocol specifications and specification series.

II. Radio Protocol Architecture and Idle Mode Tasks


Radio Protocol Architecture and Idle Mode Tasks

Module Objectives:

• Basic Principles of UTRAN Radio Protocol Model in UE and UTRAN, • WCDMA Overview,

• Radio Bearers,

• Logical Channels,

• Transport Channels,

• Physical Channels,

• UE Procedures in Idle Mode.



1 Principles of UTRAN Radio Interface Design



1.1 Radio Protocol Model in UE and UTRAN The protocol structure on the air interface is built according to a general radio protocol suite model provided by ITU-R M.1035. This model proposes a three layered structure with the following layers: • Physical Layer : The physical layer deals with the radio interface physics. This

means it provides the service to transmit bits over radio waves. Because every radio technology has its special problems, the physical layer handles things like channel coding (forward error correction), interleaving (uniform distribution of bit errors), power control, handling of propagation delays (timing advance) and synchronization. Every data transport service, the physical layer offers to higher layers, is denoted as transport channel. A transport channel describes the properties of the service (data rate, channel coding,…).

• Layer 2 (Access & Data Link) : The layer 2 is concerned with the access to the

radio media and provides data links between two entities using the radio interface. The access to the radio interface covers two tasks: multiplexing of different UE to the radio waves and multiplexing of several data streams of one UE. The data links handling typically consists of services of different reliability classes (sequence order guarantee, backward error correction, unreliable transport). The transport services, layer 2 provides to the higher layers, are called radio bearers (One UE supports up to 32 radio bearers). The radio bearers have to be mapped by the layer 2 to the transport channels provided by the physical layer.

• Layer 3 (Application & Control) : On top of layer 2 there are the control protocols

for access and non access control. Both protocol classes use signaling bearers of the layer 2. Also the user data streams are located in the layer 3. They use special bearer services (radio bearers) of layer 2.



Physical Layer (WCDMA)

Access & Data Link Layer

Signalling Bearer Data Bearer

Control Protocol(Access Stratum)

Control Protocol(Non Access Stratum)

User Data Streams(Non Access Stratum)

Transport Channels

Radio Bearer

figure 1 General radio protocol architecture defined by ITU-R.



For the UMTS radio interface using WCDMA the physical layer is implemented in one protocol. This protocol provides all necessary tasks to transmit a bit over the radio wave. This includes tasks like forward error correction (channel coding), bit error distribution (interleaving), error detection (cyclic redundancy check), closed loop power control, synchronization and timing advance control (only for TDD). The physical layer offers its services to the higher layer by so called transport channels . A transport channel is the mean with which properties (data rate, channel coding) bits are transmitted over the air. These transport channels are accessed by the MAC (media access control) protocols. This protocol belongs to the layer 2 and has two general tasks: • multiplexing of several UE to the shared radio resource (e.g. random access control,

multiplexing of UEs to shared channels) • multiplexing of logical channels within one UE to transport channels (logical

channels describe the type of information to be transmitted, they are the services offered by MAC to higher layers).

As already mentioned, the MAC protocol offers its transport services via logical channels . The information to be transmitted is mapped onto logical channels according to the type of information (e.g. dedicated control information, dedicated data, common control information). The layer contains now several protocols to enhance the logical channel service offered by MAC. The first protocol of this is the RLC (radio link control) . The RLC protocol creates for every logical channel an instance of an RLC protocol. Such an instance is able to provide three different reliability services for the corresponding logical channel. These services are: • transparent mode : The RLC protocol instance provides no further reliability. • unacknowledged mode : The RLC protocol instance provides sequence order

control functionality. • acknowledged mode : The RLC protocol instance performs backward error

correction. The two protocols PDCP (packet data convergence protocol) and BMC (broadcast /



multicast protocol) also belong to the layer 2 to enhance the data bearers for user data. The PDCP protocol is used to perform compression of user data (e.g. IP header compression). The BMC protocol supports cell broadcasting and multicast broadcasting services. The only control protocol for the access stratum is RRC (radio resource control) . It contains all procedures to control, modify and release radio bearers. The RRC messages use radio bearer services offered by layer 2 for transport.

Physical Layer (PHY)

Medium Access Control (MAC)

RLC RLC RLC RLC RLC RLC RLC RLC. . .

Radio Resource Control(RRC)

Logical Channels

Transport Channels

PDCP PDCP BMC

Radio Bearers

NAS signalling protocols NAS: user data streams

Layer 2

Layer 1

Layer 3AS

Layer 3NAS

Radio Link Control (RLC)

figure 2 UTRAN radio protocol architecture.



In contrast to the protocol model used within UTRAN and on the Iu interface there is no ALCAP (access link control application part) protocol for the radio interface, although all the radio bearers require a dynamic set up. The reason is, that the RRC protocol provides all function for the physical set up of radio bearers. That requires that the RRC protocol can directly control all lower layers, that are responsible for bearer service provisioning. So there are the following inter-layer interfaces used for bearer control: • RRC – Physical Layer : The RRC uses this interface to control the physical layer

directly. This includes control procedures for power control and physical channel (radio) set up. The physical layer can sent measurement reports and synchronization indications to the RRC protocol.

• RRC - MAC : The RRC will configure the transport channels (e.g. data rate, channel

coding) via this link. A special feature the RRC has to configure in the MAC is the multiplexing of the logical channels onto transport channels (Quality of Service problem). The MAC protocol can send traffic measurement to the RRC using this interface.

• RRC – RLC : When a radio bearer is set up, a RLC protocol instance provides one

of three reliability levels, already mentioned before. The RRC protocol has to configure the RLC protocol instance according to the wanted reliability before the radio bearer can be used.

• RRC – PDCP : When a radio bearer for packet switched user data is needed, the

RRC protocol can insert a PDCP protocol instance in the radio bearer. The PDCP protocol will then perform compression / de-compression of the header information in the packet switched data (e.g. IP header compression). The RRC protocol has to specify the type of compression.

• RRC – BMC : When a cell broadcast or multicast service shall be used, the RRC

protocol will include a BMC protocol instance in the radio bearer. The RRC protocol has to configure the BMC protocol.





RLC RLC RLC


Logical Channels

Transport Channels

PDCP BMC

Radio Bearers

RLC

figure 3 Inter-layer control paths in the UTRAN protocol model.



1.2 WCDMA Physics – An Overview The UTRAN radio interface uses DS-CDMA (direct sequence code division multiple access) . Within UMTS release 3/release 1999 this interface comes in two different versions: • FDD (frequency division duplex) : Uplink and downlink transmission are in

separated frequency bands. This requires a pair of frequency bands for the radio interface.

• TDD (time division duplex) : Uplink and downlink transmission are time multiplexed

onto the same frequency band. This requires only one frequency band for the radio interface.

A cell can support FDD, TDD or both. A frequency channel of UMTS has a radio channel bandwidth of 5 MHz for FDD and TDD. To uniquely address every radio channel a so called UARFCN (UMTS Absolute Radio Frequency Channel Number) is assigned. Every UMTS radio channel of TDD and FDD has to have a center frequency which proves to be an integer multiple of 200 kHz. Therefore the IMT 2000 standard defines the UARFCN to be

UARFCN = 5 * ( Fcenter / MHz ).

The center frequency can have a range of 0.0 MHz ≤ Fcenter ≤ 3276.6 MHz. This definition is absolute, so it will be easily possible to integrate new frequency ranges into UMTS. There is especially no special numbering of uplink and downlink channels for the FDD mode. Which uplink – downlink frequency separation is used depends on UTRAN and on the UE radio capabilities. Therefore the UE sends the supported duplex frequencies after the first access to the UTRAN to the RNC. The RNC then has to choose an appropriate duplex frequency if FDD mode will be used.



200 kHz

... ...

Fcentre =N*200 kHZ

UARFCN = 5 * (Fcentre )

figure 4 Absolute radio frequency channel numbering used in UTRAN.



FDD and TDD mode of UTRAN use QPSK (Quaternary Pulse Shift Keying) for transmission. The data streams before modulation (chip sequence) are combined to a complex valued stream. In the modulator this stream is separated in the real and in the imaginary part. The real part is input to pulse shaping filter (cosine roll off filter) and modulated onto the cosine of the radio wave. The imaginary part also runs through a pulse shaping filter and is then modulated onto the sine of the radio wave. Both modulated components are summed and amplified for transmission.



cos

SplitReal &

Imaginarypart

Complex valuedData stream

Real Part

ImaginaryPart

PulseShaping

PulseShaping

-sin

RF

I (real part)

Q (imaginary part)QPSK

figure 5 Modulation scheme used in UTRAN.



UTRAN uses a direct sequence CDMA approach. This means that every bit to be transmitted is first coded into a chip sequence. Typically the chip sequence requires a higher bandwidth, so that also the term spread spectrum technology can be applied. Within UTRAN a two step mechanism for the spreading of a bit stream is used. The two steps are : • spreading : Spreading means the coding of a bit into several chips. The chip

sequence used to encode a bit is called channelisation code . Channelisation codes are taken from the so called OVSF (orthogonal variable spreading factor) code tree. This code tree supports spreading factors that are powers of 2 (e.g. 2, 4, 8, 16, 32, 64, 256, 512). In UMTS the channelisation codes are used to separate data streams (physical channels) within one source (cell, UE).

• scrambling : After a bit stream is spread with a channelisation code, it can be

combined with other spread sequences using perfect orthogonal codes relative to each other. To separate the different UEs and cells, the combined chip sequences of every entity are scrambled by a entity specific scrambling code . This means the scrambling codes separate UEs or cells. In contrast to the channelisation codes the scrambling codes represent pseudo noise sequences, that are not perfect orthogonal, but are statistically independent and have good cross correlation properties with each other.

Typically there will be power factors applied to each spread sequence. This is because when a higher spreading factor is used, less power is necessary for the transmission. How the real data streams are transformed into a complex stream, needed for modulation, is different in UE and Node B. In the UE some streams are assigned to the real part, other streams to the imaginary part. In a cell every stream is transmitted in parallel on real and imaginary part. This is simply done by assigning all chips with even number to the real part, the chips with odd number are assigned to the imaginary part (serial to parallel transformation).



Σ

Σ

ccI,1

ccQ,

1

ccI,2

ccQ,

2

βI,1

βI,2

βQ,1

βQ,2

j

to QPSKmodulation

Spreading and Scrambling in UE – Uplink

sc

BIT

STREAMS

cc : channelisation code

sc : scrambling code

j : imaginary unit

β : power factors

figure 6 Spreading and scrambling in UE for uplink transmission.



--intentionally left blank--



Σto QPSKmodulation

Spreading and Scrambling in the cell – Downlink

cc1

cc1

β1

j

sc

BIT

STREAMS

SerialTo

Parallel(1->2)

cck

cck

βk

j

sc

SerialTo

Parallel(1->2)

.

.

.

SynchronisationChannels

figure 7 Spreading and scrambling in Node B for downlink transmission.



The channelisation codes of UTRAN are defined as so called OVSF (orthogonal, variable spreading factor) codes. These OVSF codes provide a complete set of perfect orthogonal spreading codes for the spreading factors 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, … . This means the spreading factor is a power of 2. The OVSF codes are arranged in a code tree. This tree represents the spreading factors in the horizontal line. For a spreading factor SF there are exactly SF orthogonal codes, arranged in a vertical line. These k codes are labeled from 0 to SF-1 according to their spreading factor SF. With this a channelisation code can be selected with two values : spreading factor and code number : cch, SF, k with 0 ≤ k ≤ SF-1. A channelisation code consists of a sequence of +1 and –1 of length SF. All codes having the same SF are orthogonal. In general codes that are located in different trees are orthogonal. This allows to use streams with different spreading factors and hence with different data rates. The use of a channelisation code blocks all codes that come after this code in the same tree. But because of the use of scrambling codes, this blocking is valid within one entity (e.g. within one UE or within one cell).



Cch, 1, 0

Cch, 2, 0

(1)

(11)

Cch, 2, 1

(1-1)

Cch, 4, 0

(1111)

Cch, 4, 1

(11-1-1)

Cch, 4, 2

(1-11-1)

Cch, 4,3

(1-1-11)

. . .

SF = 1 SF = 2 SF = 4 SF = 8 512

figure 8 Tree of orthogonal channelisation codes used in UTRAN



1.3 Logical Channels The MAC (media access control) has the task to multiplex different data streams coming from different radio bearers to the same physical interface, means to the same physical layer. For this task the MAC layer offers higher layers transport services according to the type of information to be transported. Therefore these services are divided into so called logical channels . A logical channel describes the type of information transmitted on the radio bearer. According to the general protocol model, that is divided into a control plane and an user plane, there are two categories of logical channels: • control channels (CCH) : Control channels transport data to and from the control

plane. So typically the information carried over control channels consists of control protocol messages (access and non-access stratum).

• traffic channels (TCH) : Traffic channels are used to convey user data to and from

the user plane. The information within TCHs are the frames and messages from the user plane protocols and the user data streams itself.

The data of the logical channels are input and output to/from MAC in the direction of the RLC protocol instances. As one can see, every radio bearer running through a RLC instance is assigned a logical channel type. The MAC layer multiplexes and de-multiplexes these logical channels to/from transport channels, which prove to be the services offered by the physical layer. It is the task of the RRC protocol to configure the assignment of radio bearers to physical channels and to configure the multiplexing onto the transport channels. An important note is, that the MAC handles all traffic related control activities by the multiplexing of logical onto transport channels. Therefore a radio bearer that is assigned to a certain logical channels can get a priority by the RRC protocol. This priority shall be used by MAC for the data scheduling.






RRC

Control Channels

Transport Channels

PDCP PDCP BMC

Radio Bearers

NAS signaling protocols NAS: user data streams

Traffic ChannelsLogical

channels

figure 9 Logical channel categories and their relation to the UTRAN radio protocols.



The logical channels are defined by the following logical channel types, where every logical channel type is either a control channel CCH, or a traffic channel TCH, but never both. The traffic channels TCH are used for the user plane information transport. The following logical channel types are defined: • dedicated traffic channel (DTCH) : Dedicated traffic channels is an unidirectional

point-to-point traffic channel, this means it is dedicated to a single UE. DTCH can exist in uplink and downlink.

• common traffic channel (CTCH) : In contrast to a DTCH a common traffic channels

is point-to-multipoint and only downlink (so it is also unidirectional). This means, a CTCH is used by the network (cell) to transfer user plane information to UEs. Several UEs can listen to one CTCH, everyone of these UE has to pick out its dedicated data. This requires an explicit addressing. Note that it is possible to transmit data to a group or UEs or a single UE.

The control plane information consists of access and non-access stratum protocol messages. This kind of information uses control channels CCH for transport. The following logical channel types are defined: • broadcast control channel (BCCH ) : A broadcast control channel exist in downlink

only, every cell has such a BCCH. It is used by the cell to convey general system information to the UEs camped on this cell.

• paging control channel (PCCH) : As the BCCH also the paging control channels

are downlink only. This channels is used, when the network does not know the location cell of an UE or the UE is in sleep mode (UE has to be woken up).

• common control channel (CCCH) : A common control channel is bi-directional

channel, commonly used by several UE that have no connection at the moment. Its main use is for radio access to the first or a new cell.

• dedicated control channel (DCCH) : A dedicated control channel is a point-to-point,

bi-directional channel. It is used to transport control data dedicated to a single UE. A DCCH is normally established after the radio access.

• shared channel control channel (SHCCH) : This channels exists for TDD mode

only. It is used for general control information when shared physical resources are



used.

Control Channels Traffic Channels

Logical Channels

BCCH

PCCH

CCCH

DCCH

SHCCH

CTCH

DTCH

downlink, dedicated

uplink, dedicated

downlink, shared

uplink, shared

figure 10 Logical channel types used in UTRAN.



1.4 Transport Channels The logical channels, discussed before, describe the type of information that is transmitted. The transport channels describe the transport services provided by the physical layer. This means a transport channels is the means, how data of the logical channels is carried over the air interface. Like the logical channels the transport channels come in different types. These types belong to one of the following two classes: • common transport channels : Common transport channels indicated shared

resources. This means the information of several UEs will be multiplexed onto the air interface. This implies, that an explicit addressing is necessary, when data is sent on a common transport channel. It is a task of MAC to provide the needed addressing information (c-RNTI or u-RNTI).

• dedicated transport channels : In contrast to a common transport channel, a

dedicated transport channel indicates the transfer of information on a physical resource dedicated to exactly one UE.

When a radio bearer set up happens (controlled by RRC protocol), the radio bearer to be established is assigned a logical channel. Additionally the RRC protocol will add one or several transport channels to this radio bearer, hence to the corresponding logical channel. It is up to MAC to select one of these transport channels for a concrete packet of data for transmission. This means it is also possible that data of a single radio bearer is sent on a common transport channel, the next time it is carried over a dedicated resource of a dedicated transport channel. With this knowledge also the role of MAC in the protocol stack of the UMTS air interface becomes clear. First MAC multiplexes different radio bearers (data streams) of a single UE, second MAC multiplexes several UE onto shared radio resources.



MAC

PHY

RLC

Logical Channel

CommonTrCH

Dedic.TrCH

UE 1

MAC

PHY

RLC

Logical Channel

CommonTrCH

Dedic.TrCH

UE 2

CommonPhysicalresource

Dedic.Physicalresource



cell

Radio bearer Radio bearer

Menu M enu

figure 11 Transport channel categories and their relation to the physical resource usage.



In the same way, the logical channels are divided into logical channel types, also the transport channels can be distinguished by their type. Each type is either a common or a dedicated transport channel. The common transport channels form the biggest group. Most of them are used to describe fixed transport characteristics of certain standard information flows. In detail there are the following common transport channel types: • random access channel (RACH) : Random access channels exist in the uplink

direction only. A RACH is used by the UEs to get radio access. It is a channel with collision risk and a very limited space for data transmission.

• forward access channel (FACH) : The FACH is the counterpart of the RACH. It

exists in the downlink only and is typically used by the network after random access of an UE to provide a radio bearer to this UE.

• broadcast channel (BCH) : The BCH is a pure downlink channel, that carries

BCCH information to the UEs. It has a very low and fixed bit rat. • paging channel (PCH) : Also the PCH exist in the downlink direction only. It is used

to transport the PCCH information to the UE. An UE having no ongoing transaction with the network shall listen to the PCH to receive PCCH information.

• downlink shared channel (DSCH) : The DSCH is downlink only. It is a common

transport channel for data and control information transmission to the UEs. A DSCH is always associated with one or several DCHs in the uplink.

• common packet channel (CPCH) : This channel is used for the FDD mode only. It

is an uplink channel, where several UEs are allowed to transmit dedicated user data (DTCH) and dedicated control information (DCCH). A CPCH is always associated with a DCH in the downlink direction (e.g. for power control)

• uplink shared channel (USCH) : This channel is available in TDD mode only. As

the name says, it is an uplink channel with the same tasks like CPCH for the FDD mode. The SHCCH information is tightly related to the USCH.

In the current implementations of UTRAN there is only one dedicated transport channel. • dedicated channel (DCH) :The DCH is a unidirectional channel, that can exist in

uplink or in downlink. It is dedicated to a single UE and can be used for dedicated



traffic (DTCH) and dedicated control (DCCH) information.

Common Channels Dedicated Channels

Transport Channels

BCH

PCH

RACH

FACH

DSCH

DCH

downlink, dedicated

uplink, dedicated

downlink, shared

uplink, sharedCPCH

USCH

figure 12 Transport channel types used in UTRAN.



1.5 Mapping of Logical onto Transport Channels The mapping of logical channel types onto transport channel types is task of MAC. There are restriction for this mapping defined. In the uplink the following logical / transport channel type combination are allowed (CPCH only for FDD; SHCCH, USCH only for TDD) : • CCCH : CCCH information can be transmitted on RACH. • DCCH : DCCH information can occur on RACH, CPCH / USCH, DCH. • DTCH : DTCH data can be sent on RACH, CPCH / USCH, DCH. • SHCCH : The data of a SHCCH can occur on RACH, USCH. In the downlink there are different channels and different type combination allowed : • BCCH : BCCH information can be sent on BCH, FACH. • PCCH : PCCH data is allowed on PCH only. • CCCH : CCCH information can use the FACH only. • DCCH : DCCH data for the downlink can occur on FACH, DSCH, DCH. • DTCH : DTCH information can be transmitted on FACH, DSCH, DCH. • CTCH : CTCH data can occur on FACH only. • SHCCH : The SHCCH occurs in TDD only and can be sent on FACH or DSCH.



BCCH PCCH CCCH DCCH DTCH CTCH SHCCH

BCH PCH FACH DSCH DCH

BCCH PCCH CCCH DCCH DTCH CTCH SHCCH

cell

MAC multiplexing

MAC demultiplexing

Menu

UE

figure 13 Mapping of downlink logical channels onto transport channels.



--intentionally left blank--



CCCH DCCH DTCH SHCCH

RACH CPCH USCH DCH

CCCH DCCH DTCH SHCCH

cell

MAC multiplexing

MAC demultiplexing

Menu

UE

figure 14 Mapping of uplink logical channels onto transport channels.



1.6 Transport Formats and Transport Format Sets The transport channels enable the MAC layer to sent and receive data to/from the physical layer. The data transfer between these two layer is organized by the transmission of so called transport blocks . A transport block is the basic data unit exchanged between MAC and the physical layer. Every transport block belongs to one and only one transport channel. But to have an optimized size of transmitted data unit (e.g. for error checks), several transport blocks can be transferred at the same time on the same transport channel between MAC and PHY. The set of all transport blocks exchanged at the same time on one transport channel is called transport block set . The transport blocks and transport block sets can have several characteristics, described by the following attributes:

• transport block size : This attribute specifies the number of bits in one transport block. All transport blocks within one transport block set have a fixed transport block size. Between different transport block sets (at different times) the size can change.

• transport block set size : This is the number of bits in a transport block set. It is

always an integer multiple of the transport block size of the transport blocks. In other words, this values is

(number of transport blocks) x (transport block size)

• transmission time interval (TTI) : This time value indicates the time interval between two subsequent transport block set transfers between MAC and PHY. It is equal to the periodicity at which the transport block sets are sent by the physical layer. This means the MAC delivers one transport block set every TTI. The TTI is always an integer multiple of the radio frame length (10 ms).

• error protection scheme : This attribute specifies the forward error check type

to be applied to every transport block of the transport block set. In UMTS – WCDMA there are at the moment the following types defined : turbo coding (rate 1/3), convolution coder (rate 1/2 or 1/3), no channel coding.

• size of CRC : Every transport block of a transport block set is error protected

with a CRC (cyclic redundancy check). This CRC can have different sizes (0, 8,



12, 16, 24 bits for CRC).

Transport Block

Transport Block

Transport Block

Transport Block

Transport BlockSet

Transport Block Size

TransportBlock

Set Size

MAC PHY

Transport Block Set

Transport Block Set

Transmission Time Interval

figure 15 Transport blocks and transport block sets.



The mentioned transport blocks are defined between MAC and the physical layer PHY. This holds exactly with respect to the UE. In UTRAN there is a little modification. This is because the physical layer PHY is terminated in the Node B, whereas MAC usually is placed in the serving RNC. Therefore in UTRAN the transport blocks are sent between Node B and serving RNC using an ATM AAL 2 virtual channel. In this channel the data of the corresponding transport channel is packed into a frame protocol and sent like user data.



Menu

UE Node B RNC

MAC

to/from RLCRadio bearers

MAC

to/from RLCRadio bearers

PHYFP/AAL2

ATM/L1PHYPHY

FP/AAL2

TB 1

TB 2

TB 3...

TB 3

TransportBlock Set

Physical Channel(TTI radio frames)

RELAY

Frame Protocolin AAL2 VC

TB 1

TB 2

TB 3...

TB 3

TransportBlock Set

figure 16 Transport of transport blocks on air interface and on Iub.



For an established transport channel different transport block and transport block set attributes can be used. When MAC sends a transport block to the physical layer it has to indicate, with which attributes the transport blocks shall be sent. The same is necessary, when the physical layers receives data and sends it to the MAC layer. For this purpose the so called transport format parameter set is used. This set consists of two general parts: • semi-static part : The parameters that belong to this part, are configured by the

RRC layer. These parameters are fixed for all transport block sets of the corresponding transport channel until the RRC reconfigures the parameters.

• dynamic part : The values of the parameters of the dynamic part can change from

transport block set to transport block set, it is up to the MAC to choose an appropriate set of parameters from the allowed values. Also the values of the dynamic part are configured by the RRC layer.

The individual parameters of the dynamic part are: • Transport Block Size, • Transport Block Set Size, The semi-static parameters are : • Transmission Time Interval,

• error correction scheme (no channel coding, convolution coder 1/2, convolution

coder 1/3, turbo coder 1/3), • size of CRC (0, 8, 12, 16, 24 bits). • static rate matching parameter (used by PHY to perform dynamic puncturing, when

the transport block set is too long for the radio frame). In the TDD mode the transmission time interval can be also in the dynamic part (optional feature). For the communication between MAC and PHY every transport format gets a unique transport format indicator . This indicator is only for internal use, so it will not be



further discussed here.

Semi-Static Part TTI

Channel Coding

CRC size

Rate matching

Dynamic Part TB size

TB set size

Transport FormatMAC

PHY

Transport Block

Set

TFI

TFI

Transport Block

Set

TFI: Transport Format Indicator

figure 17 Transport format and the associated parameters (FDD mode).



When a radio bearer is configured, there will be signaling exchange between UE and RNC. The responsible protocol is RRC. During the radio bearer configuration the MAC layers and physical layers in UE and network will be informed about the allowed transport formats for a certain transport channel. The information about the allowed formats will be contained in a so called transport format set , which is in fact a list of one or several transport formats. The only restriction is, that the semi-static parts of all transport formats in the set are the same. This means all allowed variations of transport formats concern the transport block size, the number of transport blocks in a set. (In TDD also the transmission time interval can be variable.) For the transmission of a transport block set, the MAC layer will choose one the indicated transport formats. It is important to note, that some combination of transport formats of different transport channels at the same time may be forbidden (e.g. because of limited maximum data rate or other UE capability restrictions).



Semi-Static Part

TTI

Channel Coding

CRC size

Rate matching

DynamicParts

TB size

TB set size

Transport Format Set

TB size

TB set size. . .

TransportFormatIndicator

TFI 1 TFI 2. . .

figure 18 Transport format combination.



1.6.1 Example for Usage of different Transport Formats Lets consider a transport channel that can be used with several data rates, but has a fixed frame size of 64 bits and a fixed delay requirement of 10 ms (on air interface). This leads possibly to the following dynamic parts in the form {transport block size, transport block set size} : • (a) {64 bits , 64 bits} • (b) {64 bits, 128 bits} (means two transport blocks), • (c) {64 bits, 192 bits} (means three transport blocks), • (d) {64 bits, 256 bits} (means four transport blocks). The transport channel shall require a convolution coder with rate 1/3 and the transmission time interval is fixed to 10 ms. We have already a channel coding, so lets assume, there is no need for an additional error check, means a CRC with 0 bits is to be applied: • {TTI : 10 ms, convolution coder 1/3, CRC 0 bits, rate matching parameter}. If the MAC layer wants to send data for this transport channel, it has to take the semi – static parameters and to select one of the four possible semi- static parameters (a) ,… (d). In the figure an example with sequence (a) (c) (c) (b) (c) (a) is shown.



TTI : 10 ms TTI : 10 ms TTI : 10 ms TTI : 10 ms TTI : 10 ms TTI : 10 ms

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block

Transport block Transport block

(a) (c) (c) (b) (c) (a)

6.4 kbps 19.2 kbps 19.2 kbps 12.8 kbps19.2 kbps 6.4 kbps

Transport format set :

- dynamic: {64,64}, {64,128}, {64,192}, {64,256}

- semi-static : {10 ms, convolution 1/3, no CRC, ...}

figure 19 ``Simultaneous´´ usage of different transport formats – example.



1.6.2 Transport Formats for various Transport Channels In the tables below the possible transport formats for the different transport channel types are shown.

figure 20 Possible transport form ats for BCH, PCH, FACH, RACH.

Attribute Values

BCH PCH FACH RACH


0 … 5000 bits 1 bit

granularity 246 bits 1 … 5000 bits

0 … 5000 bits

0 … 5000 bits Dynamic Part

Transport Block Set Size

0 … 200 000 bits 1 bit

granularity

246 bits 1 … 200 000

bits

0 … 200

000 bits

0 … 200 000 bits

Transmission Time Interval 10, 20, 40, 80

ms 20 ms

10 ms (FDD) 20 ms (TDD)

10, 20, 40, 80

ms

10, 20 ms (FDD)

10 ms (TDD) Type of channel coding

no coding turbo coding convolutional

coding

convolutional coding


no coding, turbo

coding, convol. coding


code rates 1/1, 1/2, 1/3 1/2 1/2

1/1, 1/2, 1/3

1/2

Semi-static Part

CRC size 0, 8, 12, 16,

24 bits 16 bits 0, 8, 12,16, 24

0, 8, 12,16,

24 0, 8, 12,16, 24



figure 21 Possible transport formats for CPCH, DCH, DSCH, USCH.

Attribute Values

CPCH DCH DSCH USCH


0 … 5000 bits 1 bit

granularity 0 … 5000 bits 0 … 5000 bits

0 … 5000 bits

0 … 5000 bits

Dynamic Part

Transport Block Set Size

0 … 200 000 bits 1 bit

granularity

0 … 200 000 bits

0 … 200 000 bits

0 … 200 000

bits

0 … 200 000

bits

Transmission Time Interval (optional, for TDD only) 10, 20, 40, 80

ms

not applicable -

( CPCH uses a

random access

principle)

10, 20, 40, 80 ms

( for TDD real-time data)

10, 20, 40, 80 ms

( for TDD real-time

data)

10, 20, 40, 80 ms ( for TDD real-time

data)

Transmission Time Interval

10, 20, 40, 80 ms

not applicable -

( CPCH uses a

random access

principle)

10, 20, 40, 80 ms

10, 20, 40, 80 ms

10, 20, 40, 80 ms

Type of channel coding


coding


coding


coding

no coding turbo cod.

convol. coding

no coding turbo cod.

convol. coding

code rates 1/1, 1/2, 1/3 1/1, 1/2, 1/3 1/1, 1/2, 1/3

1/1, 1/2, 1/3

1/1, 1/2, 1/3

Semi-static Part

CRC size 0, 8, 12, 16, 24 bits

0 0, 8, 12,16, 24

0, 8, 12, 16, 24

0, 8, 12, 16, 24



1.7 Physical Channels – An Overview On the air interface UTRAN uses a time hierarchical structure for organization purposes. This structure knows the following elements: • radio frame : A radio frame has a length of 10 ms in time, which corresponds to

38400 chips. Radio frames are numbered with a SFN (system frame number) . • slot : Every radio frame is further divided into 15 slots. These slots especially

represent the period for fast power control. Every slot has 25600 chips, so a slot has a duration of 666.7 µs.

• chip : The chip is the smallest information unit, that can be transmitted. As already

mentioned, UMTS uses QPSK. This means one channel can transmit two chips at one moment. The chip rate is 3.84 Mcps (Mega chips per second).

For the peer-to-peer communication of physical layers of different entities (cell – UE) the physical layer defines so called physical channels . In contrast to logical and transport channels, which are defined between different protocols in one entity, the physical channels are like protocol messages. Especially they are needed to provide data transmission for physical layer procedures, like power control or random access. Because of this tight relation between radio physics and the physical channels, there are differences for FDD and TDD mode. And one can easily imagine, that in future radio access technologies (e.g. HIPERLAN/2) there will be new physical channels definitions. The already discussed concepts of transport and logical channels shall be more or less independent of the physical channels, so that an exchange of the radio technology will be possible in future. Now the problem with independence is, that the RRC layer is responsible for the configuration of radio links, therefore the physical channels will have some common properties, which are: • carrier frequency (indicated by an UARFCN), • scrambling code , • channelisation code or spreading factor ,



• start / stop time (can also be infinite duration), • (on FDD uplink only) relative phase (e.g. transmission on I or Q branch). Additionally every physical channel gets a slot format definition, which indicates the number and meaning of bits to be transmitted on this physical channel.

radio frame radio frame radio frame

10 ms 10 ms = 38400 chips 10 ms

SFN = 4 SFN = 5 SFN = 6

Slot #1 Slot #2 Slot #3Slot #0 Slot #14. . .

10 ms2560 chips

Data

Pilot bits TFCI FBI TPC

DPDCH

DPCCH

DPDCH : DedicatedPhysical DataChannel

DPCCH : DedicatedPhysical ControlChannel

TFCI : Transport FormatCombination Ind.

FBI : Feedback Ind.

TPC : Transmit PowerCommand

figure 22 Radio frame architecture and slots on UTRAN radio interface; physical channels as slot formats.

muss heissen 2/3 ms



Because the physical layer can work in FDD or TDD mode, which are in fact two different radio interface solutions, there are separated physical channel definition for FDD and TDD. In FDD we have to distinguish three different types of physical channels : • physical channels carrying transport channel data , • physical channels for physical layer procedures, • physical signals carrying information of the physical layer. In detail we have the following: • DPCCH (Dedicated Physical Control Channel) and DPDCH (Dedicated Physical

Data Channel) : The DPDCH carries the DCH information. The DPCCH is associated to one or several DPDCHs and is used for physical layer signaling.

• PRACH (Physical Random Access Channel) : The PRACH is the channel that

transports the RACH information and organizes the random access. • PCPCH (Physical Common Packet Channel) : The CPCH is like the PRACH a

shared physical channel. Its use is to transport the CPCH transport channel. • P-CCPCH (Primary Common Control Physical Channel) : The P-CCPCH carries

the BCH and is transmitted in the entire cell. • S-CCPCH (Secondary Common C ontrol Physical Channel) : The S-CCPCH

supports FACH and PCH. • PDSCH (Physical Downlink Shared Channel) : The PDSCH is the physical

channel for the DSCH. • SCH (Synchroni zation Channel) : The SCH is not associated with a transport

channel. This channel is split into a P-SCH (Primary SCH) and a S-SCH (Secondary SCH). Both channels use a so called synchronization code. The UEs shall use the P-SCH to find a cell and synchronize to its slot timing. The S-SCH will be used by the UEs to find the begin of the radio frame and to determine the scrambling code group of the cell.



• CPICH (Common Pilot Channel) : The CPICH is also not associated with a transport channel. The CPICH consists of a predefined symbol sequence and is used by UEs to find out the scrambling code used in the cell.

• Physical Signals : The physical signals are physical channels that carry ternary

information (-1,0,+1). They are used in several physical layer procedures (e.g. random access, paging …).

DPDCH

PRACH

DPCCH

PCPCH

P-CCPCH

S-CCPCH

PDSCH

CPICH

SCH

Physical Signals

DCH

RACH

CPCH

BCH

FACH

PCH

DSCH

TrCH

PhCH

FDD

figure 23 Physical channels for FDD mode.



2 UE Procedures in Idle Mode



2.1 General on UE Idle Mode Procedures An UE is in idle mode, when there is no ongoing signaling or user data transaction with the network using a radio connection. In this state the UE has to perform three tasks : • cell selection / re-selection : Before a UE can access a network it has to have

knowledge about the network. This knowledge comes from the BCCH that is broadcasted in every cell of the network all the time. The task of the UE is first to find a suitable cell, then to listen to the BCCH of this cell. When the UE is moving away from the cell, radio signal strength and quality decrease. Therefore also when the UE has a suitable cell, the UE will search for better cells. The criteria to perform such a re-selection are typically formed by signal quality and strength.

• PLMN selection / re-selection : When the UE searches the complete frequency

spectrum for suitable cells, cells of several PLMN may be found. The access stratum protocols (RRC) have to report the available PLMN to the higher layer (GMM/MM). It is up to these non access stratum protocols to select one of the available PLMN. This includes the change of a PLMN, when certain preferred PLMN (e.g. home PLMN) are available.

• Location Registration : When the UE enters a new PLMN or a new region

(Location Area, Routing Area) of a PLMN, the new location has to be registered within the network. It is up to the radio protocol RRC to report the current location information (routing area identity, location area identity), received from the BCCH of the current cell, to the higher layers (non access stratum protocols GMM/MM). If these layers detect a change in the location, they will trigger the corresponding location registration procedure.



NAS control

BCCH RF measurement

LocationRegistrationResponse

LocationArea

changes

PLMNselected

PLMNavailable

PLMN selection /re-selection

cell selection /re-selection

location registration

cellcell

cell

periodic updatingattach / detach

automatic ormanual selections

figure 24 General overview of the idle mode tasks.



For the idle mode of an UE there is a special set of states defined. There are three idle mode states : • camped normally : In this state the UE listens to the common control channels of a

cell, that provides full service access for the UE. In detail the UE performs the following actions : UE listens to the PCH of the cell, UE monitors the relevant BCCH information, UE performs measurements of the current and of other cells (indicated in BCCH)

and triggers cell re-selection when necessary. • any cell selection : This state is entered, when no suitable cell with full service is

found, or after unsuccessful location registration procedures. In this state, the UE shall try to find an acceptable cell of any PLMN, with full or restricted service access rights. If such a cell is found, the state camped on any cell is entered.

• camped on any cell : In this state the UE is camped on a cell with restricted service

access only. This means the UE can use emergency services only. The following actions are done by the UE: UE listens to PCH of the cell, UE monitors relevant system information, UE performs measurements for cell re-selection, the UE shall try to find cells with full service access.

When the UE requests a network service (e.g. mobility management procedure, call, data session, short message), the UE will leave the idle mode and enters the connected mode state. For the state behavior in idle mode four functions are important: • initial cell selection : The UE searches the frequency spectrum supported by the

UE for suitable cells. • stored information cell selection : The UE will maintain a list with frequencies and

scrambling codes of the last used cells. If this list is available the search process can be accelerated.

• cell reselection evaluation process : This function evaluates the UE measurements to find the best new cell.

• cell selection when leaving idle mode : After connected mode the UE returns to idle mode. The functions determines the best cell for idle mode after the connection is released.



Stored infoCell selection

Campednormally

no suiable cell found Initial

Cell selection

1 no cell info storedcell info stored

new PLMN selected

2suitable cell found suitable cell found

Connectedmode

leave idlemode

cell selectionafter idle mode

return toidle mode

no suitablecell found

suitable cell found

Cell ReselectionEvaluation

triggersuitable

cell found

Any cellselection

no suitablecell foundlocation

registrationrejection

no suitablecell found no USIM

1

USIMinserted

Camped onany cell

Cell ReselectionEvaluation

trigger suitablecell found

2

acceptable cell found

suitablecell found

no acceptable cell found

cell selectionafter idle mode

return toidle mode Connected Mode

(limited services)

leave idlemode

acceptable cell found

no acceptable cell found

figure 25 State diagram to control the behavior of the UE in idle mode.



2.2 PLMN Selection and Reselection The PLMN selection is in fact controlled by NAS protocols (GMM, MM), the execution of the selection is done by the AS protocol (RRC). The initial PLMN selection (e.g. after switch on) is always controlled by the NAS protocols. An user interaction is usually only possible before the PLMN selection. The procedure runs in two steps : 1. The UE-NAS protocols (GMM,MM) send a PLMN search request to RRC. In the

request the corresponding PLMN identity is contained. The radio protocols now search for cells belonging to the given PLMN. This is in fact a cell selection.

2. When a suitable cell belonging to the correct PLMN is found, and confirmation is

sent to the NAS protocol. In case a cell of this PLMN cannot be found, the RRC protocol will send a list of available PLMNs is sent to the NAS protocols.



UE - NAS UE - AS

UE

cell 1cell 3

cell 2

use laststored PLMN

PLMN Search.REQ

(PLMN ID)

use laststored cell list

search for cellwith PLMN ID

PLMN Search.CNF

(PLMN IDor

all available PLMN)

Menu

figure 26 PLMN selection.



For the PLMN reselection there are two different modes of operation: • automatic mode : The NAS protocols select a new PLMN without user interaction. • manual mode : The selection is performed by the user. The PLMN reselection has three general steps: 1. The UE-AS protocol RRC provides the NAS protocols with a list of available PLMN. 2. Either the user or the NAS protocol itself select on the indicated PLMN. 3. A cell of the selected PLMN is chosen in the cell reselection process. After

successful completion of the cell reselection, an indication is sent to the NAS protocols.



UE - NAS UE - AS

UE

PLMN Search.REQ

(ALL)

PLMNreselection

use last storedcell list, if any

forcell reselection

PLMN Search.REQ(PLMN ID)

PLMN Search.CNF(PLMN ID)

PLMN List.CNF

(all available PLMNs)

Menu

figure 27 Manual PLMN (re-)selection.



2.3 Location Registration Trigger When the UE is camped on a cell (camped normally or camped on any cell state), the UE will constantly read the system information that is broadcasted on the BCCH of the corresponding cell. When the information received by the RRC protocol changes, due to cell reselection or change of the current cell’s system information, the NAS protocols have to be informed about this. This happens with a primitive message between RRC and the MM sub-layer. This primitive is called RRC System Information.IND and contains all changed parameters of the system information. On reception of this primitive, the NAS protocols have to decide about further actions to be triggered. One example here is the location registration. When the RRC System Information.IND indicates that the location or routing area changed, the MM or GMM layer will start a location or routing area update.



UE - NAS UE - AS

UE

cellSystem Information

changed

System Information.IND

( sys info to be updated)

BCCH

e.g. location reg.trigger

Menu

figure 28 Location trigger; Location information received from cell broadcast.

III. WCDMA Physical Layer for FDD Mode


WCDMA Physical Layer for FDD Mode Module Objectives:

• Basic Principles of UTRAN Radio Protocol Model in UE and UTRAN, • WCDMA Overview,

• Radio Bearers,

• Logical Channels,

• Transport Channels,

• Physical Channels,

• UE Procedures in Idle Mode.



1 Physical Layer Tasks



1.1 Physical Layer Functions The physical layer offers transport services to the higher layers via the transport channels. The data of the transport channels has to be processed before the bits can be transferred on the radio interface using DS-CDMA. The processing functions of the physical layer are the following: • channel coding (FEC) , • error detection on trans port channels using CRC , • multiplexing/de-multiplexi ng of transport channels , • rate matching (d ynamic puncturing) , • mapping of multiplexed transport channels onto physical channels. Next to these tasks related to transport channel processing, the physical layer is responsible for the radio specific procedures and tasks, that are: • radio measurements (FER : frame error rate, SIR : signal interference ratio, …), • macro-diversity, • frequency and time (chip, slot, frame) synchronization, • closed loop power control, • power weighting and multipl exing of physical channels, • modulation, spreading, scrambling .



Radio Tasks

Channel coding

Error detection (CRC)

MUX/DMUX of TrCH

Rate matching (puncturing)

MUX/DMUX (TrCH<->PhCH)

Radio measurements

Macro - diversity

Frequency & Time synchronization

Closed loop power control

Power weighting and spreading

Combination of several PhCH

Scrambling and modulation

Transport Channel Processing

Physical layer tasks

figure 1 Physical layer tasks.



1.2 Multiplexing of Trans port Channels – Coded Composite Transport Channels

Because every transport channel needs its own special treatment, there is a variable behavior of the physical layer to the different transport channels. In fact the physical layer offers the feature, that the certain transport channels can be treated together. This means a set of established transport channels is multiplexed into a so called Coded Composite Transport Channel CCTrCH . Such a CCTrCH itself can be multiplexed to one or several physical channels. In the uplink direction there is the following behavior for FDD and TDD mode defined: • DCH: If several DCH are established in the UE, these transport channels are

multiplexed into one CCTrCH. This CCTrCH is the transmitted over one or several physical channels.

• RACH: There can be at most one RACH in a UE at one time. The RACH transport

channel cannot be combined with other transport channels. • CPCH: An UE can be connected to at most one CPCH of a cell. The CPCH cannot

be combined with other transport channels. • USCH: One UE can have several USCH. These USCH can be combined into one

CCTrCH. This CCTrCH can be transmitted over several physical channels. In the downlink direction in FDD and TDD mode the following general definition holds: • PCH, FACH : PCH and FACH can be combined into one CCTrCH. • BCH : As there is only one BCH in one cell, a BCH can not be combined with other

transport channels. • DCH : Several DCH can be combined into one CCTrCH. • DSCH : Several DSCH can be combined into one CCTrCH. This description contains general restrictions on transport channel combinations. Which combinations will be really used, is indicated in RRC signaling.



CodingMultiplexing

DCH DCH DCH

Splitting

CCTrCH

PhCHPhCH

Coding

RACH

PhCH

Coding

CPCH

PhCH

CodingMultiplexing

USCH USCH

Splitting

CCTrCH

PhCHPhCH

CodingMultiplexing

PCH FACH FACH

Splitting

CCTrCH

PhCHPhCH

Coding

BCH

PhCH

CodingMultiplexing

DSCH DSCH

Splitting

CCTrCH

PhCHPhCH

figure 2 Multiplexing of transport channels onto coded composite transport channel.



1.3 Transport Channel Processing The processing of the transport channels that come from the MAC layer has the following steps, that can be identified with the presented functional blocks: • CRC attachment (error detection) : Every transport block of a transport block set

gets its own CRC, used for error detection. • Transport Block concatenation & code block segmentation : The transport

blocks are concatenated after the CRC is appended. If the resulting data block is too long (e.g. does not fit into one radio frame) a segmentation is performed afterwards.

• Channel Coding : UTRAN FDD and TDD offer four different channel coding

schemes as FEC. These are : no coding, convolution coder 1:2, convolution coder 1:3, turbo coder 1:3.

• Rate Matching : The physical layer can perform a puncturing of bits to reduce the

data rate. The physical layer gets rate matching parameters from RRC layer. • Radio Frame Equalization : If the data block after rate matching is too short for one

radio frame, some padding bits are appended. • 1st and 2 nd interleaving, • TrCH Multiplexing : This function multiplexes several transport channels to one

CCTrCH (Coded Composite Transport Channels). • Physical Channel Segmentation : The CCTrCH are split to several physical

channels, if there are any. • DTX bit insertion : If no information is to be transmitted by the network, so called

DTX (discontinuous transmission) bits are inserted. This is only for downlink. • Radio Frame segmentation : When a data block is too long for one radio frame (10

ms), it is segmented to several radio frames. • Physical Channel mapping : The data has to be mapped to the slot format of a

physical channel or to several physical channels if necessary.



The processing is slightly different for FDD uplink, FDD downlink and TDD mode.

TrCH multiplexing

CRC attachmentTrBk concatenation

Code block segmentation

Channel CodingRadio FrameEqualization

1st interleaving

Rate Matching

Radio FrameSegmentation

. . .

TrCH 1 TrCH 2 TrCH N

Physical Channel Segmentation

2nd interleaving

Physical Channel Mapping

FDDUL

figure 3 Transport channel processing blocks for FDD uplink transmission in the UE.



When multiple transport channels are multiplexed to CCTrCH (Coded Composite Transport Channel) and transmitted in physical channels, there has to be an indication which transport formats are used for every transport channel. Therefore the so called Transport Format Combination Identifier (TFCI) is used. In UE and Node B the value of the TFCI can be translated into:

- the number of transport channels,

- the transport format for every transport block of every transport channel in the combination.

This allows the de-multiplexing of CCTrCHs. The TFCI values and the assignment of transport format combination is signaled by RRC during radio bearer establishment. The definition of TFCIs runs in the following way. 1. During radio bearer set up or reconfiguration the transport channels to be

multiplexed are defined. 2. Now each transport channel has its transport format set. One transport format from

each transport channel’s transport format set build a transport format combination . Such a combination has to be chosen with care, taking UE radio capabilities into account.

3. Several transport format combinations form a so called transport format

combination set . Every transport format combination in the transport format combination set is uniquely identified with a transport format combination identifier TFCI.



TrCH 1

TF 6

TrCH 2

TF 3

TrCH 3

TF 1

TFCI 1

Physical ChannelTransport Format Combination

TransportFormat 6

TrCH 1

TransportFormat 3

TrCH 2

TransportFormat 1

TrCH 3

Transport Format Combination Set

TFCI 1 TFCI 2 TFCI 3 TFCI 4 TFCI 5

TF : TransportFormat

figure 4 Transport format combination identifier TFCI.



2 Physical Layer Procedures



2.1 General about Physical Layer Procedures The physical layer defines several procedures to control the radio interface on the lowest level. Most of these procedures are triggered and mastered by higher layers like MAC and RRC. The procedures can be divided into the following categories: • synchronization procedures : These types of procedures are used for cell search,

radio frame / slot and chip synchronization to physical channels. In the TDD mode also timing advance procedures are used to synchronize the UE to the cell timing.

• power control procedures : One of the most critical issues for CDMA systems is

the near - far problem. The solution for this is a very fast power control mechanism, using a closed control loop (UE - Node B – UE and Node B – UE – Node B).

• random access procedure : Like all known mobile radio access technologies also

WCDMA has to use a random access mechanism to establish a radio connection between an UE and the network. But also for shared resources between several UE an access mechanism with collision risk is used.

• radio measurements : For the mobility handling within the radio network the UE

and the Node B have to perform measurements of radio signal quality (bit error rate) and radio signal strength (signal interference ratio, interference power, signal power). These measurement are used as criteria for the cell reselection or handover procedures. For the measurements the UE physical layer has uses so called compressed mode radio frames. In such radio frame some slots are not used for transmission/reception, rather the measurements are then performed.

The procedures look different for TDD and FDD, but for the higher layers like MAC and RRC TDD- and FDD- physical layers shall behave equally.



Synchronization Procedures

Power Control Procedures

Random Access Procedure

Radio Measurements

Physical Layer Procedures

Cell Search

Frame / Slot / Chip Sync

Timing Advance (TDD only)

Closed Loop Power Control

Random Access (collision risk, collision detect.)

Signal Quality (BER)

Signal Power

figure 5 Physical layer tasks - overview.



2.2 Cell Search The task of the cell search procedure is to determine the downlink scrambling code and the common channel frame synchronization of a cell. There is no normative specification how to implement this feature. A typical procedure looks like the following. The procedure can be performed in three steps: 1. Slot Synchronization

First the UE uses the SCH (Synchronization Channel : physical channel) to get the so called primary synchronization code. This code will be used to find the slot edges, so slot synchronization can be achieved. The primary synchronization code is fixed, means, it is common to all cells.

2. Frame Synchronization

After the first step the UE has to find out the secondary synchronization code used in the cell. This is typically done by correlating the received signal with all possible secondary synchronization codes (FDD has 64 such code, TDD has 32 such codes). When the UE identified the secondary synchronization code, it can determine the frame borders.

3. Scrambling Code Identification

Every of the secondary synchronization codes is associated with a set of primary scrambling codes. One of these scrambling codes is used by the cell for the common control channels. It is up to the UE to find the correct code with the help of the CPICH (Common Pilot Channel : physical channel) in FDD mode. In the TDD mode there is no CPICH, thus the P-CCPCH (Primary Common Control Physical Channel : physical channel) is used (this channel carries the BCH transport channel in TDD mode). After the code is identified, the UE can read the BCCH information. Then the cell is found.

The figures below show the principle idea of cell search in the FDD mode. The TDD mode procedure has also the mentioned three steps, but looks different at step 2 and 3.



. . .

slot slot slot

P-SCHP-SCHP-SCH Primary Synchronization Code

time/slots

PSCfilter

output

one cell received

Menu

UE

figure 7 Cell search step 1: Primary Synchronization Channel (P-SCH).

time/slots

PSCfilter

output

three cells received

1 1 1

3 3 32 2 2

Menu

UE

cell 1 cell 3cell 2

figure 6 P-SCH usage if three cells are received.



Primary Synchronization Code

time/slots

SSC 1

Secondary Synchronization Code

. . .slot frame

P-SCHP-SCHP-SCH

14 0 14 S-SCHS-SCHS-SCH 1 S-SCH . . .

time/slots

SSC 2

time/slots

SSC64

.

.

.

match = frame begin

no match

no match

Menu

UE

figure 8 Cell search step 2: Seconda ry Synchronization Channel (S-SCH).



Primary Common Pilot Channel

Primary Synchronization Code

Secondary Synchronization Code

CPICH

. . .

frame

P-SCHP-SCH

0 14 S-SCHS-SCH 1 S-SCH . . .

CPICH CPICH. . .

(predefined bit sequence with primary scrambling code)

chips

SC 1

chips

SC 7

chips

SC 8

.

.

.match

no match

no match

Menu

UE

figure 9 Cell search step 3: Common Pilot Channel (CPICH).

CPICH is sent over full slot, so there is no Tx off period



2.3 Closed Loop Power Control The closed or inner loop power control is the fast power control mechanism applied by WCDMA. In FDD only the physical channels DPCCH, DPDCH and PCPCH use the closed loop power control. In TDD the DPCH is the only physical channel with closed loop control. The closed loop power control consists of two control loops: • UE – Node B – UE : This closed loop is used for the corresponding uplink channels.

The mechanism runs as follows. The UE sends data on uplink channels (DPCCH, DPDCH, PCPCH, DPCH) to the network. The Node B receives the transmitted signal and evaluates the signal interference ratio SIR. If the SIR is better than a target value SIRtarget (set by higher layers with open loop control), the Node B will send a Transmit Power Command (TPC) to the UE indicating, that it shall decrease the uplink transmit power. If the SIR is worse than the target value, the TPC indicates, that the UE shall increase the uplink transmit power.

• Node B – UE – Node B : This is the control loop for the downlink channels (DPCCH,

DPDCH, DPCH). The game here is the same as for the uplink. Now the UE receives the data from the Node B and evaluates the received SIR. Also the UE has a target SIRtarget provided by higher layer signaling (open loop power control). If the SIR is better, than a TPC for power decreasing is sent. Otherwise the TPC indicates, that a higher downlink transmit power is necessary. In contrast to the uplink, there is no guarantee for an UE, that the Node B obeys the command.

The TPC is a parameter within the physical channel slot formats. This means it is transmitted 15 times in 10 ms (radio frame). The typical power change rate is 1 dB, but also 2 dB are possible.



TransportChannel

Processing

TransportChannel

Processing

SIRMeasurement

Evaluation

DemodulationDespreading

ModulationSpreading

TransportChannel

Processing

TransportChannel

Processing

DemodulationDespreading

ModulationSpreading

TPCTPC

physical channel

1

2 3

4 ± 1 dB

UE (Node B) Node B (UE)

figure 10 Closed loop power control and transmit power command (TPC).



2.4 Random Access Procedure (FDD) The random access procedure in FDD mode requires two physical channels :

• PRACH (physical random access channel) : This channel is uplink only and is used by the UE. The PRACH consists of two parts : PRACH preambles : The preambles are blocks of 4096 chips. These

blocks are packed into an access slot of length 5120 chips. The chips of the preamble form complex pseudo noise code called signature . The UE sends these preambles with increasing power to the network until a response is received (or the maximum number of retransmissions is exceeded).

PRACH data part : In this part the UE can transmit data within one or two radio frames.

• AICH (Acquisition I ndicator Channel) : The AICH carries the responses to the

PRACH preambles sent by the UE. The AICH consists of 15 access slots in 20 ms. That means one access slot of AICH has 5120 chips length. In one slot there are 32 symbols. These 32 symbols represent the acquisition indicator AI. For different signature (see the PRACH preambles) the AI can have the values +1,0,-1. +1 is a positive response, -1 a negative response and 0 is no response. The access slots of the AICH are synchronized with the SCH transmission.

The random access procedure now runs in three steps: 1. The UE selects an access slot for the PRACH preamble. This selection is affected

by the so called Access Service Class the UE belongs to. Also the UE selects a signature (like a scrambling code) for the preamble. Then the preamble is sent in the selected access slot.

2. Now the UE listens to the corresponding access slot of the AICH.

1.1. If there is a positive AI (acquisition indicator) for the signature, the sending of preambles is stopped and step 3 is performed.

2.2. If there is a negative answer (AI=-1), the sending of preambles is stopped and

the higher layers in the UE are informed about the failure of the random access.



2.3. If there is no answer on the AICH for the corresponding signature, the UE will select a new access slot for a PRACH preamble and a new signature has to be selected. If the maximum number of preambles is exceeded the sending of preambles is stopped and the higher is informed about the failure of the procedure. Otherwise the UE goes back to step 1 and sends the PRACH preamble with higher transmit power.

3. The UE can now send the data part of the PRACH in one or two radio frames. The

data and control part of PRACH are sent three or four PRACH access slots after the last preamble. After the message has been sent, the higher layers (RRC) decide, whether the UE waits for further information from the network on the FACH or not.

0 1 2 3 4 5 6 7 8 910111213140 1 2 3 4 5 6 7 8 910111213140 1 2 3 4 5 6 7 8 91011121314

0 1 2 3 4 5 6 7 8 910111213140 1 2 3 4 5 6 7 8 910111213140 1 2 3 4 5 6 7 8 91011121314AICH

PRACH

+

control

data

10 ms

1314

control

data

physical random accessprocedure

random accessdata transmission

figure 11 Random access procedure in FDD – timing hierarchy.



--intentionally left blank --



PRACH preamble

listen to AICHPRACH preamble

listen to AICH

listen to AICH

PRACH preamble

AICH: AI = +1

PRACH data and control transmission

Menu

UE Node B

RACH Data partto RNC

RNC

figure 12 Random access procedure – message se quence chart and f unctional entities.



2.5 Common Packet Channel Access Procedure The CPCH is a common transport channel in a cell. This means it will be shared by several UE. Therefore an access procedure for the different UE that will use the CPCH is necessary. The CPCH will be transported on a PCPCH (physical common packet channel). This access procedure has two general parts that have to be performed by PHY and RRC. The two parts are: • PCPCH availability and CPCH format detection , • CPCH access and data transmission on the PCPCH . For these two tasks the following physical and logical resources are necessary: • BCCH (logical channel) : The BCCH carries system information also about the

PCPCH that are available in the cell. Mainly semi-static information is included in the BCCH (e.g. scrambling codes for the PCPCH, transport format sets and transport format combination sets for the CPCH).

• CSICH (CPCH Status Indicator Channel) : This physical channel is a typical physical

signal. It is used to indicated to the UE that a certain PCPCH is available. Also the minimum spreading factor on an available PCPCH can be sent by the network (Channel Assignment mode).

• PCPCH (Physical Common Packet Channel) :This channel carries the CPCH.

Additionally the PCPCH has an access preamble part (similar to the random access preambles), collision detection part (this part is used for contention resolution in case of a successful access), power control part (provides inner loop power control for the CPCH before the data transmission begins).

• AP-AICH (Access Preamble Acquisition Indicator Channel) : The AP-AICH carries

the acquisition indicators AI for the PCPCH access preambles. The values of an AI can be +1 (successful access), -1 (negative outcome) and 0 (no indication=access not detected).

• CD/CA-ICH (Collision Detection/Channel Assignment Indicator Channel) : The

CD/CA-ICH is the physical signal that carries the answer to the PCPCH collision detection part. The collision detection and channel assignment indicators can have the values +1 (CPCH can be used by UE), -1 (CPCH can not be used by UE), 0 (no



indication = CPCH can not be used by UE).

BCCH

CSICH

Dynamic PCPCH attributes- PCPCH availability- PCPCH minimum spreading factor

Semi-static CPCH attributes- transport format sets- transport format combination sets- scrambling codes

PCPCH

CD/CA-ICH

AP-AICH

- PCPCH data part = CPCH- PCPCH access preamble part- PCPCH collision detection

preamble part- PCPCH power control part

Access Preamble Indicator(+1,-1,0)

Collision Detection Indicator(+1,-1,0)

cellMenu

UE

figure 13 CPCH access procedure: Informat ion resources about CPCH resources.



Before a UE can use the CPCH of a cell, it has to get information about the CPCH. Therefore the BCCH (on P-CCPCH) and the CSICH have to be used. For the CPCH usage we have to distinguish two different modes: • channel assignment active : When the channel assignment is active the PCPCH to

be used for the CPCH transmission is signaled by the UTRAN to the UE (using RRC messages).

• channel assignment inactive : If the channel assignment is not active, the UE

selects randomly one of the PCPCH in the cell for the CPCH transmission. It is up to the UTRAN to decide which of the two modes shall be used in a cell. Therefore in the System Information Block 8 that is sent on the BCCH (on P-CCPCH) (see RRC) the cell will indicated whether channel assignment is active or not. In this System Information Block 8 also the possible transport formats (= transport format set) and the allowed transport format combinations (= transport format combination set) are indicated. Furthermore the UE gets the scrambling codes that shall be used on the PCPCH from this system information. Now the UE gets semi-static information from the BCCH, this means everything that is transmitted in the System Information Block 8 is set by the operator via O&M. In contrast to that, the UE also has to get information whether a PCPCH is currently available or not (e.g. because it is in use). Therefore the CSICH (CPCH Status Indicator Channel) is used. This physical channel carries status indicators about the PCPCH. The exact meaning of these indicators depends on whether channel assignment is active or not: • channel assignment not active : In this case the CSICH defines which of the

PCPCH of the cell (up to 16 possible) are currently available or not. • channel assignment is active : When channel assignment is active the CSICH

indicates, which minimum spreading factor (= maximum data rate) is available for a PCPCH of this cell. The spreading factors can vary between 4, 8, 16, 32, 64, 128, 256 and N/A (not available).

With the CSICH and the BCCH information the UE can start and access to a CPCH resource, means to a PCPCH.



cell

P-CCPCH (BCCH) : System Information Block 8

( channel assignment mode, transport format set,transport format combination set, scrambling codes, ... )

CSICH : CPCH Status Indicators

( PCPCH availability | PCPCH minimum available spreading factor)

CPCH access : information acquisition phase

Menu

UENode B RNC

figure 14 CPCH access step 1: Information acquisition phase.



The access to a PCPCH can be described in the following 5 steps: 1. The UE selects a signature (like a scrambling code) for the transmission of the

PCPCH access preamble and sends it on the PCPCH with the scrambling code indicated by the BCCH information.

2. The UE now listens to the AP-AICH (Access Preamble Acquisition Indicator

Channel) . The indicators on this channel can have three different meanings :

a. negative indication : The UE will abort the CPCH access procedure. b. no indication : The UE will increase the transmit power for the access

preambles, first check the CSICH for availability of the PCPCH again (if the PCPCH is no longer available or not with the correct data rate, the UE shall abort the procedure) and then send a preamble again (step 1). When the maximum number of preambles has been sent, the UE shall abort the CPCH access.

c. positive indication : The UE shall stop sending preambles and proceed with

step 3. 3. After reception of a positive acquisition indicator the UE shall send the PCPCH

collision detection preamble . For the CD (collision detection) preamble the UE shall chose a random signature (scrambling code like) that will be used as a random identifier for the UE on the physical layer.

4. The UE now listens to the CD/CA-ICH (Collision Detect ion/Channel Assignment

Indicator Channel) . The information on this physical channel can be :

a. negative or no acknowledgement for the chosen signature : In this case the UE shall abort the CPCH access.

b. positive acknowledgement : The UE can now use the CPCH (step 5).

5. The UE has now the PCPCH for the CPCH information transport. First the UE will

send a PCPCH power control preamble to the network. This is used for the closed loop power control. (Please note, that a CPCH is always associated with a downlink DCCH for the closed loop power control). After this preamble the UE will immediately send its data.



0 1 2 3 4 5 6 7 8 9 1011121314 0 1 2 3 4 5 6 7 8 9 1011121314 0 1 2 3 4 5 6 7 8 9 1011121314

0 1 2 3 4 5 6 7 8 9 1011121314 0 1 2 3 4 5 6 7 8 9 1011121314 0 1 2 3 4 5 6 7 8 9 1011121314

AP-AICH

PCPCH

+

control

data

10 ms

1314

control

data

CD/CA-ICH +

PCPCHaccess preamble

PCPCHcollision detection

preamble

PCPCHpower control

preamble

PCPCHdata part

figure 16 CPCH access step 2: Timing hierarchy.

PCPCH access preamble

listen to AP-AICHPCPCH access preamble

listen to AP-AICHAP-AICH : AI = +1

PCPCH collision detection preamble

CD/CA – ICH : positive ackn.listen to CD/CA-ICH

PCPCH power preamble and data part

M enu

UENode B RNC

CPCH Data partto RNC

figure 15 CPCH access step 2: Message sequence chart.

IV. UTRAN Layer 2 Protocols MAC, RLC, PDCP


UTRAN Layer 2 Protocols MAC, RLC, PDCP

Module Objectives:

• Medium Access Control Protocol MAC: Tasks, Functions and Frames • Radio Link Control Protocol RLC: RLC Modes, RLC Frames,

• Packet Data Convergence Protocol PDCP: Tasks and Frames.



1 Medium Access Control Protocol MAC



1.1 MAC Services and Functions The MAC protocol sits on top of the physical layer. So MAC has to use the transport channel services offered by the physical layer. On top of MAC the various RLC (Radio Link Control) entities are located. MAC offers the logical channels to the RLC. MAC has the following functions that can be used by the higher layers : • mapping of logical onto transport channels, • selection of appropriate transport format for each transport channels according to

the current source rate (with respect to the transport channel combination set), • priority handling and scheduling of data flows in the UE, • priority handling and scheduling between UE on common/shared resources, • identification of UE on common/shared resources, • multiplexing/de-multiplexing of several radio bearers (= RLC instance) onto the same

transport channel, • traffic volume measurement and reporting towards RRC, • switching of the transport channel type for a radio bearer (controlled by RRC),

means several transport channel types can be assigned to one radio bearer, • ciphering/de-ciphering (only if not performed by RLC), • control of random access and CPCH access (e.g. priority classes).



Mapping of logical onto transport channels

Transport format selection

Priority handling / schedulingof data streams in one UE

Priority handling / schedulingbetween different UEs

Identification of Ues onCommon / shared resources

Multiplexing / de-multiplexingof radio bearers on one TrCH

Traffic volume measurements

Transport channel type switching

Ciphering / de-ciphering

Random and CPCH access control

Media Access Control (MAC) functions

figure 1 Functions of MAC protocol.



1.2 MAC Protocol Architecture The MAC layer has to deal with the common and shared transport channels. Therefore three different MAC entities are defined, they describe how the logical channel information flows through the MAC layer. These entities are: • MAC-b : MAC-b handles the broadcast (transport) channel BCH exclusively. The

MAC-b on the UTRAN side is typically in the Node B. • MAC-c/sh : MAC-c/sh is responsible for the other common transport channels like

PCH, FACH, RACH, CPCH (FDD only), DSCH, USCH (TDD only). • MAC-d : In contrast to the first two entities that handle common transport channels

only, the MAC-d entity is in control of the dedicated transport channels DCH. The figure on the other page shows how these three entities are arranged in UE and UTRAN. The difference between UE and UTRAN is, that an UE has to handle its own dedicated resources only, whereas the UTRAN has to deal with the dedicated resources from all its UE. Therefore the UTRAN can have several MAC-d entities. An UE has only on MAC-d. There is also a direct connection between MAC-d and MAC-c/sh. This link is used, when dedicated logical channels (DTCH, DCCH) are transmitted via a common or shared resource (see the mapping of logical onto transport channels). Of course the detailed implementation of the entities in UE and UTRAN differ.



MAC-b MAC-c/sh MAC-d

...

BCCH PCCHCCCH

CTCHSHCCH

DCCHDTCH

BCH

.........

PCHFACH

RACHCPCH

USCHDSCH

...

DCH

MAC-b MAC-c/sh MAC-d

...

BCCH PCCHCCCH

CTCHSHCCH

DCCHDTCH

BCH

.........

PCHFACH

RACHCPCH

USCHDSCH

...

MAC-d

DCH

MAC-d

Menu

UE

Node BRNC

figure 2 MAC protocol architecture in UE and UTRAN.



1.3 MAC Frames for peer-to-peer Communication The MAC protocol layers in UE and UTRAN have to communicate to each other (peer-to-peer). Therefore the MAC protocol specifies so called MAC PDU (MAC Protocol Data Units) . A MAC PDU is represented by a bit string not necessarily an integer multiple of 8 bits. The bits are transmitted from left to right and up to down (normal reading), this means the leftmost bit in the first line is the first octet to be transmitted, the rightmost bit in the last line is the last bit to be transmitted. A MAC PDU consists of two parts : • MAC header : The MAC header is the first part of a MAC PDU. The information

included in the header depends upon the logical/transport channel pair the MAC header is used for. In fact the MAC header can contain the following elements (in ordered form):

TCTF (Target Channe l Type Field) : The TCTF identifies the logical channel

type that is associated with the data in the transport channel. UE-Id type : The UE-ID type parameter indicates the kind of UE ID (either u-

RNTI or c-RNTI) that is included in the header. UE-ID : The UE-ID identifies the UE on common transport channels. It can be

either u-RNTI or c-RNTI. C/T : When multiple logical channels of the same type (e.g. DTCHs) are

multiplexed onto the same transport channel, the C/T field indicates to which of the logical channels (e.g. DTCH 1, DTCH 2, …) the data of the transport channel belongs to.

• MAC SDU (Service Data Unit) : The MAC SDU is the second part of the MAC PDU.

In the MAC SDU the data from the RLC instances is transported (= logical channel/radio bearer). In contrast to the header the MAC SDU always has a size that is an integer multiple of 8 bits. When the MAC protocol performs ciphering, the MAC SDU is the only part of the MAC PDU that will be encrypted.

The header parameters are all conditional in their presence, this means, that their presence in the MAC PDU depends on the situation in which the MAC PDU is used.



TCTF UE-IDtype UE-ID C/T

MAC header

RLC data

MAC SDU

MAC PDU

MAC PDU

bit 0 last bit

RNC

Menu

UE

figure 3 MAC PDU for peer-to-peer communication between UE and UTRAN.



The TCTF (Target Channel Type Field) indicates the type of logical channel the data of the MAC SDU belongs to. Whether the TCTF will be part of the MAC header of a MAC PDU depends on whether there can be different logical channels on the corresponding transport channel. Note that it is not necessary to distinguish DCCH and DTCH, because the DCCH always get their own explicit radio bearers, so that there is no collision between DCCH and DTCH. Therefore the transport channels that need the TCTF are : • FACH (can carry BCCH, CCCH, DCCH or DTCH, CTCH, SHCCH), • USCH (carries DCCH or DTCH, SHCCH), • DSCH (carries DCCH or DTCH, SHCCH), • RACH (carries CCCH, DCCH or DTCH, SHCCH). The transport channels DCH and CPCH can carry DCCH and DTCH only. Because DCCH and DTCH will never collide there is no TCTF for DCH and CPCH necessary. The C/T field indicates to which logical channel the data in the MAC SDU belongs to, when several logical channels of one type (e.g. DTCH) exist on the same transport channel. When a new radio bearer is established, the new radio bearer is assigned to a logical channel type, a number is assigned to this logical channel for this radio bearer. The next radio bearer for the same logical channel type gets the next higher number. The size of the C/T field is fixed to 4 bits. In case that a dedicated logical channel is transmitted on a common transport channel (e.g. DTCH on CPCH), an explicit addressing of the UE is necessary. Therefore the MAC header can include the UE-ID which can be either the u-RNTI or the c-RNTI. It has to be indicated which of the two is used. Therefore the UE-ID type field is used. The UE-ID type field is 2 bits, the UE-ID is 16 bits (c-RNTI) or 32 bits (u-RNTI). The coding of all these parameters is shown on the next page. Not mentioned values are always reserved and a MAC PDU that uses such reserved values will be discarded by the current protocol version of MAC.



Designation TCTF for FACH (TDD) TCTF for FACH (FDD)

BCCH 000 00 CCCH 001 01000000 CTCH 010 10000000

DCCH or DTCH 01100 11 SHCCH 100 - not applicable -

figure 4 TCTF coding for FACH in FDD and TDD mode.

Designation USCH (TDD) DSCH (FDD & TDD)

SHCCH 0 0 (for TDD only) DCCH or DTCH 1 1

figure 5 TCTF coding for USCH (TDD) and DSCH (FDD/TDD).

Designation RACH (TDD) RACH (FDD)

CCCH 00 00 DCCH or DTCH 0100 01

SHCCH 10 - not applicable -

figure 6 TCTF encoding for RACH in FDD and TDD mode.

C/T field Designation

0000 logical channel 1 0001 logical channel 2

… … 1110 logical channel 15 1111 reserved

figure 7 Encoding of the C/T field (4 bits).

UE – ID type field UE – ID type length of UE-ID field

00 u – RNTI 32 bit 01 c – RNTI 16 bit 10 reserved - not applicable - 11 reserved - not applicable -

figure 8 Encoding of the UE-ID type field (2 bits) and corresponding length of UE-ID.



1.3.1 Examples of different MAC Head ers in various Situations In this section five examples of MAC PDU structures are shown. 1. DTCH or DCCH on DCH with several dedicated channels

In the first example dedicated logical channels on one DCH are considered, where several dedicated channels are configured for this DCH. Because a dedicated transport channel (DCH) is used, there is no need for a UE-ID field, so also no UE-ID type field is necessary. Because only dedicated logical channels are possible on a DCH, a TCTF field is not defined for the DCH. This means the only MAC header parameter that remains is the C/T field. As we have several logical channels on the DCH, the C/T field is necessary.

2. One DTCH or one DCCH on RACH/FACH

In this example one dedicated channel is sent on a common transport channel. Therefore we need the TCTF, but no C/T field. Because a common resource is used by several UE, an explicit addressing is necessary, so the UE-ID and UE-ID type field are present.

3. Several DTCH and/or DCCH on a CPCH

We have several DTCH, so the C/T field is mandatory. Also a common transport channel is used, this means the UE-ID and UE-ID type field have to be in the MAC PDU. The TCTF field is not present, because a CPCH can carry dedicated logical channels only.

4. BCCH on BCH

The BCH carries BCCH information only, so no TCTF field is used. BCCH information is not dedicated, so an UE-ID and UE-ID type field is not applicable. As there is only one BCCH, the C/T field is meaningless. All in all, there will be no MAC header in this example.

5. CCCH on RACH/FACH

A RACH or FACH can carry several different logical channel information. So a TCTF field is required. But there is no dedicated information in a CCCH and there is only one CCCH in a cell, so UE-ID, UE-ID type and C/T field are not present.



TCTF MAC SDU

C/T MAC SDU

(1) Several DTCH/DCCH on DCH

(2) 1 DTCH or 1 DCCH on RACH/FACH

TCTFUE-IDtype

UE-ID MAC SDU

(3) Several DTCH/DCCH on CPCH

UE-IDtype

UE-ID C/T MAC SDU

MAC SDU(4) BCCH on BCH

(5) CCCH on RACH/FACH

figure 9 MAC headers for different logical/transport channel combinations.



2 Radio Link Control Protocol RLC



2.1 RLC Functions and Services The RLC layer sits on top of the MAC and uses the logical channel services offered by MAC. The RLC layer creates one RLC instance for every radio bearer, which is the in fact the WCDMA transport service to higher layers. The RLC will enhance the MAC transport services with the following functions : • Segmentation and reassembly : This function segments and reassembles the

higher layer data units into smaller RLC PDU (RLC Protocol Data Unit) . This is done in correspondence with the possible transport formats.

• Concatenation : If the higher layer data cannot be put into one RLC PDU, the data

can be spread over several RLC PDU. Where several of the higher layer data units can share one RLC PDU.

• Padding : If the data of the higher layer does not fill one RLC PDU and there is no

other higher layer data unit, padding bits are appended to the higher layer data to fill the RLC PDU.

• Transfer of user data : The RLC can transfer higher layer data in RLC PDU in

acknowledged, unacknowledged and transparent mode. • Error correction : In acknowledged mode the RLC protocol instance can perform a

backward error correction. • In sequence delivery : In acknowledged mode the RLC protocol instance performs

a re-ordering of received higher layer data. • Duplicate detection : In acknowledged mode the RLC discards higher layer data

already received. • Flow control : In acknowledged mode the two communicating RLC entities can

agree about the higher layer data rate. • Sequence number check : In unacknowledged mode the RLC protocol instance can

detect corrupted higher layer data units by checking the sequence numbers of the RLC PDU.



• Ciphering : In acknowledged and unacknowledged mode the RLC layer

encrypts/decrypts the higher layer data.

Segmentation / Reassembly

Concatenation

Padding

Ciphering

Transfer of user data

Error correction

Duplicate detection

Flow control

Sequence number check

Radio Link Control (RLC) functions

figure 10 RLC Functions and Tasks.



With the RLC functions the radio link control sub-layer provides the higher layers with logical bearer service functions. Therefore every radio bearer will have its own RLC instance. Such an instance is configured by the RRC protocol according to the radio bearer properties needed. During this configuration also the logical channel the radio bearer is assigned to is fixed.





RLC RLC RLC


Logical Channels

Transport Channels

PDCP BMC

Radio Bearers

RLC

figure 11 RLC within the UTRAN protocol architecture.



2.2 RLC Modes of Operation To adapt the radio bearer service characteristics to the requirements of the radio bearer user (signaling bearer for RRC, user data bearer) different configurations of the RLC protocol instance handling a radio bearer are possible. In fact there are three different modes of operation for a RLC protocol instance : • transparent mode : In transparent mode the RLC protocol performs transport of

higher layer data including segmentation/reassembly functionality. No other service is provided by the RLC in this mode. Even ciphering is not done in RLC, instead the MAC protocol has to perform ciphering.

• unacknowledged mode : In unacknowledged mode the RLC transports higher layer

data without guaranteeing the delivery of the data. The mode includes the following features : detection of erroneous data (erroneous data frames are discarded), sequence check, ciphering.

• acknowledged mode : The acknowledged mode provides a reliable radio bearer

service. All possible functionality of the RLC protocol is used. In detail the acknowledged mode includes : ciphering, flow control, protocol error detection, flow control, duplicate detection, in-sequence delivery, error correction by automatic retransmission.

Which of the functions are used in the established radio bearer depends upon the mode that is configured and upon the logical channel that will be used for this radio bearer.



TransparentMode

UnacknowledgedMode

AcknowledgedMode

RLC

Logical Channel

Radio Bearer

- Segmentation- Reassembly- Data transfer

- Segmentation- Reassembly- Data transfer- Sequence control - Ciphering

-Segmentation- Reassembly- Data Transfer- Ciphering- Error correction- Flow control- Duplicate detection

RLC modes

RRCconfiguration

figure 12 RLC modes of operation.



2.3 RLC Transparent Mode In transparent mode the RLC will not add specific functionality to the radio bearer. The data from the higher layers is treated in the following entities one after each other : • transmission buffer : For transmission scheduling the data is stored in this buffer

until it can be sent to the MAC layer. • segmentation : Before the data is sent to MAC it is segmented if it does not fit into

the transport block. • receive buffer : When data is received from the MAC layer it is first stored in this

buffer. • reassembly : Before the information can be sent to the higher layer, the segmented

data is reassembled. The transparent mode can be used by the following logical channels: • BCCH ,

• DCCH, • PCCH, • CCCH (transparent mode only for uplink), • DTCH, • SHCCH (transparent mode only for uplink).



Segmentation

TransmissionBuffer

Receive Buffer

Reassembly

radiointerface

BCCH/PCCH/CCCHDCCH/DTCH/SHCCH

Tr SAP Tr SAP

SAP : Service Access Point

figure 13 RLC transparent mode – functional entities.



The RLC protocol defines frames to transport the user data and to perform own procedures. In case of the transparent mode there are no RLC procedures applicable. Therefore there is no need for special RLC protocol information to be appended to the radio bearer data. The result is the TrD PDU (Transpare nt Data Protoc ol Data Unit) of RLC. The TrD PDU is used in transparent RLC mode only and carries the higher layer data only. The size of the TrD PDU is not restricted to be an integral multiple of 8 bits. Ciphering of the data is not performed by RLC, but by MAC. MAC will apply the encryption to the complete TrD PDU.



Higher layer data

TrD PDU

figure 14 Transparent Mode Data PDU (TrD) for RLC transparent mode.



2.4 RLC Unacknowledged Mode In unacknowledged RLC mode the radio bearer will be equipped with the additional functionality of message sequence order check. Therefore every RLC PDU that is sent to MAC will have a sequence number. When higher layer data cannot be reassembled due to missing or erroneous RLC PDU the higher layer data is discarded. The following entities can be found in RLC unacknowledged mode : • transmission buffer ,

• segmentation / reassembly , • add RLC header : This function packs the higher layer data (RLC SDU) in a RLC

frame (RLC PDU). A sequence number is included in the RLC header of the RLC PDU.

• ciphering : In unacknowledged mode ciphering is performed by the RLC layer. • receive buffer, • remove RLC header. The RLC unacknowledged mode can be used in combination with the following logical channel types : • CCCH (unacknowledged mode used in downlink only),

• DCCH, • DTCH, • SHCCH (unacknowledged mode used in downlink only), • CTCH.



Segmentation

TransmissionBuffer

Remove RLCHeader

Reassembly

radiointerface

CCCH/DCCH/DTCH/SHCCH/CTCH

UM SAP UM SAP

Add RLC Header

Ciphering

Receive Buffer

Deciphering

figure 15 RLC unacknowledged mode – functional entities.



The RLC PDU (frame) used in RLC unacknowledged mode is the UMD PDU (Unacknowledged Mode Pr otocol Data Unit) . In contrast to the TrM PDU of RLC the UMD PDU contains protocol control information plus the higher layer data (RLC SDU = Service Data Unit). There are two RLC information elements in the RLC header : • Sequence Number : Every UMD PDU for one radio bearer gets a number, such that

the next UMD PDU gets the next higher number.

• Length Indicator : The length indicator specifies the number of octets used for the RLC SDU (higher layer data) or the end of a RLC SDU that is segmented into several RLC PDU. Several length indicators can occur in one UMD PDU. Each one points to the end of one SDU (this means the value of the length indicator is the number of octets between the last length indicator up to and including the last octet of the corresponding SDU) or indicates special events.

• Extension bit E : The extension bit is 0 when the following octet contains the RLC

SDU, otherwise it is 1. • data part : The data part carries the RLC SDU. In an UMD PDU the data part is

required to have a size that is an integer multiple of 8 bits (octet aligned). The length indicator in a UMD PDU can be of size 7 or 15 bits. Which length will be chosen depends upon the largest UMD PDU that is used for one RLC SDU that is segmented into these PDU. If the largest UMD PDU for one SDU is ≤125 octets, a 7 bit indicator is used, otherwise the length indicator for these UMD PDU shall be 15 bits. Some special values of the length indicator are used to indicate begin and end of SDU.

7 bit LI 15 bit LI Description 0000 000 0000 0000 0000 000 Previous RLC PDU was filled with the last

segment. 1111 100 1111 1111 1111 100 The first octet of this PDU data part is the first

octet of a RLC SDU. 1111 101 1111 1111 1111 101 reserved (RLC PDU will be discarded) 1111 110 1111 1111 1111 110 reserved (RLC PDU will be discarded) 1111 111 1111 1111 1111 111 The rest of the RLC PDU is padding.

figure 16 Special reserved length indicator values for RLC unacknowledged mode.



Sequence Number E

8 7 6 5 4 3 2 1

Length Indicator E

Length Indicator E=0

. . .

Data

(segmented RLC SDU)

Padding

UMD PDU

figure 17 Unacknowledged Mode Data PDU (UMD).



2.5 RLC Acknowledged Mode The RLC mode with the most sophisticated service is the acknowledged mode. In this RLC mode the radio bearer is enhanced with functionality for error correction, sequence control and flow control. Ciphering is performed by RLC in the acknowledged mode too. In contrast to transparent and unacknowledged mode, where receiving and transmitting entity are independent, the acknowledged mode requires a bi-directional logical channel. Transmitting and receiving entity are closely coupled with each other. In fact the acknowledged mode can be used on DCCH / DTCH only. The following functional entities can be distinguished in an acknowledged mode RLC instance : • segmentation (transmitter) and reassembly (receiver),

• retransmission buffer (transmitter) : Stores the data sent to the other side until it is

positively acknowledged. • transmission buffer (transmitter) and receive buffer (receiver), • add RLC header (transmitter) / Set RLC header fields : This function creates the

RLC PDU for acknowledged mode. In the RLC PDU acknowledgements for received RLC PDU can be included.

• remove RLC header (receiver) : This function removes the RLC header from the

RLC PDU and evaluates the acknowledgements in it. All positive acknowledged RLC PDUs are removed from the retransmission buffer, all negative acknowledged RLC PDUs will be retransmitted.

• RLC control unit : The RLC control unit is used for the initialization and reset of the

RLC instance. Also parameter negotiation is controlled by this unit. • Demux (receiver) : The demux unit is used to de-multiplex the RLC PDU with and

without user data inside.



Segmentation

Add RLC header

RetransmissionBuffer

MUX

TransmissionBuffer

Set RLC header field

Ciphering

RLC control

Demux

Deciphering

Receive Buffer

Remove RLC headerAckn. information

Reassembly

DCCH/DTCH

AM-SAP AM-SAP

figure 18 RLC acknowledged mode – functional entities.



In RLC transparent and unacknowledged mode only one RLC PDU type is used respectively. In RLC acknowledged mode four different RLC PDU are defined. There are : • AMD PDU (Acknowle dged Mode PDU) : The acknowledged mode PDU is the

PDU that carries the RLC SDU (higher layer data) in acknowledged mode. Additionally the AMD PDU can carry status information for acknowledgements (piggybacked status ).

• STATUS PDU : A status PDU is used to transfer pure RLC control information

between two peer RLC instances. The information in a STATUS PDU can be explicit acknowledgements (positive and negative) or to indicate the window size (= how many AMD PDU can be sent before an acknowledgement is necessary). A STATUS PDU can also be transported using an AMD PDU (piggybacked status PDU).

• RESET PDU : The RESET PDU is used between two RLC instances to agree about

the actual HFN (Hyper Frame Number) used on air interface for ciphering purposes. • RESET ACK PDU : The RESET ACK PDU is the response to a RESET PDU. It

contains the HFN in the other direction. The STATUS, RESET and RESET ACK PDU are pure control PDU, they do not carry higher layer data. To distinguish AMD PDU from control PDU every PDU used in acknowledged mode contains in the first position (bit 8 of octet 1) the D/C field . The D/C field is one bit in length, a D/C value 0 indicates a control PDU, whereas the D/C value 1 means a AMD PDU.



D/C

8 7 6 5 4 3 2 1

PDU inAM

AMD PDU1

control PDU (RESET, RESET ACK, STATUS)

0

PDUD/C

figure 19 D/C field – discrimination between control and data PDU.



The AMD PDU is used to carry user data and piggybacked status information to the other RLC instance. Also it is possible to request status information with an AMD PDU. The AMD PDU consist out of the following protocol control information elements : • D/C field : The D/C field for an AMD PDU is 1. Indeed this indicates that the frame

contains an AMD PDU.

• Sequence Number : The sequence number is a numbering for all AMD PDU of one radio bearer. In contrast to the 7 bit sequence number in an UMD PDU, the AMD PDU has a sequence number of 12 bits.

• Poll bit (P) : If P=1 in an AMD PDU the sender of the AMD PDU requests the

receiver to send status information. The requested status information can be sent explicitly in a STATUS PDU or can be piggybacked in a AMD PDU. If P=0 no status information is requested.

• Header Extension (HE) : The header extension field consist out of 2 bits. These two

bits indicate, whether the next octet contains data or a length indicator (plus E bit).

HE value Description 00 Following octet contains data. 01 Following octet contains length indicator and E bit.

10 - 11 Reserved (PDU will be discarded). • Length indicator : Like in case of the UMD PDU the length indicator can be 7 or 15

bits. If the AMD PDU that carry one segmented RLC SDU have all a size of less than 126 octets a length indicator with 7 bit shall be used. Otherwise the length indicator with 15 bits are used. Like for the unacknowledged mode also for AMD PDU special values are reserved. In one AMD PDU several length indicators can occur, each one pointing to the end of a SDU or indicating a special event.

7 bit LI 15 bit LI Description

0000 000 0000 0000 0000 000 Previous AMD PDU was filled with the last segment.

1111 100 1111 1111 1111 100 Reserved (AMD PDU will be discarded) 1111 101 1111 1111 1111 101 Reserved (AMD PDU will be discarded) 1111 110 1111 1111 1111 110 Rest of the AMD PDU contains piggybacked

status PDU. 1111 111 1111 1111 1111 111 The rest of the RLC PDU is padding.



• Extension bit (E) : If E=0 the next octet contains data, if E=1 the next octet belongs to the length indicator.

Sequence Number1

8 7 6 5 4 3 2 1

Sequence Number P

Length Indicator E

. . .

Data

(segmented RLC SDU)

Padding or piggybacked STATUS

AMD PDU

HE

Length Indicator E=0

figure 20 Acknowledged Mode Data PDU (AMD) – frame structure.



To synchronize the two RLC protocol instances in UTRAN and in the UE the RESET and RESET ACK PDU are used. The synchronization mainly concerns the exchange of the HFN (Hyper Frame Numbers) used on the radio interface independent for uplink and downlink. In detail the RESET and RESET ACK PDU contain the following information elements: • D/C field : Because RESET and RESET ACK are control PDU the D/C field is set to

0.

• PDU Type : To distinguish the different control PDU a PDU type field is defined as shown below.

PDU type field Description

000 STATUS PDU 001 RESET PDU 010 RESET ACK PDU

011 - 111 Reserved (PDU will be discarded) • RSN (Reset Sequence Number) : Every issued RESET PDU gets a RSN and the

next issued RESET gets the next higher RSN. With this number a retransmitted RESET can be detected and the RESET ACK can be assigned to one RESET. The field has a length of one bit.

• HFNI (Hyper Frame Number Indicator) : The HFNI is a 20 bit long field that

contains the Hyper Frame Number HFN for the current hyper frame on the radio interface.



PDU Type0

8 7 6 5 4 3 2 1

RSN 0

Padding

RESET /RESET ACK

PDUHFNI

0 0

HFNI

HFNI

figure 21 RESET and RESET ACK PDU.



The last PDU type that is defined for the acknowledged mode is the STATUS PDU. The STATUS PDU carries status information, this is mainly acknowledgements and the window size used. Like the RESET and RESET ACK PDU also the STATUS PDU is a control PDU. The following elements are in a STATUS PDU : • D/C field : The D/C field for a STATUS PDU is set to 0 because it is a control PDU.

• PDU Type : To distinguish the different control PDU, the PDU type indicator is used.

For a STATUS PDU the PDU type is 000. • SUFI (Super Field) : A STATUS PDU can carry one or several SUFI. A SUFI

contains a data type that corresponds to status information of RLC. These data types will be explained below. The super fields are not required to have a length that is an integer multiple of 8 bits.

When STATUS PDU is transported in an AMD PDU, it is called a piggybacked STATUS PDU. In this case the general structure of the STATUS PDU is the same. The only difference is that in a piggybacked STATUS PDU the D/C field is not used (but still coded as 0). The piggybacked STATUS PDU is transmitted after the data part in an AMD PDU. That a piggybacked STATUS PDU is present in the AMD PDU will be indicated by the special length indicator `1111 110´ or `1111 1111 1111 110´.



PDU Type0

8 7 6 5 4 3 2 1

STATUSPDU SUFI 1

SUFI K

SUFI 1

. . .

Padding

figure 22 STATUS PDU.



The super fields SUFI are used to encode data types that indicate the status of the acknowledged mode RLC protocol instance. Therefore the SUFI follow a general format syntax composed out of : • Type : The type field indicates which data type is contained in the SUFI. The

presence of the Type indicator is mandatory and has a length of 4 bits.

• Length : The length indicator is an optional element in a SUFI, whether it is present or not depends upon the type indicator. The length indicator always follows the type indicator and its length can be different from data type to data type.

• Value : The value field is optional and like for the length indicator its presence

depends upon the data type. The length of the value field depends either on the length indicator (if it is present) or on the data type when a fixed length of the value field is used for this data type.

For the currently used protocol version of RLC the following data types can be used to indicate the RLC protocol instance status :

Type Description

0000 No more data (NO_MORE) 0001 Window Size (WINDOW) 0010 Acknowledgement (ACK) 0011 List (LIST) 0100 Bitmap (BITMAP) 0101 Relative List (Rlist) 0110 Move Receiving Window (MRW) 0111 Move Receiving Window Acknowledgement (MRW_ACK)

1000 - 1111 Reserved (PDUs with this encoding are invalid)



Type (4 bits)

Length

Value

SUFI

(mandatory)

(conditional [Type])

(conditional [Type])

Type Description

0000 No more data (NO_MORE)

0001 Window Size (WINDOW)

0010 Acknowledgement (ACK)

0011 List (LIST)

0100 Bitmap (BITMAP)

0101 Relative List (Rlist)

0110 Move Receiving Window (MRW)

0111 Move Receiving Window Acknowledgement (MRW_ACK)

1000 - 1111 Reserved (PDUs with this encoding are invalid)

figure 23 Super fields for RLC acknowledged mode status control.



The different SUFI data types are used for the following purposes: • NO_MORE : The NO_MORE data type is used to indicated the end of a STATUS

PDU. All information following this type will be regarded as padding. The NO_MORE data type consists out of the type indicator only.

• ACK : The ACK type is used for acknowledgement purposes and indicates the end

of the STATUS PDU too. Thus all information after this type is regarded as padding. The ACK data type consists out of type indicator and a 12 bit long sequence number LSN. All AMD PDU with a sequence number SQN < LSN that are not indicated to be erroneous in the same STATUS PDU will be acknowledged positively.

• WINDOW : The WINDOW data type consists out of the type indicator and a 12 bit

long window size WSN. The WSN is the new transmitter window size of the receiving entity. That means the WSN indicates the number of allowed unacknowledged AMD PDU in the direction of the sender of the STATUS PDU. In the window size of the AMD PDU sending in the other direction (= direction of the STATUS PDU) is not affected.

• LIST : The LIST super field consists of the type indicator and a length indicator LEN

(4 bits) and a list of LEN number of pairs. Each pair is composed out of a sequence number SNi (12 bit) that indicates an erroneous AMD PDU and a length Li (4 bit) that indicates how many AMD PDU after the PDU SNi are wrong too.



0 0 0 0NO_MORE

0 0 1 0ACK

LSN

0 0 0 1WINDOW

WSN

0 0 1 1LIST LEN

SN 1

L 1

SN (LEN)

L (LEN)

. . .

figure 24 Super fields: LIST, WINDOW, ACK and NO_MORE.



• BITMAP : The BITMAP super field is used for selective acknowledgements. It contains type indicator and a length indicator LEN (4 bit) and a sequence number FSN (12 bit). The bitmap contains positive and negative acknowledgements for AMD PDUs with a sequence number between FSN and FSN+(LEN+1)*8 – 1. The bitmap has therefore a length of LEN +1 octets. The acknowledgement is as follows :

+=+=

=receivedcorrectly not NFSNSN with PDU AMD 0

receivedcorrectly NFSNSN with PDU AMD 1 Nbit

• MRW : The MRW (move receive window) status indication is used to request the

receiver to move its receiving window without acknowledgements. This is typically done when the transmitter discards AMD PDU (e.g. congestion).

• MRW_ACK : This super field is used as an acknowledgement for a received MRW

status indication. • RLIST : The RLIST is another possibility to indicate erroneous received AMD PDU.



0 1 0 0BITMAP LENFSN

Bitmap

0 1 1 0 1 0 0 1. . .

FSN + 2 : positive ack

FSN + 1 : positive ack

FSN + 0 : negative ack

figure 25 BITMAP super field.



2.6 RLC Frame Formatting Examples

2.6.1 UMD PDU The first example is a UMD PDU that shall contain three different SDU with the following parameters : - SDU 1 with 4 octets,

- SDU 2 with 6 octets and - SDU 3 with 4 octets. This means the UMD PDU has to have three different length indicators for each SDU segment one. The target size of the UMD PDU for the available transport formats should be 20 octets, this will require padding at the end of the UMD PDU. We assume that the maximum length of the UMD PDU is less or equal than 125 octets, so 7 bit length indicators are used.



ZZZZZZZZ

ZZZZZZZZ

ZZZZZZZZSDU 3

ZZZZZZZZ

YYYYYYYY

YYYYYYYY

YYYYYYYY

YYYYYYYY

YYYYYYYY

SDU 2

YYYYYYYY

XXXXXXXX

XXXXXXXX

XXXXXXXXSDU 1

XXXXXXXX

End of SDU 3 at 14.octet, next octet is data00111000

End of SDU 2 at 10.octet, next octet is length indicator10101000

End of SDU 1 at 4.octet, next octet is length indicator10010000

UMD sequence no. 53, next octet is length indicator10010110

figure 26 UMD PDU containing three different SDU.



2.6.2 AMD PDU Formatting Example The example of an AMD PDU shall contains one SDU with 3 octets in length. Additionally the AMD PDU should acknowledge all AMD PDU up to sequence number 1041 (H`411), but for the AMD PDU 834 (H´342), 836 (H´344) and 837 (H´345) a negative acknowledgement shall be given. Therefore the AMD PDU will contain a piggybacked status PDU with a bitmap field and an acknowledgement super field inside.



00000000 Padding

00000000

10001000

SUFI 2 type = 0010 (ACK), FSN = H´411 = d´104100100100

Bitmap ( wrong are H´342, H´344 and H´345)11110010

01000010

PDU-type 000 (STATUS), SUFI 1 type = 0100 (BITMAP)00100000

Bitmap length 0000 (1octet), FSN = H´342=d´83411000000

00000000

XXXXXXXX

XXXXXXXX SDU

XXXXXXXX

Length: piggybacked STATUS inside, next octet is data00111111

Length: SDU ends at octet 3, next octet is length indicator11100000

P=0 (no status report requested), next octet is length ind.10001001

D/C=1 (AMD PDU), SN = H´232=d´56210001001

figure 27 AMD PDU formatting example.



2.7 RLC Modes for different Logical Channels Every radio bearer uses a RLC protocol instance in one of its three modes : transparent, unacknowledged or acknowledged. For some radio bearers it is possible that uplink and downlink use different RLC modes. A change of the RLC mode is possible by explicit radio bearer reconfiguration performed by RRC (with explicit signaling). Every radio bearer is also assigned a logical channel type, this restricts the usage of the different RLC modes in a radio bearer. The following behavior is defined for the control channels: • BCCH : The BCCH uses the transparent RLC mode exclusively. There is no

possibility for unacknowledged or acknowledged mode for a BCCH. • PCCH : For the PCCH the transparent mode can be used only. • CCCH : The CCCH can be mapped to two different transport channels. In the uplink

the CCCH uses the RACH with transparent RLC mode, in the downlink the CCCH is mapped to the FACH using the unacknowledged mode of RLC.

• DCCH : The DCCH is a bi-directional, point-to-point channel. Therefore the DCCH

can work in transparent, acknowledged and in unacknowledged mode. Which of the three RLC modes will be chosen, depends on the configuration done by RRC.

• SHCCH : The SHCCH is used in TDD mode as point-to-multipoint bi-directional

channel. In the downlink the SHCCH can use the FACH or DSCH with unacknowledged mode, in the uplink the SHCCH uses the RACH or USCH with transparent mode.

There are two logical traffic channels defined. The following holds: • CTCH : The CTCH can work in unacknowledged mode only.

• DTCH : The DTCH has like the DCCH all possible RLC modes for usage. It depends

upon the configuration done by RRC for radio bearer set up, which of the three modes will be used.



As one can easily see, there are only two logical channels where the RLC mode can be chosen freely – that are the dedicated logical channels DCCH and DTCH. The common logical channels have a fixed RLC mode to be used, it can only differ in uplink and downlink.

DLULSHCCH

XCTCH

DLULCCCH

XPCCH

XBCCH

CommonLogical

Channels

XXXDTCH

XXXDCCHDedicated

Logical

Channels

AMUMTrM

figure 28 Possible RLC modes for different logical channel types.



3 Packet Data Convergence Protocol PDCP



3.1 PDCP Tasks and Functions The Packet Data Convergence Protocol (PDCP) is used in the user plane on the air interface only. In fact the PDCP protocol provides some user data bearer service enhancements for packet switched traffic. Packet switched services in UMTS are organized according to the recommendation TS 23.060 (GPRS = General Packet Radio Service). This recommendation specifies a tunneling of packets of a network protocol (like IP or PPP) for an external data network through the UMTS/GPRS network. That means the IP datagram for the internet is a collection of data bits to be transported in the user plane bearers. The UMTS network will not evaluate the content of the IP datagram information. But for typical data networks the content in the network protocol is relatively constant (e.g. source and destination IP addresses). Therefore a compression algorithm to be applied to the control information of the network protocol (IP header) can increase the resource efficiency especially on the air interface. This is the task of PDCP : • header compression / decompression for the packet data network protocols,

• transfer of packet oriented user data using RLC transparent, unacknowledged or

acknowledged mode, • PDCP sequence numbering to support loss-less radio bearers. The PDCP protocol itself has no own procedure. The configuration of a PDCP protocol instance for a radio bearer is done by RRC procedures.



Network Protocol HeaderCompression

PDCP sequence numbering

Data Transfer

Packet Data Convergence Protocol (PDCP) functions




RRC

Logical Channels

Transport Channels

PDCP PDCP BMC

Radio Bearers

NAS signaling protocols NAS: user data streams

figure 29 PDCP functions and tasks.



The compression of the header of the network protocol (e.g. TCP/IP, RTP/UDP/IP, …) is specific to this protocol. Each radio bearer used for packet data transfer can be equipped with one or more compression algorithms or none. This means a for one radio bearer different algorithms can be applied. Hence the PDCP protocol will include a Packet Identifier (PID) in the transmission, to indicate the used compression algorithm. These PID values are specific for one radio bearer and their meaning is negotiated by RRC protocol and also depends on the compression protocol that is used. (Note: One compression protocol usually requires several PID.)



PDCP entity

ProtocolCompression

Algorithm Type 1

ProtocolCompression

Algorithm Type 2

PDCP entityProtocol

Compression Algorithm

Type 1

ProtocolCompression

Algorithm Type 2

PDU numbering

PDCP entity

ProtocolCompression

Algorithm Type 1

RLCUM TrMAM

figure 30 PDCP compression entities with diff erent stages of packet transfer capability.



3.2 Data Transfer with PDCP To transport a user data packet on a radio bearer with PDCP protocol instance, either acknowledged or unacknowledged/transparent RLC mode can be used. The difference between these modes is, that in acknowledged mode the RLC protocol will confirm the delivery of the packet to the PDCP protocol entity. The PDCP user itself is not notified about this.



ReceiverOriginator

PDCP user PDCP RLC RLC PDCP PDCP user

PDCP-Data.REQ RLC-AM-Data.REQ

AMD-PDU

PDCP-Data.IND

RLC-AM-Data.IND

AcknowledgementRLC-AM-Data.CNF

ReceiverOriginator

PDCP user PDCP RLC RLC PDCP PDCP user

PDCP-Data.REQ RLC-UM-Data.REQ

UMD-PDU

PDCP-Data.IND

RLC-UM-Data.IND(RLC-TrM-Data

.REQ) (TrM-PDU)(RLC-TrM-Data

.IND)

figure 31 PDCP data transfer in acknowledged and unacknowledged RLC mode.



The PDCP protocol defines three different PDU : • PDPC-No-Header PDU : This PDU contains pure data from the user. The PDCP

protocol will not add any overhead. It is used, when no PDCP functionality is to be applied.

• PDCP-Data PDU : The PDCP-Data PDU is used to transport user data packets

when compression, but no sequence numbering is used. Therefore this PDU includes a PID (Packet Identifier).

• PDCP-SeqNum PDU : This PDU is used for user data that requires header

compression (hence PID is included) and sequence numbering (so a 16 bit sequence number is included).

To distinguish the PDCP-Data and PDCP-SeqNum PDU a PDU Type field is used.

Bit PDU Type 000 PDCP – Data PDU 001 PDCP – SeqNum PDU

010 – 111 reserved (PDU with this field will be discarded in this version of the protocol).

To indicate the compression algorithm applicable for packet, the PID field is used. The values of the PID are assigned dynamically by RRC signaling (e.g. radio bearer set up and modification).

Bit Description 00000 No header compression used. 00001

- 11111

Dynamically negotiated header compression identifier.



Data

Data

Data

PDU Type PID

PDU Type PID

Sequence Number (16 bits)

PDCP-No-Header PDU

PDCP-Data PDU

PDCP-SeqNum PDU

figure 32 PDCP protocol frames.



3.3 PDCP Frame Formatting Example The next figure shows a PDCP protocol data unit. If one knows that the corresponding radio bearer uses the PDCP functionality, it is clear, that the first three bits indicate the PDU type. In the shown case, the PDU type is b´001 which indicates a PDCP-SeqNum PDU.



0 0 1 0 0 1 0 1 PDU – type (SeqNum), PDI = d´5 1 0 1 0 0 0 1 0 0 1 1 1 0 1 1 0

Sequence Number : H´A2 76

0 0 1 0 0 1 0 0 …

0 1 1 1 1 1 1 0

Data part

figure 33 PDCP PDU with sequence number for acknowledged mode.

V. Radio Resource Control Protocol RRC


Radio Resource Control Protocol RRC Module Objectives:

• RRC Functions and Tasks, • RRC Protocol States,

• RRC Connection Management,

• Handling of Signaling Connection to the Core Network,

• Security Mode Control,

• UTRAN Radio Resource Management,

• UTRAN Mobility Management,

• RRC Protocol Specification



1 RRC Tasks and Functions, RRC States



1.1 RRC Tasks and Functions The RRC protocol is the application part for the UMTS radio access technology. This means all controlling radio tasks are in the responsibility of RRC. In detail the recommendation defines the following RRC functions : • broadcast of system information for NAS stratum ,

• broadcast of system information for AS stratum , • establishment, maintenance and rel ease of RRC signaling between UE and

UTRAN connections , • establishment, reconfiguration and release of radio bearers , • RRC connection mobility functions , • Quality of Service (QoS) control , • UE measurement reports , • outer loop power control , • security control , • paging , • Initial cell selection and reselection , • transport of NAS stratum control messages . With all these tasks the RRC protocol belongs to the access stratum, where the application oriented control tasks are performed, and it belongs to the transport stratum, because it carries the higher layer control plane protocol messages.



System Information Broadcast

RRC signaling connection

Radio Bearer Control

RRC mobility handling

QoS control

Outer Loop Power Control

Security Mode Control

Paging

Initial Cell Selection / Reselection

Radio Resource Control (RRC) functions

NAS control message transfer

figure 1 Radio resource control functions prov ided by RRC protocol.



1.2 Usage of Radio Bearers for Signaling The RRC protocol uses the radio bearer service provided by the layer 1 and layer 2 of the UMTS radio interface. The radio bearers in an UE will be numbered from 0 to 31. The radio bearers 0, 1, 2, 3, 4 are pre-assigned for exclusive RRC usage. The following is specified : • RB 0 : The radio bearer 0 shall be used for all CCCH. As discussed in the section

before the CCCH in the uplink is mapped to the RACH with RLC transparent mode, whereas the downlink CCCH is mapped to the FACH with RLC unacknowledged mode.

• RB 1 : Radio bearer 1 is used for DCCH messages with RLC unacknowledged

mode. • RB 2 : RB 2 is used for all DCCH messages in RLC acknowledged mode, but not for

RRC messages that transport NAS messages inside. • RB 3 and optionally RB 4 : These two radio bearers shall be used for RRC

messages carrying NAS messages on DCCH in RLC acknowledged mode. The radio bearers 5, …, 31 can be used with explicit radio bearer set up for all purposes, e.g. traffic channels or control channels. For RRC messages the protocol specifies which RLC mode and with this which radio bearer can be chosen for transport of this message.



MAC

RLC(UM)

RLC(AM)

RRC

Control Channels

Radio Bearers

NAS signaling protocols

RLC(TrM in UL,UM in DL)

RB 0

RLC(AM)

RB 1 RB 2 RB 3

CCCH DCCH DCCH(RRC only)

DCCH(NAS)

figure 2 Usage of radio bearers for signaling purposes.



1.3 RRC Protocol States of a UE The RRC protocol is application part (radio resource management) and transport protocol (NAS message transport). Therefore the RRC protocol requires a state definition with transitions between the states. The RRC state definition describes the RRC protocol behavior as a nested set of states. Two main states are defined : • UTRA idle mode : In UTRA idle mode the UE has no signaling relationship with the

UTRAN. In this case the idle mode procedures, already described in this course, have to be applied. This means as far as the UE is switched on, it searches for PLMN and cells and listens to the broadcasted system information of selected cells.

• UTRA RRC connected mode : In the connected mode the UE has a signaling

connection with the UTRAN. The set up of this signaling connection is done by a RRC procedure (RRC connection set up). This procedure is the transition from idle to connected mode. When the RRC connection is released, the connected mode is left and the idle mode is entered.

For multi mode mobile phones (e.g. UMTS, GSM/GPRS) the RRC states can be combined with the radio resource management states of GSM/GPRS. In GSM/GPRS the states of a mobile can be : • idle mode : The idle mode of GSM/GPRS has the same meaning as the idle mode

of UMTS. The only difference is, that the UE is camped on a GSM/GPRS cell.

• GSM connected mode : In GSM the RR (radio resource layer) performs the radio management. This protocol can set up a RR connection between network and mobile equipment. When such a connection exists, the UE is in GSM connected mode. A GSM-DCCH is allocated for the UE in this case.

• GPRS packet transfer mode : In GPRS the radio resources are allocated for a

mobile temporary only. Such a temporary resource is called a temporary block flow. When a mobile is granted a temporary block flow, the UE is in GPRS packet transfer mode (GPRS-RLC state).

With a multi mode UE it shall be possible to in-service-transitions between the different radio access technologies (RAT). Therefore it is possible to make a inter-system handover from UTRA connected mode to GSM connected mode and vice versa. A



transition from UTRA connected mode to GPRS packet transfer mode is simply done by stopping the packet transfer in UMTS, making a cell reselection to a GPRS cell and getting a GPRS temporary block flow.

Idle Mode

UTRA idle mode GSM/GPRS idle mode

UTRAConnected Mode

GSMConnected

Mode

GPRSPacket

TransferMode

RRC connectionSet up

RRC connectionRelease

RR connectionSet up/Release

Inter-systemHandover

TBF set up/release

CellReselection

figure 3 Radio resource states of UE in UTRAN and GSM/GPRS.



The UTRA connected state can be further decomposed into four different states. These four sub-states describe, on which level the UE is known by UTRAN and which resources are allocated by the UE. UTRAN can know any UE either on cell level (CELL states) or on URA level (URA state). On the other hand any UE can have a DCH or a FACH or no transport channel for control message exchange. Therefore we have the following four connected states : • CELL_FACH : In this state the UE is known on cell level and the UE uses the FACH

transport channel to send DCCH and CCCH information. The state CELL_FACH is the only state, that can be entered from states without resources (idle state, URA_PCH, CELL_PCH). Especially this state is entered when the radio resource connection will be set up.

• CELL_DCH : When a UE is known on cell level and has a DCH transport channel,

the UE is in CELL_DCH state. This state can be entered from CELL_FACH, CELL_PCH and URA_PCH by setting up a DCH. When the last DCH is released the UE enters CELL_FACH, CELL_PCH, URA_PCH or idle mode.

• CELL_PCH : In this state the UE is still known by the UTRAN on cell level, but no

resources are used by the UE. The UE listens to the system information and the paging channel PCH only. In this state the RRC connection is maintained, but to exchange messages between UTRAN and UE a paging and a following transition to CELL_FACH (cell update) is necessary. This transition is the only possible one. In this state the UE will report all cell reselections to UTRAN (cell update).

• URA_PCH : This state is comparable to the CELL_PCH state, only that the UTRAN

knows the UE on URA level. The UE will report cell reselections only, when a new URA is entered (URA update). To reach the UE the UTRAN has to perform paging and the UE will enter CELL_FACH state (URA update).



URA_PCH CELL_PCH

CELL_FACH CELL_DCH

Idle Mode

UTRA idle mode

RRCconnection

setup

RRCconnection

release

InterSystem

Handover

RRCconnection

release

RRCconnection

setup

figure 4 UTRAN RRC States for the connected mode and their associated transitions.



2 RRC Procedures



2.1 RRC Connection Management

2.1.1 RRC Connection Establishment The aim of the intial random access performed by the UE is the set up of a signaling connection towards the RNC (serving RNC). This signaling connection is provided by the RRC protocol and is always the first RRC procedure that occurs after random access. The procedure is done in the following way : • When the UE wants to start a service, the RRC protocol layer will start create the

RRC message RRC CONNECTION REQUEST. This message contains an UE – ID (either IMSI or TMSI with old LAI or P-TMSI with old RAI) plus a cause value indicating the reason for the access. This message will be sent on the RACH in a TrM PDU (RLC).

• The network will on reception of this message perform admission control and in the

positive case will response with a RRC CONNECTION SETUP message. This message contains again the UE-ID, a transaction identifier (to identify the connection), a new RNTI (Radio Network Temporary Id) and a list of radio bearers (including transport channel and physical channel configuration) to be set up by the UE. Always a DCCH in acknowledged mode has to be set up. This message is sent by the network on the FACH using an UMD PDU (RLC).

• On the established DCCH (either on a DCH or a common transport channel) the UE

will now send the RRC CONNECTION SETUP COMPLETE message. This is always provided in a AMD PDU (RLC), which means this message requires an acknowledgement. In this message the UE will include its radio capabilities (RF capabilities, available security algorithms, UE positioning cap., measurement cap., multi-mode cap., …).

• Because the last message used a AMD PDU of RLC the network has to

acknowledge this message explicitly using a STATUS PDU or a piggybacked STATUS PDU of RLC.

The network can also reject the connection request. In this case the RNC shall issue a



RRC CONNECTION REJECT instead of a RRC CONNECTION SETUP message. In general this procedure implements the transition from state UTRA Idle Mode to UTRA Connected Mode. After the UE has sent the RRC CONNECTION REQUEST it is in CELL_FACH state. Depending on whether the RRC CONNECTION SETUP message granted a DCH or not, the UE is after the procedure still in CELL_FACH or in CELL_DCH state.

RRC CONNECTION REQUEST

( Initial UE-ID, establishment cause )

RRC CONNECTION SETUP

( Initial UE-ID, RRC transaction id, new U-RNTI, radio bearer list)

RRC CONNECTION COMPLETE

( RRC transaction id)

Menu

UE RNC

figure 5 RRC connection establishment,



2.1.2 RRC Connection Release In normal cases the RRC connection will be released explicitly by the UTRAN – RNC. The procedure shall be triggered when the UE is in state CELL_FACH or CELL_DCH. This procedure looks like the following : • When the serving RNC decides to release the RRC connection it will send the RRC

message RRC CONNECTION RELEASE . This message will be send on the DCCH of the UE or on a CCCH in unacknowledged RLC mode (UMD PDU). The CCCH is mainly used, when the UE is in CELL_FACH state. The message itself contains RRC transaction identifier, U-RNTI and a release cause. Additionally a counter (N308) is included, telling the UE how often the acknowledgement (see next step) of the RRC CONNECTION RELEASE shall be retransmitted.

• The behavior of the UE depends on state and logical channel of the RRC

CONNECTION RELEASE message. UE is in CELL_DCH & release received on DCCH : In this case the UE will send

N308 times the message RRC CONNECTION RELEASE COMPLETE on the DCCH using UMD PDU of RLC.

UE is in CELL_FACH & release received on DCCH : The UE will send the RRC CONNECTION RELEASE COMPLETE on the DCCH using AMD PDU of RLC. When the AMD PDU has been acknowledged by UTRAN the connection is released.

UE is in CELL_FACH & release received on CCCH : In this case the UE will

immediately release the connection, no further signaling is exchanged. Please note, that the UTRAN can repeat the RRC CONNECTION RELEASE message several times to increase the reception probability. How often and with which interval the message is repeated is network specific.



RRC CONNECTION RELEASE

( U-RNTI, RRC transaction id,Release cause, N308 )

RRC CONNECTION RELEASE COMPLETE

( RRC transaction id )

Menu

UE RNC

figure 6 RRC connection release.



2.1.3 Paging Type 1 Procedure There are two types of paging in UTRAN. The first type discussed in this section is the normal paging. It is to be applied in case the UE is in state UTRA Idle mode, CELL_PCH or URA_PCH on request of a higher layer. Typical trigger for this kind of paging are incoming service requests from the network (RANAP-paging) or the UTRAN wants the UE to read updated system information. This type of paging is performed by usage of the RRC message PAGING TYPE 1. This message is sent on the PCCH which allows transparent RLC mode only. The message contains a paging record, which is a list of the following elements : • paging cause (e.g. terminated conversational call, terminated signaling),

• CN domain indicator (PS or CS domain), • UE-ID (choice between IMSI, TMSI/LAI, PTMSI/RAI), • UTRAN-ID (U-RNTI). This set of information elements can be repeated up to 8 times, this means, up to 8 mobile subscribers can be paged in on PAGING TYPE 1 message. When a UE in UTRA idle mode receives a paging with its identifier, it shall start a random access to set up a RRC connection like discussed before. If the UE is in CELL_PCH or URA_PCH state when a PAGING TYPE 1 message is received, it shall perform a cell update (see later).



PAGING TYPE 1

( Paging record : UE-ID, U-RNTI, cause)

-- cell update –

or

-- RRC connection establishment --

Menu

UE RNC

figure 7 Paging Type 1 to request the establishment of a RRC connection or to request a cell update.



2.2 Iu Signaling Conn ection Management The signaling connection between UE and serving RNC (RRC connection) is only one connection used for signaling. The NAS (Non Access Stratum) protocols exchange signaling messages directly between UE and CN. Therefore signaling connections on the Iu interface between MSC and serving RNC or SGSN and serving RNC exist. These signaling connections are provided by the SCCP on the Iu-PS and Iu-CS interfaces. This means also that the UE can have multiple signaling connections (one on each Iu interface), but only one RRC connection

2.2.1 Iu Signaling Connection Establishment – Initial Direct Transfer

The set up of a signaling connection on an Iu interface is triggered by the UE. This is simply done by sending a message to the corresponding core network entity (MSC or SGSN). This first message to this CN entity will be packed into the RRC message INITIAL DIRECT TRANSFER . This message is always sent on the DCCH in acknowledged mode of RLC. The message itself contains • CN identity (either PS or CS core network),

• Intra Domain NAS Node Selector : This parameter is used to route the message

from the serving RNC to a special node in the core network. Typically this parameter is derived from PTMSI or IMSI or TMSI. But also the IMEI can be used.

• NAS message. The reception of this message from a subscriber triggers the serving RNC to set up an Iu signaling connection to the corresponding core network entity.



INITIAL DIRECT TRANSFER

(CN identity, Intra domain NAS node Selector, NAS message)

Signaling connectionSet up

(NAS message)

Menu

UE RNC CN

figure 8 Initial direct transfer procedure to set up a signaling connection towards one core network domain.



2.2.2 NAS Message Transport – Direct Transfer One of the tasks of the RRC protocol is to carry NAS messages transparently between core network and UE. The first step to this task is the set up of an Iu signaling connection as discussed before. When the Iu signaling connection exists the RRC protocol offers two messages that transport NAS messages to and from the CN. • DOWNLINK DIRECT TRANSFER : This RRC message carries NAS messages

received from a core network entity on the Iu interface within the corresponding Iu signaling connection. The important parameters of this message are the core network identity (PS or CS), the RRC transaction identifier and the NAS message itself.

• UPLINK DIRECT TRANSFER : This RRC message is sent by the UE to the serving

RNC. It contains the NAS message to be sent to the CN and the core network identity.

Both RRC messages are sent on the DCCH using acknowledged mode RLC. This means NAS messages are always sent with the highest possible reliability and also their sequence order is preserved. This is essential for the core network protocols.



UPLINK DIRECT TRANSFER

( CN identity, NAS message)

Signaling connectionMessage transport

(NAS message)

DOWNLINK DIRECT TRANSFER

( CN identity, NAS message,RRC transaction id)

Signaling connectionMessage transport

(NAS message)

Menu

UE RNC CN

figure 9 Direct transfer procedur e of RRC protocol for the transparent transport of NAS messages between UE and CN.



2.2.3 UE Dedicated Paging – Paging Type 2 This is now the second kind of paging provided by UTRAN. The UE dedicated paging is used for UE in CELL_FACH or CELL_DCH mode only. The aim of this procedure is to inform the subscriber about an incoming service request when in CELL_FACH or CELL_DCH mode. An example for this is a subscriber that has currently a signaling relation with a SGSN for a packet switched service (e.g. PDP context) and a circuit switched service is incoming. In this case the MSC, that handles the CS service, does not know that the user is already in connection with the UTRAN (for the PS service). Therefore the MSC will request a paging (RANAP procedure). It is up to the UTRAN, to decide whether a paging on the PCCH (PAGING TYPE 1) shall be used (this means the subscriber is idle or in a PCH state), or the paging shall be done on the currently used DCCH with the RRC message PAGING TYPE 2. This message is always sent on DCCH using acknowledged mode RLC. In the PAGING TYPE 2 message the RRC transaction identifier, a paging cause value and the CN identity that requested the paging can be found. What happens after the reception of a PAGING TYPE 2 message by the UE depends on the higher layers. Typically the UE will set up a signaling connection on the Iu interface towards the CN entity that requested the paging. This is of course done with an INITIAL DIRECT TRANSFER message containing a NAS message as answer to the paging.



PAGING TYPE 2

(RRC transaction id, paging cause,CN identity)

Paging Request

INITIAL DIRECT TRANSFER

(..., NAS message)

Signaling connectionSet up

(NAS message)

Menu

UE RNC CN

figure 10 Dedicated paging pr ocedure of RRC protocol to request the set up o f a signaling connection towards a core network domain.



2.2.4 Iu Signaling C onnection Release The signaling connection on an Iu interface is after set up controlled by the corresponding core network entity. Especially the release of an Iu signaling connection is always from the core network. But the UE shall be informed when a connection is to be released. So when the core network releases the Iu signaling connection, the RNC will notify the UE with the message SIGNALLING CONNECTION RELEASE . The message is sent on the DCCH of the UE in acknowledge RLC mode. It contains the RRC transaction identity and the core network identifier of the affected Iu signaling connection. On the other there has to be a possibility, that the UE requests the release of an Iu signaling connection. But there is no NAS protocol that is responsible for such a thing, therefore the serving RNC must work as an agent for the UE. This means, the UE can send the RRC message SIGNALLING CONNECTION RELEASE REQUEST to the serving RNC. This message is always on the DCCH using AMD PDU of RLC. The message contains the CN identifier only. With this the serving RNC will request the release of the Iu signaling connection from the core network entity (RANAP procedure: Iu Release Request). Whether the core network reacts on the message or not depends on MSC or SGSN. Normally the release of the last signaling connection of the Iu interface also triggers the serving RNC to release the RRC connection.



SIGNALLING CONNECTIONRELEASE REQUEST

( CN identity )

Iu signaling connectionrelease request

SIGNALLING CONNECTIONRELEASE

( RRC transaction id, CN identity )

Iu signaling connectionrelease

Menu

UE RNC CN

figure 11 Release of Iu signaling connection.



2.3 Security Mode Control When a signaling connection on an Iu interface to a core network entity exists, this core network entity can request the serving RNC to start encryption and integrity check on the link between UE and serving RNC. From the point of the core network this start signal is triggered by a RANAP message. On the air interface the serving RNC will send a SECURITY MODE COMMAND message to the UE. This message is sent within the DCCH of the UE using acknowledged RLC mode. The message contains indications, which algorithms shall be chosen for integrity protection and for encryption. Also the core network identity is included. When the UE is able to start the encryption it will send the SECURITY MODE COMPLETE message back to the serving RNC. If the security activation is unsuccessful a SECURITY MODE FAILURE message is sent instead. Both message use the DCCH with acknowledged RLC mode. This procedure can also be used to modify the security algorithms. Additionally the following rule is specified. The circuit switched user plane data streams are always encrypted/integrity protected with the keys, established during CS authentication. The packet switched user plane data streams always use the keys from the PS authentication. The control plane data streams will use the keys that hold for the last SECURITY MODE COMMAND message.



SECURITY MODE COMMAND

( CN identity, integrity andencryption algorithms )

Security Mode Command

( keys, algorithms )

SECURITY MODE COMPLETE


Security Mode Complete

( selected algorithms )

Menu

UE RNC CN

figure 12 Security feature activation procedure.



2.4 Example Procedure: Location Update A basic example for the discussed elementary procedures of RRC protocol layer are the core network based mobility management procedures like location update or routing area update. In this example we look to the location area update to the MSC. The procedure is triggered by the UE in idle mode, when from the broadcast information a new location area identity is detected. The following happens : 1. The UE starts a random access and request a RRC connection from the network.

The establishment cause will be originating, high priority signaling. The RRC connection will then be granted by the network and a dedicated channel will be assigned (! project specific).

2. After the RRC CONNECTION SETUP COMPLETE has been acknowledged by the

network, the UE will issue the NAS message Location Update Request. This will establish the signaling connection on Iu-CS interface. Therefore this message is packed into a INITIAL DIRECT TRANSFER message, which requires explicit acknowledgement.

3. The MSC will now start authentication. Because this is a pure core network related

procedure, we will see NAS messages in UPLINK and DOWNLINK DIRECT TRANSFER messages.

4. Now the core network triggers the encryption and integrity protection. But this time

the RNC is involved, so the RRC messages SECURITY MODE COMMAND and COMPLETE will be seen.

5. After the ciphering is activated, the result of the location update is sent to the UE.

This is the NAS message Location Update Accept, which contains a new TMSI. Therefore the UE will acknowledge it with TMSI Reallocation Complete, which is again a NAS message.

6. Now the MSC knows that it is the end of the procedure, so it will release the Iu

signaling connection. Hence the UE is notified with SIGNALLING CONNECTION RELEASE.

7. Because this was the only and so the last signaling connection of the UE, the RNC

decides to release the RRC connection too. So the UE gets RRC CONNECTION



RELEASE. The UE will then answer with RRC CONNECTION RELEASE COMPLETE, this message will be repeated as indicated in the message from the RNC. With this the procedure ends.

Of course this procedure can also be performed on a common transport channel. The main steps of the procedure remain.

[RACH:CCCH] TrM{RRC Connection Request }

[FACH:CCCH] UM{RRC Connection Setup }

[DCH:DCCH] AMD{RRC Conn. Setup Com. }

[DCH:DCCH] STATUS (ackn.)

[DCH:DCCH] AMD{Initial Direct Transfer }

[DCH:DCCH]

( CS – CN, Location Update Request )

Connection Request { Initial UE Message }

( Location Update Request )

STATUS (ackn.)

Connection Confirm { Direct Transfer }

( Authentication Request )

[DCH:DCCH] AMD{DL Direct Transfer }

( CS – CN, Authentication Request )

Data Form 1 { Direct Transfer }

( Authentication Response )

[DCH:DCCH] AMD{UL Direct Transfer }

( CS – CN, Authentication Response )

Data Form 1 { Security Mode Command }

( CK, IK, UIA, UEA )

[DCH:DCCH] AMD{Security Mode Command }

( CS-CN, UIA, UEA )

Data Form 1 { Security Mode Complete }

( selected algorithms )

[DCH:DCCH] AMD{Security Mode Complete }

( CS-CN )

Menu

UE RNC MSC

figure 13 Location update procedure – message sequence chart 1(2)




( Location Update Accept )


( CS-CN, Location Update Accept )


( TMSI Reallocation Complete )


( CS – CN, TMSI Reallocation Complete )

Data Form 1 {Iu Release Command}[DCH:DCCH] AMD{Sig.Connection Release }

Data Form 1 { Iu Release Complete }[DCH:DCCH] STATUS (ackn.)

Released signalling connection[DCH:DCCH] UMD{RRC Connection Release }

Release Complete[DCH:DCCH] UMD{RRC Conn. Rel. Complete }

[DCH:DCCH] UMD{RRC Conn. Rel. Complete }


Menu

UE RNC MSC

figure 14 Location update – m essage sequence chart 2(2).



2.5 UTRAN Radio Resource Management The radio resources on the UMTS air interface are divided into three steps : • radio bearers : A radio bearer describes a complete transmission capability with

properties (transport channels) and resources (physical channels). The radio bearer is what is used by the application oriented protocols (control plane, user plane).

• transport channels : A transport channel is the means, with which properties (data

rates, error correction, …) information is to be transferred over the air interface. Every radio bearer is multiplexed to one or more transport channels.

• physical channels : The physical channel describes the resource to be used for the

bit transmission. A physical channel is characterized by frequency, scrambling code and time slot (in case of TDD mode). Every transport channel is multiplexed to one or more physical channels.

It is up to the RRC protocol to configure these elements. Therefore the RRC protocol possesses procedures for • Radio Bearer Set Up : This procedure establishes a radio bearer including transport

and physical channels.

• Radio Bearer Reconfiguration : With this procedure the QoS (Quality of Service) of an existing radio bearer can be modified. This includes modifications of physical and transport channels.

• Radio Bearer Release : This procedure releases radio bearers and possibly

modifies associated transport and physical channels. Also the release of an Iu signaling connection can be indicated by this procedure.

• Transport Channel Reconfiguration : This procedure modifies a transport channel

used by an UE. This can also mean a modification of a physical channel. • Transport Format Combination Control : With this procedure the UTRAN can

control the use of transport format combinations (TFCs) from the set of allowed transport formats for the uplink transmission.



• Physical Channel Reconfiguration : This is used when the physical resource has

to be modified. The use of this procedure will not change transport channel or radio bearer directly. An important case where the physical channel reconfiguration is used, is the hard and soft handover.

• Active Set Update : This procedure enables the soft handover. The procedure is

used to add a radio link (means a physical transmission path for existing radio bearers) or to remove them


MAC

RLC


Logical Channels

Transport Channels

PDCP BMC

Radio Bearers

Physical Channelconfiguration

Transport Channelconfiguration

Radio Bearerconfiguration

figure 15 Radio resource hierarchy in UTRAN.



2.5.1 Radio Bearer Establishment The UTRAN can assign radio bearers to a UE by sending the RADIO BEARER SETUP message to the UE. This message is sent on the DCCH in unacknowledged or acknowledged mode. With this message the UE can be assigned up to 8 signaling radio bearers and up to 16 radio access bearers (RAB) for user plane usage. One radio access bearer (RAB) can consist of up to 8 radio bearers. The message then contains descriptors, how each radio bearer shall be configured with respect to the PDCP protocol, RLC protocol and which multiplexing of radio bearers onto which transport channels is allowed. The message can optionally provide a new U-RNTI (and C-RNTI). This is used in case of a serving RNC relocation. Additionally the RADIO BEARER SETUP message contains parameters to configure transport channels (e.g. transport formats and identifiers, transport format combinations and combination identifiers TFCI) and to configure the physical channels (e.g. scrambling code, channelisation code, frequency). When the UE receives this message it will perform the configuration (control links between RRC and lower layer protocols) and will send the RRC message RADIO BEARER SETUP COMPLETE in acknowledged mode on the DCCH. Hence this message requires explicit acknowledgement.



RADIO BEARER SETUP

( signaling radio bearers, radio access bearers,transport channels, physical channel )

RADIO BEARER SETUP COMPLETE


Menu

UE RNC

figure 16 Radio bearer set up procedure.



2.5.2 Radio Bearer Reconfiguration This procedure is used to change the configuration of already existing radio bearers or radio access bearers. The procedure runs in the same way as the radio bearer set up and the messages have the same parameters as the set up messages. Also this procedure can assign a new U-RNTI to the UE, which is used during relocation and hard handover to a new serving RNC. Again the RADIO BEARER RECONFIGURATION message is sent in unacknowledged or acknowledged mode on the DCCH. The UE will response with RADIO BEARER RECONFIGURATION COMPLETE , which is always sent in acknowledged mode on the DCCH.



RADIO BEARER RECONFIGURATION


RADIO BEARER RECONFIGURATION COMPLETE


Menu

UE RNC

figure 17 Radio bearer reconfiguration procedure.



2.5.3 Radio Bearer Release When a radio bearer or radio access bearer is no longer necessary, the network will transmit the RADIO BEARER RELEASE message to the UE. In the message the released bearers are indicated. Additionally transport and physical channels can be reconfigured or deleted. The message is also able to indicate a release of a signaling connection on the Iu interface (only used when the released connection is not the last one). This message is sent on the DCCH in acknowledged or unacknowledged mode. The UE will response to the command with the RRC message RADIO BEARER RELEASE COMPLETE , which is sent on the DCCH using acknowledged mode.



RADIO BEARER RELEASE


RADIO BEARER RELEASE COMPLETE


Menu

UE RNC

figure 18 Radio bearer release procedure.



2.5.4 Transport and Physical Channel Reconfiguration When the modification of the transmission parameters is restricted to the transport channels or the physical channels, the messages TRANSPORT CHANNEL RECONFIGURATION respectively PHYSICAL CHANNEL RECONFIGURATION can be used. Both messages are sent on DCCH using either acknowledged and unacknowledged mode. The UE has to response with TRANSPORT CHANNEL RECONFIGURATION COMPLETE respectively PHYSICAL CHANNEL RECO NFIGURATION COMPLETE . Both messages will be sent on DCCH using acknowledged mode.



PHYSICAL CHANNEL RECONFIGURATIONor

TRANSPORT CHANNEL RECONFIGURATION

( transport channels, physical channel )

PH.CHANNEL RECON. COMPLETEor

TR.CHANNEL RECON. COMPLETE


Menu

UE RNC

figure 19 Physical and transport channel reconfiguration procedure.



2.5.5 Active Set Update UTRAN provides the soft handover feature. This means the physical radio communication (radio link) is between one UE and one or more Node Bs. This is implemented in the following way : • The UE decodes the same data stream from several Node Bs with different

scrambling codes (RAKE receiver). This means, the UE has to add a new radio link in case of a soft handover situation.

• The uplink transmission from the UE is received by one or more Node Bs. But this

time the UE uses only one scrambling code. Hence the serving RNC has to inform all affected Node Bs about scrambling code of the UE.

The addition, removal or modification of radio links belonging to a radio bearer is done by the message ACTIVE SET UPDATE . This message is sent by the serving RNC to the UE using the DCCH in acknowledged mode. The message contains the new downlink scrambling codes and channelisation codes, plus the maximum allowed uplink transmission power. Because the message is also used to remove radio links, the same data is included for radio links that are no longer necessary. The UE has to acknowledge the ACTIVE SET UPDATE message with ACTIVE SET UPDATE COMPLETE , which is also sent on the DCCH in acknowledged mode.



ACTIVE SET UPDATE

( new radio links, radio links to be removed )

ACTIVE SET UPDATE COMPLETE


Menu

UE RNC

figure 20 Active set update procedure to add or delete radio links.



2.6 Radio Measurement Management To observe the quality of the radio links, the UE can be requested to send measurement reports for the following items: • intra-frequency measurements (quality and signal strength on the current

frequency), • inter-frequency measurements, • inter-radio access technology measurements (e.g. measurement of GSM

frequencies), • UE positioning measurements, • traffic volume measurements, • quality measurements. The serving RNC will request the UE to report these measurements with the MEASUREMENT CONTROL message, which is always sent in acknowledged mode on the DCCH. The UE will periodically report the measurements using the MEASUREMENT REPORT message. This message can be sent in acknowledged or unacknowledged mode. Which of the two modes will be chosen is defined in the MEASUREMENT CONTROL message.



MEASUREMENT CONTROL

( specification of measurements )

MEASUREMENT REPORT

( measurement results )

. . .

MEASUREMENT REPORT

( measurement results )

. . .

Menu

UE RNC

figure 21 Measurement control procedure and measurement reports.



2.7 Example Procedure: Circuit Switched Call As an example for the allocation of radio bearers the circuit switched call set up and its release with a hard handover in between will be shown. The complete call flow is divided into four parts : 1. Random access, RRC connection set up, Authentication, Ciphering and Call

request. 2. Call set up with radio bearer assignment and call answer. 3. Hard handover. 4. Call release. The first turn is the access until call request. This works in the following steps : a. The UE send RRC CONNECTION REQUEST to the network. The serving RNC will

answer with RRC CONNECTION SETUP including the establishment of a DCH for DCCH signaling. On the DCCH the UE will acknowledge will RRC CONNECTION SETUP COMPLETE, this message requires an explicit RLC acknowledgement.

b. Next the UE will trigger the set up of a signaling connection on Iu-CS with INITIAL

DIRECT TRANSFER. Inside is the mobility management message CM Service Request. The INITIAL DIRECT TRANSFER requires an explicit RLC acknowledgement.

c. The MSC will now trigger authentication. This will be performed by the two mobility

management messages Authentication Request and Authentication Response. Both are NAS messages that will use the direct transfer service of RRC.

d. After authentication the encryption will be started. Again this is triggered by the

MSC. The UE is notified with SECURITY MODE COMMAND and responses with SECURITY MODE COMPLETE. The last need RLC acknowledgement.



[RACH:CCCH] TrM{RRC Connection Request }

[FACH:CCCH] UMD{RRC Connection Setup }

[DCH:DCCH] AMD{RRC Conn. Setup Com. }


[DCH:DCCH] AMD{Initial Direct Transfer }

[DCH:DCCH]

( CS – CN, CM Service Request )

Connection Request { Initial UE Message }

( CM Service Request )

STATUS (ackn.)

Connection Confirm { Direct Transfer }

( Authentication Request )


( CS – CN, Authentication Request )


( Authentication Response )


( CS – CN, Authentication Response )

Data Form 1 { Security Mode Command }[DCH:DCCH] AMD{Security Mode Command }

Data Form 1 { Security Mode Complete }[DCH:DCCH] AMD{Security Mode Complete }


Menu

UE RNC MSC

figure 22 Circuit switched call – message sequence chart 1(4): access.



The second part is concerned with the call set up : e. With this the pure access procedure is completed and the call request can be

issued. Therefore the UE will send the call control message Setup to the MSC. The MSC will acknowledge the received call data with Call Proceeding. Both messages are directly transferred between UE and MSC.

f. After the call set up is initiated, the MSC will begin with routing of the call towards its

destination. Additionally the MSC can trigger the allocation of radio access bearers, that are necessary to support the call. The MSC will use the RANAP procedure RAB Assignment Request. On the air interface the RRC protocol will now set up a radio bearer for the call using the RRC message RADIO BEARER SETUP. When the radio bearer is activated, the UE can acknowledge with RADIO BEARER SETUP COMPLETE. This message again requires explicit acknowledgement.

g. The last step of the call set up is the notification that the B-party is reachable

(Alerting) and that the B-party answers the call (Connect and Connect Acknowledge). All three messages are NAS messages from the call control protocol. Therefore they will be transported in direct transfer messages.




( Setup )


( CS – CN, Setup )


( Call Proceeding )


( CS – CN, Call Proceeding )

Data Form 1 { RAB Assignment Response }[DCH:DCCH] AMD{Radio Bearer Setup Com. }

Data Form 1 { RAB Assignment Request }[DCH:DCCH] AMD{Radio Bearer Setup }



Data Form 1 {Direct Transfer}[DCH:DCCH] AMD{DL Direct Transfer }

( Alerting )( CS – CN, Alerting )


Data Form 1 {Direct Transfer}[DCH:DCCH] AMD{DL Direct Transfer }

( Connect )( CS – CN, Connect )


Data Form 1 {Direct Transfer}[DCH:DCCH] AMD{UL Direct Transfer }

( Connect Acknowledge )( CS – CN, Connect Acknowledge )

Menu

UE RNC MSC

figure 23 Circuit switched call – message sequence chart 2(4): call setup.



In the third part a hard handover should occur : h. To observe the signal quality, the network will request the UE to perform radio

measurements (intra-frequency or inter-frequency) for this cell and surrounding cells (measured by their CPICH). Therefore the RNC sends the MEASUREMENT CONTROL message to the UE. This message requires explicit RLC acknowledgement. The UE will now perform the measurements and will send the result in the MEASUREMENT REPORT message to the RNC.

i. The RNC will evaluate the measurement reports will decide, whether a handover is

necessary or not. If yes, all necessary resource will be prepared in the new cell (and possibly in the new RNC, new MSC). When everything is ready the UE will get the PHYSICAL CHANNEL RECONFIGURATION (or any of the other reconfiguration messages). Inside can be a new U-RNTI, new C-RNTI and the new physical channel parameters (frequencies, scrambling codes, channelisation codes). The UE will now configure its physical layer to the new parameters – this is the hard handover. In the new cell the UE will then reset its RLC instance and will send the PHYSICAL CHANNEL RECONFIGURATION COMPLETE message. This is already the end of the handover for the UE.



[DCH:DCCH] AMD{Measurement Control }


[DCH:DCCH] UMD{Measurement Report }

[DCH:DCCH] UMD{Measurement Report }

...

...

[DCH:DCCH] UMD{Physical Channel Reconfiguration }

[DCH:DCCH] AMD{Physical Channel Reconfiguration Complete }


Menu

UE RNC

figure 24 Circuit switched call – messag e sequence chart 3( 4): hard handover.



In the last part of the call flow, the release of the call is shown. j. The UE sends the call control message Disconnect to indicated the end of the call.

This triggers the MSC to send Release and Release Complete. k. So the call ended, therefore the resources are no longer necessary. The MSC will

therefore release all Iu-CS resources including the Iu-CS signaling connection. This is done by a RANAP procedure Iu Release Command. On the air interface the RADIO BEARER RELEASE will be sent to the UE. After the radio bearer release the Iu signaling connection release will be indicated to the UE and because it is the last signaling connection, the RNC will also release the RRC connection.




( Disconnect )


( CS – CN, Disconnect )


( Release )


( CS – CN, Release )

Data Form 1 {Iu Release Command }[DCH:DCCH] AMD{Radio Bearer Release }


Released

[DCH:DCCH] UMD{RRC Connection Release}

Data Form 1 {Direct Transfer}[DCH:DCCH] AMD{UL Direct Transfer }

( Release Complete )( CS – CN, Release Complete )

Data Form 1 {Iu Release Complete }[DCH:DCCH] AMD{Radio Bearer Release Com. }

Release Complete

[DCH:DCCH] AMD{Sign. Connection Release }




Menu

UE RNC MSC

figure 25 Circuit switched call – message seque nce chart 4(4): call disconnect and release.



2.8 UTRAN Mobility Management In contrast to GSM, where the BSS (Base Station Subsystem) has very low mobility handling capabilities, the UTRAN offers its own mobility management for UE in UTRA connected mode. The UTRAN can know the UE on three different levels : • UE is unknown (UTRA idle mode),

• UE is known on cell level (CELL_DCH, CELL_FACH or CELL_PCH), • UE is known on URA (UTRAN Registration Area) level (URA_PCH). Like location or routing area update to the core network, also the UTRAN offers procedures to update the location. In UTRA idle mode this is not possible, because there is no RRC connection. In CELL_DCH the change of the cell is associated with a handover. This means the UTRAN connects the reconfiguration of air interface resources (radio bearer, transport channel, physical channel) with the mobility management. In CELL_FACH, CELL_PCH states the UE has no dedicated transport channel, thus a handover is not necessary. Instead when changing the cell the UE will stop transmission on the common resource, if there is any, and will perform a cell update . With the cell update the UTRAN is informed about the new location. Possibly new resources will be allocated and the can resume traffic if necessary. In URA_PCH state the UE is also not assigned a dedicated resource, thus also here a handover is not necessary. In this state the UE also will not use any common transport resource. But the RRC connection is still active. The UE will not report any cell change, but when it enters a new URA, it will perform a URA update . This allows the UTRAN to track the location of the UE. With these procedures associated is the UTRAN mobility information procedure. It is used after cell or URA change or when the serving RNC has been changed to provide the UE with new identifiers, in detail a new U-RNTI and a new C-RNTI can be assigned by this procedure.



HandoverCell UpdateURA Update

RNC

Menu

UE

figure 26 UTRAN mobility handling procedures.



2.8.1 Cell and URA Update Procedure When the UE enters a new cell (in CELL_PCH or CELL_FACH) or a new URA (in URA_PCH) it will issue the RRC message CELL UPDATE respectively URA UPDATE . Both messages are sent on the CCCH (means on RACH) in transparent mode. The message are sent to the new cell. The response to the update will come from the UTRAN on the corresponding FACH. The UTRAN will use the message CELL UPDATE CONFIRM or URA UPDATE CONFIRM respectively. In the cell update confirmation message the possibly new serving RNC can provide a new U-RNTI, and the controlling RNC can provide a new C-RNTI for this cell. Additionally radio bearers, transport channels and physical channels can be deleted, reconfigured or added. The URA UPDATE CONFIRM can assign a new U-RNTI only. The response of the UE to the confirmation message depends on its content. The UE shall send : • RADIO BEARER RELEASE COMPLETE : if radio bearer release has been

requested in the confirmation message,

• RADIO BEARER RECONFIGURATION COMPLETE : if radio bearer modification is requested in the confirmation message,

• TRANSPORT CHANNEL RECONF. COMPLETE : if no radio bearer, but transport

channel modification has been requested, • PHYS. CHANNEL RECONF. COMPLETE : if no radio bearer, no transport channel,

but a physical channel reconfiguration has been requested, • UTRAN MOBILITY INFORMATION CONFIRM : if no resources are modified by the

confirmation message, but a new C-RNTI or a new U-RNTI or new security information is provided.

The response from the UE is always sent on the DCCH using acknowledged mode. When nothing changes, there is no need for a response from the UE.



CELL UPDATEor

URA UPDATE

CELL UPDATE CONFIRMor

URA UPDATE CONFIRM

( radio bearer to be deleted, radio bearer reconfiguration,transport channel reconfig., phys.channel reconfig.

U-RNTI, C-RNTI, security info )

RADIO BEARER RELEASE COMPLETERADIO BEARER RECONF.COMPLETE

TRANSP.CHANNEL RECONF.COMPLETEPHYS.CHANNEL RECONF.COMPLETE

UTRAN MOBILITY INFORMATION CONFIRM----

Menu

UERNC

figure 27 Cell and URA update procedure.



2.8.2 UTRAN Mobility Information The UTRAN can also change C-RNTI, U-RNTI or security information (algorithms for encryption and integrity protection) without a cell change. Therefore the UTRAN will issue a UTRAN MOBILITY INFORMATION message on the DCCH in acknowledged or unacknowledged mode. The message contains optional the parameters new C-RNTI, new U-RNTI or new security info for the mobile. The UE shall acknowledge the UTRAN MOBILITY INFORMATION message with the message UTRAN MOBILITY INFORMATION CONFIRM , which sent on the DCCH in acknowledged mode. This procedure is necessary, when the serving RNC changes without being directly related to a handover.



UTRAN MOBILITY INFORMATION

( new U-RNTI, new C-RNTI, new security information)

UTRAN MOBILITY INFORMATION CONFIRM

Menu

UERNC

figure 28 UTRAN mobility information procedure.



3 RRC Message and Parameter Specification



3.1 RRC Protocol The description of all RRC messages can be found in recommendation TS 25.331. The section 10 contains the message definition in so called human readable form. The section 10 is organized in the following way : • 10.1 is a general introduction to the notation,

• 10.2 contains a RRC messages with its parameters, • 10.3 contains the parameter definitions : 10.3.1 CN related information elements,

10.3.2 UTRAN mobility information elements,

10.3.3 UE related information elements,

10.3.4 Radio Bearer information elements,

10.3.5 Transport Channel information elements,

10.3.6 Physical Channel information elements,

10.3.7 Measurement information elements,

10.3.8 Other information elements,

10.3.9 ANSI-41 information elements (related to US American core network

specification), 10.3.10 Multiplicity values (constants describing how many parameters can be

used in a parameter list). The message decoding itself is defined in section 11. Here the messages and parameters are defined again, but this time is ASN.1 (Abstract Syntax Notation 1 – specified by ITU-T X.680). The definition here is structure in modules. The encoding itself is defined by ITU-T recommendation X.690. The RRC protocol uses the Packed



Encoding Rules (PER).

10.1 General about the notation

10.2 RRC message definition

10.3.1 CN related parameters

10.3.2 UTRAN mobility parameters

10.3.3 UE related parameters

10.3.4 Radio bearer parameters

10.3.5 Transport channel param.

10.3.6 Physical channel param.

10.3.7 Measurement parameters

10.3.8 Other information elements

10.3.9 ANSI-41 parameters

10.3.10 Multiplicity values

TS 25.331

10.3 Parameter Definition

figure 29 Section of RRC protoc ol relevant for the message and parameter definition.



3.1.1 Example of Parameter and Message Definition As an example the UTRAN MOBILITY INFORMATION message is shown on the next page. The first things that can be seen is a short description of the function, the RLC modes, the logical channel and the direction that is applicable for the message. Then a table contains the possible parameters that are used in the message. The first row contains the names of the parameters. The second row indicates whether the parameter has to be present or not. This field can take the following values : • MP : Mandatory Present, • MD : Mandatory Default (this parameter has takes a default value if not present), • CV : Conditional on Value (this means, that a parameter has to be present or must

not be present, depending on other parameter values in the message), • CH : Conditional on History (whether the parameter must or must not be present

depends on preceding messages), • OP : Optional. The next field is used in case of lists. A list is a parameter container, that has zero, one or several times the same parameter sequence inside. The Multi field indicates how many parameters are possible. Here also a range can be specified, e.g. 1 to <constant>. The value in the brackets is a constant that can be found in section 10.3.10. The row Type and Reference describes which type definition is to be used for the parameter and in which section of the recommendation this type definition can be found. The last field is used for remarks and general descriptions in informal language format. Some of the parameter names in the first row have one or several > in front of the name. A > indicates, that the parameter is contained in the parameter having one > less in front of the name. For instance the parameter >>RB with PDCP information belongs to the parameter >RB with PDCP information list. This parameter itself is contained in the Downlink counter synchronization info. The bold face parameter names do not indicate a real parameter, rather they are remarks, that divide the parameter into groups



for easy reading. 10.2.62 UTRAN MOBILITY INFORMATION This message is used by UTRAN to allocate a new RNTI and to convey other UTRAN mobility related information to a UE.

RLC-SAP: AM or UM

Logical channel: DCCH

Direction: UTRAN→UE

Information Element/Group name Need Multi Type and reference Semantics description Message Type MP Message Type UE Information Elements Integrity check info CH Integrity check info

10.3.3.16

RRC transaction identifier MP RRC transaction identifier 10.3.3.36

Integrity protection mode info OP Integrity protection mode info 10.3.3.19

Ciphering mode info OP Ciphering mode info 10.3.3.5

New U-RNTI OP U-RNTI 10.3.3.47 New C-RNTI OP C-RNTI 10.3.3.8 UE Timers and constants in connected mode

OP UE Timers and constants in connected mode 10.3.3.43

CN Information Elements CN Information info OP CN Information info

full 10.3.1.3a

UTRAN Information Elements URA identity OP URA identity

10.3.2.6

RB Information elements Downlink counter synchronisation info

OP

>RB with PDCP information list OP 1 to <maxRBallRABs>

This IE is needed for each RB having PDCP in the case of lossless SRNS relocation

>>RB with PDCP information MP RB with PDCP information 10.3.4.22

figure 30 Human readable tabular format of message specification - example.



When a more detailed look into the message parameters is necessary, the reference specifies the section in which the parameter definition can be found. An example from the message UTRAN MOBILITY INFORMATION is the new U-RNTI. This parameter is of type U-RNTI which is specified in section 10.3.3.47 of recommendation TS 25.331. If one looks to this section the table on the next page can be found. It defines the U-RNTI as a structure that consists out of two mandatory (MP) elements : S-RNTI and serving RNC identity. These two parameters are defined as bit-strings with a certain length, used to encode the parameter value.



10.3.3.47 U-RNTI The U-RNTI (UTRAN Radio Network Temporary Identity) is allocated to a UE having a RRC connection and identifies the UE within UTRAN.

Information Element/Group name

Need Multi Type and reference

Semantics description

SRNC identity MP bit string(12) S-RNTI MP bit string(20)

figure 31 U-RNTI parameter specification.



Another example for a RRC parameter is the Frequency Info described in TS 25.331 section 10.3.6.36. The frequency info consists of a parameter that is equipped with the keyword CHOICE in front of the parameter name. This indicates that one and only one of the parameters that belong to this type has to be selected and transmitted. In the example the frequency info consists either of the FDD or the TDD parameter (both parameters have one >). The FDD parameter consists of UARFCN (UMTS Absolute Radio Frequency Channel Number) uplink and downlink. The TDD parameter has one common UARFCN.



10.3.6.36 Frequency info

Information Element/Group

name Need Multi Type and

reference Semantics description

CHOICE mode MP >FDD >>UARFCN uplink (Nu) OP Integer(0..1

6383) If this IE is not present, the default duplex distance defined for the operating frequency band shall be used [21]

>>UARFCN downlink (Nd) MP Integer(0 .. 16383)

[21]

>TDD >>UARFCN (Nt) MP Integer(0 ..

16383) [22]

figure 32 Frequency information parameter specification.

VI. Iu Interface Control Plane – SCCP and RANAP


Iu Interface Control Plane – SCCP and RANAP

Module Objectives:

• General architecture and tasks of Iu interface,

• Broadband SS7 Protocols MTP3B and SAAL,

• Signaling Connection Control Part SCCP – Procedures,

• Radio Access Network Application Part RANAP – Procedures,



1 Iu Control Plane Protocol Stack



1.1 Inter-working between Iu and Uu Interface The Iu interface is located between UTRAN and the core network CN. As discussed in the very beginning of this course, the Iu interface has to fulfill access and transport related tasks. The bearer services of the Iu interface are provided by ATM. The adaptation layers of type 2 and type 5 are applicable. The signaling is transported using AAL 5 exclusively. Therefore two additional protocols are placed in the signaling protocol stack to get a suitable signaling bearer. These two protocols are SAAL (Signaling ATM Adaptation Layer) and MTP3B (MTP level 3 Broadband) . The interesting protocols on Iu are SCCP and RANAP . The SCCP is mainly used to set up and release Iu signaling connections. The RANAP protocol is the application part of Iu, this means, RANAP provides functions and procedures for access and transport control specific to UMTS. Therefore RANAP is closely related to the RRC protocol on Uu. The SCCP signaling connections are triggered by the UE (using RRC message INITIAL DIRECT TRANSFER). So a SCCP signaling connection on Iu is always related to the corresponding RRC connection of the UE. The Iu interface can occur in the versions Iu-PS, Iu-CS and Iu-BC (Broadcast). For one UE there can be at most one signaling connection on Iu-CS and at most one signaling connection on Iu-PS. The RNC that terminates the Iu signaling connections for one UE is always the serving RNC of this UE.



Iu - CS

Iu - PS

RRC RANAP

SCCP

(Signaling)Bearer

Protocols

(Signaling)Bearer

Protocols(RLC, MAC, PHY) (MTP3B, SAAL,

AAL5, ATM, PHY)

Menu

UE

3G-MSC

3G-SGSN

servingRNC

figure 1 Relation between air interface pr otocol RRC and Iu si gnaling protocols.



1.2 Iu Interface for PS Domain Iu-PS and CS Domain Iu-CS and their Tasks

The Iu interface provides the necessary communication definition between core network and UTRAN. As there are two independent core network domains, also two different Iu interfaces are specified. Towards the SGSN (PS domain) the Iu-PS interface is used, between MSC/VLR (CS domain) and UTRAN the Iu-CS interface is defined. The main concept of handling a UE by the UMTS network is the uniqueness of responsibility. This means, that only one RNC is responsible (serving RNC) and at most one MSC/VLR and at most one SGSN control the UE with respect to the demanded services. This directly implies, that for one UE at most one Iu-CS and at most one Iu-PS interface exists. Both possible communication lines Iu-CS and Iu-PS are handled for one UE in the serving RNC. A very special property of the Iu interface is, that it is independent of the underlying transmission technology and also independent of the radio access technology or the core network service it is used for. This independence allows changes in technology with future developments in telecommunications. On the other hand this introduces a lot of abstract concepts into the protocols, which leads sometimes to some difficulties in understanding the interface.



3G-MSC3G-SGSN

RNCRNC

Node B Node B Node B Node B

Menu

UE

Iu PS Iu CS

CN

UTRAN

figure 2 Iu-PS and Iu-CS interface.



The Iu interface has to support the following functions: • NAS signaling transport between UE and CN, • resource management, • handling of multiple core network domains, • cell broadcast service, • serving RNC relocation. Additional the Iu interface shall support location services. This means that the core network is provided with information about the location of subscribers.



Serving RNC Relocation

Iu Interface tasks

Multiple CN Domains

Resource ReservationTransparent Transport of

NAS Signaling

Handling of Iu signalingconnections Location Reporting

UE Identity Transfer Security Activation

figure 3 Iu interface tasks.



1.3 Iu Interface Protocol Architecture The control plane of the interfaces Iu-CS and Iu-PS are the same. In both the signaling bearer service is provided by ATM with the adaptation layer AAL5. This is an asynchronous, connectionless service for data transport. To enhance this bearer with functions for in-sequence delivery and congestion handling, the signaling ATM adaptation layer SAAL is used. On top of SAAL the MTP3B (Message Transfer Part level 3 Broadband) is used. This protocol performs signaling message routing and network management. Whether the MTP3B is really necessary for routing depends on the specific network. In typical implementations there will be a direct AAL5 virtual path from RNC to the core network entity, such that a MTP3B routing has no effect. But also in this case the MTP3B is necessary to support the SCCP (Signaling Connection Control Part). This protocol allows connectionless and connection-oriented transfer services for higher layer messages. This protocol will be discussed in detail. On top of SCCP the RANAP (Radio Access Network Application Part) protocol provides the messages and procedures for the Iu interface. In fact all the mentioned functions of the Iu interface will be performed by RANAP.



Radio Network Layer

Transport NetworkLayer

RANAP

AAL5

SCCP

MTP3B

SAAL

ATM

Physical Layer

Control Plane CS/PS Domain

User Plane

AAL5AAL2

IP

UDP

GTP-U

Iu UPprotocol

Iu UPprotocol

PSCS

figure 4 Iu interface protocol architecture.



2 Iu Signaling Network Protocols



2.1 Broadband SS7 Protoc ols MTP3B and SAAL ATM allows a very flexible network configuration with the concept of virtual channels . A virtual channel is an end-to-end layer 2 connection between two ATM end-points. The virtual channel has a predefined path through the ATM network that will be defined during set up. The switching of such a virtual channel in ATM is done link-by-link using Virtual Path Identifier (VPI) / Virtual Channel Identifier (VCI) . When an ATM cell is sent by an ATM switch it will contain VPI/VCI in its cell header. The receiving ATM switch will analyze VPI/VCI and look up in a table (for the corresponding input port) and find out the VPI/VCI for the next link and the associated output port. This is what is called ATM switching. The advantage is that it can be implemented near to the hardware, and so it is very fast. With this concept it is possible to configure end-to-end links over very big distances. Also this kind of switching is completely transparent to higher layers. Thus a very flexible network topology can be obtained from ATM. But the virtual channel that is established in this way is a low level transport service only. To make the virtual channel suitable to the application's need, every virtual channel is assigned to a special adaptation layer. The adaptation layer describes the transmission characteristics. The ATM cell is the transport frame of ATM. On the physical link a constant (synchronous) cell stream is running all the time. ATM will multiplex all virtual channels that go over this link to this cell stream. The asynchronous component of ATM is now, that there is no fixed timing scheme for the multiplexing. Instead ATM will schedule the different virtual channels according to the quality of service profile and their traffic volume. This concept allows ATM to serve variable bit rate services, but you can never tell which ATM cell will carry which virtual channel data. When we will use ATM for signaling transport it is necessary to note that ATM can discard cells and can disorder cells in case of fail-over procedures. For SS7 user parts such a behavior cannot be accepted. Thus we will need very special adaptation layers for SS7 signaling transport over ATM.



ATM

AALx AALx

ATM user ATM user

Virtual Link Virtual Link

Virtual Channel

VPI 1; VCI 1 VPI 2; VCI 2

Incoming Outgoing

VPI VCI Input Port VPI VCI Out. Port

1 1 A 2 2 B... ...

ATMATM

VPIVCIPTCLP

PayloadATM cell

12163148*8

HEC

8

figure 5 ATM virtual channel connections and ATM switching.



ATM currently defines four different adaptation layers to enhance the basic transmission service and to describe the ATM user traffic characteristics (Quality of Service). These four adaptation layers are called AAL (ATM Adaptation Layer) and are labeled in the following way: ” AAL type 1 (AAL1) : AAL1 is a stream oriented transport service, so there no

message or frame boundaries of the ATM user preserved during transmission. The traffic characteristics of AAL1 virtual channel is that of a constant bit rate stream. The virtual connections are usually purely point-to-point. AAL1 enables a synchronous transmission of ATM networks and is widely used for ISDN speech transmission.

” AAL type 2 (AAL2) : AAL2 is like AAL1 stream oriented, but supports streams that run on a variable bit rate. AAL2 become more and more important and is expected to completely substitute AAL1 in future. AAL2 is very interesting for speech codecs with voice inactivity detection or for multi-rate codecs (AMR) like the ones used in GSM/UMTS.

” AAL type 5 (AAL5) : AAL5 is a message oriented protocol (but can also support stream oriented services). This means AAL5 is very suitable when the ATM user produces data in forms of messages or frames. Also AAL5 supports variable bit rate streams, but is especially adopted to handle traffic that comes in bursts. AAL5 virtual channels are usually point-to-point, but can also configured for point-to-multipoint topology.

Additionally ATM defines AAL type 3/4, but we will not need it here. The AAL5 service is very suitable for signaling transport, but AAL5 does not give any reliability (backward error correction).



AAL type 1 AAL type 2 AAL type 5

-stream oriented

- constant bit rate

-Point-to-point(connections)

-stream oriented

- variable bit rate

-Point-to-point(connections)

-message oriented(stream oriented possible)

- variable bit rate- bursty traffic

-Point-to-Point(connectionless)or- Point-to-Multipoint

ATM virtual channel transport characteristics(ATM Adaptation Layers)

figure 6 ATM adaptation layers and their characteristics.



To transport SS7 signaling messages over ATM one searches for a way with minimal amount of changes in already existing protocols. The easiest way doing this is the following. Broadband SS7 will keep the basic architecture of SS7 networks and will substitute the PCM timeslots by ATM virtual channels. Therefore the main protocol of broadband SS7 is still ” MTP3B (MTP level 3 Broadband) : Main protocol of SS7 remains MTP level 3 with

its functionality for message handling (routing and distribution) and signaling network management. Only the network management is slightly modified to be conform with the new transmission technology. Routing is still the same, except the result of routing is no longer a timeslot of a PCM line, instead as result of a routing process one will get an ATM virtual channel used for signaling transport.

The major change concerns MTP level 2 and level 1, because they do no longer exist. Instead they are replaced by an ATM virtual channel with the following signaling bearer protocols to adapt the ATM transfer service to MTP3B's needs. ” AAL5 : The transmission characteristics of signaling coming from MTP3B is

obviously message oriented and the traffic is bursty. Hence AAL5 is used to adjust the support of such traffic.

” SAAL (Signaling ATM Adaptation Layer) : As already explained, AAL5 does not provide reliability. This is the task of SAAL layer.

SAAL together with AAL5 characterize the virtual channel as a (virtual signaling link). An interesting part of SAAL is its upper layer interface towards MTP3B. To keep the basic implementation of a MTP level 3, SAAL offers exactly the same primitives as MTP level 2. So there was no need to design a new MTP level 3.



SAAL

AAL5

SAAL

AAL5

SAAL

AAL5

SAAL

AAL5

SAAL

AAL5

SAAL

AAL5

(Virtual Channel)

. . . . . .

MTP Level 3 (Broadband)

MTP3B

MTP Level 3 (Broadband)

MTP3B

MTP3B

SAAL

MTP level 2/level3 interface

figure 7 SS7 message routing in an ATM environment.



The SAAL layer mainly substitutes MTP level 2 and therefore overtakes the tasks of it. In detail this is: ” Reliable Message Transfer : This task splits into : Message Delimitation : SAAL provides frames to delineate the messages. Error Detection : AAL5 provides error check on transmitted SAAL messages and

reports errors that occur to SAAL. Error Correction : In case of reported errors from AAL5 SAAL will trigger the

retransmission of the erroneous messages. In-Sequence Delivery : SAAL applies a send sequence number N(S) for each

transmitted message, which is used for acknowledgement and retransmission, but also to deliver messages in sequence.

” Signaling Link Status Control : Like MTP level 2 also SAAL has to monitor the

availability of the remote end and has to observe the quality of the signaling link. Signaling Link Erro r Rate Monitoring : SAAL counts the errors that occur on

the signaling within a certain time. Alignment of Signaling Link : SAAL utilizes special link status messages to

synchronize the link status information with its peer protocol. ” Flow control : SAAL is able to indicate load congestion information to its peer to stop

or enable sending of new data frames. Within the SAAL DATA frame there will be the well known information elements of MTP level 3, as there are SIO, routing label and data field. The MTP user data field can have a length of up to 4096 octets. The SAAL protocol information is included in the SAAL frame as trailer.



Flow Control

Signaling Link Status Control

Reliable Message Transfer Message Delimitation

Error Detection (performed by AAL5)

Error Correction

In-Sequence Delivery

Local Congestion Indication

Signaling Link Error Rate Monitoring

Alignment of Signaling Links

SAAL tasks and functions, SAAL Sequenced Data PDU

User dataMTP3

Routing LabelSIOPaddingPL

PL : Padding LengthN(S) : Send Sequence No.

SPARE

PDUTypeN(S)

832, 40 or 44<= 4096 octets0,8,16 or 2424 4 2 2

figure 8 SAAL frame transporting a SS7 signaling message reliably.



2.2 Signaling Connection Control Part SCCP

2.2.1 SCCP Modes of Operat ion and Prot ocol Classes The SCCP protocol provides signaling bearer service functions. Two possible modes are possible for the transport of signaling messages : • connectionless : The connectionless mode transports every signaling message

using a high level routing address (global title). This address has to be translated in intermediate nodes to find the end destination.

• connection oriented : In case a signaling message is transported in connection

oriented mode, a signaling connection is set up in the beginning of the communication. During this connection set up, the message path is determined and a pair of connection identifiers is exchanged.

Both modes will now be divided further into so called protocol classes: • Protocol Class 0 : This protocol class is a connectionless service where each

message gets an individual routing. This means when two messages 1 and 2 are send with this class 0, it can happen that message 2 arrives before message 1.

• Protocol Class 1 : Like protocol class 0 also protocol class 1 is connectionless. In

contrast to class 0 it is now up to the higher layer to define message groups. The SCCP will guarantee that all messages within one group will get the same routing through the network, such that the message sequence order remains untouched.

• Protocol Class 2 : Protocol class 2 is a connection oriented service. This service

guarantees the in-sequence delivery of signaling messages that belong to the same signaling connection.

• Protocol Class 3 : Protocol class 3 is like the class 2 a connection oriented service,

and all messages belonging to one connection will be delivered in-sequence. Additionally the protocol class 3 provides mechanisms for flow control and backward error correction.



The protocol class 3 is usually not used in communication networks. The class 2 will be used by RANAP for messages that are dedicated to a certain UE. For common RANAP messages not specific to a certain UE the protocol class 0 will transport the messages. The protocol class 1 is not used by RANAP, but for instance TCAP within the circuit switched core network uses this service.

SCCP Modes of Operation

single messagewith individual routing

messagegroupswith commonrouting

signalingconnectionswith uniformrouting

signalingconnectionswith uniformrouting and messagenumbering

Connectionless ModeConnection-oriented

Mode

ProtocolClass 0

ProtocolClass 1

ProtocolClass 2

ProtocolClass 3

figure 9 SCCP operation modes and protocol classes.



2.2.2 Connection-oriented SCCP Procedures A new SCCP connection is necessary, whenever signaling needs to be exchanged between UE and CN transparently and no such connection already exists. The connection is normally established by the radio network controller RNC. In some situations (S-RNC relocation) also the core network can set up a SCCP connection. In both cases the connection set up will be requested with the SCCP message CR (Connection Request) . This message is transported in together with the MTP3B routing label which contains source and destination address for the connection (DPC, OPC). In the CR message itself the SSN (Subsystem Number) can be found. This SSN indicates the protocol that is on top of the SCCP, on the Iu interface the SSN will always be H´8E = RANAP. Additionally this message contains a source local reference, which is a 3 octet long number used to identify the originator process of the message within the originator device (e.g. RNC or MSC or SGSN). The CR message contains usually a RANAP message. When the other side receives the CR it has to decide whether it wants to establish the connection or not. In the first case the SCCP message CC (Connection Confirm) shall be sent. This message contains now two local references. As destination local reference the reference from the other side will be used. Also the node that sends the CC message will allocate a local reference and include it as source local reference. If the connection shall not be established, the node that receives the CR message will send CREF (Connection Refused) instead of CC.



CR (SSN=RANAP, source LR=x, RANAP msg.)

PositiveAcknowledgement

NegativeAcknowledgement

CC (source LR=y, destination LR=x,RANAP msg. optional)

CREF (destination LR=x, RANAP msg. or not)

LR : Local Referencex = reference of RNCy = reference of CN

or

RNC MSC/SGSN

figure 10 SCCP connection establishment.



As long as the SCCP connection exists, both sides can send user messages from RANAP inside of the logical signaling connection. The message transport is done by SCCP using the message DT1 (Data Form 1) , which is used for protocol class 2 signaling connections. The use of a signaling connection makes addressing of the higher layer message extremely simple. In a DT1 one will always find the destination local reference, which is the reference value allocated by the receiver of the message. This enables the receiver to assign the message from the DT1 to a process that shall handle the higher layer message. When one of the two nodes of a signaling connection want to release it, the message RLSD (Released) shall be used. This message can contain a last higher layer message and will contain both local references. The other side will on reception of the RLSD message send RLC (Release Complete) to acknowledge the end of the signaling connection.



DT1 (destination LR=y, RANAP msg.)

SCCP connectionrelease

DT1 (destination LR=x, RANAP msg.)

RLC (destination LR=y, source LR= x)

LR : Local Referencex = reference of sending sidey = reference of receiving side

RLSD (destination LR=x, source LR=y)

RNC MSC/SGSN

connection-oriented messagetransfer

figure 11 SCCP connection-oriented data transmission and connection release.



2.2.3 SCCP Connectionless Signaling Pr ocedures In case of a connectionless signaling transport the higher layer messages will be send without a fixed signaling relation between sender and receiver. In case of the Iu interface this concerns RANAP messages that are not related to a specific UE. This is typically the case for all RANAP messages between CN and RNC. The RANAP message that is used of connectionless transport of signaling messages is called UDT (Unit Data) . This message contains a called address and a calling address for routing. Both messages are SCCP address formats, that can contain MTP3B addresses (Signaling Point Codes), SSN (Subsystem Numbers) or global titles (GT). Two other variants of the UDT message exist, the XUDT (extended UDT) and LUDT (Long UDT) message. The UDT message can contain a higher layer message with a size of up to 255 octets. If a higher layer message is longer than this, it can be segmented into pieces smaller than 255 octets and each segment will be transported in one XUDT message. With the usage of ATM broadband technology the message LUDT can support the SCCP connectionless service for higher layer messages with a size of up to 64 Kbytes. One LUDT can carry up to 3954 octets, if the higher layer message is bigger, it has to be segmented. There is no acknowledgement for UDT, XUDT or LUDT message. But in the messages there is a parameter to indicate whether the message shall be returned in case of errors (e.g. routing failure) or not. If this parameter is set to true, the erroneous message will be returned to the originator in a UDTS (UDT Service) , XUDTS (XUDT Service) or LUDTS (LUDT Service) message. The service messages include a cause value that indicates the reason for the return of the message.



UDT (called address, calling address, user msg.)

NegativeAckn.

UDTS ( called address, calling address,user msg., cause)

connectionlessdata transmission

RNC MSC/SGSN

figure 12 SCCP connectionless messages.



2.2.4 SCCP Addresses The SCCP protocol is standardized by the ITU-T and exists since the dawn of CCSS7. The task of the SCCP is the message transport through a signaling network, hence the SCCP needs an addressing mechanism to route signaling messages. On the Iu interface the SCCP is responsible to transport RANAP messages between core network and radio network controllers. RANAP will use for one UE and one CN domain (PS or CS) one signaling connection of SCCP for messages dedicated to this UE. This directly implies that for one UE it is possible to have zero, one or two SCCP signaling connections. But at most one signaling connection to one CN domain is supported. To establish such a connection the CR message of SCCP has to be routed from the RNC to the correct core network entity (MSC or SGSN). The same problem holds for the UDT messages, that also need an addressing. The SCCP address format consists of three (optional) elements: Signaling Point Code (SPC = MTP address), Subsystem Number (SSN) and Global Title (GT). Which combination of these elements will be used is partly standardized and partly project specific. For the RANAP messages the Subsystem Number SSN has to be present and shall be set to the value H´8E (=RANAP). The use of the global title GT is optional, but if a GT is included in a message it shall have type 4 with numbering plan NP, nature of address NA and translation type TT. The numbering plan on the Iu interface is always the ISDN telephony numbering plan (E.163/164, NP=H´1). The corresponding translation type is TT=H´00 (unknown translation type) and the nature of address NA=H´01 indicates a international number format. The use of a SPC is also optional.



67 5 4 3 2 1 0

Global Title present / TypeSub.pres.

SPCpres.

Rtg. Ind.0

00SPC

Subsystem Number

Translation Type (TT)

Numbering Plan (NP) Encoding Scheme

O/E Nature of Address

3. digit

2. digit 1. digit

4. digit

AddressIndicator

figure 13 SCCP address format.



2.2.5 SCCP Message Formatting The formatting of SCCP messages is described by ITU-T Q.713, which divides the message elements into three groups : • (F) parameters that are mandatory and have a fixed length, • (V) parameters that are mandatory and have a variable length, • (O) parameters that are optional. The SCCP message contains always first of all the F-parameters with their value only. This means there is no information element identifier and no length indicator, hence the sequence order of F-parameters has to be fixed by the protocol. The next are the V-parameters. After the last F-parameter a pointer to each V-parameter can be found. The sequence order of the pointers is again fixed by the protocol. Each pointer value indicates the distance between pointer and the parameter in bytes. The F-parameter itself contains first a length indicator, then the parameter value. When there are optional elements allowed for a message after the last pointer to a V-parameter the pointer to the optional part will come. If this pointer is H´00 there are no optional elements in the message. If it is not H´00 the pointer indicates the begin of the optional part. In the optional part the parameters are encoded with a information element identifier first, a length indicator second and the parameter value last. When the information element identifier H´00 is met, the end of the optional part is indicated. Each SCCP message has a standard element in the beginning. Hence this parameter is a mandatory one and it is also fixed in length (1 octet). This parameter is the message type. So when one meets a SCCP message, it is all the time clear that the first octet indicates the SCCP message that is transmitted. This enables the receiver to look to the protocol specification and find out what is the meaning of the rest of the message.



Message type

Mandatory parameter A

Mandatory parameter F

Pointer to parameter M

Pointer to parameter P

Pointer to the optional part

Length indicator parameter M

Mandatory parameter M

Length indicator parameter P

Mandatory parameter P

Identifier parameter X

Length indicator parameter X

Optional parameter X

Identifier parameter Z

Length indicator parameter Z

Optional parameter Z

End of the optional part

F

V

O

fixed order

figure 14 SCCP message format layout.



The table on the next page contains some of the message types and some information element identifiers for the optional part.



Message Type Code

CR Connect Request 0000 0001 = H' 01

CC Connect Confirm 0000 0010 = H' 02

CREF Connect Refused 0000 0011 = H' 03

RLSD Released 0000 0100 = H' 04

RLC Release Complete 0000 0101 = H' 05

DT1 Data Form 1 0000 0110 = H' 06

UDT Unit Data 0000 1001 = H' 09

UDTS Unit Data Service 0000 1010 = H' 0A

XUDT Extended Unit Data 0001 0001 = H’11

XUDTS Extended Unit Data Service 0001 0010 = H’12

figure 16 Message type coding (excerpt from Q.713).

Parameter Code

Called Party Address 0000 0011 = H' 03

Calling Party Address 0000 0100 = H' 04

Credit 0000 1001 = H' 09

Data 0000 1111 = H' 0F

Hop Counter 0001 0001 = H’11

figure 15 Information element identifier coding for optional parameters (excerpt from Q.713).



As an example let’s look to the message CR. This message is specified like all other SCCP message in form of a table in ITU-T Q.713. This table lists all the parameters that are defined for this message. For the mandatory parameters the sequence order of the list is also the sequence order in the message. The table first indicates the parameter name (e.g. message type code), then a reference section where a detailed description of this parameter can be found. After the reference the type of the parameter will be indicated (F-, V- or O- parameter). Last a specification how long the parameter (with identifier and length indicator if applicable) can be. One can see that the CR message contains always the message type, the source local reference, the protocol class and the called party address. The rest of the parameters is optional. Well some of them are only applicable for certain protocol classes (e.g. Credit for protocol class 3) or in certain situations (e.g. calling party address in case the connection is between foreign networks). The second message shown is UDT. Here the same principles apply as for the CR. The table specifies the possible and mandatory parameters. One can see that this time the calling party address is mandatory. Indeed no optional elements are defined for a UDT, hence there will no pointer to the optional part in a UDT message.



Parameter § Type (F V O) Length (octets)

Message type code 2.1 F 1

Source local reference 3.3 F 3

Protocol class 3.6 F 1

Called party address 3.4 V 3 minimum

Credit 3.10 O 3

Calling party address 3.5 O 4 minimum

Data 3.16 O 3-130

Hop counter 3.18 O 3

Importance 3.19 O 3

End of optional parameters 3.1 O 1

figure 18 CR message specification in tabular format (excerpt from Q.713).

Parameter § Type (F V O) Length (octets)

Message type 2.1 F 1

Protocol class 3.6 F 1

Called party address 3.4 V 3 minimum

Calling party address 3.5 V 3 minimumb)

Data 3.16 V 2-Xa)

figure 17 UDT message specification in tabular format (excerpt from Q.713).



The figure on the next page shows an example for a formatted SCCP message. It is a CR that shall be used to set up a SCCP connection between RNC and SGSN or MSC. When we look to the protocol stack on Iu interface, then it will be seen that RANAP is on top of SCCP, hence this message transports a RANAP message. The formatting specification of the CR message is printed above. From the corresponding table we can find that first comes the message type code which is one octet in length. The CR message has the message type code H´01. After the message type comes the source local reference which is mandatory and of fixed length (3 octets). Hence the next three octets contain the value of the source local reference without any identifier or length indicator. The next element in the table is the protocol class, also this element is mandatory and of fixed length (1 octet). As we use only protocol class 2 here, the value of the protocol class parameter is H´02. With that all F-parameters have been discussed. The next mandatory element is the called party address, which proves to be a V-parameter. So what we will find in the message is now a pointer to the called party address. With that all mandatory elements are in the message, but the protocol still defines optional parameters for a CR. Therefore a pointer to the optional part must be included in the message. In the example the pointer is H´00 which means that there are no optional elements in the message. Now it is time to care about the calling party address. The pointer to this element is H´02, thus the second octet after the pointer is the beginning of the calling party address. As this element is variable in its length the first octet of the parameter is a length indicator (1 octet always) indicating how long is the parameter value. This is here 2 octets for the calling party address. The calling party address is structured according to the general addressing format. So the next octet is the address indicator that defines that there is no SPC (bit 0 = 0), there is a SSN (bit 1 = 1), there is no global title (bits 2..5 = H´0) and the routing is based on the SSN (bit 6 = 1). This immediately defines the meaning of the next octet, it is the SSN. Because RANAP is transported in SCCP on the Iu interfaces, the SSN has the value H´8E for RANAP.



SourceLocal

Reference

Message type CR

Protocol class 2

Pointer to the Called Party Address

Pointer to the optional part = 0

Length Called Party Address = 2

Address indicator

Subsystem RANAP

0 0 0 0 0 0 0 1

0 0 0 0 0 0 1 0

0 0 0 0 0 0 1 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 1 0

0 0 0 0 0 01 1

1 0 0 0 1 1 1 0

figure 19 Message formatting example.



3 Radio Access Network Application Part RANAP



3.1 General The Iu interfaces for MSC (Iu-CS) and for SGSN (Iu-PS) possess the same control plane which provides the UMTS specific signaling protocols. The corresponding application part protocol is RANAP (Radio Access Network Application Part) . As the name says, RANAP enables the core network to communicate with the UTRAN (RNC). RANAP is on top of SCCP and hence uses the connection-less and connection-oriented services of SCCP. RANAP procedures can be categorized into three big groups : • procedures that transport higher layer (NAS) signaling between UE and CN (e.g.

MM, CM, GMM protocols), • procedures that trigger radio specific actions for a special UE, hence the RNC and

the RRC protocol are directly involved (e.g. radio access bearer allocation) and • procedure for general control of the Iu interface (e.g. overload handling).



RANAP RANAP

SCCP SCCPRRCRRC

RLCRLC

MACMAC

PHYPHY

MTP3B MTP3B

SAAL SAAL

AAL5 AAL5

ATM ATM

Relay

MM,CM,

GMM

MM,CM,

GMM

M enu

UE

MSC

SGSNRNC

figure 20 General control plane protocols on Iu and relation to radio protocols.



The RANAP protocol offers services implemented as signaling procedures. These signaling procedures use the SCCP for the signaling message transport. To decide when to use a connection-less and when to use a connection-oriented SCCP transport service, RANAP divides its services in three groups:

- General Control : General control services are not specific to an individual UE. Moreover the general control services are related to the Iu interface as a whole. Typical procedures of general control are for instance overload handling, reset procedure, error indication. The general control services use the connection-less signaling service of SCCP.

- Notification : Notification services are related to specified UEs or all UEs in a

certain area. The typical notification service is the paging procedure. Notification services use the connection-less signaling service of SCCP.

- Dedicated Control : Dedicated control services are specific to one and only one

UE. Therefore the dedicated control service messages are sent in a SCCP connection associated with that UE.



RANAPGeneral Control Notification Dedicated Control

SCCP

UnitData UnitData Data

UDT UDT DT 1CRCC

MSC/SGSNRNC

figure 21 RANAP services and usage of SCCP operation modes.



As explained, dedicated RANAP messages will be sent in connection-oriented SCCP mode. This means the Iu signaling connection has to exist. A pre-requisite for the establishment of an Iu signaling connection is the RRC connection between UE and RNC. This RRC connection will be set up during random access of the UE to the network. When the RRC connection exists, there can be • no Iu signaling connection (then there is no dedicated RANAP service possible), • one Iu signaling connection (either with MSC or SGSN), • two Iu signaling connections with MSC and SGSN. As it can be seen, the Iu signaling connection and the RRC connection together form a signaling link between UE and MSC/SGSN. Especially the NAS (Non Access Stratum) messages between UE and CN will use this signaling link for message transfer. On the Uu interface the NAS messages are packed into RRC messages and on the Iu interface there are sent in RANAP messages. The RNC which sits in between has to relay from RANAP to RRC and back. When an Iu signaling connection between RNC and MSC/SGSN exists, the UE will be identified by this connection. This means the local references of SCCP that uniquely determine a SCCP connection, also uniquely identify the UE for the time of the existence of the connection.



Iu Signalling Connection

RANAP RANAP

SCCP SCCPRRCRRC

RLCRLC

MACMAC

PHYPHY

MTP3B MTP3B

SAAL SAAL

AAL5 AAL5

ATM ATM

Relay

MM,CM,

GMM

MM,CM,

GMM

RRC connection

M enu

UERNC

MSC

SGSN

figure 22 Iu signaling connections.



3.2 RANAP Functions The task of RANAP is to enable the core network to trigger access related actions, like radio access bearer assignment. This means RANAP is UTRAN specific and not CN specific. But RANAP is designed as an abstract protocol, this means, RANAP does not rely on a very detailed knowledge about UTRAN, instead RANAP treats the access network as general as possible. On result from this is the radio access bearer concept. The following functions are provided by RANAP to give the CN some control over UTRAN: • S-RNC relocation : The serving RNC is the controlling point within UTRAN for one

UE. The serving RNC is the only element the CN will see for this UE. When the S-RNC changes the CN is affected by this, hence the relocation procedure must be controlled by MSC/SGSN.

• RAB management : The CN handles the services the user requested. So the CN

has to tell the UTRAN to establish a bearer service from UE to CN – the radio access bearer.

• Iu signaling conn ection management : RANAP is the protocol that uses SCCP

connections for dedicated signaling, so it is the one that triggers the set up and the release of Iu signaling connections.

• CN triggered paging : When there is no Iu signaling connection, but a service is

incoming for a UE, the CN triggers the RNC to perform paging. • Iu overload control : When the CN is in a overload condition it must indicate this to

the RNC to reduce traffic. Note that the Iu bearer belongs to the radio access bearer which is physically controlled by the RNC and not by the CN.

• Reset of Iu interface : If there is a failure in UTRAN or CN the Iu interface can be

reset. • NAS message transfer : The RANAP protocol carries NAS messages as dedicated

messages over the Iu interface.



• Security mode control : The security features (encryption, integrity protection) are running from UE to serving RNC. The CN has to trigger the activation of these features.

S-RNC Relocation

RAB Management

Iu Signaling ConnectionManagement

NAS message transfer

Iu Overload Control

Reset of Iu Interface

CN triggered Paging Security Mode Control

figure 23 RANAP Functions.



3.3 RANAP Procedure Classes For the RANAP services several elementary signaling procedures are defined. These elementary signaling procedures follow a classical request-response pattern. Three different behaviors are defined for elementary procedures, these behaviors are categorized into procedure classes: • class 1 : The procedure class 1 is the standard pattern. The initiator of the procedure

sends a request and immediately starts a timer to observe the procedure. The receiver of the request message will evaluate it and possibly perform some action and will answer with a positive or negative response message. When the timer expires and no such response message is received by the initiator an implicit negative acknowledgement is assumed.

• class 2 : The procedures of class 2 have a request message only. No response

message is defined and needed. (Typically the response is another procedure request in the backward direction.) Hence there is also no timer needed here.

• class 3 : Procedures of class 3 combine several sub-requests into one request

message. Again the initiator of the procedure starts a timer to observe the procedure. The receiver of the request message has to evaluate all sub-requests, process them and has to send an individual response message for each sub-request. When the timer expires all outstanding responses are assumed to be negative.



Request

Response (positive or negative ackn.)

timer

time out = implicit negative acknowledgement

Class 1

RequestClass 2

Request


timer

time out = implicit negative acknowledgement

Class 3



RNCRNC

figure 24 RANAP procedure classes and associated timer supervision.



3.4 RANAP Signaling Procedures

3.4.1 Initial UE Message The first message MSC/SGSN will get from a UE is the RANAP message Initial UE Message . This message is originally triggered by the UE. When the UE wants to send a message to MSC or SGSN it will issue the RRC message Initial Direct Transfer in the corresponding RRC connection to the RNC. In the Initial Direct Transfer message the UE will include • CN Domain Indicator : indicates PS or CS core network domain, • intra domain node selector : indicates which MSC/SGSN to choose, • NAS-PDU: a higher layer message for the CN entity. The RNC will now request a Iu signaling connection (SCCP connection) to the specified core network entity. This means it sends the SCCP message CR (Connection Request). Inside the CR the RANAP message Initial UE Message is included. The Initial UE Message contains • LAI and for PS domain the RAC, • SAI (Service Area Identity), which substitutes the cell ID that was used in GSM, • NAS – PDU from the RRC message, • global RNC-ID, • Iu signaling connection identifier, which acts like the SCCP local references but is

now on RANAP level. The core network has to evaluate the CR with the Initial UE Message and can respond with CC to confirm the Iu signaling connection or with CREF to reject the Iu signaling connection.



RNC CN

RRC: Initial Direct Transfer(CN domain indicator,

intra domain NAS node selector,NAS-PDU)

CR [ Initial UE Message ](LAI, RAC, SAI, NAS-PDU,

CN domain ind., global RNC-ID, Iu signaling connection id)

Me nu

UE

figure 25 Establishment of Iu signaling connections.



3.4.2 Direct Transfer To send further NAS messages in an existing Iu signaling connection the RANAP message Direct Transfer is used. This message can be sent to/from the RNC and is always in connection-oriented SCCP transmitted. This means the Direct Transfer message comes within a DT1. (Note that the downlink Direct Transfer can also be sent in a CC.) The uplink Direct Transfer is triggered by the RRC message Uplink Direct Transfer which comes from the UE. The RRC message contains a CN domain indicator (PS or CS) and the NAS – PDU. The RANAP message Direct Transfer takes over the NAS – PDU and adds the LAI, RAC, SAI. In the downlink the Direct Transfer message contains the NAS-PDU from the CN and a SAPI (Service Access Point Identifier) which is used by the RNC to perform a priority scheduling of downlink signaling messages. The NAS-PDU is then relayed to the RRC message Downlink Direct Transfer which additionally includes the CN domain indicator.



RRC: Uplink Direct Transfer(CN domain indicator,

NAS-PDU)DT1 [ Direct Transfer ](LAI, RAC, SAI, NAS-PDU)

RRC: Downlink Direct Transfer(CN domain indicator,

NAS-PDU)

DT1|CC [ Direct Transfer ](SAPI, NAS-PDU)

RNC CN

Me nu

UE

figure 26 Direct transfer procedure to transport NAS messages.



3.4.3 Security Mode Control The security features in UMTS cover encryption of signaling and data and integrity protection of signaling messages. These two features are available between UE and serving RNC. When the CN wants to trigger activation of the security features, it will send the RANAP message Security Mode Command . This message is sent within the SCCP connection of the UE. It contains a list of permitted algorithms UEA (UMTS Encryption Algorithm) and UIA (UMTS Integrity Algorithm) and the keys CK (Cipher Key) and IK (Integrity Key). When the serving RNC receives the RANAP message Security Mode Command, it will select one UEA and one UIA from the list of permitted algorithms within the message. Which algorithms will be selected depends on the UE radio access capabilities, that determine which algorithms the UE supports. The RNC gets this information from the UE during set up of the RRC connection. When this is done, the RNC will start the security feature with the RRC message Security Mode Command. This message contains the selected algorithms. If the UE can obey the command it will response with the RRC message Security Mode Complete. In the RNC this message triggers the RANAP message Security Mode Complete which informs the CN about the selected algorithms. If the security functions can not be activated, the message Security Mode Reject will be used instead. PS and CS core network domain can activate the security independently of each other. The following rule is used for co-ordination in the serving RNC: • PS user data will always be encrypted with the PS key IKPS from SGSN, • CS user data will always be encrypted with the CS key IKCS from MSC, • signaling will be encrypted and integrity protected with the keys of the last issued

Security Mode Command.



RRC: Security Mode Command(Integrity Algorithm,

Encryption Algorithm)

DT1 [ Security Mode Command ](permitted Integrity Algorithms UIA,

permitted Encryption Algorithms UEA,IK, CK)

RRC: Security Mode Complete( ) DT1 [ Security Mode Complete ]

(chosen UIA, chosen UEA)

RNC CN

M enu

UE

figure 27 Security mode activation procedure.



3.4.4 Iu Signaling Connect ion Release by CN When the Iu signaling connection is no longer needed it will be released. Typically it is the CN that detects that an Iu signaling connection is not needed any more. The criteria is that the last service that was active in MSC/SGSN is terminated. In this case the MSC/SGSN will send the RANAP message Iu Release Command within the SCCP connection of the UE to the RNC. The RNC will now inform the UE with the RRC message Signaling Connection Release. In the same moment all radio access bearers that are associated to the corresponding SCCP connection will be released. When this is done, the RNC sends back Iu Release Complete . In this message the identifiers of all now released RABs are indicated together with the transported data volume for PS bearers. Now the CN can release the SCCP connection with RLSD and RLC.



RRC: Signaling Connection Release

(CN domain indicator)

DT1 [ Iu Release Command ](cause)

DT1 [ Iu Release Complete ]( released RAB IDs,

RAB data volume report )

RLSD(cause : SCCP user originated)

RLC

RNC CN

Menu

UE

figure 28 Release of Iu signaling connections.



3.4.5 Iu Signaling Connection Release by RNC or UE It is also possible that UE or RNC trigger the release of a SCCP connection. If the UE wants release it, it will send the RRC message Signaling Connection Release Request to the RNC. The RNC will now issue the RANAP message Iu Release Request . The MSC/SGSN should now respond in the same way like before.



RRC: Signaling Connection Release DT1 [ Iu Release Command ]

DT1 [ Iu Release Complete ]

RLSD

RLC

RRC: Signaling ConnectionRelease Request

DT1 [ Iu Release Request ](cause)

(CN domain identity)

RNC CN

M enu

UE

figure 29 Release of Iu signaling conn ection triggered by UE or RNC.



3.4.6 Paging When MSC or SGSN want to send signaling or downlink data (from a PDP context) to the UE but no SCCP connection exists for this UE, paging will be triggered. The CN entity then sends the RANAP message Paging in a SCCP message UDT to the RNC. The paging message contains IMSI (mandatory) and optional a temporary identifier like TMSI or PTMSI. Also the CN has to tell the RNC in which area the paging shall be performed – this can be LAI or RAI. The RNC will now send a paging message. Two possibilities exists here: • the UE currently has a resource allocated from this RNC (UTRAN state CELL_DCH

and CELL_FACH) : In this case the serving RNC will send the RRC message Paging Type 2 on the dedicated control channel to the UE.

• the UE has currently no resource allocated from this RNC (UTRAN states IDLE,

CELL_PCH and URA_PCH) : If this holds, the RNC will send the RRC message Paging Type 1 on a normal paging channel.

If the UE receives the paging it will response to this with a NAS message to the corresponding core network domain. In other words the CN will receive an Initial UE Message from this UE as answer to the paging.



3.4.7 Example Procedure: Location Update The following is the complete sequence for a location update, that shows the usage of RANAP. On the Iu interface between MSC and RNC the SCCP with RANAP and possible NAS messages are shown. On the Uu interface only the highest layer is printed. The procedure has the following steps: 1. After random access to the UTRAN the UE sends its first NAS message (Location

Update Request) to the MSC. Hence the serving RNC packs it into the Initial UE Message which is sent in a CR of SCCP. So the Iu signaling connection will be established now. The following CC completes the connection set up.

2. Before the MSC processes the update it will authenticate the user. Therefore the

MM-messages Authentication Request and Authentication Response are used. Both messages belong to the NAS protocol MM, hence the Direct Transfer message of RANAP is used for transport on Iu.

3. When the user is successfully authenticated, the following communication shall be

encrypted. Therefore the MSC activates the security features with Security Mode Command and it gets back Security Mode Complete.



RNC

MM: Authentication Request CC [ Direct Transfer ]

MM: Location Update Request CR [ Initial UE Message ](new LAI, SAI, Location Update Request )(old LAI, old TMSI, MS classmark)

(Authentication Request )(CKSN, RAND, AUTN)

MM: Authentication Response DT1 [ Direct Transfer ]( Authentication Response )(old LAI, old TMSI, MS classmark)

RRC: Security Mode Command DT1 [ Security Mode Command ](permitted UIA, permitted UEA, CK, IK)(UIA, UEA)

RRC: Security Mode Complete DT1 [ Security Mode Complete ](chosen UEA, chosen UIA)( )

Loc

atio

nU

pdat

e 1(

2)

M enu

UE MSC

figure 31 Location update procedure 1(2).



4. Now the location update can be completed. The UE gets the MM message Location Update Accept, again transported using the Direct Transfer Message. In the Location Update Accept message the UE gets a new TMSI. This TMSI must be acknowledged with TMSI Reallocation Complete. Also this message belongs to the MM protocol, so again the Direct Transfer message is used for transport.

5. Now the MSC detects that the location update is over and no other service is

running or pending, hence the Iu signaling connection can be released. Therefore the MSC sends Iu Release Command. The RNC will inform the UE with Signaling Connection Release (RRC message) and acknowledges to the MSC with Iu Release Complete. Radio access bearers have not been used in this procedure, so none has to be released. The rest is the release of the SCCP connection with RLSD and RLC.



MM: Location Update Accept DT1 [ Direct Transfer ](Location Update Accept )(new LAI, new TMSI)

MM: TMSI Reallocation Complete DT1 [ Direct Transfer ]( TMSI Reallocation Complete )( )

RRC: Signaling Connection Release DT1 [ Iu Release Command ]

DT1 [ Iu Release Complete ]

Loc

atio

nU

pdat

e 2(

2)

RLSD

RLC

RNC

M enu

UE MSC

figure 32 Location update procedure 2(2).



3.4.8 RAB Assignment Procedure The management of radio access bearers utilizes the RAB Assignment procedure. This procedure is used to set up, release and modify radio access bearers. The procedure is always triggered by the CN and is a dedicated procedure. The CN has to send the RANAP message RAB Assignment Request . This message is a class 3 procedure, so several set up requests, release requests and modification requests can be combined in one single RAB Assignment Request message. Each of these sub-requests requires one individual RAB Assignment Response message for positive or negative acknowledgement. The effect of the RAB Assignment Request message is that it triggers procedures of the network control plane (ALCAP protocols) to set up, release or modify the interface specific bearer services on Iu, Iub, Iur and Uu. For instance on Uu the RRC messages Radio Bearer Setup or Radio Bearer Reconfiguration or Radio Bearer Release can be seen as result of the RAB Assignment Request. For the set up of RABs the RAB Assignment Request message carries the following information elements: • RAB-ID: Each radio access bearer gets its own identifier. This identifier is eight bits

in length. (Note: The RAB-ID is for CS the stream identifier and for PS the NSAPI.) • RAB parameters: The RAB parameters describe the properties of the RAB. This is

done in an abstract manner using quality of service parameters. • User Plane Info: This element is used to convey configuration parameters for user

plane protocols (Iu User Plane protocol). • Transport Layer Info: The transport layer information element typically contains

transport layer addresses for user data transport on Iu. For instance on Iu-PS the IP addresses of RNC and SGSN are contained in here.



RRC: Radio Bearer Setup|Radio Bearer Reconfiguration|

Radio Bearer Release

DT1 [RAB Assignment Request]

(Setup|Modific. : RAB-ID, RAB parameters,User Plane Info, Transport Layer Info;

Release : RAB-ID, cause )

RRC: Radio Bearer ... Complete

Iu bearer setup/release

Iub/IurBearer Setup/

Release

DT1 [RAB Assignment Response]

(Setup|Modific. : RAB-ID,Transport Layer Info;

Release : RAB-ID, data volume )

DT1 [RAB Assignment Response]

. . .

RNC

M enu

UE MSC

figure 33 RAB assignment procedure.



3.4.9 RAB Release triggered by RNC In some situations it is necessary that the RNC can trigger the release of a radio access bearer. For instance when the radio link synchronization is lost (e.g. UE is in a coverage hole) this might be necessary. In this case the RNC can send the RANAP message RAB Release Request which contains the RAB-ID and a cause value. If the MSC or SGSN receive this message they shall start a RAB Assignment procedure to release the mentioned RAB.



DT1 [ RAB Release Request ](RAB-ID, cause)

DT1 [ RAB Assignment Request ](Release: RAB-ID)

DT1 [ RAB Assignment Response ](RAB-ID)

RNC MSC

figure 34 RAB release triggered by RNC.



3.4.10 Common ID Procedure In UMTS there is a clear separation between UTRAN and CN. Especially because there are two independent core network domains, the RNC of the UTRAN must be able to co-ordinate these domains. On the other hand it is possible that there might be pure UTRAN operators offering their RNC to be connected to other operator's CN. In both cases the RNC has to perform co-ordination tasks. For this the IMSI is necessary when the co-ordination is dedicated to individual UE. The typical tasks in the RNC that require the IMSI are: • paging co-ordination: An UE can be connected to one core network domain, but not

to the other. So when the paging from the not connected domain comes in, the RNC has to make the paging directly to the UE (Paging type 2 on DCCH).

• charging: If charging shall be done in the RNC the user identity must be known, to

assign the charging record to this user. Therefore the CN will send the IMSI in the RANAP message Common ID to the UE. This happens typically after authentication and when a longer communication is necessary.



CN

DT1 [ Common ID ](IMSI)

RNC MSC

figure 35 Common ID procedure.



3.4.11 Example Procedure: Mobile Originated Call (MOC) The radio bearer management is necessary whenever a service requires transport bearer services for user data. The two services that are known for this are the CS call and the PS session. The example provided here is the mobile originated circuit switched call – MOC. The call will be presented in four big steps: 1. Processing of the UEs access request

a. The UE has to request the call service (CM Service Request message of MM protocol),

b. Authentication (Authentication Request and Response; MM protocol), c. Sending of IMSI to the RNC (Common ID; RANAP), d. Activation of security features (Security Mode Command and Complete;

RANAP).



MM: Authentication Request CC [ Direct Transfer ]

MM: CM Service Request CR [ Initial UE Message ](LAI, SAI, CM Service Request )(MOC establishment request)

(Authentication Request )(CKSN, RAND, AUTN)

MM: Authentication Response DT1 [ Direct Transfer ]( Authentication Response )(old LAI, old TMSI, MS classmark)

RRC: Security Mode Command DT1 [ Security Mode Command ](permitted UIA, permitted UEA, CK, IK)(UIA, UEA)

RRC: Security Mode Complete DT1 [ Security Mode Complete ](chosen UEA, chosen UIA)( )

CS

cal

l set

up 1

(4)

DT1 [ Common ID ](IMSI)

RNC

M enu

UE MSC

figure 36 MOC 1(4): access.



2. Call establishment request a. UE requests the call with Call Control protocol (Setup and Call Proceeding;

CC protocol). b. Radio access bearer establishment (RAB Assignment Request and

Response of RANAP). The RAB set up triggers the set up of link bearer services on Uu (Radio Bearer Setup and Setup Complete; RRC protocol), on Iu (Establishment Request and Confirmation; AAL2 signaling protocol) and on Iub (not shown here).

c. When the user channel (RAB) is set up, the user plane protocols will start signaling for the initial configuration (in-band signaling).



CC: Call Proceeding DT1[ Direct Transfer ]

CC: Setup DT1 [ Direct Transfer ](Setup )(called party address, codec capabilities)

(Call Proceeding )( )

RRC: Radio Bearer Setup

DT1 [RAB Assignment Response]( Authentication Response )

DT1 [RAB Assignment Request](Setup: RAB parameters)

RRC: Radio Bearer SetupAAL2 Sig.Protocol : Establishment Request

AAL2 Sig.Protocol : Establishment Confirm

CS

cal

l set

up 2

(4)

in-band signalling to initialise the user plane

RNC

M enu

UE MSC

figure 37 MOC 2(4): call request.



3. Call completion a. When the B-party is reachable the calling user gets the CC message Alerting. b. When the B-party accepts the call, the calling user gets the CC message

Connect and acknowledges with Connect Acknowledge.



CC: Alerting DT1[ Direct Transfer ]

CC: Connect Acknowledgement DT1 [ Direct Transfer ](Connect Acknowledgement )

(Alerting )( )

CC: Connect DT1[ Direct Transfer ](Connect )( )

Call Active

CS

call

set

up 3

(4)

RNC

Me nu

UE MSC

figure 38 MOC 3(4): call establishment.



4. Call clear down a. In the example the B-party disconnects the call (Disconnect, Release,

Release Complete; CC protocol). b. Because this was the last CS service that was active, the MSC release the

SCCP connection (Iu Release Command and Complete; RANAP) and with this all associated radio access bearers.

c. Therefore one can see the release of the Uu bearer (Radio Bearer Release and Release Complete; RRC protocol) and of the Iu bearer (Release Request and Confirm; AAL2 signaling protocol).

d. The last action is now to release the SCCP connection with RLSD and RLC.



CC: Disconnect DT1[ Direct Transfer ](Disconnect )( )

CC: Release DT1[ Direct Transfer ](Release )( )

CC: Release Complete DT1[ Direct Transfer ](Release Complete )( )

DT1[ Iu Release Command ]

RRC: Radio Bearer Release CompleteAAL2 Sig.Protocol : Release Request

AAL2 Sig.Protocol : Release Confirm

RRC: Radio Bearer Release

RRC: Signalling Connection ReleaseDT1[ Iu Release Complete ]

RLSD

RLC

CS

call

setu

p 4(

4)

RNC

Menu

UE MSC

figure 39 MOC 4(4): call disconnect and release.



3.4.12 S-RNC Relocation When an UE communicates with the core network always a RRC connection between UE and serving RNC and a SCCP connection between serving RNC and Core Network must exist. Because of the mobility of the subscribers, the serving RNC can change. This change of the serving RNC is associated with a procedure called Serving RNC Relocation (S-RNC relocation) . The procedure has two effects: • the old Iu (SCCP) signaling connection between old (source) RNC and CN is

substituted by a new Iu signaling connection between new (target) RNC and CN, • the old RRC connection between UE and old (source) RNC is substituted by a new

RRC connection between new (target) RNC and CN. Together with the change of the Iu signaling connection also the associated radio access bearers have to be moved to the new Iu interface that handles the UE's traffic. When two Iu signaling connections exists simultaneously (on Iu-CS and on Iu-PS) the relocation has to be performed with MSC and SGSN at the same moment. It is important to note, that the relocation is not a handover. The handover procedure is used move the radio links of an UE from one cell to another cell. The relocation can take place simultaneously with a handover (UE involved in relocation) or a long time after the handover (UE not involved in relocation). This principle decouples the core network from radio related tasks (e.g. handover).



Ser

ving

RN

C R

eloc

atio

n1(

4)

sourceRNC

targetRNC

Core Network

old RRCconnection

old SCCPconnection

new RRCconnection

new SCCPconnection

S-RNC relocation

Menu

UE

figure 40 S-RNC relation principles.



The relocation procedure has four main steps: 1. Relocation Indication

a. The current serving RNC (source) has all information about the radio status of the UE. The source RNC will decide that a relocation is necessary. The criteria for that decision are operator and vendor specific. The result of the decision is the RANAP message Relocation Required , which contains the source RNC-ID and the target RNC-ID, which must be taken from an internal data base of the source RNC. Also this message contains a container with RRC parameters that describe the current radio configuration of the UE.

2. Relocation Preparation a. The CN must now trigger the target RNC to allocate all radio access bearers

for the UE and to set up the new Iu signaling connection. Hence the CN sends the RANAP message Relocation Request in a SCCP message CR. The Relocation Request message contains the list of RABs that are needed, the keys IK and CK, the algorithms UEA and UIA and the RRC parameter container from the source RNC. The parameter relocation type indicates UE involved or UE not involved.

b. When all resource are allocated by the target RNC it will send Relocation Request Acknowledge in CC (Connection Confirm). This message tells the CN which RABs are set up and which are not. Also a RRC parameter container is included, which contains the radio configuration for the UE in the target RNC after the relocation.

3. Relocation Execution

a. Now the relocation can start, hence the CN sends Relocation Command to the source RNC. Inside of this message is the RRC container from the target RNC with the new radio configuration for the UE. Additionally the CN can indicate radio access bearers between source and target RNC (requires Iur interface) on which buffered downlink data from the source RNC can be forwarded to the target RNC.

b. When the target RNC gets a Node B the information that the radio signal of the UE has been detected it will send Relocation Detect to the CN.

c. When the target RNC has provided the UE with new RNTI (Radio Network Temporary ID) and thus has now the RRC connection with the UE, it will send Relocation Complete .

4. Garbage Collection in the source RNC

a. Now the relocation is completed and the old Iu signaling connection and the



old RABs on the old Iu interface can be released. Hence the CN should send Iu Release Command to the source RNC.

sourceRNC

CN targetRNC

CC [Relocation Request Ackn.](RABs successfully set up,

RABs failed to set up,chosen UIA, chosen UEA,

target-to-source RNC transparent container)

DT1 [ Relocation Required ]( relocation type, source RNC-ID, target RNC-ID,

source-to-target RNC transparent container )

CR [ Relocation Request ]( IMSI, RABs to be set up, IK, CK, UIA,UEA,source-to-target RNC transparent container )

DT1 [ Relocation Command ](RABs to be released, RABs for data forwarding

target-to-source RNC transparent container)

DT1 [ Relocation Detect ]( )

DT1 [ Relocation Complete ]( )

Serv

ing

RN

C R

eloc

atio

n2(

4)

figure 41 Relocation procedure (RANAP message sequence chart).



3.4.13 S-RNC Relocation for Soft Handover Completion The soft handover is a situation in which the UE is typically connected to several cells or is connected to cells not under the control of the serving RNC. As already mentioned in the latter case the whole user and signaling traffic has to go via the serving RNC. The end of the soft handover (soft handover completion) is reached, when the cell the UE is connected to is under control of the serving RNC. This will be done with a relocation. In this case the UE does not have to deal directly with the relocation, because the UE has already the radio links to the cells of the target RNC, so the UE is not involved in the procedure. The following is done: • The source RNC detects that the relocation is necessary and starts the RANAP

procedure with Relocation Required. Then the Iu resources (RABs and SCCP connection) have to be prepared in the target RNC (Relocation Request, Relocation Request Acknowledge). When this is done the relocation can be executed (Relocation Command).

• The execution of the relocation in the case of a soft handover completion does not

touch the radio resources, instead the source RNC simply sends a message (Relocation Commit; RNSAP protocol) to the target RNC. This message tells the target RNC that it shall become the serving RNC now.

• This Relocation Commit message triggers two things. First the target RNC provides

the UE with new RNTI and with this becomes the new serving RNC of the UE (UTRAN Mobility Information; RRC protocol). Second the target RNC sends immediately Relocation Detect to the CN.

• When the UE acknowledges the new RNTI and with this also the new RRC

connection to the target RNC, the target RNC has to send Relocation Complete to the CN. The relocation is done with that.

• Now the CN releases the old Iu resources of the source RNC with Iu Release

Command.



sourceRNC

CN targetRNC

CC [ Relocation Request Acknowledgement ]

DT1 [ Relocation Required ]CR [ Relocation Request ]

DT1 [ Relocation Command ]

(Iur) RNSAP: SRNC Relocation Commit

DT1 [ Relocation Detect ]

( )

DT1 [ Relocation Complete ]

( )DT1 [ Iu Release Command ]

( )DT1 [ Iu Release Complete ]

( )

RLSD

RLC

RRC : UTRAN Mobility Information

(new U-RNTI)

RRC : UTRAN Mobility Information

Confírm

Serv

ing

RN

C R

eloc

atio

n3(

4)

Menu

UE

Menu

UE

figure 42 Soft handover completion.



3.4.14 S-RNC Relocation with Hard Handover When the S-RNC is performed together with a hard handover, the UE is said to be involved in the relocation. The difference to the soft handover completion is the handover execution. The other steps in the relocation process remain unchanged. So when the source RNC gets the Relocation Command from the CN it will send a RRC message to the UE. This RRC message will reconfigure the radio protocols (PHY, MAC, RLC) of the UE so that is goes to the new cell. Several RRC messages are possible, the example shows the RRC message Physical Channel Reconfiguration, which modifies the physical layer (in other words the radio link) only. This message is formed according to the RRC parameter container the source RNC has received from the target RNC via CN. The UE now reconfigures the radio layer and synchronizes to the new cell's radio link. When this synchronization is successfully completed the target RNC sends the Relocation Detect message. Then the UE will send the RRC message Physical Channel Reconfiguration Complete which indicates the end of the handover and also the new RRC connection to the target RNC is completed. Hence the target RNC can send the Relocation Complete message to the CN. The rest of the procedure is again the same as before.



CC [ Relocation Request Acknowledgement ]

DT1 [ Relocation Required ] CR [ Relocation Request ]

DT1 [ Relocation Command ]

DT1 [ Relocation Detect ]

( )

DT1 [ Relocation Complete ]

( )DT1 [ Iu Release Command ]

( )DT1 [ Iu Release Complete ]

( )

RLSD

RLC

RRC : Physical Channel

Reconfiguration

(new radio linkconfiguration)

RRC : PhysicalChannel

ReconfigurationComplete

Serv

ing

RN

CR

eloc

atio

n4(

4)

Physical layersynchronisation

sourceRNC

CN targetRNC

Menu

UE

M enu

UE

figure 43 Hard handover associated with a serving RNC relocation.



3.5 RANAP Message Specification

3.5.1 RANAP Specification The RANAP protocol is specified in TS 25.413. The specification covers a description of all procedures and the message content. Like the RRC protocol also RANAP uses ASN.1 (Abstract Syntax Notation 1) for the definition of the messages and their parameters. To format the messages for transmission the packed encoding rules PER will be used. Again there is a ``human readable´´ message description in the protocol recommendations too. This can be found in section 9 of TS 25.413. This section 9 is structured in the following way : • 9.1 contains the message definition and content

• 9.2 contains the message’s information elements • 9.3 is the ASN.1 description of the RANAP messages, • 9.4 specifies the encoding rules for the messages (PER), • 9.5 is a list of timers used for the RANAP procedure control.



TS 25.413 9. Elements for RANAP Communication

9.1 Message Functional Definition and Content

9.2 Information Elements Definition

9.3 Message and Information Element Abstract Syntax with ASN.1

9.4 Message Transfer Syntax

9.5 Timers

figure 44 Section of TS 25.413 relevant for message and parameter definition.



3.5.2 RANAP Message For mat Definition The human readable message and parameter definition is very similar to the one of the RRC protocol. On the next page there is the RELOCATION REQUEST ACKNOWLEDGE message shown as example. First a short description of the message, its direction and the used SCCP mode is indicated. Then a table is used to specify the parameters of the message. The first row in the table contains the names of the parameters to be included in the message. The second row contains an indicator whether the information element is mandatory or not, in detail the following is defined : • M : Mandatory, the information element has to be in the message. • O : Optional, the parameter may or may not be included. • C : Conditional, there will be a special condition indicated when the parameter is

mandatory. Then comes a row that specifies the range or multiplicity of parameters. This means the allowed number of copies of repetitive parameters is specified here. The next row gives a reference section where a more detailed description of the parameter can be found. The row `Semantics description´ can give an informal description of the parameter. The row `Criticality´ is used to describe which information is applicable for each parameter in case of failures, this can be : • - : No criticality information is available for this parameter. • YES : This non-repeatable parameter has criticality information to be applied. • GLOBAL : The repeated parameters of the same type have a common criticality

information. • EACH : Each of the repeated parameters has its individual criticality information. The criticality information tells the receiver of a message how to react when parameters cannot be comprehended. The possible values of criticality information are REJECT IE, IGNORE IE/NOTIFY SENDER and IGNORE IE. The exact meaning of these criticality values depend upon the message and the parameter. An exact description for this behavior is to be found in section 10 of TS 25.413. Like in case of the RRC protocol message definition also RANAP knows nested parameters. The sign > is used to indicate that a parameter is nested into another parameter (that has one > less).



figure 45 Specification of relocation request message (excerpt from TS 25.413).

9.1.11 RELOCATION REQUEST ACKNOWLEDGE

This message is sent by the target RNC to inform the CN about the result of the resource allocation for the requested relocation. Direction: RNC → CN. Signalling bearer mode: Connection oriented.

IE/Group Name Presence Range IE type and reference

Semantics description

Criticality Assigned Criticality

Message Type M 9.2.1.1 YES reject

Target RNC To Source RNC Transparent Container

C – IfApplNotOtherCN

9.2.1.30 YES ignore

RABs Setup 0 to <maxnoofRABs

EACH reject

>RAB ID M 9.2.1.2 - >Transport Layer Address

C – ifPS 9.2.2.1 -

>Iu Transport Association

C – ifPS 9.2.2.2

RABs Failed To Setup 0 to <maxnoofRABs

EACH ignore

>RAB ID M 9.2.1.2 - >Cause M 9.2.1.4 -

Chosen Integrity Protection Algorithm

C - ifAvail 9.2.1.13 Indicates which algorithm that will be used by the target RNC.

YES ignore

Chosen Encryption Algorithm

O 9.2.1.14 Indicates which algorithm that will be used by the target RNC.

YES ignore

Criticality Diagnostics O 9.2.1.35 YES ignore

Condition Explanation IfPS This Group is only present for RABs towards the PS domain. IfApplNotOtherCN Must be included if applicable and if not sent via the other CN

domain. IfAvail This IE is only present if available at the sending side.

Range bound Explanation maxnoofRABs Maximum no. of RABs for one UE. Value is 256.

VII. Iu Interface User Plane Protocols


Iu Interface User Plane Protocols Module Objectives:

• Iu User Plane Protocol Iu UP for CS Services,

• Iu Interface User Data Transfer for PS Services,

• GTP-U Protocol.



1 Iu User Plane Protocol



1.1 Iu User Plane Protocol Modes and Tasks The Iu User Plane (Iu UP) protocol is located on Iu-PS and Iu-CS user plane as the highest layer that transports user data. This protocol is considered to be specific to UTRAN, hence it belongs to the so called radio network layer (RNL). Below the radio network layer is the transport network layer (TNL) which is independent of any UMTS related things. On Iu-CS the TNL is built out of AAL2/ATM and on Iu-PS the TNL is formed by GTP-U/UDP/IP/AAL5/ATM. The task of the Iu UP protocol is to decouple the service related user data transport characteristics from the underlying transport network protocols. This shall enable the easy exchange of the transport network protocols (e.g. all IP network without ATM) without any modification of the services. Only the Iu UP protocol has to be adapted to the new transport network. On Iu-PS there is currently no need for an adaptation of the transport services provided by GTP-U/UDP/IP… to the session service (PDP context). Hence on Iu-PS the Iu UP protocol is more or less switched off, it does not provide frames or functionality. Of course this might change in future. On Iu-CS one of the main applications are speech calls with mobile specific speech codecs (AMR : Adaptive Multi-rate Codec). These codecs require a special media flow characteristics, which is not provided by AAL2/ATM. So on Iu-CS the Iu UP protocol has to enhance the transport network bearer service with additional functionality (sub-flows).



CNRNC

user planetransport

bearerprotocols

user planetransport

bearerprotocols

radioprotocols

radioprotocols

RNL-SAP RNL-SAP

Iu UP Iu UP

TNL-SAPTNL-SAP

TNL SAP = Transport Network Layer Service Access PointRNL SAP = Radio Network Layer Service Access Point

Iu u

ser

plan

epr

otoc

ol.

Menu

UE

figure 1 Meaning and location of Iu UP protocol.



The functionality of the Iu UP protocol is divided into so called User Plane Modes . Currently there are two modes defined : • Transparent Mode : The transparent mode is characterized by no functionality from

the Iu UP protocol. This means there are no frames provided and no functionality can be expected from the protocol. This simply means the protocol is switched off. The Iu-PS user plane utilizes this mode in all current implementations.

• Support Mode for predefined SDU sizes : This is in the moment the only mode that

enables specific Iu UP protocol functionality. The main functionality of this mode is the support of RAB sub-flows and sub-flow combinations. Associated with this the Iu UP protocol can perform a frame quality classification of user data, blocking of certain sub-flow combinations (rate control) and handling of the jitter of user data arrival.

The support mode for predefined SDU sizes works only, when the sizes of the user data frames are predefined, this means for each sub-flow combination all sizes of all sub-flows are exactly known. This is the case for speech codecs. The user plane modes can be further divided into versions. In UMTS Release 1999 only one version (version 1) exists for both modes. In UMTS Release 4 a version 2 is defined for the support mode.



Iu u

ser

plan

epr

otoc

ol m

odes

and

mod

eve

rsio

ns.

Iu User Plane Protocol

Transparent ModeSupport Mode for

predefined SDU sizes

Version 1 Version 1

Version 2(only for UMTS Release 4 and higher)

-Transfer of user data -Transfer of user data-UP Initialization-Rate Control-Time Alignment-Handling of error events-Frame quality classification

used on Iu-PS used on Iu-CS

figure 2 Iu UP operation modes and currently available versions with their functionality.



Which of the two user plane modes and which version of this mode shall be used for a radio access bearer is configured by RANAP. In the RAB Assignment Request message the parameter user plane information that is provided for a RAB setup, contains the user plane mode version and user plane mode.



Con

figur

atio

nof

the

IuU

Ppr

otoc

ol w

ithR

AN

AP

.

RNC MSC|SGSN

RANAP: RAB Assignment Request(Setup: RAB-ID, RAB parameters,

User Plane Information = User Plane Mode +supported UP Mode Version )

RANAP: RAB Assignment Response(Setup Acknowledgement: RAB-ID)

figure 3 Parameters in RAB Assignment procedure affecting the Iu user plane protocol.



1.1.1 Transparent Mode In transparent mode the Iu UP protocol is bypassed, thus the user data is transparently flowing through the Iu UP protocol layer without any processing.



Tra

nspa

rent

IuU

P m

ode.

Iu UP - TrM

TNL SAP

RNL SAP

Iu

Iu UP - TrM

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

RNC MSC|SGSN

figure 4 Transparent operation mode of Iu UP protocol.



1.1.2 Support Mode for Predefined SDU Sizes In the support mode for predefined SDU sizes the Iu UP protocol enables three categories of functionalities : • Frame Handler Function : The frame handler function performs framing and de-

framing of user data and control messages. Together with that a cyclic redundancy check can be applied to user data.

• Procedure Control Function : The Iu UP protocol in support mode provides

signaling procedures for initialization, rate control, time alignment and error event notification.

• NAS stream specific functions : These functions are special processing features of

user data. In the support mode for predefined SDU sizes version 1 this covers : detection of frame loss, frame quality classification and decision to discard or deliver frames. Additionally frame loss notifications are sent to the data stream consumer (speech codec).



Sup

port

mod

efo

r pr

edef

ined

SD

Usi

zes

ofIu

UP

.

TNL SAP

RNL SAP

Iu

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

NAS streamspecific functions

ProcedureControl

Functions

Frame HandlerFunction

NAS streamspecific functions

ProcedureControl

Functions

Frame HandlerFunction

RNC MSC|SGSN

figure 5 Functional architecture of Iu UP protocol for support mode.



1.2 Iu UP Support Mode Procedures

1.2.1 User Plane Initialization When a new RAB is established, the RANAP message RAB Assignment Request contains in the user plane information parameter the configuration of the Iu UP protocol. If this parameter indicates the support mode for predefined SDU sizes, there will be an initialization procedure within the user channel (in-band signaling) after the user channel is set up. The initialization is a procedure of the Iu UP protocol in support mode and is triggered by the RNC with the message Initialization . This message contains the number sub-flows that have been defined. The RNC will give an identifier for each established RAB sub-flow combination, which is called RFCI (RAB sub-flow combination identifier) . For each sub-flow combination the size (length) of each sub-flow inside must be indicated. The MSC has to check the transmitted configuration and shall acknowledge it with Initialization Acknowledgement .



Initi

alis

atio

n1

(3).

RANAP: RAB Assignment Request

(Setup: RAB-ID, RAB parameters , User Plane Mode : Support Mode for predefined SDU sizes )

RANAP: RAB Assignment Response

(Setup Acknowledgement: RAB-ID)

INITIALISATION( number of defined sub-flows, RFCI for each sub-flow-combination,

length of each sub-flow in each sub-flow-combination,Inter PDU Transmission Interval IPTI for each sub-flow-combination)

INITIALISATION ACK

RNC MSC|SGSN

figure 6 Initialization procedure.



In general the parameter in the Initialization message can be presented in the following way. From the RAB Assignment Request message the Iu UP protocol gets all the information about sub-flows and sub-flow combinations that are applicable to this RAB (RAB parameters). As already mentioned, each sub-flow occurs in each sub-flow combination, but possibly with different sizes. So the Initialization message will contain for each sub-flow combination a RFCI that is used as unique identifier for this combination. The size of each sub-flow in a combination is indicated. Additionally the IPTI (Inter PDU Transmission Interval) which is the mean time between two consecutive user data frames of one sub-flow combination is indicated. This IPTI is typically the size of the SDU for one sub-flow combination divided by the bit rate of this combination.



Initi

alis

atio

n2

(3).

sub-flow-combination 1

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

sub-flow-combination 2

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

sub-flow-combination X

sizeof

sub-flow 1

sizeof

sub-flow 2

sizeof

sub-flow 3

sizeof

sub-flow NIPTI

. . .

sf1

sf2

sf3

sfN. . .

. . .

. . .

. . .

RFCI=1

RFCI=2

RFCI=X

N sub-flows

figure 7 Sub-flow combin ation configuration.



1.2.2 Transfer of User Data When the Iu UP protocol for the RAB is configured, user data can be transported using the Iu UP protocol. Therefore the frame of type Transfer Of User Data is provided. This PDU transports the user data as payload and includes the RFCI that indicates according to which sub-flow combination the payload is built.



Tra

nsfe

r of

Use

rD

ata.

Transfer of User Data(RFCI, payload)

Transfer of User Data

(RFCI, payload)

RNC MSC|SGSN

figure 8 Transfer of user data frames in support mode.



1.2.3 Rate Control Procedure The rate control procedure is used by the RNC to indicate to the MSC which sub-flow combinations are currently allowed and which are currently permitted. This is done using the Rate Control frame of Iu UP protocol, in which a bitmap can be found. This bitmap specifies for each defined sub-flow combination whether it is blocked (b´1) or allowed (b´0). With that the serving RNC is able to control the maximum and minimum data rates by enabling and inhibiting certain sub-flow combinations. Usually this functions works together with the control procedures of the AMR (Adaptive Multi-rate Codec). When and how the serving RNC uses this procedure is operator and manufacture specific. Note that in version 2 of the support mode (UMTS Release 4 and higher) also the MSC can send rate control messages.



Rat

eC

ontr

ol.

Rate Control(RFCI indicator bitmap)

0 0 0 1 1 . . . 11 2 3 4 5 X

RFC X : barred

RFC 5 : barredRFC 4 : barredRFC 3 : allowedRFC 2 : allowedRFC 1 : allowed

...

RNC MSC|SGSN

figure 9 Rate control procedure.



1.2.4 Time Alignment Procedure The RNC has to send the downlink data in radio frames that are periodical time slices of 10 ms. So the sending of data in dedicated channels is in fact synchronous. But the MSC sends the data via the Iu bearer based on ATM, so it is possible that the user data arrives at the RNC at irregular intervals (jitter). To compensate this jitter the RNC maintains a jitter buffer. If the jitter becomes too big, the jitter buffer may have a under-run or a over-run. Therefore the RNC can report to late and to early sending to the MSC. This is simply done by the Iu UP protocol message Time Alignment . This message carries a time alignment value which specifies the to late or to early sending in the range of –40 ms to +40 ms in 500 µs steps.



Tim

eA

lignm

ent.

Time Alignment(time alignment)


(RFCI, payload)bad

timing

Time Alignment Acknowledgement


(RFCI, payload)

adjustedtiming

RNC MSC|SGSN

figure 10 Time alignment for user data with too high jitter.



1.2.5 Error Event Procedure If UE or RNC detect an error in the transmitted downlink data, the error event indication procedure is triggered. The Iu UP protocol provides the Error Event message for this. This message contains an error cause (e.g. wrong SDU sizes, undefined RFCI, etc.) and an error distance. The error distance specifies who detected the error. The error distance 0 is a local error detected by the Iu UP protocol in the RNC. If the failure is detected by other protocols in the RNC (e.g. AMR codec) the error distance is set to 1, if the error indication comes from the UE the error distance is set to 2.



Err

orE

vent

.

Error Event(error cause, error distance)

RNC MSC|SGSN

figure 11 Error event indication.



1.3 Frame Quality Classification Function The frame quality classification function is available in the support mode for predefined SDU sizes only. The function consists of the following features : • CRC check : The Iu UP protocol can perform a cyclic redundancy check for the user

data payload on Iu. • frame quality classification : The Iu UP protocol layer can divide the received frames

in categories of frames without errors (good), frames with bit errors (bad) and frames with bit errors resulting from air interface problems (bad due to radio).

• On basis of the RAB configuration, frame quality classification and CRC check the Iu

UP protocol can decide to discard or deliver the frame. The exact behavior and applicability of these features is configured during RAB establishment. The parameter that is responsible for this is the Delivery Of Erroneous SDU element in the RAB parameters. This parameter can be set individually for each defined sub-flow. The Delivery Of Erroneous SDU parameter can have three different values: • YES : The CRC check for payload will be performed by Iu UP protocol, and all three

features are applicable. Frames with and without errors will be delivered to the higher layers (e.g. AMR codec).

• NO : The CRC for payload will be performed by Iu UP protocol, and all three

features are applicable. But only frames without bit errors will be delivered, whenever bit errors are detected (by CRC or frame quality classification) the frame will be discarded.

• NO ERROR DETECTION CONSIDERATION : If this is the value of the parameter,

the Iu UP protocol will not perform the CRC check for payload. Also the frame quality classification is not used, instead each user data frame will be delivered without any error detection consideration.

This parameter must be set for each sub-flow individually. But the Iu UP protocol will treat all sub-flows in a sub-flow combination in the same way. This is done in the



following way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is NO, all sub-flows are handled in this way. If the Delivery Of Erroneous SDU parameter of at least one sub-flow is YES, but for no sub-flow the Delivery Of Erroneous SDU parameter is NO, all sub-flows are treated like Delivery Of Erroneous SDU parameter is YES. If for all sub-flows the Delivery Of Erroneous SDU parameter is NO ERROR DETECTION CONSIDERATION then all sub-flows are handled according to this.

Radio Access Bearer

Traffic Class Asymetry Max. Bitrate Guaranteed Bitrate

Delivery Order Max. SDU-Size Transfer Delay Priority

SDU Error Ratio

Bit Error Ratio

Delivery of erroneousSDUs

Size of subflow SDUin each combination

Sub-Flow 1SDU Error Ratio

Bit Error Ratio

Delivery of erroneousSDUs

Size of subflow SDUin each combination

Sub-Flow x

. . .

Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n1-

CR

Cer

ror

prot

ectio

n ac

tivia

tion/

deac

tivat

ion.

.

Delivery Of Erroneous SDU::= ENUMERATED{yes,no,no-error-detection-consideration

}

Payload CRC applicable

Payload CRC not applicable

figure 12 Parameter in RAB Assignment Request to control the frame quality classification.



1.3.1 Downlink User Data Handling The handling of the downlink user data is simple. When the MSC wants to send a downlink user data SDU, it shall evaluate the Delivery Of Erroneous SDU parameter for this sub-flow. If at least for one sub-flow Delivery Of Erroneous SDU = YES or NO, the MSC shall calculate a CRC over the payload and transmit it in the user data frame (Transfer of User Data). The frame quality classification is always set to good, because user data from the MSC has no bit errors by definition. The RNC receives the user data frame and shall evaluate the CRC if it is included. In case bit errors (from Iu interface) are detected, the frame is always discarded, regardless of the value of the Delivery Of Erroneous SDU parameters.



Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n2

-do

wnl

ink.

Transfer of User Data(RFCI, payload, FQC = good, payload CRC )

FQC ( Frame Quality Classification )[ 0= frame good, 1= frame bad, 2= frame bad due to radio ]

RNC discards the frame whenpayload CRC present and bit

errors are detected with it.

CN

Menu

UE RNC

figure 13 Downlink user data handling.



1.3.2 Handling of Uplink User Data In case of uplink data the Iu UP protocol behavior is a little bit more complex. This is because now we can have errors from the radio interface and errors from the Iu interface. In the RNC the following can is done : • frame quality classification according to the information received from the radio

protocols, • decision to discard or deliver the frame, • calculation of a CRC for the payload if applicable. In the MSC the following can happen : • checking of frame quality classification, • checking of CRC if there is one, • decision to discard or deliver the frame.



Fra

me

Qua

lity

Cla

ssifi

catio

n fu

nctio

n3

-up

link.

TNL SAP

RNL SAP

Iu

TNL SAP

Rad

io In

terf

ace

Pro

toco

ls

Radio framequality classification

Add payload CRCif needed, set FQC

discard frame?

No

check payload CRCif present, check FQC

deliver frame?

Yes

RNC MSC|SGSNdata with FQC

figure 14 Uplink user data frame quality handling.



1.4 Frame Formats

1.4.1 Transfer of User Data (PDU Type 0 and 1) The Iu UP protocol provides two frames (PDU types) for the transport of user data payload. These two frames are • PDU type 0 : PDU type 0 allows a CRC to be transmitted for the payload. • PDU type 1 : In contrast to type 0 there can be no CRC for the payload in a PDU

type 1. Common elements of both frame types are : • PDU type indication : Distinguishes between PDU type 0 (with payload CRC), PDU

type 1 (without payload CRC) and PDU type 14 (control messages of Iu UP protocol).

• Frame Number : This field works as a sequence number for the user data frames. It

is a strictly increasing number. • FQC (frame quality classification) : The FQC classifies the frame quality according

to good (b´00), bad (b´01) and bad due to radio (b´10) frames. • RFCI (RAB sub-flow combination identifier) The payload that is transported by the frame is not required to have length that is an integral multiple of 8 bits. But always the Iu UP protocol pads the missing bits such that the payload is aligned to octet boundaries. For future compatibility the frames contain a so called spare extension. This extension is currently not used and not transmitted. In future versions it might happen that additional parameters are transmitted in this extension.



7 6 5 4 3 2 1 0

PDU Type (0000) Frame Number

FQC RFCI

Header CRCPayload

CRCPayload CRC

Payload

Payload Padding

Spare Extension (0..4 octets)

IuU

ser

Pla

ne p

roto

col f

ram

es: T

rans

fer

Of U

ser

Dat

e (P

DU

Typ

e 0

and

1).

7 6 5 4 3 2 1 0

PDU Type (0001) Frame Number

FQC RFCI

Header CRC spare

Payload

Payload Padding


figure 15 PDU Type 0 and 1 for transfer of user data.



1.4.2 Control Frames (PDU Type 14) For control messages that do not carry user data inside the PDU type 14 is used. This frame format consists of • ACK/NACK : This field indicates whether the control message is a procedure request (b´00), positive acknowledgement (b´01), negative acknowledgement (b´10).

• Sequence Number : The sequence number for PDU type 14 is used as a

transaction identity. An acknowledgement shall use the sequence number of the corresponding request. The sequence numbers of requests shall be increasing numbers.

• Iu UP mode version : This four bit field indicates the version of the used Iu UP

mode. Currently only the value b´0000 (version 1) is used. • Procedure Indicator : The procedure indicator differentiates between Initialization procedure (b´0000), Rate control procedure (b´0001), Time alignment procedure (b´0010), Error event indication (b´0011).

The rest of the frame is used for the parameters that are specific to the procedure.



figure 16 Control frame format of Iu UP protocol (PDU Type 14).

payload CRC

SequenceNumber

7 6 5 4 3 2 1 0

PDU Type (1110) ACK/NACK

Iu UP modeversion

Procedure Indicator

Header CRC payloadCRC

Procedure Data


IuU

ser

Pla

ne p

roto

col f

ram

es: C

ontr

olF

ram

e (P

DU

Typ

e14)

.



1.4.3 Example of Formatted Frame The following contains an example of a formatted Iu UP protocol frame. The PDU type is formed by the highest four bits of the first octet. It has the value H`E = d´14 which indicates a control frame. The next two bits form the ACK/NACK field and is b´00 so this frame constitutes a procedure request. The last two bits of the first octet are the sequence number. In the second octet the higher four bits give the user plane mode version which is b´000, so version 1 of the user plane mode is used here. The lower four bits are the procedure indicator. The value b´0001 together with the ACK/NACK field mean a Rate Control message. In the Iu UP protocol specification TS 25.415 the Rate Control message is defined to have only one parameter – a bitmap of allowed and barred sub-flow combinations. The first element of this parameter is an indicator how many sub-flow combinations are indicated. In the actual case this means 3 sub-flow combinations are defined. Then the last octet contains the bitmap beginning from the highest bit. Bit 8 and 7 of the last octet are 0, so RFCI 1 and RFCI 2 are allowed, whereas RFCI 3 is blocked, because bit 6 is 1.



IuU

ser

Pla

ne p

roto

col f

ram

es: R

ate

Con

trol

exa

mpl

e.

payload CRC

7 6 5 4 3 2 1 0

Header CRCpayload

CRC

1 1 1 0 0 0 1 0

0 0 0 0 0 0 0 1

0 0 0 0 0 0 1 1

0 0 1 0 0 0 0 0

PDU type 14=Control, Procedure request

UP mode version 0, Procedure 1 = rate control

spare, 3 RFCIs defined

RFCI 1and 2 allowed, RFCI 3 barred

figure 17 Example of a formatted rate control frame



2 Iu-PS User Plane – GTP-U



2.1 Iu-PS Protocols for User Data Transfer The Iu-PS user plane is responsible to transport packet data between RNC and SGSN for activated PDP contexts. Thus the data is running from UE to SGSN via RNC and then to the GGSN and vice versa. On the radio interface Uu the packet data is transported in the PDCP (Packet Data Convergence Protocol) which performs packet header information compression and decompression. The lower layers of Uu (RLC, MAC and PHY) form the radio bearer that is temporary used as transport resource for the PDP context. The radio bearer is of course part of the radio access bearer RAB that is currently allocated for the PDP context. Note that the PDP context can exist with and without an associated radio access bearer. It can be de-allocated when no user packet data has to be sent. On the Iu-PS interface the radio access bearer is implemented on the user plane by the protocols : • Iu-UP (Iu user plane protocol) : This protocol is at the moment running in transparent

mode only, so there is no functionality provided by this protocol on Iu-PS. • GTP-U (GPRS Tunneling Protocol – User plane) : The GTP-U layer forms data

transport tunnels between RNC and SGSN for each radio access bearer of all PDP contexts. So this protocol tunnels the user packets between RNC and SGSN.

• UDP/IP : These two standard protocols are denoted as path protocols. UDP

provides an unreliable data transport, but as the ATM network is reliable enough, there should be no problem. The IP layer enables the routing between SGSN and RNC as far as this is necessary.

• AAL5/ATM : The AAL 5 layer provides an unacknowledged transport service for

variable bit rate service, especially for bursty traffic. The AAL 5 virtual channels have to be defined by the operator (semi-permanent virtual channels) and are usually end-to-end between RNC and SGSN.



SGSNRNC

GTP-U GTP-U

RLCRLC

MACMAC

PHYPHY

UDP UDP

IP IP

AAL5 AAL5

ATM ATM

PDCPPDCP

RelayRNL-SAP RNL-SAP

Iu Packet Bearer = GTP-TunnelUu Packet Bearer

= Radio Bearer

RNL-SAP : Radio Network Layer Service Access Point

Iu UP Iu UP

GT

P-U

on

the

pack

etor

ient

ed I

u us

er

pla

ne

Menu

UE

figure 18 Packet oriented data transfer over Iu and Uu.



The complete picture of the Iu-PS interface protocol stack shows, that it consists of control and user plane. No network control plane is defined, thus there is no ALCAP (Access Link Control Application Part) involved on Iu-PS. This is, because the AAL5 virtual channels are pre-configured (semi-permanent) and do not need a dynamical set up. Also there is no sub-channeling within an AAL5 virtual channel, this means, all IP packets are equally, statistically multiplexed onto the virtual channel. The differentiation between the data packets of different PDP contexts is done in the GTP-U protocol layer. Hence it is necessary to configure this protocol when a new radio access bearer is set up for a PDP context. But RAB management is a task of RANAP, so it is a task of RANAP (RANAP-RAB management process) to configure the GTP-U protocol after RAB establishment.



NAS signaling / PS user data

Physical Layer

ATM (NNI)

AAL 5 AAL 5

SAAL

MTP 3 B

SCCP

RANAP Iu User Plane Prot.

control plane networkcontrol plane

user plane

radionetwork

layer

transportnetwork

layer

SGSNRNC

IP

UDP

GTP-U

Rel

atio

nbe

twee

n Iu

-PS

cont

rola

ndus

erp

lane

figure 19 Protocol architecture on Iu-PS.



2.2 Tunnel End Points a nd Tunnel Configuration The GPRS feature of UMTS is built according to the principle of tunneling. This means network protocol packets for an external data network (e.g. IP or PPP datagrams) must be transported through another network (in our case UMTS network). So the tunnel is nothing else than a transport bearer service. The UMTS packet switched bearer services consist of several transport tunnels. A first bearer service is between UE and RNC (radio bearer), the second between RNC and SGSN and a third is between SGSN and GGSN. In this section only the tunnel between RNC and SGSN is of interest, but most of the statements hold for the SGSN-GGSN tunnel too. Each tunnel is identified by its two endpoints. As the tunnels is a transport service specific to a certain PDP context, the protocols GTP-U, UDP and IP have to deal with the definition of the endpoints. Indeed an endpoint is defined as the pair : • IP address of the endpoint node and • TEID (Tunnel Endpoint Identifier) which is a local reference number for the PDP

context chosen by this endpoint node, the address belongs to. So the TEID is unique only together with the IP address.

These two identifiers will be carried in each user data packet, the TEID is contained in the GTP-U part and the IP address will be contained in the IP header of the data frame that carries the tunneled data. With this it is possible to uniquely identify and process the packet. In this you may miss the UDP port number. In UMTS the UDP source port number of a tunnel can vary during time (ephemeral port numbers for source) and the UDP destination port numbers are pre-defined by the GTP-U protocol (port number 2152). When a tunnel is to be set up, it is necessary to indicate IP address and TEID for both tunnel endpoints. All TEID values except TEID = 0 can be used for tunnels. The TEID = 0 is reserved for control procedures of GTP-U (e.g. error indications, path test).



SGSNRNC

IP/ATMnetwork

ATM

AAL 5

IP

UDP

GTP-U

Tunnel Endpoint Tunnel Endpoint

Iu Tunnel (Iu Packet Bearer)

RNC-IP Addr.

UDP Port No.

SGSN-IP Addr.

UDP Port No.

TEIDRNC TEIDSGSN

(TEIDRNC, TEIDSGSN)

Con

cept

of T

unne

lbea

rer

serv

ice

son

Iu-P

S.

figure 20 Tunnel end points and the relevant protocols.



When a PDP context is active a radio access bearer for this context can exist or not. In other words, when no packet user data must be transported the radio access bearer can be released and in the moment packet data must be sent a new radio access bearer will be set up. The radio access bearer for a packet data bearer is from the point of view of RANAP signaling procedure nothing special. The RANAP message RAB Assignment Request is used to trigger the set up of the radio access bearer and the RNC acknowledges with RAB Assignment Response. In the request and response message two parameters are special for packet data bearers set : • Transport Layer Address : This element contains the IP address of SGSN (request)

or RNC (response). • Iu Transport Layer Association : This parameter transports the TEID of SGSN

(request) or RNC (response) to the other side. With this both sides (e.g. RNC and SGSN) have all information to establish the tunnel as a logical transport resource. Any further action is not necessary.



RNC SGSN

RANAP: RAB Assignment Request(Setup: RAB-ID, RAB parameters,

Transport Layer Address = SGSN-IP address,Iu Transport Association = SGSN-TEID,PDP type = protocol to be tunnelled )

RANAP: RAB Assignment Response(Setup Acknowledgement: RAB-ID,

Transport Layer Address = RNC-IP address,Iu Transport Association = RNC-TEID )

Allo

catio

nof

TE

IDs

and

IPad

dre

sse

s fo

r th

e tu

nne

l usi

ngR

AN

AP

.

figure 21 RAB Assignment parameters for configuration of tunnels.



The UDP port numbers for GTP-U messages are handled in the following way. GTP-U two three types of frames are defined : • GTP-U data frames (G-PDU) :

A G-PDU carries user data inside. The destination port number of a G-PDU is always set to d´2152. The source port number is freely chosen by the originator of the G-PDU (ephemeral source port).

• GTP-U request control frames :

A request control frame is used to trigger a signaling procedure. The destination port is again d´2152, whereas the source port is freely chosen.

• GTP-U response control frames :

A response control frames is the answers to a request control frame. The source port of a response control frame is always d´2152 (e.g. this equals the destination port of the associated request control frame) and the destination frame is the source port number of the associated request control frame.

In other words the GTP-U protocol uses port number d´2152, which must always be used for the destination port number in initial messages (G-PDU or request control frame),but the source port number can be chosen freely in initial messages. In response messages the values from the corresponding initial message are taken and interchanged.



RNC (SGSN) SGSN (RNC)

Source Port : X

Dest. Port : 2152GTP-U request message

Source Port : 2152

Dest. Port : XGTP-U response message

Source Port : X

Dest. Port : 2152GTP-U data frame TEID

UD

Ppo

rt n

umbe

r ut

iliza

tion

for

GT

P-U

cont

rola

ndda

ta m

essa

ges.

figure 22 GTP-U within UDP and the associated UDP port numbers.



2.3 GTP-U Procedures

2.3.1 Packet Data Transfer The main task of the GTP-U protocol is to transport packet user data of a PDP context within the associated tunnel on Iu-PS. The G-PDU (GTP – Protocol Data Unit) is responsible for this. This frame is transported within a UDP/IP datagram that contains the IP address of RNC (downlink) or SGSN (uplink) and the UDP destination port (d´2152) and source port (ephemeral). In the header of the G-PDU the TEID of the receiver endpoint is included. Also a sequence numbering for the packet user data is contained in here. The user data itself will be transported as payload in the G-PDU which is also called T-PDU (Transport PDU).



RNC SGSN

[TEIDRNC, sequence number, T-PDU=user data]

G-PDU (RNC-IP-address, source port: X, destination port: 2152)

[TEIDSGSN, sequence number, T-PDU=user data]

G-PDU (SGSN-IP-address, source port: Y, destination port: 2152)

GT

P-U

user

dat

a tr

ans

port

.

figure 23 G-PDU for packet oriented user data transfer.



2.3.2 Error Indication When SGSN or RNC receive a G-PDU for a TEID that is not active, a error notification shall be sent. Therefore the GTP-U protocol contains the Error Indication procedure. This frame is a request control frame which is sent in TEID=0, that has been reserved for control procedures. The error indication frame itself then contains a parameter TEID1, that contains the inactive TEID the G-PDU was received for. When the remote side receives such an error indication, it shall implicitly release the RAB that is associated with the inactive TEID. The PDP context itself is not affected by this.



RNC SGSN

[TEID=0, TEID1 = inactive PDP context]

Error Indication

[TEID=0, TEID1 = inactive PDP context]

Error Indication

releaseRAB

releaseRAB

!PDP contextnot released

GT

P-U

erro

r in

dica

tion

for

inac

tive

TE

IDs.

figure 24 GTP-U Error indication for inactive PDP contexts.



2.3.3 Path Test Procedure RNC and SGSN periodically test whether their counterpart is still active. This procedure is the path test or echo procedure. The node that starts a path test, will send a GTP-U control frame of type Echo Request with TEID = 0. The remote side has to response with a frame Echo Response .



RNC SGSN

[TEID=0]

Echo Request (RNC-IP-address, source port: X, destination port: 2152)

[TEID=0]

Echo Response (SGSN-IP-address, source port:2152, destination port:X)

[TEID=0]

Echo Request (SGSN-IP-address, source port: Y, destination port: 2152)

[TEID=0]

Echo Response (RNC-IP-address, source port:2152, destination port:Y)

Pat

h a

vaila

bili

tyte

stw

ithG

TP

-U e

cho

proc

edur

e.

figure 25 Echo request for path test procedure.



2.4 GTP-U Frame Format The GTP-U frames are transported in UDP/IP datagrams. The IP protocol can be of version 4 or 6. In any case the IP header carries the source and the destination IP address used for IP routing between RNC and SGSN if it is necessary. The UDP header includes the UDP port numbers as they have been discussed before. The GTP frame follows as data part of the UDP frame. The GTP frame contains the TEID of the destination node.



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

IP version header length type of service total lengthdatagram identification flags fragment offset

time to live protocol (H´11=UDP) header checksum

source IP address

UDP source port number

destination IP address

options (e.g. time stamps, route records, security info)

IPv4header

UDP destination port numberUDP datagram length UDP checksum

UDPheader

versionPT 0 E S PN GTP message type GTP message lengthTunnel Endpoint Identifier (TEID)

Sequence Number N-PDU number next extension header

extension header length extension header content extension header content=0

GTP message parameters/data

GTPmessage

PT = Protocol Type (1=GTP; 0=GTP´)version = 001 (TS 29.060 V3.x.y)E = extension header field indicatorS = sequence number indicatorPN = N-PDU number indicator

IP/U

DP

/GT

Phe

ader

son

Iu.

figure 26 IP/UDP/GTP frame layout.



The GTP-U frame contains the following elements : • version (3): The version field indicates the differentiates between different GTP

versions. UMTS must use GTP version 2 (b´001) or higher. GTP version 2 is specified in TS 29.060 V3.x.y. GPRS/GSM can use GTP version 1 (b´000) which has been specified in GSM TS 09.60.

• PT (Protocol Type) (1): The protocol type distinguishes between GTP (b´1) and GTP' (b´0) used between GSN and charging gateway function, and thus is a charging data protocol.

• E (Extension Header Flag) (1): This bit indicates whether the octet 12 of the header shall be evaluated (b´1) or not (b´0)

• S (Sequence Number Flag) (1): This bit indicates whether the octets 9 and 10 shall be evaluated (b´1) or not (b´0).

• PN (N-PDU Number Flag) (1): This bit indicates whether the octet 11 shall be evaluated (b´1) or not (b´0).

• Message Type (8): The message type differentiates between the following frame types: G-PDU (H´FF), Echo Request (H´01), Echo Response (H´02), Error Indication (H´1A), Supported Header Extension Indication (H´1F).

• Length (16): These two octets indicate the length of the payload (without GTP header) in bytes.

• TEID (Tunnel Endpoint ID) (32): The tunnel endpoint identifier of the destination. • Sequence Number (16): The sequence number is a strictly increasing label for each

G-PDU. For control message frames the sequence number is used as a transaction identifier (in other words: request and response have the same number). The sequence number is must be present when one of the E, S or PN bits are set. The sequence number shall be used only when the S bit is set.

• N-PDU Number (8): The N-PDU number represents a sequence number for network protocol data units (e.g. IP datagrams for external network). It is used during inter-SGSN routing area updates and inter-system handovers to support loss-less data transmission. This field must be present when one of the bits E, S or PN is set, this field shall be evaluated only when the PN bit is set.

• Next Extension Header Type (8): This field is used to indicate which extension header follows after the standard header. The value H´00 indicates that no extension header follows, H´01 means the PDCP number extension header. This field must be present when one of the bits E, S or PN is set and shall be evaluated only when the E bit is set.

After the header follows then either the payload (no extension header indicated) or an extension header.



8 7 6 5 4 3 2 1version

Message Type

Length

Tunnel Endpoint ID(TEID)

Sequence Number

N-PDU Number

PT 0 E S PN

Next Extension Header Type

1

2

3

4

5

6

7

8

9

10

11

12

Version : 0 0 1 (GTP V2)PT (Protocol Type): 1=GTP, 0=GTP´E (Extension Header) : octet 12 is validS (Sequence Number): octets 9/10 validPN (N-PDU Number): octet 11 valid

Message Type Code Message Type 0 0 0 0 0 0 0 1 Echo Request 0 0 0 0 0 0 1 0 Echo Response 0 0 0 1 1 0 1 0 Error Indication 0 0 0 1 1 1 1 1 Supported Header Extension Indication 1 1 1 1 1 1 1 1 G-PDU

GT

Phe

ader

and

GT

P-U

rel

evan

tmes

sage

type

cod

es.

Next Header Extension Type

Type

0 0 0 0 0 0 0 0 No more extension headers 0 0 0 0 0 0 0 1 PDCP PDU Number extension header.

figure 27 GTP frame format.



The extension headers of GTP are built according to a model consisting of the following elements : • Extension Header Length (8), • Extension Header Content (N*8) : The extension header content represents the

meaning of this header. It must be an integral multiple number of 8 bits. • Next Extension Header Type (8): This field indicates, what comes after this

extension header. When this field is H´00 the payload will follow. The only extension header that is currently defined is the extension header for PDCP PDU numbers. In case of relocations and associated handovers, this header can be used to support loss-less relocation.



8 7 6 5 4 3 2 1

Extension Header Length

Extension Header Content


8 7 6 5 4 3 2 1

PDCP PDU Number


PDCP PDU number extension headerGeneral Extension Header Layout

0 0 0 0 0 0 0 1

GT

Pex

tens

ion

head

er..

figure 28 Extension header layout and PDCP Number extension header.

VIII. Iub Interface and Node B Application Part NBAP


Iub Interface and Node B Application Part NBAP

Module Objectives:

• Protocol Model of Iub, • Logical Model of Node B,

• Node B Application Part NBAP Protocol,

• Frame Protocols.



1 Iub Interface Principles



1.1 Protocol Model and Interface Tasks The protocol model on the Iub interface between RNC and Node B follows the general protocol model that consists out of control plane, user plane and network control plane : • control plane : The control plane is built from the NBAP (Node B application part)

protocol, that is used to control the Node Bs from the controlling RNC.

• user plane : The user plane is used to send transport channel data to/from the UE between RNC and Node B.

• network control plane : The network control plane is formed by the ALCAP (Access

Link Control Application Part), that is used to set up user plane bearers for the transport channels.



NBAP Transport ChannelFrame Protocols

SAAL (UNI)

AAL type 5

SAAL (UNI)

AAL type 5 AAL type 2

Signaling Transport Converter

AAL 2Signaling Protocol

ATM + Physical Layer

figure 1 Iub protocol model.



The data between UE and serving RNC must be sent over the Iub interface from Node B and RNC. This data covers user data and signaling (RRC messages). On the Iub interface the user plane is used for that, The data coming or going to the UE is packed in a frame protocol on Iub and sent inside a AAL2 virtual channel. The AAL2 virtual channel carries the transport channel data. For dedicated transport channels the AAL2 virtual channel is set up dynamically. For common transport channels the AAL2 virtual channel is set up by operation and maintenance when a cell is configured, so no dynamical set up is needed. The configuration of such AAL2 virtual channel call is one of the tasks of NBAP. For the NBAP signaling, that is exclusively exchanged between RNC and Node B, a special signaling virtual channel of type 5 must be created. The NBAP (Node B Application Part) is used by the controlling RNC to configure the Node B and the corresponding radio resources. Thus the NBAP protocol has the following functions : • cell configuration management : Controlling RNC can manage the cell

configuration information in a Node B.

• common transport channel mgt. : The C-RNC can configure the common transport channel resources in a cell.

• system information mgt. : The C-RNC can modify the scheduling of the System

Information of a cell. • resource event mgt. : The Node B can inform the C-RNC about the status of its

resources. • measurements : The Node B reports radio frequency measurements on common

and dedicated resources. • radio link mgt. and supervision : This function allows the C-RNC to manage and

supervise radio links (dedicated resources).



NBAP

Transport ChannelFrame Protocols

SAAL (UNI)



Signaling

NBAP functions :

-cell configuration-common TrCH mgt.-system information mgt.-measurements-radio link mgt/supervision

RF/WCDMA

Transport Channels

M enu

UE

Node B

RNC

figure 2 Signaling data and transport channels on Iub.



1.2 Logical Model of Node B Resources To standardize the communication between Node B and controlling RNC, a logical model of the Node B with all its resources is defined. The elements that can be created, modified or deleted in the Node B model can be categorized by the following: • Node B communication context : A communication context corresponds to all

dedicated resources that are necessary for a user in dedicated mode. This includes also shared channels (e.g. USCH, DSCH).

• Common transport channels : Common transport channels are configured in the

Node B on request of the C-RNC. • Transport network logical resources : The resources (bearer services) on the Iub

ATM interface are described by this item. • Radio network logical resources : The radio network resources are cells, common

physical channels and common transport channels. These elements provide a standardized picture of a Node B.



Node B

Radio Network Logical Resource

Cell Cell Cell…

Transport Network Logical Resources

Communication ContextsCommon Transport

Channels

ControllingRNC

figure 3 Logical model of Node B resources.



1.2.1 Transport Network Logical Resources In this model the interface Iub is divided into ports for the different Node B resources, such as dedicated channels, common transport channels and the cells itself. The following ports are defined: • Node B control port : This port is for general O&M operation for the Node B and to

create other ports and elements. There is one control port per Node B. This control port corresponds to one signaling bearer between C-RNC and Node B.

• Communication control port : The communication control port is used for UE

dedicated signaling between C-RNC and Node B. One Node B can have several communication control ports. One signaling bearer can support at most one communication control port.

• Iub DCH Data Port : Represents the user plane transport bearer for one and only

one DCH data stream or to combined DCH data streams. • Iub RACH Data Port : Transports the RACH data streams. • Iub CPCH Data Port : Transports the CPCH data streams. • Iub FACH Data Port : Transports the FACH data streams. • Iub DSCH Data Port : Transports the DSCH data streams. • Iub USCH Data Port : Transports the USCH data streams. • Iub PCH Data Port : Transports the PCH data streams. The DCH, DSCH and USCH user data streams that correspond to one or more UE contexts and are thus controlled by a common communication control port are called traffic termination point .



Node B

Traffic Termination Point

Controlling RNC

Cell Cell Cell Cell Cell…

ControlPort RACH CPCH FACH PCH DSCH DCH USCH

Comm.Port

figure 4 Transport network logical resources.



1.2.2 Communication Context A communication context means all dedicated resources necessary for a user in dedicated mode. One Node B can keep multiple communication contexts. A communication context is described by a list of attributes, which shall always include: • a list of cells where dedicated or shared physical resources are used,

• a list of DCH which are mapped to the dedicated physical resources, • a list of DSCH and USCH used by this UE, • the complete DCH characteristics for each DCH, • the complete transport channel characteristics for each DSCH and USCH, • a list of Iub DCH data ports (Transport network resource), • a list of Iub DSCH and USCH data ports, • for each Iub DCH data port the corresponding cells and DCH, that are multiplexed to

this data port, • for each Iub DSCH and USCH data port the corresponding cells and DSCH and

USCH, that are carried on this port, • physical layer parameters (outer loop power control, etc.). A communication context is typically associated with a communication control port. The communication context itself is created using the Node B control port. This also means, that a communication context is restricted to one Node B.



Node B

Cell Cell Cell


Controlling RNC

DSCH DCH USCHComm.

Port

Communication Context :

cell list

DCHs

DSCHs / USCHs

DSCHs / USCHs

DCH data ports

DSCH/USCH Data ports

Physical layer parameters

TrCh characteristics

figure 5 Node B communication contexts.



1.2.3 Common Transport Channel Resources Common transport channels as defined on the Uu interface as services offered by the physical layer towards MAC have to be configured in each cell. The controlling RNC is responsible for this configuration. The common transport channels RACH, FACH, CPCH, DSCH, USCH and PCH can be configured in the Node B. Therefore each of these channels has its own port on the transport network interface. The BCH is always pre-activated in each cell. So there is no special port for a BCH. Instead each BCH can be modified by the controlling RNC using the Node Bs control port with NBAP messages.



Node B


Controlling RNC

Cell Cell Cell Cell Cell…

ControlPort RACH CPCH FACH PCH DSCH DCH USCH

Comm.Port

Common Transport Channels(TrCH type, associated ports, associated cells,

Physical parameters)

figure 6 Common transport channel resources.



For the control of the common transport channels, an operational state is defined for each common transport channel. This state has three values: • not existing : The resource does not exist in the Node B. • enabled : The resource can be used by the C-RNC. • disabled : The resource is blocked due to failures or congestion. Between these states there are several transitions, that can be triggered by the C-RNC or by other events. The transitions between NOT EXISTING and ENABLED and all transitions to NOT EXISTING are triggered by the C-RNC using NBAP procedures. In contrast to that the transitions between ENABLED and DISABLED are due to some external events. In this case a status notification will be sent by the Node B to the C-RNC.



Not Existing

Enabled

Disabled

CommonTransportChannel

SetupRequest

CommonTransportChannelDelete

Request CommonTransportChannelDelete

RequestResourceStatus

Indication(disabled)

ResourceStatus

Indication(enabled)

figure 7 Common transport channel states.



1.2.4 Radio Network Logical Resources The Node B terminates the air interface Uu, so that all radio related aspects will run through the Node B. The controlling RNC has to manage also these radio resources. The radio resources contain the cells, the common physical channels and also the common transport channels discussed before.



CELL(cell-ID)

PCPICH(CPCId)

SCPICH(CPCId)

S-SCH(CPCId)

P-SCH(CPCId)

FDD mode

PCCPCH(CPCId)

PICH(CPCId)

SCCPCH(CPCId)

PRACH(CPCId)

AICH(CPCId)

PCPCH(CPCId)

CD/CA-ICH(CPCId)

AP-ICHCSICH(CPCId)

Resourceidentifier

1 0-m 1 1 1 0-i 0-i 0-k 0-k

0-j0-q0-q

1

CPCH(CTCId)

BCH(CTCId)

PCH(CTCId)

FACH(CTCId)

RACH(CTCId)

1-p

1

1

1 0-1 0-n 1

11

FACH(CTCId)

1

0-nchild multiplicity

(0-n FACH possible)

parent multiplicity(FACH belongs to 1 SCCPCH)

CPCId: Common Physical Channel IdCTCId: Common Transport Channel Id

figure 8 Organization of radio network resources in object oriented form.



The main resource of the radio network is the cell. Cells can be managed and configured by the C-RNC. Note that this does not mean, that a cell administration at the Node B is not necessary. To organize the cell management, two state definitions are introduced : • local cell state : This state is maintained at the Node B and has the values

EXISTING and NOT EXISTING. A cell that has local state NOT EXISTING can not be configured by the C-RNC. By local operation at the Node B (configuration of hardware and software) the local state of the cell can become EXISTING. This is now reported to the C-RNC, such that the now available cell can be configured by the C-RNC.

• resource operational state : The operational state of the cell is applicable in local

cell state EXISTING only. The values of the operational state are NOT EXISTING (not configured cell, but available for the C-RNC), ENABLED (cell is configured by the C-RNC and can be used) and DISABLED (cell is configured by C-RNC but currently out of service).

The transitions between the local cell states are triggered by O&M intervention at the Node B. The operational states NOT EXISTING and ENABLED are changed by C-RNC operations using NBAP procedures. Only the transitions between ENABLED and DISABLED are due to local events in the Node B. In this case a notification is sent to the C-RNC by the Node B.



Not Existing

Enabled

Disabled

CellSetup

Request

CellDelete

Request

CellDelete

Request

ResourceStatus


ResourceStatus

Indication(enabled)

Not Existing

Existing

ResourceStatus

Indication(add cell)

ResourceStatus

Indication(delete cell)

Local Cell State Operational Cell State

figure 9 States of radio network resources.



The common physical channels have an operational state only. This state definition is similar to the common transport channels. The common physical channels will be in state ENABLED, when the C-RNC configures the cell using a NBAP procedure.



Not Existing

Enabled

Disabled

CellSetup

Request

CellDelete

Request

CellDelete

Request

ResourceStatus


ResourceStatus

Indication(enabled)

figure 10 Common physical channel resource states.



2 Node B Application Part NBAP



2.1 NBAP tasks, functions and message transport The Node B Application Part (NBAP) is the application specific protocol on the Iub interface. The general task of NBAP is to provide procedures to enable the radio resource controlling of the Node B by the controlling RNC. Therefore the NBAP supports messages that are transported via the ATM transport network using AAL 5 bearer services with SAAL (Signaling ATM Adaptation layer). SAAL especially guarantees the in-sequence delivery of NBAP messages. The NBAP protocol provides functions for the following things: • Cell Configuration Mgt. : Cell configuration management means cell set up,

reconfiguration and deletion triggered by the C-RNC.

• Common TrCH Mgt. : The C-RNC is able to set up, to reconfigure and to delete common transport channels in a cell.

• System Information Mgt. : To update the system information broadcasted in a cell,

the C-RNC can use NBAP procedures. • Resource Event Mgt. : The C-RNC can block or unblock Node B resources. On the

other hand the Node B can inform the C-RNC about the status of a certain resource. • Configuration Alignment : This function enables Node B and C-RNC to verify their

information about the resources. • Measurements on Common Resources : This function allows the C-RNC to start

measurements in the Node B, and the Node B can report these measurements. • Radio Link Mgt. : The C-RNC can set up, add, delete and prepare radio links used

for dedicated mode. • Radio Link Supervision : This is used to report failures and restorations of radio

links. • Measurements on dedicated resources : The C-RNC can request the Node B to

measure certain radio links and to report these measurements.



Cell Configuration Mgt.

Node B Application Part - NBAP

Common TrCH Mgt.

System Information Mgt. Resource Event Mgt.

Configuration AlignmentMeasurements on common

resources

Radio Link Mgt. Radio Link Supervision

Measurements on dedicatedresources

figure 11 NBAP tasks and functions.



2.2 NBAP Cell Configuration Management Procedures The cell configuration management procedures are used by the C-RNC for • cell set up ,

• cell reconfiguration , • cell deletion . The corresponding cell is identified by its cell-Id .

2.2.1 Cell Creation The cell set up is triggered by the C-RNC using the NBAP message CELL SETUP REQUEST. The parameters in the message describe the cell configuration, especially the parameters of the physical channel configuration. The Node B will configure the cell and its physical channel resources. When the configuration is successful, the Node B will confirm with CELL SETUP RESPONSE. Otherwise the Node B shall send the message CELL SETUP FAILURE to the C-RNC. The cell set up procedure can be started when the cell is indicated to be available only. When the procedure is completed successfully, the cell is in operational state ENABLED.



CELL SETUP REQUEST

( cell-ID, physical channel parameters )

CELL SETUP RESPONSE

C-RNCNode B

figure 12 Cell creation and configuration procedure.



2.2.2 Cell Reconfiguration A cell in operational state ENABLED can also be reconfigured by the controlling RNC. Therefore the C-RNC uses the NBAP message CELL RECONFIGURATION REQUEST. The cell will be identified by its cell-ID. As in the CELL SETUP REQUEST message, the physical channel resources can be reconfigured. If the cell reconfiguration is successful, the Node B will confirm with CELL RECONFIGURATION RESPONSE. In case of failures the Node B will issue a CELL RECONFIGURATION FAILURE message.



CELL RECONFIGURATION REQUEST

( cell-ID, physical channel parameters )

CELL RECONFIGURATION RESPONSE

C-RNCNode B

figure 13 Cell reconfiguration.



2.2.3 Cell Deletion A cell that is in operational state ENABLED or DISABLED can be deleted by the C-RNC. This will bring the cell’s operational state to NOT EXISTING. The C-RNC will send the message CELL DELETION REQUEST to the Node B. The cell will again be identified by its cell-ID. The Node B will now deactivate the cell, but still the cell seen as resource is available (local cell state is EXISTING).The Node B shall always respond with CELL DELETION RESPONSE. This happens also, when the cell-Id from the CELL DELETION REQUEST is not existing.



CELL DELETION REQUEST

( cell-ID )

CELL DELETION RESPONSE

C-RNCNode B

figure 14 Cell deletion.



2.3 Common Transport Ch annel Management Procedures

After a cell has been set up, the common resources have to be configured. This includes the common physical channels FACH, PCH, RACH, CPCH. Also the related physical channels associated with the transport channels have to be configured.

2.3.1 Common Transport Channel Establishment For the set up of a common transport channel, the C-RNC will send the COMMON TRANSPORT CHANNEL SETUP REQUEST . With this message the following combinations of transport channels can be configured : • (FDD) FACH, one PCH and/or one PICH related to one SCCPCH,

• (TDD) Secondary CCPCH and FACH, PCH with the corresponding PICH, • one RACH and/or one AICH related to one PRACH, • (FDD) one CPCH and/or one AP-AICH and/or one CD/CA-ICH related to one

PCPCH. The Node B will set up the common transport channel and its associated physical channels on reception of this message. This will bring the operational state of the common transport channel to ENABLED. In case this is successful, the Node B will send the NBAP message COMMON TRANSPORT CHANNEL SETUP RESPONSE . Otherwise the message COMMON TRANSPORT CHANNEL SETUP FAILURE will be sent.



COMMON TRANSPORT CHANNEL SETUP REQUEST

( cell-ID, transport channel parameters, physical channel parameters )

COMMON TRANSPORT CHANNEL SETUPRESPONSE

C-RNCNode B

figure 15 Common transport channel creation.



2.3.2 Common Transport Channel Reconfiguration and Deletion Transport channels in operational state ENABLED and DISABLED can be reconfigured or deleted by the controlling RNC. Therefore the messages COMMON TRANSPORT CHANNEL RECONFIGURATION REQUEST(RESPONSE) or COMMON TRANSPORT CHANNEL DELETION REQUEST(RESPONSE) will be used. For the reconfiguration the same channel combinations can be reconfigured like in the set up procedure.



COMMON TRANSPORT CHANNEL RECONFIGURATION REQUEST / DELETION REQUEST

( cell-ID, ... )

COMMON TRANSPORT CHANNELRECONFIGURATION RESPONSE / DELETION RESPONSE

C-RNCNode B

figure 16 Common transport channel reconfiguration and deletion.



2.4 Resource Event Management The resource event procedures are used by the Node B to report resource status information to the controlling RNC. This is done especially for the radio network resources (cells, common transport channels, common physical channels) and for the transport network resources (ports).

2.4.1 Resource Status Indication Procedure The RESOURCE STATUS INDICATION message is sent by the Node B to the controlling RNC in the following cases : • a cell becomes EXISTING or NOT EXISTING (local cell state) in the Node B,

• a cell changed its resource operational state (ENABLED <-> DISABLED) and/or its

capabilities, • a common transport or physical channel changes its capabilities or operational state

(ENABLED <-> DISABLED). To indicate which effect the indicated event will have, the RESOURCE STATUS INDICATION message has the parameter Indication type inside. This parameter can be : • no failure (e.g. when a cell becomes existing or a common transport channel

becomes enabled),

• service impact (e.g. a cell becomes not existing) Together with the indication type parameter several characteristics of the resource can be indicated.



RESOURCE STATUS INDICATION

( indication type, resource characteristics )

C-RNCNode B

figure 17 Resource status indication procedure.



2.4.2 Blocking and Unblocking of Resources When a cell shall become inaccessible the Node B will inform the controlling RNC with the message BLOCK RESOURCE REQUEST . This message will request the C-RNC to prohibit the traffic to the corresponding cell. The message contains a Blocking Priority Indicator. If this indicator is set to “High Priority” the C-RNC shall prohibit the usage of the cell immediately. If the indicator is “Normal Priority” the C-RNC shall block the cell when it is idle or after the expiry of the Shut Down Timer specified in the message. If the priority is “Low Priority” the C-RNC will block the cell when it is idle. If the resources are successfully blocked, the C-RNC sends the BLOCK RESOURCE RESPONSE message to the Node B. The cell enters now the state DISABLED. This means the cell is still in local cell state EXISTING and it is configurable. When the Node B decides to unblock the cell it will issue a UNBLOCK RESOURCE INDICATION message to the C-RNC. Traffic to this cell can be restarted.



BLOCK RESOURCE REQUEST

( cell-Id, blocking priority, shut down timer )

BLOCK RESOURCE RESPONSE

UNBLOCK RESOURCE INDICATION

( cell-Id )

C-RNCNode B

figure 18 Blocking and unbl ocking of resources.



2.5 System Information Management The controlling RNC is able to update the system information broadcasted in a cell. Therefore the C-RNC will send the NBAP message SYSTEM INFORMATION UPDATE REQUEST to the corresponding Node B. The message can contain requests for modification of already broadcasted system information or can request the Node B to add or delete system information blocks. Additionally the scheduling of the system information blocks can be changed. On reception of this message the Node B will reconfigure the BCCH of the cell. If this is done it will acknowledge with SYSTEM INFORMATION UPDATE RESPONSE . Otherwise the SYSTEM INFORMATION UPDATE FAILURE message is sent.



SYSTEM INFORMATION UPDATE REQUEST

SYSTEM INFORMATION UPDATE RESPONSE

C-RNCNode B

figure 19 System information update procedure.



2.6 Radio Link Mana gement Procedures In contrast to the common channels, that are configured semi-static to the cell, the dedicated channels for a certain UE are assigned dynamically. Hence there are special procedures to tell the Node B to assign a radio link (=dedicated resources) to a certain UE.

2.6.1 Radio Link Setup (Communi cation Context Creation) The dedicated resources of one UE are handled by the Node B in form of a communication context. With the first radio link attached to this UE this communication context will be created. Therefore the NBAP procedure message RADIO LINK SETUP REQUEST will be sent by the controlling RNC to the corresponding Node B. On reception of this message the Node B shall allocate necessary resources like transport channels (DCH or shared channels ,e.g. DSCH, USCH) and physical channels . The RADIO LINK SETUP REQUEST message contains UL and DL physical channel information (scrambling codes, spreading codes, transport format combination sets, inner loop power control parameters). If this is done the Node B will send RADIO LINK SETUP RESPONSE back to the controlling RNC. If an error occurred, the message RADIO LINK SETUP FAILURE will be used instead.



RADIO LINK SETUP REQUEST

RADIO LINK SETUP RESPONSE

( UL/DL physical channel information )

( Node B communication context ID )

C-RNCNode B

figure 20 Radio link setup procedure to create a communication context.



2.6.2 Radio Link Addition and Deletion Once a communication context has been established using a radio link set up procedure, additional radio links can be appended to the context (soft handover) or radio links can be removed from the communication context. In both cases the controlling RNC triggers the procedure by RADIO LINK ADDITION REQUEST or RADIO LINK DELETION REQUEST . Inside the addition request message the new radio link will be specified like in case of the set up request. In the deletion request message the radio link identities (RL ID), for the radio links to be released, will be given. The Node B will try to perform the requested procedure (either adding a new radio link or removing existing radio links). An acknowledgement is sent back by issuing either RADIO LINK ADDITION RESPONSE or RADIO LINK DELETION RESPONSE . If the last radio link has been removed from the communication context, the context will be terminated too.



RADIO LINK ADDITION REQUEST

RADIO LINK ADDITION RESPONSE

( communication context ID,UL/DL physical channel information )

RADIO LINK DELETION REQUEST

RADIO LINK DELETION RESPONSE

( communication context ID, RL ID )

C-RNCNode B

figure 21 Radio link addition and deletion.



2.6.3 Synchronized Radio Link Reconfiguration Of course sometimes it might be necessary to reconfigure all or part of all radio links belonging to one communication context. For this there are two types of reconfiguration procedures. The first one is the synchronized procedure, where the change of the radio link configuration will first be prepared and then the switching to the new radio link configuration takes place on command of the controlling RNC. This procedure is initiated by the C-RNC by sending the RADIO LINK RECONFIGURATION PREPARE REQUEST message to the affected Node Bs. These Node Bs will now prepare all necessary resources for the new radio link configuration, but will not execute the switching from the old to the new configuration. The Node Bs will only send the RADIO LINK RECONFIGURATION PREPARE READY message. After the preparation is done, the C-RNC can either abort the reconfiguration (RADIO LINK RECONFIGURATION CANCEL message) or trigger the execution of the reconfiguration with RADIO LINK RECONFIGURATION COMMIT . On reception of the RADIO LINK RELOCATION COMMIT message the Node Bs will switch to the new radio configuration at the begin of the radio frame indicated in the message.



RADIO LINK RECONFIGURATION PREPARE

( communication context ID, new radio link parameters )

RADIO LINK RECONFIGURATION READY

RADIO LINK RECONFIGURATION COMMIT

C-RNCNode B

figure 22 Synchronized radi o link reconfiguration.



2.6.4 Unsynchronized Radio Link Reconfiguration The second type of radio link reconfiguration is the unsynchronized version. In this case there is no exact timing for the switching from old to new radio configuration. Moreover it is left to the Node B when the reconfiguration is performed. The procedure consist of two messages. The reconfiguration is triggered by the C-RNC with the message RADIO LINK RECONFIGURATION REQUEST . Again this message contains the new radio link parameters for a communication context. On reception of this message the Node B prepares the new resources and executes the reconfiguration. If this is done the RADIO LINK RECONFIGURATION RESPONSE message is sent back.



RADIO LINK RECONFIGURATION REQUEST

RADIO LINK RECONFIGURATION RESPONSE

( communication context ID,UL/DL physical channel information )

C-RNCNode B

figure 23 Unsynchronized radi o link reconfiguration.



2.6.5 Radio Link Failure If the Node B detects, that one or more radio links of a communication context are no longer available, it sends the message RADIO LINK FAILURE INDICATION to the controlling RNC. Typical causes for a failure of a radio link are • synchronization failure (physical layer cannot detect UE signal), • transport resources unavailable (e.g. congestion on Iub), • control processing overload (Node B processors in congestion), • hardware failure, • O&M intervention.



RADIO LINK FAILURE INDICATION( communication context ID,

failure cause )

C-RNCNode B

figure 24 Radio link failure indication.



2.7 Measurement Control Procedure The Node B is able to perform radio measurements on its radio resources. This includes common and dedicated resources. The controlling RNC has to request the measurements with the message COMMON MEASUREMENT INITIATION REQUEST or DEDICATED MEASUREMENT INITIATION REQUEST for common channels or dedicated radio links respectively. The message contains the resource for the measurement and filter parameters for the measurements. Also the message contains information when to send measurement reports (e.g. periodic report, report on thresholds). If the measurement can be performed by the Node B, it will acknowledge the request with either COMMON MEASUREMENT INITIATION RESPONSE or DEDICATED MEASUREMENT INITIATION RESPONSE . Note that this message can contain a first measurement report. After this the Node B will now measure the activated radio parameters and send measurement reports periodically or when certain thresholds are reached. This will be done in a COMMON/DEDICATED MEASUREMENT REPORT message. The C-RNC can stop the measurements by sending a COMMON/DEDICATED MEASUREMENT TERMINATION REQUEST to the Node B.



COMMON/DEDICATED MEASURMENTINITIATION REQUEST

( measurement type, periodic or threshold reporting )

COMMON/DEDICATED MEASUREMENTINITIATION RESPONSE

COMMON/DEDICATED MEASUREMENT REPORT

COMMON/DEDICATED MEASUREMENT REPORT

...

COMMON/DEDICATED MEASURMENTTERMINATION REQUEST

C-RNCNode B

figure 25 Measurement control procedure.



2.8 NBAP Message Formatting The messages of NBAP are defined in ASN.1 using Packed Encoding Rules (PER) for encoding. This is the same as for RRC, RANAP and RNSAP formatting.



3 Frame Protocols



3.1 Frame Protocol Architecture On the link between Node B and controlling RNC (Iub interface) the NBAP organizes the signaling. The data to and from the UE also has to run over this interface. This data consists in principle of the transport channels. Therefore the Iu interface provides so called frame protocols . These protocols are used for the transfer of dedicated and common transport channels between Node B and RNC. Next to the pure transport task, these protocols also provide functionality for synchronization between Node B and RNC. For the transport channel transfer the Iub interface uses AAL2 virtual channels. The difference between common and dedicated transport channels is, that dedicated transport channels will use AAL2 virtual channels with dynamical set up and release (ALCAP protocols).



C-RNC

NBAP


SAAL (UNI)



SignalingRF/WCDMA

Transport Channels

SignalingTransport

AAL 2 –ALCAP

Menu

UE

Node B

figure 26 Protocol architecture on Iub.



3.2 Transport Channe l Frame Protocols

3.2.1 Transport Block Transfer Frames The recommendation TS 25.435 and TS 25.427 define frame protocols for the common transport channels • RACH, • CPCH, • FACH, • PCH, • DSCH, • USCH, • DCH. For each of these transport channels an individual frame is defined. The content of one of these transport channels is packed into an established AAL2 virtual channel. One such frame can typically carry one or more transport blocks (TB). Because it is possible, that several different transport formats are used, the TFI (Transport Format Indicator) is sent in the frame too. Note that BCH information is not transported via this mechanism, instead the NBAP procedure SYSTEM INFORMATION UPDATE is used to transport the system information to the Node B.



MAC MAC

PHY

TransportBlockSet

TB 1TB 2

TB N

PHY

PhCH

PhCH

FrameProtocol

FrameProtocol

TransportBlockSet

TB 1TB 2

TB N

AAL 2ATM

AAL 2ATM

TrCH frame

TrCH frame

UE Node B RNC

figure 27 Transfer of transport blocks over Uu and Iu.



3.3 Data Transfer Procedure The data transfer procedure is used to convey transport blocks of a certain transport channel to Node B or to RNC. This is simply done by sending a transport channel frame on the Iub interface in the AAL 2 virtual channel assigned to this transport channel. For common transport channels also the virtual AAL2 channel is common, for a DCH the AAL 2 virtual channel is usually dedicated to one UE. The frames contain the transport blocks of the corresponding transport channel and the transport format indicator (TFI) associated to the current transport block combination. Additional parameters in the frames are timing information (receive time, send time), power control parameters (only for downlink frames). In case of several DCH attached to one UE, one frame can also carry the transport blocks of several DCH.



MAC – PDUs onRACH, CPCH, USCH, DCH

RACH-, CPCH-, USCH-, DCH- Data Frame

( Transport blocks, TFI, timing parameter )

MAC – PDUs onDSCH, PCH, FACH, DCH

DSCH-, PCH-, FACH-, DCH- Data Frame

( Transport blocks, TFI, timing parameter,power control parameter )

C-RNCNode B

M enu

UE

figure 28 Data transfer procedures.



3.4 Node Synchronization The node synchronization procedure is used in AAL2 virtual channels for common and dedicated transport channels. The procedure is used to exchange timing information (radio frame numbers) between controlling RNC and Node B. The C-RNC triggers the procedure by sending a DL Synchronization frame to the Node B. The frame contains the so called t1 number, which is the radio frame number of the RNC when the frame was send by the RNC. The Node B will receive this frame through the AAL 2 virtual channel and will answer with a UL Synchronization frame. This frame contains now again t1 plus two additional times t2 and t3. The number t2 is the radio frame number, when the Node B received the DL Synchronization frame, whereas t3 indicates the radio frame number, when the UL Synchronization frame was sent. With this both nodes have the three time values t1, t2 and t3, such that they can translate their own time values in to the time values of the other entity.



UL SYNCHRONISATION( t1, t2, t3 )

DL SYNCHRONISATION( t1)

Node B C-RNC

figure 29 Node synchronization procedure.



3.5 Frame Protocol Format The frame protocols of the Iub interface are defined in TS 25.435 and TS 25.427. For each frame type an individual frame format is defined. The next figure shows as example the format of a UL- DCH frame. The frame begins with a CRC (Cyclic Redundancy Check) for the header information. The field FT (Frame Type) is set to 0 for a data frame. After this the CFN (Connection Frame Number) which indicates on which radio frame the data shall be send or was received is included. In a UL-DCH data frame the transport blocks of several DCH can be transported. Therefore a list of the TFI for each DCH that is assigned to the UE is send. From these TFI the receiver of the data can decompose the payload into the transport blocks of each DCH. Now the payload is following. In it one can find the data of all transport blocks according to the TFI for each DCH. Each transport block will be transmitted octet aligned with the help of padding bits. After the transport block data a quality estimate (QE) is included. The QE is calculated out of the BER (Bit Error Rate) of the received data. Then for each transport block a CRC indicator (CRCI) is transmitted. When this CRCI is 0 the received transport block has no errors from the air interface. If it is 1 air interface errors corrupted some bits. Last a check sum over the complete payload is transmitted, to enable the RNC to check on errors from the ATM transmission line.



figure 30 Frame layout for uplink DCH.

FTHeader CRC

TFI of first DCHTFI of first DCH

TFI of last DCH

QE

First TB of first DCH

First TB of first DCH (cont.) Pad

Last TB of last DCH (cont.) Pad

Last TB of last DCH

Payload Checksum

Header

Payload

Optional

7 0

CRCI of

first TB of

first DCH

PadCRCI of

lastTB of

last DCH

Last TB of first DCH

Last TB of first DCH (cont.) Pad

First TB of last DCH

First TB of last DCH (cont.) Pad

Payload Checksum (cont)

CFN

Spare Extension

Spare

Spare

IX. Iur Interface and Radio Network Subsystem Application Part RNSAP


Iur Interface and Radio Network Subsystem Application Part RNSAP

Module Objectives:

• Iur Interface Protocol Stack,

• Logical Model of Drift RNC Resources,

• Role of SCCP on Iur,

• RNSAP Procedures.



1 Iur Interface Principles



1.1 Iur Interface Tasks and Protocol Model The Iur interface is used for the communication between serving RNC and drift RNC. Its task is to allow the serving RNC to perform remote cell control. This means, that the cell resources of the drift RNC can be used by the serving RNC for its subscribers. But the serving RNC can not directly control the cell (it is not the controlling RNC for these cells), instead the serving RNC uses the Iur interface towards the controlling RNC of the cells (which is the drift RNC) and sends its requests. The protocols of the Iur interface is structured according to the general model with control, network control and user plane. The control plane is governed by the RNSAP (Radio Network Subsystem Application Part), which provides all necessary messages for the control related communication between serving and drift RNC. The RNSAP messages will be send on a signaling bearer provided by SCCP, MTP3B, SAAL and AAL5 over ATM. The SCCP protocol will be used to set up signaling connection for a UE between serving and drift RNC. The user plane of the Iur interface consists out of frame protocols for the transport channels, like it is known from Iub interface. The frame protocols for dedicated transport channels DCH are the same as on Iub, the frame protocols for common transport channels are specific to Iur, because the UE data on common channels has to be identified by its drift RNTI D-RNTI or serving RNTI S-RNTI. The transport channel data is transported in AAL2 virtual channels over ATM. For the establishment and release of the AAL2 user bearers, the network control plane with the AAL2 signaling protocol is used.



1

RNSAP


SCCP



Signaling

Transport Channels

SAAL (NNI)

S-RNTI

D-RNTI

Menu

UE

Node B D-RNC

S-RNC

figure 1 Architecture of Iur.



1.2 Logical Model of Drift RNC Resources The serving RNC needs an imagination of the resources in a drift RNC. This is necessary to make the meaning of RNSAP messages and procedures unique. Hence there is a logical model that is used as abstract view on a drift RNC. This model is relatively simple. For the control signaling between D-RNC and S-RNC a Iur control port is used. This port is typically connected with the AAL5 virtual channel used to transport the RNSPA messages. For each configured transport channel there will also be a port, associated with the corresponding AAL2 virtual channel. For the radio resources the basic element is the cell. But in contrast to Iub where the controlling RNC knows the cell’s resources in detail, the serving RNC will see only the radio links established in these cells.



2

Drift RNC

Serving RNC

RadioLink

IurControl

Port

IurDCH

IurDCH

IurDSCH

IurDSCH

IurUSCH

IurRACH/CPCH/FACH

RadioLink

RadioLink

RadioLink

cell cell

… … IurUSCH

…Iur

RACH/CPCH/FACH

…

figure 2 Logical resource model of drift RNC.



2 Radio Network Subsystem Application Part RNSAP



2.1 RNSAP Functions and Tasks The tasks performed on the Iur interface can be divided into four categories: • UTRAN mobility procedures,

• dedicated transport channel procedures, • common transport channel procedures, • global procedures. The mobility task mainly have to do with the relocation of the serving RNC and paging. The other tasks deal with radio resource configuration.



3

Iur

UTRAN

Mobility

Mgt.

DCH

Mgt.

Common

TrCH

Mgt.

Global

Tasks

RNC RNC

figure 3 Categories of functions provided by RNSAP on Iur.



2.2 RNSAP Procedures – General Procedures

2.2.1 Common Transport Channel Resource Request When the UE shall use common transport channels in a cell that is not controlled by its serving RNC, then these channels must be configured for the UE using a RNSAP procedure. This procedure not only configures the radio resources, but it also prepares resources on the Iur user plane for the common transport channel data. The S-RNC will send for this purpose the RNSAP message COMMON TRANSPORT CHANNEL RESOURCES REQUEST . The message contains all information for the D-RNC to allocated common transport channel resources and resources on a ATM AAL 2 virtual channels for the UE. The message itself is sent in connectionless mode of SCCP. The D-RNC will response with COMMON TRANSPORT CHANNEL RESOURCES RESPONSE. When the common transport channel is no longer necessary for this UE, the S-RNC shall send the message COMMON TRANSPORT CHANNEL RESOURCES RELEASE REQUEST.



14

COMMON TRANSPORT CHANNEL RESOURCES REQUEST

COMMON TRANSPORT CHANNEL RESOURCES RESPONSE

COMMON TRANSPORT CHANNEL RESOURCES RELEASE REQUEST

D-RNC S-RNC

figure 4 Common transport channel request.



2.2.2 Uplink and Downlink Signaling Transfer Procedure The uplink and downlink signaling transfer procedure is used for transparent transport of RRC messages between UE and serving RNC using common control channels CCCH. If the S-RNC wants to send a RRC message to the UE on the CCCH (mapped to FACH), it will send the RNSAP message DOWNLINK SIGNALLING TRANSFER to the drift RNC. The message contains the cell identifier C-Id and the D-RNTI to identify the UE. The RRC message is contained as so called layer 3 parameter. On reception of this message the D-RNC shall send the RRC message on the FACH to the UE. If on the other hand the UE sends a RRC message using the S-RNTI (or U-RNTI) for identification on the RACH (CCCH) to the network, the D-RNC will forward this message to the S-RNC using the RNSAP message UPLINK SIGNALLING TRANSFER. This message contains the S-RNTI and the C-RNTI used by the D-RNC for the UE in this cell. Additionally the message contains of course the RRC message in the layer 3 parameter and the cell identity. If this is the first message from the UE to the serving RNC, the drift RNC shall allocated a drift RNTI for this UE and include it in the message. Both messages will be send in connectionless SCCP mode. For RRC message exchanged on dedicated control channels DCCH, this procedure will not be used. Instead the signaling of the DCCH will be multiplexed to the corresponding transport channel stream, which will be transported on Iur in one of the frame protocols of the user plane. So DCCH information is for the D-RNC only user data.



4

RRC – MSG UPLINK SIGNALLING TRANSFER

( cell ID, S-RNTI, RRC-MSG, D-RNTI )

DOWNLINK SIGNALLING TRANSFER

( cell ID, D-RNTI, RRC-MSG)

[RACH]

RRC – MSG[FACH]

D-RNC S-RNC

Menu

UE

figure 5 Transport of RACH/FACH RRC signaling messages over Iur.



2.2.3 Paging Procedure The paging procedure can be used by the serving RNC to page the UE in a cell belonging to the controlling RNC. For this the S-RNC sends to the RNSAP message PAGING to the controlling RNC of the corresponding cell. The message is sent in connectionless SCCP mode. It will include the cell Id or the URA Id.



5

PAGING

( cell ID or URA ID, IMSI, TMSI or PTMSI )RRC: Paging Type 1 or 2

D-RNC S-RNC

Menu

UE

figure 6 Paging carried over Iur to the D-RNC when UE is roaming into cell of D-RNC.



2.2.4 Relocation Commit Procedure The relocation commit procedure is used during S-RNC relocation, when the UE is not required to perform a hard handover associated with the relocation. The RNSAP message RELOCATION COMMIT is triggered, when the serving RNC gets the RANAP message RELOCATION COMMAND from the core network. This means that all resources for the relocation are prepared and the relocation shall be executed now. The serving RNC will send the RELOCATION COMMIT to the target RNC, which will become the new serving RNC. The message RELOCATION COMMIT can be send in connection-oriented and in connectionless mode of SCCP: • if the UE is currently utilizing one or more radio links in a cell of the Target-RNC, the

message shall be sent in connection-oriented mode (no further UE identifier is required),

• if the UE is currently not utilizing a radio link in a cell of the Target-RNC, the

message shall be sent in connectionless mode (in this case the message shall contain the D-RNTI for identification).

At the reception of the RELOCATION COMMIT message, the Target-RNC shall send the RANAP message RELOCATION DETECT, finalize the relocation and will become the new serving RNC for this UE. When this is done, the new serving RNC will send the RANAP message RELOCATION COMPLETE to the core network. This is typically done, when the new serving RNC allocated a new S-RNTI for the UE.



6

RELOCATION COMMIT

( D-RNTI, RANAP relocation information)

Relocation RequiredRelocation Request

Relocation CommandRelocation Request Ack.

UTRAN MobilityInformation

(new U-RNTI)

Relocation Detect

UTRAN MobilityInformation Confirm

Relocation Complete

D-RNC

M enu

UE S-RNCCN

figure 7 Serving RNC relocat ion with Iur interface.



2.3 RNSAP Procedures – DCH Management

2.3.1 Radio Link Establishment The DCH procedures of RNSAP are used to set up, modify and release radio links for a certain UE. The serving RNC needs the RNSAP procedures instead of the NBAP procedures, whenever the desired cell is in control of another RNC. To establish the first radio link for a UE in a cell controlled by the D-RNC, the serving RNC uses the RNSAP message RADIO LINK SETUP REQUEST . This message contains the S-RNTI for the UE. The message is sent in connection oriented SCCP mode, in fact a SCCP connection will be established with this message. Thus you will find the RADIO LINK SETUP REQUEST message in the SCCP message CR. If there is no D-RNTI in the RNSAP message, the D-RNC shall allocate a D-RNTI. The message itself also contains the physical channel information that is necessary to set up a radio link. The D-RNC will on reception of this message sent the NBAP message RADIO LINK SETUP REQUEST to the Node B that controls the cell. From it the RADIO LINK SETUP RESPONSE message (NBAP) comes back. When all requested radio links have successfully been established, the D-RNC will send the RNSAP message RADIO LINK SETUP RESPONSE back to the serving RNC. If a new D-RNTI was allocated, it shall be included in the response message.



7

RADIO LINK SETUP REQUESTRadio Link Setup Request

RADIO LINK SETUP RESPONSERadio Link Setup Response

D-RNC S-RNCNode B

figure 8 Radio link activation with D-RNC.



2.3.2 Radio Link Addition and Deletion When at least one radio link for a UE exists, then there is a signaling connection for this UE between S-RNC and D-RNC. The S-RNC can now add further radio links or remove some of the existing radio links. In the messages used for these purposes no UE identifier needs to be included, because all messages have to be sent within the existing SCCP connection. The procedure will be triggered by the serving RNC using the RNSAP messages RADIO LINK ADDITION REQUEST or RADIO LINK DELETION REQUEST . The D-RNC will on reception of one of these messages trigger the corresponding procedure to the Node B. Then it will give a response message back to the serving RNC. When the last radio link is deleted with RADIO LINK DELETION REQUEST, then the D-RNC shall also release the SCCP signaling connection with the RADIO LINK DELETION RESPONSE.



8

RADIO LINK ADDITION REQUESTRadio Link Addition Request

RADIO LINK ADDITION RESPONSERadio Link Addition Response

RADIO LINK DELETION REQUESTRadio Link Deletion Request

RADIO LINK DELETION RESPONSERadio Link Deletion Response

D-RNC S-RNCNode B

figure 9 Radio link addition and deletion procedure.



2.3.3 Synchronized Radio Link Reconfiguration Already the NBAP defines two types of procedures to reconfigure radio links for a UE. The first type is the synchronized reconfiguration and the second type is the unsynchronized reconfiguration. For cells that do not belong to the serving RNC the corresponding procedures from RNSAP must be used. Of course it is a prerequisite, that radio links and the associated SCCP connection on Iur exist. The synchronized reconfiguration works on Iur in the same way like on Iub. First the serving RNC will trigger the procedure by sending RADIO LINK RECONFIGURATION PREPARE. On reception of this message the D-RNC will prepare all necessary resources for the reconfiguration, but will not perform the reconfiguration. Instead the D-RNC will send the message RADIO LINK RECONFIGURATION READY back to the S-RNC. When the reconfiguration shall be executed, the S-RNC sends RADIO LINK RECONFIGURATION COMMIT to the D-RNC with an indication, at which radio frame the configuration shall be executed. If the serving RNC cancels the reconfiguration it shall not send the commit message, but will use the message RADIO LINK RECONFIGURATION CANCEL instead.



9

RADIO LINK RECONFIGURATIONPREPARERadio Link Reconfiguration Prepare

RADIO LINK RECONFIGURATIONREADYRadio Link Reconfiguration Ready

RADIO LINK RECONFIGURATIONCOMMITRadio Link Reconfiguration Commit

RADIO LINK RECONFIGURATIONCANCELRadio Link Reconfiguration Cancel

OR

D-RNC S-RNCNode B

figure 10 Radio link reconfi guration – synchronized.



2.3.4 Unsynchronized Radio Link Reconfiguration The unsynchronized radio link reconfiguration does not guarantee an exact point in time, when the reconfiguration will be executed. Thus the procedure is simpler. The serving RNC will trigger the unsynchronized reconfiguration by sending the RNSAP message RADIO LINK RECONFIGURATION REQUEST . The message is sent in the SCCP connection associated with the UE and contains all necessary parameters for the new radio links. On reception of this message the D-RNC will execute the reconfiguration of the radio links. When this is successfully done the message RADIO LINK RECONFIGURATION RESPONSE. Otherwise the message RADIO LINK RECONFIGURATION FAILURE should be sent.



10

RADIO LINK RECONFIGURATIONREQUESTRadio Link Reconfiguration Request

RADIO LINK RECONFIGURATIONRESPONSERadio Link Reconfiguration Response

D-RNC S-RNCNode B

figure 11 Radio link reconfi guration – unsynchronized.



2.3.5 Physical Channel Reconfiguration Procedure In a situation where a drift RNC is involved, the problem can arise that cells used by the UE are under the control of the D-RNC. It can happen that the drift RNC needs to reconfigure the physical channels of the cell. In this case the D-RNC has to notify the serving RNC about the need to change the physical channels. Therefore the D-RNC should send PHYSICAL CHANNEL RECONFIGURATION REQUEST to the serving RNC. At this point the D-RNC will wait for the serving RNC to respond. The serving RNC has to answer with PHYSICAL CHANNEL RECONFIGURATION COMMAND, which allows the D-RNC to change the physical channels affecting the radio link of the UE. This message will come after the UE has been informed about the change in the physical channel configuration. The PHYSICAL CHANNEL RECONFIGURATION messages are sent within the SCCP connection associated with that UE.



11

PHYSICAL CHANNEL RECONFIGURATIONREQUEST

Physical Channel Reconfiguration

PHYSICAL CHANNEL RECONFIGURATIONCOMMAND

Physical Channel Reconfiguration Complete

D-RNC S-RNC

Menu

UE

figure 12 Physical channel reconf iguration requested by D-RNC.



2.3.6 Radio Link Failure Indication When a Node B detects that one or more radio links are no longer available, it will send the NBAP message RADIO LINK FAILURE INDICATION to the corresponding controlling RNC. When the radio link belongs to a UE that is has a serving RNC that is different from the controlling RNC, the failure indication will be forwarded by the controlling RNC using the RNSAP message RADIO LINK FAILURE INDICATION .



11

RADIO LINK FAILURE INDICATIONRadio Link Failure Indication

D-RNC S-RNCNode B

figure 13 Radio link failure indication from remote Node B.



2.3.7 Dedicated Measurements The serving RNC needs to know the signal strength and quality of the UE received from every cell that has a radio link to this UE. As far as the cell is controlled by the serving RNC directly, the NBAP procedures for dedicated measurements can be used. When a UE has a radio link to a cell controlled by a drift RNC, the serving RNC has to activate and receive the measurements via the Iur interface using RNSAP procedures. The basic procedure is the same as the one in the NBAP protocol. The serving RNC has to activate the dedicated measurements in the foreign cell by sending the RNSAP message DEDICATED MEASUREMENT INITIATION REQUEST . This message will be sent in the SCCP signaling connection associated with the radio links of the UE. The message contains parameters to indicate, which measurements shall be taken and when a measurement report has to be done (periodical or on thresholds). If the D-RNC receives this message and is able to activate the measurement it should respond with DEDICATED MEASUREMENT INITIATION RESPONSE. The response message can already contain a first measurement report. The regular measurements itself are transported in a DEDICATED MEASUREMENT REPORT message. This message will contain the measurement report from the Node B. When the measurements of the radio link are no longer necessary, the serving RNC can deactivate it with DEDICATED MEASUREMENT TERMINATION REQUEST.



12

DEDICATED MEASUREMENTINITIATION REQUESTDedicated Measurement Initiation Request

DEDICATED MEASUREMENTINITIATION RESPONSEDedicated Measurement Initiation Response

DEDICATED MEASUREMENT REPORTDedicated Measurement Report

DEDICATED MEASUREMENT REPORTDedicated Measurement Report

... ...

DEDICATED MEASUREMENTTERMINATION REQUEST

Dedicated Measurement TerminationRequest

D-RNC S-RNCNode B

figure 14 Dedicated measurement control.



2.3.8 Downlink Power Control The serving RNC not only receives measurements from all associated cells, but also from the UE directly (RRC message: Measurement Report). This information is used by the serving RNC to evaluate handover conditions and to determine the power of the radio frequency signal for the downlink transmission. For cells that belong to the serving RNC the downlink power control can be done directly using NBAP messages (DL POWER CONTROL REQUEST for FDD mode or DL POWER TIMESLOT CONTROL REQUEST for TDD mode). For cells that are controlled by a D-RNC the serving RNC must use RNSAP messages. The RNSAP messages for the power control are DL POWER CONTROL REQUEST for FDD mode and DL POWER TIMESLOT CONTROL REQUEST for TDD mode. So the messages have the same name as the NBAP messages. They contain parameters for the corresponding Node B to perform the power control.



15

DL POWER CONTROL REQUESTDL Power Control Request

DL POWER TIMESLOTCONTROL REQUESTDL Power Timeslot Control Request

D-RNC S-RNCNode B

figure 15 DL power control.


Complete Signaling Sequences in UTRAN

Appendix A: Complete Signaling Sequences in UTRAN

Complete signaling message sequence charts with Iu, Iub, Iur and Uu Protocols with focus on the functional protocols RANAP, NBAP, RNSAP, RRC.

© 2002 by Alexander SeifarthIPR NOTE: All presented information is IPR owned by ETSI and its partners. Alexander Sei-farth does not claim any IPR or other right on this information.The document must not be copied or distributed in any way may it be electronically, mechanc-ially or photographically.

Alexander Seifarth is not responsible for any damage or disadvantage, etc. resulting from use of this material. This covers monetary loss as well as physical or any other damage.



1. RRC Connection Setup into state CELL_DCHA UE has entered the area of a RNC and triggers now radio contact. The reason for the radio access is a higher layer service request coming from NAS protocols (e.g. MM, GMM, SM, CC, SMS, etc.). The following actions must be done:

•1. Random access: The UE accesses the RACH and sends the message RRC Connection Request.

•2. DCH Allocation: The RNC must now decide which channel to allocate. This decision is based upon the service the UE wants to have and upon the actual congestion level. The DCH requires set up of a communication context in the Node B (Radio Link Setup) and coniguration of a AAL2 virtual channel that shall transport the established DCH. Additionally the channel between serving RNC and Node B must be synchronized (Downlink Synchronization and Uplink Synchronization).

•3. DCH Activation and RRC connection completion: When the DCH is prepared, the RNC informs the UE about the successful established RRC Connection and gives the UE all infor-mation about its new dedicated channel DCH (e.g. transport formats, physical layer parameters, RLC coniguration). Now the UE will begin to send on the DCH and synchronize itself with the Node B. When this is successfully done, the UE and Node B will send an indication about the successfully synchronized radio link (RRC Connection Setup Complete and Radio Link Restore Indication).

From the point of RRC states the UE begins the procedure in UTRA IDLE mode and leaves the procedure in CELL_DCH mode.



��

UE Node B RNCRACH:CCCH RRC Connection RequestRRC RRC

allocate RNTI,select L1 and L2

parameters

NBAP NBAPRadio Link Setup

start Rx

NBAP NBAPRadio Link Setup Response

ALCAP ALCAPEstablishment Request

ALCAP ALCAPEstablishment Confirmed

DCH-FPDCH-FP Downlink Synchronisation

DCH-FPDCH-FP Uplink Synchronisation

start Tx

FACH:CCCH RRC Connection SetupRRC RRC

NBAP NBAPRadio Link Restore Indication

DCH:DCCH RRC Connection Setup CompleteRRC RRC



2. RRC Connection Establishment to RRC state CELL_FACHIn the following sequence the UE again performs an access to get a RRC connection, but this time only a FACH is granted to the UE.

•1. Random Access:The UE access the RACH and sends RRC Connection Request. This message is received by the RNC. The RNC must again de-cide, which resources shall be granted to the UE. In the present case only the FACH/RACH will be accessible for the UE. Thus there is no need to allocate any resource on Iub or Uu.

•2. RRC connection establishment completion:The RNC indicates now the successful establishment of the RRC connection with RRC Connection Setup. In this message the UE gets the information to use the FACH/RACH as transport resources. The message itself is sent on the FACH. The UE will answer with RRC Connection Setup Complete on the RACH, this message requires a last acknowledgement on the FACH.



��

UE Node B RNC

RACH:CCCH RRC Connection RequestRRC RRC

allocate RNTI,

FACH:CCCH RRC Connection SetupRRC RRC

RACH:DCCH RRC Connection Setup CompleteRRC RRC

FACH:CCCH RLC acknowledgement for RRC Connection Setup CompleteRRC RRC



3. Radio Access Bearer Establishment from CELL_DCH with DCH Setup - synchronized The following procedure shows a radio access bearer setup triggered by the core network (MSC or SGSN). The UE is initially in RRC state CELL_DCH. This means a DCH already exists for the UE. The radio access bearer requires a DCH. The procedure will show as general case a soft handover situation, this means we will see two radio links (already existing) in two different Node B and one Node B belongs to the serving RNC and the other Node B belongs to a drift RNC.The procedure will be performed as so called synchronized radi link modiication.

•1. Radio Access Bearer RequestThe core network will send the RANAP message RAB Assignment Request to the actual serving RNC of the UE. The RNC has to analyze the quality of service parameter for the RAB. These abstract parameters have to be mapped onto physical parameters for the setup of transport bearers on Iu, Iub, Iur and Uu.

•2. Iu Bearer Setup and Radio Link PreparationThe serving RNC begins now to set up all the individual bearer services. First of all the Iu bearer must be set up when a circuit switched service (Iu-CS) is wanted, for packet oriented services this is not necessary. Second the serving RNC triggers both Node B to prepare the radio link needed for the UE (Radio Link Reconiguration Prepare). Because there is already a DCH, this one will simply be modiied to fulill the requirements of the RAB. If both Node B have prepared the radio resources, they will send a Radio Link Reconiguration Ready message to the serving RNC back. Concurrently with this the serving RNC triggers the establishment of AAL2 virtual channel resources for the radio link for Iub and Iur interfaces. These two ATM transport bearer resources require a synchronization between serving RNC and the Node B at the endpoint. This is done with the Iub/Iur frame protocols (Uplink Syn-chronization and Downlink Synchronization).

•3.Radio Bearer Setup CompletionNow that the radio link and the associated Iur/Iub transport bearer are established, it is time to change the DCH coniguration. There-fore the serving RNC sends Radio Link Reconiguration Commit to both Node B and the UE gets the Radio Bearer Setup message from it. The UE and the Node B will now apply the new transport formats and physical channel coniguration and try to decode each other. If this is successful, the UE sends Radio Bearer Setup Complete to the serving RNC. This indicates a successful radio bearer setup. Thus the serving RNC can return RAB Assignment Response back to the core network with a success indication inside.



��

UENode BDrift RNS

Node BServing RNS Drift RNC Serving RNC ��

RAB Assignment RequestRANAP

select Iu, Iub, Iur andUu bearer parameter

RANAP

ALCAP: Iu TransportBearer Setup (only Iu-CS)

Radio Link ReconfigurationPrepare RNSAPRNSAP

Radio Link Reconfiguration PrepareNBAPNBAP

Radio Link Reconfiguration PrepareNBAPNBAP

Radio Link Reconfiguration ReadyNBAPNBAP

Radio Link Reconfiguration ReadyNBAPNBAP

ALCAP: Iur TransportBearer Setup

ALCAP: IubTransportBearer Setup


DCH-FPDCH-FP

DCH-FPDCH-FP

Downlink Synchronisation


DCH-FPDCH-FP

DCH-FPDCH-FP

Uplink Synchronisation


Radio Link ReconfigurationReady RNSAPRNSAP



��

UENode BDrift RNS


Radio Link ReconfigurationCommit RNSAPRNSAP

Radio Link Reconfiguration CommitNBAPNBAP

Radio Link Reconfiguration CommitNBAPNBAP

Radio Bearer Setup RRCRRCDCH:DCCH

New Transport Formats will be applied on DCH

Radio Bearer Setup Complete RRCRRCDCH:DCCH

RAB Assignment ResponseRANAPRANAP



4. Radio Bearer Setup in state CELL_DCH with DCH required - unsynchronizedThe procedure presented before was synchronized. This means that before the radio link is really modiied, the modiication itself is prepared in both Node B. The modiication itself is done synchronized when the serving RNC sends the message Relocation Commit. The following procedure is now unsynchronized, this means, both Node B will immediately modify the radio link without waiting for each other.

•1. Radio Access Bearer RequestThe core network will send the RANAP message RAB Assignment Request to the actual serving RNC of the UE. The RNC has to analyze the quality of service parameter for the RAB. These abstract parameters have to be mapped onto physical parameters for the setup of transport bearers on Iu, Iub, Iur and Uu.

•2. Iu Bearer Setup and Radio Link PreparationThe serving RNC begins now to set up all the individual bearer services. First of all the Iu bearer must be set up when a circuit switched service (Iu-CS) is wanted, for packet oriented services this is not necessary. Now the serving RNC triggers both Node B to modify the existing radio links (Radio Link Reconiguration). Each Node B performs immediately the reconiguration and returns the message Radio Link Reconiguration Response. Concurrently with this the serving RNC triggers the establishment of AAL2 virtual channel resources for the radio link for Iub and Iur interfaces. These two ATM transport bearer resources require a synchronization between serving RNC and the Node B at the endpoint. This is done with the Iub/Iur frame protocols (Uplink Synchronization and Downlink Synchronization).

•3.Radio Bearer Setup CompletionThe serving RNC sends now the Radio Bearer Setup message to the UE. The UE and the Node B will now apply the new transport formats and physical channel coniguration and try to decode each other. If this is successful, the UE sends Radio Bearer Setup Complete to the serving RNC. This indicates a successful radio bearer setup. Thus the serving RNC can return RAB Assignment Response back to the core network with a success indication inside.



��

UENode BDrift RNS



select Iu, Iub, Iur andUu bearer parameter

RANAP


Radio Link ReconfigurationRequest RNSAPRNSAP

Radio Link Reconfiguration RequestNBAPNBAP

Radio Link Reconfiguration RequestNBAPNBAP

Radio Link Reconfiguration ResponseNBAPNBAP

Radio Link Reconfiguration ResponseNBAPNBAP




DCH-FPDCH-FP

DCH-FPDCH-FP



DCH-FPDCH-FP

DCH-FPDCH-FP



Radio Link ReconfigurationResponse RNSAPRNSAP



��

UENode BDrift RNS


Radio Bearer Setup RRCRRCDCH:DCCH

New Transport Formats will be applied on DCH





5.Radio Bearer Setup in RRC state CELL_FACH with DCH requiredIn the two radio bearer setup procedures before always a DCH already existed. Now we look to the radio bearer setup with DCH from state CELL_FACH. This means currently there is no DCH before the radio bearer setup begins.

•1. Radio Access Bearer RequestThe core network requests the radio access bearer with the message RAB Assignment Request. The message contains the abstract quality of service description of the transport resources required. The RNC maps these abstract parameters to the individual links.

•2. Bearer SetupThe RNC triggers the setup of Iu bearer resources when circuit switched resources are needed. Next the DCH must be conigured, but currently there is no radio link. Hence the serving RNC sets up a communication context with one radio link in one of its Node B. This is done with the message Radio Link Setup. The Node B acknowledges with Radio Link Setup Response. For the conigured DCH a transport resource on Iub is needed, hence the serving RNC conigures an AAL2 virtual channel for DCH transport. This Iub bearer is now synchronized between Node B and serving RNC.

•3. Radio Bearer Setup CompletionThe UE gets now the Radio Bearer Setup message in which it inds the coniguration parameters for the DCH. So the UE applies these parameters and tries to synchronize the radio link with the Node B. If this is successful, the UE shall send Radio Bearer Setup Complete and the Node B shall issue Radio Link Restore Indication to the serving RNC. This concludes the radio bearer setup, thus the serving RNC can acknowledge with RAB Assignment Response to the core network.



��

UENode BDrift RNS



select Iu, Iub andUu bearer parameter

RANAP


Radio Link Setup RequestNBAPNBAP

Radio Link Setup ResponseNBAPNBAP


DCH-FPDCH-FPDownlink Synchronisation

DCH-FPDCH-FPUplink Synchronisation

Radio Bearer Setup RRCRRCFACH:DCCH



Radio Link Restore IndicationNBAPNBAP



6. Radio Bearer Setup in RRC state CELL_FACH with FACH requiredIf a UE gets a radio access bearer without DCH, then there is no need for dynamical transport bearer setup on Uu and Iub. This is because the common transport channel resources are preconigured by the operator via O&M. So the radio bearer setup is relatively simple in this case.

•1. Radio Access Bearer RequestThe core network requests the radio access bearer with RAB Assignment Request. The serving RNC analyzes the abstract RAB description inside and derives the individual link parameters for Iu, Iub and Uu.

•2. Bearer SetupIn the present case the RAB requires no DCH and the UE will only get the FACH/RACH common transport channel resources. The RACH and FACH radio transport channels are already conigured during cell setup. The same holds for the Iub ATM transport re-sources associated with RACH and FACH. Thus the only bearer that might need dynamical coniguration can be the Iu bearer, but this is necessary for Iu-CS only. Hence the only thing to do is to tell the UE with Radio Bearer Setup to use FACH/RACH. The UE acknowledges with Radio Bearer Setup Complete. This message will be acknowledged. This concludes the RAB setup.



��

UENode BDrift RNS



select Iu, Iub andUu bearer parameter

RANAP


Radio Bearer SetupRRCRRC

FACH:DCCH

Radio Bearer Setup CompleteRRCRRC

RACH:DCCH


RLC Acknowledgement for Radio Bearer Setup CompleteRRCRRC

FACH:DCCH



7. Soft Handover - Radio Link Addition and DeletionConsider a UE that has multiple radio links with Node B directly connected to the actual serving RNC. So the UE is in a soft handover situ-ation. The present case describes the procedure when one radio link between UE and a Node B connected to the serving RNC is deleted and in the same procedure a new radio link between the UE and a Node B connected to a drift RNC is added.

•1. Preparation of new radio linkFirst of all the serving RNC must prepare the new radio link that shall be added. Therefore a communication context within the new Node B in the drift RNS has to be created, this happens with the Radio Link Setup message. It commands the Node B to decode the UE’s uplink scrambling code and to send data to the UE with a downlink scrambling code of the Node B. When the new radio link is prepared the Node B acknowledges with Radio Link Setup Response. After this the Iur and Iub ATM transport resources must be prepared. This resource is synchronized between Node B and serving RNC. Because the UE is already sending on its scrambling code, the Node B can already detect the UE’s signal, hence it will send Radio Link Restore Indication to the serving RNC.

•2. Active Set UpdateNow that the new radio link is prepared and the Node B already uplink data from the UE receives, the serving RNC must tell the UE also to decode the new downlink scrambling code of the new Node B. Therefore the serving RNC sends Active Set Update to the UE which will especially contain the new downlink scrambling code to decode. In the same message the UE can be advised to no longer decode an obsolete, old downlink scrambling code. The UE acknowledges with Active Set Update Complete.

•3. Deletion of the old radio linkThe old radio link that is no longer decoded by the UE must now be released in the associated Node B. Hence the serving RNC sends a Radio Link Deletion message to it. The Node B will remove the radio link. If this was the last radio link in the communication context for the UE, the context is deleted too.



��

UENode BDrift RNS


Radio Link Setup RequestRNSAPRNSAP

Radio Link Setup RequestNBAPNBAP

decision to add anddelete a radio link

start Rx

Radio Link Setup ResponseNBAPNBAP

Radio Link Setup ResponseRNSAPRNSAP



Radio Link Restore IndicationNBAPNBAP

Radio Link Restore IndicationRNSAPRNSAP

DCH-FPDCH-FPDownlink Synchronisation


start Tx



��

UENode BDrift RNS


Radio Link Deletion RequestNBAPNBAP

Radio Link Deletion ResponseNBAPNBAP

ALCAP: IubTransportBearer Release

stop Rx and Tx

Active Set Update RRCRRCDCH:DCCH

Active Set Update Complete RRCRRCDCH:DCCH

(add radio link X, delete radio link Y)



8. Hard Handover without Serving RNC RelocationThe following use case describes a hard handover, where the UE changes Node B and both Node B belong to drift RNC and not to the serving RNC. The presented low is therefore the most general one and can easily be reduced to cases where some RNC are equal.

•1. Handover Decision and PreparationThe serving RNC decide upon the handover based on the radio measurements made by UE and Node B. Before the handover can be started, the new radio link resources in the new (target) Node B must be prepared. Hence the serrving RNC triggers the setup of a communication context together with a radio link (Radio Link Setup Request). When the radio resources in the target Node B are prepared and the associated Iub ATM transport bearer resources between target Node B and target RNC is prepared, the serv-ing RNC will be informed about it (Radio Link Setup Response). The serving RNC can now trigger the establishment of an Iur ATM transport bearer. The Iub/Iur ATM transport bearer will be synchronized between target Node B and serving RNC.

•2. Handover ExecutionThe UE begins handover execution when the serving RNC sends a reconiguration message to it (Physical Channel Reconigura-tion). The UE immediately begins to modify its radio links. Hence the old (source) Node B loses the radio contact and therefore makes a Radio Link Failure Indication. In contrast to that the target Node B will now receive the signal of the UE and hence sends a Radio Link Restore Indication. In the same way the UE indicates the successful reception of the target RNC radio signal with a reconiguration completion indication (Physical Channel Reconiguration Complete).

•3. Garbage CollectionIt remains to remove the radio and Iub/Iur resources of the old radio link. Therefore the serving RNC sends a Radio Link Deletion message to the source Node B. This message will delete the radio link and when it was the last radio link, the communication context in the source Node B will be deleted too. Last the Iub/Iur ATM transport resources to and from the source Node B can be cleared.



��

UENode B

Target RNSNode B

Source RNS Target RNC Source RNC Serving RNC

NBAP

ALCAP: IubTransportBearer Establishment

HandoverDecision

RRC

DCH-FP

RNSAP

Physical Channel Reconfiguration

Radio Link Setup RequestRNSAP

Radio Link Setup RequestNBAP

start Rx

NBAPRadio Link Setup Response

NBAP

RNSAPRadio Link Setup Response

RNSAP

RRCDCH:DCCH

DCH-FPDownlink Synchronisation


NBAPRadio Link Failure Indication

NBAP

RNSAPRNSAPRadio Link Failure Indication

ALCAP: IurTransportBearer Establishment



��

UENode B

Target RNSNode B

Source RNS Target RNC Source RNC Serving RNC

NBAP


RRC

ALCAP: Iur TransportBearer Release

RNSAP

Physical Channel Reconfiguration Complete

Radio Link Deletion RequestRNSAP

Radio Link Deletion RequestNBAP

NBAPRadio Link Deletion Response

NBAP

RRCDCH:DCCH

NBAPRadio Link Restore Indication

NBAP

RNSAPRNSAPRadio Link Restore Indication

RNSAPRadio Link Deletion Response

RNSAP



9. Hard Handover with Serving RNC RelocationThe following scenario shows a hard handover associated with a relocation of the serving RNC. The serving RNC at the begin of the pro-cedure is labelled as source RNC, whereas the RNC that shall be the serving RNC at the end of the procedure is called target RNC. The procedure is presented for the case that there is a signaling connection towards SGSN and MSC. A change of MSC (inter-MSC handover) or a change of SGSN is not considered here.

•1. Relocation Indication and PreparationThe decision to perform a relocation together with hard handover comes exclusively fromt the actual serving (source) RNC. The Relocation Required message indicates the relocation to the core network. MSC and SGSN shall prepare the relocation and inform the target RNC with Relocation Request. This triggers the target RNC to prepare the radio access bearer resources for the UE. In detail this means for the target RNC to set up an Iu ATM transport bearer towards MSC, to allocate the radio link for the UE in the new Node B (Radio Link Setup) and with this the associated Iub ATM transport bearer for the DCH is needed. The Iub transport bearer must be synchronized. When all is done, the target RNC sends an acknowledgement (Relocation Request Acknowledge) back to each core network domain.

•2. Relocation ExecutionTo start relocation both CN domains must send Relocation Command to the source RNC. When this happened, the UE will get the a message that indicates the new radio resources for it (Physical Channel Reconiguration). So the UE now tunes to the new radio link in the target Node B. Therefore the target Node B will send the Radio Link Restore Indication to target RNC, which will forward this indication as Relocation Detect. In the same way the source Node B will loose the radio link and sends Radio Link Failure Indication to the source RNC. When the UE concludes the radio link change, it will send Physical Channel Reconiguration Complete on the new resource to the target RNC. This triggers the Relocation Complete message to both CN domains.

•3. Garbage CollectionThe resources in the source RNC and source Node B are no longer needed. Thus the core network will delete all resources with Iu Release Command.



��

UENode B

Target RNSNode B

Source RNS Target RNC Source RNC ��

NBAP

DCH-FP

Radio Link Setup RequestNBAP

DCH-FPDownlink Synchronisation

ALCAP: Iu TransportBearer Establishment for Iu-CS

RANAPRANAPRelocation Required

RANAP RANAPRelocation Required

RANAPRANAPRelocation Request

RANAPRANAPRelocation Request

NBAPRadio Link Setup Response

NBAP

ALCAP: Iub TransportBearer Establishment


RANAPRANAPRelocation Request Acknowledge

RANAPRANAPRelocation Request Acknowledge



��

UENode B

Target RNSNode B


RANAPRANAPReloocation Command

RANAP RANAPRelocation Commnand

NBAPRadio Link Restore Indication

NBAP

RANAPRANAPRelocation Detect

RANAPRANAPRelocation Detect

RRCRRCPhysical Channel Reconfiguration

NBAPRadio Link Failure Indication

NBAP

RRCRRCPhysical Channel Reconfiguration Complete

RANAPRANAPRelocation Complete

RANAPRANAPRelocation Complete



��

UENode B

Target RNSNode B


NBAPRadio Link Deletion

NBAP

RANAPRANAPIu Release Command

RANAP RANAPIu Release Command


NBAP

ALCAP: IuTransportBearer Release


RANAPRANAPIu Release Complete

RANAP RANAPIu Release Complete



10. Switch from CELL_DCH to CELL_FACH with Drift RNCBased on the trafic measurements for a radio bearer the serving RNC must decide whether the UE shall be kept in state CELL_DCH utilizing a dedicated channel DCH or the UE must be sent to state CELL_FACH without a dedicated resource. In the present procedure the UE is currently located in a cell belonging to a drift RNC. At the start of the procedure the UE has one radio link in this cell.

•1 Preparation of new resourcesWhen the serving RNC decides to switch the UE’s state to CELL_FACH because there trafic is low, it is necessary to prepare the FACH and RACH transport resources. Because the UE is actually located in a cell of a drift RNC, this requires the set up of ATM transport resources for RACH and FACH and the remote allocation of bandwidth on these common transport channels. The latter is achieved with the RNSAP messages Common Transport Channel Resource Request. The ATM resources are then established.

•2 Radio Bearer modiicationTo activate the switching to CELL_FACH the UE must be informed about the change with respect to the transport channel modiica-tion. Hence the serving RNC sends the RRC message Transport Channel Reconiguration via the still existing DCH to the UE. The UE must now modify its radio coniguration and when done conirm with Transport Channel Reconiguration Complete.

•3 Release of old resourcesNow the resources associated with the obsolete DCH can be released.



��

UENode BDrift RNS


NBAP


decision to switchfrom CELL_DCH to

CELL_FACH

RRC

ALCAP: IurTransport BearerConfiguration if needed

RNSAP

Transport Channel Reconfiguration

Common TransportChannel Resource Request

RNSAP

RNSAP

Common TransportChannel Resource Response

RNSAP

RRC

RRCTransport Channel Reconfiguration Complete

RRC

DCCH:DCH

DCCH:RACH

RNSAPRadio Link Deletion Request

RNSAP

NBAPRadio Link Deletion Request

NBAP

RNSAPRadio Link Deletion Response

RNSAP


ALCAP: IurTransportBearer Release



11. Cell Update without Serving RNC RelocationWhen the UE is in state CELL_FACH, it will perform cell reselection and with this must perform cell updates to keep the serving RNC in-formed about its location. In this situation it can happen, that the UE enters a cell not belonging to the serving RNC area. Thus the servin g RNC must forward the cell update message to the serving RNC. In detail the procedure looks the following way:

•1 Cell UpdateThe UE sends the RRC message Cell Update on RACH to the reselected cell. This message is received by the controlling RNC of the cell which is not the serving RNC of the UE. Inside the message the UE indicates its U-RNTI composed of S-RNC-ID and S-RNTI. From this the controlling RNC will know, that it is not the serving one for the UE. Hence the controlling RNC will forward the cell update message inside of a RNSAP message to the corresponding S-RNC.

•2 Common Transport Channel Resource PreparationThe serving RNC has to decide to perform a relocation or not. In the present case there will be no relocation. Therefore the S-RNC triggers the foreign RNC to allocate resources for FACH/RACH. This is done with the RNSAP operation Common Transport Channel Resource Request. Possibly this can mean, that ATM transport resources on Iur have to be set up.

•3 Procedure CompletionThe serving RNC can now indicate the successful cell update with RRC message Cell Update Complete. In this message the UE can be told to reconigure its radio resources (transport channel, physical channel, radio bearer). In the present case there is no recon-iiguration, which triggers the UE to complete the procedure with RRC message UTRAN Mobility Information Conirm. It remains to release the common transport channel resources in the old radio subsystem, hence the S-RNC sends the RNSAP message Com-mon Transport Channel Resource Release.



��

UENode B

Target Drift RNSNode B

Source Drift RNS Target Drift RNC Source Drift RNC Serving RNC

ALCAP: IurTransportBearer Configuration if needed

Decision NOTto make relocation

RRC

RNSAP

Cell UpdateRRC

CCCH:RACH

RNSAPUplink Signaling Transfer

(RRC Message: Cell Update)

RNSAPRNSAPCommon Transport Channel Resource Request

RNSAPRNSAPCommon Transport Channel Resource Response

RRC RRCCell Update Complete

RRC RRCUTRAN Mobility Information Confirm

RNSAPRNSAP

Common Transport ChannelResource Release

UTRAN and UMTS Signalling Protocols

Documents

Transcript of UTRAN and UMTS Signalling Protocols