Basic Signaling Procedures - 67 PDF

Basic Principles of WCDMA System Basic Signaling Procedures
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.
2004-08-24 Confidential Information of Huawei. No Page6-1, Total67

Spreading without Permission
MO Service Flow
Non Access Strat um : MM/SM/CC/SMS
AS :RRC AS : RANAP
UTRAN CN
Switch on AS : P LMN Selection , Cell Selection , RRC Connection Setup , Iu Connection Setup
MM P rocedures of NAS : Attach , Security Functions , Location Management;
St art Service : Call Control Procedures of CS , Section Management P rocedures of PS , set up the service bearer
Finish Service : Call Control Procedures of CS , Section Manage ment P rocedures of PS, release the service bearer
Switch off MM P rocedures of NAS : Detach ( include the IMSI Detach, GP RS Detach )
AS : RRC Connection Release Iu Connection Release
Figure 6-1 Calling procedure
1) 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.
2) 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.
3) After passing the procedures such as authentication, the UE enters the
service-related 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.
4) 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..
5) 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.
6) 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 switch-off
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.

MT Service Flow
Non Access Strat um : MM/SM/CC/SMS
AS : RRC AS : RANAP
UTRAN CN
IDLE St ate: NAS: P aging P rocedure initiated by CN
AS : RRC Connection Setup Iu Connection Setup
MM P rocedures of NAS : Security Functions;
St art Service : Call Control Procedures of CS , or Section Manage ment P rocedures of PS, set up the service bearer
Finish Service : Call Control P rocedures of CS , or Section Management P rocedures of PS, release the service bearer
IDLE St ate: AS：RRC Connection Release Iu Connection Release
Figure 6-2 Called procedure
1) The UE of the subscriber is in the idle state. Now it is paged from the network side.
2) 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.
3) The authentication and ciphering procedures of mobility management may be
executed.
4) The service bearer is established through the CS call connection procedure and
the PS session management procedure for service proceeding.
5) After the service ends, the related service bearer is cleared.
6) 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 non-access
stratum identification such as IMSI, TMSI or P-TMSI. The UTRAN does not 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 6-3 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:

z A dedicated physical channel is allocated to the UE in both the uplink and the
downlink.
z RNC knows the cell where the UE camps on according the current active set of the
UE.
z 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) 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.
2) 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.
2. CELL_FACH state
The CELL_FACH state features the following:

z No dedicated transport channel is allocated to the UE.

z The UE continuously monitors a downlink FACH channel.

z 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.
z 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:
z Monitors an FACH.
z Monitors the BCH channel of the current serving cell to decode the system
messages.
z Initiates a cell update procedure when the cell becomes another UTRA cell.
z Uses the C-RNTI allocated in the current cell as the UE identification on the
common transport channel unless a new cell is selected.
z 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:

z No dedicated channel is allocated to the UE.
z 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.
z 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.
Monitors the BCH channel of the current serving cell to decode the system 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:

z No dedicated channel is allocated to the UE.
z The DRX technology is adopted for the UE to monitor the information transmitted
on the PCH channel at a specific paging time slot.
z No uplink activity is allowed.
z 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:
z Monitors the paging time slot based on the DRX period and receives the paging
messages transmitted on the PCH.
z Monitors the BCH channel of the current serving cell to decode the system
messages.
z 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:
z To establish a call or a signaling connection, the upper layer at the network side
initiates the paging procedure.
z 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.
z 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.
UE UTRAN
PAGING TYPE 1
Figure 6-4 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.
UE UTRAN
PAGING TYPE 2
Figure 6-5 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:

User selection Automatic/

of PLMN Manual selection
PLMN Selection
Indication
and Reselection
to user Location PLMNs
Registration available
response
PLMN
selected
NAS Control
Cell Selection
and Reselection
Radio measurements
Registration
Area
changes
CM requests
Location
Registration
Figure 6-6 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:
z The UE can receive the system messages broadcast by the PLMN.
z The UE can initiate the random access procedure in the cell.
z The UE can receive the paging from the network.
z 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 UE’s 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.

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.
z 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).
z 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

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.

