Umts Call Flows

Module 01
UE-UTRAN Signalling Protocols
Version 0.0.1 (07/02/2005)

Author: Alexander Seifarth (a.seifarth@techcom.de)
1 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

1. Network Architecture

1.1. Top Level Network Architecture

UTRAN
UTRAN
Uu Iu CN
CN
(UMTS
(UMTSTerrestrial
Terrestrial
Radio
RadioAccess
Access (Core
(CoreNetwork)
Network)
Network)
Network)
UE
Non Access Protocols
Access Protocols Access Protocols intra-CN

protocols
intra-UTRAN
protocols

UMTS inherits its top level network architecture from second generation mobile communication networks. Any UMTS
network can be divided into three major network subsystems:
• UE (User Equipment): The UE is built from Mobile Equipment (ME) providing all required hard- and software to gain
access to the network and a UMTS Subscriber Identity Module (USIM). In other words the UE is a 3G enabled cell
phone.
• UTRAN (UMTS Terrestrial Radio Access Network): The major change of UMTS compared to second generation
systems like GSM is the radio access technology. Instead of the classical GSM BSS (Base Station Subsystem) using
TDMA/FDMA radio access there is now UTRAN utilizing CDMA (Code Division Multiple Access). UTRAN currently comes in
three different flavours – FDD mode, TDD mode and low chip rate TDD mode. (This script focuses on FDD mode).
• CN (Core Network): The core network is the same for GSM and UMTS. It is responsible to provide telecommunication
services like mobility handling, circuit switched call services, packet switched data services and messaging service. The CN
can be split into domains – the CS domain and the packet switched domain.
Several signalling protocols provide the communication facilities between these subsystems. To establish the basic
communication links (access links) between UE-UTRAN and UTRAN-CN there are access signalling protocols between
these subsystems. On the other hand for telecom services there are protocols between UE and CN for mobility
management, CS call management, PDP context management, SMS, etc. These protocols belong to the so called non-
access signalling protocols. These non-access protocols are exchanged between UE and CN directly. UTRAN must
transparently pass signalling messages from non-access signalling protocols from UE to CN and vice versa.
Obviously there are also protocols inside UTRAN and inside CN. These are labelled intra-UTRAN or intra-CN protocols
respectively.

1.2. Network Elements and Interfaces

MSC/VLR
Node B RNC Iu-CS Server#1
Iub
CS
MGW #1
Iub ...
Node B
Uu
Iur MSC/VLR
Server#N
UE
RNS
CS
MGW #K
Node B RNC
Iub
CS-CN
Iu-PS SGSN #1
RNS
BTS A ...
BSC
Iu-PS SGSN #L
BSS Gb PS-CN
UTRAN is composed of two different network elements:
• RNC (Radio Network Controller): The RNC is responsible for all radio management tasks inside of UTRAN. This
includes channel allocation/modification/removal, handover procedures, security functions, etc.
• Node B: The Node B serves one or more cells. The tasks of the Node B is to terminated the physical layer (WCDMA FDD)
and convert it to the transport protocol on the Iub interface towards RNC. In other words the Node B is a relay point.
Anything above the radio physical layer must pass transparently through the Node B.
Between RNC and Node B there is the Iub interface. Its task is to transfer data (user data, signalling) between UE and
RNC. Furthermore there is an optional interface Iur between two RNC. The Iur interface is related to soft handover
procedures. This interface is similar to the Iub interface used for transparent transfer of data between UE and the so called
serving RNC.
For the connection between UTRAN and CN there is the Iu interface defined. It comes in two different versions – Iu-CS for
the connectivity between RNC and MSC (MSC server, CS Media Gateway MGW) and Iu-PS for RNC-SGSN communication.
The Iu interfaces shall transfer user data (CS speech calls, CS data calls, PDP context data), non-access signalling to and
from the UE and access signalling between RNC and MSC/SGSN.
Iu, Iub and Iur interfaces are currently based on ATM as transport layer technology, but also IP may be used. The IP based
UTRAN is already specified.
In parallel to UTRAN the classical GSM BSS may still be used together with UTRAN. Thus the core network still provides
connectivity for A and Gb interface. Note that in future releases also the GSM BSS may be based on Iu interfaces rather
than the old second generation protocols.

MSC CS-MGW
Server SGSN
Iu-CS Iu-PS
Serving Drift
Serving RNC RNC RNC Drift RNC
Iur
• radio management • relay between Iur
(handover decision, and Iub
channel de/allocation • splitting/combining
• NAS message relay Iub Iub Iub function [optional]
• Iu management Node B Node B Node B • local admission
• backward error control
correction
• splitting/combination
function
• local and global
admission control
UE

A UE can be in one of two states:
• IDLE: A UE in IDLE mode has no connectivity to UTRAN, in other words there is no signalling relation with an RNC and of
course no radio resources are allocated for the UE.
• CONNECTED: A CONNECTED mode UE has a signalling relation with an RNC which performs all radio management tasks
for this UE. This special RNC is called the serving RNC (S-RNC) for the UE. A single UE has in CONNECTED mode exactly
one serving RNC, in IDLE mode there is no serving RNC for the UE.
During soft handover procedures it can happen, that a UE is connected with a cell that does not belong to the serving
RNC’s area. The RNC managing this cell is called a drift RNC (D-RNC). A D-RNC must have an Iur interface to the serving
RNC of the UE.
The drift RNC must not perform radio management procedures for the UE, this is task of the serving RNC. The drift RNC
provides functionality to relay data between serving RNC and UE. In other words the drift RNC is a Iub/Iur relay. In some
RNC equipment also functionality to combine and split data streams to/from a UE during soft handover can be provided.

1.3. UTRAN/UE Main Functional Protocols Overview

1.3. UTRAN/UE Main Functional Protocols
MSC/VLR
Server
Node B RANAP
RANAP Iu-CS
WCDMA
WCDMA NBAP
NBAP ALCAP
ALCAP
UE Uu Iub RNC
ALCAP
ALCAP CS-MGW
Iu-CS
Uu RRC
RRC Iub
Iur
ALCAP RNSAP
ALCAP RNSAP
SGSN
RNC RANAP
RANAP Iu-PS

There are some main functional protocols within UTRAN that implement the UMTS specific operations. These protocols are:
• RRC (Radio Resource Control): The RRC protocol is exchanged between UE and serving RNC. It provides functions
for radio channel management, handover, security functions, measurements, etc.
• RANAP (Radio Access Network Application Part): RANAP is the main protocol on the Iu interfaces. MSC server and
SGSN use RANAP signalling messages to allocated radio access bearers and to handle relocation of the serving RNC.
• NBAP (Node B Application Part): NBAP is the control protocol on the Iub interface. It allows the RNC to command the
Node B to allocate or delete channels on the air interface, to transport Node B measurements to the RNC. Although there is
a detailed specification of NBAP, most of all available UTRAN equipment implements a propriety version of NBAP.
• RNSAP (Radio Access Network Application Part): RNSAP is used on Iur interface, thus it is an open protocol. The
RNSAP protocol extends the NBAP protocol, so that a serving RNC can allocate radio resources on cells owned by a drift
RNC. Some other functions of RNSAP concern the relocation of the serving RNC function and packet data forwarding from
old to new RNC over Iur.
The mentioned protocols RRC, NBAP, RANAP, RNSAP are UTRAN specific protocols. On Iub, Iur and Iu-CS interfaces real-
time data streams will be transported. Thus before such a real-time data stream can be transferred, an appropriate
transmission bearer must be allocated on the transport network, this requires another protocol:
• ALCAP (Access Link Control Application Part): The term ALCAP is a generic “placeholder” for a transport network
specific control protocol to allocate transport bearers for delay sensitive data. In case of ATM-AAL2 transport network the
ACLAP is the ITU-T protocol Q.2630 (AAL type 2 signalling protocol). If IP/UDP is used instead, the ALCAP is not defined,
because in IP/UDP there is no resource allocation defined.

NAS Signalling Relay MSC/VLR
Server
MM
MM CC
CC SS
SS SMS
SMS
RNC
UE
CS CS-MGW
CSdata
data
RNS
SGSN
GMM
GMM SM
SM SMS
SMS PS
PSdata
data

The non-access signalling protocols between UE and MSC server/SGSN are the direct transfer application part (DTAP)
protocols known from GSM/GPRS.
For the CS services there are:
• MM (Mobility Management): This protocols provides location area update, authentication, IMSI detach procedures
and some others (e.g. identity request, MM information).
• CC (Call Control): Here we find mobile originated and mobile terminated call setup, local and remote call release, as
well as call related supplementary services, mid-call modification and DTMF interaction.
• SS (Supplementary Services): This protocol allows to trigger non-call related supplementary services like USSD,
management of call forwarding and call barring, etc.
For PS core network the following protocols are used:
• GMM (GPRS Mobility Management): This protocol defines GPRS attach, GPRS detach, routing area update,
authentication, service request and some other procedures (e.g. identity request, GMM information).
• SM (Session Management): The SM protocol provides the functionality for PDP context activation, PDP context
deactivation and PDP context modification.
For PS and CS core network domain the short messaging service is possible. The protocols for SMS are identical for both
domains:
• SMS (Short Message Service): The SMS protocol suite consists of SM-CP (Short Message Control Protocol), SM-RP
(Short Message Relay Protocol), SM-TL (Short Message Transfer Layer) and SM-AL (Short Message Application Layer).

1.4. UTRAN Protocol Stacks on Iux Interfaces

1.4. Protocol Stacks on Iux Interfaces – Iu-CS
Serving Iu-CS (control plane) MSC/VLR Server
RNC CS-MGW
Iu-CS (user + transport network control plane)
Control Plane Transport User Plane

Network
MM
MM CC
CC SS
SS SMS
SMS Control CS call data
Plane Iu Iu Iu Iu
Iu . . . Iu Iu . . . Iu
RANAP
RANAP UP UP UP UP
UP UP UP UP
SCCP
SCCP ALCAP
ALCAP
MTP3B
MTP3B
SAAL
SAAL SAAL
SAAL ... SAAL
SAAL AAL2
AAL2 ... AAL2
AAL2
PVC PVC PVC PVC PVC
ATM
ATM
1.4. Protocol Stacks on Iux Interfaces – Iu-CS
On the Iu-CS interface the main functionality is to transfer CS call (speech, video, data) between RNC and CS media
gateway (CS-MGW). CS user data is carried over the Iu UP (Iu User Plane) protocol from RNC to CS-MGW and vice
versa. The Iu UP protocol supports codecs with multiple data rate modes like the AMR codec. Each application has its own
Iu UP instance which is carried as AAL2 call inside a AAL2 virtual channel.
To allocate AAL2 calls inside a AAL2 virtual channel the establishment procedure of the ALCAP protocol (Q.2630) must be
used. In the same way when the application terminates, the associated AAL2 call must be released by ALCAP’s release
procedure. Thus the ALCAP protocol is required between RNC and CS-MGW.
The UMTS specific higher layer control of radio access bearers the AAL2 call belongs to the RANAP protocol is used.
RANAP uses the SCCP (Signalling Connection Control Part) for virtual signalling connection between RNC and MSC
server to identify a single UE.
For signalling message transfer MTP3B (Message Transfer Part level 3 Broadband) is used. This is commonly known
as broadband or high speed SS7. MTP3B provides routing facilities between RNC, MSC server and CS-MGW. The
transmission is done on one or more high speed SS7 signalling links. Such high speed links are provided via SAAL
(Signalling ATM Adaptation Layer) protocol instances. Each SAAL represents one ATM virtual channels together with
retransmission functionality to increase transmission reliability.
The non-access signalling protocol for the circuit switched side (MM, CC, SS, SMS) are carried over RANAP.

1.4. Protocol Stacks on Iux Interfaces – Iu-PS
Serving Iu-PS (control plane, user plane) SGSN
RNC
Control Plane User Plane
GMM
GMM SM
SM SMS
SMS PS call data (PDP Contexts)
...
RANAP
RANAP GTP-U
GTP-U
SCCP
SCCP UDP
UDP
MTP3B
MTP3B IP
IP
SAAL
SAAL SAAL
SAAL ... SAAL
SAAL AAL5
AAL5 ... AAL5
AAL5
PVC PVC PVC PVC PVC
ATM
ATM

1.4. Protocol Stacks on Iux Interfaces – Iu-PS
On Iu-PS user data consists of PDP context packets. PDP context data is transferred over the GTP-U (GPRS Tunnelling
Protocol – User plane). GTP-U provides so called GTP-U tunnels which are used to identify subscriber and PDP context
and to route PDP context data correspondingly. The GTP-U protocol uses IP/UDP as transport layer. The IP layer routes
between RNC and SGSN. In an ATM environment IP is transmitted over one or more AAL5 virtual channels.
The control stack is similar to Iu-CS. The RANAP protocol is used between SGSN and RNC to allocate radio access bearer
services for PDP contexts. There is no ALCAP on Iu-PS because AAL2 is not used here.
Obviously the non-access signalling protocols on Iu-PS are different to Iu-CS. Between RNC and SGSN we can find GMM,
SM and SMS on RANAP.

1.4. Protocol Stacks on Iux Interfaces – Iub
UE Uu Node B Iub RNC
Control Plane Transport Network User Plane

Control Plane
Transport Channel Data
TrCH
TrCH TrCH
TrCH TrCH
TrCH
NBAP
NBAP FP
FP ... FP
FP ... FP
FP
ALCAP
ALCAP ... ALCAP
ALCAP
SAAL
SAAL SAAL
SAAL SAAL
SAAL SAAL
SAAL AAL2
AAL2 AAL2
AAL2
... ... ...
PVC PVC PVC PVC PVC PVC
ATM
ATM

1.4. Protocol Stacks on Iux Interfaces – Iub
On the Iub interface data (user data and signalling) to and from the UE must be transported transparently. This UE-RNC is
data is transferred in form of so called transport channels TrCH. Each transport channel is carried over Iub in a Frame
Protocol (FP). Each such frame protocol FP uses a single AAL2 call inside a AAL2 virtual channel as transport resource.
To allocate a AAL2 call for a frame protocol instance, again the ALCAP protocol is required. The ALCAP is carried over a
single SAAL ATM virtual channel. Dependent on the RNC/Node B vendor also one or several ALCAP instances might be
used on Iub.
The main protocol on Iub, the NBAP protocol, may also be split into several parts. Again this depends on the equipment
vendor. Thus one or more SAAL ATM virtual channels are required to transfer NBAP messages over the Iub interface.

1.4. Protocol Stacks on Iux Interfaces – Iur
UE Uu Node B Iub Drift RNC Iur Serving RNC
Control Plane Transport User Plane

Network
Transport Channel Data
Control Plane
RNSAP
RNSAP TrCH
TrCH TrCH
TrCH TrCH
TrCH
FP
FP ... FP
FP ... FP
FP
SCCP
SCCP ALCAP
ALCAP
MTP3B
MTP3B
SAAL SAAL
SAAL SAAL SAAL
SAAL AAL2
AAL2 AAL2
AAL2
... ...
PVC PVC PVC PVC PVC
ATM
ATM

1.4. Protocol Stacks on Iux Interfaces – Iur
The Iur interface is comparable to Iub with two differences. First instead of NBAP the RNSAP protocol is used. The second
difference is that RNSAP and ALCAP use broadband SS7 for transfer and routing of signalling messages between serving
RNC and drift RNC.

2. Radio Protocol Architecture and
Channels

Channels
2.1. Radio Protocol Architecture

NAS Protocols CS
CS PS
PS CB
CB
MM App PDP
PDPCtx. SMS
MM GMM
GMM SM
SM CC
CC SS
SS SMS
SMS App Ctx. SMS
... App
App
RAB RAB
RRC
RRC
... Radio Bearer (RB)
#1 #x #y1 #y2 #y #z
... PDCP
PDCP BMC
BMC
RLC
RLC ... RLC
RLC RLC
RLC RLC
RLC RLC ... RLC
RLC RLC
Logical Channels (LogCH)

#1 #x #y1 #y2 #y #z
Medium
MediumAccess
AccessControl
Control(MAC)
(MAC)
Transport Channels (TrCH)
#1 #2 #n
WCDMA
WCDMAPhysical
PhysicalLayer
Layer(FDD)
(FDD)
#1 #k
Physical Channels (PhCH)
RF
The UMTS radio protocol architecture as it is implemented in the UE has the following protocols:
• WCDMA Physical Layer: The physical layer offers bit transport services in form of so called transport channel TrCH.
To transmit TrCH data over the air the physical layer has access to physical channels PhCH. A PhCH represents the
physical resource and is identified by frequency, scrambling code and channelization code (plus some additional parameters
for certain channels).
• Medium Access Control (MAC): MAC protocol has the task to include or check UE identifiers on transport channels
that are shared between several UE (common transport channels). The transport services are offered to higher layers in
form of logical channels LogCH. Thus the MAC also has to multiplex and demultiplex logical channels onto or from
transport channels.
• Radio Link Control (RLC): To each logical channel there is one RLC instance. The RLC belongs to a single radio
bearer (RB) which represents the transmission resource for a layer 3 application (codec, RRC protocol, PDP context). The
RLC protocol offers reliability in form of sequence numbering and backward error correction. Typically one RLC belongs to
one logical channel, but for acknowledged mode one RLC instance can also utilize two logical channels.
• Packet Data Convergence Protocol (PDPC): This protocol is applicable for radio bearers belonging to PDP contexts
only. The protocol performs IP header compression and optionally also IP datagram numbering.
• Broadcast Multicast Control (BMC): This protocol exists only for cell broadcast SMS radio bearer. This protocol
contains the scheduling messages and the basic CB SMS frames.
• Radio Resource Control (RRC): The main signalling protocol for radio resource management.
For a single application one or more radio bearers have to be allocated. For user applications all radio bearers of a single
application are combined in a radio access bearer (RAB).

Channels
2.2. Logical Channel Types and their Usage

UE Identification in UTRAN
UE Uu Node B Iub Serving
RNC
Case UE Identification in RNC

No
NoUE
UEIdentification
Identification Some information (System Information, CB SMS) does
not require a UE identification.
Layer
Layer11Identification
Identification UE must have a dedicated physical resource. This
resource uniquely identifies the UE for the time the
resource is assigned to it.
Layer
Identification UE uses common resources and identifies itself with a
special MAC header identifier (c-RNTI, u-RNTI, dsch-
RNTI) on that resource.
Layer
Identification UE has no dedicated resource and no assigned MAC
header identifier, but uses common resources (RRC
signalling only). The RRC message must contain a UE
identifier as layer 3 parameter.
Logical Channel Types ptm: point-to-multipoint
ptp: point-to-point
dl: downlink
Control Channels ul: uplink
BCCH
BCCH Broadcast Control Channel System Information broadcast; downlink channel;
[dl, ptm] no UE specific information
PCCH
PCCH
Paging Control Channel Point-to-multipoint paging procedure (Paging Type 1)
[dl, ptm]
UE identification by RRC message itself
CCCH
CCCH
Common Control Channel Point-to-point RRC signalling on common resource
[ul+dl, ptp]
when no MAC identifier available
DCCH
DCCH
Dedicated Control Channel Point-to-point RRC signalling on common or dedic.
[ul+dl, ptp]
resource with MAC identifier available (on common
resource)
Traffic Channels
DTCH
DTCH
Dedicated Traffic Channel Point-to-point data (CS data, CS speech, PS data) on
[ul|dl|ul+dl, ptp]
common or dedicated resource (requires MAC-ID on
common resource).
CTCH Common Traffic Channel
CTCH [dl (currently), ptm] Used for cell broadcast SMS. Thus no UE-ID.

For FDD mode the following logical channel types are defined:
• BCCH (Broadcast Control Channel): The BCCH carries the cell’s system information, which are RRC messages
(System Information Blocks, Master Information Block). The BCCH is not associated with a radio bearer.
• PCCH (Paging Control Channel): The PCCH carries RRC messages ‘Paging Type 1’. This message type is used to page
a UE or to indicate system information changes. Like the BCCH there is no radio bearer associated with the PCCH.
• CCCH (Common Control Channel): The CCCH is a bi-directional RRC signalling channel where layer 3 identification is
required. The UE uses CCCH signalling at the beginning of communication when no DCCH is available. Only radio bearer RB
0 is attached to CCCH. RB 0 is configured via system information, because it works as a start up point.
• DCCH (Dedicated Control Channel): The normal bi-directional RRC signalling and also rate control signalling is
exchanged on a DCCH. Every DCCH is associated with its own radio bearer which must be configured via explicit RRC
signalling from RNC to UE. On DCCH only layer 1 or layer 2 identification is allowed.
• DTCH (Dedicated Traffic Channel): CS call data (speech, video, data) as well as PDP context data is carried over
DTCH. Like for DCCH also on DTCH layer 1 or layer 2 identification is required, layer 3 identification is not possible.
• CTCH (Common Traffic Channel): This channel type is currently used for cell broadcast SMS (CB SMS) only.
It should be obvious that any DTCH or CTCH requires an associated radio bearer. Such radio bearers are granted via RRC
procedure from the RNC to the UE.

Channels
2.3. Transport Channel Types and their Usage

Dedicated TrCH Node B Common TrCH
• mapped onto dedicated • mapped onto shared

physical resources physical resources
• only one UE can use the • multiple UE can be
physical resource assigned to same physical
• automatically provides resource
Layer 1 identification for • requires Layer 2
the UE assigned to the identification for DCCH,
channel WCDMA FDD cell DTCH
• used with DCCH and common • requires Layer 3
DTCH physical identification for CCCH,
PCCH [opt]
channel
dedicated
physical
channels
Common
CommonTrCH
TrCH
UE
Dedicated
DedicatedTrCH
TrCH
Dedicated
DedicatedTrCH
TrCH
Common
CommonTrCH
TrCH
Dedicated
DedicatedTrCH
TrCH
UE UE
2.3. Transport Channel Types and their Usage 1
Transport Channel Types dl: downlink
ul: uplink
Common Channels
BCH Broadcast Channel Carries BCCH.

BCH [dl, 1/cell]
PCH Paging Channel

PCH [dl, ≦16/cell] Carries PCCH.
RACH Random Access Channel Can carry CCCH, DCCH and DTCH. Minimum SF is 32
RACH [ul, ≦16/cell] and maximum transmission time is 10|20 ms.
FACH Forward Access Channel

FACH [dl, ≦16/cell] Can carry CCCH, DCCH, DTCH, BCCH and CTCH.
Minimum SF is 4.
DSCH Downlink Shared Channel

DSCH [dl, ≦?/cell] Carries DCCH and DTCH. A DSCH is always used
together with one or more DCH.
CPCH Common Packet Channel

CPCH [ul, ≦64/cell] Carries DCCH and DTCH. Minimum SF is 4 and
maximum transmission time is 80 ms.
HS-DSCH High Speed DSCH

HS-DSCH [dl, ≦16/cell]
Carries DCCH and DTCH. Can switch between QPSK
and 16QAM on physical channel.
2.3. Transport Channel Types and their Usage 2
Transport Channel Types
Dedicated Channels
DCH
DCH
Dedicated Channel One DCH can carry one or more DCCH or one DCH
[ul|dl]
can carry one or more DTCH.

A single transport channel has a certain characteristics that describes how bits are transmitted over the air interfaces. This
concerns bit rate, delay and reliability. A special characteristics is whether the associated physical channel used for
transport channel data transmission is dedicated to a single UE or must be shared between several UE. This means that we
have two groups of transport channels – dedicated TrCH and common TrCH.
Common transport channels are created during cell setup or O&M triggered cell reconfiguration. In UMTS FDD mode we
have the following common transport channels:
• BCH (Broadcast Channel): There is exactly one BCH per cell and it is used to carry BCCH. The format of a BCH is fixed
by specification so that any UE camping on a cell can read the BCH.
• PCH (Paging Channel): A PCH carries PCCH. A cell may have up to 16 PCH by specification. A UE selects a PCH
depending on subscriber identity.
• RACH (Random Access Channel): The random access channel is used to carry CCCH, DCCH, DTCH in the uplink. In
case of CCCH any UE in the cell can freely access the RACH, for DCCH/DTCH a UE has to get permission from the RNC to
do so. Especially it is so that for DCCH/DTCH on RACH the UE needs a temporary identifier (C-RNTI) for layer 2
identification.
• FACH (Forward Access Channel): The FACH is the downlink response channel to the RACH. It is used to carry CCCH,
DCCH, DTCH, CTCH and BCCH. For DCCH/DTCH on FACH the already mentioned C-RNTI is required. Note that there is no
fixed timing relationship between transmission on RACH and reception on FACH. Rather a UE that uses RACH/FACH the
FACH must be monitored permanently.
• CPCH (Common Packet Channel): The CPCH is working like the RACH, but is used for DCCH and DTCH only.
Compared to the RACH the CPCH allows higher bit rates and longer transmission periods – thus a higher throughput can be
achieved on CPCH.

• DSCH (Downlink Shared Channel): The downlink shared channel shall be used for packet data in the downlink. The
channel allows multiplexing of DCCH/DTCH of several UE using time and code multiplexing mechanisms. This shall increase
resource usage efficiency.
• HS-DSCH (High Speed Downlink Shared Channel): This channel is one of the new features in UMTS Release 5. The
HS-DSCH has the same function like the normal DSCH. DCCH/DTCH of several UE shall be multiplexed – again time and
code multiplexing is used. The special thing is, that the physical resource allocation and the multiplexing is handled at the
Node B, not at the RNC. Furthermore the associated physical channel allows switch between QPSK and 16QAM.
In contrast to this the dedicated transport channels which are assigned to a single UE will be created and deleted during
normal operation using NBAP/RNSAP- and RRC-procedures. There is only one dedicated transport channel type defined:
• DCH (Dedicated Channel): The dedicated channel carries either several (or one) DCCH or several (or one) DTCH.
Obviously several logical channels on a DCH belong to the same UE. Thus the DCH is the only case where layer 1
identification is in use. A UE can have several DCH simultaneously. A single DCH is either uplink or downlink.

Channels
2.4. Physical Channels and their Usage

2.4. Physical Channels and their Usage 1
Physical Channel Types dl: downlink
ul: uplink
Synchronisation Channels
P-SCH Primary Synchr. Channel Transmits Primary Synchr. Code (PSC) to detect cell.
P-SCH [dl, 1/cell]
S-SCH Secondary Synchr. Channel Transmits a Secondary Synchr. Code sequence to

S-SCH [dl, 1/cell] identify scrambling code group and radio frame start.
Measurement Reference Channels
P-CPICH Primary Common Pilot CH

P-CPICH [dl, 1/cell] Transmits a pre-defined symbol sequence (all –1)
with the primary dl scrambling code of the cell.
S-CPICH Secondary CPICH

S-CPICH [dl, 0...15/cell] Transmits a pre-defined symbol sequence with one
the 15 possible secondary scrambling codes of cell.
System Information Broadcast
P-CCPCH Primary Common Control

P-CCPCH Physical Channel
Carries BCH with BCCH. Always scrambled by primary
[dl, 1/cell] dl scrambling code of the cell.
ul: uplink
PhCH for FACH and PCH
S-CCPCH Secondary Common Carries either 1) FACH only, 2) PCH only or 3) FACH
S-CCPCH Control Physical Channel + PCH multiplexed.
[dl, ≦ 16/cell]
Paging Indicator Channel Contains paging indicators for discontinuous
PICH
PICH reception (DRX) in association with a PCH.
[dl, ≦ 16/cell]
PhCH for RACH
PRACH Physical Random Access

