Chapter 6 Basic Signaling Procedures

Basic Principles of WCDMA System
Error! Use the Home tab to apply

1 to the text that you want
to appear here.
Chapter 6 Basic Signaling Procedures

6.1 Overview
6.1.1 Types of Signaling Procedures
There are various signaling procedures in the WCDMA system. In the protocol stack
plane, there are signaling procedures in the access stratum and the non-access
stratum; and in the network architecture plane, there are signaling procedures in the
CS domain and the PS domain.
The signaling procedures in the access stratum and the non-access stratum are
classified from the angle of the protocol stack. In the protocol stack, the RRC and
RANAP layers and the protocol layers below them are called the access stratum, and
the protocol layers MM, SM, CC and SMS above them are called the non-access
stratum. Simply speaking, the access stratum signaling procedures refer to the
procedures in which the radio access stratum equipment such as RNC and Node B
shall participate. The non-access stratum signaling procedures refer to the
procedures in which only UE and CN participate. The RNC and Node B in the radio
access network do not participate in these procedures. That is, the access stratum
signaling makes preparation for the signaling exchange of the non-access stratum.
Through the signaling exchange of the access stratum, signaling paths are set up
between UE and CN, so that the UE and the CN can enter the non-access stratum
signaling procedures.
The access stratum procedures comprise PLMN selection, cell selection and radio
resource management procedures. The radio resource management procedures are
the procedures in the RRC layer. They consist of RRC connection setup procedure,
UE-CN signaling setup procedure, RAB setup procedure, call release procedure,
handover procedure and SRNS relocation procedure. Among them, the handover
procedure and the SRNS relocation procedure involve two cases: Inter-RNC, and
inter-SGSN/MSC. In that case, the SGSN/MSC needs to participate in the
procedures. Therefore, in the protocol stack plane, the access stratum procedures
are bottom layer procedures that provide bottom layer bearer for the upper layer
signaling procedures.
The non-access stratum procedures consist of CS mobility management, CS call
control, PS mobility management, and PS session management.
6.1.2 General Introduction

The following gives a simple description of the basic signaling procedures.
First is the service procedure from the UE switch-on, service proceeding to UE
switch-off in the case the subscriber does not move.
2016-07-21
Confidential Information of Huawei. No

Spreading without Permission
Page1, Total68

to appear here.
Figure 1.1 Calling procedure

1)
2)
3)
4)
5)
6)
The UE is switched on and first enters the signaling exchange of the access
stratum. First the UE selects a PLMN (the network of a certain operator) and a
cell, and camps on an appropriate cell. Then it sets up the RRC connection, and
the signaling connection of the Iu interface. By now, a signaling path has been
set up between the UE and the CN for the non-access stratum signaling
procedures through these access stratum signaling procedures.
Then the non-access stratum mobility management procedure starts between
the UE and the CN. The subscriber attach procedure will be executed, which
includes minor procedures such as authentication, ciphering. The location
update procedure will be executed when the subscriber in idle state change the
location.
After passing the procedures such as authentication, the UE enters the servicerelated procedures of the non-access stratum, which includes the CS call
connection procedure and the PS session management procedure. These
procedures establish the service bearer for service proceeding. After that, the
subscriber can start to make a call or access the Internet.
When the subscriber ends the service, the CS call connection procedure or the
PS session management procedure will be executed to release the service
bearer..
If the subscriber powers off the UE at this time, the UE and the CN will use the
non-access stratum mobility management procedure to detach from the CS
domain or the PS domain.
When the non-access stratum signaling exchange ends, the system will use the
access stratum signaling procedures to clear the previously setup lu signaling
connection and the RRC signaling connection.
By now, the service procedure from UE switch-on, service proceeding to UE switchoff ends in the case that the subscriber does not move. As shown in the above, the
service procedure is completed through the coordination of the signaling procedures
of both the access stratum and the non-access stratum. The access stratum signaling
procedures provide signaling bearers for the non-access stratum signaling
procedures.
The following is a called service procedure.
2016-07-21

Page2, Total68

to appear here.
Figure 6.1 Called procedure

1)
2)
3)
4)
5)
6)
The UE of the subscriber is in the idle state. Now it is paged from the network
side.
If there is no available signaling connection between UE and CN, the UE, the
RNC and the CN will enter the access stratum signaling procedures, and set up
the RRC connection and the Iu interface signaling connection.
The authentication and ciphering procedures of mobility management may be
executed.
The service bearer is established through the CS call connection procedure and
the PS session management procedure for service proceeding.
After the service ends, the related service bearer is cleared.
The signaling connections of the access stratum, including the Iu interface
signaling connection and the RRC connection are released.
The above two procedures describe the service proceeding in the case that the
subscriber does not move. The description is simple. Detailed descriptions of the
procedures are given in the subsequent chapters.
Due to the mobility feature of mobile communications, there are a number of
procedures related to mobility processing. For example, if a subscriber changes
his/her location when he/she does not handle any service, mobility management
procedures such as location update will be executed. And if the subscriber changes
his/her location while handling the service, procedures such as handover and SRNS
relocation will be executed.
6.2 UE State and Paging Procedure

6.2.1 UE State
The UE may operate in one of two basic modes: Idle mode and connected mode.
After being switched on, the UE operates in the idle mode and is identified by a nonaccess stratum identification such as IMSI, TMSI or P-TMSI. The UTRAN does not
2016-07-21

Page3, Total68

to appear here.
save the information of the UE operating in the idle mode. It can only page all the UEs
in a cell or all the UEs at one paging time slot.
After establishing an RRC connection, the UE shifts from the idle mode to the
connected mode: CELL_FACH or CELL_DCH state. The connected mode of UE is
also called the RRC state of UE. It reflects the level of the UE connection and the
transport channel that can be used by the UE. When the RRC connection is released,
the UE shifts from the connected mode to the idle mode.
Figure 1.1 Operating modes of the UE

In the connected mode, the UE has altogether four states:
1. CELL_DCH state
The CELL_DCH state features the following:
A dedicated physical channel is allocated to the UE in both the uplink and the
downlink.
RNC knows the cell where the UE camps on according the current active set of
the UE.
The UE can use the dedicated transport channels, downlink/uplink shared
transport channels or the combination of these transport channels.
The UE enters the CELL_DCH state in one of the following two ways:
1)
2)
2016-07-21
In the idle mode, the UE sets up the RRC connection on the dedicated channel,
thus shifting from the idle mode to the CELL_DCH state.
In the CELL_FACH state, the UE uses the common transport channel and then
is converted to the dedicated transport channel, thus shifting from the
CELL_FACH state to the CELL_DCH state.

Page4, Total68

to appear here.
2. CELL_FACH state
The CELL_FACH state features the following:
No dedicated transport channel is allocated to the UE.

The UE continuously monitors a downlink FACH channel.
A default uplink common channel (for example, RACH) or an uplink shared
transport channel is allocated to the UE for the UE to use at any time during the
access procedure.
The cell-level location of the UE is known by the UTRAN, specifically, the cell
reported during the last cell update initiated by UE.
The UE performs the following operations in the CELL_FACH state:
Monitors an FACH.
Monitors the BCH channel of the current serving cell to decode the system
messages.
Initiates a cell update procedure when the cell becomes another UTRA cell.
Uses the C-RNTI allocated in the current cell as the UE identification on the
common transport channel unless a new cell is selected.
Transmits uplink control signaling and small data packets on the RACH.
In the CELL_FACH state, if the data service is not activated in a certain time period,
the UE will enter the CELL_PCH state so as to save the power. In addition, if neither
the UE nor the network side has the data transport requirement after the UE
temporarily exits the CELL_PCH state and executes the cell update, the UE will
return to the CELL_PCH state.
3. CELL_PCH state
The CELL_PCH state features the following:
No dedicated channel is allocated to the UE.

The DRX (discontinuous reception) technology is adopted for the UE to monitor
the information transmitted on the PCH channel at a specific paging time slot.
No uplink activity is allowed.
The cell-level location of the UE is known by the UTRAN, specifically, the cell
reported during the last cell update initiated by the UE in the CELL_FACH state.
The UE performs the following operations in the CELL_PCH state:
Monitors the paging time slot based on the DRX period and receives the paging
messages transmitted on the PCH.
messages.
Initiates the cell update procedure when the cell changes.
The DCCH logical channel cannot be used in this state. To initiate any activity, the
network needs to send a paging request via the PCCH logical channel of the cell
where the UE is.
The UE shifts to the CELL_FACH state in one of the following two ways: By paging
from the UTRAN and by any uplink access.
4. URA_PCH state
The URA_PCH state features the following:
2016-07-21
No dedicated channel is allocated to the UE.

Page5, Total68

to appear here.
The DRX technology is adopted for the UE to monitor the information transmitted
on the PCH channel at a specific paging time slot.
No uplink activity is allowed.
The URA-level location of the UE is known by the UTRAN, specifically, the URA
reported during the last URA update initiated by the UE in the CELL_FACH state.
The UE performs the following operations in the URA_PCH state:
Monitors the paging time slot based on the DRX period and receives the paging
messages transmitted on the PCH.
messages.
Initiates the URA update procedure when the URA changes.
The DCCH logical channel cannot be used in this state. To initiate any activity, the
network needs to send a paging request via the PCCH logical channel of the URA
where the UE is.
No resource is allocated for data transport in the URA_PCH state. Therefore, if the
UE has the data transport requirement, it needs to first shift to the CELL_FACH state.
6.2.2 Paging Procedure

Different from fixed communications, the location of the communication terminal in
mobile communications is not fixed. To establish a call, the CN sends a paging
message to the UTRAN via the Iu interface, and the UTRAN forwards the message to
the UE through the paging procedure on the Uu interface, so that the UE being paged
initiates the signaling connection setup procedure with the CN.
When receiving the paging message from a certain CN domain (CS or PS domain),
the UTRAN first needs to decide whether the UE has established a signaling
connection with another CN domain. If the UE has not established any signaling
connection, the UTRAN can only learn the current service area where the UE is and
will send the paging message (PAGING TYPE 1 message) to the UE via the paging
control channel. If the UE has already established a signaling connection, the UTRAN
can learn the channel where the UE is currently active when the UE is in the
CELL_DCH or CELL_FACH state and will send the paging message (PAGING TYPE
2 message) to the UE via the dedicated control channel. In this sense, the paging
falls into the following two types based on the UE mode and state:
1)
Paging a UE in the idle mode or the PCH state
In this paging type, the PCCH (Paging Control Channel) is used to send paging
messages to the UE in the idle mode or in the CELL_PCH or URA_PCH state to page
it. This paging type has the following functions:
2016-07-21
To establish a call or a signaling connection, the upper layer at the network side
initiates the paging procedure.
To transit the UE state from CELL_PCH or URA_PCH to CELL_FACH, the
UTRAN initiates the paging to trigger the UE state transition.
When the system message changes, the UTRAN initiates the paging of the UE
in the idle mode or in the CELL_PCH or URA_PCH state so as to trigger the UE
to read the updated system information.

Page6, Total68

to appear here.
UTRAN
UE
PAGING TYPE 1
Figure 1.1 Paging a UE in the idle mode or the PCH state

The UTRAN initiates the paging procedure by sending a PAGING TYPE 1 message
at a proper paging time slot via the PCCH. This paging moment is related to the IMSI
of the UE. The UTRAN may page a UE at several paging time slots to let the UE
correctly receive the paging message.
2)
Paging a UE in the CELL_DCH or CELL_FACH state
In this paging type, the dedicated paging message is sent to a UE in the CELL_DCH
or CELL_FACH state.
UTRAN
UE
PAGING TYPE 2
Figure 1.2 Paging a UE in the CELL_DCH or CELL_FACH state

For a UE in the CELL_DCH or CELL_FACH state of the connected mode, the UTRAN
initiates the paging procedure by sending a PAGING TYPE 2 message via the DCCH
(Dedicated Control CHannel). This paging type is also called the dedicated paging
procedure.
6.3 UE in the Idle Mode

6.3.1 Overview
After being switched on or when roaming, the UE needs to find the network and
establish contact with the network in the first place. It can get the network services
only in this way. Therefore, activities of the UE in the idle mode are essential to the
UE. This section describes the procedure for the UE to find the network and establish
contact with the network.
In the UE idle mode, this process falls into PLMN selection and reselection, cell
selection and reselection, and location registration, whose relationship is shown in the
following figure:
2016-07-21

Page7, Total68

to appear here.

User selection
of PLMN
Indication
to user
Automatic/
Manual selection
PLMN Selection
and Reselection
Location
Registration
response
PLMNs
available
PLMN
selected
NAS Control
Cell Selection
and Reselection
Radio measurements
Registration
Area
changes
CM requests
Location
Registration
Figure 1.1 UE in the idle mode

After being switched on, the UE shall first select a PLMN, and then select a cell
belonging to this PLMN. When finding such a cell, the UE can learn the information of
the neighboring cells via the system message (broadcast). Thus, it can select the cell
with the best signal quality from all these cells to camp on. Then the UE initiates the
location registration procedure (attach or location update). After that, the UE camps
on the cell. The residence of the UE has four functions as follows:
The UE can receive the system messages broadcast by the PLMN.

The UE can initiate the random access procedure in the cell.
The UE can receive the paging from the network.
The UE can receive the cell broadcast service.
After the UE camps on the cell and its registration succeeds, the signal strengths of
the current cell and the neighboring cells keep changing as the UE moves. Therefore,
the UE needs to select the most suitable cell. This is the cell reselection procedure.
The most suitable cell may not be the cell with the best signal quality currently. For
example, the UE is at the border of a cell, and moves between two cells that belong
to different LAs or RAs. In this case, the UE keeps initiating the location update, thus
wasting the network resources and the UEs energy. Therefore, the reselection of a
cell from all the cells shall follow a certain rule that is detailed later.
When finding out that the cell selected during the cell reselection belongs to another
LA or RA, the UE shall initiate the location update procedure so that the network can
get the latest location information of the UE. It detects the change of the LA or RA via
the SIB1 in the system broadcast message.
If the location registration or update fails, for example, the network rejects the UE, or
the UE is outside the coverage of the current PLMN, the UE can conduct the PLMN
reselection to select another available PLMN.
2016-07-21

Page8, Total68

to appear here.
6.3.2 PLMN Selection and Reselection

The purpose of PLMN selection and reselection is to select the best PLMN available
(that is, the PLMN that can provide normal services). To achieve this purpose, the UE
will maintain a PLMN list that is sorted by priority, and search the PLMNs from high
priority to low priority, thus finding the PLMN with the highest priority. In addition, there
are two modes of PLMN selection and reselection: Automatic and manual. Simply, the
automatic PLMN selection is the process in which the UE automatically selects a
PLMN by the PLMN priority, while the manual PLMN selection is the process in which
all the currently available PLMNs are presented to the subscriber for the subscriber to
select one of them.
6.3.3 Cell Selection and Reselection

