RAN - Field - Opt - M3 - Signalling Flows - RU20 - Jan2012

3G RAN Field Optimization
Module 3 – Signalling
RU20
Soc Classification level

1 © Nokia Siemens Networks Presentation / Author / Date
3G RAN Optimisation
• Cluster health checks

• Drive Test KPIs
• Parameter consistency
Cluster Drive Test • Standard Acceptance Report
• Neighbour list
Analysis • Drive Survey Analysis
Preparation verification
• System Performance (RRC
• Uplink interference as a
and RAB phases)
problem indicator
• 3G<>2G Cell reselection

• RF optimisation • Neighbour Planning
RF Optimisation • New Site Integration Inter-System • Handover Process and
and Neighbour
• Neighbour plan Working and compressed mode
Planning
optimisation Optimisation • 3G ISHO service
analysis (AMR and PS)
• GSM ISHO Optimisation
• RRC Establishment
Signalling Parameter • Use of Parameters to
• RAB Establishment
optimise network
Flows • Mobility Optimisation
performance
• Location & Routing
area update
• HSDPA & HSUPA
• HSPA+ features
Objectives
• After this module the delegate shall be able to:

– Describe the signalling flows for AMR calls, PS calls, HSPA calls,
ISHO, SHO, SRNC relocation procedures and Location & Routing
Area update procedures
– Understand the impact of RU20 features on the above topics
– Understand the key pieces of information contained in the messages
– Understand the protocols and transport mechanisms used for the
various messages

Module 3 - Content
• Introduction – Protocol stacks, Dual Iub, IP based interfaces

• AMR call signalling flows – RRC connection setup, Fast L1 Synchronisation, RAB setup
• Common Channel Setup
• CS Video call setup
• Location & Routing Area Update Procedures
• CS call mobility – Inter-system Handover (ISHO)
• PS call signalling – Directed RRC connection setup, GPRS Attach, PDP Context Activation
• PS call – RRC state transitions
• PS call mobility – Cell Change Order in ISHO, SRNC Relocation procedure
• HSDPA call – HSDPA setup, Direct Resource Allocation for HSPA, Fractional DPCH
• HSUPA call – HSPA setup, Selection of 2ms TTI in HSUPA, SRB on HSUPA
• HSPA call mobility – Serving Cell Change, HSPA over Iur
• HSPA+ features – Dual Cell HSDPA, CS Voice over HSPA, LTE Interworking, HSDPA MIMO

UMTS Bearer Services
Non-Access
Radio Access
Stratum
Bearers
Signalling
connection
RRC RRC Iu
connection connection
Stratum
Access
Radio bearer service Iu bearer service
: SAP
UE Uu RAN Iu CN
Protocol Stacks
Communication between the UE, RNC and circuit switched core network (CN) makes
use of
• Uu interface protocol stack
• Iub interface protocol stack
• Iu-CS interface protocol stack
• A interface protocol stack Multimedia
BTS RNC 3G MSC
Gateway
Uu
Iub Iu.cs A
• Protocol stacks include both user and control planes

• The control plane of one protocol stack may make use of the user plane of another
protocol stack e.g. RRC messages which form the control plane of the radio
interface protocol are communicated to and from the BTS using the user plane of
the Iub protocol stack
CS Radio Interface Protocol (RIP) User Plane
Radio Interface Protocol is responsible for setting up, reconfiguring and releasing
radio bearers
The 3G MSC provides connectivity to the circuit switched core and PSTN
The multimedia gateway provides transcoding for
• Speech calls: between AMR and A Law PCM
• Video calls: no transcoding is required i.e. vocoder appears only in the UE
Transparent mode RLC is used between the UE and RNC
AAL2 based ATM is used to transfer user plane data across the Iub and Iu,cs
interfaces
UE Multimedia GW 3G MSC
e.g. e.g.
vocoder RNC vocoder
A Law A Law
RLC-U RLC-U PCM, PCM,
Iu,cs Iu,cs etc etc
MAC Node B MAC
UP UP PSTN
FP FP
AAL2 AAL2 AAL2 AAL2 Link Link

ATM ATM ATM ATM Layer Layer
WCDMA WCDMA
L1 L1 Phy Phy Phy Phy Phy Phy Phy
Soc Classification levelUu Iub Iu,cs A
CS Radio Interface Protocol (RIP) Control Plane
• The radio interface protocol control plane allows RRC signalling between the RNC
and UE
• RRC signalling is communicated across the Iub using the Iub user plane protocol
stack i.e. using Frame protocol and AAL2 based ATM
• Acknowledged or unacknowledged mode RLC is used between the UE and RNC
UE RNC
RRC RRC
RLC-C RLC-C
MAC Node B MAC
FP FP
AAL2 AAL2
ATM ATM
WCDMA WCDMA
L1 L1 Phy Phy
Uu Iub

Iub Protocol stack
The Iub protocol stack has three planes

The radio network control plane uses the NBAP protocol and completes tasks
such as configuring a radio link at a BTS
The transport network control plane uses ALCAP and is responsible for setting
up and tearing down user plane transport bearers
Radio Network Transport
User Plane
Control Plane Network Control
Plane • The user plane uses Frame
NBAP Frame Protocol
Protocol and is responsible for
encapsulating all data to and
from the UE
ALCAP
Q.2630.1
Q.2150.2 • ATM Adaptation Layer 5 (AAL5)
SSCF-UNI SSCF-UNI is used for the control planes
SSCOP SSCOP whereas AAL2 is used for the
AAL5 AAL5 AAL2 user plane
ATM
Physical Layer

Iu-CS Protocol stack
•The Iu-CS protocol stack has three planes

•The radio network control plane uses the RANAP protocol and completes
tasks such as configuring a RAB or assigning Iu-CS resources
•The transport network control plane is responsible for setting up/tearing
down Iu transport bearers
Radio Network Transport
User Plane
Control Plane Network Control
Plane
Iu User Plane • The user plane is responsible
RANAP
Protocol for encapsulating all data to and
from the UE
Q.2630.1
• ATM Adaptation Layer 5 (AAL5)
SCCP Q.2150.1 is used for the control planes
MTP3b MTP3b whereas AAL2 is used for the
SSCF-NNI SSCF-NNI user plane
SSCOP SSCOP
AAL5 AAL5 AAL2
ATM
Physical Layer
PS Radio Interface Protocol (RIP) User Plane
HSDPA PS Core
UE RNC Network
RLC-U RLC-U
Iu,ps Iu,ps
MAC-d Node B MAC-d
UP UP
R99 FP FP
AAL2 AAL2 AAL5 AAL5
ATM ATM ATM ATM

WCDMA WCDMA
L1 L1 Phy Phy Phy Phy
Uu Iub Iu,ps
• MAC-hs in NodeB
• MAC-hs in UE • HARQ
• HARQ
UE PS Core
• Packet scheduling
• Disassembly of RNC Network
• Flow control
transport blocks
• Transport format
• Re-ordering RLC-U
selection
RLC-U
Iu,ps Iu,ps
MAC-d Node B MAC-d
UP UP
MAC-hs MAC-hs FP FP
HSDPA
AAL2 AAL2 AAL5 AAL5
ATM ATM ATM ATM

WCDMA WCDMA
Uu Iub Iu,ps
Soc Classification level Iub can be implemented
11 © Nokia Siemens Networks
over IP protocol
PS Radio Interface Protocol (RIP) User Plane
HSUPA
• MAC-e/es in UE • MAC-hs in NodeB • MAC-hs in RNC

• Multiplexing of • HARQ • ensures in
MAC-d PDUs • Extracting MAC-es sequence delivery
• E-TFC selection PDUs • soft handover
based upon Node • E-DCH scheduling combining
B scheduling and control
• HARQ
PS Core
UE RNC Network
RLC-U RLC-U
MAC-d MAC-d
Iu,ps Iu,ps
Node B MAC-es
MAC-e/es UP UP
MAC-hs FP FP
HSUPA
AAL2 AAL2 AAL5 AAL5
ATM ATM ATM ATM

WCDMA WCDMA
Uu Iub Iu,ps
Iub can be implemented
over IP protocol
Soc Classification level Presentation / Author / Date
Dual Iub
Rel99 RT, NRT, Control plane and O&M is carried over the
ATM Iub over E1s / STM1s
HSPA is carried over Ethernet using Iub over IP
ATM STM-1/
OC3
E1/T1 (TDM Network)
RNC
3G BTS Ethernet
Packet Network Ethernet

Dual Iub
User Plane Stack
User Plane ATM Stack User Plane IP Stack
Iub User Plane Protocol

Iub User Plane Protocol
BFD
UDP ICMPv4
AAL2
IPv4 ARP
ATM
VLAN tag
SDH/PDH Ethernet-MAC
Physical layer Ethernet-Phy
ARP – Address Resolution Protocol

ICMP – Internet Control Message Protocol
BFD – Bidirectional Forwarding Detection

Dual Iub
Control Plane Stack
NBAP Q.AAL
STC
SAAL
ATM
SDH/PDH
Physical layer
SAAL – Signalling ATM Adaptation Layer

STC – Signalling Transport Converter

IP Based Iub
Control plane User plane

IP Based Iu-CS
AAL2

IP Based Iu-PS

IP Based Iur

Module 3 - Content


AMR CS Call Phases
UE BTS DRNC SRNC CN
1. Cell search, BCCH

decoding & RACH access
1
2. RRC Connection Setup 2

3. UE <-> CS-CN signalling 3
4. RAB Set-up 4
5. UE <-> CS-CN signalling 5
6. Service Established 6
7. Branch addition/deletion & active set update 7
8. Service Released 8

Cell Search Procedure 1
Slot synchronisation to a cell
Primary
SCH Frame synchronisation and
identification of the cell code
group
Secondary
SCH Determination of the exact
primary scrambling code used
by the found cell
CPICH
P-CCPCH, (SFN modulo 2)=0 P-CCPCH, (SFN modulo 2)=1
The Primary CCPCH is

detected using the identified
10 ms p-scrambling code  system
and cell specific BCH
information can be read

Random Access Procedure 1
Information on BCCH:
• Preamble scrambling code
• Message Length (10 or 20 ms)
• Available signatures and RACH sub-
channels
• Power Ramp Step (P0)
• Preamble Retransmission Max
• Power Offset (Pp-m)
• Set of Transport Format Parameters
UE
WBTS

RRC Connection Set-up Signalling Flow 2
UE WBTS RNC
RRC: RRC CONNECTION REQUEST (RACH)
Admission
Control
NBAP: RADIO LINK SETUP
REQUEST
NBAP: RADIO LINK SETUP
RESPONSE
ALCAP:
ERQ
ALCAP:
ECF
FP Downlink
Sync
FP Uplink
Sync
RRC: RRC CONNECTION SETUP (FACH)
L1 Sync
NBAP: SYNCH INDICATION
RRC: CONNECTION SETUP COMPLETE (DCH)

RRC Connection Request 2
UE initiates the RRC establishment process by sending the RRC Connection Request message
to the RNC (either in response to a paging request from the network or initiated by high layer
request in the UE)
RRC Connection Request message is sent using unacknowledged mode RLC on the RACH
Contains info such as establishment cause (e.g. OriginatingConversationalCall), CPICH Ec/Io of
current cell and mobile identity (in terms of PTMSI, TMSI, IMSI, RAI, LAI)
• RRC Connection Request

message is sent from the BTS
across the Iub using Frame
Protocol to encapsulate the
transport blocks and send them
UE identity here given by TMSI and LAI via AAL2 based ATM
(transparent mode)
• The BTS measures the one
Establishment Cause
way propagation delay in chips
(resolution is 3 chips) and
inserts into message
CPICH Ec/Io of measured cell

NBAP Radio Link Setup 2
• Once the RNC has received the RRC Connection Request message it sends a Common
NBAP: Radio Link Setup Request to the BTS
• The Common NBAP: Radio Link Setup Request includes uplink and downlink configuration
data for the radio link that the BTS is being requested to support (see next slide)
• The radio link refers only to the communication link between the BTS and UE. It does
not include Iub communication
• The Common NBAP: Radio Link Setup

Request is sent using AAL5 based
ATM within the radio network control
plane belonging to the Iub protocol
stack
• The BTS acknowledges the Common
NBAP: Radio Link Setup Request
message with a Common NBAP:
Radio Link Setup Response message
• The Common NBAP: Radio Link Setup
Response is sent using AAL5 based
ATM within the radio network control
plane belonging to the Iub protocol
Soc Classification level Example NetHawk Iub Log stack
NBAP Radio Link Setup 2
• The Iub time of arrival window start point (toAWS) is 15 ms.

Downlink data frames are expected to arrive after this time. The DL Iub
time of arrival window endpoint (toAWE) is 5 ms prior to the LTOA.
DL frames are expected to arrive before this time.
• The downlink transport format set is defined by being able to transmit
0 or 1 transport blocks of size 148 bits
• The downlink TTI is 40 ms and rate 1/3 convolutional coding is used
with a rate matching attribute of 1 and a 16 CRC
• The uplink transport format set is defined by being able to transmit 0
or 1 transport blocks of size 148 bits
• The uplink TTI is 40 ms and rate 1/3 Convolutional coding is used with
a rate matching attribute of 1 and a 16 CRC
• The cell ID is specified to be ID = 60791
• This radio link is the first radio link to be configured for this UE
• The propagation delay from the UE to the BTS is specified to be 6
chips (actual value = IE*3). This is equal to the value that the BTS
measured from reception of the PRACH RRC Connection Request
message
• The initial downlink transmit power is –18.0 dBm (actual value =
IE/10)
• The maximum DL transmit power is –7.1 dBm (actual value = IE/10)
Soc Classification level • The minimum DL transmit power is –18.0 dBm (actual value = IE/10)
ALCAP Establishment 2
• On receiving the Common NBAP: Radio Link Setup Response
message indicating that the BTS has accepted the request for a
radio link, RNC sends an ALCAP: Establish Request message to
request Iub resources.
• The ALCAP: Establish Request is sent using AAL5 based ATM
within the radio network control plane belonging to the Iub protocol
stack
Message contains;
• AAL type 2 Link Characteristics (ALC) (fixed length 12 octet data field) which
specifies the maximum and average bit rates and SDU size to be used
• Destination and Originating Signalling Association Identifiers (DSAID) and
(OSAID) are defined. These are used for routing across ATM switches
• The Connection Element Identifier (CEID) (5 octets, fixed length) which
includes: Channel ID (CID) being established and path identifier as 107001
The Network Service Access Point (NSAP) address is specified

using a fixed length 20 octets
• Once the BTS has received the ALCAP: Establish Request
message signalling the requirement for an AAL2 ATM link, the BTS
acknowledges by sending an ALCAP: Establish Confirm message
• The ALCAP: Establish Confirm is sent using AAL5 based ATM within
the radio network control plane belonging to the Iub protocol stack

DCH Synchronisation on Iub 2
Used to achieve or restore the synchronisation of the DCH data stream in the
downlink direction – as well as a keep alive procedure in order to maintain activity on
the Iub transport bearer
• The procedure is initiated by the SRNC by sending a DL SYNCHRONISATION frame
protocol control frame towards BTS. This is done over the newly created ATM connection
• The DL SYNCHRONISATION frame protocol control frame indicates the target CFN
• Upon reception of the DL SYNCHRONISATION control frame, the BTS immediately
responds with an uplink SYNCHRONISATION control frame indicating the ToA for the DL
SYNCHRONISATION control frame as well as the CFN indicated in that control frame
• Depending on the received value of ToA, the RNC corrects itself to ensure subsequent TOAs
are within the window defined by the NBAP: Radio Link Setup message

RRC Connection Setup 2
• RNC replies to the UE’s original RRC Connection Request message with an RRC
Connection Setup message which is sent via the BTS using FP to encapsulate the
transport blocks across the Iub via AAL2 based ATM
• The RRC Connection Setup message is sent to UE on FACH (S-CCPCH) using UM RLC
• This message echos the UE identity in terms of the (P)TMSI and the RAI/LAI (The UE is
assigned a new U-RNTI which is used by UTRAN to address the UE)
Message contains information such as;

