Drive Test - Signalling Flows PDF

WCDMA RAN Optimisation
Signalling Flows
Introduction
This material contains WCDMA signalling material, including

• Signalling flows for AMR calls, PS calls, HSPA calls, ISHO, SHO, SRNC relocation
procedures and Location & Routing Area update procedures
• Protocols and transport mechanisms used for the various messages
• Key pieces of information contained in the message
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)
• Layering – DRRC Connection Setup, Common Channel layering, MBLB blind HO/state trans
• PS call signalling – 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, DC HSDPA
• HSUPA call – HSPA setup, Selection of 2ms TTI in HSUPA, SRB on HSUPA
• HSPA call mobility – Serving Cell Change, HSPA over Iur
UMTS Bearer Services
Non-Access
Radio Access
Stratum
Bearers
Signalling
connection
RRC RRC Iu
connection connectio
n
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 UP Iu,cs UP etc etc
MAC Node B MAC
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
Uu Iub Iu,cs A
CS Radio Interface Protocol (RIP) User 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 L1 WCDMA 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 Network
User Plane
Control Plane Control Plane
• The user plane uses Frame Protocol and is
NBAP Frame Protocol
responsible for encapsulating all data to and from
the UE
ALCAP Q.2630.1 • ATM Adaptation Layer 5 (AAL5) is used for the
Q.2150.2 control planes whereas AAL2 is used for the user
SSCF-UNI SSCF-UNI plane
SSCOP SSCOP
AAL5 AAL5 AAL2
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 Network
User Plane
Control Plane Control Plane
RANAP Iu User Plane

Protocol
Q.2630.1
• The user plane is responsible for
encapsulating all data to and from the UE
SCCP Q.2150.1
MTP3b MTP3b • ATM Adaptation Layer 5 (AAL5) is used for
SSCF-NNI SSCF-NNI the control planes whereas AAL2 is used for
SSCOP SSCOP the user plane
AAL5 AAL5 AAL2
ATM
Physical Layer
PS Radio Interface Protocol (RIP) User Plane – HSDPA
UE RNC PS Core Network
RLC-U RLC-U
R99
MAC-d MAC-d Iu, ps UP Iu, ps UP
Node B
FP FP
AAL2 AAL2 AAL5 AAL5
WCDMA WCDMA
L1 Uu L1 ATM ATM ATM ATM
Iub Iu,ps
Phy Phy Phy Phy
HSDPA
MAC-hs in UE
• HARQ
UE RNC PS Core Network
• Disassembly of transport blocks
• Re-Ordering RLC-U RLC-U
MAC-d MAC-d Iu, ps UP Iu, ps UP
MAC-hs in NodeB Node B
• HARQ MAC-hs MAC-hs FP FP
• Packet Scheduling MAC-ehs MAC-ehs AAL2 AAL2 AAL5 AAL5
• Flow Control ATM ATM ATM ATM
WCDMA Uu WCDMA
• Transport format selection L1 L1 Iu,ps
Phy Phy Phy Phy
MAC-ehs (Rel7) when downlink Flexible RLC
is supported
Iub can be implemented over IP protocol
PS Radio Interface Protocol (RIP) User Plane - HSUPA
RNC
HSUPA PS Core Network
UE RLC-U
MAC-e/es in UE Iu, ps UP
RLC-U MAC-d
• HARQ MAC –es Iu, ps UP
MAC-d Node B
• Scheduling & MAC-e multiplexing MAC-is
MAC-e/es MAC-e FP FP
• E-DCH TFC Selection MAC-is/i MAC-i AAL2 AAL2 AAL5 AAL5
MAC-e in NodeB
Uu ATM ATM ATM ATM
WCDMA WCDMA
• HARQ L1 L1 Phy Phy Phy
Iu,ps
Phy
• Scheduling & MAC-e multiplexing
MAC-es in RNC Iub can be implemented over IP protocol
• In-sequence delivery (reordering)
• SHO data combining
MAC-is/i when Uplink Flexible RLC is

supported (RU40 feature)
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
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
IP Based Iu-CS
AAL2
IP Based Iu-PS
IP Based Iur
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 P-CCPCH, (SFN modulo

2)=0 2)=1
The Primary CCPCH is detected using the

identified p-scrambling code  system and
10 ms 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
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 or RSCP 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 via AAL2 based ATM (transparent mode)
• The BTS measures the one way propagation delay in chips
(resolution is 3 chips) and inserts into message
Differences in EcNo estimation at RRC Connection Request 2
LG RRC Connection Request EcNo PDF Motorola RRC Connection Request EcNo PDF
Measurement made in a UK 0.090 0.160
network in 2005 0.080 0.140
0.070
0.120
0.060 Mot A1000
0.100
Mot A835
0.050 LG 8130, 8138, 8180, 8330
PDF
PDF
0.080 Mot A835, A920, A925
0.040 LG U8110, 8120
Mot C975, E1000
0.060
0.030 Mot C975, V975
0.020 0.040
0.010 0.020
0.000 0.000
-25
-23
-21
-19
-17
-15
-13
-11
-8.5
-6.5
-4.5
-2.5
-0.5
-25
-23
-21
-19
-17
-15
-13
-11
-8.5
-6.5
-4.5
-2.5
-0.5
EcNo EcNo
NEC RRC Connection Request EcNo PDF Nokia RRC Connection Request EcNo PDF
0.160 0.090
0.140 0.080
0.070
0.120
0.060
0.100
NEC 313, 323, 338, 616 0.050 Nokia 6630, 6680
PDF
PDF
0.080 NEC 313, 616

0.040 Nokia 7600
NEC 606, 808
0.060
0.030
0.040 0.020
0.020 0.010
0.000 0.000
-25
-23
-21
-19
-17
-15
-13
-11
-8.5
-6.5
-4.5
-2.5
-0.5
-25
-23
-21
-19
-17
-15
-13
-11
-8.5
-6.5
-4.5
-2.5
-0.5
EcNo EcNo
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
Example NetHawk Iub Log plane belonging to the Iub protocol 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)
• 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
RRC Connection
• Convolutional coding rate to be used and CRC size Setup msg
• 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 frame and
slot structure
UE Node B RNC
RRC: RRC Connection Request (RACH)

NBAP: Radio Link Setup Request
NBAP: Radio Link Setup Response
ALCAP: Establish Request
ALCAP: Establish Confirm
FP: Downlink Sync
FP: Uplink Sync
RRC: RRC Connection Setup (FACH)
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
Connection Setup message on 2nd in-sync
the FACH primitive
40 ms window
3rd in-sync
primitive
40 ms window
4th in-sync
primitive
Fast Layer 1 Synchronisation with Post Verification 2
RU20 introduces Fast Layer 1 Synchronisation

• 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
Fast Layer 1 Synchronisation – with Post verification 2
• UE transmit timing no longer depends upon N312

• Total delay before UE starts UL transmission is reduced by 70 ms (N312=4)
• UE stops transmitting after 40 ms if the post verification fails
Node B starts UE starts transmitting UE stops transmitting if

transmitting verification check fails
10 ms radio
frames
40 ms window
UE starts Post verification check
receiving
Fast Layer 1 Synchronisation (RU20 feature) 2
RRC Signalling
L1 Synchronization happens between RRC Connection Setup and RRC connection Setup complete
messages
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)

Start Tx/Rx
L1 Sync
NBAP: SYNCH INDICATION
RRC: CONNECTION SETUP COMPLETE (DCH)
Fast Layer 1 Synchronisation 2
RRC Signalling
• If the feature is enabled, the RNC sets the ‘Post

Verification Period’ information element to TRUE
when signalling to a release 6 or newer UE
• Information element can be included within the
following message types:
• RRC Connection Setup
• Radio Bearer Reconfiguration
• Radio Bearer Setup
• Cell Update Confirm
RRC Connection Setup Complete
• 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,