PRACH Channel Consists of a preamble part to perform open loop
[ul, ≦ 16/cell] power control and a data part transferring RACH data.
AICH Acquisition Indicator

AICH Channel Associated with a single PRACH. Carries the preamble
[dl, ≦ 16/cell] responses (acquisition indications).

ul: uplink
PhCH for DCH
DPCH Dedicated Physical Channel Carries one or several DCH of a single UE and
DPCH [dl, dynamical allocation] physical layer information (TPC, pilot bits, TFCI).
Data rate ≦1860 kpbs (SF=4). [Physical channel bit rate]
DPCCH Dedicated Physical Ctrl CH Carries physical layer information from a single UE to
DPCCH [ul, dynamical allocation]
Node B (TPC, pilot bits, TFCI, FBI). SF=256 fix.
[ 1/UE]
DPDCH Dedicated Physical Data CH Carries one or several DCH of a single UE to Node B.
DPDCH [ul, dynamical allocation]
Data rate ≦ 960 kpbs (SF=4). [Physical channel bit rate]
[≦6/UE]
PhCH for DSCH

Physical Downlink Shared
PDSCH Carries a DSCH with DCCH/DTCH of several UE
PDSCH Channel
multiplexed by time and channelization codes.
[dl, dynamical allocation
of codes] Data rate ≦ 1920 kbps (SF=4).[Physical channel bit rate]
DPCH Dedicated Physical Channel A PSDCH must be used by together with DPCH by a
DPCH [dl, dynamical allocation]
UE. The DPCH contains physical layer control bits.

ul: uplink
PhCH for CPCH
PCPCH Physical Common Packet Carries CPCH with DCCH/DTCH of several UE

PCPCH Channel multiplexed by time (asynchronous) and CPCH access
[ul]
preambles, collision detection preambles and power
control preambles.
Data rate ≦960 kpbs (SF=4) for max. 80 ms.
AP-AICH Access Preamble Gives positive or negative acquisition indications to

AP-AICH Acquisition Indicator CH
CPCH access preambles for CPCH access preambles.
[dl]
CD/CA-ICH Collision Detection/ Gives collision indications or channel assignment

CD/CA-ICH Channel Assignment
indications (code alloc.) for CPCH collision preambles.
Indicator Channel
[dl]
CSICH CPCH Status Indicator CH Gives status indications about availability/non-

CSICH availability of CPCH resources.
[dl]
DPCH Dedicated Physical CH Carries physical layer control bits (TPC) used for
DPCH closed loop power control of PCPCH.
[dl]

ul: uplink
PhCH for HS-DSCH
HS-PDSCH High Speed Physical Carries a HS-DSCH with DCCH/DTCH of several UE.
HS-PDSCH Downlink Shared Channel Fixed spreading factor 16. Up to 15 HS-PDSCH may
[dl, ≦ 15/cell]
be used in parallel. Can switch between QPSK and
16QAM.
Single HS-PDSCHData rate =960 kpbs (16QAM) and
=480 kbps (QPSK).
HS-SCCH HS-DSCH related On this channel the physical layer assigns a UE the
HS-SCCH Shared Control Channel
HS-PDSCH for the next transmission period.
[dl, ≦4 per HS-DSCH]
HS-DPCCH Dedicated Physical CH Transmits quality indicator (C/I) and

HS-DPCCH [ul, 1 per UE on HS-DSCH] acknowledgements for received data on HS-PDSCH
from UE to Node B.

Channels
2.5. Radio Bearers (RB) and Radio Access Bearers (RAB)

2.5. RB and RAB - Architecture
UE Serving
MSC
RNC
Server
RB 1 CS-MGW
R R
RB 2
R RB 3
R
C RB 4 C
Rate AMR
RB 5 control RAB (CS) A B C
A
M A RB 6 RAB subflow 1
B RB 7 Iu UP RAB subflow 2 Iu UP
R C RB 8 RAB subflow 3
PDP
RAB (PS)
PDP
Ctx. RB 9
Context 1
1
PDP
PDP
Ctx.
Context 2
2
RAB (PS)
SGSN

2.5. RB and RAB - Architecture
Transmission resources for telecommunication services in UMTS are handled on several levels – each network subsystem is
responsible for its own resources. This allows to handle transmission resources on different time scales.
As shown in the section about the radio protocol architecture within UTRAN each application uses one or more so called
Radio Bearers (RB). Radio bearers are used for signalling (RRC protocol messages, rate control signalling) as well as for
user data applications (CS calls, PDP contexts). But user data applications have to be terminated by the core network.
Thus for each active application the core network establishes one so called Radio Access Bearer (RAB). A RAB can be
considered as a virtual transmission resource between UE and CN.
Depending on the application a single RAB can utilize one or more radio bearers. For PDP contexts it is even possible to
have a RAB without radio bearer. Note that a PDP context can be active with and also without radio access bearer. The
SGSN removes or reallocates the RAB by timer supervision. Whereas the radio bearers are removed and reallocated by the
RNC also by timer supervision.

2.5. RB and RAB – RRC Radio Bearer Usage
NAS Protocols
MM
MM GMM
GMM SM
SM CC
CC SS
SS SMS
SMS
high priority low priority
signalling transfer signalling transfer
RRC
RRC
RB 0 RB 1 RB 2 RB 3 RB 4
RLC RLC RLC RLC RLC
(UL:TM; DL:UM) (UL/DL:UM) (UL/DL:AM) (UL/DL:AM) (UL/DL:AM)
CCCH DCCH 1 DCCH 2 DCCH 3 DCCH 4
MAC
MAC
DL-TrCH UL-TrCH
PHY
PHY
2.5. RB and RAB – RRC Radio Bearer Usage
The RRC protocol has to use radio bearers for the transmission of its signalling messages.
The very first radio bearer RB 0 is special, because it is configured via system information (BCCH) and acts as a start up
item for signalling. RB 0 is always mapped to CCCH and is thus found on RACH and FACH.
For normal signalling (DCCH) there are RB 1, RB 2, RB 3 and RB 4. RB 1 and RB 2 are used for radio management
procedures only, whereas RB 3 and RB 4 are to be used for non-access signalling (CN procedures). The difference between
RB 1 and RB 2 is the mode of the associated RLC protocol instance. RB 1 is always running with unacknowledged mode, RB
2 always uses acknowledged mode.
RB 3 and RB 4 have to use acknowledged mode, their difference is the priority. RB 3 is for high priority CN signalling (MM,
GMM, SM, CC, SS). In contrast to that RB 4 is for low priority signalling (SMS).

Channels
2.6. Channel Configuration Scenario

UE with one variable rate AMR CS call, 1 PDP context (active data transfer)
MM,
MM,GMM,
GMM,CC,
CC,SS,
SS,SM,
SM,SMS
SMS
AMR
AMRcodec
codec PDP
PDPCtx.
Ctx.
RRC
RRC A B C frame
header
RB 1 RB 2 RB 3 RB 4 RB 5 RB 6 RB 7 RB 8 RB 9
PDCP
RLC UM AM AM AM TM TM TM TM UM|AM
DCCH 1 DCCH 2 DCCH 3 DCCH 4 DTCH 1 DTCH 2 DTCH 3 DCCH 5 DTCH 5
MAC
DCH DCH DCH DCH DCH

DCH #31 #0 #1 #2 #3 #4
PHY
DL DPCH DPCCH DPDCH UL

The scenario shown here presents the configuration of a UE in UTRA connected mode with two services running:
• one AMR speech call with variable bit rate,
• one PDP context with active data transfer.
The UE uses several radio bearers RB1, …, RB4 for RRC signalling. Obviously these radio bearers are DCCH. For the AMR
codec also four radio bearers are required. RB 5, …, RB 7 carry the encoded speech data in form of the codec’s A, B and C
bits. Every 20 ms the codec produces one set of A, B and C bits. Together with the codec frame header which are mapped
to RB 8 they form the AMR codec frame. The frame header is essential for rate control of AMR codecs. For the PDP context
there is at most one radio bearer RB 9 required. RB 5, 6, 7 and 9 are mapped to DTCH, whereas the radio bearer RB 8 for
the AMR codec frame header is DCCH.
All RRC signalling radio bearers RB 1, …, RB 4 are multiplexed onto the same DCH (UL-DCH + DL-DCH). RB 5, 6, 7 and 8
belong to the codec but require different reliability settings. Thus they are mapped each to their own DCH (UL/DL). The
same is true for the PDP context’s radio bearer RB 9, it also gets its own DCH.
On the physical layer all DCH can be multiplexed to a single DPDCH in the uplink and a DPCH in the downlink. If the data
rate exceeds the capacity of single DPDCH or DPCH, several physical channels might be used in parallel.

Module 02
Radio Layer 2 Protocols MAC, RLC,

PDCP
Version 0.0.1 (10/02/2005)


1. Transport Channel Configuration

1.1. Transport Formats (TF) and Transport Format Sets

(TFS)

1.1. TF and TFS – Transport Blocks and Format
MAC TrCH x PHY

MAC PHY
Transport Block Set TBS

Transport Block Transport Block TB #0
Set TBS Transport Block TB #1
Transmit Time ...
Interval TTI
Transport Block TB #N-1
Transport Block Transport Format (TF)

Set TBS
channel coding algorithm
Transmit Time CRC size
Interval TTI rate matching attribute
TTI
Transport Block
TB size (no. of bits)
Set TBS
TBS size (no. of TB in TBS)
time
1.1. TF and TFS – Transport Format Sets
Transport Format Set (TFS)
channel coding algorithm
TB size #0 TB size #1 TB size #K-1
CRC size
TBS size #0 TBS size #1
... TBS size #K-1
rate matching attribute
TTI TFI 0 TFI 1 TFI K-1

| 1.1.1.1.9 ul-AddReconfTransChInfoList |
| 1.1.1.1.9.1 uL-AddReconfTransChInformation |
|-----0-- |1.1.1.1.9.1.1 ul-TransportChannelType |dch |
|***b5*** |1.1.1.1.9.1.2 transportChannelIdentity |32 |
| 1.1.1.1.9.1.3 transportFormatSet |
| 1.1.1.1.9.1.3.1 dedicatedTransChTFS |
| 1.1.1.1.9.1.3.1.1 tti |
| 1.1.1.1.9.1.3.1.1.1 tti40 |
| 1.1.1.1.9.1.3.1.1.1.1 dedicatedDynamicTF-Info |
| 1.1.1.1.9.1.3.1.1.1.1.1 rlc-Size |
| 1.1.1.1.9.1.3.1.1.1.1.1.1 octetModeType1 |
|***b5*** |1.1.1.1.9.1.3.1.1.1.1.1.1.1 sizeType1 |16 |
| 1.1.1.1.9.1.3.1.1.1.1.2 numberOfTbSizeList |
| 1.1.1.1.9.1.3.1.1.1.1.2.1 numberOfTransportBlocks |
| |1.1.1.1.9.1.3.1.1.1.1.2.1.1 zero |0 |
| 1.1.1.1.9.1.3.1.1.1.1.3 logicalChannelList |
| |1.1.1.1.9.1.3.1.1.1.1.3.1 allSizes |0 |
| 1.1.1.1.9.1.3.1.1.1.2 dedicatedDynamicTF-Info |
| 1.1.1.1.9.1.3.1.1.1.2.1 rlc-Size |
| 1.1.1.1.9.1.3.1.1.1.2.1.1 octetModeType1 |
|10000--- |1.1.1.1.9.1.3.1.1.1.2.1.1.1 sizeType1 |16 |
| 1.1.1.1.9.1.3.1.1.1.2.2 numberOfTbSizeList |
| 1.1.1.1.9.1.3.1.1.1.2.2.1 numberOfTransportBlocks |
| |1.1.1.1.9.1.3.1.1.1.2.2.1.1 one |0 |
| 1.1.1.1.9.1.3.1.1.1.2.3 logicalChannelList |
| |1.1.1.1.9.1.3.1.1.1.2.3.1 allSizes |0 |
| 1.1.1.1.9.1.3.1.2 semistaticTF-Information |
| 1.1.1.1.9.1.3.1.2.1 channelCodingType |
|1------- |1.1.1.1.9.1.3.1.2.1.1 convolutional |third |
|***b8*** |1.1.1.1.9.1.3.1.2.2 rateMatchingAttribute |185 |
|-011---- |1.1.1.1.9.1.3.1.2.3 crc-Size |crc16 |