• Signalling Radio Bearers (SRBs) configuration to be used
• Configuration information on uplink and downlink transport CH’s
• TTI used, SRB TBS size, RLC PDU size
• Convolutional coding rate to be used and CRC size
• DPCCH power offset used for the uplink open loop power control
• Downlink BLER target for outer loop power control
• Power control algorithm and step size to be used
• Downlink primary CPICH scrambling code
RNC can send the RRC Connection Setup message multiple times on the Layer 3
(FACH) depending on whether it receives the RRC Setup Complete message from
the UE within a certain time period (Nokia sends up to 3 RRC Connection Setup
messages, 1st-2nd time gap 100ms, 2nd-3rd time gap 1100ms)
Layer 1 Synchronisation 2
• Once the BTS has relayed the RRC Connection Setup message it starts to transmit the
downlink DPCCH on the radio link which has been configured by the NBAP: Radio Link Setup
Request message
• The transmit power has been computed by Admission Control (AC) and instructed within the
NBAP: Radio Link Setup Request message
• The UE uses the information within the RRC Connection Setup message to indicate which
scrambling code and which channelisation code to search for. The RRC Connection Setup
message also provides timing information so the UE has some knowledge of when to expect
the start of the downlink
UE frame and slot structure
Node B RNC
RRC: RRC Connection Request (RACH)
NBAP: Radio Link Setup Response
ALCAP: Establish Request
ALCAP: Establish Confirm
FP: Downlink Sync
FP: Uplink Sync

RRC: RRC Connection Setup (FACH)
Soc Classification level L1 Synchronisation

• Once UE has identified the precise timing of the downlink DPCCH it

evaluates the quality over the first 40 ms. If the UE judges the quality to
be greater than Qin it sends an CPHY-Sync-IND primitive to higher layers
• After the first 40 ms have been judged the UE evaluates the DPCCH
quality every 10 ms but based upon the previous 40 ms of DPCCH
frames (sliding window)
• Layer 3 of the UE uses to timer T312 (6s) and counter threshold N312 (1)
to determine whether or not the L1 synchronisation has succeeded. Both
T312 and N312 were broadcast to the UE in SIB 1
• T312 was started when UE initiated the establishment of the DPCH i.e.
when the RRC Connection Request message was sent
• Layer 3 of the UE must count N312 CPHY-Sync-IND primitives before
T312 expires to consider the DPCH as established. If T312 expires then
the UE considers the DPCH establishment attempt as a failure

Assuming that N312 CPHY-Sync-IND primitives are received prior to T312 expiring
then the UE starts to transmit its UL DPCCH.
• Layer 1 of the UE continues to compare the downlink DPCCH quality against Qin for
160 ms after achieving the DPCH establishment. After the 160 ms period L1 of the UE is
able to report both CPHY-Sync-IND and CPHY-Out-of-Sync-IND primitives based upon Qin
and Qout respectively. During this phase the DPCCH quality is evaluated every 10 ms but
over the previous 160 ms rather than the previous 40 ms. CRC indications are also used
throughout this phase
•The initial transmit power for the UE is calculated from the offset provided in the
RRC Connection Setup message. The transmit power is then given by (Offset –
CPICH RSCP) as measured by the UE
•The UE transmits pc-Preamble DPCCH radio frames followed by a further SRB-
delay DPCCH radio frames. Both these parameters are specified within the RRC
Connection Setup message
• While the UE has been transmitting these DPCCH radio frames the BTS has been
attempting to achieve uplink synchronisation
• L1 of the BTS generates in-sync primitives whenever it judges itself to have successfully
received a DPCCH frame. If the BTS receives NInSynchInd successive (not necessarily
consecutive) in-sync primitives it sends a Synchronisation Indication message to the RNC to
indicate that the DPCH has been established and that the BTS has moved from the initial
state to the in-sync state
• Example below shown for N312 = 4

• Total delay before UE is able to start transmitting is greater than 70 ms
• Assumes that UE is in good coverage and in-sync primitives are generated on every
occasion
Node B starts transmitting UE starts transmitting
10 ms radio
frames
40 ms window
1st in-sync
UE starts primitive
receiving
40 ms window
Delay while UE
receives RRC 2nd in-sync
Connection Setup primitive
message on the FACH 40 ms window
3rd in-sync
primitive
40 ms window
4th in-sync
Soc Classification level primitive
Fast Layer 1 Synchronisation (RU20 feature) 2
with Post Verification
• Node B starts transmitting the DPCCH or F-DPCH after NBAP Radio Link Setup
• UE starts receiving after decoding the RRC Connection Setup message
• UE RRC layer starts T312 (previously read from SIB1)
• UE L1 achieves downlink chip and frame synchronisation
• UE starts to transmit uplink DPCCH
• Post verification is completed:

• UE L1 collects 40 ms of quality measurements
• generates a CPHY-Sync-IND primitive if quality is sufficiently good
• CPHY-Sync-IND primitive is forwarded to UE RRC layer
• Single CPHY-Sync-IND primitive completes post verification
• If post verification fails, the UE stops transmitting

RRC Connection Setup Complete 2
• Having transmitted the

DPCCH during (pc-Preamble
+ SRB-delay) 14 radio
frames the UE transmits the
RRC Connection Setup
Complete message using
SRB 2 on the newly
established DCH
• DCCH contains the RRC

Connection Setup Complete
message
• Message is sent using

Acknowledged mode RLC
• The message contains the

UE radio access capability

UE<–> CS_CN signalling 3
•Location Update
•Authentication
•Security Mode Setup
•Paging
•Call Setup
MSC /
VLR
U
E
RN MG
C W
WB
TS
UE<–> CS_CN signalling 3
UE RNC CN
RRC Connection Establishment
INITIAL DIRECT TRANSFER (CM Service
Request) SCCP: Connection Request
SCCP: Connection Confirm
Location reporting Control
RANAP: COMMON ID
Security Mode Command
1
Security Mode Complete
OR
2
CM Service Accept
UPLINK DIRECT TRANSFER (Setup, mobile

originated side)
DIRECT TRANSFER (Call

Proceeding)

CM Service Request 3
•Having established the RRC connection the UE is able to send a NAS message to
the CS core
•DCCH contains the RRC: Initial Direct Transfer message (DCCH ->DCH -> DPCH)
•Message is sent using acknowledged mode RLC
•The RRC: Initial Direct Transfer message is received by the RNC and forwarded to
the CS core, across the Iu-CS, using a RANAP: Initial UE Message
•The NAS message (TS 24.008) is not read by the RNC but is forwarded to the
multimedia gateway
•Since the RANAP message is a RANAP: Initial UE Message means, the SCCP layer
includes a SCCP: Connection Request message which is used to establish a
connection orientated signalling link (this does not reserve any resources for the
AMR call itself)
•The SCCP layer of the Iu-CS protocol stack responds to the Connection Request
message with a Connection Confirm message
UE Node B RNC MGW
Initial Direct Transfer (CM Service Request) SCCP: Connection Request

Location Report Control 3
•The CS core sends a RANAP: Location Reporting Control message to the

RNC
•This allows the core network to request information regarding the location of
a particular UE
•The CS core will expect a RANAP: Location Report message in response to
this control message (following call establishment)
•The RANAP: Location Reporting Control message requests the RNC to
provide a location report whenever the UE changes service area
UE Node B RNC MGW

Location Reporting Control

Common ID 3
•The CS core sends a RANAP: Common ID message to the RNC

•This informs the RNC of the UE’s permanent NAS identity i.e. the IMSI. This
is used by the RNC to create a reference between the permanent NAS
identity and the RRC connection.
•The CS core does not expect a response to the RANAP: Common ID
message
UE Node B RNC MGW

Common ID

Security Mode 3
•The CS core then sends a Security Mode Command message to the UE

•The purpose of this procedure is to trigger the start or stop of ciphering or to
command the restart of the ciphering with a new ciphering configuration, for the radio
bearers of one core network domain and for all signalling bearers
•The general structure and contents of the Security Mode Command message are
the same as those used for IMSI attach i.e. ciphering and integrity protection are
initialised for the four SRBs belonging to the UE
•The UE responds to the Security Mode Command message with a Security Mode
Complete message
UE Node B RNC MGW

Common ID

CM Service Accept 3
•The CM Service Accept message is only sent if the security mode procedure is not
used
•If the security mode procedure is used then completion of that procedure is used as
an alternative indication of CM service acceptance. (as stated in 24.008)
•The CM Service Accept message serves only as an acknowledgement and contains
no additional information
UE Node B RNC MGW

Common ID
OR CM Service Accept

Setup 3
•UE sends a NAS Setup message to the CS core which includes the number being
dialled by the UE
•The NAS message is sent to the RNC using an RRC: Uplink Direct Transfer
message and forwarded to the CS Core using a RANAP: Direct Transfer message
•The structure of the NAS message is specified by 24.008 (see below)
03 45 04 03 20 02 80 5E 03 81 06 F2 15 02 03 01
Call Control Capabilities

4 Octets (3 + IEI)
1 bearer supported
PCP support
DTMF support
1 speech bearer supported
Called Party BCD Number
Message Type 5 Octets
1 Octet Unknown type of number
0100 0101 => Setup Message Telephone numbering plan
Number: 602
Protocol discriminator Example structure
½ Octet Bearer Capability of NAS set-up
0011 => Call Control Message 5 Octets message
GSM full rate speech versions 1 and 2
Transaction Identifier GSM standardised coding is used
½ Octet Transfer mode is circuit switched
0000 => message flow 0 Information transfer capability is speech
Call Proceeding 3
•Having received the NAS Setup message the CS core sends the NAS Call
Proceeding message to the UE
•The NAS message is a simple acknowledgement and contains no further
information
•In some scenarios it is possible that the NAS message contains more information
•The NAS message can be interpreted using the message structure definition in TS
24.008
•The Call Proceeding message is sent to the UE using a RANAP: Downlink Direct
Transfer message
UE Node B RNC MGW

Common ID
Setup
Call Proceeding

Facility 3
• Facility message is used to indicate to the UE that a supplementary

service is active. The supplementary service to be invoked and its
associated parameters are specified within the NAS Facility message
UE Node B RNC MGW

Common ID
Setup
Call Proceeding
Facility

RAB Setup 4
UE Node B RNC MGW

Common ID
Setup
Call Proceeding
Facility
RAB Assignment Request
Admission Control
Radio Link Reconfigure Prepare
Radio Link Reconfigure Ready
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
AAL2SIG:ERQ
AAL2SIG:ECF
Radio Link Reconfiguration Commit
Radio Bearer Setup
Radio Bearer Setup Complete
RAB Assignment Response

RANAP: RAB Assignment Request 4
•The CS core initiates the RAB Establishment procedure by sending the

RANAP: RAB Assignment Request message to the RNC
•The RANAP: RAB Assignment Request message requests the RNC to
establish a RAB with a specified set of QoS parameters
•The CS core requests these QoS parameters based upon the UE
subscription and the service being requested
Information in the RAB Assignment request message includes;
• traffic class (i.e. conversational, streaming etc.)
• Maximum and guaranteed bit rates
• Maximum SDU size (used with TTI to define bit rates)
• information of RAB sub flows (SRB and AMR RAB sub flows for Class A, B and C
bits)
•On receipt of the RANAP: RAB Assignment Request Admission Control
(AC) will decide whether the RAB can be admitted

NBAP: Radio Link Reconfiguration 4
•If admission control (AC) procedure within the RNC decides to accept the
RAB request it prepares to reconfigure the radio link at the BTS by sending
the NBAP: Radio Link Reconfigure Prepare message
•This message contains similar information as that specified in the Common
NBAP: Radio Link Set-up message
•Provides information on the calculated TFC (cTFC) based on the individual
transport channels defined as well as information on each transport channel
•The NBAP: Radio Link Reconfigure Prepare message has not changed the
uplink SIR target nor has it changed the downlink DPCCH / DPDCH power
offsets
•The BTS responds to the NBAP: Radio Link Reconfigure Prepare message
with a NBAP: Radio Link Reconfigure Ready message
UE Node B RNC MGW

ALCAP: Establish Request/Confirm (ERQ/ECF) 4
•Having received acknowledgement that the radio link has been prepared for
reconfiguration the RNC assigns additional Iub resources for the speech transport
blocks
•Iub resources are in addition to those that have already been assigned for the SRB
transport blocks
•The Destination Signalling Association Identifier (DSAID) is set to the same identifier
as that used to configure the SRB Iub resources
The Connection Element Identifier (CEID) includes (5 octets, fixed length):
• The SRB and AMR make use of separate CID
• The path identifier is the same identifier as that used to configure the SRB Iub
resources
•The request for AMR Iub resources is acknowledged using the ALCAP: Establish
Confirm message
UE Node B RNC MGW
AAL2SIG:ERQ
AAL2SIG:ECF

DCH Synchronisation on Iub 4
• Once the Iub resources have been allocated for the AMR transport blocks,
DCH synchronisation is achieved by sending downlink and uplink frame
protocol control frames (in the same way as described in the RRC
connection set-up procedure)
• This ensures the AMR transport blocks arrive at the BTS within the window
start and end points
UE Node B RNC MGW

AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync

Iu-CS ALCAP: Establish Request/Confirm 4
•Having allocated transmission resources on the Iub, the RNC sends a request to
assign transmission resources on the Iu-CS
•This is done using the transport network control plane of the Iu-CS protocol stack
•The request for AMR Iu-CS resources is acknowledged using the ALCAP: Establish
Confirm message
•Once the transmission resource allocations have been configured the RNC sends a
NBAP: Radio Link Reconfiguration Commit message to the BTS
UE Node B RNC MGW

AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
AAL2SIG:ERQ
AAL2SIG:ECF

RRC: Radio Bearer Setup & RAB Assignment 4
Response
•Once the NBAP: Radio Link Reconfiguration Commit message has been sent to the
BTS the RNC sends a RRC: Radio Bearer Setup message to the UE
• The activation time is specified in terms of CFN. This is the time at which the radio bearer
setup shall become applicable. This is the same CFN as recorded in the NBAP: Radio Link
Reconfiguration Commit message
• The message provides information for mapping the new radio bearers to the transport
channels
• The calculated transport format combinations (cTFC) are signalled to the UE. These are the
same cTFC as signalled to the BTS in the NBAP: Radio Link Reconfigure Prepare message
• The four transport channels are configured in an identical fashion as was done at the BTS
with the NBAP: Radio Link Reconfigure Prepare message (An AMR Voice call comprises 1
SRB and 3 RAB sub flows for Class A, B and C bits)
• This message also provides information on the configuration of the transport channels (e.g.
DL BLER for SRB and AMR RAB sub flow Class A bits, UL scrambling codes, puncturing
limits, spreading factors, power offsets) and radio link (e.g. downlink primary scrambling
code)
• The UE acknowledges the RRC: Radio Bearer Setup message with a RRC: Radio Bearer
Setup Complete message
•Once the radio bearer establishment has been acknowledged, the RNC indicates to the CS
core that the RAB has been established using the RANAP: RAB Assignment Response
message
UE-CN signalling 5
UE Node B RNC MGW

Common ID
Setup
Call Proceeding
Facility
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
AAL2SIG:ERQ
AAL2SIG:ECF
Radio Bearer Setup
Alerting
Connect
Connect Acknowledge
Call Established
Location Report
Measurement Control

Alerting 5
•Having received the RANAP: RAB Assignment Response message, CS

core sends NAS Alerting message to the UE
•This message is sent to indicate that the called user alerting has been
initiated.
•The Alerting message is sent to the UE using a RANAP: Direct Transfer
message
•The structure of the NAS Alerting message is specified by 24.008
UE Node B RNC MGW

Alerting