The UE needs to select the cell after selecting the PLMN. It should select the cell with
the best signal quality that belongs to the PLMN.
First, if some information related to the PLMN, such as frequency and scramble, is
stored in the UE, the UE will use the information to conduct cell search (stored
information cell selection). In this way the UE can find the network quickly. In most
cases, the UE is switched off and on again in the same location, for example, UE
switch-off at night and switch-on in the morning. Therefore, such information is stored
in the SIM card or the non-volatile memory of the UE.
1. Cell selection
The cell selection procedure is as follows:
1)
Search for a cell
The cell search aims to find a cell, although the cell may not belong to the selected
PLMN. The cell search procedure is as follows (it is certain that a frequency should
be locked in the first place):
The UE synchronizes the slot via the primary SCH. After that, it shall synchronize the
frame. The frame synchronization is implemented by using the synchronization code
of the secondary SCH. This procedure also determines the scramble group of the
cell. Then the UE finds the scramble with the maximum result value by associating
each scramble in the scramble group with the CPICH. Thus the primary scramble is
determined.
It is obvious that if the UE has already known some information of the cell, such as
the frequency or even the primary scramble, the above procedure can be greatly
speeded up.
2)
Read broadcast channel
The UE obtains the scramble of PCCPCH in Step 1) above. The PCCPCH channel
code is already known and is unique in the entire UTRAN. The UE now can read the
information in the broadcast channel.
2016-07-21
After reading the MIB, the UE can decide whether the PLMN currently found is
the desired PLMN, since the MIB has the PLMN identity field. If yes, the UE will
find the other SIBs and get their contents based on the scheduling information of
the other SIBs in the MIB. If not, the UE has to search for the next frequency and
start the procedure over again (starting from the cell search).
If the current PLMN is the PLMN to be found by the UE, then the UE reads SIB3
and gets Cell selection and re-selection info. It calculates whether the cell
residence standard is satisfied with the acquired information. If the standard is
Page9, Total68

to appear here.
satisfied, then the UE considers the cell as a suitable cell. It then camps on the
cell, reads other necessary system information, and then initiates the location
registration procedure.
If the above conditions are not satisfied, the UE then reads SIB11 and obtains the
neighboring cell information. Then it can calculate and decide whether the
neighboring cell satisfies the cell selection and residence standards.
When finding any neighboring cell satisfying the cell residence standard, the UE will
camp on the cell, read the other necessary system information, and then initiate the
location registration procedure.
If it does not find a cell satisfying the cell residence standard, it will consider that there
is no PLMN coverage, and proceed with the PLMN selection and reselection
procedure.
2. Cell reselection
In the idle mode, the UE needs to monitor the signal quality of the current cell and the
neighboring cell so as to select the best cell to provide the service. This is the cell
reselection procedure. If the cell reselection condition is satisfied within the
Treselection time, the UE will select the cell, camp on the cell, and read its broadcast
message. By now, the cell reselection ends.
3. Cell selection after the UE leaves the connected mode
When transiting from the connected mode to the idle mode, the UE needs to conduct
the cell selection to find a suitable cell. This selection procedure is the same as the
common cell selection procedure. The only difference is that the cell selected at this
time is cell used in the connected mode. If a suitable cell cannot be found from these
cells, the stored information cell selection mode should be adopted.
6.3.4 Location Registration

For these procedures, see MM and GMM procedures.
6.4 Radio Resource Management Procedures

6.4.1 RRC Connection Setup Procedure
In the idle mode, when the non-access layer of the UE requests to establish a
signaling connection, the UE will initiate the RRC connection procedure. Each UE has
up to one RRC connection only.
When the SRNC receives the RRC CONNECTION REQUEST message from the UE,
its RRM (Radio Resource Management) module decides whether to accept or reject
the RRC connection request based on specific algorithm. If it accepts the request, it
will then decide whether to establish a dedicated channel or a common channel. The
RRC connection setup procedure differs with the channel used for the RRC
connection establishment.
2016-07-21

Page10, Total68

to appear here.
1. RRC connection established on a dedicated channel
SRNC
NodeB
UE
1. RRC CONNECTION REQUEST
3. RL SESETUP REQUEST
2. Allocate
RNT1, L1 and
L2 parameters
4. RL SETUP RESPONSE
5. ALCAP establishment and synchronization

6. RRC CONNECTION SETUP
7. RRC CONNECTION SETUP COMPLETE
Figure 1.1 RRC connection established on the dedicated channel

Description:
1)
2)
3)
4)
5)
6)
7)
The UE sends an RRC Connection Request message via the uplink CCCH to
request to establish an RRC connection.
Based on the RRC connection request cause and the system resource state, the
SRNC decides to establish the connection on the dedicated channel, and
allocates the RNTI and L1 and L2 resources.
The SRNC sends a Radio Link Setup Request message to Node B, requesting
the Node B to allocate specific radio link resources required by the RRC
connection.
After successfully preparing the resources, the Node B responds to the SRNC
with the Radio Link Setup Response message.
The SRNC initiates the establishment of Iub user plane transport bearer with the
ALCAP protocol and completes the synchronization between the RNC and the
Node B.
The SRNC sends an RRC Connection Setup message to the UE in the
downlink CCCH.
The UE sends an RRC Connection Setup Complete message to the SRNC in
the uplink DCCH.
By now, the RRC connection setup procedure ends.

2. RRC connection established on a common channel
When the RRC connection is set up on a common channel, since the cell common
resources already established are used, it is unnecessary to set up radio link and
user plane data transport bearer. The rest procedure is similar to that when the RRC
connection is set up in a dedicated channel.
2016-07-21

Page11, Total68

to appear here.
6.4.2 Signaling Setup Procedure

After the RRC connection between the UE and the UTRAN is successfully set up, the
UE sets up a signaling connection with the CN via the RNC for NAS information
exchange between the UE and the CN, such as authentication, service request and
connection setup. This is also called the NAS signaling setup procedure.
For the RNC, the signaling exchanged between the UE and the CN is a direct transfer
message. After receiving the first direct transfer message, that is, the Initial Direct
Transfer message, the RNC sets up a signaling connection with the CN on the SCCP.
The procedure is shown in the following figure:
SRNC
UE
CN
1.RRC INITIAL DIRECT TRANSFER

2.RANAP: INITIAL UE MESSAGE(CR)
3.SCCP CC (Success)
3.SCCP CC (Failure)
Figure 1.1 Signaling setup procedure

The specific procedure is given as follows:
1)
2)
3)
4)
After the RRC connection is established, the UE sends the Initial Direct Transfer
message to the RNC via the RRC connection. This message carries the NAS
information content sent to the CN by the UE.
After receiving the Initial Direct Transfer message from the UE, the RNC sends
the SCCP Connection Request (CR) message to the CN via the Iu interface. The
message content is the Initial UE Message sent from the RNC to the CN, and
carries the message content sent from the UE to the CN.
If the CN is ready to accept the connection request, then it returns the SCCP
Connection Confirm (CC) message to the RNC. The SCCP connection is
successfully set up. The RNC receives the message and confirms the signaling
connection setup success.
If the CN cannot accept the connection request, then it returns the SCCP
Connection Reject (CJ) message to the RNC. The SCCP connection setup fails.
The RNC receives the message and confirms the signaling connection setup
failure. Then it initiates the RRC release procedure.
After the signaling connection is successfully set up, the message sent by the UE to
the CN is forwarded to the RNC via the Uplink Direct Transfer message, and the RNC
converts it into the Direct Transfer message to send to the CN. The message sent by
the CN to the UE is forwarded to the RNC via the Direct Transfer message, and the
RNC converts it into the Downlink Direct Transfer to send to the UE.
6.4.3 RAB Establishment Procedure

The RAB refers to the user plane bearer that is used to transfer voice, data and
multimedia services between the UE and the CN. The UE needs to complete the
RRC connection establishment before setting up the RAB.
2016-07-21

Page12, Total68

to appear here.
The RAB setup is initiated by the CN and executed by the UTRAN. The basic
procedure is as follows:
First the CN sends the RAB assignment request message to the UTRAN,
requesting the UTRAN to establish the RAB.
The SRNC in the UTRAN initiates the establishment of the data transport bearer
between the Iu interface and the Iub interface (Iur interface).
The SRNC sends the RB setup request to the UE.
After completing the RB establishment, the UE responds to the SRNC with the
RB setup complete message.
The SRNC responds to the CN with the RAB assignment response message and
the RAB setup procedure ends.
When the RAB is successfully established, a basic call is set up and the UE enters
the conversation process.
The RAB setup procedure falls into the following three cases based on the radio
resource utilization (the radio resource states when the RRC connection is set up and
when the RAB is set up):
1)
2)
3)
DCH-DCH: The RRC uses the DCH, while the RAB prepares to use the DCH.
RACH/FACH-RACH/FACH: The RRC uses the CCH, while the RAB prepares to
use the CCH.
RACH/FACH-DCH: The RRC uses the CCH, while the RAB prepares to use the
DCH.
Detailed description of the RAB setup procedure is given as follows:

1. DCH-DCH
When the current RRC state of the UE is the DCH (Dedicated CHannel), the assigned
RAB can only be set up on the DCH. According to the RL (radio link) reconfiguration,
the RAB setup procedure falls into two cases: Synchronous RL (DCH-DCH)
reconfiguration and asynchronous RL (DCH-DCH) reconfiguration. Their difference
lies in whether the Node B and the UE can use the new configuration parameters
immediately after receiving the configuration message from the SRNC.
1)
In the synchronous case, after receiving the configuration message from the
SRNC, the Node B and the UE cannot use the new configuration parameters
immediately. Instead, they obtain the synchronization time specified by the
SRNC from the message, and use the new configuration parameters at the
synchronization time.
In the asynchronous case, after receiving the configuration message from the
SRNC, the Node B and the UE immediately use the new configuration
parameters.
Synchronous RL reconfiguration
In the DCH-DCH synchronization case, synchronous reconfiguration of RL is required

among the SRNC, the Node B and the UE.
2016-07-21
After receiving the RL reconfiguration message from the SRNC, the Node B
cannot use the new configuration parameters immediately. Instead, they prepare
the corresponding radio resources, and wait for the reconfiguration commit
message from the SRNC so as to get the synchronization time specified by the
SRNC from the message.
After receiving the configuration message from the SRNC, the UE cannot use
the new configuration parameters immediately. Instead, it gets the
synchronization time specified by the SRNC from the message.
The Node B and the UE use the new configuration parameters at the same time
in the synchronization time specified by the SRNC.
Page13, Total68

to appear here.
The following is the DCH-DCH synchronous RL reconfiguration in the RAB setup

procedure.
UE
NodeB
SRNC
CN
1. RANAP: RAB ASSIGNMENT REQUEST

2. ALCAP establishment
3. RL RECONFIG PRE
4. RL RECONFIG READY
5.ALCAP establishment and synchronization
6. RL RECONFIG COMMIT
7. RRC: RB SETUP
8. RRC: RB SETUP COMPLETE
9. RANAP: RAB ASSIGNMENT RESPONSE
Figure 1.1 RAB setup procedure (DCH-DCH, synchronous)

Description:
2)
The CN sends the RANAP RAB (Radio Access Bearer) Assignment Request
message to the UTRAN to initiate the RAB setup request.
After receiving the RAB setup request, the SRNC maps the QoS parameter of
the RAB as the AAL2 link feature parameter and the radio resource feature
parameter. The ALCAP of the Iu interface initiates the user plane transport
bearer setup procedure of the Iu interface based on the AAL2 link feature
parameter (only for setuping RAB of Iu-CS interface user plane).
The SRNC sends the NBAP Radio Link Reconfiguration Prepare message to its
subordinate Node B, requesting it to prepare to add one (or more) DCH for RAB
bearer on the existing radio link.
The Node B allocates the corresponding resources, and sends the Radio Link
Reconfiguration Ready message to its home SRNC, notifying it that the radio link
reconfiguration is ready.
The ALCAP of the Iub interface in the SRNC initiates the user plane transport
bearer setup procedure of the Iub interface. The Node B and the SRNC establish
synchronization with each other by exchanging the uplink and downlink
synchronization frames of the DCH frame protocol.
The SRNC sends the Radio Link Reconfiguration Commit message to its
subordinate Node B.
The SRNC sends the RRC Radio Bearer Setup message to the UE.
After executing the RB setup, the UE sends the Radio Bearer Setup Complete
message to the SRNC.
After receiving the Radio Bearer Setup Complete message, the SRNC responds
to the CN with the Radio Access Bearer Assignment Response message. The
RAB setup procedure ends.
Asynchronous RL reconfiguration
In the DCH-DCH asynchronous case, synchronous RL reconfiguration is not required

among the SRNC, the Node B and the UE: After receiving the configuration message
from the SRNC, the Node B and the UE immediately use the new configuration
parameters.
The following is the DCH-DCH asynchronous RL reconfiguration in the RAB setup
procedure.
2016-07-21

Page14, Total68

to appear here.
UE
NodeB
SRNC
CN
1. RANAP: RAB ASSIGNMENT REQUEST

3. RL RECONFIG REQ
4. RL RECONFIG RESP
5. ALCAP establishment and synchronization
6. RRC: RB SETUP
7. RRC: RB SETUP COMPLETE
8. RANAP: RAB ASSIGNMENT RESPONSE
Figure 2.1 RAB setup procedure (DCH-DCH, asynchronous)

Description:
The CN sends the RANAP RAB (Radio Access Bearer) Assignment Request
message to the UTRAN to initiate the RAB setup request.
After receiving the RAB setup request, the SRNC maps the QoS parameter of
the RAB as the AAL2 link feature parameter and the radio resource feature
parameter. The ALCAP of the Iu interface initiates the user plane transport
bearer setup procedure of the Iu interface based on the AAL2 link feature
parameter.
In the asynchronous case, synchronization is not required for the radio
reconfiguration. The SRNC sends the NBAP Radio Link Reconfiguration Request
message to its subordinate Node B, requesting it to set up a new DCH on the
existing radio link.
After receiving the Radio Link Reconfiguration Request message, the Node B
allocates the corresponding resources, and sends the Radio Link
Reconfiguration Response message to its home SRNC, notifying it that the radio
link reconfiguration is complete.
The ALCAP of the Iub interface in the SRNC initiates the user plane transport
bearer setup procedure of the Iub interface. The Node B and the SRNC establish
synchronization with each other by exchanging the uplink and downlink
synchronization frames of the DCH frame protocol.
The SRNC sends the RRC Radio Bearer Setup message to the UE.
After executing the RB setup, the UE sends the Radio Bearer Setup Complete
message to the SRNC.
After receiving the Radio Bearer Setup Complete message, the SRNC responds
to the CN with the Radio Access Bearer Assignment Response message. The
RAB setup procedure ends.
6.4.4 Call Release Procedure

The call release procedure is the RRC connection release procedure. The RRC
connection release procedure falls into two types: UE-initiated release and CNinitiated release. The difference between the two release types lies in who sends the
call release request message of the upper layer first, though the final resource
release is initiated by the CN.
After deciding to release a call, the CN sends the IU RELEASE COMMAND message
to the SRNC. The SRNC takes the following steps after receiving the release
command:
2016-07-21

Page15, Total68

to appear here.
1)
2)
3)
Returns the IU RELEASE COMPLETE message to the CN.