Each transport channel has to be configured with a set of transport characteristics that control the data transmission within
the channel.
Data transmission within a transport channel is organized in so called transport blocks (TB). A single transport block TB
contains data from one logical channel. Zero, one or more of these transport blocks (also from different logical channels)
are assembled in a single transport block set (TBS). One TBS has to be transmitted every transmission time interval
(TTI), which can be 10 ms, 20 ms, 40 ms or 80 ms.
The configuration of a single transport channel has to configure the TTI, TB size (bits or octets) and TBS size (in number of
transport blocks). Every transport block TB gets in the physical layer its own cyclic redundancy check (CRC). The size of the
CRC (CRC Size) which can be 0 bits, 8 bits, 12 bits, 16 bits or 24 bits, is a transport channel configuration parameter too.
The transport blocks together with their CRC are channel coded with either a ½ convolutional coding, 1/3 convolutional
coding or a 1/3 turbo coding. The type of channel coding is also part of the TrCH configuration parameter.
A problem of code division multiple access using OVSF channelization code tree is that the number of bits after channel
coding must be adapted to the physical layer frame size. This task is performed by the rate matching function. When too
many bits are coming from the channel encoder a puncturing algorithm will be used to reduce the number of bits, when
too less bits are available some bits will be repeated. The rate matching algorithm is configured with a single rate
matching attribute.
These parameters: TB size, TBS size, TTI, CRC size, Channel Coding and Rate Matching Attribute form a so called
transport format (TF). A single TBS is transmitted with exactly one TF. Several transport formats TF can be configured
in parallel for a single transport channel. All TF of a TrCH are called transport format set (TFS). The physical layer’s
architecture requires that all TF of a TFS have the same settings for TTI, CRC size, Channel Coding and Rate Matching
Attribute.
Whenever a new TrCH shall be created it is the RNC that allocates a TFS for it. The TFS is sent to Node B via NBAP
signalling. The UE gets the TFS either via System Information (BCCH) or via explicit RRC signalling on a CCCH or DCCH.

1.2. Transport Format Combinations TFC

TFS (TrCH 1) MAC
MAC TFS (TrCH 2)
TFI 0 0 kbps TFI 0 0 kbps
TFI 1 8 kbps TrCH 1 TrCH 2 TFI 1 16 kbps
TFI 2 32 kbps
PHY
PHY
TFCI TrCH 1 TrCH 2 Total TrCH Bit Rate
0 TFI 0 TFI 1 16 kbps
blocked TFI 1 TFI 2 40 kbps
blocked TFI 1 TFI 1 24 kbps

A UE can use several transport channels simultaneously. Each transport channel has its own set of transport formats
assigned. This means at every time instant every transport channel transmits a TBS using a certain transport format.
A set of one transport format for every configured transport channel is a transport format configuration (TFC). Which
transport format combinations TFC are permitted is indicated by the RNC to the UE. One major function that uses TFC
restrictions is the admission control, because in the end effect each TFC is associated with a certain required transmission
power.

2. Medium Access Control MAC

2.1. MAC Entities

2.1. MAC Entities
UE Node B RNC
NBAP NBAP
MAC-b BCH MAC-b
RACH, FACH,
MAC-c/sh DSCH, CPCH,PCH MAC-c/sh
MAC-hs HS-DSCH MAC-hs
MAC-d DCH MAC-d

MAC-d

2.1. MAC Entities
The MAC protocol is split into several entities:
• MAC-b: This entity is responsible for broadcasting the system information downlink. The system information is
assembled by the RNC at sent via NBAP messages to the Node B. From here the MAC-b sends this information periodically
in the cell.
• MAC-c/sh: MAC-c/sh has to manage all common transport and shared logical channels. For DCCH/DTCH on common
transport channels this includes identification of the UE with help of special UE identifiers contained in the MAC header.
• MAC-d: For DCH as well as DCCH/DTCH the MAC-d entities are responsible.
MAC-b and MAC-c/sh are created once per cell, whereas MAC-d is available inside the UE and the serving RNC for each UE.
For high speed downlink packet access a new MAC entity is introduced:
• MAC-hs: This entity manages the high speed downlink shared channel HS-DSCH. It is implemented in the Node B and
gets its data input from MAC-d (serving RNC) directly or indirectly via MAC-c/sh (drift RNC). MAC-hs is especially
responsible to perform the scheduling of downlink packet data.

2.2. MAC – PDU, LogCH Identification, UE Identification

on Layer 2

2.2. MAC-PDU, UE/LogCH Identification
x = T(raffic) | C(ontrol)
DCH case:
DxCH DxCH DxCH

#0 #1 #K-1
... Transport Block Set TBS
TB #0 (MAC-PDU #0)
MAC-d
MAC-d TB #1 (MAC-PDU #1)
...
TB #L-1 (MAC-PDU #L-1)
DCH #N
MAC - PDU
MAC MAC-SDU = LogCH Data
Header (RLC PDU)
PHY
PHY
DxCH – number (if K>1)

x = T(raffic) | C(ontrol)
Common TrCH (RACH, FACH, DSCH, CPCH) case:
DxCH DxCH
CCCH BCCH| #0 #K-1
CTCH from MAC-d
... Transport Block Set TBS
TB #0 (MAC-PDU #0)
MAC-c/sh
MAC-c/sh TB #1 (MAC-PDU #1)
...
TB #L-1 (MAC-PDU #L-1)
RACH |
FACH |
DSCH |
CPCH MAC - PDU
Header (RLC PDU)
PHY
PHY LogCH Type
DxCH – number (if K>1)
UE-identifier (for DxCH only)

Common TrCH (HS-DSCH) case:
DxCH DxCH DxCH
#0 #1 #K-1
...
MAC-d
MAC-d
MAC-d - PDU
MAC-d Flow Header (RLC PDU)
LogCH Type
MAC-hs DxCH – number (if K>1)
MAC-hs
MAC-hs PDU
HS-DSCH MAC-hs MAC-d ... MAC-d
Header PDU #0 PDU #M-1
PHY
PHY

Two major functions are provided by MAC protocol:
• explicit UE identification on common transport channels,
• multiplexing of logical channels onto/from transport channels.
On a DCH the MAC frame provides in its header the DCCH or DTCH logical channel number if more than one logical
channel is multiplexed onto the DCH.
On common transport channels like RACH, FACH, DSCH, FACH or CPCH the MAC header indicates the type of logical
channel that the transport block carries, the UE identity if the logical channel is DCCH or DTCH and if more than one logical
channel of the same UE and of the same type is contained the logical channel number.
For high speed downlink packet access a single UE can get one or more so called MAC-d flows on Iub interface. Each MAC-
d flow corresponds to a so called re-ordering queue. The MAC-d PDU indicates to which logical channel (DTCH) the data
belongs to. On the air interface the MAC-hs entity assembles several MAC-d PDU of the same user and bundles them in a
MAC-hs PDU. In the MAC-hs PDU the re-ordering queue identity and a sequence number (for retransmission purposes) is
contained. Furthermore size indicators for the contained MAC-d PDU are implemented into the MAC-hs PDU.

• MAC-PDU (non HS-DSCH)
MAC Header MAC SDU
UE-ID
TCTF Type
UE-ID C/T RLC PDU (LogCH Data)
• MAC-d PDU (for HS-DSCH)

MAC Header MAC SDU
C/T RLC PDU (LogCH Data)
• MAC PDU (HS-DSCH)

MAC Header MAC-hs SDUs
MAC-d PDU MAC-d PDU ... MAC-d PDU

MAC-hs Header
#0 #1 #N-1
Version Queue Seq.No. Size Index No. MAC-d

Flag #0 ... Size Index No. MAC-d
Flag #Y
Flag ID TSN Id. #0 PDUs #0 Id. #Y PDUs #Y

MAC PDU
UE RNC
MAC header UE identifier
----(no
(noMAC
MACUE
UEID)
ID) • UE uses CCCH/PCCH/BCCH/CTCH or
DCH/HS-DSCH
U-RNTI
U-RNTI(32
(32bit)
bit) • UE uses DCCH/DTCH on RACH/FACH in a
new cell
= S-RNC-ID + S-RNTI
C-RNTI
C-RNTI(16
(16bit)
bit) • UE uses DCCH/DTCH on RACH/FACH/
CPCH (not after cell change)
DSCH-RNTI
DSCH-RNTI(16
(16bit)
bit) • UE uses DCCH/DTCH on DSCH

• TCTF (Target Channel Type Field): Indicates logical channel type that is carried in the MAC header.
• UE-ID/UE-ID type: Identifies a UE on common transport channels for DCCH or DTCH. The UE-ID can be u-rnti (umts –
radio network temporary identifier), c-rnti (cell-rnti) or dsch-rnti. These identifiers must be allocated for a UE via RRC
signalling before their use.
• C/T (Channel of Type): If several logical channels of the same type are multiplexed onto the same transport channel,
this field is used to distinguish and therefore demultiplex them.
The following information elements are used in HS-DSCH frames only:

• Version Flag: Currently always set to zero. May be used to allow MAC-hs extensions in future.
• Queue ID: Indicates which re-ordering queue inside the UE the data belongs to. This enables independent buffer
management for data of different applications.
• TSN (Transmission Sequence Number): Sequence number for re-ordering purposes in case of disordering or re-
transmission.
• SID (Size Index Identifier): Identifies the size of a number of consecutive MAC-d PDU (see next field). The SID is
dynamically configured via higher layer signalling and is independent for each re-ordering queue.
• Number of MAC-d PDU: Indicates the number of consecutive MAC-d PDU with the same SID.
• Flag: If 0 then another SID fields follows, if 1 then the MAC-d PDU part starts after the flag.

• Example: MAC-PDU (Transport Block) Æ DCCH on DCH
| 2.2 FP: Transport Block |

|0011---- |2.2.1 MAC: C/T Field |Logical Channel 4 |
| |2.2.2 MAC: Target Channel Type |DCCH (Dedicated Control Channel) |
| |2.2.3 MAC: RLC Mode |Acknowledge Mode |
|----0--- |2.2.4 RLC: Data/Control |Control PDU |
|-----000 |2.2.5 RLC: PDU Type |STATUS |
| |2.2.6 RLC: Acknowledgement Super Field |
|0010---- |2.2.6.1 RLC: SUFI Type |Acknowledgement |
|**b12*** |2.2.6.2 RLC: Last Sequence Number |2 |
| |2.2.7 RLC: Padding |
|**b124** |2.2.7.1 RLC: Padding |'000000000000000000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'0000000000000000000000000'B |

• Example: MAC-PDU (Transport Block) Æ DCCH on FACH
| 2 FP: Transport Block |

|01------ | 2.1 MAC: Target Channel Type Field |DTCH/DCCH (Dedicated Traffic/Cont... |
|--01---- | 2.2 MAC: UE-ID Type |C-RNTI (Cell Radio Network Tempor... |
|**b16*** | 2.3 MAC: UE-ID |0 |
|----0010 | 2.4 MAC: C/T Field |Logical Channel 3 |
| | 2.5 MAC: RLC Mode |Acknowledge Mode |
|1------- | 2.6 RLC: Data/Control |Acknowledged mode data PDU |
|**b12*** | 2.7 RLC: Sequence Number |1 |
|-----1-- | 2.8 RLC: Polling Bit |Request a status report |
|------01 | 2.9 RLC: Header extension type |Octet contains LI and E bit |
|0001010- | 2.10 RLC: Length Indicator |10 |
|-------1 | 2.11 RLC: Extension Bit |The next field is LI and E bit |
|1111111- | 2.12 RLC: Length Indicator |Rest is padding |
|-------0 | 2.13 RLC: Extension Bit |The next field is data |
|**B10*** | 2.14 RLC: Last Data Segment |94 02 08 00 18 00 11 88 10 00 |
|***B4*** | 2.15 RLC: Padding |00 00 00 00 |

The two examples show a trace made on Iub interface. They contain MAC PDU on non-high speed channels.
The first example shows a transport block on DCH. There is no UE-ID because a DCH is already identifying a UE uniquely.
Also there is no TCTF, because on a DCH there can be either DCCH or DTCH but not mixed.
The second example shows a transport block on FACH. The TCTF indicates that DCCH is transported, thus a UE-ID is
required to assign the dedicated data to a UE. In this case the c-rnti is used.

2.3. RACH Access Control

2.3. RACH Access Control – Basic Procedure 1(3)
Uu Iub
UE Node B RNC
MAC PHY PHY MAC
START P = Persistence Value (SIB 7)

M = Preamble Cycle Counter (UE counter)
M= 1
Wait 10 ms
R=random (0≤R<1)
IF (R ≤ P)
TRUE FALSE
1st Preamble Cycle
[PHY] Acess.Request PHY:PRACH AccessPreamble
PHY:PRACH AccessPreamble Case: No acquisition indication

1) maximum no. of preambles
... 2) maximum power on PRACH
PHY:PRACH AccessPreamble
[PHY] NoAck.Indication

Uu Iub
UE Node B RNC
MAC PHY PHY MAC
Wait 10 ms
M:=M+1
Wait 10 ms
R=random (0≤R<1)
IF (R ≤ P)
TRUE FALSE
2nd Preamble Cycle
[PHY] Acess.Request PHY:PRACH AccessPreamble
PHY:PRACH AccessPreamble Case: Negative acquisition indication
PHY:AICH AI = -1
[PHY] NAck.Indication

Uu Iub
UE Node B RNC
MAC PHY PHY MAC
NBO1min = minimum value for backoff timer 1 (SIB)

Wait 10 ms NBO1max = maximum value for backoff timer 1 (SIB)
NBO1=random
{0 ≤ NBO1min ≤ NBO1 ≤ NBO1max}
Wait TBO1 (= NBO1 x 10 ms)
M:=M+1 Wait 10 ms
R=random (0≤R<1)
IF (R ≤ P)
TRUE FALSE
3rd Preamble Cycle
[PHY] Acess.Request
PHY:PRACH AccessPreamble
Case: Positive acquisition indication
[PHY] Ack.Indication PHY:AICH AI = +1
[PHY] Data.Request PHY:PRACH RACH Data RACH-FP RACH DATA

2.3. RACH Access Control – Basic Procedure
The MAC layer is in control of the PRACH preamble cycles. This means the MAC layer has to trigger PRACH preamble cycles
and to handle negative outcomes of this procedure.
Whenever a data transmission on RACH shall be done the MAC layer will first of all generate a random number R and
compare it against a so called persistence value P. The persistence value P is coming from system information SIB 7, a
block generated by the Node B itself. If the number R is bigger than P (R>P) then the MAC layer will wait 10 ms and
generate a new random number. If R is less or equal to P then the physical layer can start a random number. By
decreasing P the Node B can reduce the number of UE that will simultaneously access the RACH.
When a preamble cycle ends without an indication from the Node B, then the MAC layer will wait another 10 ms and restart
the preamble cycle (of course with random number and persistence check first) again.
When a preamble cycle ends with a negative indication from the Node B, then again the MAC layer has to wait 10 ms. But
afterwards the backoff 1 timer (T_BO1) is started with a time N_BO1 x 10 ms. N_BO1 is a random number that lies within
the range N_BO1min and N_BO1max. These limits are BCCH parameters. When T_BO1 has its time out, then another
preamble cycle including persistence check is done.
Both negative cases (no indication, negative indication) will be aborted when the maximum number of preambles (BCCH
parameter) is exceeded.
In case the preamble cycle is positive, then the RACH data will be transmitted.

3. Radio Link Control (RLC) Protocol

3.1. RLC Modes of Operation

RLC
RLCModes
Modes
Transparent
TransparentMode
Mode Unacknowledged
UnacknowledgedMode
Mode Acknowledged
AcknowledgedMode
Mode
TM
TM UM
UM AM
AM
• sequence number check

• no sequence number • sequence number check
• acknowledgements
check • no acknowledgements
• retransmission
• no acknowledgements • no retransmission
• no retransmission
• segmentation/reassembly
• segmentation/reassembly
is done in RLC
• segmentation/reassembly is done in RLC
may be used or not used
• sequence number and
• sequence number and
length indicators included in
• no RLC overhead length indicators included in
RLC frame + RLC control
RLC frame
messages required
MAC Header MAC Header MAC Header

RLC Seq. No. RLC Seq. No.
Length Indicators Length Indicators
RLC SDU cipher
(Data) unit cipher cipher
RLC SDU unit RLC SDU unit
(Data) (Data or Ctrl)

The RLC protocol is used to enhance the reliability of a single radio bearer. Thus there is one instance of RLC protocol per
radio bearer available. Each RLC instance can be set in one of three modes independent of each other:
• Transparent Mode (TM): In transparent mode there is no additional reliability provided by the RLC protocol instance.
Only segmentation and reassembly functions might be used. There is no RLC overhead included in this mode. Ciphering is
done over the whole RLC SDU.
• Unacknowledged Mode (UM): In unacknowledged mode there is at least a sequence number check provided by RLC.
This is used to ensure correct reassembly. Thus there are sequence numbers and length indicators for reassembly control n
the RLC frame. Ciphering is done over the whole RLC PDU except the sequence number.
• Acknowledged Mode (AM): In acknowledged mode the RLC protocol instance provides acknowledgements and
retransmission functionality. The RLC PDU contains now sequence number, length indicators for reassembly control and
RLC status messages for retransmission control. Ciphering is done over the whole RLC PDU except the sequence number.
Which mode is used is configured by the RNC during radio bearer setup procedure. Thus the UE is told via RRC signalling
which RLC mode to use on a radio bearer.
It is possible to combine TM and UM on the same radio bearer. This can be done by assigning uplink and downlink different
modes. It is not possible to combine AM with another mode, because for acknowledgements always uplink and downlink
direction must be used simultaneously in AM.

LogCH Type RLC Modes

BCCH TM
PCCH TM
CCCH-UL TM
CCCH-DL UM
DCCH TM UM AM
DTCH TM UM AM
CTCH UM

3.2. Segmentation/Reassembly Function

Layer
Layer33(RRC,
(RRC,applic.)
applic.)
RLC SDU #0 RLC SDU #1
RLC
RLC
RLC RLC RLC

header #0.0 header #0.1 #1.0 header #1.1 padding
RLC PDU #0 RLC PDU #1 RLC PDU #2

MAC
MAC
Transport Block Set
MAC RLC
header header #0.0
MAC RLC
header header #0.1 #1.0
PHY
PHY MAC RLC
header header #1.1 padding

Next to the enhanced reliability functions provided by RLC there is another task done by this protocol – segmentation and
reassembly. The RLC protocol instances have to segment higher layer data so that a transport block of an appropriate size
corresponding to the available transport formats can be formatted.
The RLC protocol can perform segmentation together with concatenation (several RLC SDU or segments of an RLC SDU in
one RLC PDU) and padding. The RLC protocol has been designed for maximum resource efficiency.
In unacknowledged and acknowledged mode the RLC protocol includes length indicators in its PDU to indicate the end of
an higher layer frame (RLC SDU). Sometimes the length indicators can also carry special control meaning.
In transparent mode such length indicators are not used. Rather the RLC protocol reassembles everything that comes in
the same transport blocks. This might not be exactly the inverse of the segmentation process in transparent mode.
Therefore segmentation and reassembly is usually switched off when transparent mode is used. The higher layers have
then to send frame of correct size to match the transport block sizes.

3.3. RLC Transparent Mode Procedures

UE RNC
RLC TMD PDU

RLC SDU segments
.
.
RLC TMD PDU .
RLC SDU segments
IF all segments of a SDU
received
Æ reassembly
RLC TMD PDU

RLC SDU segments
.
.
RLC TMD PDU .
RLC SDU segments
received
Æ reassembly

|00------ |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) |
| |2.2 MAC: RLC Mode |Transparent Mode |
|**b166** |2.3 RLC: Whole Data |'001000010000011101000000001000011'B |
| | |'010000000100110001000000001000000'B |
| | |'111110100110110000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'0'B |
RLC Transparent Mode DATA
segmented
SDU data

In transparent mode there is only the data transfer procedure defined. It is implemented via the TMD PDU (Transparent
Mode Data). The TMD PDU contains nothing else data from higher layers, no RLC control information is to be found.

3.4. Unacknowledged Mode Procedures

UE RNC
RLC UMD PDU

Sequence No. = 2, Length Indicators, RLC SDU segments
.
.
RLC UMD PDU .
received
Æ reassembly
RLC UMD PDU

.
.
RLC UMD PDU .
received
Æ reassembly