Connect/Connect Acknowledge 5
•Having received the Alerting message, the CS core sends the NAS Connect
message to the UE
•This message is sent to indicate call acceptance by the called user
•The Connect message is sent to the UE using a RANAP: Direct Transfer
message
•The structure of the NAS Connect message is specified by 24.008
•The UE acknowledges the NAS Connect message with the NAS Connect
Acknowledge message
At this point the call has been successfully established
UE Node B RNC MGW

Alerting
Connect
Connect Acknowledge

Location Report 6
•The RNC replies to the earlier RANAP: Location Reporting Control

message with the RANAP: Location Report message
•The RANAP: Location Report message is sent to the UE using a RANAP:
Direct Transfer message
•The location report specifies that the service area identity based upon the
PLMN ID, LAC and SAC
UE Node B RNC MGW

Alerting
Connect
Connect Acknowledge
Call Established
Location Report

Measurement Control 6
Once the call has been established the RNC sends an RRC: Measurement Control
message
Prior to receiving this message, the UE uses the measurement control information from
the SIBs
This message is used to specify;
• The neighbour list to be used by the UE
• Intra-frequency neighbour with cell ID 0 is always the serving cell
• Intra-frequency neighbours with cell IDs other than 0 are then specified. The UE uses the cell
ID as a pointer to the location within its neighbour register where the information is stored i.e. if
two neighbours are assigned the same cell ID then one will overwrite the other
• Each neighbour has its scrambling code specified as well as an indication that the SFN should
be read and whether or not transmit diversity is being used
• The Layer 3 UE filter coefficient is also specified
• Specifies measurement quantity to be used for Intra-frequency measurements (e.g. Ec/Io)
• Specifies which cells UE should report on Active + Monitored
• Criteria for reporting events 1a, 1b and 1c are specified
• Informs UE on the transfer mode to be used for Measurement Reports (e.g. acknowledged
mode RLC)
• Specifies whether measurement reports should be event or periodically triggered
Branch Addition / Active Set update 7
UE Node B1 Node B2 RNC MGW
Call Established
Measurement Control
Measurement Report
Admission
Control
NBAP: Radio Link Addition Request
Cell starts
receiving
NBAP: Radio Link Addition Response
ALCAP: Establish Request

ALCAP: Establish Confirm Required when Event 1a
FP: Downlink Sync is for a soft handover
FP: Uplink Sync rather than softer
handover
Cell starts
transmitting Active Set Update
If softer handover then only

L1 SYNC a single set of transport
Active Set Update Complete blocks are forwarded across
the Iub
Measurement Control

RRC: Measurement Report 7
Event 1a
•Once the UE determines that an event 1a (add) has occurred it sends a

measurement report to the RNC. This is done using the RRC: Measurement Report
message
•The UE reports all active set cells plus up to N monitored set cells within the
measurement report. (As specified in the RRC: Measurement Control message)
•The measurement identity reflects that provided within the measurement control
message
•Active set cell measurements are provided as specified within the measurement
control message i.e. synchronisation information and CPICH Ec/Io. The scrambling
code is used to identify the active set cells
•Monitored set cell measurements are provided as specified within the measurement
control message i.e. synchronisation information and CPICH Ec/Io.
•The event 1a is specified to have been triggered by a monitored set cell
UE Node B1 Node B2 RNC MGW
Call Established
Measurement Control
Measurement Report