1. RRC connection established on a dedicated channel
UE NodeB SRNC
1. RRC CONNECTION REQUEST
2. Allocate
RNT1, L1 and
3. RL SESETUP REQUEST L2 parameters
4. RL SETUP RESPONSE
5. ALCAP establishment and synchronization
6. RRC CONNECTION SETUP
7. RRC CONNECTION SETUP COMPLETE
Figure 6-7 RRC connection established on the dedicated channel
Description:
1) The UE sends an RRC Connection Request message via the uplink CCCH to
request to establish an RRC connection.
2) 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.
3) 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.
4) After successfully preparing the resources, the Node B responds to the SRNC with
the Radio Link Setup Response message.
5) 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.
6) The SRNC sends an RRC Connection Setup message to the UE in the downlink
CCCH.
7) 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.

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:
UE SRNC CN
1.RRC INITIAL DIRECT TRANSFER
2.RANAP: INITIAL UE MESSAGE(CR)
3.SCCP CC (Success)
3.SCCP CC (Failure)
Figure 6-8 Signaling setup procedure
The specific procedure is given as follows:

1) 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.
2) 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.
3) 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.
4) 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.
The RAB setup is initiated by the CN and executed by the UTRAN. The basic
procedure is as follows:
z First the CN sends the RAB assignment request message to the UTRAN,
requesting the UTRAN to establish the RAB.
z The SRNC in the UTRAN initiates the establishment of the data transport bearer
between the Iu interface and the Iub interface (Iur interface).
z The SRNC sends the RB setup request to the UE.
z After completing the RB establishment, the UE responds to the SRNC with the RB
setup complete message.
z 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) DCH-DCH: The RRC uses the DCH, while the RAB prepares to use the DCH.
2) RACH/FACH-RACH/FACH: The RRC uses the CCH, while the RAB prepares to
use the CCH.
3) 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.
z 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.
z In the asynchronous case, after receiving the configuration message from the
SRNC, the Node B and the UE immediately use the new configuration
parameters.
1) Synchronous RL reconfiguration
In the DCH-DCH synchronization case, synchronous reconfiguration of RL is required
among the SRNC, the Node B and the UE.
z 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.
z 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.
z The Node B and the UE use the new configuration parameters at the same time in
the synchronization time specified by the SRNC.

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 6-9 RAB setup procedure (DCH-DCH, synchronous)
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 (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.
2) 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.

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 6-10 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 CN-initiated
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:
1) Returns the IU RELEASE COMPLETE message to the CN.
2) Initiates the release of the user plane transport bearer of the Iu interface.
3) 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 6-11 Release of the RRC connection established on a dedicated channel
Description:
1) The RNC sends the RRC Connection Release message to the UE.
2) The UE returns the RRC Connection Release Complete message to the RNC.
3) The RNC sends the Radio Link Deletion message to the Node B to delete the
radio link resources in the Node B.
4) After releasing its related resources, the Node B returns the Radio Link Deletion
Response message to the RNC.
5) 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
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) 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.
2) 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.
3) 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) 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.
2) The RNC compares the reported measurement result with the set threshold to
decide the cells to be added and deleted.
3) If some cells are to be added, the RNC notifies the Node B to get ready.
4) The RNC notifies the UE to add and/or delete cells via the active set update
message.
5) 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.
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 6-12 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) Hard handover between FDD and TDD in the same cell.
2) Hard handover among cells in a Node B.
3) Hard handover among cells in different Node Bs in the same RNC.
4) 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) Physical channel reconfiguration.
2) Transport channel reconfiguration.
3) Radio bear setup.
4) Radio bear release.
5) 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

UE Target NodeB 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 6-13 Hard handover procedure
Description:
1) 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.
2) 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.
3) 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.
4) The SRNC sends the Physical Channel Reconfiguration message carrying the
target cell information to the UE via the downlink DCCH.
5) 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.
6) 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.
7) 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.
8) 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.
9) 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
UE-related 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) Cell update

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.
z 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 6-14 Cell update procedure