|01000000 |2.1 MAC: Target Channel Type Field |CCCH (Common Control Channel) |
| |2.2 MAC: RLC Mode |Unacknowledge Mode |
|0101010- |2.3 RLC: Sequence Number |42 |
|-------1 |2.4 RLC: Extension Bit |The next field is LI and E bit |
|1111100- |2.5 RLC: Length Indicator |Start with new SDU |
|-------0 |2.6 RLC: Extension Bit |The next field is data |
|**B18*** |2.7 RLC: First Data Segment |30 f7 36 c0 00 04 24 c4 02 00 18... |
|**B19*** |3.5 RLC: Data Segment |49 d3 e2 84 f8 ea 30 00 14 61 67... |

|**B19*** |2.5 RLC: Data Segment |92 13 e5 a9 40 00 52 8a 13 a7 cd... |
|**B19*** |3.5 RLC: Data Segment |d3 e8 84 fa 6a 90 00 15 08 00 06... |

|**B19*** |2.5 RLC: Data Segment |04 80 11 dc 32 00 01 04 13 f7 eb... |
|0001110- |3.5 RLC: Length Indicator |14 |
|1111111- |3.7 RLC: Length Indicator |Rest is padding |
|**B14*** |3.9 RLC: Last Data Segment |ba dd fc 80 64 53 ca 08 00 40 8c... |
|***B3*** |3.10 RLC: Padding |00 00 00 |

• UMD PDU (7-bit Length Indicators) • UMD PDU (15-bit Length Indicators)
Sequence Number E Sequence Number E
LI0 E LI0 (high part)

... LI0 (low part) E
LIN-1 E=0 ...

LIN-1 (high part)
LIN-1 E=0
segmented
RLC SDU
segmented
RLC SDU
padding
padding

In unacknowledged mode there is also only one frame defined, the UMD PDU (Unacknowledged Mode Data PDU). It
is used to carry RLC SDU or segments of RLC SDU between UE and RNC.
To enable faithful segmentation and reassembly, length indicators are used to point to the end of the last segment of a
RLC SDU. This means a length indicator is to be found whenever a UMD PDU contains the last (or the only one) segment of
a RLC SDU. In some situations special length indicators will be included that have control meaning (e.g. reset of
reassembly etc.).
Length indicators can be either 7 bit long or 15 bit long. It depends on the largest UMD PDU (transport block size – MAC
header size) in the associated transport channel. If the maximum UMD PDU size is less or equal 125 bytes, then 7 bit
length indicators shall be used, otherwise 15 bit length indicators have to be included in the UMD PDU.
For detection of lost RLC PDU there is a 7 bit long sequence number included in every UMD PDU. If an UMD PDU is lost,
then all RLC SDU with segments in this UMD PDU are discarded by the receiver.

3.5. Acknowledged Mode Procedures

UE Reset RNC
RLC RESET PDU

Reset Sequence Number, Hyper Frame Number uplink (HFNI)
RLC RESET ACK PDU

Reset Sequence Number, Hyper Frame Number downlink (HFNI)
RLC RESET PDU

Reset Sequence Number, Hyper Frame Number downlink (HFNI)
RLC RESET ACK PDU

Reset Sequence Number, Hyper Frame Number uplink (HFNI)

UE Data Transfer with Solitary STATUS PDU RNC
RLC AMD PDU

Sequence No. = 12, Poll Bit P, Length Indicators, RLC SDU segments
.
.
RLC AMD PDU .
RLC STATUS PDU

Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST
RLC AMD PDU

.
.
RLC AMD PDU .
RLC STATUS PDU

Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST

UE Data Transfer with Piggybacked STATUS PDU RNC
RLC AMD PDU

.
.
RLC AMD PDU .
RLC AMD PDU

Sequence No. = 34, Poll Bit P, Length Indicators, RLC SDU Segments,
Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST}
RLC AMD PDU

.
.
RLC AMD PDU .
RLC AMD PDU

Sequence No. = 39, Poll Bit P, Length Indicators, RLC SDU Segments,
Piggybacked STATUS PDU = {Acknowledgement super fields (SUFI): ACK, BITMAP, LIST, RLIST}

UE Move Receiving Window Procedure RNC
RLC STATUS PDU

Move Receiving Window (MRW) super field: SN1,...SNK
RLC STATUS PDU

Move Receiving Window Ack (MRWACK) super field
RLC STATUS PDU

Move Receiving Window (MRW) super field: SN1,...SNK
RLC STATUS PDU

Move Receiving Window Ack (MRWACK) super field

UE Windowsize Configuration RNC
RLC STATUS PDU

Window (WINDOW) super field: window size
RLC STATUS PDU

Window (WINDOW) super field: window size

In acknowledged mode there some more procedures defined. In detail we have
• Reset: The Reset procedure is used to recover after errors in acknowledged mode. A new HFNI (Hyper Frame Number
Indicator) for ciphering can be allocated at Reset procedure. The RESET PDU and RESET ACK PDU are defined for this
procedure.
• Data Transfer with solitary STATUS PDU: For data transfer the AMD (Acknowledged Mode Data) PDU is defined. It
carries a 12 bit long sequence number. A single AMD or a series of AMD PDU can be acknowledged by a stand-alone
acknowledgement in form of a STATUS PDU.
• Data Transfer with piggybacked STATUS PDU: Very often AMD PDU are exchanged in both directions. In this case it
is possible to include STATUS PDU in AMD PDU for acknowledgements. This simply is more efficient with respect to
bandwidth usage.
• Move Receiving Window: In some situations an AMD PDU is transmitted and retransmitted correctly. This situation
can be determined by thresholds (maximum number of retransmissions) or timers (maximum time for data transmission).
Either an error is the result or both sides agree to skip the problematic AMD PDU. For skipping (discarding) the Move
Receiving Window procedure is used. In a STATUS PDU the command to move the receiving window with the sequence
numbers of the AMD PDU to be discarded are indicated. An acknowledgement completes the procedure.
• Window Size: The RLC protocol uses acknowledgements that acknowledges several AMD PDU with one message. The
maximum number of AMD PDU that can be sent without acknowledgement is indicated in the window size procedure. A
STATUS PDU contains a window size field in which the limit is indicated.

|----1--- |2.2.4 RLC: Data/Control |Acknowledged mode data PDU |
|**b12*** |2.2.5 RLC: Sequence Number |2 |
|-1------ |2.2.6 RLC: Polling Bit |Request a status report |
|--01---- |2.2.7 RLC: Header extension type |Octet contains LI and E bit |
|***b7*** |2.2.8 RLC: Length Indicator |9 |
|---1---- |2.2.9 RLC: Extension Bit |The next field is LI and E bit |
|***b7*** |2.2.10 RLC: Length Indicator |Rest is padding |
|---0---- |2.2.11 RLC: Extension Bit |The next field is data |
|**b72*** |2.2.12 RLC: Last Data Segment |df d9 4c ed 0d 21 31 f1 10 |
|**b40*** |2.2.13 RLC: Padding |00 00 00 00 00 |
|----0--- |2.2.4 RLC: Data/Control |Control PDU |
|-----000 |2.2.5 RLC: PDU Type |STATUS |
| |2.2.6 RLC: Acknowledgement Super Field |
|0010---- |2.2.6.1 RLC: SUFI Type |Acknowledgement |
|**b12*** |2.2.6.2 RLC: Last Sequence Number |3 |
| |2.2.7 RLC: Padding |
|**b124** |2.2.7.1 RLC: Padding |'000000000000000000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'000000000000000000000000000000000'B |
| | |'0000000000000000000000000'B |

• AMD PDU (7-bit Length Indicators) • AMD PDU (15-bit Length Indicators)
D/C D/C
(1) Sequence Number (high part) (1) Sequence Number (high part)
Seq.Number (low part) P HE Seq.Number (low part) P HE
LI0 E LI0 (high part)

... LI0 (low part) E
LIN-1 E=0 ...

LIN-1 (high part)
LIN-1 E=0
segmented
RLC SDU
segmented
RLC SDU
Padding| piggybacked STATUS PDU

padding

• RESET/RESET ACK PDU • STATUS PDU
D/C PDU TYPE D/C PDU TYPE

(0) 001/010
RSN reserved
(0) 000 SUFI #1
HFNI SUFI #1
...
HFNI
SUFI #N
HFNI padding
padding
padding Note: In case of a piggybacked STATUS PDU

the D/C bit is reserved.

Super Fields (SUFI)
NO_MORE
0 0 0 0 LIST MRW
0 0 1 1 LENGTH 0 1 1 0 LENGTH
WINDOW SN1 high SN1 high
0 0 0 1 WSN high SN1 low L1 SN1 low SN2 high
WSN low ... SN2 high
SNLENGTH high ...
ACK SNLENGTH low LLENGTH SNLENGTH high
0 0 1 0 LSN high
SNLENGTH low NLENGTH
LSN low BITMAP
0 1 0 0 LENGTH MRW_ACK
RLIST FSN high 0 1 1 1 NLENGTH
0 1 0 1 LENGTH FSN low BITMAP
SNACK high
FSN high ...
BITMAP Padding SNACK low Padding
FSN low CW1
...
CWLENGTH padding

AMD PDU have a similar format like UMD PDU. The sequence of length indicators is used to control reassembly. Each
length indicator points to the end of the last segment of a RLC SDU. Furthermore some special length indicator values are
reserved (e.g. whether a STATUS PDU is carried within the AMD PDU or not, etc.). Again there are 7 bit long length
indicators and 15 bit long length indicators. If the maximum AMD PDU size is less or equal to 126 octets then 7 bit long
length indicators shall be used, otherwise 15 bit length indicators are chosen.
The sequence number of AMD PDU is 12 bit long to enable bigger window size for acknowledgements. The poll bit P is
used to request immediate acknowledgement for a AMD PDU.
STATUS PDU contain one or more so called super fields SUFI. Each SUFI carries special acknowledged mode control
meaning for acknowledgements, window size negotiation, moving receiving window. The following SUFI types are known:
• No More: Indicates end of the STATUS PDU.
• ACK: A simple acknowledgement. Indicates the next expected AMD PDU sequence number (LSN: last sequence number).
• LIST: Indicates gaps of the reception of AMD PDU. Each gap is indicated by its start sequence number (SN: start
number) and its length (L:length). Up to 15 gaps can be indicated in a single LIST super field.
• BITMAP: Indicates positive or negative acknowledgement for a series of consecutive AMD PDU with a bitmap. The first
bit of the bitmap stands for AMD PDU with sequence number FSN (FSN: first sequence number). The second bit of the
bitmap is for FSN+1, and so on. When the bit is ‘0’ the associated AMD PDU is negatively acknowledged.
• MRW/MRW_ACK: Used to move the receiving window. Inside the MRW field each AMD PDU to be discarded is
indicated by its sequence number SN.
• RLIST: A relative list used to indicate gaps in the reception. The method to specify the gap is different to LIST super
field. In a RLIST special code words CW are used to calculate gap start and length.

Module 03
Radio Resource Control Signalling

(RRC)
Version 0.0.1 (21/03/2005)


1. System Information

1.1. System Information Blocks and Segmentation

1.1. System Information Blocks and Segments
UE RNC
[BCH:BCCH] RRC SystemInformation (SI)