NBAP: RL Setup/Addition Request 7
RL Setup for Soft HO
RL Addition for Softer
•Assuming the RNC admission control admits the new radio link then it sends an
NBAP: Radio Link Setup Request message to the appropriate BTS (i.e. BTS 2) in the
case of soft handover (For softer handover RNC uses the NBAP: Radio Link Addition
Request
•If the event 1a corresponds to a softer handover then the Iub resources are
already configured and synchronisation already achieved. The BTS will also
already have knowledge of the uplink and downlink physical layer configuration.
•Once the BTS has received the NBAP: Radio Link Addition Request message it
starts to receive using the appropriate uplink configuration
UE Node B1Node B2 RNC MGW
Call Established
Measurement Control
Measurement Report
NBAP: Radio Link Addition Request

NBAP: RL Setup/Addition Request 7
•BTS responds to the NBAP: Radio Link Addition Request with an NBAP: Radio Link
Addition Response
• If the event 1a corresponds to a soft handover then Iub resources must be
configured, synchronisation achieved and the BTS informed of the physical layer
configuration
•L1 of the BTS generates in-sync primitives whenever it judges itself to have
successfully received a DPCCH frame. If the BTS receives NInSynchInd (8)
successive (not necessarily consecutive) in-sync primitives then it sends a
Synchronisation Indication message to the RNC to indicate that the DPCH has been
established and that the BTS has moved from the initial state to the in-sync state
•In the case that the event 1a is for soft handover then Iub resources must be
reserved using the ALCAP: Establish Request and ALCAP: Establish Confirm
messages. Synchronisation must also be achieved using the FP: Downlink Sync and
FP: Uplink Sync messages. The cell then starts transmitting the same transport
blocks as the original cell

RRC: Active Set Update/Complete 7
•The RRC: Active Set Update message is then transmitted from both cells
•UE confirms to RNC that the AS has been updated by sending an RRC: Active Set
Update Complete message
•Once the RNC has received the RRC: Active Set Update Complete message it
updates the neighbour list used by the UE using an RRC: Measurement Control
message
•A list of neighbours to be removed from the neighbour list is specified (referenced
using their cell ID within the neighbour list)
•A list of neighbours to be added to the neighbour list is specified. These neighbours
are referenced using a cell ID. If a neighbour already exists with the same cell ID,
then that neighbour is over written
•The scrambling code of each neighbour to be added is specified and an indication is
made that the SFN of each should be read when measurements are made.
•Once the UE has entered soft handover then reporting events 6f and 6g become
applicable
•These reporting events are configured using a separate measurement control
message

Release of AMR Speech Call 8
UE Node B RNC MGW
Call Established
Direct Transfer (Disconnect)
Direct Transfer (Release)
Direct Transfer (Release Complete)
Iu Release Command
Iu Release Complete
RRC Connection Release
RRC Connection Release Complete
Radio Link Deletion Request
Radio Link Deletion Response
ALCAP: Release Request
ALCAP: Release Response
ALCAP: Release Response
Call Released
•In this example the UE initiates the call release by sending the Disconnect message
to the CS core
•The network acknowledges the Disconnect message with a Release message
•The core network initiates the release of the Iu resources using the Iu Release
Command message
Module 3 - Content


Common Channel Setup (RU10 feature)
Introduction
• RACH and FACH transport channels are used for call setup
• Allocation of RACH and FACH or DCH is based on establishment cause received from
UE (22 causes)
• Available SRB DCH bitrates are 3.4 kbps or 13.6 kbps
• Feature is used for SRB setup and connection setup
• Call setup on CCH is faster than on DCH
• More efficient allocation of UTRAN resources
• less signalling processing power required
• no channel element (CE) required
• no dedicated transport resources on Iub interface
• less spreading code resource used
• RACH and FACH load is continuously monitored in RNC
• Common channel setup increases load to RACH-FACH channels
• Air interface quality (CPICH EcNo) criteria has impact on CCH allocation
• Algorithm checks minimum required EcNo when triggered

Common Channel Setup
Signalling Radio Bearers
• During CCH setup there are 3 Signaling Radio Bearers defined and allocated:
• SRB 1 is RLC Transparent Mode
• SRB 2 is RLC Acknowledged Mode
• Used for RRC messages
• Used for RRC messages carrying NAS information
• During DCH setup there is another (optional) SRB allocated

• Used for RRC messages carrying low priority NAS signaling

Decision Making Process
RNC receives RRC
Connection Request
Setup on CCH preferred for this establishment cause?

RACH and FACH Load ok?
CPICH Ec/Io ok? NO
RRC Idle -> CELL_DCH
Ptx_Total ok?
If Rel99 UE, then Setup on CCH is allowed?
If Rel7 UE, then Setup on HSPA/DCH not preferred? Check Directed RRC
Setup algorithm for
YES appropriate RF carrier
RRC Idle -> CELL_FACH

SRB mapped onto HSPA?
YES NO
SRB on
RACH/FACH SRB on HSPA SRB mapped onto
13.6 kbps DCH?
YES NO
• Four possible outcomes:
• SRB on RACH/FACH SRB on 13.6 kbps
DCH
SRB on 3.4 kbps
DCH
• SRB on HSPA
• SRB on 3.4 kbps DCH • Mapping SRB onto HSPA requires F-DPCH
• SRB on 13.6 kbps DCH to be enabled
Establishment Cause Mapping
• 22-bit mapping coding various establishment reasons
Bit Cause Bit Cause
0 Originating conversational call 11 Inter-RAT cell change order
1 Originating streaming call 12 Registration
2 Originating interactive call 13 Detach
3 Originating background call 14 Originating high priority signalling
4 Originating subscribed traffic call 15 Originating low priority signalling
5 Terminating conversational call 16 Call re-establishment
6 Terminating streaming call 17 Terminating high priority signalling
7 Terminating interactive call 18 Terminating low priority signalling
8 Terminating background call 19 Terminating cause unknown
9 Emergency call (always 0) 20 MBMS reception
10 Inter-RAT cell re-selection 21 MBMS ptp RB request
Access causes in green prefer CCH – Access causes in black prefer DCH or HSPA
DCH bitrate selection
• 22-bit mapping coding various establishment reasons
Bit Cause Bit Cause
0 Originating conversational call 11 Inter-RAT cell change order
1 Originating streaming call 12 Registration
2 Originating interactive call 13 Detach
3 Originating background call 14 Originating high priority signalling
4 Originating subscribed traffic call 15 Originating low priority signalling
5 Terminating conversational call 16 Call re-establishment
6 Terminating streaming call 17 Terminating high priority signalling
7 Terminating interactive call 18 Terminating low priority signalling
8 Terminating background call 19 Terminating cause unknown
9 Emergency call (always 0) 20 MBMS reception
10 Inter-RAT cell re-selection 21 MBMS ptp RB request

Access causes in red use 13.6kbps – Access causes in blue use 3.4 kbps
Module 3 - Content


CS Video Telephony
•The bearer of CS Video Telephony (UDI) is set up on a CS 64kbps data RAB

•3G-324M is the 3GPP version of ITU H-324
•3G-324M data flow is transparent to the network: no transcoding/decoding.

H.324 Signaling Terminal A Terminal B
TerminalCapabilitySet
4 phases in Video Handshaking TerminalCapabilityAck
TerminalCapabilitySet
•TerminalCapabilitySet
message: terminals exchange TerminalCapabilityAck
information about their own MasterSlaveDetermination
terminal system capabilities
•MasterSlaveDetermination: MasterSlaveDeterminationAck
terminals exchange random MasterSlaveDetermination
numbers, to determine the master

MasterSlaveDeterminationAck
and slave terminals
•VideoIndicateReadyToActivate OpenLogicalChannel
: [optional procedure], wait for

video transmission until both UEs OpenLogicalChannelAck
are ready to send. OpenLogicalChannel
•OpenLogicalChannel: logical
channels are opened for OpenLogicalChannelAck
information streams [Audio,

Video, Data]

Module 3 - Content


Location Update and Security Mode Setup
UE WBTS RNC CN
INITIAL DIRECT TRANSFER (Location Update Request)
Authentication Request
Authentication Response
Identity Request
Identity Response
DIRECT TRANSFER (Location Update Accept)
DIRECT TRANSFER (TMSI Reallocaiton Complete)
Iu Release Command
Iu Release Complete
SCCP: Release
RRC: Connection SCCP: Release
Release Complete
RRC: Connection Release
Complete
Complete
Complete
NBAP: Radio Link Deletion
Request
Response
ALCAP: Release
Request
ALCAP: Release
Soc Classification level Confirm
Location Update and Security Mode Setup
Location Update Process

Location Update Request
•Once the UE has established a dedicated communication link with UTRAN via RRC
Connection Establishment, it is in a position to initiate the Location Update procedure
•The UE uses an uplink RRC: Initial Direct Transfer message to encapsulate and
send a Location Updating Request message to the RNC
•The BTS extracts the RRC: Initial Direct Transfer message and encapsulates it
within a DCH Frame Protocol frame
•The RNC extracts the Location Updating Request message and encapsulates it
within a RANAP: Initial UE Message prior to forwarding it to the multimedia gateway
(CN)
•The header to this message informs the CS core of the LAI, SAI and the global RNC
ID. These identify the actual location of the UE rather than the location stored in the
UE’s SIM
UE Node B RNC MGW
RRC Connection Request (RACH)

RRC Connection Setup (FACH)
RRC Connection Setup Complete (DCH)
Location Updating Request (DCH) SCCP: Connection Request

Location update request across Iu-CS
•The SCCP layer of the Iu-CS protocol stack adds a header to the RANAP
message which includes a Connection Request message
•The Connection Request message initiates the establishment of a
connection orientated connection between RNC and MGW
•The SCCP layer of the Iu-cs protocol stack responds to the Connection
Request message with a Connection Confirm message
UE Node B RNC MGW


Authentication Request
•Having received the Location Updating Request message the CS core

responds with an NAS Authentication Request message
•The Authentication Request message is sent to the RNC encapsulated
within a RANAP Direct Transfer message
•The RNC extracts the Authentication Request message and encapsulates it
within an RRC Downlink Direct Transfer message
•The RNC then encapsulates the RRC Downlink Direct Transfer message
within a downlink Frame Protocol data frame prior to forwarding it to the BTS
•The BTS extracts the RRC Downlink Direct Transfer message and forwards
it to the UE
•Message is sent using Acknowledged mode RLC

Authentication Response
•Having received the Authentication Request message the UE responds with

an Authentication Response message
•The Authentication Response message is sent to the BTS encapsulated
within an RRC Uplink Direct Transfer message
•The BTS encapsulates the RRC Uplink Direct Transfer message within an
uplink Frame Protocol data frame prior to forwarding it to the RNC
•The RNC extracts the Authentication Response message and encapsulates
it within a RANAP Direct Transfer message prior to forwarding it to the CS
core
UE Node B RNC MGW

(DCH) Authentication Request
Authentication Response (DCH)

Security Command/Complete
•The CS core sends a Security Mode Command message to the UE

•It is also used to start integrity protection or to modify the integrity protection
configuration for all signalling radio bearers
•The security mode command is sent to the RNC using the Security Mode Command
message of the RANAP protocol
•This message does not include a NAS PDU
•The RNC receives the RANAP: Security Mode Command and subsequently
generates an RRC: Security Mode Command
Complete message
•The RANAP: Security Mode Complete message is not a simple encapsulation of the
message from the UE i.e. it is not a RANAP: Direct Transfer message . It is
generated by the RNC from the RRC: Security Mode Complete message

Identity Request/Response
CS core may request the UE to provide its identity. This is done using the Identity
Request msg.
• CS core sends the Identity Request message encapsulated within a RANAP: Direct Transfer message
• RNC sends the Identity Request message encapsulated within a RRC: Downlink Direct Transfer msg
• UE sends the Identity Response message encapsulated within a RRC: Uplink Direct Transfer message
• RNC sends the Identity Response message encapsulated within a RANAP: Direct Transfer message
UE Node B RNC MGW

Authentication Response (DCH)
(DCH) Security Mode Command
Security Mode Complete (DCH)
(DCH) Identity Request
Identity Response (DCH)

Location Update Accept
•CS core responds to the Location Updating Request with a Location Updating Accept
message
•The Location Updating Accept is sent to the RNC encapsulated within a RANAP:
Direct Transfer message
•RNC extracts the Location Updating Accept message and encapsulates it within an
RRC: Downlink Direct Transfer message. Message is sent using Acknowledged mode
RLC
UE Node B RNC MGW
Authenication Response (DCH)
(DCH) Security Mode Command
Secuirty Mode Complete (DCH)
(DCH) Identity Request
Identity Response (DCH)
(DCH) Location Updating Accept

Release
•Having sent the Location Updating Accept message the CS core initiates the release of the Iu-
cs connection by sending a RANAP: Iu Release Command message to the RNC
•The RANAP message includes only the cause for the release which in this case is a normal
release
•The RNC replies to the RANAP: Iu Release Command message with a RANAP: Iu Release
Complete message
•The RANAP: Iu Release Complete message is relatively empty because it is only clearing a
RANAP signalling connection rather than a RAB connection
•Having released the Iu-cs connection at the RANAP layer, the SCCP layer releases the
underlying connection orientated link
•The SCCP: Released message specifies both the RNC and CS core local references
•Having sent the Iu Release Command Complete message the RNC initiates the release of the
RRC connection by sending an RRC Connection Release message to the UE
•Network instructs the UE to release the RRC connection
•Message is sent using unacknowledged mode RLC
•The UE responds by sending (n308+2) RRC Connection Release Complete messages to the
RNC
•UE informs the network that it is releasing the RRC connection
•Message is sent using unacknowledged mode RLC
Radio Link Deletion
•The Dedicated NBAP: Radio Link Deletion Request is used to remove a

radio link at a BTS
•The Dedicated NBAP: Radio Link Deletion Request specifies the:
• BTS communication context (specifies the UE to which the radio link deletion
refers)
• CRNC communication context (specifies the UE to which the RL deletion refers)
• RL ID for the RL to be deleted (each UE may have multiple radio links at a BTS)
•The Dedicated NBAP: Radio Link Deletion Response is used to remove a
radio link at a BTS

ALCAP Iub Deletion
•Having deleted the radio link, the ALCAP protocol is used to release the Iub
resources
•The ACLAP: Release Request is used to release the Iub resources
•The RNC replies to the ACLAP: Release Request message with a ACLAP:
Release Confirm message

Routing Area / Location Area Update
•The MS is not engaged in a CS connection
Network Mode Mode I Mode II
PS-attached RA update RA update
CS-attached LA update LA update
PS/CS-attached RA update (periodic) Separate LA and RA updates
combined RA update (normal)
•In case of PS/CS-attached in Network Mode I, the MSC-VLR relies on SGSN to

receive periodic RA updates
•If the SGSN detects that the MS is lost, the SGSN detaches the MS
and notifies the MSC-VLR
•For normal LU, combined RA/LA update is performed when
the MS changes locations
•In Network Mode II, the RA update (to SGSN) and LA update
(to MSC-VLR) are performed separately
•LA update is always performed before RA update
•The MS is engaged in a CS connection

•During a CS connection, the network knows that the MS is attached and no
periodic location update is performed
Network Mode of Operation
•In Mode I the Gs interface is present between MSC and SGSN
MSC
Gs
CS Paging
PS Paging
UTRAN SGSN GGSN
•In Mode II the Gs interface is not present between MSC and SGSN
MSC
CS Paging
UTRAN PS Paging SGSN GGSN

Location Update
Signalling
MS BSS/RNC MSC/VLR New MSC/VLR Old HLR

1. Channel assignment
2. Location update request (TMSI, Old LAI)
3. Request subscriber idenity (IMSI/TMSI)
4. Send subscriber identity (IMSI/TMSI)
5. Get Authentication Parameters

6. Authentication Parameters
7. Security procedures
8. Update Location
9. Cancel old location
10. Location cancelling accepted

11. Update acknowledgement
12. Location update accept (new TMSI)
13. Location update complete

RA Update
Signalling
MS BSS New Old New Old
UE UTRAN SGSN SGSN GGSN VLR HLR VLR
1. RA Update Request
2. SGSN Context Request & Response
3. Security Functions
4. SGSN Context Ack
4a. Forward Packets (GPRS only)
Inter-SGSN
RA Update 5. Update PDP Context Request & Response
6. Update Location
7. Cancel Location & Ack
8. Insert Subscriber Data & Ack
9. Update Location Ack
10. RA Update Accept

11. RA Update Complete

Combined LA/RA Update (Gs needed)
Signalling
MS BSS New Old New Old
UE UTRAN SGSN SGSN GGSN VLR HLR VLR
1. RA Update Request
2. SGSN Context Request & Response
3. Security Functions
4. SGSN Context Ack
4a. Forward Packets (GPRS only)
Inter-SGSN
RA Update 5. Update PDP Context Request & Response
6. Update Location
7. Cancel Location & Ack
8. Insert Subscriber Data & Ack
9. Update Location Ack
10. Location Update Request

LA Update
12. Location Update Accept 11. Location Update Procedure
13. RA Update Accept
14. RA Update Complete
15. TMSI08.01.2020
Reallocation Complete

Module 3 - Content


ISHO AMR Call
UE WBTS RNC CN
RCC: Measurement Control
RCC: Measurement Report

NBAP: RL Reconfigure Prepare
Reporting
Event NBAP: RL Reconfigure Ready
Triggered
NBAP: RL Reconfigure Commit
RCC: Physical Channel
Reconfiguration
RCC: Physical Channel Reconfiguration
Complete
NBAP: Compressed Mode
Command
Handover Decision :
BSIC verification
(GSM RSSI)
NBAP: Compressed Mode required
Command
RCC: Measurement Report (BSIC
verified) RANAP: Relocation Required
RANAP: Relocation Command
RCC: Handover From UTRAN
Command RANAP: Iu Release Command
RANAP: Iu Release Complete
Request
Response
Measurement Report
Once UE identifies that one of the trigger mechanisms for

ISHO (e.g. Event 1F, Ec/Io) has exceeded the relevant
threshold (< -15dB), it sends an RRC: Measurement Report
to the RNC

Radio Link Reconfiguration
•On receiving the RRC: Measurement Report the RNC uses the NBAP: RL
Reconfiguration Prepare message to inform the BTS of how its existing radio link will
need to be reconfigured to support the compressed mode operation
•The NBAP: RL Reconfiguration Prepare message informs the BTS about the
compressed mode method to be used together with the various timing parameters,
e.g. the position of the compressed mode transmission gap within a radio frame,
duration of the transmission gap and frequency of transmission gaps (Different
parameters can be configured depending on the compressed mode purpose, e.g.
RSSI measurements or BSIC verification)
•The BTS through uses the NBAP: RL Reconfiguration Ready message to inform the
RNC that it received the necessary changes. At this point the BTS has not
implemented the changes
•RNC sends the NBAP: RL Reconfiguration Commit message to the BTS informing it
of the connection frame number (CFN) during which it must apply the new radio link
configuration
•Having reconfigured the radio link at the BTS, the RNC sends an RRC: Physical
Channel Reconfiguration message to the UE. This message informs the UE of the
necessary changes to the existing radio links as well as informing the UE of the CM
pattern that will be used (e.g. Transmission Gap Pattern Sequence Indicator)

Physical Channel Reconfiguration
•Having prepared the BTS for the

radio link reconfiguration, the RNC
sends an RRC: Physical Channel
Reconfiguration message to the UE.
This message informs the UE of the
CFN when it should be ready to start
compressed mode measurements
together with the compressed mode
method and parameters.
•Once the new configuration has
become active (at the appropriate
CFN) the UE responds with an RRC:
Physical Channel Reconfiguration
Complete message to the RNC.

Compressed Mode Measurements
•The RNC informs the BTS of which compressed mode pattern to activate at
the appropriate CFN using the NBAP: Compressed Mode Command (i.e.
GSM RSSI Measurements)
•The UE is informed of the CFN in the RRC: Measurement Control message
sent by the RNC following the NBAP: Compressed Mode Command. The
RRC: Measurement Control message also contains the 2G neighbour list,
representing the 2G cells which the UE should measure during compressed
mode
•During compressed mode operation the UE informs the RNC of the 2G
measurements it makes using RRC: Measurement Report messages which
are typically sent periodically. The RNC uses these measurements to
determine whether the UE should move to the 2G network
•If the 2G cell with the highest RSSI is on a shared RF carrier the UE is
required to complete the BSIC verification part of the process. The RNC
informs the BTS of this requirement using a second set of NBAP:
Compressed Mode Command and RRC: Measurement Control messages.

Compressed Mode Measurements (GSM RSSI)

Compressed Mode Measurements
BSIC verification

Handover to 2G Network
Once the UE has verified the BSIC measurement using the RRC: Measurement
Report the RNC sends a RANAP: Relocation Required message to the CS-CN and
CS-CN responds with a RANAP: Relocation Command message.
The RNC instructs the UE to move to the 2G cell using the RRC: Handover
Command from UTRAN message.
Information on 2G target cell

Release of 3G resources
•Once the UE has handed over to the 2G network the previously reserved
UTRAN resources must be cleared down
•It is common for the BTS to send the RNC a Radio Link Failure message
before the UTRAN resources are cleared. (This is because the UE has
moved to 2G and the BTS no longer has an uplink signal to maintain
synchronisation with).
•The CN then instructs the RNC to clear the Iu resources using the RANAP:
Iu Release Command. This message is acknowledged by the RNC in the
RANAP: Iu Release Complete, which then proceeds to delete the radio link
at the Node B and the Iu signalling connection. AAL2 signalling is used to
clear the Iub resources for both the user plane and signalling radio bearer.

Module 3 - Content


PS Call Phases
UE BTS DRNC SRNC CN
1. Cell search, BCCH

decoding & RACH access
2. RRC Connection Setup (Directed RRC optional) 2

3. GPRS Attach 3
4. RAB Set-up 4
5. UE <-> PS-CN signalling (PDP context activation Request/Accept) 5
6. Radio Bearer Reconfiguration 6
7. PS Data Session Established
8. State Transitions
9. Branch addition/deletion & active set update
10. PS Data Session Released

Directed RRC Connection Setup 2
•3GPP release 5 or newer UE is directed from non-HSDPA supporting cell to

the cell which supports HSDPA
•3GPP release 99 or release 4 UE is directed from HSDPA supporting cell to

the cell which does not support HSDPA.
UE UTRAN
Frequency 1
RRC: RRC CONNECTION REQUEST (RACH)
Directed RRC Connection Setup

for HSDPA layer
RRC: RRC CONNECTION SETUP (FACH)
Frequency 2
RRC: CONNECTION SETUP COMPLETE (DCH)

Enhanced Directed RRC Connection Setup 2
•Non HSDPA UEs

•Directed away from HSDPA capable cell if
•Load of the target cell not too big (i.e. R99 load balancing back to source cell not
triggered)
•HSDPA UEs
•Directed away from non-HSDPA capable cell if
•Establishment cause indicated by UE allowed in HSDPA layer
•Not too much HS-DSCH users in target cell
•Directed to other HSDPA capable cell if
•Load balancing required
•Establishment cause indicated by UE allowed in HSDPA layer
•HSUPA UEs
•Same rules as for HSDPA UEs, but additionally
•Directed to HSUPA capable cell if possible
•Not directed away from HSUPA capable cell

GPRS Attach 3
•UE performs cell search and RRC Connection Establishment in the similar
way as for an AMR call
•The UE registers with the PS-CN through the GPRS Attach procedure
UE Node B RNC SGSN
RRC Connection
Initial Direct Transfer: GPRS Attach Request (DCH) SCCP: Connection Request
Initial UE message : GPRS Attach Request
Downlink Direct Transfer: Authentication and Ciphering Request (DCH)
Direct Transfer: Authentication and Ciphering Request
Uplink Direct Transfer: Authenication and Ciphering Response (DCH) Direct Transfer: Authentication and Ciphering Response
Security Mode Command (DCH) Security Mode Command

Common ID
Downlink Direct Transfer: Common ID (DCH) Direct Transfer: Identity Request
Uplink Direct Transfer: Identity Response (DCH) Direct Transfer: Identity Response
Downlink Direct Transfer: Location Attach Accept (DCH) Direct Transfer: Attach Accept
Uplink Direct Transfer: Attach Complete (DCH) Direct Transfer: Attach Complete

GPRS Attach Request 3
•The UE has now established a dedicated communication link with UTRAN and is in
a position to send a message to the core network (PS core in this case)
•The UE uses an uplink RRC: Initial Direct Transfer message to encapsulate and
send a GPRS MM : Attach Request message to the RNC
•The BTS extracts the RRC: Initial Direct Transfer message and encapsulates it
within a DCH Frame Protocol frame
•The RNC extracts the Attach Request message and encapsulates it within a
RANAP: Initial UE Message prior to forwarding it to the SGSN
•The SCCP layer of the Iu-PS protocol stack responds to the Connection Request
message with a Connection Confirm message
UE Node B RNC SGSN


Authentication and Ciphering Request 3
•Having received the Attach Request message the PS core responds with an
Authentication and Ciphering Request message
•The Authentication and Ciphering Request message is sent to the RNC
encapsulated within a RANAP Direct Transfer message
•The RNC extracts the Authentication and Ciphering Request message and
encapsulates it within an RRC Downlink Direct Transfer message
•The RNC then encapsulates the RRC Downlink Direct Transfer message within a
downlink Frame Protocol data frame prior to forwarding it to the Node B
•The BTS extracts the RRC Downlink Direct Transfer message and forwards it to the
UE
UE Node B RNC SGSN


Authentication and Ciphering Response 3
•Having received the Authentication and Ciphering Request message the UE

responds with an Authentication and Ciphering Response message
•The Authentication and Ciphering Response message is sent to the BTS
encapsulated within an RRC Uplink Direct Transfer message
•The BTS encapsulates the RRC Uplink Direct Transfer message within an
uplink Frame Protocol data frame prior to forwarding it to the RNC
•The RNC extracts the Authentication and Ciphering Response message
and encapsulates it within a RANAP Direct Transfer message prior to
forwarding it to the PS core
UE Node B RNC SGSN


Security Mode Command 3
•The CS core sends a Security Mode Command message to the UE

•It is also used to start integrity protection or to modify the integrity protection
configuration for all signalling radio bearers
•The security mode command is sent to the RNC using the Security Mode Command
message of the RANAP protocol
•The RNC receives the RANAP: Security Mode Command and subsequently
generates an RRC: Security Mode Command. The message is sent using
Acknowledged mode RLC
Complete message
•The RANAP: Security Mode Complete message is not a simple encapsulation of the
message from the UE i.e. it is not a RANAP: Direct Transfer message . It is
generated by the RNC from the RRC: Security Mode Complete message

Common ID 3
•The purpose of the Common ID procedure is to inform the RNC about the
permanent NAS UE Identity (i.e. IMSI) of a user
•This is used by the RNC e.g. to create a reference between the permanent
NAS UE identity of the user and the RRC connection of that user for UTRAN
paging co-ordination
UE Node B RNC SGSN


Common ID

Identity Request/ Response 3
•PS Core may request the UE to provide its identity using the Identity Request
message
• PS Core sends the Identity Request message encapsulated within a RANAP: Direct Transfer message
• RNC sends the Identity Request message encapsulated within a RRC: Downlink Direct Transfer message
• UE sends the Identity Response message encapsulated within a RRC: Uplink Direct Transfer message
• RNC sends the Identity Response message encapsulated within a RANAP: Direct Transfer message
UE Node B RNC SGSN


Common ID
Attach Accept 3
•The PS core responds to the Attach Request with a Attach Accept message
•The Attach Accept is sent to the RNC encapsulated within a RANAP: Direct Transfer
message
•The RNC extracts the Attach Accept message and encapsulates it within an RRC:
Downlink Direct Transfer message
UE Node B RNC SGSN


Common ID
Attach Complete 3
•The UE core responds to the Attach Accept with a Attach Complete message
•The RNC extracts the Attach Complete message and encapsulates it within a RANAP: Direct
Transfer message
•The Attach Complete is sent to the RNC encapsulated within RRC: Uplink Direct Transfer
message
•There is no Iu release as PS-CN is waiting for additional signalling using the same RRC (e.g.
PDP context Activation)
UE Node B RNC SGSN

Common ID
Uplink Direct Transfer: Attach Complete (DCH)
Direct Transfer: Attach Complete
PDP Context (PS call) 5
UE Node B RNC SGSN
GPRS Attach
Uplink Direct Transfer : Activate PDP context request (DCH) Direct Transfer : Activate PDP context request
RANAP: RAB Assignment Request
RRC: Radio Bearer Setup
Measurement Control
Measurement Control
Downlink Direct Transfer : Activate PDP Context Accept (DCH) Direct Transfer: Activate PDP Context Accept
Call Established

PDP Context Activation Request 5
DCCH contains the RRC: Uplink Direct Transfer message

Message is sent using acknowledged mode RLC
The RRC: Uplink Direct Transfer message is received by the RNC and
forwarded to the PS core using a RANAP: Direct Transfer Message
The most important part in Activate PDP Context Request message are the
requested QoS fields
Typically the UE requests all of the QoS parameters ‘Subscribed’ which
means that the network uses HLR QoS profile to set-up the QoS
UE Node B RNC SGSN
GPRS Attach

PDP Context Activation Request 4
ACT. PDP CONTEXT REQUEST (GPRS SM)
•The most important part in Activate PDP - Transaction identifier: 00h

Network Serv. Access Point Id
- NSAPI 5
Context Request message are the LLC Serv. Access point Id
- SAPI 3
requested QoS fields Quality of Service
- length: 11 (0Bh)
•As can be seen the UE is requesting all - Reliab. class: Subscribed (MS only)
- Delay class: Subscribed
of the QoS parameters ‘Subscribed’ - Precedence class: Subscribed

- Peak throughput: Subscribed
which means that the network uses HLR - Mean throughput: Best effort
- Traffic class: Subscribed
QoS profile to set-up the QoS - Delivery order: Subscribed

- Delivery of erroneous SDUs: Subscribed
- Maximum SDU size: Subscribed maximum SDU size
• Mean throughput is set to ‘best effort’ - Maximum bit rate for uplink: Subscribed (MS only)
- Maximum bit rate for downlink: Subscribed (MS only)
•The requested IP address is requested - Residual BER: Subscribed

- SDU error ratio: Subscribed
- Transfer delay: Subscribed (MS only)
to be dynamic, based on IETF allocated - Traffic handling priority: Subscribed
- Guaranteed bit rate for uplink: Subscribed (MS only)
addresses and IPv4 - Guaranteed bit rate for downlink: Subscribed (MS only)
Packet Data Protocol Address
•Access Point is : 07 67 33 67 67 73 6E - Length: 2 (02h)

- Dynamic PDP addressing is applied
31 0A 73 74 61 74 64 79 6E 68 6C 72 03 - PDP type organisation: IETF allocated address

- PDP type number: IPv4
63 6F 6D which corresponds to the APN Access Point Name

- length: 23 (17h)
set in the UE - value

07 67 33 67 67 73 6E 31 0A 73 74 61 74 64 79 6E 68 6C 72 03 63 6F 6D
Protocol Conf. Options
- length: 33 (21h)
- Configuration protocol: IP PDP type
Password Authentic. Protocol (PAP)
Contents: 01 15 00 0A 04 64 65 6D 6F 00
Internet Protocol Control Protocol (IPCP)
Contents: 01 05 00 10 81 06 00 00 00 00 83 06 00 00 00 00
RAB Assignment Request 4
•Having received the Activate PDP Context Request message the PS core
sends the RANAP: RAB Assignment Request message to the RNC
•The RANAP: RAB Assignment Request message requests the RNC to
establish a RAB with a specified set of QoS parameters
•The PS core requests these QoS parameters based upon the subscription
and the service being requested (as seen from Activate PDP Context
Request message the QoS is based entirely on the subscription)
UE Node B RNC SGSN
GPRS Attach

Radio Bearer Setup/Complete & RAB Assignment 4
Response
•Once the RANAP: RAB Assignment Request message has been received
from PS CN and RNC has resources to setup the 0/0 kbps RB the RNC
sends a RRC: Radio Bearer Setup message to the UE
•The UE acknowledges the RRC: Radio Bearer Setup message with a RRC:
Radio Bearer Setup Complete message
•Once the radio bearer establishment has been acknowledged, the RNC
indicates to the PS core that the RAB has been established using the
RANAP: RAB Assignment Response message
UE Node B RNC SGSN
GPRS Attach

Measurement Control 4
•Once the RAB has been established the RNC sends a measurement control
messages
• For traffic volume measurements (UE internal)
• For intra and inter frequency measurements
•Prior to receiving this message, the UE uses the measurement control information
from the SIBs (inter and intra freq. Measurements – traffic volume measurements are
not performed prior to measurement control)
•Measurement control defines the reporting thresholds also for traffic volume
measurements which are used for the UL capacity requests
UE Node B RNC SGSN
GPRS Attach
Measurement Control
Measurement Control

Activate PDP Context Accept 5
•Once the radio access bearer establishment has been acknowledged,

(measurement control messages can be sent before or after the Activate PDP
Context Accept) the PS CN indicates to the UE that the PDP Context Activation has
been successfully established using the RANAP: Activate PDP Context Accept
message
•RNC receives the Direct Transfer : Activate PDP Context Accept message and
forwards it as Downlink Direct Transfer : Activate PDP Context Accept message to
the UE
UE Node B RNC SGSN
GPRS Attach
Measurement Control
Measurement Control
Call Established

Radio Bearer Reconfiguration 6
UE Node B RNC SGSN
GPRS Attach
Measurement Control
Measurement Control
Call Established
Measurement Report : e4a
NBAP: Radio Link Reconfigure Prepare

Admission Control

AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
RRC: Radio Bearer Reconfiguration (DCH)
RRC: Radio Bearer Reconfiguration Complete (DCH)
Measurement Control

Measurement Report e4a 6
•Once the UE determines that an event 4a has occurred it sends a measurement

report to the RNC. This is done using the RRC: Measurement Report message
•As instructed, the UE sends measurement report when the RLC buffer absolute
payload exceeds 8B
•The measurement identity reflects that provided within the measurement control
message
UE Node B RNC SGSN
GPRS Attach
Measurement Control
Measurement Control
Call Established

Radio Link Reconfigure prepare / ready 6
Assuming that the admission control procedure within the RNC decides to accept the
capacity request from UE, the RNC prepares to reconfigure the radio link at the BTS
by sending the NBAP: Radio Link Reconfigure Prepare message
This includes the parameters to reconfigure the existing SRB transport channel and
the additional PS transport channel (s)
The radio link refers only to the communication link between the BTS and UE. It does
not include Iub communication
The BTS responds to the NBAP: Radio Link Reconfigure Prepare message with a
NBAP: Radio Link Reconfigure Ready message
UE Node B RNC SGSN
Call Established


Iub ALCAP Establish Request/Confirm 6
•Having received acknowledgement that the radio link has been prepared for
reconfiguration the RNC assigns additional Iub resources for the PS
transport blocks
•These Iub resources are in addition to those that have already been
assigned for the SRB transport blocks
•These additional Iub resources are configured with a new Channel ID (CID)
•The request for PS Iub resources is acknowledged using the ALCAP:
Establish Confirm message
UE Node B RNC SGSN
Call Established

AAL2SIG:ERQ
AAL2SIG:ECF

Iub DCH Synchronisation 6
•Once the Iub resources have been allocated for the PS transport blocks,
DCH synchronisation is achieved by sending downlink and uplink frame
protocol control frames
•This process has already been described during the RRC connection setup
procedure for IMSI attach
•The result is timing such that the PS transport blocks arrive at the BTS
within the window start and end points
•Once the transmission resource allocations have been configured the RNC
sends a NBAP: Radio Link Reconfiguration Commit message to the BTS
UE Node B RNC SGSN
Call Established

AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync

Radio Bearer Reconfiguration 6
•Once the RNC has sent the NBAP: Radio Link Reconfiguration Commit message to
the BTS, it follows this up by sending an RRC: Radio Bearer Reconfiguration
•The information contained in this message is largely the same as that sent to the
BTS in the NBAP: Radio Link Reconfigure Prepare
•The UE acknowledges the RRC: Radio Bearer Reconfiguration message with a
RRC: Radio Bearer Reconfiguration Complete message
•RNC sends RRC: Measurement Control message to the UE to stop the UE traffic
volume measurements (as the UL is having max bit rate already)
•The required user bit rate connection is now established and data flow between UE
client
UE and server is open Node B RNC SGSN
Call Established
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync


Module 3 - Content


RRC State transitions for PS call
•When the RNC notices that there is nothing being transmitted between UE and RNC
inactivity timers will start to run and in case of expiry of those timers the UE is moved
to use common channels i.e. cell state transition from Cell_DCH to Cell_FACH
occurs
•In order to save some UE battery power (as in Cell_FACH the UE has to read FACH
channel all the time) in case of further inactivity i.e. no capacity requests from UE or
RNC the UE is moved to Cell_PCH where the UE only listens PCH (paging channel)
• Typical UE power consumptions for UTRAN Connected Mode
different states;
URA_ CELL_
• Cell_DCH ~200-300mW PCH PCH
URA update
Inactivity timer Inactivity
• Cell_FACH ~100-200mw expires or timer
Cell
expires
• URA_PCH/Cell_PCH/Idle <5mw after URA
update
update
or after
Establish DCH cell
update
CELL_ CELL_
DCH Explicit signalling or FACH
inactivity timer
expiration
Release RRCEstablish RRC Release RRC
ConnectionConnection Connection
Idle Mode
DCH to FACH Transition
UE Node B RNC SGSN
GPRS Attach
Call Established

AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync All data is sent and RLC
Radio Link Reconfiguration Commit buffer is empty
RRC: Radio Bearer Reconfiguration Complete (DCH) =>Inactivity timer expires
Measurement Control
Data Flow

RRC: Radio Bearer Reconfiguration Complete (RACH)
Measurement Control (FACH)
NBAP: Radio Link Deletion Request
NBAP: Radio Link Deletion Response

ALCAP: Release Confirm
UE in Cell_FACH, PDP Context Active and GPRS Attached

DCH to FACH transition
•In case the RNC decides to move the UE to Cell_FACH state it sends RRC: Radio
Bearer Reconfiguration
•The UE acknowledges the RRC: Radio Bearer Reconfiguration message with a
RRC: Radio Bearer Reconfiguration Complete message on RACH
•RNC sends RRC: Measurement Control message to the UE to setup the UE traffic
volume measurements for the UE capacity requests (e4a)
•RNC sends NBAP: Radio Link Deletion Request message to the BTS to delete the
dedicated resources from the BTS for the UE moved to the Cell_FACH
•The Dedicated NBAP: Radio Link Deletion Request is used to remove a radio link at
a BTS
•Having deleted the radio link, the ALCAP protocol is used to release the Iub
resources
•The ACLAP: Release Request is used to release the Iub resources
•The RNC replies to the ACLAP: Release Request message with a ACLAP: Release
Confirm message

FACH to DCH transition (1/2)
UE WBTS RNC-NBAP RNC-RRC RNC-L2 RNC-RRM
UE in cell_FACH state
UE has data to RNC has data to
send send
RRC of UE MAC requests DL
requests capacity capacity from RRM
from RRM
Traffic volume
measurements DL capacity request
RRC: Measurement report (RACH) Channel type

selection
UL capacity request
WBTS provides
periodical cell load
information to RRM
NBAP: Radio Resource Indication

RR indication
UL and DL
packet
scheduling
FACH to DCH transition (2/2)
UE WBTS RNC-NBAP RNC-RRC RNC-L2 RNC-RRM
RL setup (NBAP) and AAL2 transmission setup
PS indicates UE
about the granted
capacity
capacity allocation
RRC: Radio Bearer Reconfiguration (FACH)
L1 Sync
NBAP: Synchronisation Indication
sync
indication
L2 configuration
RRC: Radio Bearer Reconfiguration complete (DCH)
UE in cell_DCH state

Module 3 - Content


ISHO PS Call
UE WBTS RNC CN
NBAP: RL Reconfigure Prepare
Reporting
Event NBAP: RL Reconfigure Ready
Triggered NBAP: RL Reconfigure Commit
Complete NBAP: Compressed Mode Command BSIC
verification not
RCC: Measurement Control often required
RCC: Measurement Report for PS
RCC: Cell Change Order from UTRAN RANAP: SRNC Context Request
Command
UE performs LAU to
2G SGSN followed by RANAP: SRNC Context Response
RAU Request RANAP: SRNC Data Forwarding
Command
Data is forwarded to 2G SGSN (from 3G SGSN) until UE
location is updated and data is sent directly to 2G SGSN
NBAP: Radio Link Failure RANAP: Iu Release Command

RANAP: Iu Release Complete
NBAP: Radio Link Deletion Request
NBAP: Radio Link Deletion Response
AAL2: Release Request
AAL2: Release Response

SRNS Relocation Procedure
CN CN
CN CN
Iu Iu Iu Iu Iu Iu Iu Iu
RNC RNC RNC RNC RNC RNC RNC RNC

Iur Iur Iur Iur
SRNS “SRNS“
Relocation Anchoring

SRNC Relocation for RT
Source RNC CN Target RNC MS
SRNC Relocation Decision
RANAP:Relocation Required
•SRNC Relocation starts when all the cells of the
x RANAP:Relocation Request
active set belong to a different RNC
Start RelocPrep timer
•In successful case after sending the Relocation
Start RelocOverall timer
required message to CN there will be Relocation
Request sent to target RNC
RANAP:Relocation Request Ack
x
User plane set-up
•In case of ACK from target RNC there will be
Stop RelocPrep timer
RANAP: Relocation Command sent from CN to
RANAP:Relocation Command
x Source RNC
xRNSAP:Relocation Commit •After that the Source RNC sends RANSAP:
Start RelocOverall timer SRNC operation Relocation Commit message over Iur to the
started
Target RNC
RANAP:Relocation Detect
•When target RNC starts SRNC operation and
UP switching detects that the relocation is successful there will
RRC:UTRAN Mobility Information
be RANAP: Relocation Detect message sent

RRC:UTRAN Mobility Information Confirm
Stop RelocOverall
from target RNC to CN
RANAP:Relocation complete
timer
RANAP:Iu Release
x •At the same time RRC: UTRAN Mobility
x Stop RelocOverall timer Information is sent to the UE and after confirm
RANAP:Iu Release Complete
from UE the target RNC informs CN with RANAP:
User plane release
Relocation Complete –message that the
relocation procedure was successful and Iu is
released from source RNC
SRNC Relocation for NRT
x
RANAP:Relocation Required •Procedure is similar with RT but:
•A timer T_Reloc_Inhibit_NRT is
Start RelocPrep timer RANAP:Relocation Request
Start RelocOverall timer

started when the HC of the SRNC
RANAP:Relocation Request Ack
x
User plane set-up
has made a decision to initiate a
Stop RelocPrep timer
SRNC Relocation procedure for
x the MS using a NRT (only)
Start TDataFwd timer
Data tunnel
service in Cell_DCH state
xRNSAP:Relocation Commit •After the reception of the
Start RelocOverall timer SRNC operation
started
RANAP: Relocation Command
RANAP:Relocation Detect message from the CN the Source
UP switching RRC:UTRAN Mobility Information RNC establishes a unidirectional
RRC:UTRAN Mobility Information Confirm data forwarding tunnel with the
Stop RelocOverall timer
RANAP:Relocation complete Target RNC and it starts
x
x RANAP:Iu Release TDataFwd timer.
Stop RelocOverall timer
User plane release

SRNC Relocation for NRT in DCH
Decision
•New RAB assignment requests received from the CN(s) during the SRNC
Relocation procedure (including the inhibition period) are rejected with a cause value
"Relocation Triggered", If a RAB assignment request is received during
T_Reloc_Inhibit_NRT, the SRNC Relocation procedure is started immediately
•If the PS receives a DL or UL capacity request during the T_Reloc_Inhibit_NRT, the
SRNC Relocation procedure is started immediately
•If a soft handover is executed (i.e. a soft handover branch is setup in the SRNC or a
different neighboring RNC than the current DRNC) before expiration of the timer
T_Reloc_Inhibit_NRT, the timer is stopped and the preparation for SRNC Relocation
is terminated
• The handover measurements from the MS using a NRT (only) service are handled
normally, and thus the SHO in this stage is possible
•There is defined a failure counter for cancellations of SRNC Relocation procedures

due to inactivity of NRT (only) services during the relocation signaling
• The exact value of timer T_Reloc_Inhibit_NRT could be set in accordance with a
success rate of the (NRT) relocation procedures

SRNC Relocation for NRT in FACH / PCH
MS BTS1 BTS2 Target RNC Source RNC PS CN
MS is in CELL_FACH, CELL_PCH
or URA_PCH state
If the state of the MS is The MS moves to the

CELL_FACH state (if
CELL_FACH, CELL_PCH not already there)
or(URA_PCH, the SRNC RRC:Cell/URA Update

[ Cell/URA Update Cause, U-RNTI ]
RNSAP:Uplink Signalling
Transfer Indication
Relocation procedure is [ new C-RNTI, D-RNTI, UL message ]
started in the SRNC when an The MS selects a cell controlled

by the target RNC and initiates
RRC makes relocation
decision (SRNC
relocation is supported
RRC:Cell/URA Update a RRC:Cell/URA Update
procedure via the BTS2
by the DRNC and CN)
message is received from RANAP:Relocation Required
the MS via a target RNC and RANAP:Relocation Request
through the RNSAP:UPLINK RANAP:Relocation Request Acknowledge

[May include addresses for DL PDUs towards
the target RNC]
SIGNALLING TRANSFER
User plane establishment
INDICATION message .
[May include addresses for DL PDUs which the
source RNC may forward to the target RNC]
Data Forwarding (if addresses received from CN)
RNSAP:Relocation Commit
RRC:Cell/URA Update Confirm [ D-RNTI ; may include Direct Transfer
messages and RAB Context information]
[ S-RNTI, SRNC-ID, new S-RNTI,
new SRNC-ID, (new C-RNTI) ]
RANAP:Relocation Detect
RRC:UTRAN Mobility Information Confirm
RANAP:Relocation Complete
MS is in CELL_FACH , CELL_PCH or URA_PCH state

In RAN1.5 the target RRC state RANAP:Iu Release Command
of the MS is decided based on
the RRC state information
received from the source RNC.
Resource
Soc Classification level releasing
SRNC Relocation for NRT in FACH / PCH
•The SRNC Relocation procedure is started when RRC:CELL UPDATE or RRC:URA

UPDATE message is received by the source RNC inside RNSAP:UPLINK
SIGNALLING TRANSFER INDICATION message. The cause value ‘Relocation
Desirable for Radio Reasons’ shall be used in RANAP:RELOCATION REQUIRED
message sent to the CN.
•If there is no response from the CN to the RANAP:RELOCATION REQUIRED
message before the RANAP timer TRelocPrep expires, the source RNC cancels the
RANAP:Relocation Preparation procedure by initiating the RANAP:Relocation Cancel
procedure with a cause value 'TRELOCprep expiry'.’
•After this the source RNC may reinitiate the SRNC relocation procedure, or
(preferably) initiate a call re-establishment by sending an RRC:RRC CONNECTION
RELEASE message with a cause value ''Directed Signalling Connection Re-
establishment' to the MS.
•If repeated Cell/URA Update messages are received from the target RNC during the
SRNC relocation procedure, these messages are ignored by the source RNC and
relocation procedure is continued as normally.
•If however, the message with a cause value is ‘RLC unrecoverable error’ is received
(during the SRNC relocation procedure) before the RNSAP:RELOCATION COMMIT
message has been sent to the target RNC, the ongoing relocation procedure is
cancelled with a cause value ‘Failure in the Radio Interface Procedure’ and a RRC
Connection Release message with a cause value ''Directed Signalling Connection
Re-establishment' is sent to the MS.
SRNC Relocation
Relocation Required

The RANAP:RELOCATION
REQUIRED message contains
RANAP:Relocation Required
the following parameters:
RANAP:Relocation Request
Information element Presence Comments

• Message Type M, RANAP
• Relocation Type M, RANAP
• Cause M, RANAP
RANAP cause value Usage
Time Critical Relocation Used in all coverage based relocation initiations
in RAN1.5
Resource Optimisation Relocation Used in cases where all RLs in the active set of
the MS are located in DRNS
Relocation Desirable for Radio Reasons Used in cases where relocation is triggered by a
Cell/URA update received over Iur.
O&M Intervention The source cell is emptied by a forced HO
procedure. Not used in RAN1.5

Module 3 - Content


HSDPA Setup – Channel Type Selection
• High level procedure is the same as that for an NRT DCH

• Selection between DCH and HS-DSCH is then completed when RNC receives
the capacity request
UE Node B RNC SGSN
RRC Establishment
GPRS Attach
0/0 kbps DCH

PDP Context Activation
allocated
RNC completes channel type

selection procedure

Setting Up the HS-DSCH
Cell DCH – HS-DSCH transition
UE Node B RNC SGSN
PDP Established
UE sends measurement report MEASUREMENT REPORT

showing event 4a (buffer levels value UL-DCCH-Message ::=
exceed the set threshold) integrityCheckInfo

messageAuthenticationCode '00011100 11100101 11111001 01001000'B,
Buffer payload is 256B rrc-MessageSequenceNumber 3

message measurementReport :
measurementIdentity 16,
measuredResults trafficVolumeMeasuredResultsList :
rb-Identity 5,
rlc-BuffersPayload pl256
eventResults trafficVolumeEventResults :
ul-transportChannelCausingEvent dch : 1,
trafficVolumeEventIdentity e4a

Radio Link Reconfigure prepare / ready
Assuming that the admission control procedure within the RNC decides to
accept the capacity request from UE, the RNC prepares to reconfigure the
radio link at the BTS by sending the NBAP: Radio Link Reconfigure
Prepare message
This includes HSDPA MAC-d flow information, UE capability Information
(CQI feedback, ACK/NACK, PO etc.). Also information from HSDPA return
channel is included
The BTS responds to the NBAP: Radio Link Reconfigure Prepare message
with a NBAP: Radio Link Reconfigure Ready message
UE Node B RNC
PDP Established

UE Node B RNC
PDP Established
AAL2SIG:ERQ
AAL2SIG:ECF
AAL2SIG:ERQ
AAL2SIG:ECF
First ERQ is the setup of the UL NRT return channel for HSDPA i.e. 64kbps
• BTS WAM/AXC responds back with Establish Confirm if the reservation is
ok also from UL CAC point of view
Second ERQ is for HS-DSCH
• BTS WAM/AXC responds back with Establish Confirm if the reservation is
ok also from UL CAC point of view

UE Node B RNC
PDP Established
RADIO LINK RECONFIGURATION COMMIT
NBAP-PDU
Radio Link Reconfigure Ready initiatingMessage
AAL2SIG:ERQ procedureID
- procedureCode: 30
AAL2SIG:ECF
- ddMode: common
AAL2SIG:ERQ - criticality: ignore
AAL2SIG:ECF - messageDiscriminator: dedicated
FP: Downlink Sync transactionID
- longTransActionId: 66
FP: Uplink Sync
initiatingMessage
FP: Downlink Sync RadioLinkReconfigurationCommit
FP: Uplink Sync protocolIEs
Radio Link Reconfiguration Commit - id: 143
- criticality: ignore
NodeB-CommunicationContextID:
160001
- id: 24
- criticality: ignore
After receiving NBAP: RL Reconfiguration Ready CFN: 40
message from BTS and successful AAL2 setup the

RNC can order the BTS to commit the modification
and the exact time for modifications : CFN = 40

UE Node B RNC
PDP Established
RADIO BEARER RECONFIGURATION [DCCH] 1
value DL-DCCH-Message ::=
Radio Link Reconfigure Ready integrityCheckInfo
AAL2SIG:ERQ messageAuthenticationCode '11000110
10000101 10011001 10000000'B,
AAL2SIG:ECF
rrc-MessageSequenceNumber 4
AAL2SIG:ERQ message radioBearerReconfiguration : later-
AAL2SIG:ECF than-r3 :
rrc-TransactionIdentifier 0,
FP: Downlink Sync
criticalExtensions criticalExtensions : r5 :
FP: Uplink Sync radioBearerReconfiguration-r5
FP: Downlink Sync activationTime 40,
new-H-RNTI '00000000 00000001'B,
FP: Uplink Sync
rrc-StateIndicator cell-DCH,
specificationMode complete :
rb-InformationReconfigList
rb-Identity 5,
•RRC: RADIO BEARER RECONFIGURATION rlc-Info

ul-RLC-Mode ul-AM-RLC-Mode :
message is used to deliver same setup information to Retransmissions :
transmissionRLC-Discard maxDAT-
the UE that was given to BTS in NBAP: RL maxDAT dat6,
RECONFIGURATION PREPARE message timerMRW te300,

maxMRW mm12
•The H-RNTI given to UE is the same as given to BTS transmissionWindowSize tw128,

timerRST tr250,
i.e. 00000000 00000001 B max-RST rst12,
pollingInfo
•Activation time for new configuration is CFN 40 (just timerPollProhibit tpp100,
timerPoll tp240,
like given to the BTS) poll-SDU sdu1,
lastTransmissionPDU-Poll TRUE,
lastRetransmissionPDU-Poll TRUE,
pollWindow pw50
•The HS-DSCH Capacity request procedure provides means for the RNC to request
HS-DSCH capacity from the BTS, by indicating the users buffer size in the RNC for a
given priority level (CmCh-PI)
•The RNC is allowed to reissue the HS-DSCH capacity Request if from the BS no
Capacity Allocation has been received with an appropriate time threshold
•Trigger: No capacity available for the data waiting in RLC buffers.
UE Node B RNC
PDP Established
ATM Conn:10 VPI:1 VCI:120 CID:14 Line:1 CT:0
Radio Link Reconfigure Ready 524 11:26:28.604285
AAL2SIG:ERQ AAL 2
UUI: 26 (1Ah)
AAL2SIG:ECF
SSSAR-PDU: 7F 0A 0F 00 2A
AAL2SIG:ERQ HS-DSCH CAPACITY REQUEST
AAL2SIG:ECF Control Frame CRC : 63 (3Fh)
FP: Downlink Sync Control Frame Type : 10 (0Ah)
CmCH-PI : 15 (Fh)
FP: Uplink Sync
User Buffer Size : 42 (002Ah) octets
FP: Downlink Sync
FP: Uplink Sync
Soc Classification level HS-DSCH: Capacity Request

•HS-DSCH Capacity Allocation is generated either in response to a HS-DSCH Capacity

Request or at any other time
•The flow control is mainly controlled by the Node-B sending capacity allocation messages. The
Node-B does know the status of the buffers in the RNC by the capacity request and by every
further data frame . So the Node B may use this message to modify the traffic flow at any time
by indicating its capacity to deliver PDU
UE Node B RNC
PDP Established
AAL2SIG:ERQ
AAL2SIG:ECF
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
FP: Downlink Sync
FP: Uplink Sync
HS-DSCH: Capacity Request
HS-DSCH: Capacity Allocation

UE Node B RNC SGSN
PDP Established

AAL2SIG:ERQ
AAL2SIG:ECF
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync
FP: Downlink Sync
FP: Uplink Sync
Measurement Control
HS-DSCH: Capacity Request
HS-DSCH: Capacity Allocation
HSDPA Traffic

Direct Resource Allocation for HSPA
Introduction
In RU20 HSPA transport channels can be allocated directly in Cell_DCH or

Cell_FACH (Common Channel Setup), without waiting for capacity request.
• Operator can manage the feature to allocate HSPA directly

– never (DCH 0/0 is used) or
– when UE is in Cell_DCH and/or
– when UE is in Cell-FACH
• DRA is always used when UE has F-DPCH allocated

(even DRA shall not be used in a cell)
• It is used for Background and Interactive traffic classes
• DCH in downlink / DCH in uplink still used 0/0 kbps DCH allocation
– DCH /DCH or
– HSDPA / DCH
Direct Resource Allocation for HSPA reduces the HSPA cal setup delay

Module 3 - Content


HSPA Setup
HSUPA cannot be established without HSDPA, HSDPA UL return channel is HSUPA

instead of R99
– High level procedure is the same as that for an NRT DCH
– RNC starts by allocation a 0/0kbps connection
– Selection between DCH and E-DCH is then completed when RNC receives the uplink or
downlink capacity request
UE Node B RNC SGSN
RRC Establishment
GPRS Attach
0/0 kbps DCH

PDP Context Activation
allocated
Uplink capacity request
RNC completes channel
type selection procedure
HSUPA connection can be established

• RRC Idle mode
• directly from CELL_PCH (Cell Update with reason Uplink Capacity Request)
HSPA Setup
Channel type selection
started 1
Uplink NRT RB mapped to Yes HS-DSCH possible to No

DCH > 0 kbps select in the downlink HC HSPA serving cell
selected +
No Yes Preliminary E-
UE capability No No DCH active set
Preliminary E-DCH active 3 selected
supports E-DCH set is acceptable
Yes 2 Minimum E-DCH
Yes active set
UE specific
PS RAB combination No HS-DSCH possible to No 4 selected
allows use of E-DCH select in the downlink
Yes Cell specific PS (can
Yes be more than 1)
Traffic class and THP No Number of E-DCH allocations No
allowed on E-DCH is below the maximum
Yes Yes
HSDPA mobility enabled No Final E-DCH active set is No UE specific PS
and HS-DSCH available acceptable
and no IFHO/ISHO
measurements Yes
DCH E-DCH DCH

Yes selected selected
IFHO/ISHO measurements selected
prevent HSUPA
1) Channel type switching running

2) RAB combinations allowed for HSUPA
up to 3 NRT RAB (any combination E-DCH RABs / DCH RABs) with or without AMR
3) Preliminary active set = all active cells with HSUPA enabled
4) Minimum AS = all HSUPA enabled active cells with sufficient quality
HSUPA Setup – Radio Bearer Reconfiguration
UE Node B RNC
PDP Established UE in Cell_DCH