¾ 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.
z 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.
z 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.
z 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.
2) 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 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.
z 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 6-15 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.
z 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.
z Handover to UTRAN

UE UTRAN CN
1.RELOCATION REQUEST
2. RELOCATION REQUEST
ACKNOWLEDGE
3. HANDOVER TO UTRAN
COMPLETE
Figure 6-16 Handover-to UTRAN procedure

1) The CN notifies the UTRAN that a UE is to be handed over to it via the Relocation
Request message.
2) 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.
3) 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 UE’s
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 DRNC Old SRNC SRNC
NODEB NODEB NODEB NODEB

CELL CELL CELL CELL CELL CELL CELL CELL
UE UE
Figure 6-17 Static relocation procedure

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 UE’s participation, it is also called the UE Involved relocation.
The connection change is shown in the following figure:
CN CN
SRNC Target RNC Old SRNC SRNC
NODEB NODEB NODEB NODEB

CELL CELL CELL CELL CELL CELL CELL CELL
UE UE
Figure 6-18 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:

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.

Figure 6-19 Location update flow
1) The MSC/VLR receives the location update request initiated by the subscriber with
TMSI. If the TMSI is not known:
A. 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.
B. 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.
2) 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.
3) 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.
4) 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.

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 6-20 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:
z 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).
z 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 6-21 IDENTITY procedure

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 6-22 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 6-23 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 UE’s 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.

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 6-24 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
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 6-25 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 re-insert 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 6-26 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 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 6-27 TMSI reallocation during location update

& 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.

Figure 6-28 Combined location update
1) Upon receipt of the RA update request from the MS, the SGSN may initiate the
location update procedure to the HLR when necessary.
2) 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.
3) Upon receipt of the location update request from the SGSN, the MSC/VLR
updates the MS location and stores the relevant data.
4) Upon receipt of the Location Update Accept message from the HLR, the
MSC/VLR sends it via the Gs interface to the SGSN.
5) 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.

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
z GMM/PMM
GMM: GPRS Mobility Management (different from CMM Circuit Mobility Management)
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.
z RANAP
RANAP (Radio Access Network Application Part) encapsulates and transports
higher-layer signaling, processes the signaling between the 3G-SGSN and the UTRAN,
and manages the GTP connections at the Iu interface.
z 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 / GMM /
SM / SMS SM / SMS
Relay
RRC RRC RANAP RANAP
RLC RLC SCCP SCCP
MAC MAC Signalling Signalling

Bearer Bearer
AAL5 AAL5
L1 L1
ATM ATM
Uu Iu-Ps
MS RNS 3G SGSN
Figure 6-29 Control plane protocols at the MS side and the network side of the PS domain in the UMTS
6.6.2 Mobility Management State
The PMM states in the UMTS include PMM-DETACHED, PMM-IDLE and

PMM-CONNECTED.
z 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.
z PMM IDLE State
In this state, the MS location is known but the MS is idle.
z 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 6-30 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:
z Combined GPRS/IMSI Attach/Detach procedure
z IMSI-attached GPRS Attach procedure
z GPRS-attached IMSI Attach procedure (combined RA update)
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.
6.6.4 Combined GPRS/IMSI Attach Procedure
new old
MS UTRAN new SGSN old SGSN GGSN EIR MSC/VLR HLR 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 6-31 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) 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.
2) 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 then respond with the
Identification Response message that carries the subscriber’s 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.
3) 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.
4) 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.
5) The IMEI check as defined in the identity check procedure takes place. This
function is currently not implemented.
6) 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
specific procedure is given as follows:
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.
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 6-32 MS-initiated detachment
1) The MS sends the Detach Request message (with Detach Type, P-TMSI, P-TMSI
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 P-TMSI
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.
2) 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.
3) In the case of IMSI Detach, the SGSN should send the IMSI Detach Indication
message to the VLR.
4) 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.