SFNPrime (INTEGER 0…4094 step 2), Segment Combination = CHOICE {
Combination 1: no data |
Combination 2: first segment |
Combination 3: subsequence segment |
Combination 4: last segment |
Combination 5: last segment, first segment |
Combination 6: last segment, complete list = {complete block#0, …, complete block#N} |
Combination 7: last segment, complete list = {complete block#0, …, complete block#N}, first segment |
Combination 8: complete list = {complete block#0, …, complete block#N} |
Combination 9: complete list = {complete block#0, …, complete block#N}, first segment |
Combination10: complete SIB of size 215…226 |
Combination11: last segment of size 215…226 }
System Information Block (SIB):

first subsequent ... subsequent last
segment segment segment segment

1.1. System Information Blocks and Segments
Signalling on the BCCH is done by means of the RRC System Information. On the BCH that carries the BCCH there is only
RLC transparent mode used. Thus the RRC protocol must provide its own sequence numbering and segmentation
functionality.
For segmentation of System Information Blocks (SIB) the RRC protocol defines the System Information (SI) message.
In each SI message one or more segments of a SIB or several SIB can be contained. Several combinations allow to
indicate first, last and subsequent segments, or to bundle several complete blocks in one SI message.
Additionally to the SIB segments the SI message also indicates the cell time via the System Frame Number (0..4095).
The SFN is translated into the SFN prime via th following rule. In each frame with even SFN (SFN mod 2 = 0) it holds
SFN prime = SFN. In radio frames with odd SFN (SFN mod 2 = 1) we have SFN prime = SFN-1. In other words the SFN
prime is increased with every second radio frame by 2.

1.2. Master and Scheduling Information Blocks

UE Master Information Block (MIB) RNC
[BCH:BCCH] RRC MasterInformationBlock (MIB)

MIB value tag, supported PLMN types = GSM-MAP|ANSI-41|GSM-MAP+ANSI-41,
PLMN identity = MCC + MNC, ANSI-41-CN information,
references to other system information blocks = { SIB Type, value tag, scheduling }
80 ms

80 ms


UE Scheduling Information Block (SchIB1/2) RNC
[BCH:BCCH] RRC SchedulingInformationBlock1/2

repetition
rate given
in MIB

repetition
rate given
in MIB


Master Information Block MIB
| |masterInfoBlock (= masterInfoBlock) |
| |sib_description |
| |1 sib_choice |
| |1.1 masterInfoBlock |
|-001---- |1.1.1 mib-ValueTag |2 |
| |1.1.2 plmn-Type |
| |1.1.2.1 gsm-MAP |
| |1.1.2.1.1 plmn-Identity |
| |1.1.2.1.1.1 mcc |
|***b4*** |1.1.2.1.1.1.1 digit |2 |
|--0110-- |1.1.2.1.1.1.2 digit |6 |
|***b4*** |1.1.2.1.1.1.3 digit |2 |
| |1.1.2.1.1.2 mnc |
|---0000- |1.1.2.1.1.2.1 digit |0 |
|***b4*** |1.1.2.1.1.2.2 digit |9 |
| |1.1.3 sibSb-ReferenceList |
| |1.1.3.1 schedulingInformationSIBSb |
| |1.1.3.1.1 sibSb-Type |
|***b8*** |1.1.3.1.1.1 sysInfoType1 |44 |
| |1.1.3.1.2 scheduling |
| |1.1.3.1.2.1 scheduling |
| |1.1.3.1.2.1.1 segCount |1 |
| |1.1.3.1.2.1.2 sib-Pos |
|***b6*** |1.1.3.1.2.1.2.1 rep128 |6 |
| |1.1.3.2 schedulingInformationSIBSb |
| |1.1.3.2.1 sibSb-Type |
|------01 |1.1.3.2.1.1 sysInfoType2 |2 |
...

The individual system information blocks in the RRC protocol divide the information into groups. Two blocks have special
meaning: the master information block and the scheduling information blocks.
In the master information block MIB the PLMN type (GSM-MAP or ANSI-41) is indicated. For GSM-MAP the PLMN identity
(MCC + MNC) is broadcasted also in the MIB. Then for every further system information block the MIB indicates
scheduling information and a value tag (except SIB 7). The value tag indicates changes of the associated SIB by
incremented value.
The master information block always starts at radio frames with SFN mod 8 = 0.

1.3. System Information Blocks (SIB)

General System Information Transmission
UE RNC
[BCH:BCCH] RRC SIBx

SIBx data
repetition
rate given
in MIB
[BCH:BCCH] RRC SIBx

SIBx data
repetition
rate given
in MIB
[BCH:BCCH] RRC SIBx

SIBx data

UE RNC
[BCH:BCCH] RRC SIB1

CN common GSM-MAP NAS info = LAC, CS domain system info = {periodic LAU timer T3212, ATT flag},
PS domain system info = {RAC, Network Mode of Operation NMO},
UE timers and constants in idle mode, UE timers and constants in connected mode
[BCH:BCCH] RRC SIB2

URA-ID list = URA#1,.., URA#<maxURA>
[BCH:BCCH] RRC SIB3

SIB4 indicator = true|false, cell identity, cell selection and re-selection info, cell access restriction
[BCH:BCCH] RRC SIB4

cell identity, cell selection and re-selection info, cell access restriction

UE RNC
[BCH:BCCH] RRC SIB5

SIB6 indicator = true|false, PICH power offset, AICH power offset, secondary CCPCH system info,
primary CCPCH info = Tx diversity indicator, PRACH system information list, CBS DRX level 1 information
[BCH:BCCH] RRC SIB6

PICH power offset, AICH power offset, secondary CCPCH system info, CBS DRX level 1 information,
primary CCPCH info = Tx diversity indicator, PRACH system information list
[BCH:BCCH] RRC SIB7

UL interference, dynamic persistence level for PRACH in SIB5/6, expiration time factor
[BCH:BCCH] RRC SIB8

CPCH parameters (UE access parameters), CSICH power offset, CPCH set info (code and resource info)
[BCH:BCCH] RRC SIB9

CPCH persistence levels

UE RNC
[BCH:BCCH] RRC SIB10

DRAC (dynamic resource allocation) system information

SIB12 indicator = true|false,
FACH measurement occasion info = {measurement cycle length info, IF/IRAT measurement indicators}
measurement control system information = {HCS indicator, cell selection/re-selection quantity,
neighbour cell list SF/IF/IRAT, traffic volume measurements}

FACH measurement occasion info = {measurement cycle length info, IF/IRAT measurement indicators}
measurement control system information = {HCS indicator, cell selection/re-selection quantity,
neighbour cell list SF/IF/IRAT, traffic volume measurements}
[BCH:BCCH] RRC SIB13|SIB13.1|SIB13.2|SIB13.3|SIB13.4

ANSI-41 CN information

UE RNC

3.84 Mcps TDD mode system information
[BCH:BCCH] RRC SIB15|SIB15.1|SIB15.2|SIB15.3|SIB15.4|SIB15.5

system information for UE positioning

pre-defined RB/TrCH/PhCH configuration for inter-system handover to UTRAN

3.84 Mcps TDD|1.28 Mcps TDD mode system information

PLMN identities for neighbour cells for idle|connected mode UE

System Information Block SIB1
| |sibType1 (= sibType1) |
| |sib_description |
| |1 sib_choice |
| |1.1 sibType1 |
|**b16*** |1.1.1 cn-CommonGSM-MAP-NAS-SysInfo |00 18 |
| |1.1.2 cn-DomainSysInfoList |
| |1.1.2.1 cN-DomainSysInfo |
|0------- |1.1.2.1.1 cn-DomainIdentity |cs-domain |
| |1.1.2.1.2 cn-Type |
|**b16*** |1.1.2.1.2.1 gsm-MAP |01 01 |
|-----01- |1.1.2.1.3 cn-DRX-CycleLengthCoeff |7 |
| |1.1.2.2 cN-DomainSysInfo |
|-------1 |1.1.2.2.1 cn-DomainIdentity |ps-domain |
| |1.1.2.2.2 cn-Type |
|**b16*** |1.1.2.2.2.1 gsm-MAP |08 01 |
|----01-- |1.1.2.2.3 cn-DRX-CycleLengthCoeff |7 |
| |1.1.3 ue-ConnTimersAndConstants |
|----1010 |1.1.3.1 t-301 |ms2000 |
|010----- |1.1.3.2 n-301 |2 |
|---1100- |1.1.3.3 t-302 |ms4000 |
...
|--001--- |1.1.3.22 t-317 |s10 |
| |1.1.4 ue-IdleTimersAndConstants |
|***b4*** |1.1.4.1 t-300 |ms1000 |
|-011---- |1.1.4.2 n-300 |3 |
|----1010 |1.1.4.3 t-312 |10 |
|000----- |1.1.4.4 n-312 |s1 |

2. RRC Connection Handling
2.1. RRC States

2.1. RRC States
URA_PCH
URA_PCH CELL_PCH
CELL_PCH
CELL_DCH
CELL_DCH CELL_FACH
CELL_FACH
UTRA
UTRAIDLE
IDLE

2.1. RRC States
To manage radio resources of a UE in UMTS a state system with respect to the RRC protocol is introduced. In general a
UE has two main states – UTRA Idle and UTRA Connected. The difference between idle and connected is that in
connected mode there is a serving RNC for the UE, whereas in idle mode there is no serving RNC. Note that a connected
mode UE can have radio resources allocated or not. In idle mode a UE cannot have radio resources.
To make a more detailed specification of a connected mode UE there are four sub-states defined for connected mode:
• CELL_DCH: In this state the UE uses DCH for signalling and might use additional DCH or DSCH for applications. The
UE is subject to soft and hard handover procedures in this state.
• CELL_FACH: In this state the UE listens to FACH for RRC signalling and uses RACH on the uplink side. Also CPCH
might be in use. Mobility is handled in this state via cell reselection, handover procedures like in CELL_DCH state are not
used.
• CELL_PCH: Here the UE has currently no radio resources allocated. Thus the UE waits for incoming paging messages
on the PCH. The UE executes cell reselection, the RNC knows the current serving cell of the UE.
• URA_PCH: This state is similar to CELL_PCH, only this time the RNC knows the current URA (UTRAN Registration
Area) of the UE and not the cell.
In CELL_FACH, CELL_PCH and URA_PCH the UE performs automatic cell reselection. Thus the RNC has to be updated
whenever the area of interest (cell for CELL_FACH and CELL_PCH, URA for URA_PCH) changes.

2.1. RRC States – Cell Reselection in CELL_FACH
UE RNC
CELL_FACH
automatic
cell reselection
[RACH:CCCH] RLC/RRC TMD Cell Update
U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, …
[FACH:CCCH] RLC/RRC UMD Cell Update Confirm

U-RNTI, new U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator = state_X,
CN info, RB to reconfigure or delete, TrCH-UL to add/reconfigure/delete, TrCH-DL to add/reconfigure/
delete, uplink/downlink physical resources
State_X
...

2.1. RRC States – Cell Reselection in CELL_PCH
UE RNC
CELL_PCH
automatic
cell reselection
CELL_FACH
[RACH:CCCH] RLC/RRC TMD Cell Update

U-RNTI, STARTCS, STARTPS, cell update cause = cell re-selection , measured results on RACH, …
[FACH:CCCH] RLC/RRC UMD Cell Update Confirm

State_X
...

2.1. RRC States –URA Reselection in URA_PCH
UE RNC
URA_PCH
automatic
cell reselection
(new cell is not part of old URA) false URA_PCH

true
CELL_FACH
[RACH:CCCH] RLC/RRC TMD URA Update

U-RNTI, STARTCS, STARTPS, URA update cause = URA re-selection
[FACH:CCCH] RLC/RRC UMD URA Update Confirm

State_X
...

2.1. Mobility Handling in CELL_FACH, CELL_PCH
and URA_PCH
When a UE reselects a cell in CELL_FACH state, it has to perform a CELL UPDATE procedure afterwards in the new cell.
The CELL UPDATE message contains the current UE identifier (U-RNTI), so that the RNC can identify the UE. The
message is sent on RACH via CCCH. Thus the associated response CELL UPDATE CONFIRM is returned to the UE on the
FACH, also CCCH. In this message the UE is assigned a new state or again CELL_FACH.
A similar procedure is done when a UE reselects a cell in CELL_PCH state. The only difference to the update procedure in
CELL_FACH is, that after the cell reselection the UE enters automatically CELL_FACH state and then sends CELL UPDATE
to the RNC. With the CELL UPDATE CONFIRM the UE is sent to a new state or back to CELL_PCH.
In case the UE reselects a cell in URA_PCH state then another procedure is done. First of all the UE checks whether the
new cell still belongs to the old URA. If this is true no update procedure will be performed. Otherwise the UE enters
CELL_FACH state and sends URA UPDATE on RACH. The response CELL UPDATE CONFIRM on the FACH contains again
a new state for the UE. If this state is set to URA_PCH, then the UE goes back to URA_PCH state and enters the master
URA (URA #0 in SIB2) of the new cell.

2.2. RRC Connection Establishment

2.2. RRC Connection Estab. - CELL_FACH
UE RNC
UTRA IDLE Æ CELL_FACH
UTRA IDLE
NAS Trigger
[RACH:CCCH] RLC/RRC TMD RRC Connection Request
pre-defined configuration status indicator = true|false, Initial UE ID, establishment cause,
measured result on RACH
• orig./term. conversational call • inter-RAT cell re-selection
• orig./term. streaming call • inter-RAT cell change order
• orig./term. interactive call • registration
• TMSI + LAI • orig./term. background call • detach
• PTMSI + RAI • originating subscribed traffic call • orig./term. high/low priority signalling
• IMSI • emergency call • call re-establishment
• IMEI • terminating – cause unknown
[FACH:CCCH] RLC/RRC UMD RRC Connection Setup

Initial UE ID, new U-RNTI, new C-RNTI, RRC state indicator = CELL_FACH, capability update
requirement, signalling radio bearer to setup, TrCH to add/reconfigure
[RACH:DCCH] RLC/RRC AMD RRC Connection Setup Complete
STARTCS, STARTPS, UE radio access capability, inter-RAT UE radio access capability
[RACH:DCCH] RLC/- STATUS
Acknowledgement
CELL_FACH

2.2. RRC Connection Est. – CELL_FACH
RRC Connection Establishment Æ CELL_FACH (short trace)
+--------+--------------------+------------+------------+------------+-------------------------------------+
|No |Long Time |2. Prot |2. MSG |3. Prot |3. MSG |
+--------+--------------------+------------+------------+------------+-------------------------------------+
|68 |17:25:34,045,725 |RLC/MAC |FP DATA RACH| | |
|69 |17:25:34,045,725 |RLC reasm. |TM DATA RACH|RRC_CCCH_UL |rrcConnectionRequest |
|70 |17:25:34,130,812 |RLC/MAC |FP DATA FACH| | |
|73 |17:25:34,150,775 |RLC reasm. |UM DATA FACH|RRC_CCCH_DL |rrcConnectionSetup |
|76 |17:25:34,513,729 |RLC reasm. |AM DATA RACH|RRC_DCCH_UL |rrcConnectionSetupComplete |

RRC Connection Request
|TS 25.331 CCCH-UL (2002-09) (RRC_CCCH_UL) rrcConnectionRequest (= rrcConnectionRequest) |
| |uL-CCCH-Message |
| |1 message |
| |1.1 rrcConnectionRequest |
| |1.1.1 initialUE-Identity |
| |1.1.1.1 tmsi-and-LAI |
|***B4*** |1.1.1.1.1 tmsi |'00000111010000000010000110011110'B |
| |1.1.1.1.2 lai |
| |1.1.1.1.2.1 plmn-Identity |
| |1.1.1.1.2.1.1 mcc |
|0010---- |1.1.1.1.2.1.1.1 digit |2 |
|----0110 |1.1.1.1.2.1.1.2 digit |6 |
|0010---- |1.1.1.1.2.1.1.3 digit |2 |
| |1.1.1.1.2.1.2 mnc |
|***b4*** |1.1.1.1.2.1.2.1 digit |0 |
|-0010--- |1.1.1.1.2.1.2.2 digit |2 |
|**b16*** |1.1.1.1.2.2 lac |'0000011111010010'B |
|***b5*** |1.1.2 establishmentCause |registration |
|--0----- |1.1.3 protocolErrorIndicator |noError |

RRC Connection Setup 1( )
|TS 25.331 CCCH-DL (2002-09) (RRC_CCCH_DL) rrcConnectionSetup (= rrcConnectionSetup) |
| |dL-CCCH-Message |
| |1 message |
| |1.1 rrcConnectionSetup |
| |1.1.1 r3 |
| |1.1.1.1 rrcConnectionSetup-r3 |
| |1.1.1.1.1 initialUE-Identity |
| |1.1.1.1.1.1 tmsi-and-LAI |
|**b32*** |1.1.1.1.1.1.1 tmsi |'00000111010000000010000110011110'B |
| |1.1.1.1.1.1.2 lai |
| |1.1.1.1.1.1.2.1 plmn-Identity |
| |1.1.1.1.1.1.2.1.1 mcc |
|---0010- |1.1.1.1.1.1.2.1.1.1 digit |2 |
|***b4*** |1.1.1.1.1.1.2.1.1.2 digit |6 |
|---0010- |1.1.1.1.1.1.2.1.1.3 digit |2 |
| |1.1.1.1.1.1.2.1.2 mnc |
|0000---- |1.1.1.1.1.1.2.1.2.1 digit |0 |
|----0010 |1.1.1.1.1.1.2.1.2.2 digit |2 |
|***B2*** |1.1.1.1.1.1.2.2 lac |'0000011111010010'B |
|00------ |1.1.1.1.2 rrc-TransactionIdentifier |0 |
| |1.1.1.1.3 new-U-RNTI |
|**b12*** |1.1.1.1.3.1 srnc-Identity |'010111110000'B |
|**b20*** |1.1.1.1.3.2 s-RNTI |'00001011101011110111'B |
|**b16*** |1.1.1.1.4 new-c-RNTI |'0000000000000000'B |
|--01---- |1.1.1.1.5 rrc-StateIndicator |cell-FACH |
|----000- |1.1.1.1.6 utran-DRX-CycleLengthCoeff |3 |

| |1.1.1.1.7 capabilityUpdateRequirement |
|1------- |1.1.1.1.7.1 ue-RadioCapabilityFDDUpdateRequ.. |1 |
|-0------ |1.1.1.1.7.2 ue-RadioCapabilityTDDUpdateRequ.. |0 |
| |1.1.1.1.7.3 systemSpecificCapUpdateReqList |
| |1.1.1.1.7.3.1 systemSpecificCapUpdateReq |gsm |
| |1.1.1.1.8 srb-InformationSetupList |
| |1.1.1.1.8.1 sRB-InformationSetup |
|00000--- |1.1.1.1.8.1.1 rb-Identity |1 |
...
| |1.1.1.1.8.1.3.2 rB-MappingOption |
...
| |1.1.1.1.8.1.3.2.1.1.1 ul-TransportChannelType |
| |1.1.1.1.8.1.3.2.1.1.1.1 rach |0 |
|***b4*** |1.1.1.1.8.1.3.2.1.1.2 logicalChannelIdentity |2 |
...
| |1.1.1.1.8.1.3.2.2.1.1 dl-TransportChannelType |
| |1.1.1.1.8.1.3.2.2.1.1.1 fach |0 |

...
| |1.1.1.1.8.2.3.2 rB-MappingOption |
| |1.1.1.1.8.2.3.2.1.1.1 ul-TransportChannelType |
| |1.1.1.1.8.2.3.2.1.1.1.1 rach |0 |
...
| |1.1.1.1.8.2.3.2.2.1.1 dl-TransportChannelType |
| |1.1.1.1.8.2.3.2.2.1.1.1 fach |0 |
|----0010 |1.1.1.1.8.2.3.2.2.1.2 logicalChannelIdentity |3 |
|-00010-- |1.1.1.1.8.3.1 rb-Identity |3 |
| |1.1.1.1.8.3.2 rlc-InfoChoice |
|***b5*** |1.1.1.1.8.3.2.1 same-as-RB |2
...
|--00011- |1.1.1.1.8.4.1 rb-Identity |4 |
| |1.1.1.1.8.4.2 rlc-InfoChoice |
|00001--- |1.1.1.1.8.4.2.1 same-as-RB |2 |
...

RRC Connection Setup Complete
|TS 25.331 DCCH-UL (2002-09) (RRC_DCCH_UL) rrcConnectionSetupComplete (= rrcConnectionSetupComplete) |
| |uL-DCCH-Message |
| |1 message |
| |1.1 rrcConnectionSetupComplete |
|-00----- |1.1.1 rrc-TransactionIdentifier |0 |
| |1.1.2 startList |
| |1.1.2.1 sTARTSingle |
|-----0-- |1.1.2.1.1 cn-DomainIdentity |cs-domain |
|**b20*** |1.1.2.1.2 start-Value |'00000000000000000100'B |
| |1.1.2.2 sTARTSingle |
|--1----- |1.1.2.2.1 cn-DomainIdentity |ps-domain |
|**b20*** |1.1.2.2.2 start-Value |'00000000000000001010'B |
| |1.1.3 ue-RadioAccessCapability |
| |1.1.3.1 accessStratumReleaseIndicator |r99 |
| |1.1.3.2 pdcp-Capability |
|0------- |1.1.3.2.1 losslessSRNS-RelocationSupport |0 |
| |1.1.3.2.2 supportForRfc2507 |
| |1.1.3.2.2.1 notSupported |0 |
| |1.1.3.3 rlc-Capability |
|--010--- |1.1.3.3.1 totalRLC-AM-BufferSize |kb50 |
|-----0-- |1.1.3.3.2 maximumRLC-WindowSize |mws2047 |
|***b3*** |1.1.3.3.3 maximumAM-EntityNumber |am6 |
| |1.1.3.4 transportChannelCapability |
| |1.1.3.4.1 dl-TransChCapability |
|-0101--- |1.1.3.4.1.1 maxNoBitsReceived |b6400 |
|***b4*** |1.1.3.4.1.2 maxConvCodeBitsReceived |b640 |
...

When a UE wants to leave idle mode and enter connected mode it has to start the RRC Connection Establishment
procedure. During this procedure the UE is sent either to CELL_FACH state or CELL_DCH state. The decision which
of the two states is chosen is done by the RNC.
The first flow shows the transition to state CELL_FACH. The procedure is done in the following way:
1. The UE sends RRC CONNECTION REQUEST on the RACH (CCCH) to the RNC. Inside the message the UE indicates
its identity in the parameter ‚Initial UE ID‘. Furthermore a cause for the request is indicated via the ‚Establishment
Cause‘ information element.
2. When the RNC has made the decision about the state (here CELL_FACH) then it sends RRC CONNECTION SETUP
to the UE on FACH (CCCH). As reference to the RRC CONNECTION REQUEST the ‚Initial UE ID‘ is repeated in this
message. The ‚RRC State Indicator‘ tells the UE to enter CELL_FACH state. To use DCCH/DTCH on RACH and
FACH the UE needs a c-rnti, which is also indicated in this message. As sign for the connected mode the UE also
gets a u-rnti.
3. To confirm the connected mode the UE returns now RRC CONNECTION SETUP COMPLETE. This message is sent
on RACH because the UE is in state CELL_FACH now. The logical channel is DCCH, thus the MAC header for the
transport blocks of this message contains the c-rnti for identification of the UE.

UE RNC
UTRA IDLE Æ CELL_DCH
UTRA IDLE
NAS Trigger
[RACH:CCCH] RLC/RRC TMD RRC Connection Request
pre-defined configuration status indicator = true|false, Initial UE ID, establishment cause,
measured result on RACH
[FACH:CCCH] RLC/RRC UMD RRC Connection Setup

Initial UE ID, new U-RNTI, RRC state indicator = CELL_DCH, capability update requirement,
signalling radio bearer to setup, TrCH to add/reconfigure (signalling DCH), uplink and downlink
physical resources
DPCH and DPDCH/DPCCH
synchronisation
[DCH:DCCH] RLC/RRC AMD RRC Connection Setup Complete

STARTCS, STARTPS, UE radio access capability, inter-RAT UE radio access capability
[DCH:DCCH] RLC/- STATUS
Acknowledgement
CELL_DCH

When the UE enters CELL_DCH instead of CELL_FACH the basic flow of messages is the same. The first difference is to
be seen in the RRC CONNECTION SETUP message. The ‚RRC State Indicator‘ is now set to CELL_DCH and thus there is
no c-rnti to be allocated for the UE. Rather the physical layer will identify the UE in CELL_DCH state, the MAC layer will
not perform layer 2 identification.
Of course the RRC CONNECTION SETUP COMPLETE message will now be sent on DCH (DCCH) instead of RACH.

2.3. RRC Connection Release

UE RNC
CELL_DCH Æ UTRA IDLE
CELL_DCH
[DCH:DCCH] RLC/RRC UMD RRC Connection Release
N308, release cause
• normal event
• unspecified
• pre-emptive release
• congestion
• re-establishment reject
• user inactivity
• directed signalling connection re-establishment
[DCH:DCCH] RLC/RRC UMD RRC Connection Release Complete
N308
...
[DCH:DCCH] RLC/RRC UMD RRC Connection Release Complete
UTRA IDLE

UE RNC
CELL_FACH with DCCH Æ UTRA IDLE
CELL_FACH
[FACH:DCCH] RLC/RRC UMD RRC Connection Release
release cause
[RACH:DCCH] RLC/RRC AMD RRC Connection Release Complete
[FACH:DCCH] RLC/- STATUS

Acknowledgement
UTRA IDLE
UE RNC
CELL_FACH without DCCH Æ UTRA IDLE
CELL_FACH
[FACH:CCCH] RLC/RRC UMD RRC Connection Release
U-RNTI, release cause
UTRA IDLE

UE RNC
URA_PCH/CELL_PCH Æ UTRA IDLE
CELL_PCH
or
URA_PCH
[PCH:PCCH] RLC/RRC TMD Paging Type 1

U-RNTI, release indicator = release
UTRA IDLE

To release a UE from connected mode and send it to idle the RRC Connection Release procedure is defined. Depending
on the configuration of the UE the procedure has a different appearance.
When the UE is in state CELL_DCH then the RNC has to send the RRC CONNECTION RELEASE procedure to the UE via
the signalling DCH. Inside the message a cause value indicates the reason for the release. A counter value N308 tells the
UE how often to repeat the RRC CONNECTION RELEASE COMPLETE message on the uplink DCH to confirm the
procedure. After this the UE is in idle mode and the RNC can release all dedicated resources allocated to this UE.
When the UE is in state CELL_FACH with allocated DCCH then the RNC also sends RRC CONNECTION RELEASE to
release the UE. This time there is no counter value N308. Thus the UE sends exactly one RRC CONNECTION RELEASE
COMPLETE message on RACH, then it enters idle mode.
If the UE is in state CELL_FACH but has currently no DCCH (happens after paging in state CELL_PCH or URA_PCH or
after cell reselection) then only the RRC CONNECTION RELEASE message is sent. No completion message follows
afterwards, instead the UE enters directly idle mode (see paging procedures for more information about this).
In UMTS Release 5 a new procedure is introduced. When a UE is in state CELL_PCH or URA_PCH it is possible to page it
with a PAGING TYPE 1 message that contains a release indicator. If this indicator is set to release, then the UE enters
directly idle mode without any further action (NOTE: There is a small inconsistency with the RRC state diagram.)

3. Iu Signalling Connection Handling

3.1. Iu Signalling Connections - General

MSC
c tio n CS Server
g C onne
S ignallin
UE Iu CS-MGW
RRC
Connection
Iu S i
gnall
Serving ing Conn
ectio
RNC n PS
SGSN
S-RNTI
S-RNTI radio
radiomgt.
mgt.
CS-Iu
CS-IuSign.Connection
Sign.Connection
data
data PS-Iu
PS-IuSign.Connection
Sign.Connection

CS Mobility Management States
CMM_Detached
CMM_Detached
CMM_Idle
CMM_Idle CMM_Connected
CMM_Connected
PS Mobility Management States
PMM_Detached
PMM_Detached
PMM_Idle
PMM_Idle PMM_Connected
PMM_Connected

The RRC Connection provides signalling facilities between UE and RNC for radio management tasks. Of course the main
reason to start signalling is to get services from the core network. In other words the UE also needs signalling transfer
capabilities to and from the core network.
In UMTS (like in GSM) the UE has no direct link to the CN, thus the UTRAN has to manage signalling connection towards
the CN for the UE. These connections are called Iu signalling connections. They are implemented by the SCCP protocol
on Iu interface. The RANAP protocol is running in Iu signalling connections.
A connected mode UE can have none, one or two Iu signalling connections. At most one Iu signalling connection can be
set up for a UE to the MSC server and at most one Iu signalling connection can be established to SGSN for a UE. An idle
mode UE cannot have any Iu signalling connection. The reason for the last fact is that it is the serving RNC that has to
manage Iu signalling connections.
Within the core network entities MSC server and SGSN a mobility management state (PMM = Packet Mobility
Management, CMM = Circuit Mobility Management) is maintained for each UE. PMM and CMM states are relatively equal
defined. Both consist of three possible states:
• P/CMM_DETACHED: A UE in state P/CMM_DETACHED is currently not registered for services in the core network
entity.
• P/CMM_CONNECTED: In this state the UE is registered for services in the CN entity and an Iu signalling connection
for this UE exists in the moment. Thus the CN can immediately start signalling towards UE by sending a message within
the appropriate Iu signalling connection. This means that CN triggered paging is not required in this state.
• P/CMM_IDLE: In this state the UE is registered for services in the CN entity, but there is currently no Iu signalling
connection for this UE. Thus before a signalling procedure can be started with the UE the CN must page the UE. This
paging is for the UE the trigger to establish an Iu signalling connection (P/CMM_CONNECTED) state.

3.2. Establishment and Signalling Transfer

Iu Signalling Connection Establishment
SGSN
UE RNC
MSC
Server
CELL_DCH
CELL_FACH
[DCCH] RLC/RRC AMD Initial Direct Transfer

RANAP Initial UE Message
CN domain ID, intra domain NAS node selector, establishment cause,
NAS message, START, measured results on RACH CN domain ID, NAS message, LAI, RAC, …
[DCCH] RLC/-- STATUS

acknowledgement

Uplink NAS Signalling Transfer
SGSN
UE RNC
MSC
Server
CELL_DCH
CELL_FACH
[DCCH] RLC/RRC AMD Uplink Direct Transfer

RANAP Direct Transfer
CN domain ID, NAS message, measured results on RACH
CN domain ID, NAS message, LAI, RAC
Downlink NAS Signalling Transfer

SGSN
UE RNC
MSC
Server
CELL_DCH
CELL_FACH
AMD Downlink Direct Transfer RANAP Direct Transfer

[DCCH] RLC/RRC
CN domain ID, NAS message CN domain ID, NAS message, SAPI

The establishment of Iu signalling connection is triggered by the UE via the INITIAL DIRECT TRANSFER message. This
message indicates which core network domain the connection shall be set up to and a message for this core network is
contained. On the Iu interface the serving RNC issues the RANAP message INITIAL UE MESSAGE is sent to the indicated
core network domain.
Once the Iu signalling connection exists, the UE and the core network can freely exchange NAS signalling with each
other. The serving RNC acts as relay point for the NAS signalling messages.
In case of uplink NAS signalling the UE packs the NAS message in a UPLINK DIRECT TRANSFER message, the RNC relays
the message via RANAP DIRECT TRANSFER to the core network.
For downlink NAS messages the CN has to encapsulate the NAS PDU in a RANAP DIRECT TRANSFER message. The RNC
translates this into the DOWNLINK DIRECT TRANSFER message. The ‚SAPI‘ parameter in the DIRECT TRANSFER
message gives the priority of the NAS message.

3.3. Iu Signalling Connection Release

SGSN
UE RNC
MSC
Server
RANAP Iu Release Command

release cause
RANAP Iu Release Complete
…
IF (last Iu signalling connection to be released)
RRC Connection Release Procedure
ELSE IF (no radio bearer for releasing CN allocated)

[DCCH] RLC/RRC AMD Signalling Connection Release
CN domain ID
ELSE IF (radio bearer for releasing CN allocated)

[DCCH] RLC/RRC AMD Radio Bearer Release
…, signalling connection release indication = CN domain ID, …
[DCCH] RLC/RRC AMD Radio Bearer Release Complete
…

SGSN
UE RNC
MSC
Server
[DCCH] RLC/RRC AMD Signalling Conn. Release Indic.

CN domain ID
RANAP Iu Release Request

release cause = UTRAN generated reason
Handling like in normal Iu signalling connection

release case

The release of Iu signalling connections is managed by the core network via the RANAP Iu Release procedure.
The core network releases an Iu signalling connection via RANAP message IU RELEASE COMMAND. The serving RNC will
respond with IU RELEASE COMPLETE.
Depending on the current UE configuration there are three basic procedures possible on the radio interface:
• RRC Connection Release procedure is triggered (UE is sent to IDLE state),
• UE is informed about Iu signalling connection release via SIGNALLING CONNECTION RELEASE procedure,
• radio bearers are released via RADIO BEARER RELEASE procedure.
Of course none of these procedures is triggered when the UE is no longer in this RNC area.
In some situations the RNC can request the release of the Iu signalling connection from the CN via the RANAP procedure
IU RELEASE REQUEST. The reason for this message might be an RNC internal trigger or the UE has requested the
release by SIGNALLING CONNECTION RELEASE MESSAGE.

4. Security Mode Control

4.1. Ciphering and Integrity Protection

Integrity Protection
Transmitter Receiver
COUNT-I COUNT-I
DIRECTION DIRECTION
IK FRESH IK FRESH
f9
f9(UIA)
(UIA) f9
f9(UIA)
(UIA)
XMAC-I
RRC Message MAC-I RRC Message MAC-I
COUNT-I
RRC(28
RRC HFN HFNbit) (28 bit) RRC SN (4)

DCCH RRC messages can be protected against change of information or message injection by an integrity protection
mechanism. Therefore an algorithm f9 (UIA: UMTS Integrity Algorithm) must be available in UE and RNC. For each DCCH
RRC message this algorithm calculates a message authentication code (MAC-I: Message Authentication Code – Integrity).
This MAC-I is included in the message itself.
At the receiver side the MAC-I is calculated again and cross-checked with the transmitted one.
The algorithm UIA (f9) takes several additional values as input:
• IK (Integrity Key): A UE specific key that is derived from authentication (automatic key agreement).
• DIRECTION: Discriminates between uplink and downlink direction.
• FRESH: An offset value that is allocated for uplink by UE and for downlink by RNC. The UL/DL-FRESH values are
exchanged at set up of signalling radio bearers (RRC CONNECTION SETUP and RRC CONNECTION SETUP COMPLETE).
• COUNT-I: This value is increased with every message that is transmitted. For initialisation of COUNT-I a START value is
negotiated at radio bearer set up time.

Transmitter Ciphering Receiver
COUNT-C COUNT-C
DIRECTION DIRECTION
BEARER LENGTH BEARER LENGTH
CK f8
f8(UEA)
(UEA) CK f8
f8(UIA)
(UIA)
Keystream Keystream
Block Block
Plaintext Ciphertext Plaintext

Block Block Block
XOR XOR
COUNT-C for RLC TM on DCH MAC-d RRC

HFN HFN
(24 bit)(28 bit) CFN (4 bit)
COUNT-C for RLC UM RRC

RLC HFN HFN
(25 bit) (28 bit)RLC SN (7 bit)
COUNT-C for RLC AM RLC HFN (20 bit) RLC SN (12 bit)

Like in GSM also UMTS allows an encryption with a classical stream cipher algorithm.
The algorithm for production of the stream cipher sequence is called UEA (UMTS Encryption Algorithm) or f8. This
algorithm uses several values as input:
• CK (Cipher Key): A UE specific key that is coming from authentication (automatic key agreement).
• BEARER: The radio bearer identity.
• DIRECTION: Distinguishes between uplink and downlink direction.
• LENGTH: Length of the cipher sequence to be produced.
• COUNT-C: Strictly increasing value for each radio frame (RLC transparent mode) or RLC frame (RLC unacknowledged
or acknowledged mode). COUNT-C is initialised with the START values that are exchanged at radio bearer set up time.

4.2. Security Mode Activation

SGSN
UE RNC
MSC
Server
RANAP Security Mode Command
[DCCH] RLC/RRC AMD Security Mode Command. integrity protection info, ciphering info, …
CN domain ID, security capability, inter-RAT security capability,
ciphering mode info = {start/modify, selected UEA-no., RB activation
time, DPCH activation time}
integrity mode info = {start/modify, selected UIA-no., DL-FRESH, …}

acknowledgement
[DCCH] RLC/RRC AMD Security Mode Complete

integrity check info = {MAC-I, RRC SN for RB2},
uplink integrity protection activation info ={RRC SN for RB1-RB4},
RB ciphering activation time info = {RB-ID, RLC SN}
acknowledgement
RANAP Security Mode Complete
…

|TS 25.331 DCCH-DL (2002-09) (RRC_DCCH_DL) securityModeCommand (= securityModeCommand) |
| |1 integrityCheckInfo |
|**b32*** |1.1 messageAuthenticationCode |'10110100100001111011101010000100'B |
|-0001--- |1.2 rrc-MessageSequenceNumber |1 |
| |2 message |
| |2.1 securityModeCommand |
| |2.1.1 r3 |
| |2.1.1.1 securityModeCommand-r3 |
|***b2*** |2.1.1.1.1 rrc-TransactionIdentifier |0 |
| |2.1.1.1.2 securityCapability |
|**b16*** |2.1.1.1.2.1 cipheringAlgorithmCap |uea1 |
| | |uea0 |
|**b16*** |2.1.1.1.2.2 integrityProtectionAlgorithmCap |uia1 |
| |2.1.1.1.3 integrityProtectionModeInfo |
| |2.1.1.1.3.1 integrityProtectionModeCommand |
| |2.1.1.1.3.1.1 startIntegrityProtection |
|**b32*** |2.1.1.1.3.1.1.1 integrityProtInitNumber |'01000000110110110000111010010001'B |
| |2.1.1.1.3.2 integrityProtectionAlgorithm |uia1 |
|---0---- |2.1.1.1.4 cn-DomainIdentity |cs-domain |
|TS 25.331 DCCH-UL (2002-09) (RRC_DCCH_UL) securityModeComplete (= securityModeComplete) |

| |2 message |
| |2.1 securityModeComplete |
|-----00- |2.1.1 rrc-TransactionIdentifier |0 |
| |2.1.2 ul-IntegProtActivationInfo |
| |2.1.2.1 rrc-MessageSequenceNumberList |
|0000---- |2.1.2.1.1 rRC-MessageSequenceNumber |0 |
|----0000 |2.1.2.1.2 rRC-MessageSequenceNumber |0 |
|----0000 |2.1.2.1.4 rRC-MessageSequenceNumber |0 |

Security functions are activated by the core network via the RANAP procedure Security Mode Control. This procedure is
triggered with the message SECURITY MODE COMMAND. In this message the CN provides IK and CK to the RNC as well
as a list of permitted UIA and UEA.
The serving RNC has to select an UIA and an UEA that is supported by UE and RNC and is permitted by the CN. Then the
security functions are activated by the RRC message SECURITY MODE COMMAND. In it one can find the selected
algorithms.
When the UE is able to activate the requested algorithms it returns SECURITY MODE COMPLETE. The same message but
from RANAP protocol is also returned to the core network.

5. Paging

5. Paging
5.1. UTRAN Paging Types

UTRAN Paging
Paging Originator
CN
CNoriginated
originated Request for Iu signalling connection
UTRAN
UTRANoriginated
originated Request for UE to enter CELL_FACH and
perform Cell Update procedure
Paging Type
Paging
PagingType
Type11 PCCH on PCH; may be used to page up to 8 UE
Paging
PagingType
Type22 DCCH on DCH or FACH

Paging in UMTS can come from two different types of source – the paging originator:
• CN originated paging: The CN triggers paging whenever a downlink signalling message shall be sent, but currently
there is no Iu signalling connection for this UE at the CN domain of interest available (P/CMM_DETACHED state). Thus
CN originated paging is a request for an Iu signalling connection.
• UTRAN originated paging: The serving RNC has to trigger a paging whenever the UE is in state CELL_PCH or
URA_PCH and a downlink message shall be sent to the UE. This paging shall force the UE to enter state CELL_FACH and
perform a Cell Update procedure.
A problem for UTRAN is the question on which channel to send the paging message. The RRC protocol provides two
options:
• Paging Type 1: The RRC message PAGING TYPE 1 is always sent on the PCH. Thus it can be used for UE in state
Idle, CELL_PCH or URA_PCH. The PAGING TYPE 1 message can be used to page up to 8 UE in one single message.
Furthermore the PAGING TYPE 1 message can also be used to indicate change of BCCH (BCCH Modification) or to
release a UE from state CELL_PCH or URA_PCH to idle.
• Paging Type 2: The message PAGING TYPE 2 is sent on either DCH or FACH. Thus it is the choice for UE in state
CELL_DCH or CELL_FACH. Note that PAGING TYPE 2 is a dedicated control channel (DCCH) message, thus only one UE
can be paged with such a message.

5. Paging
5.2. CN originated paging

SGSN
UE RNC
MSC
Server
RANAP Paging
[P/DCCH] RLC/RRC TMD/AMD Paging Type 1|2 CN domain ID, UE identifier, paging area,
Type 1: Paging Record ={…, CN UE ID or U-RNTI + CN domain ID} paging cause
Type 2: CN domain ID
IF (UE idle)
[CCCH] RLC/RRC TMD RRC Connection Request
[CCCH] RLC/RRC UMD RRC Connection Setup
[DCCH] RLC/RRC AMD RRC Connection Setup Complete
...
[DCCH] RLC/RRC AMD Initial Direct Transfer

CN domain ID, …, RANAP Initial UE Message
NAS-Message = RR:Paging Response|GMM:Service Request
NAS-Message

CN Triggered Paging
|TS 25.331 PCCH (2002-03) (RRC_PCCH) pagingType1 (= pagingType1) |
| |pCCH-Message |
| |1 message |
| |1.1 pagingType1 |
| |1.1.1 pagingRecordList |
| |1.1.1.1 pagingRecord |
| |1.1.1.1.1 cn-Identity |
|110----- |1.1.1.1.1.1 pagingCause |terminatingCauseUnknown |
|---0---- |1.1.1.1.1.2 cn-DomainIdentity |cs-domain |
| |1.1.1.1.1.3 cn-pagedUE-Identity |
|**b32*** |1.1.1.1.1.3.1 tmsi-GSM-MAP |'10110110000000000000000000100001'B |
BCCH Modification Indication

|TS 25.331 PCCH (2002-03) (RRC_PCCH) pagingType1 (= pagingType1) |
| |pCCH-Message |
| |1 message |
| |1.1 pagingType1 |
| |1.1.1 bcch-ModificationInfo |
|-----010 |1.1.1.1 mib-ValueTag |3 |
|***b9*** |1.1.1.2 bcch-ModificationTime |237 |

CN originated paging is obviously triggered by the core network.
MSC server or SGSN send the RANAP message PAGING to the RNC (or to several RNC). Inside the message the UE is
identified (IMSI, TMSI/PTMSI) and the paging area (LAI/RAI) is indicated.
The RNC determines the state of the UE by checking the IMSI. Then either PAGING TYPE 1 or PAGING TYPE 2 is sent on
an appropriate downlink signalling transport channel.
If the UE is in idle state, then it first of all performs a RRC connection setup procedure. If the UE is already in connected
mode, it can skip this part.
Then the UE has to trigger the Iu signalling connection to the requesting core network using the INITIAL DIRECT
TRANSFER message.

5. Paging
5.3. UTRAN originated paging

UE
RNC
CELL_PCH
URA_PCH
[PCCH] RLC/RRC TMD Paging Type 1
Type 1: Paging Record ={…, U-RNTI, RRC connection release indication=No Release|Release Cause}
IF (RRC connection release indication = NoRelease)

[CCCH] RLC/RRC TMD Cell Update
U-RNTI, cell update cause = paging response, …
[CCCH] RLC/RRC UMD Cell Update Confirm
U-RNTI, new U-RNTI, new C-RNTI, RRC state indicator, RB info, TrCH info, PhCH info, …
OR
[CCCH] RLC/RRC UMD RRC Connection Release
U-RNTI, new U-RNTI, new C-RNTI, RRC state indicator, RB info, TrCH info, PhCH info, …
IF (RRC connection release indication = ReleaseCause
UE enters UTRA IDLE mode

In case the paging is originated by the serving RNC there is no ‚CN Domain‘ information element inside the PAGING TYPE
1 message.
The UE will enter state CELL_FACH on reception of an UTRAN originated paging. Then the UE will send a CELL UPDATE
message on RACH (CCCH). Inside it will identify itself with the u-rnti and the parameter ‚cell update cause‘ is set to
„paging response“.
The RNC has now two options. Either it sends the CELL UPDATE CONFIRM message on FACH to the UE and indicates
with this a new state and radio configuration to the UE. Or the RNC sends RRC CONNECTION RELEASE, so that the UE
immediately enters idle mode.
Since UMTS Release 5 the PAGING TYPE 1 message can contain a release indicator. If this is set to „release“, the UE will
not perform the CELL UPDATE, instead it silently enters idle mode without any further interaction with the RNC.

6. Radio Resource Management

6.1. Radio Bearer and Radio Access Bearer Setup

6.1 RB and RAB Setup
SGSN
UE RNC
MSC
Server
RANAP RAB Assignment Request

RAB to setup or Modify, RAB to release
[DCCH] RLC/RRC UMD/AMD Radio Bearer Setup
…, RRC state indicator, signalling radio bearer,
radio access bearers Æ radio bearers (user data)
transport channel to add/delete, physical channel configuration
[DCCH] RLC/RRC AMD Radio Bearer Setup Complete

…
RANAP RAB Assignment Response
successful RAB setup, failed RAB setup

+--------+----------------+--------------------+------------+------------+------------+--------------------------+
|No |Long Time |From |2. Prot |2. MSG |3. Prot |3. MSG |
+--------+----------------+--------------------+------------+------------+------------+--------------------------+
|97 |12:01:15,470,365|NB #2 (DCH #1 DL) |RLC/MAC |FP DATA DCH | | |
|105 |12:01:15,750,364|NB #2 (DCH #1 DL) |RLC reasm. |AM DATA DCH |RRC_DCCH_DL |radioBearerSetup |
|106 |12:01:15,967,569|NB #2 (DCH #1 UL) |RLC/MAC |FP DATA DCH | | |
|109 |12:01:17,327,602|NB #2 (DCH #1 UL) |RLC/MAC |FP DATA DCH | | |
|110 |12:01:17,327,602|NB #2 (DCH #1 UL) |RLC reasm. |AM DATA DCH |RRC_DCCH_UL |radioBearerSetupComplete |

The radio bearers for RRC signalling are usually set up via RRC CONNECTION SETUP. Radio bearers for user data
(especially DTCH/CTCH, but not exclusively) cannot be created with this operation.
The general radio bearer establishment is provided by the RADIO BEARER SETUP procedure implemented by RRC
protocol. This operation can be used to create any kind of radio bearer.
When radio bearers for applications like calls or PDP context shall be created, then the RADIO BEARER SETUP is part of
the radio access bearer establishment triggered by core network. This is done via the RANAP message RAB ASSIGNMENT
REQUEST. This message is used for set up, modification and release of radio access bearers. When a RAB is created or
modified, then the serving RNC calculates how many radio bearers with which settings are required and creates these
radio bearers with the RADIO BEARER SETUP procedure. In it the UE also gets an indication about the radio access
bearers created.
When the new radio bearers are allocated by the UE it will respond with RADIO BEARER SETUP COMPLETE, this will in
the end effect also trigger the RAB ASSIGNMENT RESPONSE message of RANAP back to the core network. This RANAP
message contains parameters that indicate success or failure of the procedure.

6.2. Radio Bearer and Radio Access Bearer Release

6.2. RB and RAB Release
SGSN
UE RNC
MSC
Server
RANAP RAB Assignment Request
[DCCH] RLC/RRC UMD/AMD Radio Bearer Release
RAB to setup or Modify, RAB to release
…, RRC state indicator,
radio access bearers to reconfigure list

…
successful RAB setup, failed RAB setup

[DCCH] RLC/RRC UMD/AMD Radio Bearer Release
…, RRC state indicator, signalling connection release indication = ps|cs
radio access bearers to reconfigure list

…
RAB released

6.2. RB and RAB Release
To release radio bearers the RADIO BEARER RELEASE procedure is provided by RRC protocol. It can be used to release
individual radio bearers or complete radio access bearers with all associated radio bearers and the procedure can also
trigger RRC state changes.
The RNC can in principle release a radio bearer at any time without involution of the core network. If this is really done,
depends on the traffic class of the radio access bearer. Because of delay problems when a radio bearer is to be re-
established, such a Radio Access Bearer independent Radio Bearer management is not done for conversational or
streaming traffic classes. Only background and interactive traffic class radio access bearers allow such a radio bearer
management without involution of CN.
Of course radio bearers have to be released whenever the radio access bearer of the service is terminated. A radio
access bearer can be released in two ways. Either the CN uses again the RANAP procedure RAB ASSIGNMENT REQUEST
with a RAB release indication or the CN releases the Iu signalling connection with IU RELEASE COMMAND. In the latter
case all RAB for this UE of to the releasing core network have to be terminated.
The RNC can upon one of these two procedures release the associated radio bearers with RADIO BEARER RELEASE, the
UE has to respond with RADIO BEARER RELEASE COMPLETE.
Of course there is another final way to release all radio bearers. When the UE is sent to idle state by the RRC message
RRC CONNECTION RELEASE automatically all radio bearers will be terminated. This option is used after the IU RELEASE
COMMAND when no Iu signalling connection is left at the end of the procedure.

6.3. Reconfiguration Operations

UE
RNC
[DCCH] RLC/RRC UMD/AMD Radio Bearer Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator, RB to reconfigure,
transport channels to add/delete/modify, physical channel configuration
[DCCH] RLC/RRC AMD Radio Bearer Reconfiguration Complete

…
[DCCH] RLC/RRC UMD/AMD Transport Channel Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator,
transport channels to add/delete/modify, physical channel configuration
[DCCH] RLC/RRC AMD Transport Channel Reconfiguration Complete

…
[DCCH] RLC/RRC UMD/AMD Physical Channel Reconfiguration

New U-RNTI, new C-RNTI, new DSCH-RNTI, new H-RNTI, RRC state indicator, physical channel configuration
[DCCH] RLC/RRC AMD Physical Channel Reconfiguration Complete

…

Three main operations are provided in the RRC protocol to modify the current radio configuration of a UE. There are
• RADIO BEARER RECONFIGURATION: This allows to modify physical channels (frequency, channelization codes,
scrambling codes), transport channels (transport format sets, transport format combination sets, type of transport
channels) and radio bearers itself.
• TRANSPORT CHANNEL RECONFIGURATION: This procedure allows to modify transport channels and physical
channels. Radio bearers are not affected by this procedure.
• PHYSICAL CHANNEL RECONFIGURATION: This allows to modify physical channels only.
Depending on what shall be modified the serving RNC has to select one of these procedures. If only transport format
combinations shall be allowed or blocked there is another procedure – the TRANSPORT FORMAT COMBINATION
CONTROL operation. This is not really a reconfiguration, because the channels and radio bearers are not modified by it.
The reconfiguration operations can be used to implement hard handover procedures on the same frequency or to other
frequency (inter-frequency handover). They cannot be used for soft handover (see active set update procedure) or to
perform inter-system (inter-RAT) handover (see HANDOVER FROM UTRAN COMMAND).

6.4. Inter-System Change Operations

Handover From UTRAN
UE
other RAT Core Source
(e.g. GSM BSS)
Network RNC
[DCCH] RLC/RRC AMD/UMD UE Capability Enquiry
capability update requirement
[DCCH] RLC/RRC AMD UE Capability Information
UE radio access capability, other RAT capabilities
[DCCH] RLC/RRC AMD/UMD UE Capability Information Confirm
…
other system’s handover message
[DCCH] RLC/RRC AMD Handover From UTRAN Command

RAB to handover list, other RAT system information Æ other system’s handover message, …

SUFI: Acknowledgement
other system’s handover completion

To change from UMTS WCDMA FDD mode to another radio access technology (RAT) there are inter-system (inter-RAT)
procedures defined.
Before a UE can go to another RAT it might be necessary to retrieve the UE’s capabilities with respect to this RAT. If
these RAT capabilities are not available yet at the serving RNC a capability enquiry procedure has to be performed.
During this procedure the RNC request the updated capabilities with UE CAPABILITY ENQUIRY from the UE, which will
respond with a UE CAPABILITY INFO message back to the RNC. This message contains the UE capabilities as requested
before by the UE CAPABILITY ENQUIRY message. The RNC confirms reception of the parameters by sending UE
CAPABILITY INFO CONFIRM.
When the handover to the other RAT shall be started typically a so called S-RNS Relocation procedure (not shown here)
is started. During this relocation the new RAT radio network controller (whatever this might be) sends an appropriate
handover command over the core network to the serving RNC. This will take it and pack it into a HANDOVER FROM
UTRAN COMMAND, which is sent to the UE.
The UE now changes the radio access system and completes the handover procedure in the new radio subsystem.

Handover To UTRAN
UE
other RAT Core Target
(e.g. GSM BSS)
Network RNC
RRC Inter-RAT Handover Info Signalling transfer “Inter-RAT Handover Info”
UE radio access capabilities, pre-defined
configuration status information
RRC Handover To UTRAN Command Signalling transfer “Handover To UTRAN Command”

new U-RNTI, ciphering algorithm,
signalling radio bearer to setup,
RAB and radio bearer to setup,
transport channels to add, physical channel
configuration
[DCCH] RLC/RRC AMD Handover To UTRAN Complete

…


A handover to UTRAN is of course triggered by the other RAT that is used by the UE in the moment.
Before a handover to UTRAN is started usually the new RNC (target RNC) has to get the UE capabilities with respect to
WCDMA FDD mode. Therefore the other RAT requests the UE WCDMA capabilities and forwards it over the CN to the
target RNC. This is embedded in a S-RNC relocation procedure, but this time the RNC is the destination of the procedure,
not the source.
When the target RNC has the UE capabilities it will prepare all resources for it and then create a HANDOVER TO UTRAN
COMMAND. This command is sent over the core network to the radio controller of the other RAT. From here the
message finds its way to the UE. How this is done depends on the other RAT.
Now the UE switches to the WCDMA FDD cell and completes the handover with the message HANDOVER TO UTRAN
COMPLETE.

Network Ordered Cell Change To Other RAT
UE
other RAT Source
(e.g. GSM BSS)
RNC
[DCCH] RLC/RRC AMD Cell Change Order From UTRAN
target cell description, …

update procedures
corresponding to new system

There is a second possibility to change from UTRAN to another radio access technology. This option is especially
designed for UMTS (CELL_FACH) to GSM (Packet Transfer Mode).
Here we use a network ordered cell change to switch away from UMTS to another RAT. The RNC give the CELL CHANGE
ORDER FROM UTRAN command to the UE. In this message the new cell of the other RAT is indicated. The UE now
performs a forced cell reselection to the new cell. All cell reselection criteria for automatic cell reselection are ignored at
the UE.
The remaining part of the procedure consists possibly of an update procedure in the new RAT. This is out of scope of
UTRAN.

6.5. Active Set Management (Soft Handover)

UE
RNC
[DCCH] RLC/RRC AMD/UMD Active Set Update

Radio link addition info Æ {primary CPICH info = primary DL scrambling code,
cell identity, downlink DPCH info, …}
Radio link removal info Æ {primary CPICH info = primary DL scrambling code}
[DCCH] RLC/RRC AMD Active Set Update Complete

Soft handover consists of operations to add, delete and replace cells from the so called active set. The procedure that
provides this functionality is the ACTIVE SET UPDATE.
In an ACTIVE SET UPDATE message the serving RNC indicates the cells that are to be added to the active set and the
cells that must be removed from it. Whenever the UE receives such an ACTIVE SET UPDATE it immediately performs the
requested operations and returns the ACTIVE SET UPDATE COMPLETE message.

7. UE Measurements

7. Measurements
7.1. Measurement Types and Reporting

1) Intra Frequency Measurements
2) Inter Frequency Measurements
3) Inter RAT Measurements

WCDMA physical layer
5) Quality Measurements
6) UE Internal Measurements
TrCH ... TrCH
#0 #N 7) Positioning Measurements
4) Traffic Volume Measurements