Measurement Report : e4a • MAC-d Flow ID = 0 (allocated
NBAP: Radio Link Reconfiguration Prepare by RNC and sent to the BTS in
Radio Link Reconfigure Ready NBAP Radio Link
AAL2SIG:ERQ Reconfiguration Prepare
AAL2SIG:ECF
message)
AAL2SIG:ERQ
AAL2SIG:ECF • DDI = 0 also given by RNC
Radio Link Reconfiguration Commit and sent to the BTS in NBAP
RRC: Radio Bearer Reconfiguration (DCH) Radio Link Reconfiguration
Prepare message
• Rlc-PDU-SizeList
DL-DCCH-Message {
• 3GPP specifies that the RLC
DL-DCCH-Message {
integrityCheckInfo { dl-RLC-Mode dl-AM-RLC-Mode : {
messageAuthenticationCode dl-RLC-PDU-size sizeType2 : {
'11100110010000101001010111001000'B, part1 2 PDU size for:
rrc-MessageSequenceNumber 4 },
},
message radioBearerReconfiguration : later-than-r3 : {
inSequenceDelivery TRUE,
receivingWindowSize rw2047,
– sizeType2 = (part1 IE x 32)
rrc-TransactionIdentifier 0,
criticalExtensions criticalExtensions-r4 : criticalExtensions-r5 : r6 : {
dl-RLC-StatusInfo { + 272 bits + (part 2 IE x 8),
timerStatusProhibit tsp40,
radioBearerReconfiguration-r6 { missingPDU-Indicator TRUE (part two optional)
activationTime 236, }
new-H-RNTI '1001101111001111'B,
newPrimary-E-RNTI '0000000000000000'B,
},
rlc-OneSidedReEst FALSE
– 2*32+272=336
rrc-StateIndicator cell-DCH, },
specificationMode complete : { rb-MappingInfo {
rb-InformationReconfigList { {
{ ul-LogicalChannelMappings oneLogicalChannel : {
rb-Identity 5, ul-TrCH-Type e-dch : {
rlc-Info { logicalChannelIdentity 1,
ul-RLC-Mode ul-AM-RLC-Mode : { e-DCH-MAC-d-FlowIdentity 0,
transmissionRLC-Discard noDiscard : dat15, ddi 0,
transmissionWindowSize tw2047, rlc-PDU-SizeList {
timerRST tr200, sizeType2 : {
max-RST rst12, part1 2
pollingInfo { }
lastTransmissionPDU-Poll TRUE, },
lastRetransmissionPDU-Poll TRUE, includeInSchedulingInfo TRUE
157 © Nokia Siemens
timerPollPeriodic Networks
tper200 Presentation / Author / Date
},
}
DL-DCCH-Message {
mac-LogicalChannelPriority 8
HSUPA Setup }, dl-LogicalChannelMappingList { {

dl-TransportChannelType hsdsch : 0 } } } } } },
ul-CommonTransChInfo {
UE Node B RNC modeSpecificInfo fdd : {
ul-TFCS normalTFCI-Signalling : complete : {
PDP Established UE in Cell_DCH ctfcSize ctfc2Bit : { {
ctfc2 0,
Measurement Report : e4a powerOffsetInformation {
NBAP: Radio Link Reconfiguration Prepare gainFactorInformation computedGainFactors : 0 } },
{ ctfc2 1,
Radio Link Reconfigure Ready powerOffsetInformation {
AAL2SIG:ERQ gainFactorInformation signalledGainFactors : {
modeSpecificInfo fdd : {
AAL2SIG:ECF gainFactorBetaC 15 },
gainFactorBetaD 8,
AAL2SIG:ERQ referenceTFC-ID 0 } } } } } } },
AAL2SIG:ECF ul-deletedTransChInfoList {
dch-usch : {
Radio Link Reconfiguration Commit ul-TransportChannelType dch,
ul-TransportChannelIdentity 1 } },
ul-AddReconfTransChInfoList {
e-dch : {
tti tti10,
harq-Info rvtable,
addReconf-MAC-d-FlowList {
{ mac-d-FlowIdentity 0,
mac-d-FlowPowerOffset 0,
E-DCH: mac-d-FlowMaxRetrans 3,
transmissionGrantType scheduledTransmissionGrantInfo :
• TTI = 10ms NULL} } } },

dl-CommonTransChInfo {
• HARQ info = rvtable (IR in use) dl-Parameters sameAsUL : NULL } },

dl-DeletedTransChInfoList {
{ dl-TransportChannelType dch : 1 } },
• MAC-d flow identity = 0 dl-AddReconfTransChInfoList { {

dl-TransportChannelType hsdsch : NULL,
• MAC-d flow power offset = 0 (no need to have

tfs-SignallingMode hsdsch : {
harqInfo {
numberOfProcesses 6,
different powers for different MAC-d flows as only memoryPartitioning implicit : NULL },
addOrReconfMAC-dFlow {
one used) mac-hs-AddReconfQueue-List {
{ mac-hsQueueId 0,
• MAC-d flowMaxRetrans = 3 (3 retranmissions) mac-dFlowId 0,

reorderingReleaseTimer rt120,
• Grant type is = scheduled

mac-hsWindowSize mws16,
mac-d-PDU-SizeInfo-List { {
mac-d-PDU-Size 336,
mac-d-PDU-Index 0 } } } } } },
Soc Classification level dch-QualityTarget {
158 © Nokia Siemens Networks Presentation / Author / Date bler-QualityValue -20 } } } },
DL-DCCH-Message {
ul-DPCH-Info {
HSUPA Setup ul-DPCH-PowerControlInfo fdd : {

dpcch-PowerOffset -47,
pc-Preamble 0,
sRB-delay 7,
powerControlAlgorithm algorithm1 : 0,
deltaACK 6,
e-DPCCH-info: deltaNACK 6,
ack-NACK-repetition-factor 1,
• e-DPCCH-DPCCH-Power Offset = 5 (index) harq-Preamble-Mode 0 },
• happyBit-DelayCondition = 50ms
scramblingCodeType longSC,
scramblingCode 1000064,
dpdchPresence present : {
• E-TFCI-TableIndex =1 spreadingFactor sf256,

tfci-Existence TRUE,
puncturingLimit pl0-68 } } },
• E-DCH-MinimumSet-TFCI = 4 (32kbps) ul-EDCH-Information {
e-DPDCH-Info {
• Reference E-TFCI (as MaxChannelisationCodes = e-TFCI-TableIndex 1,

e-DCH-MinimumSet-E-TFCI 4,
SF2x2) reference-E-TFCIs {
{
reference-E-TFCI 11,
reference-E-TFCI-PO 12
3840ksps 11 24/15 12 },
39 38/15 16 {
reference-E-TFCI 39,
reference-E-TFCI-PO 16
}
},

DL-DCCH-Message {
maxChannelisationCodes sf2x2,
HSUPA Setup pl-NonMax 17,

schedulingInfoConfiguration {
periodicityOfSchedInfo-Grant ms200,
powerOffsetForSchedInfo 3 },
MaxChannelisationCodes SF2x2 threeIndexStepThreshold 12,
twoIndexStepThreshold 16 },
schedulingTransmConfiguration {
PLnon-max = UL Puncturing limit : 17 = 17*0.04=0.68 i.e. (1- servingGrant {
value 8,
0.68)=32% of the bits are punctured as a default primary-Secondary-GrantSelector primary } } },
dl-HSPDSCH-Information {
• Max value for 2xSF2 is 0.44 (1-0.44=0.56 i.e. 56% of hs-scch-Info {
the bits can be punctured) hS-SCCHChannelisationCodeInfo {
4 } } },
• Max value for 2xSF2+2xSF4 is 0.38 (1-0.38=0.62 i.e. measurement-feedback-Info {
62% of the bits can be punctured) measurementPowerOffset 12,
feedback-cycle fc4,
Scheduling info interval 200ms cqi-RepetitionFactor 1,
deltaCQI 5 } },
modeSpecificInfo fdd : NULL },
Power offset for SI = 3dB dl-CommonInformation {
dl-dpchInfoCommon dl-DPCH-InfoCommon : {
Three index step threshold = 12 cfnHandling maintain : {
},
Two index step threshold = 16 powerOffsetPilot-pdpdch 0,
spreadingFactorAndPilot sfd256 : pb4,
Initial Grant (serving grant) = 11 => E-TFCI = 3 (primary positionFixedOrFlexible flexible,
tfci-Existence TRUE } },
grant) modeSpecificInfo fdd : { } },
dl-InformationPerRL-List { {
E-AGCH channelisation code (SF256) = 10 modeSpecificInfo fdd : {
primaryCPICH-Info {
primaryScramblingCode 96 },
E-HICH/E-RGCH channelisation code (SF128) = 6 servingHSDSCH-RL-indicator TRUE,
servingEDCH-RL-indicator TRUE },
E-HICH signature = 1, E-RGCH signature index =2 dl-dpchInfo dl-DPCH-InfoPerRL : fdd : {
pCPICH-UsageForChannelEst mayBeUsed,
dpch-FrameOffset 78,
Rg-combinationIndex:Cells with an index equal to the dl-ChannelisationCodeList { {
index of the Serving E-DCH cell belong to the Serving E- sf-AndCodeNumber sf256 : 14 } },
tpc-CombinationIndex 0 },
DCH RLS e-AGCH-Information {
e-AGCH-ChannelisationCode 10 },
• The E-RGCH from these cells have RG commands e-HICH-Info e-HICH-Information : {
channelisationCode 6,
which for the UE are known to be the same as the RG signatureSequence 1 },
e-RGCH-Info e-RGCH-Information : {
commands
Soc Classification level from the Serving E-DCH cell signatureSequence 2,
rg-CombinationIndex 1
160 © Nokia Siemens Networks Presentation / Author / Date } } } } } } }
HSUPA 5.8Mbps
The peak bit rate on E-DCH for single user is • To support the UE UL peak rate
increased up to 5.8 Mbps of 5.8 Mbps (5.76 Mbps) the UE
needs to send in uplink on four E-
DCH channels in parallel (2xSF2
+ 2xSF4)
• UE category 6 and 7 enable
transmission of 4 codes in
Cch,4,3 parallel and support 5.76 Mbps at
Cch,2,1 maximum with QPSK modulation
E-DPDCH
(on I- and Q-branches • 3GPP defines for the usage of
2SF2 + 2SF4 max) 2xSF2 and 2xSF4 that no
Cch,4,2
DPDCH (that is no SRB on DCH)
is allocated at the same time on
Cch,4,1 the UL for this UE
• Therefore the SRB needs to be
Cch,2,0 mapped on E-DCH in this case.
Cch,4,0
This leads to the dependency on
RU20 RAN 1470 SRB's on
SF2 SF4 SF8 HSUPA that introduces the
mapping of UL SRB’s on E-DCH