5) 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.
6) If the MS initiates the GPRS Detach procedure, the SGSN will release the PS
domain signaling connection.
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-33 SGSN-initiated detachment
1) 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.
2) 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.
3) 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.
4) The MS may, upon receipt of the Detach Request from the SGSN, send the
Detach Accept message at any time to the SGSN.
5) 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 6-34 Authentication and ciphering

1) 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
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.
2) 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.
3) 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.

6.6.7 Location Management (Routing Area Update)
new old new old

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

2. SGSN Context Request
2. SGSN Context Response

3. Security Functions
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 6-35 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;
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) 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.
3) 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.
4) 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.
5) 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.
6) 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.
7) 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.
8) 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 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.

9) 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.
10) 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.
11) 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.
12) 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.
13) 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.
14) The MS sends the Attach Complete message to the SGSN to acknowledge the
new TMSI.
15) 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.

6.6.8 Service Request
1. MS-initiated service request
MS RNC SGSN HLR GGSN

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

Request
5. Radio Bearer Setup

Complete
Response
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 6-36 MS-initiated service request
1) The MS establishes the RRC connection first if there is no existing CS channel.

2) 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) If the MS initiates a service request in the PMM-IDLE state, the SGSN will initiate
the security procedure.
4) 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.
5) The RNC indicates to the MS that the new RAB has been established (together
with the RAB ID).
6) 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.

7) 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.
8) 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
1. Downlink PDU
2. Paging
2. Paging
4. Service Request

6. Radio Bearer Setup Request

Complete 6. Radio Access Bearer Assignment
Response
7. SGSN-Initiated PDP Context Modification Procedure
8. Downlink PDU
Figure 6-37 Network-initiated service request
1) The SGSN receives the downlink PDP PDU from the MS in the PMM-IDLE state.
2) The SGSN sends a paging message to the RNC and the RNC sends the paging
message to page the MS.
3) 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.
5) The SGSN specifies the ciphering mode.
6) 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 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.
7) 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.
8) 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.

Figure 6-38 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 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 6-39 Mobile-terminated call setup procedure
1) 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.
2) 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.
3) 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).
4) The CN sends a SETUP message to the RNS. The SETUP message carries the
bearer capability of the call and the calling number.
5) 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.
6) 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.
7) The RNS sends a RAB ASSIGNMENT RESPONSE message to the CN.
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.

3. RAB establishment, release and modification procedures
RNC CN
RAB ASSIGNMENT
REQUEST
RAB ASSIGNMENT
RESPONSE
.
.
.
*
* it can be several responses
Figure 6-40 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
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.

UE Node B Serving
Serving RNS RNC CN
1. RAB Assignment Request

RANAP 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
2.1 Establish Confirm Q.aal2
Q.aal2
NBAP Radio Link Reconfiguration Prepare

NBAP
[DCH Addition]
NBAP Radio Link Reconfiguration Ready

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
RRC 3 DCCH: Radio Bearer Setup RRC
Apply new transport format set
RRC DCCH : Radio BearerSetup Complete RRC
RANAP 4. RAB Assignment Response RANAP
5. Initialization
Iu UP Iu UP
(RFCI, 0..N + subflow size information)
Figure 6-41 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.
z 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.
z Procedure
1) 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, 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.
2) 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) 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.
4) 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.
5) 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

non-synchronous modes, the procedures are similar.

5. RAB release procedure
UE Node B Serving CN
Serving RNS RNC
1 RAB Assignment Request
RANAP RANAP
[Release]
RANAP 2. RAB Assignment Response RANAP
3. ALCAP Iu Data Transport Bearer Release
not required towards PS domain

3.1 Release Request
Q.aal2 Q.aal2
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

NBAP NBAP
DCCH : Radio Bearer Release

RRC RRC
Apply new transport format set

DCCH
DCCH : Radio Bearer Release Complete

RRC RRC
Iub Data Transport Bearer Release

ALCAP
Figure 6-42 RAB release (DCH-DCH synchronous release procedure)
z 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.
z Procedure
1) 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.
2) The Serving RNC acknowledges the request message with another RANAP
message, i.e. Radio Access Bearer Assignment Response.
3) 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).
4) 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.
5) The Serving RNC receives the acknowledgement RRC message (Radio Bearer
Release Complete) from the UE and the whole release procedure thus ends.