Initiates the release of the user plane transport bearer of the Iu interface.
Releases the RRC connection.
The RRC release is to release the signaling link and all the radio bearers between the
UE and the UTRAN. Based on the resources seized by the RRC connection, the RRC
release can be further divided into two types: Release of the RRC connection
established on a dedicated channel, and release of the RRC connection established
on a common channel.
1. Release of the RRC connection established on a dedicated channel
UE
NodeB
SRNC
1. RRC: RRC CONNECTION RELEASE

2. RRC: RRC CONNECTION RELEASE COMPLETE
3. RL DELETION
4. RL DELETION RESPONSE
5. ALCAP release
Figure 3.1 Release of the RRC connection established on a dedicated channel

Description:
1)
2)
3)
4)
5)
The RNC sends the RRC Connection Release message to the UE.
The UE returns the RRC Connection Release Complete message to the RNC.
The RNC sends the Radio Link Deletion message to the Node B to delete the
radio link resources in the Node B.
After releasing its related resources, the Node B returns the Radio Link
Deletion Response message to the RNC.
The RNC initiates the ALCAP release of the user plane transport bearer of the Iu
interface.
In the end, the RNC initiates the local L2 resource release again. By now, the RRC
connection release procedure ends.
2. Release of the RRC connection established on a common channel
During the release of the RRC connection established on a common channel, since
the cell common resources are used, it is only necessary to release the UE directly
instead of releasing the Node B resources and the data transport bearer.
6.4.5 Handover Procedure

The handover procedure is a characteristic distinguishing the mobile communication
from the fixed communication. When the cell or the mode (FDD or TDD) used by the
UE changes, we say the UE performs the handover. The WCDMA system supports
the following types of handover: Soft handover, hard handover, forward handover, and
inter-system handover. The soft handover and the hard handover are initiated by the
network side, the forward handover is initiated by the UE, and the inter-system
handover can be initiated by both the network side and the UE. The causes of the
2016-07-21

Page16, Total68

to appear here.
handover include UE movement, resource optimization configuration, and manual

interference, etc.
1. Soft handover
In the WCDMA system, since the intra-frequency exists among neighboring cells, the
UE can communicate with the network via multiple radio links, and can select one
with good signal quality by comparison when these radio links are merged, thus
optimizing the communication quality. The soft handover can be conducted only in the
FDD mode. The soft handover falls into the following cases according to the locations
of the cells. The first case is the soft handover among difference cells of the Node B.
In this case, the radio links can be merged within the Node B or the SRNC. If they are
merged within the Node B, it is called softer handover. The second case is the soft
handover among different Node Bs within the same RNC and among different RNCs.
An important issue during the soft handover is the merge of multiple radio links. In the
WCDMA system, the MACRO DIVERSITY technology is adopted for the merge of the
radio links, that is, the system compares the data from different radio links based on
certain standards (such as BER), and selects the data with better quality to send to
the upper layer.
The following are some key concepts about the neighboring cell in the soft handover:
1)
2)
3)
Active set: The set of cells currently used by the UE. The execution result of the
soft handover indicates the increase or decrease of the cells in the active set.
Observation set: The set of cells that are not in the active set but are being
observed by the UE based on the neighboring cell information from the UTRAN.
The UE measures the cells in the observation set. When the measurement
results satisfy certain conditions, the cells may be added to the active set.
Therefore, the observation set sometimes is also called the candidate set.
Detected set: The set of cells that have been detected by the UE but do not
belong to the active set or the observation set. The UTRAN can request the UE
to report the measurement result of the detected set. Since the cells in the
detected set are not listed in the neighboring cell list, this set is also called the
unlisted set.
The soft handover procedure comprises the following steps:

1)
2)
3)
4)
5)
Based on the measurement control information from the RNC, the UE measures
the intra-frequency neighboring cells, and reports the measurement result to the
RNC after processing.
The RNC compares the reported measurement result with the set threshold to
decide the cells to be added and deleted.
If some cells are to be added, the RNC notifies the Node B to get ready.
The RNC notifies the UE to add and/or delete cells via the active set update
message.
After the UE successfully update the active set, if the cells are deleted, the Node
B will be notified to release the corresponding resources.
The original communication is not affected during the soft handover procedure so that
smooth handover from a cell to another can be successfully completed.
2. Hard handover
In the case the neighboring cells are inter-frequency cells, hard handover instead of
soft handover can be conducted. In the hard handover procedure, the communication
with the previous cells is interrupted first, and then is connected with new cells.
Therefore, the soft handover performance is not as good as soft handover. Generally,
the hard handover is considered only when the soft handover cannot be conducted.
2016-07-21

Page17, Total68

to appear here.
The target cell of hard handover may not be measured. It is applicable for the hard
handover in emergency, but it has a high failure ratio. In the common hard handover,
it is necessary to measure the target cell. However, the UE is generally configured
with only one decoder, it cannot decode signals of two frequencies simultaneously.
Therefore, to enable the UE to conduct inter-frequency measurement, the
compressed mode technology is introduced into the WCDMA system.
One frame
(10 ms)
Idle period available for

inter-frequency measurements
Figure 5.1 Operating mechanism of the compressed mode

The basic operating mechanism of the compressed mode technology is: When
sending some frames (the data sent per 10ms is a frame), the Node B speeds up to
send the data that are previously sent in 10ms in less than 10ms, so that the UE can
use the time saved to conduct inter-frequency measurement. The mode and time for
increasing the transmit rate is controlled by the RNC.
Similar to soft handover, the hard handover falls into the following types based on the
location relationship between the source cell and the target cell.
1)
2)
3)
4)
Hard handover between FDD and TDD in the same cell.

Hard handover among cells in a Node B.
Hard handover among cells in different Node Bs in the same RNC.
Hard handover among cells in different RNCs.
Generally, when hard handover occurs between different RNCs, both RNCs have the
Iur interface. Otherwise, the hand handover should be completed via relocation.
There are 5 signaling procedures at the Uu interface to complete the hard handover:
1)
2)
3)
4)
5)
Physical channel reconfiguration.

Transport channel reconfiguration.
Radio bear setup.
Radio bear release.
Radio bear reconfiguration.
The following figure gives the hard handover signaling procedure of cells in different
Node Bs by taking the physical channel reconfiguration as an example
2016-07-21

Page18, Total68

to appear here.

Target NodeB
UE
Old NodeB
SRNC
1. RADIO LINK SETUP REQUEST

2. RADIO LINK SETUP RESPONSE
4. PHYSICAL CHANNEL RECONFIGURATION
5. RADIO LINK
FAILURE INDICATION
6. PHYSICAL CHANNEL RECONFIGURATION COMPLETE
7. RADIO LINK
DELETION REQUEST
8. RADIO LINK
DELETION RESPONSE
9. ALCAP release
Figure 5.1 Hard handover procedure

Description:
1)
2)
3)
4)
5)
6)
7)
8)
9)
The SRNC sends the Radio Link Setup Request message to the Node B where
the target cell is, requesting the Node B to establish a radio link.
The Node B where the target cell is sends the Radio Link Setup Response
message to the SRNC, indicating the radio link is successfully established.
The SRNC adopts the ALCAP protocol to set up the Iub interface transport
bearer between the SRNC and the target Node B, and synchronizes the FP.
The SRNC sends the Physical Channel Reconfiguration message carrying the
target cell information to the UE via the downlink DCCH.
After the UE hands over from the source cell to the target cell, the Node B of the
source cell detects the radio link communication failure and then sends the
Radio Link Failure Indication message to the SRNC, indicating the radio link
failure.
After successfully handing over to the target cell, the UE sends the Physical
Channel Reconfiguration Complete message to the SRNC via the DCCH,
notifying the SRNC that the physical cannel reconfiguration is complete.
The SRNC sends the Radio Link Deletion Request message to the Node B
where the source cell is, requesting the Node B to delete the radio link of the
source cell.
The Node B where the source cell is deletes the radio link resources, and then
responds to the SRNC with the Radio Link Deletion Response message.
The SRNC adopts the ALCAP protocol to release the Iub interface transport
bearer of the SRNC and the Node B where the source cell is.
3. Forward handover
Forward handover is a part of the RRC connection mobility management. The forward
handover consists of cell update and URA update. It is used to timely update the UErelated information at the UTRAN side when the UE location changes. It can also be
used to monitor the RRC connection, switch the RRC connection state, and report
errors and forward information. For both the cell update and the URA update, the
update procedure is initiated by the UE.
1)
2016-07-21
Cell update
Page19, Total68

to appear here.
The UE in the CELL_FACH, CELL_PCH or URA_PCH can initiate the cell update
procedure. There are different cell update causes and cell update procedures for
different connection states.
In the case the cell update cause is periodical cell update, and the UTRAN side
does not allocate CRNTI or URNTI to the UE, the procedure is as follows:
UE
UTRAN
1. CELL
UPDATE
2. CELL UPDATE CONFIRM
Figure 1.1 Cell update procedure

2)
The UE sends the CELL UPDATE message to the UTRAN via the CCCH.
After processing the CELL UPDATE message received from the UE, the UTRAN
sends the CELL UPDATE CONFIRM message to the UE. The cell update ends
at the UTRAN side, and it ends at the UE side after the UE receives the CELL
UPDATE CONFIRM message.
Physical channel reconfiguration will accompany the procedure in the following
two cases: 1) The cell update cause is there is uplink data transport or response
to paging, the UTRAN side does not allocate CRNTI or URNTI to the UE or
indicate the related physical channel information, and the TFS/TFCS saved in
the UE is the same as that in the PRACH/SCCPCH broadcasted by the system
message; 2) The cell update cause is there are uplink data, or response to
paging, or cell reselection, the UTRAN side allocates CRNTI or URNTI to the UE
but does not indicate the related physical channel information, and the
TFS/TFCS saved in the UE is the same as that in the PRACH/SCCPCH
broadcasted by the system message.
Transport channel reconfiguration will accompany the procedure in the following
two cases: 1) The cell update cause is there is uplink data transport or response
to paging, the UTRAN side does not allocate CRNTI or URNTI to the UE or
indicate the related physical channel information, and the TFS/TFCS saved in
the UE differs from that in the PRACH/SCCPCH broadcasted by the system
message; 2) The cell update cause is there are uplink data, or response to
paging, or cell reselection, the UTRAN side allocates CRNTI or URNTI to the UE
but does not indicate the related physical channel information, and the
TFS/TFCS saved in the UE differs from that in the PRACH/SCCPCH
broadcasted by the system message.
In the case the cell update cause is periodical update, the UTRAN side allocate
CRNTI or URNTI to the UE but does not indicate the related physical channel
information, the UE will update its identification, that is, the RNTI reallocation will
accompany the procedure.
URA update
The purpose of the URA update procedure is that the UE in the URA_PCH state uses
the current URA to update the UTRAN after the URA reselection. This procedure can
also be used to monitor the RRC connection when there is no URA reselection.
Several different URA IDs can be broadcast in a cell, and different UEs in a cell can
2016-07-21

Page20, Total68

to appear here.
belong to different URAs. There is one and only one valid URA when the UE is in the
URA_PCH state. When the UE is in the URA_PCH state, if the URA assigned to the
UE is not in the URA ID list broadcast in the cell, the UE will initiate the URA update
procedure. Or, if the UE is in the service area but T306 expires, the UE will also
initiate the URA update procedure.
In the case the UTRAN does not allocate a new CRNTI or URNTI to the UE
during the URA update procedure, the procedure is as follows:
UE
UTRAN
1. URA UPDATE
2. URA UPDATE CONFIRM
Figure 2.1 URA update procedure (no new CRNTI or URNTI allocated)
The UE sends the URA UPDATE message to the UTRAN via the CCCH.
After processing the URA UPDATE message received from the UE, the UTRAN
sends the URA UPDATE CONFIRM message to the UE and ends the URA
update at its end. The URA update procedure ends at the UE side after the UE
receives the URA UPDATE CONFIRM message.
During the URA update procedure, if the UTRAN allocates a new CRNTI or
URNTI to the UE, then there is the RNTI REALLOCATION COMPLETE
message sent by the UE to the UTRAN in the procedure.
4. Inter-system handover
The WCDMA system supports UE handover between the UTRAN and the existing
systems (such as the GSM/GPRS). The inter-system handover falls into two cases:
Handover under network control (such as the GSM) and cell reselection of the UE
(such as GPRS), both of which are further divided into handover-to UTRAN and
handover-from UTRAN cases. The following details the inter-system handover
procedure by taking the handover-to UTRAN under the network control as an
example only. It only covers the signaling in the UTRAN.
2016-07-21
Handover to UTRAN

Page21, Total68

to appear here.
CN
UTRAN
UE
1.RELOCATION REQUEST
2. RELOCATION REQUEST
ACKNOWLEDGE
3. HANDOVER TO UTRAN
COMPLETE
Figure 2.2 Handover-to UTRAN procedure

1)
2)
3)
The CN notifies the UTRAN that a UE is to be handed over to it via the

Relocation Request message.
After getting the resources ready, the UTRAN sends the Relocation Request
Acknowledge message to the CN. This message carries the Handover To
UTRAN Command message that is to be forwarded to the UE by the peer
system.
After successfully handed over to the UTRAN, the UE sends the Handover To
UTRAN Complete message to the UTRAN.
6.4.6 SRNS Relocation

The RNC relocation refers to that the SRNC of the UE changes from one RNC to
another RNC. It is divided into two cases based on the UE location at the time of
relocation: Static relocation and associated relocation, or in other words, UE Not
Involved and UE Involved.
1. Static relocation
The precondition for the static relocation is that the UE accesses the network from
one and only one DRNC. Since the relocation procedure does not require the UEs
participation, it is also called the UE Not Involved relocation. The following is an
example of two radio links. After the relocation, the original DRNC becomes the
SRNC, the Iur interface connection is released, and the Iu interface migrates, as
shown in the following figure:
CN
CN
SRNC
Old SRNC
DRNC
NODEB
CELL
NODEB
NODEB
CELL
CELL
CELL
SRNC
CELL
NODEB
CELL
CELL
CELL
UE
UE
Figure 1.1 Static relocation procedure

2016-07-21

Page22, Total68

to appear here.
There are two CN domains in the WCDMA system. When the relocation occurs, if the
UE has connections with both of the CN domains, then the domains must be migrated
at the same time.
2. Associated relocation
Associated relocation refers to that the UE accesses the target RNC from the SRNC
via hard handover, and the Iu interface changes at the same time. Since the
relocation procedure requires the UEs participation, it is also called the UE Involved
relocation. The connection change is shown in the following figure:
CN
SRNC
CN
Target RNC
NODEB
CELL
Old SRNC
NODEB
CELL
CELL
CELL
SRNC
NODEB
CELL
CELL
NODEB
CELL
CELL
UE
UE
Figure 1.2 Associated relocation procedure

The 5 signaling procedures that can complete the hard handover can be used to
complete the associated relocation.
6.5 CS Domain Mobility Management Procedures