HSUPA 5.8 Mbps & 2ms TTI
Introduction
• 3GPP Release 6 introduces both 10 ms and 2 ms TTI for HSUPA
• NSN RAS06 and RU10 support only the 10 ms TTI

• 10 ms TTI improves cell edge performance
• NSN RU20 introduces support for the 2 ms TTI

• 2 ms TTI reduces latency (original transmission and re-transmissions)
• 2 ms supports increased peak throughputs
• SRB are mapped onto HSUPA when using the 2 ms TTI (NSN implementation)
• SRB are mapped onto DCH when using the 10 ms TTI (NSN implementation)
• Mapping SRB onto HSUPA is mandatory for the 2×SF2 + 2×SF4 configuration because
the DPDCH code is blocked by E-DPDCH codes (3GPP specification)

HSUPA 5.8 Mbps & 2ms TTI
Supported Radio Bearers Combinations
• In case E-DCH with 2ms TTI is going to be allocated to UE, SRBs must be
mapped to E-DCH
• SRB mapping
– SRB can be mapped to
 UL DCH / DL DCH
 UL E-DCH 2ms TTI / DL DPCH (w/o F-DPCH but SRB mapped to HS)
 UL E-DCH 10ms TTI / DL HSDPA
Please note: SRB have higher priority than user plane data
• Streaming Traffic Class for a RAB