6. RAB modification procedure
Node B Serving
UE Serving RNS RNC 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
(
3.1 Modify Request
Q.aal2 Q.aal2
3.2 Modify Confirm Q.aal2

Q.aal2
NBAP Radio Link Reconfiguration Prepare NBAP
NBAP Radio Link Reconfiguration Ready

NBAP
ALCAP Iub Data Transport Bearer Modify
NBAP Radio Link econfiguration Commit NBAP
4 Radio Bearer Reconfiguration (DCCH

RRC RRC
Actualizing Radio Bearer modification (e.g. Apply new transport format set)
5 Radio Bearer Reconfiguration Complete DCCH

RRC RRC
RANAP 6 RAB Assignment Response

RANAP
7. Initialization
Iu UP Iu UP
(RFCI, 0..N + subflow size information)
Figure 6-43 RAB modification (DCH-DCH synchronous modification procedure)
z 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.
z Procedure
1) 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.
2) The Serving RNC selects which parameters are to be modified and which
programs are to be initiated.
3) The SRNC uses the ALCAP protocol to modify the channel characteristics of the
Iu interface data transport bearers.
4) 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.
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.
RNC CN
PAGING
Figure 6-44 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.

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 6-45 Paging procedure of the UE in the RRC idle state
1) 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.
2) Cell 1 initiates the paging procedure via the Paging Type 1 message.
3) 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) The UTRAN coordinates the paging request over the existing RRC connection;
2) 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.

Figure 6-46 Paging procedure of the UE in the RRC connected state (CELL_DCH and CELL_FACH)
1) The CN sends the PAGING message via RANAP to UE to page the UE.
2) 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 6-47 Successful mobile-originated call release

1) 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.
2) Upon receipt of the DISCONNECT message, the network sends a RELEASE
message to the MS.
3) 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.
4) 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.

INACTIVE
Deactivate PDP Context

Activate PDP or
Context MM state change to IDLE
or PMM-DETACHED
ACTIVE
Figure 6-48 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 / GMM /
SM / SMS SM / SMS
Relay
RRC RRC RANAP RANAP
RLC RLC SCCP SCCP
MAC MAC Signalling Signalling

Bearer Bearer
AAL5 AAL5
L1 L1
ATM ATM
Uu Iu-Ps
MS RNS 3G SGSN
Figure 6-49 UMTS MS-SGSN control plane protocol

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 6-50 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
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 6-51 MS-initiated PDP Context activation
1) 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.
2) The RAB assignment procedure is executed.
3) 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.
4) 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.

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 won’t 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.
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 6-52 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
SGSN-initiated 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).

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 6-53 SGSN-initiated PDP Context modification procedure
1) 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.
2) The GGSN conducts the QoS negotiation and sends the Update PDP Context
Response (with TEID, QoS Negotiated and Cause) to the SGSN.
3) 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).
4) 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.
5) The RAB assignment procedure is executed to modify the RAB.
6) 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-54 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.

1) 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.
2) 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.
3) The GGSN conducts the QoS negotiation and sends the Update PDP Context
Response (TEID, QoS Negotiated and Cause) to the SGSN.
4) The RAB assignment procedure is executed to modify the RAB.
5) 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
1. Deactivate PDP Context Request
C1

4. Deactivate PDP Context Accept
5. Radio Access Bearer Release
Figure 6-55 MS-initiated PDP Context deactivation procedure
1) 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.
2) 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.
3) The GGSN sends the Delete PDP Context Response message (with TEID) to the
SGSN.
4) Upon receipt of the Delete PDP Context Response message, the SGSN sends the
Deactivate PDP Context Accept message to the MS.
5) 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.

MS UTRAN SGSN GGSN
C1

2. Deactivate PDP Context Request
2. Deactivate PDP Context Accept
3. Radio Access Bearer Release
Figure 6-56 SGSN-initiated PDP Context deactivation
1) 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.
2) The GGSN sends the Delete PDP Context Response message (with TEID) to the
SGSN.
3) 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.
4) The SGSN receives the Deactivate PDP Context Accept message from the MS.
5) 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.


