GPRS Signalling Messages On GRR, GMM and SM: Network MS

GPRS Signalling Messages and Procedures on the Air interface
GPRS Signalling messages on GRR, GMM and

SM
Dipl.-Ing. Reiner Stuhlfauth, ROHDE&SCHWARZ, Training Center Munich
Summary
GPRS introduces a new kind of signalling to the existing GSM network. There will be an
extension of the existing circuit switched protocol plane with a new one, the packet switched
protocol plane. Therefore some new protocols are included in the GPRS network. The
following figure summarizes the protocol plane between MS and network:
Maps network level

characteristics onto
characteristics of
underlying protocols
SNDCP
SNDCP
LLC
LLC
(Note)
MAC
RLC
RLC
Access Control signalling

+
Mapping of LLC-Frames
onto physical channels
MAC
MAC
Phys. Link
Phys. Link
Phys. RF
Phys. RF
RLC
Reliable link +
Radio Link Control
functions
MS
Um
SNDCP = SubNetwork Dependent Convergence Protocol

LLC = Logical Link Control
LLC = Logical Link Control
Logical Link between MS

and SGSN. Independent
from Radio Interface
Data Coding, Burst Forming,

Interleaving, Convolutional
Coding = Error protection
Modulation, Timing
and RF-Generation
Network
RLC = Radio Link Control
MAC = Medium Access Control
Figure: GPRS protocol plane between MS and network
The SNDCP layer is responsible for mapping the characteristics of the network level onto the
underlying protocols, which are responsible for data transfer over the air interface.
Furthermore, the SNDCP multiplexes the data of different applications, the so called PDP
contexts, onto the one transmitting channel created by an established radio link.
The LLC layer forms a logical link for data transfer between network and Mobile Station, MS.
What is special about this data transfer link, is that it is completely independent from the
underlying protocols describing or configuring the air interface. In addition, LLC offers some
adjacent features like ciphering, acknowledged or unacknowledged data transfer or like inorder-delivery.
1MAT, St, Version 1.0
The RLC layer is responsible for establishing a radio link, for maintaining it or for releasing it.
This protocol layer specifies a list of signalling messages to be exchanged between MS and
the network to fulfill some tasks concerning the radio link. In this chapter the messages will be
described in detail.
The main task of the MAC layer is to organize the access to the radio network. One of its
main parameters is, for example, the USF value field which identifies the right user of the
succeeding radio block.
The Physical link layer will build the transportation packets, i.e. the radio blocks, and will form
the used GSM Normal Bursts. The training sequence will be included, the interleaving
procedure will be done and the burst will be structured. This layer more or less describes the
same features that are already known from a GSM network, the only difference is the block
data encoding. While in GSM there was an encoding of speech data onto a Normal Burst, in
GPRS there will be an encoding of user data, depending on the used Coding scheme.
The Physical RF layer basically describes the air interface with its modulation scheme, output
power control, frequency channel and timeslot allocation characteristics. Most of its
parameters are already known in the GSM air interface. The only difference to GSM will be in
a future development step the transition to the new modulation scheme 8PSK.
Signalling messages of GPRS Radio Resource management,

GRR:
The GRR uses a list of signalling messages to establish, maintain or release a radio link
between MS and the network. The used messages of the RLC/MAC layer are the following:
GRR Signalling Messages (Via RLC/MAC)

Downlink Messages
Packet TBF Release

Packet Cell Change Order
Packet Uplink Ack / Nack
Packet Downlink Assignment
Packet Uplink Assignment
Packet Paging Request
Packet Downlink Dummy Control Block
Packet PDCH Release
Packet System Information Type 1
Packet Polling Request
Packet Power Control/Timing Advance Packet System Information Type 3
Packet PRACH Parameters
Packet System Information Type 3 bis
Packet Queueing Notification
Packet Timeslot Reconfigure
Packet Access Reject
GRR Signalling Messages (Via RLC/MAC)

Uplink Messages
Packet Cell Change Failure