– Supported with 10ms TTI
– not Supported with 2ms TTI
For Streaming RAB or SRB RNC can apply so called Non-Scheduled Transmission:
– These are considered as high priority connections with guaranteed bitrate
– RNC allocates resources from WBTS for NST – > Streaming and SRB
– WBTS uses remaining resources for Scheduled Transmissions -> NRT RABs
Module 3 - Content


HSPA Mobility
•The E-DCH serving cell is always the same as the HS-DSCH serving cell.
– When RNC has decided to change the HS-DSCH serving cell, it is checked if DCH to E-
DCH channel type switch is needed or not. E-DCH to DCH switch is needed if:
 If the new HS-DSCH serving cell does not support E-DCH
 If the new HS-DSCH serving cell supports E-DCH but the E-DCH active set changes to
unacceptable
• HSUPA use a combination of soft handover and SCC procedure
• It is not necessary for the E-DCH active set to be the same as the DCH active set
– E-DCH active set is subset of DCH active set and max number of cell in E-DCH AS is 3
• Cells can be left out from E-DCH active set but is added to DCH active set for the
following reasons:
– HSUPA is not enabled for the cell (parameter HSUPAEnabled).
– A cell is under DRNC. Soft handover over Iur is not supported – HSPA over IuR is
disabled.
– A cell cannot be added to E-DCH active set because maximum number of E-DCH users
is reached in the cell or BTS specific local cell group.
– A cell cannot be added to E-DCH active set because no free E-DCH resources in BTS
specific local cell group.
– A cell cannot be added for some other reason (i.e. signaling problems)

HS-DSCH & E-DCH Serving Cell Change
Target Serving Original Serving
UE Cell Node B 2 Cell Node B 1 RNC
HSDPA Traffic
Measurement Report (DCH) – e1A AS update to add new

NBAP: Radio Link Setup target cell to AS
RRC: Active Set Update (DCH)
NBAP: Radio Link Synchronisation Physical Channel Reconf. to
RRC: Active Set Update Complete (DCH)
RRC: Measurement Control Reconfigure the HS-DPCCH
NBAP: Radio Link Reconfiguration Prepare in the new target cell for UL
NBAP: Radio Link Reconfiguration Ready signaling- (not happening in
NBAP: Radio Link Reconfiguration Commit
case Intra BTS-SCC)
RRC: Physical Channel Reconfiguration
RRC: Measurement Control
RRC: Physical Channel Reconfiguration Complete (DCH)
Measurement Report (DCH)

NBAP: Radio Link Reconfiguration Prepare
NBAP: Radio Link Reconfiguration Ready
ALCAP : ERQ
ALCAP : ECF
RRC: Radio Bearer Reconfiguration
HSDPA Traffic
Measurement Report (DCH) – e1A

NBAP: Radio Link Setup
NBAP: Radio Link Synchronisation
Measurement Control NBAP: Radio Link Reconfiguration Prepare
Setting up periodical Ec/No NBAP: Radio Link Reconfiguration Ready
measurements for serving cell
change procedure
RRC: Physical Channel Reconfiguration
RRC: Physical Channel Reconfiguration Complete (DCH)

Periodical NBAP: Radio Link Reconfiguration Ready
measurements ALCAP : ERQ
ALCAP : ECF
HSDPA Traffic
Measurement Report (DCH) – e1A

NBAP: Radio Link Setup
NBAP: Radio Link Synchronisation
RRC: Physical Channel Reconfiguration NBAP: Radio Link Reconfiguration
Prepare
Old BTS to delete the MAC-d flow and
RRC: Physical Channel Reconfiguration Complete (DCH) to new BTS to set up the MAC-d flow
Measurement Report (DCH) SCC Triggered NBAP: Radio Link Reconfiguration
NBAP: Radio Link Reconfiguration Prepare Commit for both BTSs
NBAP: Radio Link Reconfiguration Prepare to inform the CFN when serving cell
NBAP: Radio Link Reconfiguration Ready change will be taken into use.
ALCAP : ERQ After Reserving Resources in the new
ALCAP : ECF Target cell, RNC sends the Radio
NBAP: Radio Link Reconfiguration Commit Bearer reconfiguration message to
NBAP: Radio Link Reconfiguration Commit the UE
Indication successful SCC, the UE send
Radio bearer reconfiguration
168 © Nokia Siemens Networks Presentation / Author / Date complete message to the RNC
HSPA over IuR
• Allows both HSDPA and HSUPA data to be transferred across the Iur
• Allows the Serving Cell Change procedure to target cells on a drift
RNC
• Allows drift RNC cells to be included within the HSUPA active set
• Avoids the requirement for channel type switching when moving onto
a drift RNC
• Mobility
• Serving RNC selects the initial serving cell from the set of serving and drift RNC
cells within the active set
• Serving Cell Change procedure is supported across the Iur interface
• Drift RNC indicates support for HSDPA and HSUPA within its response to Radio
Link Setup or Radio Link Addition messages
• HOPS parameters shown on previous slide are only applicable to drift RNC cells which
are neighboured from the serving RNC
• Serving RNC starts uplink SIR Error measurements over the Iur
• Serving RNC can then use SIR Error measurement for the serving cell change
procedure
Module 3 - Content


Dual Cell HSDPA
• Prior to 3GPP Release 8, HSDPA channel bandwidths are limited to 5 MHz