2. Service Request
4. Service Accept

Request

Complete
Response
7. SGSN-Initiated PDP Context Modification
8. Uplink PDU
Figure 6-57 MS-initiated service request for RAB reestablishment
1) 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.
3) The security procedure is executed.
4) 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.
5) 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.
6) 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.

1. Downlink PDU
2. Paging
2. Paging
4. Service Request

6. Radio Bearer Setup Request

Complete 6. Radio Access Bearer Assignment
Response
7. SGSN-Initiated PDP Context Modification Procedure
8. Downlink PDU
Figure 6-58 SGSN-initiated service request for RAB reestablishment


Basic Signaling Procedures - 67 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Basic Signaling Procedures - 67 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Basic Principles of WCDMA System Basic Signaling Procedures

Chapter 6 Basic Signaling Procedures

6.1.1 Types of Signaling Procedures

6.1.2 General Introduction

The following gives a simple description of the basic signaling procedures.

2004-08-24 Confidential Information of Huawei. No Page6-1, Total67

Non Access Strat um : MM/SM/CC/SMS

MM P rocedures of NAS : Attach , Security Functions , Location Management;

AS : RRC Connection Release Iu Connection Release

Figure 6-1 Calling procedure

2004-08-24 Confidential Information of Huawei. No Page6-2, Total67

Non Access Strat um : MM/SM/CC/SMS

AS : RRC Connection Setup Iu Connection Setup

MM P rocedures of NAS : Security Functions;

IDLE St ate: AS：RRC Connection Release Iu Connection Release

Figure 6-2 Called procedure

6.2 UE State and Paging Procedure

Figure 6-3 Operating modes of the UE

In the connected mode, the UE has altogether four states:

The CELL_DCH state features the following:

The CELL_FACH state features the following:

2004-08-24 Confidential Information of Huawei. No Page6-4, Total67

z The UE continuously monitors a downlink FACH channel.

The CELL_PCH state features the following:

The URA_PCH state features the following:

6.2.2 Paging Procedure

Different from fixed communications, the location of the communication terminal in

Figure 6-4 Paging a UE in the idle mode or the PCH state

2004-08-24 Confidential Information of Huawei. No Page6-6, Total67

Figure 6-5 Paging a UE in the CELL_DCH or CELL_FACH state

6.3 UE in the Idle Mode

2004-08-24 Confidential Information of Huawei. No Page6-7, Total67

User selection Automatic/

Figure 6-6 UE in the idle mode

2004-08-24 Confidential Information of Huawei. No Page6-8, Total67

6.3.2 PLMN Selection and Reselection

6.3.3 Cell Selection and Reselection

The cell selection procedure is as follows:

2004-08-24 Confidential Information of Huawei. No Page6-9, Total67

3. Cell selection after the UE leaves the connected mode

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

2004-08-24 Confidential Information of Huawei. No Page6-10, Total67

1. RRC connection established on a dedicated channel

5. ALCAP establishment and synchronization

6. RRC CONNECTION SETUP

7. RRC CONNECTION SETUP COMPLETE

Figure 6-7 RRC connection established on the dedicated channel

2. RRC connection established on a common channel

2004-08-24 Confidential Information of Huawei. No Page6-11, Total67

6.4.2 Signaling Setup Procedure

1.RRC INITIAL DIRECT TRANSFER

2.RANAP: INITIAL UE MESSAGE(CR)

Figure 6-8 Signaling setup procedure

The specific procedure is given as follows:

6.4.3 RAB Establishment Procedure

2004-08-24 Confidential Information of Huawei. No Page6-13, Total67

The following is the DCH-DCH synchronous RL reconfiguration in the RAB setup

Figure 6-9 RAB setup procedure (DCH-DCH, synchronous)

2004-08-24 Confidential Information of Huawei. No Page6-14, Total67

5. ALCAP establishment and synchronization