6.5.1 Location Update
The location update procedure is completed through logical coordination between
entities such as HLR and MSC/VLR. The HLR stores the current location information
of each mobile subscriber and all the subscriber data; the VLR stores the subscriber
data of the subscribers roaming to the location area under its control; and the MSC
processes the location registration procedure of each mobile subscriber, has dialog
with the mobile subscribers and exchanges information with HLR and VLR.
The location update procedure includes location registration, periodic location
registration and subscriber data deletion.
1. Location registration
It is to execute the Update Location operation of MAP. Different types of location
registration can be distinguished through the Update Location Type parameter in the
Update Location Request message.
The following condition can trigger the normal location registration procedure of a
mobile subscriber:
2016-07-21

Page23, Total68

to appear here.
When the UE is switched on or the mobile subscriber roams to cause the change of
his location. The Update Location Type indicates IMSI Attach in the case of UE
switch-on while Normal Updating in the case of subscriber roaming.
The UE compares the LAI in the broadcast message it has received with the LAI
stored in itself. If these two LAIs are the same, the UE will initiate the IMSI Attach
procedure; otherwise it will initiate the Normal Updating operation.
2. Periodic location registration
It is to execute the Update Location operation of MAP and the Update Location Type
parameter in the Update Location Request message indicates Periodic Updating.
Through periodic location registration (location update), the PLMN can keep track of
the current state of each mobile subscriber, especially those subscribers that have no
operation for a long period of time. The location update period and the protection time
can be set and adjusted by the PLMN operator according to the specific traffic and
subscriber habits.
3. Subscriber data deletion
It is to execute the Cancel Location operation of MAP.
Through subscriber data deletion, subscriber records can be deleted from the VLR
and the cases include the subscriber data deletion caused by subscriber roaming,
that caused by no subscriber operation for a long period of time and the deletion of
the invalid subscriber data by system administrators.
The purpose of subscriber data deletion is to enable the HLR to delete the old
subscriber information in the VLR at the time of location update or enable the
independent location deletion triggered by subscriber data modification and allow
operating staff to delete the subscriber location information.
The following figure depicts a typical location update flow that basically comprises the
above three procedures.
2016-07-21

Page24, Total68

to appear here.
Figure 1.1 Location update flow

1)
A.
B.
2)
3)
4)
The MSC/VLR receives the location update request initiated by the subscriber
with TMSI. If the TMSI is not known:
If the carried old location information indicates the location area of an adjacent
VLR, the MSC/VLR will initiate the procedure for getting the identification from
PVLR. For details, refer to the SEND IDENTIFICATION procedure indicated in
the above figure.
If the old location area is one of a non-adjacent VLR or the request for
identification from PVLR fails, the MSC/VLR will initiate a procedure (not
indicated in the above figure) to request the UE to provide the IMSI. For details,
refer to the subsequent sections.
If it is the first time for the subscriber to register its location in the current VLR, a
location update request will be initiated to the HLR. Otherwise, the LOCATION
UPDATING ACCEPT procedure will follow directly.
If the HLR finds that the MSC/VLR number involved in subscriber roaming has
changed upon receipt of the location update request from MSC/VLR, it will
initiate the CANCEL LOCATION procedure to PVLR so as to delete the
subscriber information in PVLR.
If the roaming request is rejected, the HLR will directly initiate a location update
response with the reject information to the MSC/VLR; otherwise it will insert
subscriber data to the MSC/VLR before deciding to accept or reject the location
update request according to the result of subscriber data insertion.
6.5.2 Detachment
The detachment procedure is the procedure of IMSI Detach initiated by the UE upon
switch-off, after which the MSC/VLR will set the subscriber state to IMSI detached. It
should be noted that this procedure will not be notified to the HLR. This is different
from the Purge procedure, because the HLR contains no Detach/Attach state
indicator bit for the subscriber but the Purge procedure involves this indicator bit. For
details, refer to the subsequent Purge operation descriptions.
2016-07-21

Page25, Total68

to appear here.
If the subscriber is called, the HLR will request for a roaming number from VLR
through the Provide Roaming Number procedure. Since the subscriber is detached,
the Provide Roaming Number procedure will fail with the cause value of Absent
Subscriber returned and the calling MSC will play the subscriber switch-off
announcement to the calling UE according to this cause value.
The detachment procedure is shown in the following figure.
Figure 1.1 Switch-off procedure

For some models of UEs, the Detach procedure may also be initiated if the UE is
switched off during the conversation.
6.5.3 Identification
The identification procedure takes place at the Iu interface so that the network can
provide IMEI or IMSI information to the UE. The Identity procedure is executed for
subscriber identification.
There are two types of Identity procedures:
When the VLR does not contain any IMEI of the UE, one Identity procedure will
be forced for execution and the network will initiate a request for the IMEI to the
UE through the Identity Request message while the UE will provide the IMEI to
the network through the Identity Response message.
The typical cases are the first location update of the UE, the invalidity of subscriber
IMEI stored in the VLR (note that this will not affect the subscribers since presently
IMEI authentication is not yet applied).
When the TMSI is unidentifiable during location update, one Identity procedure
will also be forced for execution and the network will initiate a request for the
IMSI to the UE through the Identity Request message while the UE will provide
the IMSI to the network through the Identity Response message.
The typical cases include subscriber roaming and the areas without using the TMSI.
Figure 1.1 IDENTITY procedure

2016-07-21

Page26, Total68

to appear here.
6.5.4 Purge
The Purge procedure refers to the VLR-initiated purge MS procedure, that is, the
Purge UE procedure in MAP. It is used for the VLR to report its subscriber deletion
operation to the HLR. Different from the IMSI Detach procedure described in the
previous section, the Purge UE procedure should be notified to the HLR, so that the
HLR will set the UE Purge Flag of this UE upon receipt of the Purge UE message to
indicate that the subscriber data have been purged from the VLR.
If the subscriber is called, the HLR will query the UE Purge Flag when the calling UE
queries the HLR in the Send Routing Information procedure. Since the UE Purge Flag
has been set, the HLR will return the cause value of Absent Subscriber to the MSC
and the calling MSC will play the subscriber switch-off announcement to the calling
UE according to this cause value. This procedure does not involve the Provide
Roaming Number operation from the HLR to the VLR.
Figure 1.1 PURGE procedure
6.5.5 Authentication Procedure

A successful authentication procedure can be expressed by a flow chart, as shown in
the following figure.
Figure 1.1 Authentication success

The authentication procedure is initiated by the network to check if the UE is allowed
to access the network, provide the random number array in the authentication
quintuple for the UE to calculate the Ciphering Key (CK), allow the UE to calculate the
Integrity Key (IK) for consistency check between the UE and the network, as well as
providing the UEs authentication of the network.
Compared with the GSM authentication procedure, the 3G authentication procedure
has the additional consistency check function and the function of the UE to
authenticate the network. All these functions contribute to the enhanced 3G security
features.
2016-07-21

Page27, Total68

to appear here.
Before the network initiates the authentication procedure and if the VLR does not
contain any authentication quintuple, the procedure of requesting an authentication
set from the HLR will be initiated to wait for the return of the authentication quintuple.
The authentication quintuple contains such information as RAND, XRES, AUTN, CK
and IK.
After detecting the presence of the authentication quintuple, the network will send an
authentication request message, which contains the RAND and AUTN information of
a certain quintuple. Upon receipt of this message, the UE will have its USIM card
check the AUTN, that is, the UE will authenticate the network. If the network is
accepted, the USIM card will use the RAND to calculate the CK, the IK and the RES.
If the USIM card determines that the authentication succeeds, the RES will be
returned in the authentication response message.
Upon receipt of the authentication response message, the network will compare the
RES in this message with the XRES in the authentication quintuple stored in the VLR
database to verify if the authentication is successful or not. If the authentication is
successful, the subsequent procedures will normally continue; otherwise the
exception handling procedure will be initiated to release the connection between the
network and the UE as well as the occupied network and radio resources.
After the successful authentication, the UE will store the CK and the IK in its USIM
card.
In some cases, the UE will report authentication failure upon receipt of the
authentication request message. There are two typical causes of authentication
failure:
When authenticating the network, the UE will check the AUTN parameter in the
authentication request message sent from the network. If the MAC information is
incorrect, the UE will report the authentication failure information with the cause value
being MAC Failure.
Figure 1.2 Authentication failure (cause value: MAC Failure)

At this time, the network will decide if to initiate the Identity procedure according to the
subscriber identity reported by the UE. If the current identity is TMSI or P-TMSI, it will
2016-07-21

Page28, Total68

to appear here.
initiate the Identity procedure and request the UE to report the IMSI information
before re-initiating the authentication procedure.
Another cause of authentication failure is that the UE detects the SQN error in the
AUTN message with the cause value being Synch failure.
Figure 1.3 Authentication failure (cause value: Synch failure)

At this time, the VLR at the network side will delete all the authentication quintuples
and initiate the procedure of synchronization to the HLR to request the HLR to reinsert the authentication quintuple before the re-authentication procedure is started.
6.5.6 Secure Mode Control

The secure mode control procedure is used by the network to send ciphering
information to the RAN. In this process, the core network will negotiate with the RAN
on the ciphering algorithm for the UE so that the UE can use this ciphering algorithm
in the subsequent service transfer procedure and shall try the best to use this
ciphering algorithm after the UE handover, that is, the relevant parameters for
ciphering will be sent to the handover destination RNC.
Figure 1.1 Secure mode control
6.5.7 TMSI Reallocation

A TMSI (Temporary Mobile Subscriber Identity) is a series of digits (4 bytes)
temporarily assigned to a subscriber. It is managed by the MSC/VLR, assigned to a
subscriber when the subscriber is registered for the first time in a location area and
deleted when the subscriber leaves this location area. It is used to uniquely identify
2016-07-21

Page29, Total68

to appear here.
the MS in a location area and is transmitted on the radio channels in place of IMSI to
prevent any third party from intercepting the signals over the radio channels and/or
tracking the mobile subscriber. Therefore, the basic purpose of TMSI is to enhance
the security of the MS.
The correspondence between TMSIs and IMSIs is stored in the VLR that manages
the current visited location area of the MS, and the new TMSI is also stored in the
SIM card of the MS. We can see that the TMSI is stored in both the VLR and the SIM
card.
The TMSI reallocation procedure may take place during subscriber location update,
call setup and supplementary service procedures. It can be implemented by selecting
the execution of the TMSI reallocation procedure in the MAP functional procedures of
MSC.
The TMSI reallocation procedure during location update is integrated with the location
update accept. The flow chart is shown in the following figure:
Figure 1.1 TMSI reallocation during location update
2016-07-21

Page30, Total68

to appear here.
& Note:
Among the mobility management procedures, the procedures of authentication, security mode control
and TMSI reallocation are optional and network operators may decide whether to activate or provision
them.
For example, this is implemented by the MAP functional procedure configuration parameters in the
MSC9800.
6.5.8 Combined Location Update

When both the location area and the routing area of a UE have changed, the
combined location update procedure will be initiated and the location update
procedure will be initiated simultaneously in the PS domain and the CS domain. The
CS domain at the network side is connected via the Gs interface with the PS domain
(when the CS domain and the CS domain of the core network are separated in the
networking, the following descriptions will use the MSC to represent the CS domain
while the SGSN to represent the PS domain). The Gs interface adopts the BSSAP+
protocol in the SS7 signaling system and enables the CS domain and the PS domain
to mutually update the MS location information stored in the databases, so as to
reduce the air interface signaling and help the MSC page the Class B MS ongoing
with the GPRS service.
The following figure shows a typical combined location update procedure.
2016-07-21

Page31, Total68

to appear here.
Figure 1.1 Combined location update

1)
2)
3)
4)
5)
2016-07-21
Upon receipt of the RA update request from the MS, the SGSN may initiate the
location update procedure to the HLR when necessary.
If the Gs interface has been configured between the SGSN and the MSC/VLR,
the SGNS will initiate the combined location update procedure to the MSC/VLR;
otherwise the RA Update Accept message will be directly sent.
Upon receipt of the location update request from the SGSN, the MSC/VLR
updates the MS location and stores the relevant data.
Upon receipt of the Location Update Accept message from the HLR, the
MSC/VLR sends it via the Gs interface to the SGSN.
Upon receipt of the Location Update Accept message from the MSC/VLR, the
SGSN sets the relevant data and sends the Routing Area Update Accept
message. If the TMSI reallocation procedure has been executed, the SGSN will
send the TMSI Reallocation Complete message received from the MS to the
MSC/VLR to finish the combined location update procedure.

Page32, Total68

to appear here.
6.6 PS Domain Mobility Management Procedures

6.6.1 MM Function Overview
The major role of Mobility Management (MM) is to track the current location of a
subscriber in the home PLMN or other PLMNs. For instance, if a subscriber wants to
log in to the GPRS network, the Attach procedure (which is a basic procedure of MM)
must be executed first, so as to register his related information in the core network.
The MM, SM (Session Management) and SMS (Short Message Services) together
form the connection layer of the 3GPP protocols. Among them, MM is located above
the RANAP layer to provide signaling transport for SM and SMS in the UMTS. The
other functions of MM also include the subscriber detachment, security, routing area
update and location update procedures.
1. Terminologies
GMM/PMM
GMM: GPRS
Management)
Mobility
Management
(different
from
CMM
Circuit
Mobility
PMM: Packet Mobility Management

Here we can simply regard the GMM as mobility management in the GSM system
and the PMM as mobility management in the UMTS system. This document focuses
on the PS domain MM features of the UMTS system.
RANAP
RANAP (Radio Access Network Application Part) encapsulates and transports higherlayer signaling, processes the signaling between the 3G-SGSN and the UTRAN, and
manages the GTP connections at the Iu interface.
MM CONTEXT
The MM Context includes subscriber data and the authentication set.

The position of GMM in the protocol stack is illustrated in the following figure.
GMM /
SM / SMS
GMM /
SM / SMS
Relay
RRC
RRC
RANAP
RANAP
RLC
RLC
SCCP
SCCP
MAC
MAC
Signalling
Bearer
Signalling
Bearer
L1
L1
AAL5
AAL5
ATM
Uu
MS
ATM
Iu-Ps
RNS
3G SGSN
Figure 1.1 Control plane protocols at the MS side and the network side of the PS domain in the UMTS
2016-07-21

Page33, Total68

to appear here.
6.6.2 Mobility Management State

The PMM states in the UMTS include PMM-DETACHED, PMM-IDLE and PMMCONNECTED.
PMM DETACHED State
In this state, the MS does not communicate with the 3G-SGSN and there is no valid
location or routing information. The MS is unreachable and the MS location is
unknown.
PMM IDLE State
In this state, the MS location is known but the MS is idle.
PMM CONNECTED State
In this state, the MS location is known and the PS signaling connection has been
established.
The specific state transitions of PMM are depicted in the following figure, where we
can see that the SM may be in the active or inactive state when the PMM is in the
connected or idle state, that is, the MM state is only related to the MM state of GPRS
and it has nothing to do with the PDP Context state or quantity.
Note: In the case of errors, the MS state may be not synchronous with the network
state and their synchronization can be achieved through the routing area update
procedure.
Figure 1.1 PMM state transitions of the UMTS
6.6.3 Association Between SGSN and MSC/VLR

The Gs interface is specified between the SGSN and MSC/VLR in the UMTS. Their
association is established through the following procedures:
2016-07-21
Combined GPRS/IMSI Attach/Detach procedure

IMSI-attached GPRS Attach procedure
GPRS-attached IMSI Attach procedure (combined RA update)
Page34, Total68

to appear here.
After the Gs interface association has been established, the system can implement
the following procedures now:
1)
CS Paging:
The MSC/VLR can send the CS paging information via the SGSN to a subscriber in
the combined attachment procedure.
2)
Non-GPRS Alert
The MSC/VLR will request the SGSN to notify the activity information of the MS to
itself and it will set the NGAF (Non-GPRS Alert Flag) so that the SGSN MM will notify
the subscriber activity once detected to the MSC/VLR and the NGAF will be cleared
then.
3)
MS Information Procedure
When the MSC/VLR needs the subscriber identity and location information, it may
obtain such information via the Gs interface from the local SGSN or it may send a
request for such information via the SGSN to get the needed information.
4)
MM Information Procedure
The MSC/VLR may send the network information via the SGSN to a subscriber and
the SGSN will pass on the information.
2016-07-21