• Rel. 8 allows 2 adjacent channels to be combined to generate an effective HSDPA
channel bandwidth of 10 MHz  known as Dual Cell HSDPA
• RU20 on Top implementation of Dual Cell HSDPA is based upon Rel 8.
• Rel. 8 allow Dual Cell HSDPA to be combined with 64QAM but not with MIMO
(Rel. 9 allows combination with MIMO and also use of two non-adjacent channels)
Basic Approach DC HSDPA Approach
1 UE using 5 MHz RF Channel 1 UE using 2 x 5 MHz RF Channels
Peak Connection Throughput = 28Mbps Peak Connection Throughput = 42Mbps
f2 (5MHz)
f1 (5MHz)
f1 (5MHz)
Double rates w/o double antennas

Load balancing between carriers
Higher Throughput even at cell edge
MIMO (28Mbps), or 64QAM (21Mbps) DC HSDPA and 64QAM (42Mbps)
171 © Nokia Siemens Networks NPO / A Arjona
Primary and Secondary Serving Cells
• The primary serving cell provides the full set of physical channels
– Inner loop power control is driven by the serving cell
– HARQ ACK/NACK and CQI are reported to the serving cell
– Uplink data is sent to the serving cell
• The secondary serving cell provides only the downlink HS-SCCH and HS-PDSCH
• The return channel must be HSUPA
Downlink Uplink
Channels Channels
HS-SCCH E-DPDCH Primary RF Carrier
HS-PDSCH E-DPCCH Primary Serving cell
DPCCH HS-DPCCH
F-DPCH* DPCCH
HS-SCCH
HS-PDSCH
Secondary RF Carrier
Secondary Serving cell

*optional
Connection Establishment (1/3)
• RRC Connection Request message includes a flag to indicate whether the

UE supports DC-HSDPA
• RRC Connection Setup Complete message includes UE HSDPA

Category information
Used by network
when DC-HSDPA
is disabled
…
Used by network
when DC-HSDPA
is enabled …

• Connection establishment from CELL_DCH shown below
• Message flow is the same as for a single cell HSDPA connection
UE Node B RNC CN
UE in CELL_DCH with standalone SRB on DCH/DCH, DCH/HSDPA or SC HSPA

DC-HSDPA is possible with current HS-DSCH
serving cell becoming primary serving cell
RL Reconfiguration Prepare
MAC-ehs resources reserved for DC-HSDPA
RL Reconfiguration Ready
[Additional HS Cell Information Response IE]
Radio Bearer Setup
[primary cell HSPA information, Downlink Secondary Cell Info FDD IE]
RL Reconfiguration Commit
UE in CELL_DCH with DC-HSDPA

• Connection establishment from CELL_FACH shown below
• Message flow is the same as for a single cell HSDPA connection
UE Node B RNC CN
UE in CELL_FACH with standalone SRB on RACH/FACH

DC-HSDPA is possible with current HS-DSCH
serving cell becoming primary serving cell
RL Setup Request
MAC-ehs resources reserved for DC-HSDPA
RL Setup Response
[Additional HS Cell Information Response IE]
Radio Bearer Setup
[primary cell HSPA information, Downlink Secondary Cell Info FDD IE]
RL Restore Indication
UE in CELL_DCH with DC-HSDPA

HS-DPCCH Signaling
• HS-DPCCH is responsible for signaling

– CQI reports
– HARQ ACK/NACK
• For DC-HSDPA, CQI & ACK/NACK information is signaled information for both
cells with the cell pair
• Physical channel capacity of the HS-DPCCH remains the same so the level of
redundancy is reduced (i.e. error correction power reduced)
• ACK/NACK coding is modified to incorporate information applicable to second cell
• CQI raw data increases from 5 to 10 bits meaning that coding rate increases from
rate 1/3 to rate 1/2 rate
Legacy DC HSDPA
Physical Channel Mapping Physical Channel Mapping
w0..w9 b0..b19 w0..w9 b0..b19

Channel Channel Channel Channel
Coding Coding Coding Coding
a0..a9 a0..a9
ACK / NACK CQI ACK / NACK CQI CQI

31 values 31 values 31 values
(5 bit) (5 bit) (5 bit)
Prim. SC SHSSC
CS Voice Over HSPA
Concept
• 3GPP Rel-8 feature which can be implemented in Rel-7 UEs
• CS Voice Over HSPA feature makes use of HSPA transport channels

• Higher spectral efficiency than Dedicated Channels (DCH)
• Mapping of CS Voice service onto HSPA transport channel takes place in RNC
• Transport channels allocated in UTRAN are not visible to CS Core NW
• Rel4 CS Core concept supports this feature w/o changes or sw upgrades
• Radio Protocol Layer 2 will be changed

• Radio Link Control Unacknowledged Mode (UM) is used
• RLC Transparent Mode used for DCH operation
• Jitter Buffer management inside RNC

CS Voice Over HSPA
Supported RAB combinations
• For CS Voce Over HSPA operation, SRB must be mapped to HSDPA/E-DCH
• Speech CS RAB
• Speech CS RAB + PS streaming PS RAB
• Speech CS RAB + 1...3 Interactive/Background PS RABs
• Speech CS RAB + PS Streaming PS RAB + 1...3 Interactive/Background PS RABs
Please note: PS streaming and multiple NRT RABs (2/3) are separate optional features.
• Codecs supported from the past are available for CS Voice Over HSPA operation
• AMR (12.2, 7.95, 5.9, 4.75), (5.9, 4.75) and (12.2)
• AMR-WB (12.65, 8.85, 6.6)
• Load based AMR selection algorithm is not used while CS Voice is mapped on HSPA

LTE interworking (1/2)
• LTE Interworking feature provides 3G support for:

• cell reselection from 3G to LTE
• PS inter-system handover from LTE to 3G
• Feature implementation is based upon 3GPP release 8
• Cell re-selection from 3G to LTE is applicable to UE which are in RRC
Idle mode, CELL_PCH and URA_PCH
• 3G, LTE and GSM can be prioritized with 8 distinct absolute priorities
• In RRC Idle, URA_PCH and Cell_PCH states, UE camped in WCDMA
will
• periodically measure all higher priority RAT
• measure lower priority RAT when 3G quality falls below a threshold
• NSN RL10 LTE system provides support for LTE to 3G inter-RAT
handover

LTE interworking (2/2)
• The 3 transitions supported by the RU20 LTE Interworking feature

Inter-system LTE HOs will be supported in RL20
3G LTE GSM
Supported
by feature GSM_Connected
CELL_DCH Handover E-UTRA Handover
RRC_CONNECTED
GPRS Packet
transfer mode
CELL_FACH
CCO with
optional CCO,
CELL_PCH NACC Reselection
URA_PCH Reselection
Connection Connection
Connection establishment/release establishment/release
establishment/release
Reselection Reselection GSM_Idle/GPRS

UTRA_Idle E-UTRA
RRC_IDLE Packet_Idle
Supported CCO, Reselection
by feature

3G -> LTE inter-system cell reselection
RU20 supports idle mode cell reselection from a WCDMA cell to LTE cell
Operator can control reselection for the UEs by applying higher priorities to LTE
Baseline for the LTE Interworking feature is 3GPP Rel8.

LTE -> 3G PS inter-system handover
• Incoming inter-system handovers from LTE are always Packet Switched
UE Node B RNC PS CN
RANAP: Relocation Request
AC and Channel
Type Selection

RANAP: Relocation Request Acknowledge
NBAP: Radio Link Restore Ind.
RANAP: Relocation Detect
RRC: Handover to UTRAN Complete
RANAP: Relocation Complete
RRC: Security Mode Command
RRC: Security Mode Complete
RRC: UE Capability Enquiry

RRC: UE Capability Information
RRC: UE Capability Information Confirm

HSDPA MIMO
• Downlink MIMO (Multiple Input Multiple Output) is a 3GPP release 7 capability
• The feature is based upon the use of 2 transmit antenna at the Node B and 2
receive antenna at the UE (downlink 2x2 MIMO)
• Peak throughput can be doubled when the UE is in good radio conditions, i.e.
peak throughput with 16QAM and 15 codes increases from 14 Mbps to 28 Mbps
• NSN feature is based upon single user MIMO rather than multi-user MIMO
• Single User MIMO can switch between two modes:
Spatial Diversity (single stream) Spatial Multiplexing (dual stream)
TB1 TB1 TB1+TB2 TB1 -TB2
Propagation Propagation
Channel Channel
Improves SNR at UE Improves throughput at

UE
MIMO Requires also:
-HSUPA 2ms TTI enabled
HSDPA MIMO -(First MIMO devices does not support REL7 F-DPCH)
- FRLCEnabled  Enabled
- HSDPA14MbpsPerUser  Enabled
- NBAPCommMode  0
MIMO is enabled with parameter MIMOEnabled

• Single stream MIMO
– Provides diversity and array gain
– Maximum MIMO single stream Bit Rate per transport block = 13.98 Mbps
• Dual stream MIMO provides spatial multiplexing gain
– Maximum MIMO dual stream Bit Rate per transport block 2*13.98 = 27.95 Mbps
=> Application throughput = 23.88 Mbps
• MIMO mode selected adaptively by the scheduler based on reported CQIs

184 © Nokia Siemens Networks RU20 Delta Optimisation/M4 Field Performance
Reported CQI
• UE categories 17 to 20 are
specified to use CQI mapping
tables
• C and D in single stream
mode
• H and I in dual stream
mode

MIMO CQI Reporting - Type A
• CQI mapping tables do not
include the maximum
transport block sizes
• CQI compensation
• BTS is left with the decision

of when to schedule the
maximum transport block
sizes

MIMO CQI Reporting - Type B
Table C (UE Categories 15 and 17) Table D (UE Categories 16 and 18)

CQI for MIMO
• The RNC informs the UE of: New for MIMO

– CQI feedback cycle (range: 0,2,4,8,10,16,20,32,40,64,80 ms)
– CQI repetition factor (range: 1,2,3,4)
– N_cqi_typeA/M_cqi ratio (range: 1/2, 2/3, 3/4, 4/5, 5/6, 6/7, 7/8, 8/9, 9/10, 1/1)
• These parameters define the pattern with which the CQI reports are sent
• UE indicates dual stream or single stream within type A according to the current
channel conditions
• Type B is sent periodically for single stream ‘fall back’ in case the BTS decides to
use single stream while the UE is reporting a dual stream
Example:
CQI feedback cycle = 8 ms
CQI repetition factor = 2
N CQI type A / M = 9/10
Type A CQI Type B CQI
New CQI sent every 4 TTI = 8 ms
Complete cycle of 10 × 4 = 40 TTI = 80 ms

MIMO 2x2 / 28 Mbps MIMO is allocated whenever possible,
both at the start of a connection and during a connection
Allocation of MIMO for a UE
• Before allocation of MIMO for a UE, RNC checks following conditions:
(if at least one of the conditions is false during active MIMO allocation, MIMO will be deactivated)
Start
no
MIMO Parameter Enabled
yes
optional
no
feature for BTS is MIMO capable
UE yes
no
UE is MIMO capable
yes
no
RAB configuration for UE allows MIMO
yes
no
Streaming RAB state changes to inactive
yes
no
SRB can be mapped to HSPA (F-DPCH)
yes
no
MAC-ehs can be allocated (Flex RLC)
Soc Classification level yes – allocate MIMO
no – do not allocate MIMO
Supported RAB Combinations
• MIMO is supported for NRT PS services only

• MIMO supports the following Radio Bearer and SRB mappings:
• User plane radio bearer mapped onto HS-DSCH in DL and E-DCH in UL
• SRB mapped onto HS-DSCH in DL and E-DCH in UL
• SRB mapped onto DCH in DL and E-DCH in UL
• If SRB is mapped onto DL DCH, UL SRB must be mapped onto 2 ms TTI E-DCH
• If SRB is mapped onto DL HS-DSCH, UL SRB can be mapped onto either 2 ms
or 10 ms TTI E-DCH
• MIMO is not used if UL SRB cannot be mapped onto E-DCH
• MIMO supports NRT HSPA multi-RAB
• MIMO is not supported for NRT PS RAB in combination with a RT Streaming PS
RAB

Mobility
• MIMO does not impact the Serving Cell Change procedure
• MIMO continues on the target cell
• HSDPA inter-frequency handover can be applied to MIMO connections
• decision making, measurements and target cell selection follow existing rules
• MIMO is de-activated during compressed mode measurements because the E-DCH is required for
MIMO (and E-DCH compressed mode is not supported)
• Data transfer across the Iur is supported for MIMO
Directed RRC Connection Setup

• Directed RRC connection setup for HSDPA does not differentiate between
MIMO and non-MIMO UE
• MIMO capability is not signalled within the RRC Connection Request message

Module 3 – Signalling Flows
Summary
• An understanding of the various signalling flows together with the
information contained in different messages is an essential element
in the optimisation engineers’ toolbox

Version control
Version Date Status Owner
RAN04 2006 Base version Mike Roche, Steve

Hunt, Gareth Davies,
Pekka Ranta
RAS051_v1.0 24. 04. 2007 HSDPA signalling added, Video Kirsi Teravainen
call signalling, added some
signalling flows
Checked for RAS051 level
RAS06_v1.0 7.7.2008 Converted to NSN format and Kirsi Teräväinen
checked to RAS06 level
HSUPA signalling flow added
RU20 20.04.2011 Added RU20 features signalling, Bartlomiej Tracz
Protocol stacks in HSDPA, Jakub Borkowski
HSUPA and in Dual Iub, IP
based interfaces description,
Common Channel Setup,
Directed RRC, Routing Area
update procedure

End of Module 3

194 © Nokia Siemens Networks Presentation / Author /15.4.2008 KTe

RAN - Field - Opt - M3 - Signalling Flows - RU20 - Jan2012

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RAN - Field - Opt - M3 - Signalling Flows - RU20 - Jan2012

Uploaded by

Copyright:

Available Formats

3G RAN Field Optimization

Soc Classification level

• Cluster health checks

• 3G<>2G Cell reselection

• After this module the delegate shall be able to:

Soc Classification level

• Introduction – Protocol stacks, Dual Iub, IP based interfaces

Soc Classification level

• Protocol stacks include both user and control planes

AAL2 AAL2 AAL2 AAL2 Link Link

MAC Node B MAC

Soc Classification level

The Iub protocol stack has three planes

Soc Classification level

•The Iu-CS protocol stack has three planes

AAL2 AAL2 AAL5 AAL5

ATM ATM ATM ATM

ATM ATM ATM ATM

• MAC-e/es in UE • MAC-hs in NodeB • MAC-hs in RNC

ATM ATM ATM ATM

Soc Classification level

User Plane ATM Stack User Plane IP Stack

Iub User Plane Protocol

Physical layer Ethernet-Phy

ARP – Address Resolution Protocol

Soc Classification level

SAAL – Signalling ATM Adaptation Layer

Soc Classification level

Control plane User plane

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

• Introduction – Protocol stacks, Dual Iub, IP based interfaces

Soc Classification level

UE BTS DRNC SRNC CN

1. Cell search, BCCH

2. RRC Connection Setup 2

Soc Classification level

Slot synchronisation to a cell

P-CCPCH, (SFN modulo 2)=0 P-CCPCH, (SFN modulo 2)=1

The Primary CCPCH is

Soc Classification level

Soc Classification level

RRC: RRC CONNECTION REQUEST (RACH)

RRC: RRC CONNECTION SETUP (FACH)

RRC: CONNECTION SETUP COMPLETE (DCH)

Soc Classification level

• RRC Connection Request

CPICH Ec/Io of measured cell

Soc Classification level

• The Common NBAP: Radio Link Setup

• The Iub time of arrival window start point (toAWS) is 15 ms.

The Network Service Access Point (NSAP) address is specified

Soc Classification level

Soc Classification level

Message contains information such as;

RRC: RRC Connection Request (RACH)

NBAP: Radio Link Setup Request

NBAP: Radio Link Setup Response

ALCAP: Establish Request

ALCAP: Establish Confirm

FP: Downlink Sync