HSPA categories
RRC Connection
Setup Complete msg
UE<–> CS_CN signalling
• Location Update
• Authentication
• Security Mode Setup
• Paging
• Call Setup
MSC /
VLR
UE
RNC MGW
WBTS
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
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
Protocol discriminator Number: 602
Example structure of
½ Octet Bearer Capability NAS set-up message
0011 => Call Control Message 5 Octets
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
Example
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 Response 4
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
RRC: Radio Bearer Setup & RAB Assignment Response 4
This acknowledgment specifies that RAB 1 has been successfully

established
RANAP-PDU
outcome
- procedureCode: 0
- criticality: reject
outcome
RAB-AssignmentResponse
protocolIEs
- id: 52
- criticality: ignore
RAB-SetupOrModifiedList
- id: 51
RAB-SetupOrModifiedItem
- rAB-ID: '00000001'B
Example
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 is for a
FP: Downlink Sync soft handover rather than softer
FP: Uplink Sync handover
Cell starts transmitting
Active Set Update
If softer handover then only a single

L1 SYNC set of transport blocks are forwarded
Active Set Update Complete 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
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

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
Content

• Common Channel Setup – CCH Setup
Common Channel Setup – Introduction
Common Channel Setup allows also connections to be established in CELL_FACH rather than CELL_DCH
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
More efficient allocation of UTRAN resources
• less signaling 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 – Signaling 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 appropriate RF
YES 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 to be enabled
• SRB on 13.6 kbps DCH
Common Channel Setup
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
Common Channel Setup
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
Common Channel Setup – Signaling Procedure
UE BTS RNC CN
RRC Connection Request (RACH)
• Cell_FACH State used for Establishment Cause such that setup on CCH is preferred
RNC Allocated C-RNTI, establishes the RRC
subsequent signaling connection/ on CCH and waits for RRC

Conn. Setup complete from UE
• UE stays on Cell_FACH RRC Connection Setup (FACH)

RRC State Indicator Cell_FACH
Single mapping option
SRB4 is not established
during e.g NRT call setup UE in CELL_FACH State
RRC: Initial UE message
UE capability required
RANAP: Initial DIRECT transfer
• Traffic Volume RRC Connection Setup Complete
RRC Connection Established, UE in Cell_FACH State
Measurements performed in
Cell_FACH state NAS Signalling Connection; UE – CN Signalling Continued
• Cell_DCH used once RRC: Security mode Command

RANAP: Security mode command
Channel Type switching RRC: Security mode Complete