Page35, Total68

to appear here.
6.6.4 Combined GPRS/IMSI Attach Procedure

MS
UTRAN
new SGSN
old SGSN
GGSN
EIR
new
MSC/VLR
HLR
old
MSC/VLR
1. Attach Request
2. Identification Request
2. Identification Response
3. Identity Request
3. Identity Response
4. Authentication
5. IMEI Check
6a. Update Location
6b. Cancel Location
6c. Cancel Location Ack
6d. Insert Subscriber Data
6e. Insert Subscriber Data Ack
6f. Update Location Ack
7a. Location Update Request
7b. Update Location
7c. Cancel Location
7d. Cancel Location Ack
7e. Insert Subscriber Data
7f. Insert Subscriber Data Ack
7g. Update Location Ack
7h. Location Update Accept
C1
8. Attach Accept
9. Attach Complete
10. TMSI Reallocation Complete
Figure 1.1 Attach procedure

Note: The C1 as indicated in the above figure is a CAMEL point where intelligent
services can be triggered or performed. In the subsequent flow charts such points as
C1, C2 and C3 are all CAMEL points.
1)
2)
2016-07-21
The MS sends an Attach Request message to initiate the Attach procedure. The
Attach Request message contains such parameters as IMSI or P-TMSI and old
RAI, Attach Type, old P-TMSI Signature and Follow On Request. If the
subscriber has no legal P-TMSI, the message will carry an IMSI; or if the
subscriber has a legal P-TMSI, it should then carry the P-TMSI and the matched
RAI or even the P-TMSI signature, if any. The Attach Type parameter indicates
what kind of Attach procedure is requested by the MS: GPRS Attach, Combined
Attach or IMSI-attached GPRS Attach. The SGNS may decide whether to
release the packet service signaling connection of the MS upon end of the Attach
procedure according to the Follow On Request indication.
If the MS uses P-TMSI for attachment and the SGSN has been changed since
the last attachment, the new SGSN should send an Identification Request to the
old SGSN and this request should carry the P-TMSI of the MS, the
corresponding RAI and the old P-TMSI signature, if any. The old SGSN should
Page36, Total68
3)
4)
5)
6)

to appear here.
then respond with the Identification Response message that carries the
subscribers IMSI and authentication set. If the MS is unknown to the old SGSN,
the old SGSN shall return a response message with the related cause value; and
if the P-TMSI of the MS does not match the signature, the old SGSN should
return another response message along with the corresponding cause value.
If the MS is unknown to the old SGSN, the new SGSN should initiate an Identity
Request to the MS with the identity type indicating IMSI and the MS should then
report its own IMSI to the SGSN.
If the MM Context of the MS does not exist in the network, the authentication
procedure is then needed. If P-TMSI reallocation is needed and the network
supports ciphering, the ciphering mode should also be set in this step.
The IMEI check as defined in the identity check procedure takes place. This
function is currently not implemented.
If the SGSN number has changed since the last detachment or if it is the first
time of the MS to attach to the network, the SGSN should notify the HLR of such.
The SGSN sends an Update Location message (with the SGSN number, SGSN
address and IMSI) to the HLR; the HLR sends the Cancel Location message (with the
IMSI and the Cancel Type) to the old SGSN and sets the Cancel Type to Update
Procedure; the old SGSN acknowledges the Cancel Location received from the HLR
with the Cancel Location Ack message (with the IMSI); the HLR sends the Insert
Subscriber Data message (with the IMSI and GPRS subscriber data) to the new
SGSN; the new SGSN acknowledges the presence of the MS in the new routing area,
and the SGSN should reject the attachment request of the MS with the appropriate
cause value and it may return the Insert Subscriber Data Ack message to the HLR if
the subscriber data do not allow the MS to attach to this routing area. If the subscriber
data check fails due to other causes, the SGSN should reject the attachment request
of the MS with the appropriate cause value and should also return the Insert
Subscriber Data Ack message to the HLR (together with the IMSI and the cause
value). If all the subscriber data have passed the check, the SGSN will construct an
MM Context for the subscriber and at the same time return the Insert Subscriber Data
Ack message (together with the IMSI in it) to the HLR. After deleting the old MM
Context and inserting the new one, the HLR sends the Update Location Ack message
to the SGSN to acknowledge the Update Location message from the SGSN. If the
Update Location request is rejected by the HLR, the SGSN will carry the appropriate
cause value to reject the attachment request of the MS.
7)
If the Attach Type discussed in Step 1 indicates the IMSI-attached GPRS Attach
or Combined Attach, the VLR should be updated, provided that the Gs interface
has been configured. The VLR number can be exported from the routing area
information, that is, the Location Update procedure may start after the first Insert
Subscriber Data message is received from the HLR. As a result, the subscriber
will be flagged as GPRS Attached in the VLR.
8) The SGSN selects the Radio Priority SMS and sends the Attach Accept message
(with the P-TMSI, VLR number, TMSI, P-TMSI signature and Radio Priority SMS)
to the MS. If another P-TMSI is reallocated, it should also be carried in this
message.
9) If the P-TMSI or TMSI has changed, the MS should send an Attach Complete
message to the SGSN to acknowledge the new TMSI.
10) If the TMSI has changed, the SGSN will send the TMSI Reallocation Complete
message to the VLR to acknowledge the reallocated TMSI.
If the attachment request cannot be accepted, the SGSN should return the Attach
Reject message (together with the IMSI and the Cause) to the MS.
2016-07-21

Page37, Total68

to appear here.
6.6.5 Detach Procedures

The Detach procedure may be MS-initiated, SGSN-initiated and HLR-initiated. This
section only describes the first two detachment procedures.
1. MS-initiated detachment
MS
BSS/UTRAN
SGSN
GGSN
MSC/VLR
1. Detach Request
2. Delete PDP Context Request
2. Delete PDP Context Response
3. IMSI Detach Indication
4. GPRS Detach Indication
C1
5. Detach Accept
6. PS Signalling Connection Release
Figure 1.1 MS-initiated detachment

1)
2)
3)
4)
5)
6)
2016-07-21
The MS sends the Detach Request message (with Detach Type, P-TMSI, PTMSI Signature and Switch Off) to the SGSN to initiate the detachment
procedure. The Detach Type parameter indicates what kind of detachment
procedure is to be performed: GPRS Detach, IMSI Detach or Combined Detach.
The Switch Off parameter indicates whether the Attach procedure is triggered by
the MS switch-off. The Detach Request message carries the P-TMSI and PTMSI signature (to check the legality of the detachment message) of the MS. If
the signature of the MS is illegal or not carried, the SGSN should initiate the
authentication procedure.
In the case of GPRS Detach, the deactivation of the active PDP Context that
exists in the GGSN and belongs to the subscriber is implemented when the
SGSN sends the Delete PDP Context Request message (with the TEID) to the
GGSN. The GGSN should acknowledge it with the Delete PDP Context
Response message.
In the case of IMSI Detach, the SGSN should send the IMSI Detach Indication
message to the VLR.
If the subscriber needs to keep IMSI-attached while GPRS-detached, the SGSN
should send the GPRS Detach Indication message to the VLR. The VLR
removes its association with the SGSN and no longer initiates the Paging or
Location Update procedure via the SGSN.
If the Detach procedure is initiated due to other reasons than MS switch-off, the
SGSN should return the Detach Accept message to the MS.
If the MS initiates the GPRS Detach procedure, the SGSN will release the PS
domain signaling connection.

Page38, Total68

to appear here.
2. SGSN-initiated detachment
MS
BSS/UTRAN
SGSN
GGSN
MSC/VLR
C1
1. Detach Request
3. GPRS Detach Indication
4. Detach Accept
5. PS Signalling Connection Release
Figure 6.1 SGSN-initiated detachment

1)
2)
3)
4)
5)
The SGSN notifies via the Detach Request message (with the Detach Type
parameter) that the MS has been detached. The Detach Type parameter
indicates whether the MS requests for re-attachment and re-activation of the
original active PDP Context before the detachment procedure. If yes, the Attach
procedure will be initiated upon completion of the Detach procedure.
The SGSN notifies the GGSN of the Delete PDP Context Request message
(with the TEID carried), so as to request the GGSN to deactivate the active PDP
Context of the MS. The GGSN should acknowledge it with the Delete PDP
Context Response message.
In the case of combined attachment, the SGSN should send the GPRS Detach
Indication message (with the MS IMSI) to notify the VLR of such. The VLR
removes its association with the SGSN and no longer conducts paging and
location updating via the SGSN.
The MS may, upon receipt of the Detach Request from the SGSN, send the
Detach Accept message at any time to the SGSN.
Upon receipt of the Detach Accept message from the MS, the SGSN will release
the PS signaling connection if the Detach Type does not indicate the
reattachment request of the MS.
6.6.6 Security Procedure (Authentication & Ciphering)

MS
BSS/UTRAN
SGSN
HLR
1. Send Authentication Info

1. Send Authentication Info Ack
2. Authentication and Ciphering Request
2. Authentication and Ciphering Response
Figure 1.1 Authentication and ciphering

1)
2016-07-21
If the SGSN does not contain any old UMTS authentication quintuple, it will send
a Send Authentication Info message (with IMSI). Upon receipt of this message,
the HLR/AUC shall respond with the Send Authentication Info Ack message that
Page39, Total68
2)
3)

to appear here.
includes the sequentially arranged quintuples. Each quintuple contains such

information as RAND, XRES, AUTN, CK and IK. For the generation of such a
quintuple, refer to 3G TS 33.102.
During the authentication of the UMTS subscriber, the SGSN will select the next
quintuple and carry the RAND and AUTN parameters of this quintuple in the
Authentication and Ciphering Request message before sending the message to
the MS. The SGSN will also select a CKSN and carries it in this message.
Upon receipt of this message, the MS will have its USIM card authenticate the
AUTN. If the AUTN is accepted, the MS will calculate the signed RES of the
RAND according to the 3G TS 33.102 protocol. If the USIM card determines that
the authentication succeeds, the MS will return the Authentication and Ciphering
Response message (RES) to the SGSN. Meanwhile, the USIM card of the MS
will also calculate the CK and IK. These keys will be stored together with the
CKSN until the CKSN is updated at the next authentication.
If the USIM card determines that the authentication fails (e.g. authentication
synchronization error), the MS will return the Authentication and Ciphering Failure
message to the SGSN.
2016-07-21

Page40, Total68

to appear here.
6.6.7 Location Management (Routing Area Update)

MS
UTRAN
new
3G-SGSN
old
3G-SGSN
GGSN
new
MSC/VLR
HLR
old
MSC/VLR
1. Routeing Area Update Request

2. SGSN Context Request
3. Security Functions
2. SGSN Context Response

4. SGSN Context Ack
C1
5. Update PDP Context Request
5. Update PDP Context Response
6. Update Location
7. Cancel Location
7. Cancel Location Ack
8. Insert Subscriber Data
8. Insert Subscriber Data Ack
9. Update Location Ack
10. Location Update Request
11a. Update Location
11b. Cancel Location
11c. Cancel Location Ack
11d. Insert Subscriber Data
11e. Insert Subscriber Data Ack
11f. Update Location Ack
12. Location Update Accept
C2
13. Routeing Area Update Accept

C3
14. Routeing Area Update Complete
15. TMSI Reallocation Complete
Figure 1.1 Routing area update

1)
The RRC connection must be established first if there is no existing RRC

connection. The MS sends the Routing Area Update Request message (with
such parameters as P-TMSI, Old RAI, Old P-TMSI Signature, Routing Area
Update Type and Follow On Request) to the new SGSN. If the MS has signaling
or data to be uploaded, the Follow On Request should be set. As an
implementation option, the SGSN may decide whether to release the Iu
connection upon end of the routing area update procedure according to the
Follow On Request flag. The Routing Area Update Type parameter should
indicate the following:
Routing area update, provided that the procedure is caused by routing area changes;
Periodic routing area update, provided that the procedure is caused by expiry of the
periodic routing area update timer;
2016-07-21

Page41, Total68

to appear here.
Combined routing area update, provided that the MS is IMSI attached and the
location area update needs to be operated in the network operation mode I;
Combined routing area update with IMSI attach, provided that the MS wants the IMSI
Attach procedure to take place in the network operation mode I;
The Serving RNC (SRNC) should add the RAI (including the routing area code and
the location area code) of the subscriber location to the front of the Routing Area
Update Request message before forwarding it to the SGSN.
2)
3)
4)
5)
6)
7)
8)
2016-07-21
In the case of inter-SGSN routing area update and provided that the MS is in the
PMM-IDLE state, the new SGSN will send the SGSN Context Request message
(with the old P-TMSI, old RAI and old P-TMSI signature of the MS) to the old
SGSN, so as to get the MM Context and the PDP Context of the MS. The old
SGSN shall check the P-TMSI and signature of the MS and turn the appropriate
cause value in the case of mismatch. In that case, the new SGSN will initiate the
security procedure. If the MS passes authentication of the security procedure,
the new SGSN should send the SGSN Context Request message (with the IMSI,
old RAI and the MS authenticated flag) to the old SGSN. The MS authenticated
flag indicates that the new SGSN has authenticated the MS. If the signature of
the MS is legal or the new SGSN has successfully authenticated the MS, the old
SGSN will return the SGSN Context Response message (with such parameters
as Cause, IMSI, MM Context and PDP Context). If the MS is unknown to the old
SGSN, the old SGSN should return the appropriate cause value and will start the
timer.
The security procedure may take place here. If the authentication fails, the
routing area update request will be rejected and the new SGSN should send the
Reject Indication to the old SGSN. The old SGSN should continue as if it had
never received the SGSN Context Request message.
In the case of inter-SGSN routing area update, the new SGSN should send the
SGSN Context Ack message to the old SGSN. The old SGSN marks the
MSC/VLR association and the information in the GGSN and HLR as illegal in its
SGSN Context. If the MS initiates the routing area update to the old SGSN again
before the ongoing routing area update procedure is complete, the update of
MSC/VLR, GGSN and HLR will be triggered.
In the case of inter-SGSN routing area update and provided that the MS is in the
PMM-IDLE state, the new SGSN shall send the Modify PDP Context Request
message (with the new SGSN address and the negotiated QoS and TEID
information) to the relevant GGSN. The GGSN shall update its PDP Context and
return the Modify PDP Context Response message (with TEID) to the SGSN.
In the case of inter-SGSN routing area update, the SGSN shall send the Update
Location message (with the SGSN number, SGSN address and IMSI) to the
HLR, so as to notify the HLR of the SGSN change.
In the case of inter-SGSN routing area update, the HLR shall send the Cancel
Location message (with the IMSI and the Cancel Type parameters) to the old
SGSN and the Cancel Type will be set to Update Procedure. The old SGSN
shall return the Cancel Location Ack message (with the IMSI) to the HLR for
acknowledgement.
In the case of inter-SGSN routing area update, the HLR will send the Insert
Subscriber Data message (with the IMSI and GPRS subscriber data) to the new
SGSN. The new SGSN acknowledges the presence of the MS in the new routing
area, and it should reject the attachment request of the MS with the appropriate
cause value and may return the Insert Subscriber Data Ack message to the HLR
if the subscriber data do not allow the MS to attach to this routing area. If the
subscriber data check fails due to other causes, the SGSN should reject the
attachment request of the MS with the appropriate cause value and should also
return the Insert Subscriber Data Ack message to the HLR (together with the
IMSI and the cause value). If all the subscriber data have passed the check, the
Page42, Total68
9)
10)
11)
12)
13)
14)
15)