RLC/MAC
...
RRC Measurement Control | SIB 3/4+11/12
RNC
RRC
RRC Measurement Report
Periodical
Measurements - Filtering
- Reporting criteria
evaluation

UE Measurements in UTRAN are divided into seven categories as shown on the slide. Every measurement in a UE has to
be created before it starts. Therefore a MEASUREMENT CONTROL message is provided. Additionally SIB 3/4 and SIB
11/12 can create measurements.
Reporting of measurements can be done either periodically or by event trigger. Which reporting mode for a created
measurement is to chosen is indicated in the associated MEASUREMENT CONTROL message. When a trigger for a report
is fulfilled then the UE sends MEASUREMENT REPORT uplink to the RNC which contains the measured results (filtered by
UE) and the indication of the event that triggered the report (only for even triggered reporting).

7. Measurements
7.2. Measurement Control and Report Procedure

UE
RNC
[DCCH] RLC/RRC AMD Measurement Control

measurement identity, measurement control command = setup, release, modify, measurement type,
measurement reporting mode Æ {RLC mode = AMD|UMD, trigger = periodical|event}, …
[DCCH] RLC/RRC AMD/UMD Measurement Report

measurement identity, measurement control command = setup, release, modify, measurement type,
measurement reporting mode Æ {RLC mode = AMD|UMD, trigger = periodical|event}, …