Packet Control Acknowledgement
Packet Downlink Ack / Nack
Packet Uplink Dummy Control Block
Packet Measurement Report
Packet Resource Request
Packet Mobile TBF Status (SMG #30+)
Packet PSI Status (SMG #30+)
But how do we distinguish between the different messages? In the RLC / MAC block we find
a field message type. This field indicates which of the following messages is sent.
< Downlink RLC/MAC control message > ::=

< MESSAGE_TYPE : bit (6) == 1 00001 >
< Packet Access Reject message content > |
< MESSAGE_TYPE : bit (6) == 0 00001 >
< Packet Cell Change Order message content > |
< MESSAGE_TYPE : bit (6) == 0 00010 >
< Packet Downlink Assignment message content > |
< MESSAGE_TYPE : bit (6) == 0 00011 >
< Packet Measurement Order message content > |
< MESSAGE_TYPE : bit (6) == 1 00010 >
< Packet Paging Request message content > |
< MESSAGE_TYPE : bit (6) == 1 00011 >
< Packet PDCH Release message content > |
< MESSAGE_TYPE : bit (6) == 0 00100 >
< Packet Polling Request message content > |
< MESSAGE_TYPE : bit (6) == 0 00101 >
< Packet Power Control/Timing Advance message content > |
< MESSAGE_TYPE : bit (6) == 1 00100 >
< Packet PRACH Parameters message content > |
< MESSAGE_TYPE : bit (6) == 0 00110 >
< Packet Queueing Notification message content > |
< MESSAGE_TYPE : bit (6) == 0 00111 >
< Packet Timeslot Reconfigure message content > |
< MESSAGE_TYPE : bit (6) == 0 01000 >
< Packet TBF Release message content > |
< MESSAGE_TYPE : bit (6) == 0 01001 >
< Packet Uplink Ack/Nack message content > |
< MESSAGE_TYPE : bit (6) == 0 01010 >
< Packet Uplink Assignment message content > |
< MESSAGE_TYPE : bit (6) == 1 00101 >
< Packet Downlink Dummy Control Block message content > |
< MESSAGE_TYPE : bit (6) == 1 10001 >
< PSI1 message content > |
< MESSAGE_TYPE : bit (6) == 1 10010 >
< MESSAGE_TYPE : bit (6) == 1 10011 >
< MESSAGE_TYPE : bit (6) == 1 10100 >
< PSI3 bis message content > |
< MESSAGE_TYPE : bit (6) == 1 10101 >
< MESSAGE_TYPE : bit (6) == 1 10110 >
< MESSAGE_TYPE : bit (6) == 1 10000 >
< MESSAGE_TYPE : bit (6) == 1 11000 >
< MESSAGE_TYPE : bit (6) == 1 11001 >
< MESSAGE_TYPE : bit (6) == 1 10111 >
< PSI13 message content >
! < Unknown message type : bit (6) = < no string > < Default downlink message content > > ;
< Uplink RLC/MAC control message > ::=

< MESSAGE_TYPE : bit (6) == 000000 >
< MESSAGE_TYPE : bit (6) == 000001 >
< MESSAGE_TYPE : bit (6) == 000010 >
< MESSAGE_TYPE : bit (6) == 000011 >
< MESSAGE_TYPE : bit (6) == 000100 >
< MESSAGE_TYPE : bit (6) == 001010 >
< MESSAGE_TYPE : bit (6) == 000101 >
< MESSAGE_TYPE : bit (6) == 000110 >
< MESSAGE_TYPE : bit (6) == 000111 >
< MESSAGE_TYPE : bit (6) == 001000 >
< MESSAGE_TYPE : bit (6) == 001001 >
< MESSAGE_TYPE : bit (6) == 001010 >
< Packet Cell Change Failure message content > |

< Packet Control Acknowledgement message content > |
< Packet Downlink Ack/Nack message content > |
< Packet Uplink Dummy Control Block message content > |
< Packet Measurement Report message content > |
< Packet Enhanced Measurement Report message content > |
< Packet Resource Request message content > |
< Packet Mobile TBF Status message content > |
< Packet PSI Status message content > |
< EGPRS Packet Downlink Ack/Nack message content > |
< Packet Pause message content > |
< Additional MS Radio Access Capabilities message content>;
The description of the single messages is given as follows, in chronological order,

corresponding to the message type field:
Packet Access Reject
This message is sent on the PCCCH or PACCH by the network to the mobile station to
indicate that the network has rejected the MSs access request. This message may contain
fields addressing more than one mobile station. The direction of this message is network to
MS.
Packet Control Acknowledgement
This message is sent on the PACCH from the mobile station to the network. The message is
formatted either as an RLC/MAC control block or as 4 identical access bursts. If sent as a
response to a Packet Polling Request message, this latter message shall specify the format
of the Packet Control Acknowledgement message. Otherwise, the System Information
parameter CONTROL_ACK_TYPE indicates which format the mobile station shall use.
The access burst format is 11 bits or 8 bits long. If the System Information parameter
ACCESS_BURST_TYPE indicates 11-bit access, the mobile station shall transmit the 11-bit
format. If the System Information parameter ACCESS_BURST_TYPE indicates 8-bit access,
the mobile station shall transmit the 8-bit format. The mobile station shall transmit the access
burst four times, once in each TDMA frame of the uplink radio block.
This message is sent in the direction of mobile station to network.
Packet Cell Change Failure
This message is sent on the PACCH from the mobile station to the network to indicate that a
commanded cell change order has failed.
Packet Cell Change Order
This message is sent on the PCCCH or PACCH by the network to the mobile station to tell
the mobile station to leave the current cell and change to a new cell. This message is the
GPRS replacement for the Handover command (HND_CMD) message in GSM.
Packet Channel Request
This message is sent in random mode on the PRACH. It does not follow the basic format of a
GSM Normal Burst. For this message, the MS will use the short Access Burst, just as known
in GSM. The possible formats of this burst are 8 or 11-bit format. The total length of this burst
is still the same, only the synchronisation sequence of this burst will be shorter, while the
message length will be enhanced to 11 bit instead of 8 bit length which is already known.
The message is 11 bits or 8 bits long. If the System Information parameter
ACCESS_BURST_TYPE indicates 11-bit access, the mobile station shall transmit the 11-bit
format. If the System Information parameter ACCESS_BURST_TYPE indicates 8-bit access,
the mobile station shall transmit the 8-bit format.
EGPRS Packet Channel Request
This message is sent by EGPRS capable MSs in cells supporting EGPRS and using 11 bit
ACCESS BURST TYPE. This message is sent to perform EGPRS one-phase access
request, EGPRS short access request or EGPRS two-phase access request. For all other
purposes (page response, cell update etc.) the standard PACKET CHANNEL REQUEST
message shall be used.
Packet Downlink Ack/Nack

This message is sent on the PACCH from the mobile station to the network to indicate the
status of downlink RLC data blocks received and to report the channel quality of the downlink.
The mobile station may optionally initiate an uplink TBF.
EGPRS Packet Downlink Ack/Nack
This message is sent on the PACCH from the mobile station to the network to indicate the
status of downlink RLC data blocks received and to report the channel quality of the downlink.
The mobile station may optionally initiate an uplink TBF or request a temporary suspension of
the downlink TBF.
Packet Downlink Assignment
assign downlink resources to the mobile station.
For a mobile station assigned to operate in the fixed allocation MAC mode, the network may
assign regularly repeating intervals during which the mobile station shall measure neighbour
cell power levels. A mobile allocation or reference frequency list received as part of this
assignment message shall be valid until a new assignment is received or each TBF of the MS
is terminated.
Packet Downlink Dummy Control Block
This message is sent on the PCCCH or PACCH by the network to the mobile station as a fill
message with either of the optional parameters PAGE_MODE and PERSISTENCE_LEVEL,
or with no content.
Packet Uplink Dummy Control Block
This message is sent on the PACCH from the mobile station to the network when the mobile
station has no other block to transmit.
Packet Measurement Report
This message is sent on the PACCH from the mobile station to the network to report
measurement results. The message may contain measurement results from the Network
Control measurements or from the Extended measurements, but not both simultaneously.
More than one message may be required depending on the number of measurements to
report.
Packet Measurement Order
This message is sent on the PCCCH or PACCH by the network to a mobile station giving
information for NC and EXT measurement reporting and network controlled cell reselection. If
not all information fits into one message, the remaining information will be sent in other
instances of the Packet Measurement Order message.
Packet Mobile TBF Status
This message is sent from the mobile station to the network on the uplink PACCH to indicate
erroneous messages have been received relating to either a downlink or an uplink TBF.
Packet Enhanced Measurement Report

This message is sent either on the PACCH, if in packet transfer mode, or on an assigned
block on a PDTCH, from the mobile station to the network to report enhanced measurement
results. The message contains measurement results from the Network Control
measurements. More than one message may be required depending on the number of
measurements to report.
Packet Paging Request
This message is sent on the PCCCH by the network to trigger channel access by up to four
mobile stations, for either TBF or RR connection establishment. It may also be sent on
PACCH to a mobile station in packet transfer mode to indicate page request for RR
connection establishment. The mobile stations are identified by either IMSI, TMSI or P-TMSI.
Depending on the method used to identify the mobile station, 1 - 4 mobile stations can be
addressed in the message. Special requirements for the transmission of this message on
PACCH applies, see specifications GSM 05.02.
Packet PDCH Release
This message is sent on PACCH by the network to notify all mobile stations listening to that
PDCH that one or more PDCHs will be immediately released and become unavailable for
packet data traffic.
Packet Polling Request
This message is sent on the PCCCH or PACCH by the network to the mobile station to solicit
a PACKET CONTROL ACKNOWLEDGEMENT message from the mobile station.
Packet Power Control/Timing Advance
This message is sent on PACCH by the network to the mobile station in order to update the
mobile station timing advance or power control parameters.
Packet PRACH Parameters
This message is sent on the PCCCH by the network to all mobile stations within the cell to
update the PRACH parameters in between Packet System Information messages containing
PRACH parameters.
Packet Queueing Notification
This message is sent on the PCCCH by the network to the mobile station to notify the mobile
station that it is being placed in a queue. The message allocates a Temporary Queueing
Identity to the mobile station.
Packet Resource Request
This message is sent on the PACCH by the mobile station to the network to request a change
in the uplink resources assigned.
Packet PSI Status
This message is sent on the PACCH from the mobile station to the network to indicate which
PSI messages the mobile station has received.

This message is sent by the network on the PBCCH or PACCH giving information for Cell
selection, for control of the PRACH, for description of the control channel(s) and optional
global power control parameters.
This message is sent by the network on PBCCH and PACCH giving information about
reference frequency lists, cell allocation, GPRS mobile allocations and PCCCH descriptions
being used in the cell.
PSI2 also contains Non-GPRS cell options applicable for non-packet access.
This message is sent by the network on the PBCCH or PACCH giving information about the
BCCH allocation (BA_GPRS) in the neighbour cells and cell selection parameters for serving
cell and non-serving cells.
Packet System Information Type 3 bis
This message is sent by the network on the PBCCH and PACCH giving information about the
BCCH allocation in the neighbour cells and cell selection parameters for non-serving cells.
This message is optionally sent by the network on the PBCCH and PACCH giving information
directing the mobile station to make interference measurements.
This optional message is sent by the network on the PBCCH giving information for
measurement reporting and network controlled cell reselection.
This optional message is sent by the network on the PBCCH or PACCH to provide broadcast
information required by non-GSM networks.
This optional message is sent by the network on the PBCCH or PACCH to provide broadcast
information required by non-GSM networks.
This message is optionally sent by the network on the PBCCH and PACCH giving information
about Cell Broadcast Channel configuration.
Packet System Information 13
This message may be broadcast by the network on the PACCH or on the PCCCH. The
message provides the mobile station with GPRS cell specific access-related information.
Packet TBF Release
This message is sent on the PACCH by the network to the mobile station to initiate release of
an uplink or downlink TBF.
Packet Uplink Ack/Nack

This message is sent on the PACCH by the network to the mobile station indicating the status
of the received RLC data blocks. This message may also update the timing advance and
power control parameters. A fixed allocation mobile station may also be assigned uplink
resources.
Packet Uplink Assignment
assign uplink resources. The mobile station may be addressed by TFI (=Temporary Flow
Identifier), TQI (=Temporary Queing Identifier), or Packet Request Reference, depending
upon the procedure used. A mobile allocation or reference frequency list received as part of
this assignment message shall be valid until a new assignment is received or each TBF of the
MS are terminated.
Packet Timeslot Reconfigure
This message is sent on the PACCH by the network to the mobile station to assign uplink
and/or downlink resources. A mobile allocation or reference frequency list received as part of
this assignment message shall be valid until a new assignment is received or each TBF of the
MS are terminated.
Additional MS Radio Access Capabilities
This message is sent on the PACCH by the mobile station to the network to inform about
radio access capabilities of the mobile station.
10
Signalling messages for GPRS Mobility Management

Ready Timer procedure
The value of the READY timer may be negotiated between the MS and the network using the
GPRS attach or GPRS routing area updating procedure.
The READY timer, T3314 is used in the MS and in the network per each assigned P-TMSI to
control the cell updating procedure. When the READY timer is running or has been
deactivated, the MS shall perform cell update each time a new cell is selected.
When the READY timer has expired the MS shall:
- perform the routing area updating procedure when a routing area border is crossed;
- not perform a cell update when a new cell is selected.
All other GMM procedures are not affected by the READY timer.
Periodic routing area updating
Periodic routing area updating is used to periodically notify the availability of the MS to the
network. The procedure is controlled in the MS by the periodic RA update timer, T3312. The
value of timer T3312 is sent by the network to the MS in the messages ATTACH ACCEPT
and ROUTING AREA UPDATE ACCEPT. The value of the timer T3312 shall be unique within
an RA.
The timer T3312 is reset and started with its the initial value when the READY timer is
stopped or expires. The timer T3312 is stopped and shall be set to its initial value for the next
start when the READY timer is started. If after a READY timer negotiation the READY timer
value is set to zero, the timer T3312 is reset and started with its initial value .If the initial
READY timer value is zero, the timer T3312 is reset and started with its initial value when the
ROUTING AREA UPDATE REQUEST message is transmitted.
When timer T3312 expires, the periodic routing area updating procedure shall be started and
the timer shall be set to its initial value for the next start.
GPRS attach procedure
The GPRS attach procedure is used for two purposes:
- normal GPRS attach, performed by the MS to IMSI attach for GPRS services only. The
normal GPRS attach procedure shall be used by GPRS MSs in MS operation mode C,
independent of the network operation mode. It shall also be used by GPRS MSs in MS
operation modes A or B if the network operates in network operation mode II or III .
- combined GPRS attach procedure, used by GPRS MSs in MS operation modes A or B
to attach the IMSI for GPRS and non-GPRS services provided that the network operates
in network operation mode I.
With a successful GPRS attach procedure a GMM context is established.
11
GPRS detach procedure

The GPRS detach procedure is used:
to detach the IMSI for GPRS services only. Independent of the network operation
mode, this procedure is used by all kind of GPRS MSs;
as a combined GPRS detach procedure used by GPRS MSs operating in MS
operation mode A or B to detach the IMSI for GPRS and non-GPRS services, or for nonGPRS services only, if the network operates in network operation mode I; or
in the case of a network failure condition to indicate to the MS that a re-attach with
successive activation of previously active PDP contexts shall be performed.
After completion of a GPRS detach procedure or combined GPRS detach procedure for
GPRS and non-GPRS services, the GMM context is released.
The GPRS detach procedure shall be invoked by the MS if the MS is switched off, the SIM
card is removed from the MS or if the GPRS or non-GPRS capability of the MS is disabled.
The procedure may be invoked by the network to detach the IMSI for GPRS services. The
GPRS detach procedure causes the MS to be marked as inactive in the network for GPRS
services, non-GPRS services or both services.
If the GPRS detach procedure is performed, the PDP contexts are deactivated locally without
peer to peer signalling between the SM and LLC entities in the MS and the network.
MS initiated GPRS detach procedure initiation
The GPRS detach procedure is initiated by the MS by sending a DETACH REQUEST
message. The detach type information element may indicate GPRS detach with switching
off, GPRS detach without switching off, IMSI detach, GPRS/IMSI detach with switching
off or GPRS/IMSI detach without switching off. If the MS is not switched off, timer T3321
shall be started after the DETACH REQUEST message has been sent. If the detach type
information element value indicates IMSI Detach the MS shall enter GMMREGISTERED.IMSI-DETACH_INITIATED, otherwise the MS shall enter the state GMMDEREGISTERED-INITIATED. If the detach type information element value indicates IMSI
Detach or GPRS/IMSI Detach, state MM IMSI DETACH PENDING is entered.
Network initiated GPRS detach procedure initiation
The network initiates the GPRS detach procedure by sending a DETACH REQUEST
message to the MS. The DETACH REQUEST message shall include a detach type IE. In
addition, the network may include a cause IE to specify the reason for the detach request. The
network shall start timer T3322. If the detach type IE indicates re-attach not required or reattach required", the network shall deactivate the PDP contexts and deactivate the logical
link(s), if any, and shall change to state GMM-DEREGISTERED-INITIATED.
Routing area updating procedure
This procedure is used for:
- normal routing area updating to update the registration of the actual routing area of an
MS in the network. This procedure is used by GPRS MSs in MS operation mode C and
by GPRS MSs in MS operation modes A or B that are IMSI attached for GPRS and nonGPRS services if the network operates in network operation mode II or III;
- combined routing area updating to update the registration of the actual routing and
location area of an MS in the network. This procedure is used by GPRS MSs in MS
operation modes A or B that are IMSI attached for GPRS and non-GPRS services
provided that the network operates in network operation mode I; or
12
- periodic routing area updating. This procedure is used by GPRS MSs in MS operation
mode C and by GPRS MSs in MS operation modes A or B that are IMSI attached for
GPRS or for GPRS and non-GPRS services independent of the network operation
mode;
-
IMSI attachment for non-GPRS services when the MS is IMSI attached for GPRS
services. This procedure is used by GPRS MSs in MS operation modes A or B, if the
network operates in network operation mode I.
P-TMSI reallocation procedure

A temporary mobile station identity for GPRS services, the Packet-TMSI (P-TMSI), is used for
identification within the radio interface signalling procedures. The structure of the P-TMSI is
specified in GSM 03.03 [10]. The P-TMSI has significance only within a routing area. Outside
the routing area it has to be combined with the routing area identification (RAI) to provide for
an unambiguous identity.
The purpose of the P-TMSI reallocation procedure is to provide identity confidentiality, i.e. to
protect a user against being identified and located by an intruder.
Usually, P-TMSI reallocation is performed at at least each change of a routing area. (Such
choices are left to the network operator).
The reallocation of a P-TMSI is performed by the unique procedure defined in this section.
This procedure can only be initiated by the network in state GMM-REGISTERED.
Authentication and ciphering procedure
The purpose of the authentication and ciphering procedure is threefold:
to permit the network to check whether the identity provided by the MS is acceptable or
not.
to provide parameters enabling the MS to calculate a new GPRS ciphering key; and
to let the network set the ciphering mode (ciphering/no ciphering) and algorithm.
The authentication and ciphering procedure can be used for either:
authentication only;
setting of the ciphering mode and the ciphering algorithm only; or
authentication and the setting of the ciphering mode and the ciphering algorithm.
The authentication and ciphering procedure is always initiated and controlled by the network.
Identification procedure
The identification procedure is used by the network to request an MS to provide specific
identification parameters to the network e.g. International Mobile Subscriber Identity,
International Mobile Equipment Identity
13
Paging for GPRS services

Paging is used by the network to identify the cell the MS has currently selected, or to prompt
the mobile to re-attach, if necessary, as a result of network failure. If the MS is not GPRS
attached when it receives a paging for GPRS services, the MS shall ignore the paging.
Paging for GPRS services using P-TMSI:
The network shall initiate the paging procedure for GPRS services using P-TMSI when GMM
signalling messages or user data is pending to be sent to the MS while the Mobile Reachable
timer is running. The network may page only GPRS MSs which are GMM-REGISTERED and
identified by a local P-TMSI.
Paging for GPRS services using IMSI:
Paging for GPRS services using IMSI is an abnormal procedure used for error recovery in the
network.
The network may initiate paging using IMSI if the P-TMSI is not available due to a network
failure.
GPRS Session management

The main function of the session management (SM) is to support PDP context handling of the
user terminal. The SM comprises procedures for
identified PDP context activation, deactivation and modification; and
anonymous PDP context activation and deactivation.
SM procedures for identified access can only be performed if a GMM context has been
established between the MS and the network. If no GMM context has been established, the
MM sublayer has to initiate the establishment of a GMM context by use of the GMM
procedures as described in chapter 4. After GMM context establishment, SM uses services
offered by GMM. Ongoing SM procedures are suspended during GMM procedure execution.
For anonymous access, no GMM context is established.
Session management states

In this section, the SM states are described for one SM entity. Each SM entity is associated
with one PDP context. The following picture describes the SM states in the MS and on the
network side.
14
Session management states in the MS

In this section, the possible states of an SM entity in the mobile station are described. As
illustrated in the figure, there are four SM states in the MS.
PDP-INACTIVE
This state indicates that no PDP context exists.

PDP-ACTIVE-PENDING
This state exists when PDP context activation is requested by the MS.
PDP-INACTIVE-PENDING
This state exists when deactivation of the PDP contexts is requested by the MS.
PDP-ACTIVE
This state indicates that the PDP context is active.

DI (REQ PDP CONTX. ACTIV)
DI (DEACTIV. PDP CONTX. ACC)
PDP-INACTIVE
DR (ACTIV. PDP CONTX. REQ)

DR (DEACTIV. PDP
CONTX. ACC)
DR (ACTIV. PDP
CONTX. REQ)
DR (DEACTIV. PDP
CONTX. ACC)
DI (ACTIV. PDP CONTX. REJ)
DI (DEACTIV. PDP CONTX. REQ)
PDP-INACTIVEPENDING
PDP-ACTIVEPENDING
DI (ACTIV. PDP CONTX. ACC)
DR (DEACTIV. PDP CONTX. REQ)
PDP-ACTIVE
DI (MOD PDP CONTXT REQ)
DR (MOD PDP CONTXT ACC)
DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by an MS

DI: GMMSM-DATA-INDICATION (Message), i.e. message received by an MS
Figure: Session management states in the MS (overview)
15
Session management states on the network side

In this section, the possible states of an SM entity on the network side are described. As
illustrated in figure 6.2/GSM 04.08, there are five SM states on the network side.
PDP-INACTIVE
This state indicates that the PDP context is not active.

PDP-ACTIVE-PENDING
This state exists when the PDP context activation is initiated by the network.
PDP-INACTIVE-PENDING
This state exists when deactivation of the PDP context is requested by the network.
PDP-ACTIVE
This state indicates that the PDP context is active.

PDP-MODIFY-PENDING
This state exists when modification of the PDP context is requested by the network.
PDP-ACTIVEPEND
DI (ACTIV. PDP CONTX. REQ)
DI (REQ PDP CONTX. ACTIV. REJ)
DR (ACTIV. PDP
CONTX. ACC)
DR (REQ PDP CONTX. ACTIV)

DI (ACTIV. PDP CONTX. REQ)
DR (ACTIV. PDP
CONTX. ACC)
PDP ACTIVE
PDP-INACTIVE
DR (ACTIV. PDP CONTX. REJ)

DR (DEACTIV. PDP
CONTX. ACC)
DR (MODIFY. PDP CONTX. REQ)

DR (DEACTIV. PDP CONTX. REQ)
DI (DEACTIV. PDP CONTX. ACC)
DI (MODIFY. PDP CONTX. ACC)
PDP-INACTIVEPEND
PDP-MODIFYPEND
DR: GMMSM-DATA-REQUEST (Message), i.e. message sent by network

DI: GMMSM-DATA-INDICATION (Message), i.e. message received by the network
Figure Session management states on the network side (overview)
16
Session Management procedures

PDP context activation
The purpose of this procedure is to establish a PDP context between the MS and the network
for a specific QoS on a specific NSAPI. The PDP context activation may be initiated by the
MS or the initiation may be requested by the network.
Successful PDP context activation initiated by the mobile station
In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT
REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts the
timer T3380. The message contains the selected NSAPI, PDP type and, if the MS requests a
static address, the PDP address. The MS shall ensure that the selected NSAPI is not
currently being used by another Session Management entity in the MS.
Upon receipt of an ACTIVATE PDP CONTEXT REQUEST message, the network selects a
radio priority level based on the QoS negotiated and may reply with an ACTIVATE PDP
CONTEXT ACCEPT message. Upon receipt of the message ACTIVATE PDP CONTEXT
ACCEPT the MS shall stop timer T3380 and enter the state PDP-ACTIVE. The MS shall
initiate establishment of the logical link for the LLC SAPI indicated by the network with the
offered QoS and selected radio priority level if no logical link has been already established for
that SAPI. If the offered QoS parameters received from the network differ from the QoS
requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP
context deactivation procedure. If the LLC SAPI indicated by the network can not be
supported by the MS, the MS shall initiate the PDP context deactivation procedure.
Successful PDP context activation requested by the network
In order to request a PDP context activation, the network sends a REQUEST PDP CONTEXT
ACTIVATION message to the MS and starts timer T3385. If available, the APN shall be
included in the REQUEST PDP CONTEXT ACTIVATION message.
Upon receipt of a REQUEST PDP CONTEXT ACTIVATION message, the MS shall than
either initiate the PDP context activation procedure as described in the previous section or
shall reject the activation request by sending a REQUEST PDP CONTEXT ACTIVATION
REJECT message. The value of the reject cause IE of the REQUEST PDP CONTEXT
ACTIVATION REJECT message shall indicate the reason for rejection, e.g. insufficient
resources to activate another context.
The ACTIVATE PDP CONTEXT REQUEST message sent by the MS in order to initiate the
PDP context activation procedure shall contain the PDP address, PDP Type and APN
requested by the network in the REQUEST PDP CONTEXT ACTIVATION message.
Upon receipt of the ACTIVATE PDP CONTEXT REQUEST message, the network shall stop
timer T3385.
The same procedures then apply as described for MS initiated PDP context activation.
MS
17
Network
ACTIVATE PDP CONTEXT REQUEST
Start T3380
ACTIVATE PDP CONTEXT ACCEPT
Stop T3380
or
ACTIVATE PDP CONTEXT REJECT
Stop T3380
Figure: MS initiated PDP context activation procedure
MS
Network
REQUEST PDP CONTEXT

Start T3385
ACTIVATE PDP CONTEXT REQUEST
Start T3380
Stop T3385
ACTIVATE PDP CONTEXT ACCEPT
Stop T3380
or
ACTIVATE PDP CONTEXT REJECT
Stop T3380
or
REQUEST PDP CONTEXT ACTIVATION REJECT
Stop T3385
Figure: Network initiated PDP context activation procedure

PDP context modification procedure
The PDP context modification procedure is invoked by the network in order to change the
QoS negotiated during the PDP context activation procedure or at previously performed PDP
context modification procedures. The procedure can be initiated by the network at any time
when a PDP context is active.
In order to initiate the procedure, the network sends the MODIFY PDP CONTEXT REQUEST
message to the MS and starts the timer T3386. The message shall contain the new QoS and
the radio priority level that shall be used by the MS at the lower layers for the transmission of
data related to the PDP context.
Upon receipt of this message the MS shall reply with the MODIFY PDP CONTEXT ACCEPT
message if the MS accepts the new QoS and the indicated LLC SAPI.
If the MS does not accept the new QoS or the indicated LLC SAPI, the MS shall initiate the
PDP context deactivation procedure for the PDP context - the reject cause IE value of the
DEACTIVATE PDP CONTEXT REQUEST message shall indicate QoS not accepted.
18
PDP context deactivation procedure

The purpose of this procedure is to deactivate an existing PDP context between the MS and
the network. The PDP context deactivation may be initiated by the MS or by the network.
PDP context deactivation initiated by the MS
In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT
REQUEST message to the network, enters the state PDP-INACTIVE-PENDING and starts
timer T3390. The message contains the transaction identifier in use for the PDP context to be
deactivated and a cause code that typically indicates one of the following causes:
# 25: LLC or SNDCP failure;
# 26: insufficient resources;
# 36: regular PDP context deactivation; or
# 37: QoS not accepted.
The network shall reply with the DEACTIVATE PDP CONTEXT ACCEPT message. Upon
receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the MS shall stop timer
T3390. Both the MS and the network shall initiate local release of the logical link if it is not
used by another PDP context.
PDP context deactivation initiated by the network
In order to deactivate a PDP context, the network sends a DEACTIVATE PDP CONTEXT
REQUEST message to the MS and starts timer T3395. The message contains the
transaction identifier in use for the PDP context to be deactivated and a cause code that
typically indicates one of the following causes:
# 25: LLC or SNDCP failure;
# 36: regular PDP context deactivation;
# 38: network failure; or
# 39: reactivation requested.
The MS shall, upon receipt of this message, reply with a DEACTIVATE PDP CONTEXT
ACCEPT message. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message,
the network shall stop the timer T3395. Both the MS and the network shall initiate local
release of the logical link if it is not used by another PDP context.
MS
19
Network
DEACTIVATE PDP CONTEXT REQUEST
Start T3390
DEACTIVATE PDP CONTEXT ACCEPT
Stop T3390
Figure: MS initiated PDP context deactivation procedure
MS
Network
DEACTIVATE PDP CONTEXT REQUEST
Start T3395
DEACTIVATE PDP CONTEXT ACCEPT
Stop T3395
Figure: Network initiated PDP context deactivation procedure

Messages for GMM and SM
P-TMSI reallocation command
This message is sent by the network to the MS to reallocate a P-TMSI.
P-TMSI reallocation complete
This message is sent by the MS to the network to indicate that reallocation of a P-TMSI has
taken place.
Authentication and ciphering request
This message is sent by the network to the MS to initiate authentication of the MS identity. In
addition, the ciphering mode is set, indicating whether ciphering will be performed or not.
Authentication and ciphering response
This message is sent by the MS to the network in response to an Authentication and
ciphering request message.
Authentication and ciphering reject
This message is sent by the network to the MS to indicate that authentication has failed (and
that the receiving MS shall abort all activities).
Identity request
This message is sent by the network to the MS to request submission of the MS identity
according to the specified identity type. E.g. responses are IMSI, TMSI, P-TMSI or IMEI.
20
Identity response
This message is sent by the MS to the network in response to an identity request message
providing the requested identity.
Routing area update request
This message is sent by the MS to the network either to request an update of its location file
or to request an IMSI attach for non-GPRS services.
Routing area update accept
This message is sent by the network to the MS to provide the MS with GPRS mobility
management related data in response to a routing area update request message.
Routing area update complete
This message shall be sent by the MS to the network in response to a routing area update
accept message if a P-TMSI and/or a TMSI has been assigned and/or if there are
established LLC connections.
Routing area update reject
This message is sent by the network to the MS in order to reject the routing area update
procedure.
GMM Status
This message is sent by the MS or by the network at any time to report certain error
conditions listed in the information element GMM cause. The purpose of the GMM cause
information element is to indicate the reason why a GMM request from the mobile station is
rejected by the network. Some possible field values are:
IMSI unknown in HLR
Illegal MS
Illegal ME
GPRS services not allowed
GPRS services and non-GPRS services not allowed
MS identity cannot be derived by the network
Implicitly detached
PLMN not allowed
Location Area not allowed
Roaming not allowed in this location area
MSC temporarily not reachable
Network failure
Congestion
Etc.
GMM Information
This message is sent by the network at any time to send certain information to the MS. This
information could be: Full name for network, Short name for network, Network time zone,
Universal time and time zone, LSA Identity, ...
21
Activate PDP context request

This message is sent by the MS to the network to request activation of a PDP context.
Activate PDP context accept
This message is sent by the network to the MS to acknowledge activation of a PDP context.
Activate PDP context reject
This message is sent by the network to the MS to reject activation of a PDP context.
Request PDP context activation
This message is sent by the network to the MS to initiate activation of a PDP context.
Request PDP context activation reject
This message is sent by the MS to the network to reject initiation of a PDP context activation.
Modify PDP context request
This message is sent by the network to the MS to request modification of an active PDP
context.
Modify PDP context accept
This message is sent by the MS to the network to acknowledge the modification of an active
PDP context.
Deactivate PDP context request
This message is sent to request deactivation of an active PDP context.
Deactivate PDP context accept
This message is sent to acknowledge deactivation of the PDP context requested in the
corresponding Deactivate PDP context request message.
Activate AA PDP context request
This message is sent by the MS to the network to initiate activation of an AA PDP context. AA
= Anonymous Access PDP context request.
Activate AA PDP context accept
This message is sent by the network to the MS to acknowledge the activation of an AA PDP
context.
Activate AA PDP context reject
This message is sent by the network to the MS to reject the activation of an AA PDP context.
Deactivate AA PDP context request
This message is sent to request deactivation of an active AA PDP context.
Deactivate AA PDP context accept
This message is sent to acknowledge deactivation of an AA PDP context requested by the
corresponding Deactivate AA PDP context request message.
22
SM Status
This message is sent by the network or the MS to pass information on the status of the
indicated context and report certain error conditions.
How can you identify the current GPRS MM or SM message? This is given by the information
element type in the Layer 3 message:
Message types for GPRS mobility management
Bits
8 7 6 5 4 3 2 1
0 0 - - - - - -
Mobility management messages
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
1
1
0
0
1
1
0
1
0
1
0
Attach
Attach
Attach
Attach
Detach
Detach
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
1
1
0
1
0
1
Routing
Routing
Routing
Routing
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
0
0
0
0
1
1
0
0
1
0
0
0
1
0
1
0
1
0
0
1
P-TMSI reallocation command

P-TMSI reallocation complete
Authentication and ciphering req
Authentication and ciphering resp
Authentication and ciphering rej
Identity request
Identity response
GMM status
GMM information
request
accept
complete
reject
request
accept
area
area
area
area
update
update
update
update
request
accept
complete
reject
Message types for GPRS session management

Bits
8 7 6 5 4 3 2 1
0 1 - - - - - -
Session management messages
0 1 0 0 0 0 0 1
0 1 0 0 0 0 1 0
0 1 0 0 0 0 1 1
Activate PDP context request

Activate PDP context accept
Activate PDP context reject
0 1 0 0 0 1 0 0
0 1 0 0 0 1 0 1
Request PDP context activation

Request PDP context activation rej.
0 1 0 0 0 1 1 0
0 1 0 0 0 1 1 1
Deactivate PDP context request

Deactivate PDP context accept
0 1 0 0 1 0 0 0
0 1 0 0 1 0 0 1
Modify PDP context request

Modify PDP context accept
0 1 0 1 0 0 0 0
0 1 0 1 0 0 0 1
0 1 0 1 0 0 1 0
Activate AA PDP context request

Activate AA PDP context accept
Activate AA PDP context reject
0 1 0 1 0 0 1 1
0 1 0 1 0 1 0 0
Deactivate AA PDP context request

Deactivate AA PDP context accept
0 1 0 1 0 1 0 1
SM Status
23
GPRS Radio Interface: Encapsulation:

The user data will be encapsulated into the different protocol planes before transmitting over
the GPRS air interface. The following figure indicates this encapsulation procedure in the
example of a Mobile Station.
Protocol layer inside MS:
Application
Data
IP
TCP/IP
SNDCP
SNDCP
Max length = 1600 octets
LLC
LLC
Information field
FCS
184 - 440 bit, depending on CS-1 - CS-4 16 or 40 bit, depending on CS
RLC/MAC
RLC/
MAC
Data field
BCS
= new data
Convolutional encoding
RF
456 bit
= previous
layer
Figure: Encapsulation of user data in different protocol layer

Please remark that there is no fixed relation between the protocol headers and the user data.
More or less all protocol headers will have a dynamic length, depending on the context. This
length will also vary through a communication link, result will be always an variating data rate
of the output data.
The Frame Check Sequence, FCS in the LLC frame structure is necessary, because in
GPRS it is possible, that the air interface, lets say the RLC / MAC layer is not using any kind
of forward error correction. This will be in case of Coding Scheme CS-4. For this reason, the
LLC layer must have an error detection mechanism. Together with the error detection
mechanism in the RLC/MAC layer, the Block Check Sequence, BCS this will be a double
error detection mechanism. But the length of the BCS is changing between 16 or 40 bit, i.e.
the protection or detection quality is very good concerning the block header, the RLC and
MAC header but it does not have the best quality of protection over all the data field.
24
GPRS: Identifiers on the data transport over the air interface

In GPRS there are some questions to be answered before handing out the received data to
the right application. For this reason, there are some different identifiers that have to be used
in certain protocol layers. The following picture demonstrates these most important
Identifiers, to be used for reaching the final destination if we transmit a Packet Data Unit,
PDU. The 3 identifiers, TFI, SAP and NSAPI are cascaded in the following way:
PDP
PDP
PDP
NSAPI
TOM
SMS
SM/GMM
SNDCP
SAPI
LLC
RLC/
MAC
Identifies
MS
RF
Identifies
Layer 3
Protocol
Identifies
PDP context
PI
I NSA
TLLI or SAP
TFI
Figure: Cascading of the identifiers in GPRS

The first question to be answered, if a BTS transmits a PDU, is who is the owner of this data
packet, i.e. which Mobile Station should receive this downlink data. For this reason there is an
identifier, TLLI, Temporary Logical Link Identifier, that is derived or calculated out of the
PTMSI, the subscriber identity number. Because of the length of this TLLI we also use a short
form, the so called Temporary Flow Identifier, TFI. The TFI is only 5 bits in length, so there are
maybe some mismatches after assignment, thats the reason, why in the first downlink data
blocks, there will always be the inclusion of the TLLI, that is much longer and therefore the
probability of misunderstanding is much lower.
This identifier is directly concerned to the air interface, it will be a question of the receiver, if
he shall hand out this data unit to higher layers of if he shall discard it, because it was sent to
somebody else. For this reason, the TLLI or TFI is included in the RLC/MAC header.
If the right Mobile Station, MS has received the data unit, there are now some more
possibilities. The next question to be answered is, which higher layer protocol should receive
the data unit, for example, is this received data unit a signalling message of the GPRS
mobility management or is it some user data, packed into an SNDCP header? To answer this
question, we use the Service Access Point Identifier, SAPI included in the transport layer
frame, the LLC frame. This identifier indicate the higher layer (in OSI Modell = Layer 3)
protocol that will be the owner of the received packet data unit. In GPRS we can find here the
25
distinction between, GPRS Mobility Management, GPRS Session Management, SMS

Transfer, User Data Unit via SNDCP or GSM foreign signalling messages, tunnelled with the
Tunneling of Messeges protocol, TOM.
In our next step, we assume that this received packet data unit is to be forwarded to the user
application, i.e. by the received data it is about a SNDCP data unit. But as we have seen, in
GPRS it is possible, that we can find more than one activated application, or the so called
PDP context that is activated. Now it is the task of this receiving layer to forward the incoming
data to the right application. Every PDP context is identified with this parameter, Network
Service Access Point Identifier, NSAPI.
Each NSAPI points to the corresponding application.
26
GPRS: Assignment of Radio Resource

In GPRS there are in principle two different ways how to assign radio ressource. First we
have to assure, that in GPRS uplink and downlink are completely different from each other
and will be assigned in 2 steps. Packet Uplink Assignment and Packet Downlink Assignment.
Packet Downlink Assignment:
This assignment consists of the main parameters:
TFI: Temporary Flow Identifier. Included in every RLC/MAC Block, identifies the owner of this
radio block.
Timeslot Allocation: Bitmap of 8 Bits, that indicates, which timeslot has been assigned for
downlink data transfer.
TBF Starting time: To indicate, when the data transfer will begin. Starting time refering to the
GSM clock timing, or multiframe number.
Frequency parameters: Which frequency channel shall be used .
Consequence will be for the Mobile Station, to receive every downlink radio block on the
assigned timeslots and decide after receiving by checking the TFI field in the RLC header if
the radio must to be forwarded to higher layer protocols or will be discarded.
Packet Uplink Assignment:

This uplink assignment contains as important Information Elements, IE the following
parameters:
TFI and TLLI: Assignment of the identifier of the TBF, to be included in every radio block.
Channel Coding Command: Which Coding Scheme should be used.
Packet Timing Advance: Field that contains the Timing Advance value to be used, the Timing
Advance Index for the update procedure on PTCCH and the timeslot, where the PTCCH is
active.
Frequency parameters: Which frequency channel shall be used .
If dynamic allocation:
USF value as 3 bit field, for every assigned timeslot
Power control parameter: the necessary parameters to calculate the transmitting
power of the MS. E. g. alpha, gamma and p0 parameter. See formula on other chapter
for details.
TBF Starting time: when will the TBF start.
27
Monitoring USF in Block B(n)

Sends in Block B(n+1)
or in Blocks B(n+1) - B(n+4)
USF = R1
n)
k B(
c
o
l
oB
Radi downlink
USF = R2
USF
k
uplin
USF = R3
1)
B(n+
k
c
o
o Bl
Radi
Fixed Allocation = Fixed number of octets to be
transmitted in N bundled Timeslots
USF = Free
USF = Free
Monitoring Paging Channel
Send Access Burst
Dynamic Allocation = USF points to next Radio Block

on uplink RF-Channel for use by MS
Extended Dynamic Allocation = USF points to next
4 Radio Blocks on uplink RF-Channel for use by MS
Figure: usage of the USF field in the uplink TBF establishment
If fixed allocation:
Downlink control timeslot: This indicates, which downlink timeslot should be monitored
for PACCH blocks.
Timeslot allocation: to indicate which timeslots should be used by the MS on the uplink
Bitmap allocation: Refering to the 52 Multiframe: which radio blocks will be assigned to
the MS for uplink data transfer.
Packet Timing Advance: Field that contains the Timing Advance value to be used, the
Timing Advance Index for the update procedure on PTCCH and the timeslot, where the
PTCCH is active.
Power control parameter: the necessary parameters to calculate the transmitting
power of the MS. E. g. alpha, gamma and p0 parameter. See formula on other chapter
for details.
28
Bitmap example
Timeslot Allocation
00001011
012345 67
PDCH
Allocation Bitmap
010
111
000
110
111
000
111
000
101
001
100
111
example
52 TDMA Frames
TN4
B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9
B10 B11X
TN6
B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9
B10 B11X
TN7
B0 B1 B2 T B3 B4 B5 X B6 B7 B8 T B9
B10 B11X
B0 - B11 = Radio Blocks
T = Frame used for PTCCH
= not assigned Radio Block
X = Idle frame
= assigned Radio Block
Figure: Example: Assignment of radio ressource in fixed allocation mode

GPRS Signalling Messages On GRR, GMM and SM: Network MS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GPRS Signalling Messages On GRR, GMM and SM: Network MS

Uploaded by

Copyright:

Available Formats

GPRS Signalling Messages and Procedures on the Air interface