to appear here.
SGSN will construct an MM Context for the subscriber and at the same time
return the Insert Subscriber Data Ack message (together with the IMSI in it) to
the HLR.
In the case of inter-SGSN routing area update, the HLR will, after deleting the old
MM Context and inserting the new one, send the Update Location Ack message
to the SGSN to acknowledge the Update Location message from the SGSN.
If the Routing Area Update Type indicates the Combined Routing Area Update
with IMSI Attach or if the location area changes, the association between the
SGSN and the VLR must be established. The new SGSN sends the Location
Update Request message (with the new RAI, IMSI, SGSN number and Routing
Area Update Type) to the VLR. If the Routing Area Update Type indicates the
Combined Routing Area Update with IMSI Attach, the Location Area Update Type
should indicate the IMSI Attach. Otherwise, it should indicate the normal location
area update. The VLR number is obtained after the SGSN is queried with the
RAI. At Step 8 described above, that is, upon receipt of the first Insert Subscriber
Data message from the HLR, the SGSN may start the Location Update
procedure now. The VLR creates or updates its association with the SGSN by
storing the SGSN number.
If the subscriber data in the VLR are marked as unacknowledged by the HLR,
the new VLR will notify this to the HLR. And the HLR will delete the old VLR data
and insert the subscriber data to the new VLR.
The new VLR allocates a new TMSI and returns the Location Update Accept
(with the VLR number and TMSI) to the SGSN. If the VLR does not change, the
TMSI allocation here is optional.
The new SGSN acknowledges the presence of the MS in the new routing area. If
the subscriber data do not allow the MS to attach to this routing area or the
subscriber data check fails, the SGSN should reject the attachment request of
the MS with the appropriate cause value. If all the subscriber data have passed
the check, the SGSN shall construct an MM Context for the MS. The new SGSN
will return the Routing Area Update Accept message (with the P-TMSI, VLRTMSI
and P-TMSI signature) to the MS.
The MS sends the Attach Complete message to the SGSN to acknowledge the
new TMSI.
If the TMSI has changed, the SGSN will send the TMSI Reallocation Complete
message to the VLR to acknowledge the reallocated TMSI.
If the attachment request cannot be accepted, the SGSN should return the Attach
Reject message (together with the IMSI and the Cause) to the MS.
Note: Steps 11, 12 and 15 will not take place unless Step 10 takes place.
2016-07-21

Page43, Total68

to appear here.
6.6.8 Service Request

1. MS-initiated service request
MS
HLR
SGSN
RNC
GGSN
1. RRC Connection Reques t

1. RRC Connection Setup
2. Service Request
4. Service Accept
4. Radio Access Bearer Ass ignment

Reques t
5. Radio Bearer Setup
Complete
6. Radio Access Bearer Ass ignment

Response
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 1.1 MS-initiated service request

1)
2)
The MS establishes the RRC connection first if there is no existing CS channel.

The MS sends the Service Request message (with P-TMSI, PAI, CKSN and
Service Type) to the SGSN. The Service Type parameter defines the required
service. It is either data or signaling. At this time, the SGSN may initiate an
authentication procedure.
If the Service Type parameter indicates data, the signaling connection between the
MS and the SGSN will be established and resources will be reserved simultaneously
for the active PDP Context.
If the Service Type parameter indicates signaling, the signaling connection for
transmitting upper-layer signaling between the MS and the SGSN will be established.
3)
4)
5)
6)
2016-07-21
If the MS initiates a service request in the PMM-IDLE state, the SGSN will initiate
the security procedure.
If the network is in the PMM-CONNECTED state and the Service Type indicates
data, the SGSN will return a Service Accept message to the MS to accept the
service request; if the Service Type indicates data, the SGSN will send a Radio
Access Bearer Assignment Request message that carries NSAPIRAB ID(s),
TEID(s), QoS Profile(s) and SGSN IP Address(es) to re-establish the RAB to
each active PDP Context.
The RNC indicates to the MS that the new RAB has been established (together
with the RAB ID).
The SRNC sends a Radio Access Bearer Assignment Response that carries
RAB ID(s), TEID(s), QoS Profile(s) and RNC IP Address(es). The GTP tunnel
has already been established over the Iu interface. If the RNC returns the Radio
Access Bearer Assignment Response message and the cause value indicates
the required QoS cannot be provided (Requested Maximum Bit Rate not
Available), the SGSN will send another Radio Access Bearer Assignment
Request message that carries a different QoS. The number of retries and the
new QoS value are implementation-dependent.
Page44, Total68

to appear here.
7)
8)
For the modified QoS in each RAB re-establishment, the SGSN will initiate a
PDP Context modification procedure to notify the MS and the GGSN of the new
negotiated QoS.
The MS sends an uplink PDU.
The Service Accept message does not mean that the RAB(s) reestablishment is
successful.
Whatever Service Type, the network will return a Service Reject message with the
appropriate cause value to the MS if the service request cannot be accepted.
When the Service Type indicates data and if the SGSN fails to reestablish the
RAB(s), the SGSN will initiate a PDP Context modification procedure or deactivates
the PDP Context. The specific conditions depend on the QoS negotiation.
2. Network-initiated service request
MS
RNC
SGSN
HLR
GGSN
1. Downlink PDU
2. Paging
2. Paging
3. RRC Connection Request
4. Service Request

Complete
6. Radio Access Bearer Assignment

Request

Response
7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU
Figure 8.1 Network-initiated service request

1)
2)
3)
4)
5)
6)
2016-07-21
The SGSN receives the downlink PDP PDU from the MS in the PMM-IDLE state.
The SGSN sends a paging message to the RNC and the RNC sends the paging
message to page the MS.
The MS establishes the RRC connection first if there is no existing CS channel.
Service Type) to the SGSN. The Service Type is set as the paging response. At
this time, the SGSN may initiate an authentication procedure. The SGSN knows
whether the downlink PDU needs RAB reestablishment.
The SGSN specifies the ciphering mode.
The SRNC sends a Radio Access Bearer Assignment Request that carries RAB
ID(s), TEID(s), QoS Profile(s) and SGSN IP Address(es) to the RNC if the
resource reestablishment is needed for the PDP Context. The RNC sends the
Radio Bearer Setup message that carries the RAB ID(s) to the MS. In return, the
MS sends the Radio Bearer Setup Complete message to the RNC. The RNC
sends the Radio Access Bearer Assignment Response message that carries
RAB ID(s), TEID(s) and RNC IP Address(es) to the SGSN, indicating that the
Page45, Total68
7)
8)

to appear here.
GTP tunnel has been established on the Iu interface and the RAB between the
RNC and the MS has also been established. If the cause value carried in the
Radio Access Bearer Assignment Response message returned by the RNC
indicates that the required QoS is not available (Requested Maximum Bit Rate
not Available), the SGSN will send the new Radio Access Bearer Assignment
Request message that carries a different QoS. The number of retries and the
new QoS parameter are related to the product implementation.
For the modified QoS in each RAB re-establishment, the SGSN will initiate a
PDP Context modification procedure to notify the MS and the GGSN of the new
QoS.
The SGSN sends a downlink PDU.
If the Service Type is set as paging response, the MS will regard the service request
as having been successfully received by the SGSN upon receipt of the Secure Mode
Control message from the RRC.
If the SGSN fails to reestablish the RAB(s), it will initiate a PDP Context modification
procedure.
6.7 Call Control

6.7.1 Mobile-originated Call Setup
To initiate a call, the UE needs to establish communication with the network via radio
interface signaling and send a message that contains the called subscriber number,
i.e. the SETUP message on the Iu interface. The CN will establish a communication
channel to the UE and use the obtained called party UERN to create an IAM/IAI
message before sending the message to the called party. Note that the IAM/IAI
message is not involved in the intra-office calls and it only exists on the E interface.
2016-07-21

Page46, Total68

to appear here.
Figure 1.1 Mobile-originated call setup procedure

1)
The UE sends a CHANNEL REQUEST message to the network over the random
access channel.
2) The network responds with an IMMEDIATE ASSIGNMENT message so that the
UE can occupy the specified dedicated channel.
3) The UE sends a CM SERVICE REQUEST message to the CN.
4) The network initiates the authentication and ciphering procedures.
5) After sending the SECURITY MODE COMPLETE message, the UE sends the
SETUP message to the CN to initiate the call setup procedure.
6) The CN responds with a CALL PROCEEDING message.
7) In the case of immediate assignment, a communication channel must be
assigned to the UE before the CN initiates the call setup procedure to the fixed
network.
8) When the called party rings, the network must send an ALERTING message to
the calling UE upon receipt of the ALERTING message from the called party.
Meanwhile, it also needs to send a ringback tone to the calling party.
9) When the called party answers, it will send a CONNECT message to the network
and the network will forward this message to the calling party.
10) When the calling UE returns a CONNECT ACKNOWLEDGE message, the call
setup procedure is complete.
6.7.2 Mobile-terminated Call Setup

A mobile-terminated call procedure is executed when the mobile subscriber is called.
And the call setup procedure is initiated by the network.
If the incoming call is allowed for setup after CN receives the IAM/IAI message or
gets the MSRN from within the local office, the CN must page the UE via radio
2016-07-21

Page47, Total68

to appear here.
interface signaling. When the UE responds with the PAGING RESPONSE message,
the CN will establish a communication channel to the UE upon receipt of this
message.
Figure 1.1 Mobile-terminated call setup procedure

1)
2)
3)
4)
5)
6)
7)
2016-07-21
The CN sends a PAGING message to the RNS and the RNS broadcasts this
PAGING message over the paging channel. For details, refer to the paging
procedure described in Section 6.6.4.
The called UE detects this paging and sends a channel request to the RNS. The
RNS returns an immediate assignment command to indicate the UE to use the
specified signaling channel.
The UE sends a PAGING RESPONSE message on the signaling channel. Upon
receipt of the PAGING RESPONSE message from the UE, the CN initiates the
authentication and ciphering procedures (these two security procedures are
optional and can be configured through the MAP function procedure).
The CN sends a SETUP message to the RNS. The SETUP message carries the
bearer capability of the call and the calling number.
Upon receipt of the SETUP message from the RNS, the UE returns a CALL
CONFIRMED message. If the negotiated bearer capability parameter changes,
the CALL CONFIRMED message shall carry the bearer capability information.
Upon receipt of the CALL CONFIRMED message from the RNS, the CN sends
an RAB ASSIGNMENT REQ message to the RNS to request for radio channel
assignment while the RNS sends an assignment message to the UE so as to
switch the UE to a specified communication channel. After the UE is switched to
the specified communication channel, it sends the RB ASSIGNMENT
COMPLETE message to the RNS.
The RNS sends a RAB ASSIGNMENT RESPONSE message to the CN.
Page48, Total68

to appear here.
8)
The UE sends an ALERTING message to indicate that the called subscriber

should ring now.
9) When the called party answers, the called UE sends a CONNECT message via
the RNS to the CN.
10) The CN returns a CONNECT ACKNOWLEDGE message to the UE to end the
call setup procedure.
6.7.3 RAB Procedure

1. RAB management
It is defined that the RAB (Radio Access Bearer) shall be established between the UE
and the CN. Different RABs are used for the different subscriber data, CN service
capabilities and QoS requirements in the service request of the UE.
The RAB ID is related to the NAS binding information. For example, the RAB ID in the
RANAP layer of the CS domain is numerically the same as the SI in the CC sublayer.
The SI is allocated by the UE and the CN corresponds with the SIs to the RAB IDs
one by one during the allocation of RAB IDs. In the point of view of a UE, the RAB ID
is global in terms of RB (Radio Bearer) and Iu bearer and one RAB ID corresponds to
a unique connection instance in the user plane (an Iu UP instance).
The CN controls the establishment, modification and release of RABs. It initiates the
establishment, modification and release procedures of RABs, while the UTRAN
executes the establishment, modification and release procedures of RABs. It is one
function of the UTRAN to initiate the RAB release request (this function is triggered
when the UTRAN cannot maintain the RAB with the UE).
During RAB establishment, the CN maps the RABs to the Uu interface bearers while
the UTRAN maps the RABs to the Uu interface transport bearers and the Iu interface
transport bearers.
If the AAL2 bearer is to be used in the CS domain, the UTRAN will initiate the setup
and release of AAL2 connections.
The priority of RABs are determined by the CN according to the subscription and QoS
information. The CN specifies the priority, preempt capability and queuing feature of
an RAB during the RAB establishment and modification messages. The UTRAN
executes the RAB queuing and resource preemption.
2. RAB access control
Upon receipt of an RAB establishment or modification request (the RAB QoS is
mapped via the BC IE according to the R99 CS specification), the CS verifies if the
subscriber is allowed to use the RAB in the request parameter. If yes, the CN will
accept the request; otherwise it will reject the request.
When the UTRAN receives an RAB establishment or modification request from the
CN, the admission control entity will judge if the request should be accepted or
rejected according to the current radio resource conditions.
2016-07-21

Page49, Total68

to appear here.
3. RAB establishment, release and modification procedures

CN
RNC
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT
RESPONSE
.
.
.
* it can be several responses
Figure 1.1 RAB assignment procedure at the Iu interface

The purpose of the RAB Assignment procedure is to modify and/or release the
established RAB, and/or establish a new RAB. The procedure is connection-oriented.
The CN first sends an RAB Assignment Request message to the RNC and the CN
then starts the timer TRABAssgt. In an RAB Assignment Request message, the CN
may request the UTRAN to establish/modify/release one or several RABs. The
message contains the following information:
The list of RABs to be established or modified, along with the bearer feature;
The list of RABs to be released.
The RAB ID is unique in each Iu connection. If the message received by the RNC
includes an existing RAB ID, the RNC will regard that the RAB is to be modified
(except release).
The RNC will receive RAB release messages at any time and will always respond. If
the RNC receives a message to release an RAB while it is establishing or modifying
this RAB, it will stop the RAB configuration procedure, release all resources related to
this RAB and return a response.
Upon receipt of the message, the UTRAN will execute the requested RAB
configuration and then send an RAB Assignment Response message to the CN to
report the result of request. One RAB Assignment Response message may contain
the information of one or more RABs as follows:
The RABs that have been successfully established, modified or released;
The RABs that fail to be established, modified or released;
The RABs in queuing.
If no RABs are queued, the CN will strop the timer TRABAssgt and then the RAB
Assignment procedure will end on the UTRAN side.
When the RABs to be established or modified are queued, the UTRAN will start the
timer TQUEUING that specifies the maximum queuing time before establishment and
2016-07-21