Measurement Control 1(4)
|TS 25.331 DCCH-DL (2002-03) (RRC_DCCH_DL) measurementControl (= measurementControl) |
|dL-DCCH-Message |
| |2 message |
| |2.1 measurementControl |
| |2.1.1 r3 |
| |2.1.1.1 measurementControl-r3 |
|***b2*** |2.1.1.1.1 rrc-TransactionIdentifier |2 |
|-1000--- |2.1.1.1.2 measurementIdentity |9 |
| |2.1.1.1.3 measurementCommand |
| |2.1.1.1.3.1 setup |
| |2.1.1.1.3.1.1 intraFrequencyMeasurement |
| |2.1.1.1.3.1.1.1 intraFreqCellInfoList |
| |2.1.1.1.3.1.1.1.1 removedIntraFreqCellList |
| |2.1.1.1.3.1.1.1.1.1 removeAllIntraFreqCells |0 |
| |2.1.1.1.3.1.1.1.2 newIntraFreqCellList |
| |2.1.1.1.3.1.1.1.2.1 newIntraFreqCell |
|--00000- |2.1.1.1.3.1.1.1.2.1.1 intraFreqCellID |0 |
| |2.1.1.1.3.1.1.1.2.1.2 cellInfo |
|-000000- |2.1.1.1.3.1.1.1.2.1.2.1 cellIndividualOffset |-20 |
| |2.1.1.1.3.1.1.1.2.1.2.2 modeSpecificInfo |
| |2.1.1.1.3.1.1.1.2.1.2.2.1 fdd |
| |2.1.1.1.3.1.1.1.2.1.2.2.1.1 primaryCPICH-Info |
|***b9*** |2.1.1.1.3.1.1.1.2.1.2.2.1.1.1 primaryScramb.. |3 |
|***b6*** |2.1.1.1.3.1.1.1.2.1.2.2.1.2 primaryCPICH-TX.. |30 |
|-1------ |2.1.1.1.3.1.1.1.2.1.2.2.1.3 readSFN-Indicator |1 |
|--0----- |2.1.1.1.3.1.1.1.2.1.2.2.1.4 tx-DiversityInd.. |0 |

|***b5*** |2.1.1.1.3.1.1.1.2.2.1 intraFreqCellID |1 |
| |2.1.1.1.3.1.1.1.2.2.2 cellInfo |
|***b6*** |2.1.1.1.3.1.1.1.2.2.2.1 cellIndividualOffset |-20 |
| |2.1.1.1.3.1.1.1.2.2.2.2.1 fdd |
|***b9*** |2.1.1.1.3.1.1.1.2.2.2.2.1.1.1 primaryScramb.. |5 |
|---1---- |2.1.1.1.3.1.1.1.2.2.2.2.1.3 readSFN-Indicator |1 |
|----0--- |2.1.1.1.3.1.1.1.2.2.2.2.1.4 tx-DiversityInd.. |0 |
|***b5*** |2.1.1.1.3.1.1.1.2.3.1 intraFreqCellID |2 |
| |2.1.1.1.3.1.1.1.2.3.2 cellInfo |
|***b6*** |2.1.1.1.3.1.1.1.2.3.2.1 cellIndividualOffset |-18 |
| |2.1.1.1.3.1.1.1.2.3.2.2.1 fdd |
|***b9*** |2.1.1.1.3.1.1.1.2.3.2.2.1.1.1 primaryScramb.. |1 |
|-----1-- |2.1.1.1.3.1.1.1.2.3.2.2.1.3 readSFN-Indicator |1 |
|------0- |2.1.1.1.3.1.1.1.2.3.2.2.1.4 tx-DiversityInd.. |0 |
| |2.1.1.1.3.1.1.2 intraFreqMeasQuantity |
| |2.1.1.1.3.1.1.2.1 filterCoefficient |fc0 |
| |2.1.1.1.3.1.1.2.2 modeSpecificInfo |
| |2.1.1.1.3.1.1.2.2.1 fdd |
|-00----- |2.1.1.1.3.1.1.2.2.1.1 intraFreqMeasQuantity.. |cpich-Ec-N0 |
| |2.1.1.1.3.1.1.3 intraFreqReportingQuantity |
| |2.1.1.1.3.1.1.3.1 activeSetReportingQuantities |
|----00-- |2.1.1.1.3.1.1.3.1.1 sfn-SFN-OTD-Type |noReport |
|------0- |2.1.1.1.3.1.1.3.1.2 cellIdentity-reportingI.. |0 |
|-------1 |2.1.1.1.3.1.1.3.1.3 cellSynchronisationInfo.. |1 |

| |2.1.1.1.3.1.1.3.1.4 modeSpecificInfo |
| |2.1.1.1.3.1.1.3.1.4.1 fdd |
|-1------ |2.1.1.1.3.1.1.3.1.4.1.1 cpich-Ec-N0-reporti.. |1 |
|--0----- |2.1.1.1.3.1.1.3.1.4.1.2 cpich-RSCP-reportin.. |0 |
|---0---- |2.1.1.1.3.1.1.3.1.4.1.3 pathloss-reportingI.. |0 |
| |2.1.1.1.3.1.1.3.2 monitoredSetReportingQuantities |
|----00-- |2.1.1.1.3.1.1.3.2.1 sfn-SFN-OTD-Type |noReport |
|------0- |2.1.1.1.3.1.1.3.2.2 cellIdentity-reportingI.. |0 |
|-------1 |2.1.1.1.3.1.1.3.2.3 cellSynchronisationInfo.. |1 |
| |2.1.1.1.3.1.1.3.2.4 modeSpecificInfo |
| |2.1.1.1.3.1.1.3.2.4.1 fdd |
|-1------ |2.1.1.1.3.1.1.3.2.4.1.1 cpich-Ec-N0-reporti.. |1 |
|--0----- |2.1.1.1.3.1.1.3.2.4.1.2 cpich-RSCP-reportin.. |0 |
|---0---- |2.1.1.1.3.1.1.3.2.4.1.3 pathloss-reportingI.. |0 |
| |2.1.1.1.3.1.1.4 reportCriteria |
| |2.1.1.1.3.1.1.4.1 intraFreqReportingCriteria |
| |2.1.1.1.3.1.1.4.1.1 eventCriteriaList |
| |2.1.1.1.3.1.1.4.1.1.1 intraFreqEventCriteria |
| |2.1.1.1.3.1.1.4.1.1.1.1 event |
| |2.1.1.1.3.1.1.4.1.1.1.1.1 e1a |
|001----- |2.1.1.1.3.1.1.4.1.1.1.1.1.1 triggeringCondi.. |monitoredSetCellsOnly |
|---00011 |2.1.1.1.3.1.1.4.1.1.1.1.1.2 reportingRange |3 |
|00000--- |2.1.1.1.3.1.1.4.1.1.1.1.1.3 w |0 |
|-----010 |2.1.1.1.3.1.1.4.1.1.1.1.1.4 reportDeactivat.. |t2 |
|111----- |2.1.1.1.3.1.1.4.1.1.1.1.1.5 reportingAmount |ra-Infinity |
|---011-- |2.1.1.1.3.1.1.4.1.1.1.1.1.6 reportingInterval |ri1 |
|***b4*** |2.1.1.1.3.1.1.4.1.1.1.2 hysteresis |0 |
|--0000-- |2.1.1.1.3.1.1.4.1.1.1.3 timeToTrigger |ttt0 |
| |2.1.1.1.3.1.1.4.1.1.1.4 reportingCellStatus |
|--100--- |2.1.1.1.3.1.1.4.1.1.1.4.1 allActiveplusMoni.. |viactCellsPlus5 |

| |2.1.1.1.3.1.1.4.1.1.2.1 event |
| |2.1.1.1.3.1.1.4.1.1.2.1.1 e1b |
|---00--- |2.1.1.1.3.1.1.4.1.1.2.1.1.1 triggeringCondi.. |activeSetCellsOnly |
|***b5*** |2.1.1.1.3.1.1.4.1.1.2.1.1.2 reportingRange |3 |
|--00000- |2.1.1.1.3.1.1.4.1.1.2.1.1.3 w |0 |
|***b4*** |2.1.1.1.3.1.1.4.1.1.2.2 hysteresis |0 |
|---0000- |2.1.1.1.3.1.1.4.1.1.2.3 timeToTrigger |ttt0 |
|---010-- |2.1.1.1.3.1.1.4.1.1.2.4.1 withinActiveSet |e3 |
| |2.1.1.1.3.1.1.4.1.1.3.1 event |
| |2.1.1.1.3.1.1.4.1.1.3.1.1 e1c |
|---011-- |2.1.1.1.3.1.1.4.1.1.3.1.1.1 replacementActi.. |t3 |
|***b3*** |2.1.1.1.3.1.1.4.1.1.3.1.1.2 reportingAmount |ra1 |
|-000---- |2.1.1.1.3.1.1.4.1.1.3.1.1.3 reportingInterval |noPeriodicalreporting |
|----0000 |2.1.1.1.3.1.1.4.1.1.3.2 hysteresis |0 |
|0000---- |2.1.1.1.3.1.1.4.1.1.3.3 timeToTrigger |ttt0 |
|100----- |2.1.1.1.3.1.1.4.1.1.3.4.1 allActiveplusMoni.. |viactCellsPlus5 |
| |2.1.1.1.4 measurementReportingMode |
|---0---- |2.1.1.1.4.1 measurementReportTransferMode |acknowledgedModeRLC |
|----1--- |2.1.1.1.4.2 periodicalOrEventTrigger |eventTrigger |

Measurement Report 1(2)
|TS 25.331 DCCH-UL (2002-03) (RRC_DCCH_UL) measurementReport (= measurementReport) |
|uL-DCCH-Message |
|**b32*** |1.1 messageAuthenticationCode |'11111000011011110101100100001111'B|
| |2 message |
| |2.1 measurementReport |
|***b4*** |2.1.1 measurementIdentity |14 |
| |2.1.2 measuredResults |
| |2.1.2.1 intraFreqMeasuredResultsList |
| |2.1.2.1.1 cellMeasuredResults |
| |2.1.2.1.1.1 cellSynchronisationInfo |
| |2.1.2.1.1.1.1 modeSpecificInfo |
| |2.1.2.1.1.1.1.1 fdd |
| |2.1.2.1.1.1.1.1.1 countC-SFN-Frame-difference |
|0000---- |2.1.2.1.1.1.1.1.1.1 countC-SFN-High |0 |
|***b8*** |2.1.2.1.1.1.1.1.1.2 off |6 |
|**b16*** |2.1.2.1.1.1.1.1.2 tm |16896 |
| |2.1.2.1.1.2 modeSpecificInfo |
| |2.1.2.1.1.2.1 fdd |
| |2.1.2.1.1.2.1.1 primaryCPICH-Info |
|***b9*** |2.1.2.1.1.2.1.1.1 primaryScramblingCode |3 |
|-100101- |2.1.2.1.1.2.1.2 cpich-Ec-N0 |37 |