RANAP: Security mode complete
selected DCH or HSPA RANAP: RAB Assignment Request
transport channels (not RRC: Radio Bearer Setup
Established RB on FACH for NRT
shown here) RRC: Radio Bearer Setup Complete RAB. RRC State indicator
Cell_FACH . Don`t established SRB4
RANAP: RAB Assignment Response

RRC: Measurement control (TVM only)
Default TVM threshold 128 byte

Measurement Setup in BTS and RNC
NAS Signalling Connection; UE – CN Signalling Continued (E.g. PDP context Accept)

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
T e rm in a l A T e rm in a l B
4 phases in Video Handshaking
T e rm in a lC a p a b ility S e t
•TerminalCapabilitySet message: terminals T e rm in a lC a p a b ility A c k
exchange information about their own terminal T e rm in a lC a p a b ility S e t
system capabilities
T e rm in a lC a p a b ility A c k
•MasterSlaveDetermination: terminals exchange M a s te rS la v e D e te rm in a tio n
random numbers, to determine the master and slave M a s te rS la v e D e te rm in a tio n A c k

terminals M a s te rS la v e D e te rm in a tio n
•VideoIndicateReadyToActivate: [optional M a s te rS la ve D e te rm in a tio n A c k

procedure], wait for video transmission until both
UEs are ready to send. O p e n L o g ic a lC h a n n e l
•OpenLogicalChannel: logical channels are opened O p e n L o g ic a lC h a n n e lA c k
for information streams [Audio, Video, Data] O p e n L o g ic a lC h a n n e l
O p e n L o g ic a lC h a n n e lA c k
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 Release SCCP: Release Complete
RRC: Connection Release Complete
NBAP: Radio Link Deletion Request
NBAP: Radio Link Deletion Response
ALCAP: Release 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 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
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

• 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
• 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:
• 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) combined RA Separate LA and RA updates
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
SGSN GGSN
UTRAN PS Paging
In Mode II the Gs interface is not present between MSC and SGSN
MSC
CS Paging
SGSN GGSN
UTRAN PS Paging
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
11. Location Update Procedure
12. Location Update Accept
13. RA Update Accept
14. RA Update Complete
15. TMSI Reallocation
2015-10-12 Complete
Content

ISHO AMR Call
UE WBTS RNC CN
RCC: Measurement Control
RCC: Measurement Report
NBAP: RL Reconfigure Prepare
Reporting Event
Triggered NBAP: RL Reconfigure Ready
NBAP: RL Reconfigure Commit
RCC: Physical Channel Reconfiguration
RCC: Physical Channel Reconfiguration Complete
NBAP: Compressed Mode Command
RCC: Measurement Report (GSM RSSI) Handover Decision : BSIC
verification required
RCC: Measurement Report (BSIC verified)
RANAP: Relocation Required
RANAP: Relocation Command
RCC: Handover From UTRAN Command
RANAP: Iu Release Command
RANAP: Iu Release Complete

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.
ISHO Cancellation
• When inter-system handover cancellation is enabled, the RNC can stop ongoing inter-system (GSM) measurement. If
the radio conditions in the current WCDMA layer improve during the inter-system measurement phase, a coverage
based handover or network initiated cell reselection attempt can be cancelled.
• UE transmission power
• Start: Measurement Event 6A
• Stop: Measurement Event 6B
• Received Signal Code Power (RSCP) or CPICH Ec/No measurement result for a primary CPICH (active set cell)
• start: Measurement event 1E
• stop: Measurement event 1F
• Downlink DPCH power
• start: DL DPCH Tx Pw increasing beyond the maximum threshold
• stop: DL DPCH Tx Pw falls below the maximum threshold
• Event 1E cancellation
• AS Update (1A or 1C) can also cancel ISHO in case of RSCP or Ec/No triggered ISHO
• If the CPICH Ec/No or the CPICH RSCP of this cell is found to be greater than or equal to the threshold for event 1E
• No cancellation once measurement phase is completed
Multiple BSIC identification
• The RNC initiates BSIC identification to the UE for max three GSM carriers simultaneously.
• If the ISHO attempt to the best neighbour cell fails, a new attempt to the other cell can be started without
new inter-system measurements in compressed mode.
– Reduces compressed mode measurements
– Increase ISHO success rate
• ISHO may fail if the initial BSIC identification of the best GSM cell (according to the GSM RSSI
measurements) fails, or the target GSM cell is fully loaded.
• Instead of waiting the penalty period and then retrying the HO with new CM measurements, the BSIC
identification for more than one GSM cell is performed.
• This increases the probability of successful BSIC identification and allows another handover attempt to
the second or third best cell without repetitive GSM measurements if the first handover attempt fails.
• In order to enable the handover attempt to the second or third best GSM cell, the RNC selects two or
three GSM target cells which meet the required radio link properties.
Multiple BSIC Identification- Message Flow
Content

3G Layering Features
3G layering features can move UE’s to other 3G carrier during call setup or when there is state
transition to Cell_DCH
From Idle
• Directed RRC Connection Setup, Directed RRC Connection Setup for HSDPA layer
• MBLB Blind HO
From Cell_FACH, Cell_PCH to DCH
• Common Channel layering
• MBLB State Transition
Layer change can happen for both CS and PS depending which services are activated
Directed RRC Connection Setup features
• Directed RRC Connection setup (DRRC) features redirect UE to UE UTRAN

other layer during RRC connection setup procedure RRC Connection Request
• Meant to be used between same sector WCDMA cells with equal coverage Directed RRC Connection
setup for HSDPA layer
areas.
RRC Connection Setup
• UE band capability not known by RNC in this point, not suitable to be used Frequency Info to UE
between different 3G frequency bands.
• Works without Adji definitions, between BTS cells configured under UE in new frequency
common sector id (Sectorid)
• HSDPA Layering for UE’s in Common Channel (CCH layering )

feature redirect UE to other layer during state transition from
Cell_FACH, Cell_PCH. F2
• Meant to be used between same sector (same sectorid) WCDMA cells with
equal coverage areas.
• UE band capability is known by RNC in this point
F1
• Works without Adji definitions, between BTS cells configured under
common sector id (Sectorid)
DRRC for PS
When DRRC triggers,

the new frequency info
is added to RRC
connection setup
message
MBLB Blind HO in RAB setup phase (BIFHORAB)
UE BTS RNC CN
RRC Connection Request
Messaging flow for RAB setup
NPAB Radio Link Setup procedure
phase blind IFHO (valid for RT
RRC Connection Setup
and NRT when Direct Resource
L1 synchronisation
Allocation is in use) RRC Connection Setup Complete
RRC Connection establishment through BTS, UE in Cell_DCH state
Blind HO works with or without
RANAP: RAB Assignment Request
direct resource allocation
RNC makes the decision of the
layering (and BTS change)
NPAB Radio Link Setup procedure (SRB+RB)
User Plane Setup
RRC: Radio Bearer Setup

Frequency Info
UE changes the frequency NBAP: Synchronisation indication
RRC: Radio Bearer Setup Complete
UE in new Frequency layer/band in Cell_DCH state

MBLB Blind HO in RAB setup phase - Frequency Info
When Blind HO is triggered

in RAB setup phase, new
frequency info is included to
Radio Bearer Setup
message
Example Signalling from CELL_PCH
UE is instructed to change RF carrier / operating band / BTS within the Cell Update Confirm message
RRC Connection established, UE in Cell_PCH with connection to PS CN (PS RAB exists)
Downlink Data
RRC: Paging
RNC takes layering and BTS
change decision
NPAB Radio Link Setup procedure (SRB+RB)
User Plane Setup

RRC: Cell Update
(RSCP, Inter-Frequency Measurement)
RACH measurement
quality check
RRC: Cell Update Confirm

Frequency Info
UE changes the frequency NBAP: Synchronisation indication
RRC: Radio Bearer Reconfiguration Complete
UE in new Frequency layer/band under new BTS In Cell_DCH

MBLB Layering in State Transition – Frequency info
New frequency info

included to Cell update
confirm message
MBLB Blind HO in RAB setup phase (BIFHORAB) Example of SIB11
- MBLB
When Blind HO is enabled:

• Intra frequency RACH measurements quantity is changed from EcNo to RSCP with parameter
RACHIntraFreqMesQuant (WCEL)
• Inter-frequency measurement are added for RACH
– Target cell measurements can be used instead of totally blind HO for Rel6 or Newer UEs.
– Inter-frequency measurements can be configured using RACHInterFreqMesQuant (WCEL) Parameter
SIB11/11bis/12 intra and inter-freq RACH measurement
...
-.............intraFreqReportingQuantityForRACH
-................sfn-SFN-OTD-Type: 0 ( noReport)
-................modeSpecificInfo:- fdd
-................intraFreqRepQuantityRACH-FDD: 0 ( cpich_EcN0) 1 (cpich_rscp) via RACHIntraFreqMesQuant
-................maxReportedCellsOnRACH: 1 ( currentCell) 2 (current cell+best neighbour), if MBLB active
-.............interFreqReportingQuantityForRACH RACH inter-freq measurements added (3GPP Rel6 UEs, 25.331)
-................modeSpecificInfo:- fdd
-................intraFreqRepQuantityRACH-FDD: 1 ( cpich_RSCP) Configured for P-CPICH RSCP 1 (cpich_rscp) via RACHInterFreqMesQuant
-................interFreqRACHRepThreshold: -95 configured via BlindHORSCPThrTarget WCEL
-................maxReportedInterFreCellsOnRACH: 8
RRC_CONNECTION_REQUEST (3GPP TS 25.331 ver 8.8.0 Rel 8)
RRC_CONNECTION_REQUEST (3GPP TS 25.331 ver 8.8.0 Rel 8)
UL-CCCH-Message
message
UL-CCCH-Message
rrcConnectionRequest
message
initialUE-Identity
rrcConnectionRequest
tmsi-and-LAI
initialUE-Identity
UE measures and reports RSCP tmsi
Bin : 43 AF 5F 15 (= 1135566613)
tmsi-and-LAI
tmsi
value from current cell and best lai
plmn-Identity
Bin : 63 AC 5F 01 (= 1672240897)
lai
mcc
neighbour cell to RNC in RRC mcc value : 2, 4, 4
plmn-Identity
mcc
mnc
Connection Request and Cell lac
mnc value : 0, 7
mcc value : 2, 4, 4
mnc
mnc value : 0, 7
Update messages Bin : 24 54 (= 9300)
establishmentCause : registration
lac
Bin : 24 54 (= 9300)
protocolErrorIndicator : noError
establishmentCause : registration Measurement quantity
measuredResultsOnRACH
currentCell
protocolErrorIndicator : noError is changed to RSCP
Example here show RRC modeSpecificInfo
measuredResultsOnRACH
currentCell
fdd
Connection request message measurementQuantity
cpich-Ec-N0 : 43 (= -3.0 dB)
modeSpecificInfo
fdd
measurementQuantity
v3d0NonCriticalExtensions
cpich-RSCP : 56 (= -60 dBm)
rRCConnectionRequest-v3d0ext :
monitoredCells
Measurement quantity is EcNo v4b0NonCriticalExtensions
monitoredCells value 1
rrcConnectionRequest-v4b0ext
modeSpecificInfo
and only current cell is measured accessStratumReleaseIndicator : rel-7
fdd
v590NonCriticalExtensions
primaryCPICH-Info
rrcConnectionRequest-v590ext
primaryScramblingCode : 142
predefinedConfigStatusInfo : false
measurementQuantity
cpich-RSCP : 57 (= -59 dBm)
v3d0NonCriticalExtensions
ueCapabilityIndication : hsdch-edch
rRCConnectionRequest-v3d0ext :
domainIndicator : ps-domain
v4b0NonCriticalExtensions
v6b0NonCriticalExtensions
rrcConnectionRequest-v4b0ext
rrcConnectionRequest-v6b0ext :
accessStratumReleaseIndicator : rel-6
v6e0NonCriticalExtensions
rrcConnectionRequest-v6e0ext :
predefinedConfigStatusInfo : false
mac-ehsSupport : true
Content

PS Call Phases
UE BTS DRNC SRNC CN
1. Cell search, BCCH decoding &
RACH access
2. RRC Connection Setup 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
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

• 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
• 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
• 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
RRC Connection Setup (FACH) 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
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)

- Transaction identifier: 00h
The most important part in Activate PDP Context Request Network Serv. Access Point Id
message are the requested QoS fields - NSAPI 5
LLC Serv. Access point Id
- SAPI 3
• As can be seen the UE is requesting all of the QoS Quality of Service
- length: 11 (0Bh)
parameters ‘Subscribed’ which means that the network - Reliab. class: Subscribed (MS only)
uses HLR QoS profile to set-up the QoS - Delay class: Subscribed
- Precedence class: Subscribed
- Peak throughput: Subscribed
• Mean throughput is set to ‘best effort’ - Mean throughput: Best effort
- Traffic class: Subscribed
• The requested IP address is requested to be dynamic, - Delivery order: Subscribed
- Delivery of erroneous SDUs: Subscribed
based on IETF allocated addresses and IPv4 - Maximum SDU size: Subscribed maximum SDU size
- Maximum bit rate for uplink: Subscribed (MS only)
• Access Point is : 07 67 33 67 67 73 6E 31 0A 73 74 61 - Maximum bit rate for downlink: Subscribed (MS only)
- Residual BER: Subscribed
74 64 79 6E 68 6C 72 03 63 6F 6D which corresponds - SDU error ratio: Subscribed
- Transfer delay: Subscribed (MS only)
to the APN set in the UE - Traffic handling priority: Subscribed
- Guaranteed bit rate for uplink: Subscribed (MS only)
- Guaranteed bit rate for downlink: Subscribed (MS only)
Packet Data Protocol Address
- Length: 2 (02h)
- Dynamic PDP addressing is applied
- PDP type organisation: IETF allocated address
- PDP type number: IPv4
Access Point Name
- length: 23 (17h)
- 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 Response 4
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
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
Call Established SGSN

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 and server is open
UE Node B RNC SGSN
Call Established
AAL2SIG:ERQ
AAL2SIG:ECF
FP: Downlink Sync
FP: Uplink Sync

Content

RRC states and transitions
Phys. Reconfiguration
Frequent cell updates After RT call with
inactive PS RABs
Phys. Reconfiguration Fast call setup from
URA Update, UL data, Paging UTRA RRC Connected Mode CELL_PCH
CUCforPCHtoDCHallowed
URA_PCH CELL_PCH
Fast call setup from Phys. Reconfiguration UL/DL
URA_PCH activation timer
CUCforPCHtoDCHallowed
After RT call with inactive

PS RABs & high mobility in CELL_FACH Phys. Reconfiguration
CELL_DCH CELL_DCH Cell Update, UL data, paging
RB. Reconfiguration
Traffic Volume, RACH load
RRC Setup / Release
RB. Reconfiguration
Inactivity Timer, Overload
IDLE Mode
Cell_DCH to Cell_FACH
The transition of the UE from CELL_DCH to CELL_FACH is performed with the Radio Bearer
Reconfiguration message
• It is initiated by the RNC in basis of data transmission inactivity both in UL and DL or low measured
throughput.
• This transition included the release of the BTS and Iub resources reserved for the connection. The
common channel resources are used in CELL_FACH for the data and signalling.
Cell_FACH to Cell_PCH
The transition of the UE from CELL_FACH to CELL_PCH is performed with the Physical Channel
Reconfiguration message
• Is initiated by the RNC in basis of data transmission inactivity both in UL and DL. In CELL_PCH state
the UE is receiving the paging messages.
• Transition to URA_PCH is performed with the same signalling procedure
To URA_PCH
When URA_PCH is enabled, to reduce the unnecessary signalling (cell updates) the UE is moved to the
URA_PCH state if UE has been moving fast (in CELL_DCH state) or when too frequent execution of cell
reselection procedure is observed (in CELL_FACH state).
In CELL_DCH state, UE location is known in cell level and handover process (HA3) can calculate the
velocity of the UE by active set changes needed for the UE.
• If the number of complete active set changes during the time period FastUEPeriod is equal or exceeds
the threshold FastUEThreshold, the RNC (HA3) shall inform RRC signalling entity (MCC via CCM)
about UE which is moving fast. This is used for deciding Cell_PCH or URA_PCH state transitions after
inactivity is detected. Low moving UEs go to CELL_PCH state.
In CELL_FACH state, transition to URA_PCH is performed for high mobility UEs if amount of cell
reselections/updates exceed predefined threshold set by parameter MaxCellReselections within time
defined with parameter CellReselectionObservingTime. If MaxCellReselections is set to 0, URA_PCH is
not possible
Cell_FACH to Cell_DCH
The re-activation of the data connection can be initiated by the UE by using the Cell Update
message (cause UL data transmission) or by the RNC by paging the UE.
• The RNC either keeps the UE in CELL_FACH or moves it to CELL_DCH with the Radio
Bearer Reconfiguration procedure.
Fast Call Setup from PCH
Fast Call setup from PCH can be activated separately

• Enables direct state transition from Cell_PCH to Cell_DCH
• Direct state transition can be done if
• Fast call setup is activated with CUCforPCHtoDCHallowed (RNFC)
• UE must include trafvol indication in cell update confirm message
• CUCEcNoThreshold (default 31 (-9dB)) or CUCRSCPThreshold
(default -92 dBm) must be good enough to trigger fast call setup
otherwise call setup goes via Cell_FACH
Content

ISHO PS Call
UE WBTS RNC CN
NBAP: RL Reconfigure Prepare
Reporting
Event NBAP: RL Reconfigure Ready
Triggered NBAP: RL Reconfigure Commit
RCC: Physical Channel Reconfiguration
RCC: Physical Channel Reconfiguration Complete
BSIC verification
RCC: Measurement Control not often required
for PS
RCC: Cell Change Order from UTRAN RANAP: SRNC Context Request
UE performs LAU to 2G Command
SGSN followed by RAU RANAP: SRNC Context Response
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
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 Relocation “SRNS“ 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 active set
x
Start RelocPrep timer RANAP:Relocation Request
belong to a different RNC
• In successful case after sending the Relocation required
Start RelocOverall timer message to CN there will be Relocation Request sent to
RANAP:Relocation Request Ack
x target RNC
Stop RelocPrep timer User plane set -up • In case of ACK from target RNC there will be RANAP:
RANAP:Relocation Command Relocation Command sent from CN to Source RNC
x • After that the Source RNC sends RANSAP: Relocation
x RNSAP:Relocation Commit Commit message over Iur to the Target RNC
Start RelocOverall timer SRNC operation
started • When target RNC starts SRNC operation and detects that
RANAP:Relocation Detect the relocation is successful there will be RANAP:
UP switching RRC:UTRAN Mobility Information Relocation Detect message sent from target RNC to CN
RRC:UTRAN Mobility Information Confirm • At the same time RRC: UTRAN Mobility Information is sent
Stop RelocOverall timer RANAP:Relocation complete
to the UE and after confirm from UE the target RNC
RANAP:Iu Release
x informs CN with RANAP: Relocation Complete –message
x Stop RelocOverall timer that the relocation procedure was successful and Iu is
RANAP:Iu Release Complete
released from source RNC
User plane release
SRNC Relocation for NRT
RANAP:Relocation Required Procedure is similar with RT but:

x RANAP:Relocation Request
Start RelocPrep timer
• A timer T_Reloc_Inhibit_NRT is started when
Start RelocOverall timer
the HC of the SRNC has made a decision to
RANAP:Relocation Request Ack
x initiate a SRNC Relocation procedure for the
User plane set -up
Stop RelocPrep timer MS using a NRT (only) service in Cell_DCH
RANAP:Relocation Command
x state
Start TDataFwd timer
Data tunnel
• After the reception of the RANAP: Relocation
x RNSAP:Relocation Commit Command message from the CN the Source
Start RelocOverall timer SRNC operation RNC establishes a unidirectional data
started
RANAP:Relocation Detect
forwarding tunnel with the Target RNC and it
UP switching RRC:UTRAN Mobility Information
starts TDataFwd timer.
RRC:UTRAN Mobility Information Confirm
Stop RelocOverall timer
RANAP:Relocation complete
RANAP:Iu Release
x
x Stop RelocOverall timer
RANAP:Iu Release Complete
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 T a rg e t R N C S o u rc e R N C PS CN
M S is in C E L L _ F A C H , C E L L _ P C H
o r U R A _ P C H s ta te
If the state of the MS is T h e M S m o v e s to th e

C E L L _ F A C H s ta te (if
CELL_FACH, CELL_PCH n o t a lre a d y th e re )
or(URA_PCH, the SRNC Relocation R R C :C e ll/U R A U p d a te

[ C e ll/U R A U p d a te C a u s e , U -R N T I ]
R N S A P :U p lin k S ig n a llin g
T ra n s fe r In d ic a tio n
procedure is started in the SRNC [ n e w C -R N T I, D -R N T I, U L m e s s a g e ]
R R C m a k e s re lo c a tio n
when an RRC:Cell/URA Update T h e M S s e le c ts a c e ll c o n tro lle d
b y th e ta rg e t R N C a n d in itia te s
a R R C :C e ll/U R A U p d a te
d e c isio n (S R N C
re lo c a tio n is s u p p o rte d
message is received from the MS p ro c e d u re via th e B T S 2

b y th e D R N C a n d C N )
R A N A P :R e lo c a tio n R e q u ire d
via a target RNC and through the R A N A P :R e lo c a tio n R e q u e s t
RNSAP:UPLINK SIGNALLING R A N A P :R e lo c a tio n R e q u e s t A c k n o w le d g e
TRANSFER INDICATION message . [M a y in c lu d e a d d re s s e s fo r D L P D U s to w a rd s

th e ta rg e t R N C ]
U s e r p la n e e sta b lis h m e n t
R A N A P :R e lo c a tio n C o m m a n d
[M a y in c lu d e a d d re s s e s fo r D L P D U s w h ic h th e
s o u rc e R N C m a y fo rw a rd to th e ta rg e t R N C ]
D a ta F o rw a rd in g (if a d d re s s e s re c e iv e d fro m C N )
R N S A P :R e lo c a tio n C o m m it
R R C :C e ll/U R A U p d a te C o n firm [ D -R N T I ; m a y in c lu d e D ire c t T ra n s fe r
m e s s a g e s a n d R A B C o n te xt in fo rm a tio n ]
[ S -R N T I, S R N C -ID , n e w S -R N T I,
n e w S R N C -ID , (n e w C -R N T I) ]
R A N A P :R e lo c a tio n D e te c t
R R C :U T R A N M o b ility In fo rm a tio n C o n firm
R A N A P :R e lo c a tio n C o m p le te
M S is in C E L L _ F A C H , C E L L _ P C H o r U R A _ P C H sta te
In R A N 1 .5 th e ta rg e t R R C s ta te R A N A P :Iu R e le a s e C o m m a n d
o f th e M S is d e cid e d b a se d o n
th e R R C s ta te in fo rm a tio n
R A N A P :Iu R e le a s e C o m p le te
re c e iv e d fro m th e s o u rc e R N C .
R e s o u rc e
re le a sin g
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 the following parameters:
RANAP:Relocation Required
RANAP:Relocation Request
Information element Presence Comments

• Message Type M, RANAP
• Relocation Type M, RANAP
• Cause M, RANAP
R A N A P c a u s e v a lu e U sage
T im e C r it ic a l R e lo c a t io n U s e d in a ll c o v e r a g e b a s e d r e lo c a ti o n i n itia tio n s
in R A N 1 .5
R e s o u r c e O p ti m is a tio n R e lo c a ti o n U s e d in c a s e s w h e r e a ll R L s in t h e a c ti v e s e t o f
t h e M S a r e l o c a t e d in D R N S
R e l o c a t io n D e s i r a b le fo r R a d io R e a s o n s U s e d in c a s e s w h e r e r e l o c a t io n is t r ig g e r e d b y a
C e ll /U R A u p d a te r e c e iv e d o v e r I u r .
O & M I n t e r v e n t io n T h e s o u r c e c e ll is e m p t ie d b y a f o r c e d H O
p r o c e d u r e . N o t u s e d i n R A N 1 .5
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 showing event MEASUREMENT REPORT

4a (buffer levels exceed the set threshold) value UL-DCCH-Message ::=
integrityCheckInfo
Buffer payload is 256B messageAuthenticationCode '00011100 11100101 11111001 01001000'B,
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
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
AAL2SIG:ECF - procedureCode: 30
- ddMode: common
AAL2SIG:ERQ
AAL2SIG:ECF
- messageDiscriminator: dedicated
FP: Downlink Sync transactionID
FP: Uplink Sync - longTransActionId: 66
FP: Downlink Sync initiatingMessage
FP: Uplink Sync RadioLinkReconfigurationCommit
protocolIEs
- id: 143
NodeB-CommunicationContextID: 160001
- id: 24
After receiving NBAP: RL Reconfiguration Ready message from - criticality: ignore

CFN: 40
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
AAL2SIG:ERQ
message radioBearerReconfiguration : later-than-r3 :
AAL2SIG:ECF 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 message is used to rlc-Info

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

timerMRW te300,
•The H-RNTI given to UE is the same as given to BTS i.e. 00000000 maxMRW mm12
transmissionWindowSize tw128,
00000001 B timerRST tr250,
max-RST rst12,
•Activation time for new configuration is CFN 40 (just like given to pollingInfo
timerPollProhibit tpp100,
the BTS) timerPoll tp240,
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
AAL2SIG:ERQ ATM Conn:10 VPI:1 VCI:120 CID:14 Line:1 CT:0 524
AAL2SIG:ECF 11:26:28.604285
AAL 2
AAL2SIG:ERQ
UUI: 26 (1Ah)
AAL2SIG:ECF
SSSAR-PDU: 7F 0A 0F 00 2A
FP: Downlink Sync HS-DSCH CAPACITY REQUEST
FP: Uplink Sync Control Frame CRC : 63 (3Fh)
FP: Downlink Sync Control Frame Type : 10 (0Ah)
FP: Uplink Sync CmCH-PI : 15 (Fh)

User Buffer Size : 42 (002Ah) octets
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 BTS does know the
status of the buffers in the RNC by the capacity request and by every further data frame . So the BTS 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 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 Allocation
HSDPA Traffic
Direct Resource Allocation for HSPA
Introduction
HSPA transport channels are directly scheduled in the RAB setup phase in Cell_DCH and Cell_FACH state
• Replaces the allocation of a 0/0 kbps DCH
• DRA is used for HSDPA in DL and E-DCH in Uplink connections (HSPA)

• 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
DRA is always used when UE has F-DPCH allocated (even DRA shall not be used in a cell)
Normal NRT RAB Setup HSPA Setup with DRA

RRC connection Setup RRC connection Setup
GPRS Service request + Security GPRS Service request + Security
PDP Context Activation request PDP Context Activation request
RAB assignment request RAB assignment request
Radio Bearer Setup 0/0 (No UP) Radio Bearer Setup to HSPA (direct)
Radio bearer Setup complete Radio bearer Setup complete
RAB assignment Response HSPA bearer Setup for User traffic
PDP context Activate accept RAB assignment Response
TVM start PDP context Activate accept
Measurement Report (TVM) Measurement Control
RB Reconfiguration to HSPA TVM start if needed
RB Reconfiguration Complete
HSPA bearer Setup for User traffic
HSPA setup
With Direct Resource allocation

• HSPA is allocated during RAB
HSPA setup
with DRA
establishment
• Replaces the allocation of a 0/0
kbps DCH
Signalling in CELL_DCH
UE N o d e-B RNC CN
S ig n a llin g lin k e s ta b lis h e d a n d U E in C e ll_ D C H s t a te
R A N A P :R A B A S S IG N M E N T R E Q U E S T [ fo r P S H S P A N R T ]
H S P A c a p a c it y r e q u e s t
establishment f o r d ir e c t r e s o u r c e
a llo c a tio n
• Replaces the allocation of a 0/0 N P A B : R A D IO L IN K R E C O N F I G U R A T I O N P R E P A R E

kbps DCH N P A B : R A D I O L I N K R E C O N F IG U R A T IO N R E A D Y
L 2 r e s o u r c e a llo c a tio n a n d Iu b t r a n s m is s io n s e t u p
G T P tu n n e l c r e a t io n
N P A B : R A D IO L I N K R E C O N F IG U R A T IO N C O M M I T
R R C : R A D IO B E A R E R S E T U P [H S - D S C H + E - D C H ]
R R C : R A D IO B E A R E R S E T U P C O M P L E T E
R A N A P : R A B A S S IG N M E N T R E S P O N S E
I n c a s e o f s u c c e s s f u l D R A , H S P A c o n n e c t io n is e s t a b lis h e d f o r th e u s e r p la n e
Signalling in CELL_FACH
UE N o d e -B RNC CN

S ig n a llin g lin k e s ta b lis h e d a n d U E in C e ll_ F A C H s ta t e a ft e r C o m m o n C h a n n e l s e tu p ( R A N 1 7 9 7 )
establishment
• Moves the UE into CELL_DCH R A N A P :R A B A S S I G N M E N T R E Q U E S T [f o r P S H S P A N R T ]
during RAB establishment H S P A c a p a c ity r e q u e s t fo r

d ir e c t r e s o u r c e a llo c a t io n
• Previously, the UE would be left in N P A B : R A D IO L IN K S E T U P R E Q U E S T
CELL_FACH until after a N P A B : R A D I O L IN K S E T U P R E S P O N S E
subsequent capacity request L 2 r e s o u r c e a llo c a t io n a n d I u b t r a n s m is s io n s e t u p
G T P t u n n e l c r e a t io n
R R C : R A D IO B E A R E R S E T U P [H S - D S C H + E - D C H ]
R R C : R A D IO B E A R E R S E T U P C O M P L E T E
R A N A P : R A B A S S IG N M E N T R E S P O N S E
I n c a s e o f s u c c e s s fu l D R A , H S P A c o n n e c tio n is e s ta b lis h e d fo r t h e u s e r p la n e
Fractional DPCH
• The Fractional DPCH (F-DPCH) was introduced within the release 6 version of the 3GPP specifications
• F-DPCH replaces the downlink DPCCH when the downlink DPDCH is not present, i.e. both application
data and SRB are transferred using HSDPA
• F-DPCH includes Transmit Power Control (TPC) bits but excludes TFCI and Pilot bits
• TFCI bits - no longer required as there is no DPDCH
• Pilot bits - no longer required as TPC bits are used for SIR measurements
• F-DPCH increases efficiency by allowing up to 10 UE to share the same downlink SF256 channelisation
code (time multiplexed one after another)
1 time slot 2560 chips

256
chips
Tx Off TPC Tx Off
Slot #i
HSPA Call Setup with F-DPCH
• Rel99 DCH shall be allocated for SRBs if the establishment cause received from UE is defined to use
DCH for SRBs by the FDPCHSetupEC RNP parameter (bit value of the cause set 1).
• Otherwise it shall follow the allocation of F-DPCH controlled by the FDPCHSetup parameter.
Establishment cause is received from the UE in the RRC: RRC CONNECTION REQUEST message.
• Parameter FDPCHSetup can be used to instruct the RNC when to allocate the F-DPCH (assuming UE
supports it). 3 options available
– (0) RRC Connection Setup message configures F-DPCH and UE is moved into CELL_DCH with an HSPA SRB
– (1) RRC Connection Setup message moves the UE into Cell_FACH. F-DPCH is then allocated immediately
after receiving the RRC connection setup complete message
– (2) RRC Connection setup message moves the UE into CELL_DCH and allocates a DCH connection for the
standalone SRB. F-DPCH is then allocated a the same time as user plane resources
HSPA Call Setup with F-DPCH
• NSN implementation supports release 7 version of F-DPCH

• RRC Connection request message includes a flag which indicates whether or not UE supports
release 7 version of F-DPCH
• RNC can use this information to decide whether or not to allocate F-DPCH
Content from RRC Connection Request message

HSPA Call Setup with F-DPCH FDPCHSetup (1) RRC Connection Setup message
moves the UE into Cell_FACH. F-DPCH is then
allocated immediately after receiving the RRC
Example FDPCHSetup = 1 connection setup complete message
UE BTS RNC CN
RNC establishes RRC
RRC Connection Request (RACH) connection on RACH/FACH and
Support for F-DPCH=TRUE RRC Connection Setup (FACH) waits for RRC Conn. Setup
Complete from the UE
UE in CELL_FACH State
RRC: Initial UE message
RANAP: Initial DIRECT transfer
[Enhanced F-DPCH support=TRUE]
UE support REL7 F-DPCH
NBAP: RL Setup Request
[F-DPCH information]
NBAP: RL Setup Response
[F-DPCH capacity information]
AAL2 Setup F-DPCH setup

RRC: Radio Bearer Reconfiguration
[RRC State Indicator: CELL_DCH; DL F-DPCH Info common for all RL; DL F-DPCH info for each RL]
NBAP: RL Restore Indication
RRC: Radio bearer Reconfiguration complete
UE in CELL_DCH state
NAS Signalling Connection; UE – CN Signalling Continued

RANAP: Security mode command
RRC: Security mode Command
RRC: Security mode Complete

RANAP: Security mode complete
F-DPCH can be used with established service, DRA is

used and all resources immediately available
NBAP: RL reconfiguration prepare
NBAP: RL Reconfiguration ready
NBAP:RL Reconfiguration Commit
RRC: Radio Bearer Setup Complete

RANAP: RAB Assignment Response
DC HSDPA - 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
NPO / A Arjona
*optional
DC HSDPA
RRC Connection RRC Connection Setup

Request message Complete message
includes a flag to includes UE HSDPA
indicate whether Category information
the UE supports
DC-HSDPA
Cat10 if Flexible RLC is
not supported
Cat14 if DC HSDPA is
disabled
Cat24 if DC HSDPA is
enabled in the network
Connection Establishment
• 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
NPO / A Arjona
Connection Establishment
• 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
NPO / A Arjona
Supported RAB Configurations
• DC HSDPA is not allocated to a standalone SRB

• DC HSDPA supports up to 3 Interactive or Background RAB mapped to HSPA
• Streaming RAB can be configured but must be mapped to DCH 0/0 kbps instead of HSPA
• A maximum of 4 MAC-d flows per UE can be configured
• Establishment of a conversational or streaming RAB triggers the release of the DC HSDPA
configuration
• DC HSDPA can be configured after the release of a conversation or streaming RAB
RT PS and CS RAB are rare cases since DC HSDPA is

assumed to be for USB dongles and data cards
NPO / A Arjona
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
NPO / A Arjona
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
PDP Context Activation
Measurement Report : e4a 0/0 kbps DCH

Uplink capacity request allocated
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
Yes No
Uplink NRT RB mapped to DCH>0 kbps HS-DSCH possible to select in the HC HSPA serving cell
downlink selected + Preliminary E-
No Yes DCH active set selected
No Preliminary E-DCH active set is No 3
UE capability supports E-DCH
acceptable
Yes 2 Minimum E-DCH active
UE specific PS Yes
set selected
No HS-DSCH possible to select in the No 4
RAB combination allows use of E-DCH
downlink
Yes Cell specific PS (can be more
Yes than 1)
Traffic class and THP allowed on E- No Number of E-DCH allocations is below No
DCH the maximum
Yes Yes
HSDPA mobility enabled and HS-DSCH No Final E-DCH active set is acceptable
No UE specific PS
available and no IFHO/ISHO
measurements Yes
DCH selected E-DCH DCH
Yes selected selected
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 by
NBAP: Radio Link Reconfiguration Prepare
RNC and sent to the BTS in NBAP
AAL2SIG:ERQ Radio Link Reconfiguration
AAL2SIG:ECF Prepare message)
AAL2SIG:ERQ
AAL2SIG:ECF • DDI = 0 also given by RNC and
Radio Link Reconfiguration Commit sent to the BTS in NBAP Radio
Link Reconfiguration Prepare
message
DL-DCCH-Message {
integrityCheckInfo {
DL-DCCH-Message {
dl-RLC-Mode dl-AM-RLC-Mode : {
• Rlc-PDU-SizeList
messageAuthenticationCode '11100110010000101001010111001000'B,
dl-RLC-PDU-size sizeType2 : {
part1 2 • 3GPP specifies that the RLC PDU
},
message radioBearerReconfiguration : later-than-r3 : {
},
inSequenceDelivery TRUE, size for:
rrc-TransactionIdentifier 0, receivingWindowSize rw2047,
criticalExtensions criticalExtensions-r4 : criticalExtensions-r5 : r6 : {
radioBearerReconfiguration-r6 {
dl-RLC-StatusInfo {
timerStatusProhibit tsp40,
– sizeType2 = (part1 IE x 32) +
activationTime 236,
new-H-RNTI '1001101111001111'B, }
missingPDU-Indicator TRUE
272 bits + (part 2 IE x 8), (part
newPrimary-E-RNTI '0000000000000000'B,
rrc-StateIndicator cell-DCH,
},
rlc-OneSidedReEst FALSE
two optional)
specificationMode complete : { },
rb-InformationReconfigList {
{
rb-MappingInfo {
{
– 2*32+272=336
rb-Identity 5, ul-LogicalChannelMappings oneLogicalChannel : {
rlc-Info { ul-TrCH-Type e-dch : {
ul-RLC-Mode ul-AM-RLC-Mode : { logicalChannelIdentity 1,
transmissionRLC-Discard noDiscard : dat15, e-DCH-MAC-d-FlowIdentity 0,
transmissionWindowSize tw2047, ddi 0,
timerRST tr200, rlc-PDU-SizeList {
max-RST rst12, sizeType2 : {
pollingInfo { part1 2
lastTransmissionPDU-Poll TRUE, }
lastRetransmissionPDU-Poll TRUE, },
timerPollPeriodic tper200 includeInSchedulingInfo TRUE
} },
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 : { {
Measurement Report : e4a ctfc2 0,
powerOffsetInformation {
NBAP: Radio Link Reconfiguration Prepare gainFactorInformation computedGainFactors : 0 } },
Radio Link Reconfigure Ready { ctfc2 1,
powerOffsetInformation {
AAL2SIG:ERQ gainFactorInformation signalledGainFactors : {
AAL2SIG:ECF modeSpecificInfo fdd : {
gainFactorBetaC 15 },
AAL2SIG:ERQ gainFactorBetaD 8,
AAL2SIG:ECF referenceTFC-ID 0 } } } } } } },
ul-deletedTransChInfoList {
Radio Link Reconfiguration Commit dch-usch : {
RRC: Radio Bearer Reconfiguration (DCH) ul-TransportChannelType dch,
ul-TransportChannelIdentity 1 } },
ul-AddReconfTransChInfoList {
e-dch : {
tti tti10,
harq-Info rvtable,
addReconf-MAC-d-FlowList {
E-DCH: { mac-d-FlowIdentity 0,
mac-d-FlowPowerOffset 0,
mac-d-FlowMaxRetrans 3,
• TTI = 10ms transmissionGrantType scheduledTransmissionGrantInfo : NULL} } } },
dl-CommonTransChInfo {
modeSpecificInfo fdd : {
• HARQ info = rvtable (IR in use) dl-Parameters sameAsUL : NULL } },
dl-DeletedTransChInfoList {
• MAC-d flow identity = 0 { dl-TransportChannelType dch : 1 } },

dl-AddReconfTransChInfoList { {
dl-TransportChannelType hsdsch : NULL,
• MAC-d flow power offset = 0 (no need to have different powers tfs-SignallingMode hsdsch : {
harqInfo {
for different MAC-d flows as only one used) numberOfProcesses 6,
memoryPartitioning implicit : NULL },
• MAC-d flowMaxRetrans = 3 (3 retranmissions) addOrReconfMAC-dFlow {

mac-hs-AddReconfQueue-List {
{ mac-hsQueueId 0,
• Grant type is = scheduled mac-dFlowId 0,
reorderingReleaseTimer rt120,
mac-hsWindowSize mws16,
mac-d-PDU-SizeInfo-List { {
mac-d-PDU-Size 336,
mac-d-PDU-Index 0 } } } } } },
dch-QualityTarget {
DL-DCCH-Message {
ul-DPCH-Info {
HSUPA Setup ul-DPCH-PowerControlInfo fdd : {

dpcch-PowerOffset -47,
pc-Preamble 0,
sRB-delay 7,
powerControlAlgorithm algorithm1 : 0,
e-DPCCH-info: deltaACK 6,
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 = SF2x2) e-TFCI-TableIndex 1,

e-DCH-MinimumSet-E-TFCI 4,
reference-E-TFCIs {
{
reference-E-TFCI 11,
3840ksps 11 24/15 12 reference-E-TFCI-PO 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-0.68)=32% of servingGrant {
the bits are punctured as a default value 8,
primary-Secondary-GrantSelector primary } } },
dl-HSPDSCH-Information {
• Max value for 2xSF2 is 0.44 (1-0.44=0.56 i.e. 56% of the bits can be hs-scch-Info {
punctured) hS-SCCHChannelisationCodeInfo {
4 } } },
• Max value for 2xSF2+2xSF4 is 0.38 (1-0.38=0.62 i.e. 62% of the bits measurement-feedback-Info {
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 modeSpecificInfo fdd : {
powerOffsetPilot-pdpdch 0,
spreadingFactorAndPilot sfd256 : pb4,
Initial Grant (serving grant) = 11 => E-TFCI = 3 (primary grant) positionFixedOrFlexible flexible,
tfci-Existence TRUE } },
E-AGCH channelisation code (SF256) = 10 modeSpecificInfo fdd : { } },
dl-InformationPerRL-List { {
E-HICH/E-RGCH channelisation code (SF128) = 6 primaryCPICH-Info {
primaryScramblingCode 96 },
E-HICH signature = 1, E-RGCH signature index =2 servingHSDSCH-RL-indicator TRUE,
servingEDCH-RL-indicator TRUE },
Rg-combinationIndex:Cells with an index equal to the index of the dl-dpchInfo dl-DPCH-InfoPerRL : fdd : {
pCPICH-UsageForChannelEst mayBeUsed,
Serving E-DCH cell belong to the Serving E-DCH RLS dpch-FrameOffset 78,
dl-ChannelisationCodeList { {
• The E-RGCH from these cells have RG commands which for the UE sf-AndCodeNumber sf256 : 14 } },
tpc-CombinationIndex 0 },
are known to be the same as the RG commands from the Serving E- e-AGCH-Information {
e-AGCH-ChannelisationCode 10 },
DCH cell e-HICH-Info e-HICH-Information : {
channelisationCode 6,
signatureSequence 1 },
e-RGCH-Info e-RGCH-Information : {
signatureSequence 2,
HSUPA 5.8Mbps
The peak bit rate on E-DCH for single user is increased up to • To support the UE UL peak rate of 5.8
5.8 Mbps 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 parallel and support 5.76
Mbps at maximum with QPSK modulation
Cch,4,3
Cch,2,1 • 3GPP defines for the usage of 2xSF2 and
E-DPDCH 2xSF4 that no DPDCH (that is no SRB on
(on I- and Q-branches 2SF2 +
2SF4 max) DCH) is allocated at the same time on the
Cch,4,2 UL for this UE
• Therefore the SRB needs to be mapped on
Cch,4,1 E-DCH in this case. This leads to the
dependency on RU20 RAN 1470 SRB's
Cch,2,0 on HSUPA that introduces the mapping of
UL SRB’s on E-DCH
Cch,4,0
SF2 SF4 SF8

HSUPA 5.8 Mbps & 2ms TTI
• 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 2ms TTI – SRB on HSUPA (UL:EDCH)
SRB on HSUPA (UL:EDCH)
UE BTS RNC CN
RRC Connection Establishment with SRB UL/DL DCH
Signalling Between UE and CN
PS-NRT RAB setup, but RB does not have DCH
RRC: Measurement Report (Capacity Request)
NBAP: RL reconfiguration prepare

NBAP: RL Reconfiguration ready
If 2ms TTI is chosen: SRB shall map to AAL2 Setup

UL:E-DCH/DL:3.4kbps DCH and RB
UL:EDCH/DL:HS-DSCH NBAP:RL Reconfiguration Commit

RRC: Radio Bearer Reconfiguration Complete
HSUPA 2ms TTI – SRB on HSUPA (UL:EDCH)
RRC Radio Bearer Reconfiguration for E-DCH 2ms TTI with SRB UL on E-DCH and DL on DCH(3.4kbps)
• RNC shall configure UE with SRB UL:E-DCH/DL:DCH (3.4 kbps), PS-NRT RB UL:E-DCH/DL:HS-
DSCH and E-DCH TTI 2ms after successful configuration in BTS and L2
• RLC parameters for SRB and PS-NRT RAB will be configured as per RRM requirements
(RNC_EFS_981_1470_294)
• SRBs UL channel shall be mapped both on E-DCH (2ms TTI) and RACH and DL channel on DCH (3.4
kpb) and FACH
• RNC shall reconfigure MAC-d flow for SRB as NST and for PS-NRT RAB as ST.
• E-TFCI table “zero” (25.321) shall be used with HSUPA on 2 ms TTI
• UL DCH channel shall not used, if 2ms TTI is selected (SRB on HSUPA)
• Radio Bearer Reconfiguration-> Uplink DPCH info
– “Number of DPDCH” Shall be set to 0
– RNC shall not include Spreading factor, puncturing Limit Radio Bearer Reconfiguration
message – HSUPA 2ms TTI
Radio bearer
reconfiguration message_HSU
HSUPA 2ms TTI
SRB on HSUPA
UL SRB on HSUPA
• Use of 2 ms TTI requires that
Uplink Signaling Radio
Bearers (SRBs) are mapped
on E-DCH. This is required to
make it possible to enable
2xSF2 + 2xSF4 physical
channel configuration that
needed for HSUPA 5.8 Mbps
feature
• The UE also provides periodic
measurement reports if the
SRB is mapped to HSPA
– There is coverage thresholds
• Periodical reporting criteria
are provided in Measurement
Control message
HSUPA 2ms TTI
Switch between HSUPA

10ms TTI and HSUPA
2ms TTI is done using TTI
Radio bearer
reconfiguration
procedure.
• Usage of HSUPA 2ms
TTI depends on radio
conditions (EcNo,
RSCP)
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 Cell Original Serving Cell
UE Node B 2 Node B 1 RNC
HSDPA Traffic
Measurement Report (DCH) – e1A AS update to add new target

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

RRC: Physical Channel Reconfiguration Complete (DCH)
Measurement Report (DCH)
ALCAP : ERQ
ALCAP : ECF
HSDPA Traffic
Measurement Report (DCH) – e1A

NBAP: Radio Link Setup
RRC: Active Set Update Complete (DCH)
Measurement Control Setting up NBAP: Radio Link Reconfiguration Prepare
periodical Ec/No measurements for NBAP: Radio Link Reconfiguration Ready
serving cell change procedure NBAP: Radio Link Reconfiguration Commit

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
RRC: Active Set Update Complete (DCH)
RRC: Measurement Control Old BTS to delete the MAC-d flow and to new BTS
RRC: Physical Channel Reconfiguration Complete (DCH) to set up the MAC-d flow
Measurement Report (DCH) SCC Triggered NBAP: Radio Link Reconfiguration Commit for both
BTSs
NBAP: Radio Link Reconfiguration Prepare to inform the CFN when serving cell change will be
NBAP: Radio Link Reconfiguration Ready taken into use.
ALCAP : ERQ
After Reserving Resources in the new Target cell,
ALCAP : ECF
RNC sends the Radio Bearer reconfiguration
NBAP: Radio Link Reconfiguration Commit message to the UE
Indication successful SCC, the UE send Radio
bearer reconfiguration 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 with its response to Radio Link Setup or Radio Link
Addition messages
• HOPS parameters shown on previous slide are only applicable to drift RNC cells with are neighboured
from the serving RNC
• Serving RNC starts uplink SIR Error measurements over the Iur
• Serving RNC can then use SIR Error measurements for the serving cell change procedure

Drive Test - Signalling Flows PDF

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

Drive Test - Signalling Flows PDF

Uploaded by

Copyright:

Available Formats

WCDMA RAN Optimisation

This material contains WCDMA signalling material, including

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

• Protocol stacks include both user and control planes

AAL2 AAL2 AAL2 AAL2 Link Link

•The Iub protocol stack has three planes

RANAP Iu User Plane

MAC-is/i when Uplink Flexible RLC is

User Plane ATM Stack User Plane IP Stack

ARP – Address Resolution Protocol

SAAL – Signalling ATM Adaptation Layer

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

1. Cell search, BCCH decoding

2. RRC Connection Setup 2

Slot synchronisation to a cell

P-CCPCH, (SFN modulo P-CCPCH, (SFN modulo

The Primary CCPCH is detected using the

RRC: RRC CONNECTION REQUEST (RACH)

NBAP: RADIO LINK SETUP REQUEST

NBAP: RADIO LINK SETUP RESPONSE

RRC: RRC CONNECTION SETUP (FACH)

RRC: CONNECTION SETUP COMPLETE (DCH)

UE initiates the RRC establishment process by sending the RRC

• RRC Connection Request message is sent from the BTS across

0.080 NEC 313, 616

RRC: RRC Connection Request (RACH)

RRC: RRC Connection Setup (FACH)

• Example below shown for N312 = 4

Node B starts transmitting UE starts transmitting

RU20 introduces Fast Layer 1 Synchronisation

• Post verification is completed:

• UE transmit timing no longer depends upon N312

Node B starts UE starts transmitting UE stops transmitting if

RRC: RRC CONNECTION REQUEST (RACH)

NBAP: RADIO LINK SETUP REQUEST

RRC: RRC CONNECTION SETUP (FACH)

• If the feature is enabled, the RNC sets the ‘Post

• DCCH contains the RRC Connection Setup Complete

• Message is sent using Acknowledged mode RLC

• The message contains the UE radio access capability,

INITIAL DIRECT TRANSFER (CM Service Request) SCCP: Connection Request

SCCP: Connection Confirm

Location reporting Control

Security Mode Command

UPLINK DIRECT TRANSFER (Setup, mobile originated side)

DIRECT TRANSFER (Call Proceeding)

UE Node B RNC MGW

RRC Connection Establishment

Initial Direct Transfer (CM Service Request) SCCP: Connection Request

UE Node B RNC MGW

RRC Connection Establishment

Initial Direct Transfer (CM Service Request) SCCP: Connection Request

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

UE Node B RNC MGW

RRC Connection Establishment

Initial Direct Transfer (CM Service Request) SCCP: Connection Request

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

UE Node B RNC MGW

RRC Connection Establishment

Initial Direct Transfer (CM Service Request) SCCP: Connection Request

UE Node B RNC MGW

RRC Connection Establishment

Initial Direct Transfer (CM Service Request) SCCP: Connection Request