Page50, Total68

to appear here.
modification of the RABs and will monitor all the queued RABs. The queued RABs
may have the following results:
Establishment or modification success;
Establishment or modification failure;
Failure due to expiry of the TQUEUING timer.
In the first RAB Assignment Response message, the UTRAN reports the state of all
the RABs involved in the RAB ASSIGNMENT REQUEST message. The UTRAN then
reports the state of the queued RABs in the following RAB Assignment Response
message, except the RABs with TQUEUING expiry. When knowing that the
modification or establishment of all the queued RABs has succeeded or failed, the
UTRAN stops the timer TQUEUING and the RAB Assignment procedure ends at the
CN and the UTRAN simultaneously.
When the CN receives a response indicating that the RABs are queued, it hopes that
the UTRAN can provide the result of RABs queuing before expiry of the timer
TRABAssgt; otherwise, it will regard that the RAB Assignment procedure has ended
and the configuration of those RABs not reported has failed.
Upon expiry of the timer TQUEUING, all the queued RABs in the UTRAN will end the
procedure of queuing and the UTRAN will use an RAB Assignment Response
message to report the states of all the queued RABs. At the same time, the whole
procedure is stopped on the CN side.
4. RAB establishment procedure
The following figure depicts the procedure of RAB establishment via UTRAN between
the CN and the UE.
2016-07-21

Page51, Total68

to appear here.
Serving
RNC
Node B
Serving RNS
UE
RANAP
CN
1. RAB Assignment Request
RANAP
[Establishment]
Select L1, L2 and Iu Data
Transport Bearer parameters
2. ALCAP Iu Data
Transport Bearer Setup
Not required towards PS domain
2.1 Establish Request
Q.aal2
Q.aal2
NBAP
Radio Link Reconfiguration Prepare

[DCH Addition]
NBAP
Radio Link Reconfiguration Ready
2.1 Establish Confirm
Q.aal2
Q.aal2
NBAP
NBAP
ALCAP Iub Data Transport Bearer Setup
DCH-FP
Downlink Synchronisation
DCH-FP
DCH-FP
Uplink Synchronisation
DCH-FP
NBAP
Radio Link econfiguration Commit NBAP
3 DCCH: Radio Bearer Setup
RRC
RRC
Apply new transport format set

DCCH
RRC
: Radio BearerSetup Complete
RRC
RANAP 4. RAB Assignment Response RANAP
5. Initialization
Iu UP
Iu UP
(RFCI, 0..N + subflow size information)
Figure 1.2 RAB establishment (DCH-DCH synchronous establishment procedure)

The above example shows the procedure of establishing an RAB (DCH) in the DCH
RRC state after the RRC connection has been established.
Time
In the CS domain, upon receipt of a service request from the UE (Caller SETUP,
called CALL CONFIRM and CONNECT messages, etc.), the CN sends an RAB
Assignment Request message to indicate that a new AS bearer channel is needed to
bear the NAS subscriber data and thus initiates the procedure of bearer channel
establishment.
1)
2016-07-21
Procedure
The CN decides what kind of RABs are to be used according to the subscriber
data, CN service capability and QoS requirements in the service request of the
UE. It sends an RANAP message, i.e. the Radio Access Bearer Assignment
Request (Setup) message, to request the RAB establishment. In the message,
Page52, Total68
2)

to appear here.
the RAB ID is filled with the SI value. The key parameters of the CS domain
include the RAB parameter, the user plane mode, the ATM address of the local
user plane and the IU BINDING ID.
The Serving RNC uses the ALCAP protocol to initialize the Iu interface data
transport bearer establishment.
In the case of using the AAL2 bearer in the CS domain (this procedure is not needed
in the case of the PS domain), the SUGR parameter will be used in the AAL2
connection establishment request message to transparently transmit the BINDING ID
to the CN, so as to complete the binding between the RABs and the data transport
bearers. This request message also contains the following key parameters:
Peer ATM address, path ID, Channel ID (CID), path feature and channel feature.
3)
4)
5)
After the Serving RNC reconfigures the radio links with such equipment as Node
B and completes the uplink-downlink synchronization, it uses an RRC message
(i.e. Radio Access Bearer Setup) to carry the subflow and subflow combination
parameters among the RAB parameters as well as the RAB ID before sending
the message to the UE.
Upon receipt of the success acknowledgement RRC message (i.e. Radio Bearer
Setup Complete) from the UE and the establishment success information of the
ALCAP procedure, the Serving RNC acknowledges the RAB establishment
success to the CN. It sends an RANAP message (Radio Bearer Assignment
Response) to the CN.
If the user plane is in the support mode, the UTRAN initializes the Iu interface
user plane via the Initialization message after the result is reported.
& Note:
The procedures of interaction with the Drift RNC and the Drift Node B are not indicated in the above
figure.
For the RACH/FACH DCH, RACH/FACH - RACH/FACH and PS domain nonsynchronous modes, the procedures are similar.
2016-07-21

Page53, Total68

to appear here.
5. RAB release procedure

Node B
Serving RNS
UE
Serving
RNC
RANAP
CN
1 RAB Assignment Request
[Release]
RANAP 2. RAB Assignment Response
RANAP
RANAP
3. ALCAP Iu Data Transport Bearer Release

not required towards PS domain
Q.aal2
Q.aal2
3.1 Release Request

3.2 Release Confirm
Q.aal2
Q.aal2
NBAP Radio Link Reconfiguration Prepare NBAP

[DCH Deletion]
NBAP Radio Link Reconfiguration Ready
NBAP
Radio Link Reconfiguration Commit
DCCH : Radio Bearer Release
RRC
NBAP
NBAP
RRC
Apply new
transport format set
DCCH
DCCH : Radio Bearer Release Complete
RRC
RRC
Iub Data Transport Bearer Release

ALCAP
Figure 5.1 RAB release (DCH-DCH synchronous release procedure)
Trigger time
This procedure is initiated in the CS domain when all the transactions over the RAB in
the CC layer end or the RNC requests to release the RAB.
1)
2)
3)
4)
5)
2016-07-21
Procedure
The CN sends an RANAP message, i.e. Radio Access Bearer Assignment
Request (Release), to initiate the RAB release procedure together with the RAB
ID specified.
The Serving RNC acknowledges the request message with another RANAP
message, i.e. Radio Access Bearer Assignment Response.
The Serving RNC uses the ALCAP protocol. In the case of the AAL2 bearer, it
uses the AAL2 release message to initiate the release procedure of the Iu data
transport bearer between itself and the CN (this procedure is not needed in the
PS domain).
The Serving RNC sends an RRC message (Radio Bearer Release) to the UE to
initiate the bearer release procedure after releasing the link with such equipment
as Node B.
The Serving RNC receives the acknowledgement RRC message (Radio Bearer
Release Complete) from the UE and the whole release procedure thus ends.

Page54, Total68

to appear here.
6. RAB modification procedure

Serving
RNC
Node B
Serving RNS
UE
CN
Request
RANAP 1. RAB Assignment
RANAP
[Modify]
2. Select L1, L2 and Iu Data
Transport Bearer parameters
e.g. for Radio Bearer
reconfiguration.)
3. ALCAP Iu Data
Transport Bearer Modify
(
Q.aal2
Q.aal2
NBAP
Radio Link Reconfiguration Prepare
NBAP
Radio Link Reconfiguration Ready
ALCAP
NBAP
3.2
Modify Request
Modify Confirm
Q.aal2
Q.aal2
NBAP
NBAP
Iub Data Transport Bearer Modify
Radio Link econfiguration Commit NBAP
4 Radio Bearer Reconfiguration (DCCH
RRC
3.1
RRC
Actualizing Radio Bearer modification (e.g. Apply new transport format set)
5 Radio Bearer Reconfiguration Complete
RRC
DCCH
RRC
RANAP 6 RAB Assignment Response
RANAP
7. Initialization
Iu UP
Iu UP
(RFCI, 0..N + subflow size information)
Figure 5.1 RAB modification (DCH-DCH synchronous modification procedure)
Trigger condition
When the UE is handed over or the UE rate changes, the CN reconfigures the traffic
channel to support the service attribute change.
1)
2)
3)
4)
2016-07-21
Procedure
The CN sends an RANAP message, i.e. the Radio Access Bearer Assignment
Request (Modify), to request the RAB modification. The request message
contains the RAB ID that indicates which RAB is to be modified and such key
parameters of the CS domain as RAB parameters.
The Serving RNC selects which parameters are to be modified and which
programs are to be initiated.
The SRNC uses the ALCAP protocol to modify the channel characteristics of the
Iu interface data transport bearers.
Upon successful modification procedure of the Iu interface transport control
plane, the Serving RNC modifies the radio links together with such equipment as
Node B. It then sends the subflow and subflow combination parameters among
the RAB parameters as well as RAB ID in the RRC message (Radio Bearer
Reconfiguration) to the UE.
Page55, Total68

to appear here.
5, 6) Upon receipt of the success acknowledgement RRC message (i.e. Radio

Bearer Setup Complete) from the UE, the Serving RNC acknowledges the RAB
modification success to the CN. It sends an RANAP message (Radio Bearer
Assignment Response) to the CN.
7) If the user plane is in the support mode, the UTRAN initializes the Iu interface
user plane via the Initialization message after the result is reported.
6.7.4 Paging Procedure

The paging procedure is a procedure of paging initiated from the CN to the called
party. When the CN needs to set up a connection with the called subscriber, it first
needs to find the called subscriber via the paging procedure. The purpose of the
paging procedure is just to enable the CN to page the called subscriber. The paging
procedure is set up via connectionless signaling.
The CN sends the PAGING message to the called subscriber to initiate the paging
procedure. The PAGING message should contain sufficient information so that the
RNC can find the called subscriber. If the called subscriber is unreachable in one
paging, the CN will repeat the paging procedure via the Iu interface. Generally, the
number of paging retries and the paging interval can be controlled by the CN.
CN
RNC
PAGING
Figure 1.1 Successful paging procedure

1. Paging procedure
After the call request information from the caller is processed by the CN, the paging
procedure starts if the called subscriber information has been successfully obtained.
The CN needs to know the location area information of the called subscriber and get
the sufficient paging information parameters before it can initiate the paging
procedure to the called subscriber.
If the CN does not get the location area information of the called subscriber, it needs
to send the PAGING message through the broadcast procedure to all the RNCs
under its control.
The CN sends the PAGING message via the RANAP interface, which processes the
PAGING message from the CN. The PAGING message includes such parameters as
whether the paging request comes from the CS domain or the PS domain, what
reason caused the paging and the specific location area information of the called
subscriber. The RANAP sends the PAGING message to the RNC where the location
area of the called subscriber resides.
When the PAGING message reaches the RNC, the RNC analyzes the parameters of
the PAGING message to get the location area information of the called subscriber
and then transmits via PCCH the PAGING information to the UE in that location area.
If the called UE detects the PAGING message from the RNC, it starts to execute the
NAS signaling procedure.
2016-07-21

Page56, Total68

to appear here.
If the paging is successful, the CN will get the paging response message; otherwise
the CN needs to repeat sending the PAGING message via the Iu interface.
2. Paging procedure of the UE in the RRC idle state
When the RRC is idle, the UE may receive paging from the CS or PS domain.
Because the UE is now in the idle state, the CN can learn the Location Area
Identification (LAI) information of the UE. The paging will be sent via this location area
and the LA in this example crosses two RNCs.
Figure 1.2 Paging procedure of the UE in the RRC idle state

1)
2)
3)
The CN initiates the paging information and sends it after passing two RNCs to
the called UE. At this time it can be see from the Iu interface that two PAGING
messages are continuously send by the CN, they carry the same LAI, except that
the DPCs are the two RNCs.
Cell 1 initiates the paging procedure via the Paging Type 1 message.
Cell 2 initiates the paging procedure via the Paging Type 1 message.
The PAGING message reaches RNC1 and RNC2 via RANAP, and the two RNCs
transmit the PAGING message to the UE in the specified location area over the
PCCH. If the called UE detects the PAGING message from RNC1 or RNC2, it then
starts executing the NAS signaling procedure.
3. Paging procedure of the UE in the RRC connected state
When the RRC is in the connected state, the paging procedure of the UE may fall into
two cases: The CS domain or the PS domain of the CN. Due to the independency of
mobility management, there are two possible solutions:
1)
2)
The UTRAN coordinates the paging request over the existing RRC connection;
The UE coordinates the paging request over the existing RRC connection.
The following example shows the paging procedure of the UE in the RRC connected
state (CELL_DCH and CELL_FACH), where the UTRAN coordinates the paging
request over the DCCH in the RRC connected state.
2016-07-21

Page57, Total68

to appear here.
Figure 2.1 Paging procedure of the UE in the RRC connected state (CELL_DCH and CELL_FACH)
1)
2)
The CN sends the PAGING message via RANAP to UE to page the UE.
The Serving RNC sends the Paging Type 2 to the RRC (UE).
& Note:
Paging Type 1 is sent over the PCCH when the UE is idle while Paging Type 2 is sent over the DCCH
when the UE is in the RRC connected state. The typical case is that the UE uses the Paging Type 2 to
send the PAGING message of the CS domain in the PS service procedure. However, the Paging Type is
controlled by the RNC and the CN does not need to know it.
6.7.5 Call Release Procedure

When the mobile subscriber ends the conversation, the calling party or the called
onhook message shall be notified to the network side to initiate the call release
procedure. The network releases the call by terminating the CS connection between
the PLMNs or between the PLMN and other networks.
Figure 1.1 Successful mobile-originated call release

2016-07-21

Page58, Total68
1)
2)
3)
4)

to appear here.
After the MS hooks on, it sends a DISCONNECT message to the network to

initiate the call clearing procedure. The release cause in the message is Normal
Call Clearing.
Upon receipt of the DISCONNECT message, the network sends a RELEASE
message to the MS.
The MS sends a RELEASE COMPLETE message to the network. If the
communication channel is no longer needed, the channel release procedure will
be executed.
If the call is the only one over the entire Iu connection, the Iu connection shall be
released. The CN sends an IU RELEASE COMMAND message to the RNS to
request for releasing the Iu connection.
6.8 PS Domain Session Management Procedures