Measurement Report 2(2)
| |2.1.2.1.2 cellMeasuredResults |
| |2.1.2.1.2.1 cellSynchronisationInfo |
| |2.1.2.1.2.1.1 modeSpecificInfo |
| |2.1.2.1.2.1.1.1 fdd |
| |2.1.2.1.2.1.1.1.1 countC-SFN-Frame-difference |
|----0000 |2.1.2.1.2.1.1.1.1.1 countC-SFN-High |0 |
|00000110 |2.1.2.1.2.1.1.1.1.2 off |6 |
|***B2*** |2.1.2.1.2.1.1.1.2 tm |17372 |
| |2.1.2.1.2.2 modeSpecificInfo |
| |2.1.2.1.2.2.1 fdd |
| |2.1.2.1.2.2.1.1 primaryCPICH-Info |
|***b9*** |2.1.2.1.2.2.1.1.1 primaryScramblingCode |1 |
|***b6*** |2.1.2.1.2.2.1.2 cpich-Ec-N0 |15 |
| |2.1.3 eventResults |
| |2.1.3.1 intraFreqEventResults |
|***b4*** |2.1.3.1.1 eventID |e1a |
| |2.1.3.1.2 cellMeasurementEventResults |
| |2.1.3.1.2.1 fdd |
| |2.1.3.1.2.1.1 primaryCPICH-Info |
|***b9*** |2.1.3.1.2.1.1.1 primaryScramblingCode |3 |

Module 04
Complete Sequences – Use Cases

(Layer 3 signalling)
Version 0.0.1 (02/05/2005)


1. CS Mobility Management

1.1. Location Area Update
• UE is UTRA idle;
• UE is PS detached;
• performs cell reselection
• no services follow after update

1.1. Location Area Update (1)
UE RNC MSC
Server
UTRA_Idle
cell reselection
false
New LAI ?
true
[CCCH] RRC RRC Connection Request
Initial UE ID = IMSI|TMSI+LAI, Est.Cause = registration
[CCCH] RRC RRC Connection Setup

U-RNTI, C-RNTI, signalling radio bearer RB1..RB4, TrCH configuration,
PhCH configuration, radio access capability update requirement
[DCCH] RRC RRC Connection Setup Complete

UE radio access capabilities
CELL_DCH|CELL_FACH
[DCCH] RRC Initial Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Location Updating Request CN domain = cs, LAI, SAI, RNC-ID,
NAS-PDU = Location Updating Request

UE RNC MSC
Server
[DCCH] RRC Downlink Direct Transfer RANAP Direct Transfer

SAPI=0, NAS-PDU = Authentication Req.
CN domain = cs, NAS-PDU = MM-message: Authentication Request
[DCCH] RRC Uplink Direct Transfer

CN domain = cs, NAS-PDU = MM-message: Authentication Response
LAI, SAI, NAS-PDU = Authentication Resp.
[DCCH] RRC Security Mode Command RANAP Security Mode Command

permitted UIA, IK, permitted UEA, CK, …
selected UIA, selected UEA, ciphering activation time, …
[DCCH] RRC Security Mode Complete

…
selected UIA, selected UEA

SAPI=0, NAS-PDU = Location Updating
CN domain = cs, NAS-PDU = MM-message: Location Updating Accept
Accept

CN domain = cs, NAS-PDU = MM-message: TMSI Reallocation Compl.
LAI, SAI, NAS-PDU = TMSI Realloc. Compl.

UE RNC MSC
Server

cause = normal event
[DCCH] RRC RRC Connection Release
cause = normal event, N308 (only for CELL_DCH)
[DCCH] RRC RRC Connection Release Complete
UTRA_Idle

1.2. IMSI Detach (UE Power Off)
• user switches UE off

1.2. IMSI Detach (UE Power Off) (1)
UE RNC MSC
Server
[BCCH] RRC SIB 1

UTRA_Idle
…, ATT, …
Power Off (User)
false
ATT=true Power Off
true
Initial UE ID = IMSI|TMSI+LAI, Est.Cause = detach


CELL_DCH|CELL_FACH

CN domain = cs, NAS-PDU = MM-message: IMSI Detach Indication CN domain = cs, LAI, SAI, RNC-ID,
NAS-PDU = IMSI Detach Indication

1.2. IMSI Detach (UE Power Off) (2)
UE RNC MSC
Server
SCCP Connection Refused

[DCCH] RRC RRC Connection Release
Cause = normal event | unspecified, N308 (only CELL_DCH)
UTRA_Idle
Power Off

2. CS Call Services

2. CS Call Services
2.1. Mobile Originating Call (MOC)
• no PS services running, no other CS services except the MOC
• no handovers during call
• call release by remote party

2.1. Mobile Originating Call (MOC) (1)
UE RNC MSC
Server
UTRA_Idle
call request (User)

Initial UE ID = IMSI|TMSI+LAI,
Est.Cause = originating conversational call


CELL_DCH|CELL_FACH

CN domain = cs, NAS-PDU = MM-message: CM Service Request CN domain = cs, LAI, SAI, RNC-ID,
NAS-PDU = CM Service Request

UE RNC MSC
Server




…

CN domain = cs, NAS-PDU = CC-message: Setup
LAI, SAI, NAS-PDU = Setup
Downlink Direct Transfer RANAP Direct Transfer

[DCCH] RRC
SAPI=0, NAS-PDU = Call Proceeding
CN domain = cs, NAS-PDU = CC-message: Call Proceeding

UE RNC MSC
Server
[DCCH] RRC Radio Bearer Setup RANAP RAB Assignment Request

RABSetupOrModifyItemÆRAB Parameter
RRC state = CELL_DCH, RAB to setupÆ radio bearer to setup,
signalling radio bearer, transport channels to add, physical channel
[DCCH] RRC Radio Bearer Setup Complete

CELL_DCH successful setup

[DCCH] RRC
SAPI=0, NAS-PDU = Alerting
CN domain = cs, NAS-PDU = CC-message: Alerting

SAPI=0, NAS-PDU = Connect
CN domain = cs, NAS-PDU = CC-message: Connect
CN domain = cs, NAS-PDU = CC-message: Connect Ackn.
LAI, SAI, NAS-PDU = Connect Ackn.
call active

UE RNC MSC
Server

[DCCH] RRC
SAPI=0, NAS-PDU = Disconnect
CN domain = cs, NAS-PDU = CC-message: Disconnect
CN domain = cs, NAS-PDU = CC-message: Release
LAI, SAI, NAS-PDU = Release

SAPI=0, NAS-PDU = Release Complete
CN domain = cs, NAS-PDU = CC-message: Release Complete

[DCCH] RRC RRC Connection Release cause = normal event
[DCCH] RRC RRC Connection Release Complete released RAB
UTRA_Idle

2. CS Call Services
2.2. Mobile Terminating Call (MTC)
• no other services running;
• call release by local party

2.2. Mobile Terminating Call (MTC) (1)
UE RNC MSC
Server
UTRA_Idle RANAP Paging

[PCCH] RRC Paging Type 1 CN domain = cs, LAI, IMSI, TMSI, cause
UE-ID = TMSI|IMSI,
cause = terminating conversation call|terminating cause unknown

Initial UE ID = IMSI|TMSI+LAI,
Est.Cause = terminating conversational call|terminating cause unknown

CELL_DCH|CELL_FACH

CN domain = cs, NAS-PDU = MM-message: Paging Response CN domain = cs, LAI, SAI, RNC-ID,
NAS-PDU = Paging Response

UE RNC MSC
Server




…
[DCCH] RRC Downlink Direct Transfer
SAPI=0, NAS-PDU = Setup
CN domain = cs, NAS-PDU = CC-message: Setup

CN domain = cs, NAS-PDU = CC-message: Call Confirmed RANAP Direct Transfer
LAI, SAI, NAS-PDU = Call Confirmed

UE RNC MSC
Server

RRC state = CELL_DCH, RAB to setupÆ radio bearer to setup,

CELL_DCH successful setup

CN domain = cs, NAS-PDU = CC-message: Alerting
LAI, SAI, NAS-PDU = Alerting

CN domain = cs, NAS-PDU = CC-message: Connect
LAI, SAI, NAS-PDU = Connect

SAPI=0, NAS-PDU = Connect Ackn.
CN domain = cs, NAS-PDU = CC-message: Connect Ackn.
call active

UE RNC MSC
Server

CN domain = cs, NAS-PDU = CC-message: Disconnect
LAI, SAI, NAS-PDU = Disconnect

SAPI=0, NAS-PDU = Release
CN domain = cs, NAS-PDU = CC-message: Release
CN domain = cs, NAS-PDU = CC-message: Release Complete
LAI, SAI, NAS-PDU = Release Complete

[DCCH] RRC RRC Connection Release Complete released RAB
UTRA_Idle

3. PS Mobility Management

3.1. PS (GPRS) Attach
• no CS services running

3.1. PS (GPRS) Attach (1)
UE
SGSN
RNC
UTRA_Idle
GPRS activation (User)

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = registration


CELL_DCH|CELL_FACH

CN domain = ps, NAS-PDU = GMM-message: Attach Request RANAP Initial UE Message
CN domain = ps, RAI, SAI, RNC-ID,
NAS-PDU = Attach Request

UE
SGSN
RNC

SAPI=0, NAS-PDU = Authentication And
CN domain = ps,
Ciphering Request
NAS-PDU = GMM-message: Authentication And Ciphering Request
CN domain = ps,
RAI, SAI, NAS-PDU = Authentication And
NAS-PDU = GMM-message: Authentication And Ciphering Response
Ciphering Response


…

SAPI=0, NAS-PDU = Attach Accept
CN domain = ps, NAS-PDU = GMM-message: Attach Accept

UE
RNC SGSN

CN domain = ps, NAS-PDU = GMM-message: Attach Complete
RAI, SAI, NAS-PDU = Attach Complete

UTRA_Idle

3.2. Routing Area Update (IDLE mode update)
• UE is PS attached;
• performs cell reselection

3.2. Routing Area Update (IDLE) (1)
UE RNC
SGSN
UTRA_Idle
cell reselection
false
New RAI ?
true
Initial UE ID = IMSI|PTMSI+RAI|TMSI+LAI, Est.Cause = registration


CELL_FACH|CELL_DCH

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update CN domain = ps, RAI, SAI, RNC-ID,
Request NAS-PDU = Routing Area Update Request

UE
SGSN
RNC

CN domain = ps,
Ciphering Request
CN domain = ps,
Ciphering Response


…

SAPI=0, NAS-PDU = Routing Area Update
CN domain = ps, NAS-PDU = GMM-message: Routing Area Update
Accept
Accept

UE
RNC SGSN

RAI, SAI, NAS-PDU = Routing Area Update
Complete
Complete
RANAP
Iu Release Command
UTRA_Idle

3.3. Routing Area Update (Connected mode update)
• UE is UTRA connected for CS services;

• UE is PS attached without Iu signalling connection, (PMM_IDLE);
• UE performs cell reselection

3.3. Routing Area Update (Connected) (1)
UE RNC
SGSN
UTRA_Connected
CELL_FACH|CELL_DCH
[DCCH] RRC UTRAN Mobility Information

…, new RAI, …
[DCCH] RRC UTRAN Mobility Information Confirm
…

CN domain = ps, NAS-PDU = GMM-message: Routing Area Update CN domain = ps, RAI, SAI, RNC-ID,
Request NAS-PDU = Routing Area Update Request

CN domain = ps,
Ciphering Request
CN domain = ps,
Ciphering Response

3.3. Routing Area Update (Connected) (2)
UE
SGSN
RNC


…

SAPI=0, NAS-PDU = Routing Area Update
Accept
Accept

RAI, SAI, NAS-PDU = Routing Area Update
Complete
Complete
UTRA_Connected

3.4. PS (GPRS) Detach (no UE power off)
• UE is UTRA Idle
• UE is PMM_Idle
• GPRS is to be deactivated by user

3.4. PS (GPRS) Detach (no UE power off) (1)
UE
SGSN
RNC
UTRA_Idle
GPRS deactivation (User)

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = detach


CELL_DCH|CELL_FACH

CN domain = ps, NAS-PDU = GMM-message: Detach Request RANAP Initial UE Message
CN domain = ps, RAI, SAI, RNC-ID,
NAS-PDU = Detach Request

UE
SGSN
RNC

CN domain = ps,
Ciphering Request
CN domain = ps,
Ciphering Response


…

SAPI=0, NAS-PDU = Detach Accept
CN domain = ps, NAS-PDU = GMM-message: Detach Accept

UE
RNC SGSN

UTRA_Idle

4. PDP Context Management

4.1. PDP Context Activation
• UE is UTRA idle,
• UE is PMM_Idle (already registered for GPRS)
• user or application activate PDP context

4.1. PDP Context Activation (1)
UE
SGSN
RNC
UTRA_Idle
PDP Context request (User)

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = originating <xxx> call


CELL_DCH|CELL_FACH

CN domain = ps, NAS-PDU = GMM-message: Service Request RANAP Initial UE Message
(service type = signalling) CN domain = ps, RAI, SAI, RNC-ID,
NAS-PDU = Service Request

UE
SGSN
RNC

CN domain = ps,
Ciphering Request
CN domain = ps,
Ciphering Response


…

CN domain = ps,
RAI, SAI, NAS-PDU = Activate PDP Context
NAS-PDU = SM-message: Activate PDP Context Request
Request

UE RNC
SGSN

RRC state = CELL_DCH/FACH, RAB to setupÆ radio bearer to setup,

successful setup
CELL_DCH|CELL_FACH

SAPI=0, NAS-PDU = Activate PDP Context
CN domain = ps,
Accept
NAS-PDU = SM-message: Activate PDP Context Accept
Packet PDU Transmission

4.2. Service Data for uplink traffic
• UE is UTRA idle and PMM_Idle,

• PDP context is active
• uplink packet data shall be sent

4.2. Service Data for uplink traffic (1)
UE
SGSN
RNC
UTRA_Idle
uplink PDP PDU

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = high priority signalling


CELL_DCH|CELL_FACH

(service type = data) CN domain = ps, RAI, SAI, RNC-ID,

4.2. Service Data for uplink traffic (2)
UE
SGSN
RNC


…


successful setup
CELL_DCH|CELL_FACH

4.3. Service Data for downlink traffic
• UE is UTRA idle and PMM_Idle,

• PDP context is active
• downlink packet data shall be sent

4.3. Service Data for downlink traffic (1)
UE
SGSN
RNC
UTRA_Idle RANAP Paging
[PCCH] RRC Paging Type 1 CN domain = ps, RAI, IMSI, PTMSI, cause
UE-ID = TMSI|IMSI, cause = terminating cause unknown

Initial UE ID = IMSI|TMSI+LAI, Est.Cause = terminating cause unkn.


CELL_DCH|CELL_FACH

(service type = paging response) CN domain = ps, RAI, SAI, RNC-ID,

4.3. Service Data for downlink traffic (2)
UE
SGSN
RNC


…


successful setup
CELL_DCH|CELL_FACH

4.4. PDP Context Deactivation by UE
• UE is UTRA connected and PMM_Connected,

• PDP context is active and will be deactivated,
• ohter PS services are still active

4.4. PDP Context Deactivation (1)
UE
SGSN
RNC
UTRA_Connected
PMM_Connected

CN domain = ps,
RAI, SAI, NAS-PDU = Deact. PDP Context
NAS-PDU = SM-message: Deactivate PDP Context Request
Request
[DCCH] RRC Radio Bearer Release RANAP RAB Assignment Request

RABReleaseItemÆRAB ID
RRC state = XXX, RAB to reconfigure, RB to release, TrCH to reconf.
[DCCH] RRC Radio Bearer Release Complete

RAB data volume

SAPI=0, NAS-PDU = Deact.PDP Context
CN domain = ps,
Accept
NAS-PDU = SM-message: Deactivate PDP Context Accept
UTRA_XXX

5. Radio Management Procedures

5.1. Soft Handover
• UE is UTRA connected in state CELL_DCH,

• soft handover including cell 1, cell 2, cell 3

5.1. Soft Handover (1 – add radio link)
UE
RNC
Active Set
CELL_DCH cell 1
[DCCH] RRC Measurement Control

intra-frequency cell list for cell 1, reporting criteriaÆ events 1A, 1B, 1C
[DCCH] RRC Measurement Report

trigger event = 1A for cell 2, measured results
[DCCH] RRC Active Set Update
cell addition info Æ downlink code information for cell 2
[DCCH] RRC Active Set Update Complete
Active Set
CELL_DCH cell 1, cell 2

intra-frequency cell list for cell 1/2, reporting criteriaÆ events 1A, 1B, 1C

5.1. Soft Handover (2 – replacement)
UE
RNC

trigger event = 1C for cell 3/1, measured results

cell addition info Æ downlink code information for cell 3
cell removal info Æ radio link id cell 1

Active Set
CELL_DCH cell 3, cell 2

intra-frequency cell list for cell 3/2, removal of cell 1’s neighbour cell list,
reporting criteriaÆ events 1A, 1B, 1C

5.1. Soft Handover (3 – radio link deletion)
UE
RNC

trigger event = 1B for cell 2, measured results

cell removal info Æ radio link id cell 2

Active Set
CELL_DCH cell 3

removal of cell 2’s neighbour cell list, reporting criteriaÆ events 1A, 1B, 1C

5.2. Packet Radio Bearer Management
• UE is UTRA connected and PMM_Connected,

• PDP context is active and RAB exists for it

5.2. Packet Radio Bearer Management (1)
UE
SGSN
RNC
CELL_DCH|CELL_FACH
RB Inactivity Timer
[DCCH] RRC Radio Bearer Release Expiry of all

Inactivity Timers
RRC state = CELL_PCH/URA_PCH, radio bearer identitiy to release
CELL_PCH|URA_PCH
uplink PDP PDU
[CCCH] RRC Cell Update

U-RNTI, cause = uplink data transmission
[CCCH] RRC Cell Update Confirm

U-RNTI, RRC state = CELL_DCH/FACG, radio bearer to set up

UE
SGSN
RNC
CELL_DCH|CELL_FACH

RB Inactivity Timer
[DCCH] RRC Radio Bearer Release Expiry of all

Inactivity Timers
RRC state = CELL_PCH/URA_PCH, radio bearer identitiy to release
CELL_PCH|URA_PCH

UE
SGSN
RNC
[PCCH] RRC Paging Type 1 Packet PDU Transmission

U-RNTI
[CCCH] RRC Cell Update
U-RNTI, cause = paging response
[CCCH] RRC Cell Update Confirm

U-RNTI, RRC state = CELL_DCH/FACG, radio bearer to set up

CELL_DCH|CELL_FACH

RB Inactivity Timer

Umts Call Flows

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Umts Call Flows

Caricato da

Copyright:

Formati disponibili

Module 01

UE-UTRAN Signalling Protocols

Version 0.0.1 (07/02/2005)

1 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

2 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

1.1. Top Level Network Architecture

3 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Non Access Protocols

Access Protocols Access Protocols intra-CN

4 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

5 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

1.2. Network Elements and Interfaces

6 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

8 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

9 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

10 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

1.3. UTRAN/UE Main Functional Protocols Overview

11 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

12 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

13 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

14 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

For the CS services there are:

For PS core network the following protocols are used:

15 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

1.4. UTRAN Protocol Stacks on Iux Interfaces

16 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Control Plane Transport User Plane

PVC PVC PVC PVC PVC

18 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Control Plane User Plane

PVC PVC PVC PVC PVC

19 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

20 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Control Plane Transport Network User Plane

21 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

22 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Control Plane Transport User Plane

23 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

24 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

25 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

2.1. Radio Protocol Architecture

26 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Logical Channels (LogCH)

28 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

2.2. Logical Channel Types and their Usage

29 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

Case UE Identification in RNC

31 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

32 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

2.3. Transport Channel Types and their Usage

33 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

• mapped onto dedicated • mapped onto shared

BCH Broadcast Channel Carries BCCH.

PCH Paging Channel

FACH Forward Access Channel

DSCH Downlink Shared Channel

CPCH Common Packet Channel

HS-DSCH High Speed DSCH

36 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

37 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

38 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth

2.4. Physical Channels and their Usage

39 June 1, 2005 CONFIDENTIAL - DRAFT Alexander Seifarth