6.8.1 Basic Concepts of Session Management
1. SM function overview
The purpose of SM is to set up, modify and release the PS domain bearer. As a major
component of the Connection Management layer in the 3GPP protocol, the SM is
located between the Mobility Management plane and the user plane, and uses the
connectionless data transfer service provided by the GMM sublayer to provide
connection management service to the upper layer, i.e., the user plane. It is used to
set up, modify and release the tunnel between the SGSN and the GGSN on one
hand, and to control the setup, modification and release of the Radio Access Bearer
between the SGSN and the RNC/MS on the other hand.
2. Terminologies
1)
PDP CONTEXT/PDP ADDRESS
The PDP context saves all tunnel forwarding information of the user plane, including
user plane IP address of RNC/GGSN, tunnel identifier and QoS.
Each piece of GPRS subscription data comprises one or more PDP addresses, each
PDP address comprises one or more PDP Context descriptions of MS, SGSN and
GGSN, and each PDP Context can exist in one of two states: Inactive and active. The
state transition chart is shown in the following figure. The PDP state indicates whether
the data with the PDP address can be transferred. Inactive sessions do not contain
routing information and cannot complete data transfer. All the PDP Contexts of the
subscriber are associated with his/her MM Context.
2016-07-21

Page59, Total68

to appear here.
INACTIVE
Deactivate PDP Context

or
MM state change to IDLE
or PMM-DETACHED
Activate PDP
Context
ACTIVE
Figure 1.1 PDP state machine model

2)
NSAPI
The NSAPI is used in the MS to identify a PDP service access point, and in the
SGSN/GGSN to identify a session. Its value is the RAB ID used by the access layer
to identify the subscriber RAB.
3)
APN resolution
The APN (Access Point Name) is of the standard domain name format. It comprises
two parts: Network Identity (NI) and Operator Identity (OI). It is used in the GGSN to
identify the ISP of a specific external network and a service, and in the SGSN to get
the GGSN address corresponding to it via the DNS resolution.
4)
QoS negotiation
While setting up a packet transport route, the SM must specify the QoS to be satisfied
by the route. During the SM process, the MS, RNC, SGSN and GGSN conduct QoS
negotiation to keep the consistency of the QoSs they provide. The QoS negotiation
algorithm is to get the minimum from the maximum QoS that can be provided by the
subscribed QoS and SGSN and the QoS satisfied by other nodes.
3. Position of SM in the protocol stack
GMM /
SM / SMS
GMM /
SM / SMS
Relay
RRC
RRC
RANAP
RANAP
RLC
RLC
SCCP
SCCP
MAC
MAC
Signalling
Bearer
Signalling
Bearer
L1
AAL5
L1
AAL5
ATM
Uu
MS
ATM
Iu-Ps
RNS
3G SGSN
Figure 4.1 UMTS MS-SGSN control plane protocol
2016-07-21

Page60, Total68

to appear here.
4. SM-related functional entities

1)
RAB management
RABM (RAB Management) is used to establish, modify, release and reestablish the
RAB.
The RAB consists of two parts: The GTP tunnel between the RNC and the SGSN,
and the Radio Bearer between the RNC and the MS. RAB ID uniquely identifies an
RAB of the subscriber.
The RAB establishment, modification, release and reestablishment are completed via
the RAB ASSIGNMENT procedure.
MS
RNC
SGSN
1. RAB Assignment Request
2. RRC:
Establish/Release/Modify
Radio Bearers
3. RAB Assignment Response
.
.
.
* it can be several responses
Figure 1.1 RAB management procedure

Description:
The SGSN sends the RAB Assignment Request (SGSN ADDR, TEIDs, and QoS)
to the RNC, requesting it to establish, modify or release the RAB(s). It can
specify the RAB radio priority and whether preemption and queuing are allowed
in the assignment parameters.
RNC establishes, modifies or releases the radio bearer.
The RNC sends the RAB Assignment Response message to the SGSN. If the
assignment fails due to the QoS, then the QoS requirement should be lowered
and the assignment request should be resent.
If the QoS changes during RAB reestablishment, the SGSN-initiated PDP Context
Modification procedure will be executed to notify the QoS to both the MS and the
GGSN.
2)
Tunnel management
The major task of tunnel management is to establish a GTP tunnel between the
SGSN and the GGSN. Tunnel management includes tunnel establishment,
modification and deletion as well as the network-initiated PDP Context activation
procedure.
The SM implements session management through the PDP Context activation,
modification and deactivation procedures. The PDP Context activation procedure is to
establish the packet transport routes of the user plane; the PDP Context modification
procedure is to modify the QoS and TFT of the active PDP Context, as well as modify
the tunneling route between the SGSN and the GGSN in the case of RAU changes;
the PDP Context deactivation procedure is to release the active PDP Context.
After the RNC initiates the RAB or Iu release procedure, the SGSN may keep these
active PDP Contexts but not deactivate them. When the subscriber initiates the
2016-07-21

Page61, Total68

to appear here.
SERVICE REQUEST procedure for RAB reestablishment, the data transport

procedure can be recovered immediately.
6.8.2 PDP Context Activation

The PDP Context activation includes the MS-initiated and the network-initiated PDP
Context activation procedures as well as the secondary activation procedure. This
section only describes the MS-initiated PDP Context activation procedure.
1. MS-initiated PDP Context activation
MS
UTRAN
3G-SGSN
3G-GGSN
1. Activate PDP Context Request

C1
3. Radio Access Bearer Setup
4. Invoke Trace
5. Create PDP Context Request
5. Create PDP Context Response
C2
7. Activate PDP Context Accept
Figure 1.1 MS-initiated PDP Context activation

1)
2)
3)
4)
2016-07-21
The MS sends the Activate PDP Context Request (with NSAPI, TI, PDP Type,
PDP Address, Access Point Name and QoS Requested) to the SGSN. The PDP
Address indicates the dynamic or static address. If it indicates dynamic address,
it is set to null.
The RAB assignment procedure is executed.
The SGSN uses the PDP Type (optional), PDP Address (optional), Access Point
Name (optional) and PDP Context subscriber data to verify the validity of the
Activate PDP Context Request message.
The SGSN assigns a TEID to the PDP Context. If the dynamic address is to be
used, the SGSN requests the GGSN to allocate a dynamic address. The SGSN
selects an APN according to a certain algorithm and then sends the request to
establish a PDP Context to the GGSN.
The GGSN allocates a dynamic address for the PDP Context, as well as the
charging ID and negotiated QoS. If the MS requests that an IP address be
allocated for the external network part, the address will be set to 0.0.0.0. Later
after the external network is allocated with an IP address, the GGSN-initiated
PDP Context modification procedure will then be executed.
Upon receipt of the Create PDP Context Response message (with NSAPI, PDP
ADDR, GGSN ADDR, TEID and QoS) from the GGSN, the SGSN sends the
address and OoS information via the Activate PDP Context Accept message to
the MS.

Page62, Total68

to appear here.
2. The improvement of MS-initiated PDP Context activation procedure in the later

version.
In the early R99 version, if the GGSN has downgraded the QoS in the activation
procedure, it wont notify this to the RNC. So the resource occupied on the two sides
of the SGSN will be inconsistent and the resources at the air interface may be even
much more than the resources allocated in the core network, thus causing the waste
of air interface resources. In the later version (later R99/R4/R5/R6), the activation
procedure was optimized. The SGSN first interacts with the GGSN to establish a GTP
tunnel and then an RAB. After then, an optional PDP Context Modification procedure
may be executed to synchronize the resources on the two sides of the SGSN, if the
QoS is downgraded during the RAB establishment procedure.
MS
UTRAN
3G-SGSN
3G-GGSN
1. Activate PDP Context Request

C1
4. Create PDP Context Request
4. Create PDP Context Response
5. Radio Access Bearer Setup
6. Invoke Trace
C2
9. Activate PDP Context Accept
Figure 4.1 MS-initiated PDP Context activation (later version)
6.8.3 PDP Context Modification

The PDP Context modification procedures include the MS-initiated, SGSN-initiated
and the GGSN-initiated PDP Context modification procedures, as well as the SGSNinitiated PDP Context modification procedure due to RAB/Iu release. This section only
describes the MS-initiated and SGSN-initiated ones. The modification parameters
include QoS Negotiated, Radio Priority, Packet Flow Id, PDP Address (in case of the
GGSN-initiated modification procedure) and TFT (in the case of MS-initiated
modification procedure).
2016-07-21

Page63, Total68

to appear here.
1. SGSN-initiated PDP Context modification
MS
UTRAN
SGSN
GGSN

3. Modify PDP Context Request
4. Modify PDP Context Accept
C1
5. Radio Access Bearer Modification
6. Invoke Trace
Figure 1.1 SGSN-initiated PDP Context modification procedure

1)
2)
3)
4)
5)
6)
The SGSN sends the Update PDP Context Request (with TEID, NSAPI, QoS
Negotiated, Trace Reference, Trace Type, Trigger Id and OMC Identity) to the
GGSN for QoS negotiation.
The GGSN conducts the QoS negotiation and sends the Update PDP Context
Response (with TEID, QoS Negotiated and Cause) to the SGSN.
The SGSN selects the Radio Priority and Packet Flow Id according to the QoS. It
then sends to MS the Modify PDP Context Request (with TI, QoS Negotiated,
Radio Priority and Packet Flow Id).
The MS accepts the QoS by sending to the SGSN the Modify PDP Context
Accept message or rejects the QoS by initiating the PDP Context deactivation
procedure.
The RAB assignment procedure is executed to modify the RAB.
If BSS tracing is to be started, the Invoke Trace message (with Trace Reference,
Trace Type, Trigger Id and OMC Identity) will be sent.
2. MS-initiated PDP Context modification
MS
UTRAN
SGSN
GGSN
1. Modify PDP Context Request

4. Radio Access Bearer Modification
5. Modify PDP Context Accept
C1
Figure 6.1 MS-initiated PDP Context modification procedure

The purpose of the MS-initiated PDP Context modification procedure is to change the
QoS or TFT of the PDP Context.
2016-07-21

Page64, Total68

to appear here.
1)
2)
3)
4)
5)
The MS sends the Modify PDP Context Request message (with TI, QoS
Requested and TFT) to the SGSN, so as to request for changing the PDP
Context.
The SGSN sends the Update PDP Context Request (with TEID, NSAPI, QoS
Negotiated, Trace Reference, Trace Type, Trigger Id and OMC Identity) to the
GGSN for QoS negotiation.
The GGSN conducts the QoS negotiation and sends the Update PDP Context
Response (TEID, QoS Negotiated and Cause) to the SGSN.
The RAB assignment procedure is executed to modify the RAB.
The SGSN sends the Modify PDP Context Accept message to the MS.
6.8.4 PDP Context Deactivation

The PDP Context deactivation procedures include the MS-initiated, SGSN-initiated
and GGSN-initiated PDP Context modification procedures. This section only
describes the MS-initiated and the SGSN-initiated ones.
1. MS-initiated PDP Context deactivation
MS
UTRAN
3G-SGSN
3G-GGSN
1. Deactivate PDP Context Request

C1
4. Deactivate PDP Context Accept
5. Radio Access Bearer Release
Figure 1.1 MS-initiated PDP Context deactivation procedure

1)
2)
3)
4)
5)
The MS sends the Deactivate PDP Context Request message (with TI and
Teardown Ind) to the SGSN, where Teardown Ind indicates whether to deactivate
the PDP Context and specifies the active PDP Context for the TI shared address.
The SGSN receives the deactivation request from the MS and sends the Delete
PDP Context Request message (TEID, NSAPI and Teardown Ind) to the GGSN
to delete the GGSN PDP Context.
The GGSN sends the Delete PDP Context Response message (with TEID) to
the SGSN.
Upon receipt of the Delete PDP Context Response message, the SGSN sends
the Deactivate PDP Context Accept message to the MS.
The SGSN invokes the RAB assignment procedure to release the RAB.
2. SGSN-initiated PDP Context deactivation

The SGSN-initiated deactivation procedure is often triggered by the MM release or
various exceptions such as PDP Context inconsistency between the MS, the SGSN
and the GGSN, or RAB reestablishment failure or resource shortage.
2016-07-21

Page65, Total68

to appear here.
MS
UTRAN
SGSN
GGSN
C1
2. Deactivate PDP Context Request
2. Deactivate PDP Context Accept
3. Radio Access Bearer Release
Figure 5.1 SGSN-initiated PDP Context deactivation

1)
2)
3)
4)
5)
The SGSN sends the Delete PDP Context Request message (with TEID, NSAPI
and Teardown Ind) to the GGSN, where Teardown Ind indicates whether to
deactivate the PDP Context and specifies the active PDP Context for the TI
shared address.
The GGSN sends the Delete PDP Context Response message (with TEID) to
the SGSN.
Upon receipt of the Delete PDP Context Response message from the GGSN,
the SGSN sends the Deactivate PDP Context Request message to the MS to
delete the MS PDP Context. If the PDP Context deactivation procedure is
triggered by DETACH, this Deactivate PDP Context Request message will not be
sent.
The SGSN receives the Deactivate PDP Context Accept message from the MS.
The SGSN initiates the RAB assignment procedure to release the RAB.
6.8.5 Reservation Procedure and RAB Reestablishment

When the RNC initiates the RAB release and Iu release procedures, the PDP Context
may not be released, rather, the PDP Context will be reserved without any change for
RAB reestablishment in the later Service Request procedure.
1. MS-initiated service request for RAB reestablishment
When the MS has the uplink data transport needs while the PDP Context is active but
the RAB does not exist, the MS will initiate the Service Request procedure to
reestablish the RAB for the active PDP Context. The procedure is shown in the
following figure.
2016-07-21

Page66, Total68

to appear here.

MS
SGSN
RNC
HLR
GGSN

2. Service Request
4. Service Accept

Request
Complete

Res ponse
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 1.1 MS-initiated service request for RAB reestablishment

1)
2)
3)
4)
5)
6)
The RRC connection must be established first if there is no existing RRC

connection.
Service Type) to the SGSN. In the message, the Service Type parameter
indicates data.
The security procedure is executed.
The SGSN sends the Service Accept message to the MS, so as to reestablish
the RAB for each active PDP Context of the subscriber with RAB released.
If the QoS changes during RAB reestablishment, the SGSN-initiated PDP
Context Modification procedure will be executed to notify the QoS to both the MS
and the GGSN.
The MS transmits the uplink data.
2. SGSN-initiated service request for RAB reestablishment

When the SGSN receives the downlink signaling or data packet and finds that the
subscriber is in the PMM-IDLE state, it needs to initiate the paging procedure. Upon
receipt of the paging message, the MS sends the Service Request message with the
Service Type indicating Paging Response. If the Service Request procedure is
caused because the SGSN receives a data packet, the RAB Assignment procedure
will be invoked to reestablish the RAB.
2016-07-21

Page67, Total68

to appear here.
MS
RNC
SGSN
HLR
GGSN
1. Downlink PDU
2. Paging
2. Paging
4. Service Request

Complete

Request

Response
7. SGSN-Initiated PDP Context Modification Procedure

8. Downlink PDU
Figure 6.1 SGSN-initiated service request for RAB reestablishment
2016-07-21

Page68, Total68

Chapter 6 Basic Signaling Procedures

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Chapter 6 Basic Signaling Procedures

Încărcat de

Drepturi de autor:

Formate disponibile

Basic Principles of WCDMA System

Error! Use the Home tab to apply