Ii GPRS

Introduction to GPRS
1
Chapter 1
GPRS Outline
2
GPRS
Objectives
On completion of this chapter the student will be able to:
Explain the difference between Circuit and Packet switching.
State how Virtual Circuits are created.
Explain the impact of Industry convergence toward Internet Protocol (IP).
Explain the GPRS Network Architecture, its functions plus the mobile station classes.
Describe the Packet Data Channels and their organization and meaning for GPRS.
Explain the different coding schemes.
3
GPRS
Industry Convergence
Voice and data are converging and starting to be carried on the same networks, but opinions vary
on how quickly this is happening and what impact it will have on the IT and telcos. Businesses are
wondering what benefits it will bring and how soon they should add voice to their data networks.
Today the volume of data in telecomms networks has surpassed voice, Within 4 years the big US
telcos are predicting that 99% of telecomms traffic will be data. Already there have been many
merges, acquisitions and alliances spanning telecomms and IT as leading companies jostle for
position, once such example is the partnership between Motorola & Cisco.
Many of the recent merges and acquisitions have been brought about by telecomms equipment
companies buying up the IT companies that make Internet Protocol (IP) telephony products. These
products allow data to be carried cheaply over networks based on the IP protocol used on the internet.
They can also be used to carry Voice over IP (VOIP) by converting it into small packets of data. In this
way more voice calls can be sent down a single line. Examples of such acquisitions include Alcatel
buying Xylan, Nortels purchase of Bay Networks, Lucent acquiring Ascend and Nokia buying Ipsilon.
Some of the mission elements include:
Voice gateways
End to end control
QoS support (except when sent over another standard e.g. ATM)
Network management facilities
One of the main benefits to the customer is that of reduced network infrastructure costs because
there will be no need for separate data and telecomms networks.
4
GPRS
Industry Convergence
Computer Media
internet access
electronic mail
streaming audio
video on demand
real time images
multimedia Mobility
interactive video services
TV/Radio / Data contribution
mobile computing High speed
services
& distribution
IP
Mobility
Mobility Personal
Wideband services
services
Telecommunication
ISDN services
video telephony
wideband data services
5
GPRS
Circuit and Packet Switching

The advantages of transferring data using packet switching as opposed to circuit
switching have long been recognised.
Circuit switching provides a fixed bandwidth channel over a unique path from user to user for
the duration of the call. It is therefore inefficient when dealing with bursty or Variable Bit Rate
(VBR) traffic (e.g. data) as the maximum required bit rate must be maintained throughout the
duration of the call therefore leaving resources under-utilised for much of the time.
Packet switching can be used for data traffic that is generated in bursts and is therefore
ideal for Variable Bit Rate data transport. The paths taken by successive packets may not
be the same. Overhead information is added to the data to enable the network to route it
correctly and the recipient has to assemble the packets in the correct sequence. Delays are
also incurred when packets queue at switches. For constant bit rate voice and video it can
cause a relatively high delay as well as uncertain queuing delays.
GSM has, until GPRS, used circuit switched connections. A bi-directional traffic
channel is established and therefore chargeable, to the user for the duration of the call
whether traffic is actually being transferred or not.
Consider as an example the inefficiency of using the Internet and downloading large quantities of
data. The uplink, though barely being used, is nevertheless an available resource, which is being
charged. Packet switching divides the data into individual, limited size containers (packets) and sends
them through the network along communication lines being shared by other channels.
6
GPRS
Circuit and Packet Switching
Circuit Switching Packet Switching
A complete resource allocated Devices share the available

to an individual device resources
Its All Mine!
Which exit did you say?
7
GPRS
Circuit Switching
The diagram shows separate paths (circuits) A-B and A-C that are created through a Circuit
Switched Data Network (CSDN). In this example, the paths are 64kb/s channels (timeslots)
provided within an E1 TDM frame that operates at 2.048 Mb/s; the timeslots are switched
at the switching nodes in order to create the required paths.
The circuits are permanently provisioned and operate at fixed data rates (64kb/s);
Nx64kb/s circuits could also be provisioned for higher bandwidth applications. Note
that a duplex path (i.e. A/B and B/A) is provided.
Circuit switching takes place at the OSI physical layer, and there is no provision for
error control or flow control. However, circuit switched paths are protocol transparent
- they provide basic pipes for transmission.
Circuit switched paths are generally suitable for applications that require a fixed, short delay
e.g. voice and video. The bandwidth available is permanently dedicated to the circuit and
the paths are non-blocking. However, this is wasteful for many data applications which are
bursty by nature, or which involve a short request / long response.
8
GPRS
Circuit Switching
A S S C
CSDN
Physical L1 Physical Physical Physical Physical
9
GPRS
Packet Switching
In a Packet Switched Data Network (PSDN), data to be transmitted is first segmented by the source
DTE into message units called packets. Each packet includes the network addresses of the source
and destination DTEs. On receipt of each packet, the Packet Switch Exchange (PSE) stores it while
inspecting the destination address; each PSE has a routing table specifying the outgoing link(s) to be
used for each destination network address. The PSE then forwards the packet on the appropriate
link at the rate of that link. This method of working is known as store-and-forward.
A number of packets may arrive simultaneously at a PSE on different incoming links for
forwarding on the same outgoing link. Packets may therefore experience unpredictably long
delays. (To prevent this, a maximum length is specified for each packet).
The PSDN has a meshed topology that offers multiple alternate routes for packets. In
the diagram, there are two alternate routes between any pair of PSEs. The PSDN
therefore provides a resilient networking service.
As packet networks use store-and-forward, the two communicating DTEs can have different access
speeds to the network. The transmission links between PSEs are better utilised because users only
occupy bandwidth when data is being sent and a number of such users can therefore "share" the
available transmission bandwidth. This technique is known as statistical multiplexing - a statistical
gain is achieved because it is unlikely that all users will be transmitting at the same time.
On packet switched networks, error control and flow control are performed on each link. Error
control ensures that packets are delivered error-free and in sequence, and flow control provides
a method of reducing congestion during busy periods. Overheads for these functions are carried
by each packet and employed by each PSE at OSI Layers 2 and 3.
Packet switching can achieve equipment economies because many DTEs can be
connected to a single PSDN access equipment.
Packets switching matches the characteristics of many data applications (occasional, bursty transfer of
data). Its statistical nature means that it is efficient. It does not offer a constant, low-delay performance
and is not therefore suitable for delay sensitive applications e.g. voice and video.
10
GPRS
Packet Switching
a c
B Data Packet where:
c = destination address
PSE a = source address
PSDN
a c
a b a c
PSE PSE
A b c C
a d
PSE
Higher D Higher
Layers Layers
L3 L3 L3 L3 L3
L2 L2 L2 L2 L2
Physical Physical Physical Physical Physical
11
GPRS
Datagrams and Virtual Circuits

The two types of service normally supported by a PSDN are known as datagram
and virtual circuit services.
Datagrams
The datagram service is normally used for the transmission of short, single-packet messages.
Each packet that enters the network is treated as a self-contained entity with no relationship
to other packets. The packets can be therefore be forwarded over different routes to the
same destination. Datagrams provide a connection-less service.
Virtual Circuit
The virtual circuit service is used when a message contains multiple packets. It
is a connection-oriented service.
Before any data packets are sent, the source DTE sends a call request packet to PSE1 (see
diagram) containing the network address of the destination DTE and a reference number called
the Virtual Circuit Identifier (VCI). PSE 1 notes the VCI and forwards the packet through
the network according to the information contained in its routing table. It assigns a new VCI
to the route PSE1 - PSE2, and updates its routing table as shown.
At PSE2, another VCI is assigned to the call request packet before it is forwarded on the outgoing
link to the destination DTE. Assuming that the call is accepted, an appropriate response packet
is returned to the calling DTE. At this point, a virtual circuit (VC) exists between the two DTEs.
During the subsequent data transfer phase, all data packets relating to the call DTE1 - DTE2
are assigned the same VCIs along the virtual circuit. In this way, the source and destination
DTEs can readily distinguish between packets arriving on the same link that relate to different
calls - multiple calls are thereby multiplexed on to the same link.
All packets take the same route across the network and should therefore arrive in sequence. The
network addresses are only required in the initial call request and call accept packets.
Permanent Virtual Circuit (PVC)

When the data transfer phase is complete, a clear-down packet is sent and the VCIs are released. If
DTE1 frequently requires to communicate with DTE2, the VC may be left permanently established - this
is known as a PVC. This can be more economical since the cost of the call will usually be based on the
quantity of data transferred, not the duration, although the user must pay for the PVC facility.
12
GPRS
Datagrams and Virtual Circuits
PSE1 PSE2
1 2 1 2
DTE1 DTE2
VCI(1) VCI(2) VCI(3)
Virtual Circuit
Routing Table - PSE1

IN OUT
VCI(1) / Link(1) VCI(2) / Link(2)
Routing Table - PSE2
IN OUT
13
GPRS
The Interconnection of the Various Network Elements

Interfaces within the NSS
All interfaces within the NSS (B, C, D, E, F, G) are based on the Signaling System No 7 (SS7)
protocol stack [ITU-T / Q.700 - Q.703]. For the communication among the various network elements,
intra-PLMN and inter-PLMN, the worldwide SS7-network is used by GSM. SS7 is well suited for
signaling purposes of circuit-switched traffic but is not designed to support packet-switched traffic.
Interfaces within the BSS and towards the NSS

The open A-Interface interconnects the BSS to the NSS. Like the NSS-specific interfaces, the
A-Interface is based on the SS7-protocol stack. Therefore, the A-Interface is an open interface
because the equipment of different system vendors needs to be interconnected at that point.
Opposed to this, the Abis-Interface between the BSC and BTSs is a system vendor specific interface
where the control plane is usually based on LAPD ( ISDN). The user plane on the other hand is based
on GSM-specific 16 kbit/s traffic channels which transfer TRAU-frames between the BTSs and the TRAU.
Note that the TRAU is missing in the figure because it is transparent for the control plane.
14
GPRS
The Interconnection of the Various Network Elements
G-Interface
HLR
D-Interface
D-Interface
VLR C-Interface VLR

Abis-Interface
A-Interface
B-Interface B-Interface
E-Interface
BTS
BSC MSC G-MSC
Air interface
F-Interface
EIR
15
GPRS
Introducing the GPRS Network Architecture

PCU (Packet Control Unit)
The first new network element is the PCU which may be located at the SGSN-site, the
BSC-site or at the BTS but usually becomes part of the BSC.
SGSN (Serving GPRS Support Node)

Another new network element is the SGSN which is basically a packet switch that
has been modified and extended for GPRS.
GGSN (Gateway GPRS Support Node)

The GGSN interfaces the PLMN towards external packet data networks (PDN) via the Gi-Interface.
BG (Border Gateway)
The BG is required for inter-PLMN packet data traffic.
CG (Charging Gateway)
The CG collects charging data records for packet switched traffic.
GPRS Interfaces
All interfaces between GPRS specific network elements are packet-switched. However,
the interfaces between the SGSN or GGSN on one hand and the HLR, VLR, EIR
or MSC on the other hand are based on SS7.
Note that the Gs-interface and the Gc-interface are optional.
16
GPRS
Introducing the GPRS Network Architecture
VLR HLR
Abis-Interface
Gr-Interface
Gs-Interface
Gc-Interface
Gi-Interface
Gb-Interface Gn-Interface
BSC Packet Data Network
BTS PCU SGSN GGSN
Air interface
(IP/PPP)
Ga-Interface
Gd-Interface
Gn-Interface Gp-Interface
CG
Ga-Interface
SGSN BG BG Foreign
SMS-G-MSC Gp-Interface PLMN
SMS-IW-MSC
17
GPRS
(1) Tasks and Functions of the PCU

Conversion of Packet Data into PCU-Frames
In the layer 1, the PCU converts all downstream packet traffic into PCU-frames whereas these
PCU-frames have the same format as the TRAU-frames. Consequently, the BSC can route both traffic
types, circuit-switched and packet-switched. Vice versa, in upstream direction the PCU-frames are
converted back into packet traffic by the PCU and sent to the SGSN via a frame relay network.
Note that the BSC remains almost transparent for packet-switched traffic.
18
GPRS
ta
da
d
he
itc
w
it-s
i cu
C
e
am
TR
AU-Fr
TRAU
BSC
TR G
AU DS
-F
ra
BTS me
PCU
Pa
cke
t- sw
it ch
ed
da
ta
19
GPRS

Responsibility for RLC/MAC on the Network Side
As mentioned on the previous slide, the BSC remains almost transparent for packet-switched traffic.
Therefore the PCU is responsible for all radio control functions in GPRS. In GPRS these radio
control functions refer to Radio Link Control / Medium Access Control (RLC/MAC).
20
GPRS
Responsibility for RLC/MAC

on the Network Side
RLC RLC
MAC MAC
PCU
21
GPRS
(1) Tasks and Functions of the SGSN

Routing of Data Packets between the GGSN and the various BSSs ( Packet Switching)
This function requires a powerful packet switch that can temporarily buffer many megabytes
of packet data. In case of a cell change of a mobile station during a packet data transfer in
downlink direction, the former SGSN needs also to be able to re-route all yet unacknowledged
packet data to the new SGSN (only in case of acknowledged operation).
22
GPRS
Routing of Data Packets between the GGSN

and the various BSSs (Packet Switching)
PCU GGSN
SGSN
PCU GGSN
PCU GGSN
23
GPRS

GPRS-Mobility Management
Opposed to circuit-switched GSM where the MSC takes care of the switching functions and the
(integrated) VLR takes care of Mobility Management (MM), in GPRS the SGSN is responsible for both,
switching and GMM. Accordingly, the SGSN requires an interface to the HLR(s) ( Gr-Interface).
Optionally and to provide for a better interoperability between circuit-switched and packet-switched
traffic, there may also be an interface between the SGSN and the VLR(s).
24
GPRS
GPRS-Mobility Management
VLR
HLR
SGSN HLR
HLR
VLR
25
GPRS

GPRS-Session Management
For GPRS session management the SGSN takes care of relaying the session management information
between the mobile station and the respective GGSN. Most importantly, all active PDP-contexts
(Packet Data Protocol) of a mobile station are taken care of by the same SGSN.
26
GPRS
GPRS-Session Management
SGSN GGSN Packet Data Network
PDP-Context Activation
Modification
Deactivation
27
GPRS

Ciphering
While in GSM ciphering is a task of the BTS ( layer 1) in GPRS ciphering becomes
a task of the SGSN ( layer 2). Ciphering will be elaborated in more detail when LLC
(Logical Link Control) is dealt with at a later time.
28
GPRS
Ciphering
BSS SGSN GGSN
29
GPRS

Charging (own network resources)
As the figure indicates, the SGSN gathers charging information related to the use of the own
network resources and forwards this information to the charging gateway.
30
GPRS

$
PLMN
Packet
GGSN
$ SGSN Data Network

Charging
Gateway
31
GPRS

Data Compression ( V.42bis)
The SGSN (optionally) provides means for data compression by means of V.42bis. V.42bis is an
ITU-T protocol that primarily is used in modems (33.6 kbit/s). We will elaborate V.42bis/V.44 in more
detail when the SNDCP (SubNetwork Dependent Convergence Protocol) is considered.
V.44
V.44 is an alternative data compression algorithm in addition to V.42bis. V.44 has originally been
developed by the company Hughes Network Systems (HNS) in the US and was proposed as
more powerful alternative to V.42bis in the year 1999 to international standards bodies ( ITU-T).
The ITU-T adopted this new compression algorithm as V .44 which offers 12% - 230% better
compression performance and therefore higher throughput rate than V.42bis.
32
GPRS
or
V.44
33
GPRS

Header Compression ( RFC 1144 and RFC 2507)
Opposed to V.42bis which is suited for the compression of all non-random information, the RFC
1144 (Request For Comment) and RFC 2507 protocol exclusively addresses the compression
of TCP/IP and/or UDP/IP headers. Whereas RFC 1144 only supports the compression of
TCP/IP headers, RFC 2507 can be used for compression of TCP/IP and UDP/IP headers.
RFC 1144 and RFC 2507 rely on the redundancy of most information elements in the header
once the virtual TCP/UDP-connection is established. These redundant information elements
will be suppressed during transmission between the two peers.
For example: TCP/IP headers are in average 40 byte long. By means of RFC 1144, TCP/IP
headers can be compressed to 2 to 3 bytes in average.
As for V.42bis, the support for RFC 1144 and RFC 2507 is optional in GPRS.
RFC 1144 and RFC 2507 are internet protocols that can be downloaded from www.ietf.org.
34
GPRS
Header Compression ( RFC 1144 and RFC 2507)
Header Compression (RFC 1144 and RFC 2507)

Header Compression
Data TCP/IP Data Data TCP/IP

SGSN GGSN
RFC 1144 or
RFC 2507
35
GPRS
(1) Tasks and Functions of the GGSN

Interface between the PLMN and external Packet Data Networks
The most important function of the GGSN is the interconnection of the PLMN towards
external packet data networks. In GPRS Rel. 99, those external packet data networks
may be either IP-based networks or networks supporting the PPP (Point-to-Point Protocol).
Please mind that X.25 is not supported by Rel.99.
36
GPRS
PLMN
Interface between the PLMN

and external Packet Data Networks
GGSN
Packet Packet Packet

Data Network Data Network Data Network
37
GPRS

Anchor Function for Packet Data Transfer
While the mobile station is roaming through the GPRS-network, the GGSN remains the
fixed point during a packet data transmission. Packet data routing inside the PLMN
therefore is transparent to external networks. The various PDP-contexts of one mobile
stations may be handled by one or more than one GGSN.
Note that inter-PLMN roaming will (usually) cause the drop of the packet data transmission
and in turn requires the re-establishment of the PDP-context.
38
GPRS
SGSN
Packet
SGSN GGSN Data Network
SGSN
39
GPRS

Charging (foreign network resources)
Like the SGSN the GGSN is involved in the collection of charging information. However, opposed to the
SGSN the GGSN collects charging information that is related to the use of external packet data networks.
Example: Subscriber is roaming in a different PLMN (V-PLMN) but connects to a GGSN in his H-PLMN.
40
GPRS
Charging (foreign network resources)

$ Packet
SGSN GGSN Data Network
$

$ $

Charging
Gateway
41
GPRS
There are Different Types of GGSNs

GPRS can offer different levels and types of services to subscribers. The level of service
depends in particular on the way the GGSN is setup and connected to internal or external
servers for authentication (RADIUS [RFC 2865]) and / or IP-address allocation (DHCP
[RFC 2131]). Dependent on these capabilities, the GGSN may provide transparent or
non-transparent access to the internet or an external intranet.
The figure provides three examples:
GGSN Type A (Transparent Access)

The operator has its own DHCP/RADIUS- and DNS-server [RFC 1034 / RFC 1101 / RFC 1876 / RFC
1982] and provides an IP-address to the mobile subscriber upon PDP-context activation. Note that the
mobile user may also have a fixed IP-address in which case he would not require a dynamic address.
GGSN Type B (Non-Transparent Access)

The GGSN acts as relay for the authentication and address allocation that is actually
performed by an external ISP (e.g. AOL).
GGSN Type C (Corpoate GGSN)

In this case, a volume customer has selected one PLMN-operator to be the host of a corporate
GGSN. Whenever an onsite-employee from anywhere in the world performs a remote
access to the corporate intranet, the GGSN C will be selected.
The selection of the type of service depends on the mobile station (AT-commands) plus the
capabilities and interconnections of the GGSN. Obviously, a GGSN Type A would also provide for
non-transparent access, if it possesses suitable interfaces towards an external ISP.
42
GPRS
There are Different Types of GGSNs
Belonging to
the PLMN
DNS DHCP
radius
Internet/Intranet
DHCP A GGSN
Internet
DNS
radius ISP function
(with DNS)
PLMN
B GGSN
GGSN
GGSN
Belonging to
an ISP C
Intranet of Volume
Customer
DNS DHCP
radius
43
GPRS
Tasks and Functions of the BG

Interface for Packet Data Transmission between PLMNs
The BG (Border Gateway) takes care of all inter-PLMN GPRS traffic. Therefore, inter-PLMN traffic is
not routed via the Gi-Interface. Note that the one or more BGs of a PLMN may be part of one (or more)
SGSN or GGSN. Inter-PLMN traffic is particularly important in case of roaming mobile stations.
44
GPRS
Tasks and Functions of the BG
Interface for Packet Data Transmission between PLMNs
PLMN BG BG PLMN
45
GPRS
(1) The Mobile Station in GPRS

With HSCSD, mobile stations were distinguished by their capability to support transmission
/ reception on one or multiple timeslots . We will cover these multislot classes later. GPRS
also uses the multislot classes but introduces in addition three mobile station classes, A,
B and C which are mostly independent of the multislot class.
These GPRS specific mobile station classes most importantly have different capabilities for the
simultaneous support of packet-switched and circuit-switched services.
Mobile Station Classes

The figure illustrates the different mobile station classes. Please note that any mobile station may be
of class B, C or DTM with a multislot class of 1 12. Legacy GSM mobile stations ( pre-GPRS)
are simply class C mobile stations which are GSM-attached. Support for 8-PSK ( EGPRS)
46
GPRS
47
GPRS

Mobile Station Class A
GPRS mobile station class A is enabled to monitor and operate circuit-switched and
packet-switched services simultaneously. No restrictions for the allocations of resources apply
for the network. That is, the mobile station may be required to transmit and/or receive during the
same timeslot on two different frequencies. This mode of operation is obviously appealing from the
service perspective but it can only be realized under unbearable technical efforts.
48
GPRS
mail
Master
Smail
Return
call
49
GPRS

Simple Class A Mobile Station (DTM Dual Transfer Mode)
The direct implementation of the Rel.97/98 standard for class A would result in mobile
stations that are required to operate in two different frequencies the same time. This
would complicate the internal architecture of the MS enormously, since two completely
separated transceivers are needed, which in turn
would result in a very high development and production cost.
The simple class A MS is not required to operate in two different frequencies in the same moment
in time. Note that this implies that the MS does not have to receive and to transmit at the same
time, and that the MS does not need to listen to the PS paging an the CS paging simultaneously, if
the PCCH is on an other frequency than the PCH ( fallback into class B of operation with priority to
CS service)! However, GSM CS and GSM GPRS services are still supported simultaneously.
Thus, simple class A feature is a subset of the GPRS class A capabilities.
The mentioned subset is referred to as DTM ( Dual Transfer Mode) . This
will be discussed in detail later.
50
GPRS
MSC
Only one ARFCN at a time!
BSS Simultaneous Operation
SGSN
51
GPRS

Mobile Station Class B
GPRS mobile station class B is enabled to monitor circuit-switched and packet-switched services
simultaneously. However, at any given moment in time, only one of the two services may be
operated. That is, either the mobile station is in circuit-switched dedicated mode (TCH or SDCCH
plus associated control channels are activated) or the mobile station is in packet transfer mode
with uplink and/or downlink TBF in operation. Still, the mobile station is attached to both core
network domains. Most mobile stations on the market today are class B mobile stations.
The graphics page also mentions the GPRS-suspension procedure that a class B mobile
station shall perform and which consists (from the perspective of the mobile station) of the
transfer of a GPRS-Suspension Request message (GPRS_SUSP_REQ) to the BSC. At the
end of the related circuit-switched connection the mobile station needs to resume GPRS either
automatically (network feature) or by performing a routing area update.
Note that in Network Operation Mode III (NOM III) a class B mobile station may (but
doesnt have to) try to follow both paging channels with priority on the circuit-switched
paging channel but it is not required to do so compared to being in a NOM I or NOM II
environment. If the mobile station class B cannot support simultaneous monitoring of the
packet-switched paging channel and the circuit-switched paging channel it shall fallback
to class C mode (with priority on circuit-switched operation).
52
GPRS
mail
Master
Smail
Return
call
Note that a mobile station class B which is both IMSI- and GPRS-attached needs to suspend GPRS
whenever a dedicated channel (DCCH) is established towards the circuit-switched domain.
53
GPRS

Mobile Station Class C
A mobile station / class C supports either circuit-switched monitoring / operation or packet-switched
monitoring / operation. Therefore, all non-GPRS capable mobile phones are class C mobile phones.
A class C mobile phone is either attached to GPRS (SGSN) or GSM-services (VLR).
If GPRS-attached, the class C mobile phone may (but doesnt have to) support
the transmission / reception of short messages.
54
GPRS
mail
Master
Smail
Return
call
55
GPRS
(1) The Different Multislot Classes

Multislot Class Type
Mobile phones with a multislot class of type 1 are not required to transmit and receive at the same
time. Opposed to that, mobile phones with a multislot class of type 2 need to support simultaneous
transmission and reception (full-duplex). Half-duplex mode of operation is possible (with fixed uplink
resource allocation only) for multislot classes 19 - 29 only. Half-duplex refers to the capability to
support either transmission in uplink direction or reception in downlink direction at any given time.
Only in half-duplex mode of operation a mobile station with multislot classes 19 - 29 supports the
maximum number of timeslots according to its multislot class. Therefore, in half-duplex mode of
operation a mobile phone that is currently transmitting is not required to receive anything else than
PACCH-information at scheduled times ( MEASUREMENT_MAPPING) from the base station.
Please note that the fixed uplink resource allocation is an optional feature with GPRS Rel. 99 and
GERAN Rel. 4. With GERAN Rel. 5, support for fixed allocation is withdrawn.
Max No of Receive Timeslots / Max No of Transmit Timeslots / Sum

These columns indicate on how many timeslots a mobile phone is capable to transmit and receive
per TDMA-frame. Examples for multislot classes 8 and 12 are presented on the following pages.
Note that the column"Sum" presents the aggregated number of allocated transmit and receive
timeslots per TDMA-frame that is supported by a mobile phone (see figure)
Obviously this value is meaningful only for multislot classes 1 to 12.

Reasons:
Type 2: Sum could be 3 - 6 for multislot class 13, 4 - 8 for multislot class 14 and so on ( Ambiguity).
Type 1: For Multislot classes 19 - 29 there is an either / or relationship of transmit and
receive timeslots. Hence the"Sum" value doesnt make sense.
*) 1 TS with frequency hopping or 0 TS without frequency hopping.
**) 1 TS with frequency hopping or change from receive mode to transmit mode. 0 TS without
frequency hopping and no change from receive mode to transmit mode.
***) 1 TS with frequency hopping or change from transmit mode to receive mode. 0 TS without
frequency hopping and no change from transmit mode to receive mode.
56
GPRS
Max No of Max No of
Multislot Receive Transmit Sum Tta Ttb Tra Trb
Type Class Rx +Tx
Timeslots Timesl
1 1 1 1 2 3 2 4 2
1 2 2 1 3 3 2 3 1
1 3 2 2 3 3 2 3 1
1 4 3 1 4 3 1 3 1
1 5 2 2 4 3 1 3 1
1 6 3 2 4 3 1 3 1
1 7 3 3 4 3 1 3 1
1 8 4 1 5 3 1 2 1
1 9 3 2 5 3 1 2 1
1 10 4 2 5 3 1 2 1
1 11 4 3 5 3 1 2 1
1 12 4 4 5 2 1 2 1
2 13 3 3 N/A N/A 1 / 0 *) 3 1 / 0 *)
2 14 4 4 N/A N/A 1 / 0 *) 3 1 / 0 *)
2 15 5 5 N/A N/A 1 / 0 *) 3 1 / 0 *)
MSs with these multislot classes and the according time constraints can be developed, using
the dynamic / extended dynamic resourc allocation.
MSs with these multislot classes can only be developed with either two antennas or two
tranceivers
MSs with these multislot classes cannot operate using neither the dynamic nor the
extended dynamic resource allocation method (Time Constraints)
57
GPRS

Measurements:
Each mobile phone shall perform adjacent cell signal level measurements in 44 out of 52 TDMA-frames
(measurements during up to 8 TDMA frames per PDCH multiframe may be omitted if required
for BSIC decoding or multi-RAT measurements). Signal level measurements relate to measuring
the BSIC plus the power level of adjacent cells. This rule applies unless the network has provided
specific Measurement Mapping parameters to the mobile phone that would override this requirement.
These Measurement Mapping parameters will provide information to the mobile phone at which
times, in which timeslots it shall perform adjacent cell measurements. However, these specific rules
only apply in half-duplex mode operation for multislot class 19 - 29 mobile phones. All other mobile
phones and multislot classes have to obey the"44 out of 52 TDMA-frames rule".
Timing Constraints
Being involved in a multislot transmission and / or reception, a mobile phone has to
have sufficient time gaps between the allocated timeslots:
to get ready to receive ( Trb) and (conditionally) to perform adjacent cell signal level
measurements in between ( Tra = Trb + N timeslots)
to get ready to transmit ( Ttb) and (conditionally) to perform adjacent cell signal level
measurements in between ( Tta = Ttb + K Timeslots)
The term"conditionally" in the previous sentences refers to the fact that a mobile phone will perform
adjacent cell signal level measurements either while preparing for transmission or while preparing
for reception. Accordingly, the more stringent time constraints Tra and Tta will never apply together
during one flow. Rather Tra & Ttb will apply together or Tta & Trb will apply together.
Note that in half-duplex mode (only multislot classes 19 - 29) only the less stringent time constraints Ttb
& Trb may apply together, if the PCU has provided Measurement Mapping parameters.
*) 1 TS with frequency hopping or 0 TS without frequency hopping.
**) 1 TS with frequency hopping or change from receive mode to transmit mode. 0 TS without
frequency hopping and no change from receive mode to transmit mode.
***) 1 TS with frequency hopping or change from transmit mode to receive mode. 0 TS without
frequency hopping and no change from transmit mode to receive mode.
58
GPRS
Max No of Max No of
Multislot Receive Transmit Sum Tta Ttb Tra Trb
Type Class Rx +Tx
Timeslots Timesl
2 16 6 6 N/A N/A 1 / 0 *) 2 1 / 0 *)
2 17 7 7 N/A N/A 1 / 0 *) 1 0
2 18 8 8 N/A N/A 0 0 0
1 19 6 2 N/A 3 1 / 0 *) 2 1 / 0 *)
1 20 6 3 N/A 3 1 / 0 *) 2 1 / 0 *)
1 21 6 4 N/A 3 1 / 0 *) 2 1 / 0 *)
1 22 6 4 N/A 2 1 / 0 *) 2 1 / 0 *)
1 23 6 6 N/A 2 1 / 0 *) 2 1 / 0 *)
1 24 8 2 N/A 3 1 / 0 *) 2 1 / 0 *)
1 25 8 3 N/A 3 1 / 0 *) 2 1 / 0 *)
1 26 8 4 N/A 3 1 / 0 *) 2 1 / 0 *)
1 27 8 4 N/A 2 1 / 0 *) 2 1 / 0 *)
1 28 8 6 N/A 2 1 / 0 *) 2 1 / 0 *)
1 29 8 8 N/A 2 1 / 0 *) 2 1 / 0 *)
MSs with these multislot classes and the according time constraints can be developed, using
the dynamic / extended dynamic resourc allocation.
MSs with these multislot classes can only be developed with either two antennas or two
tranceivers
MSs with these multislot classes cannot operate using neither the dynamic nor the
extended dynamic resource allocation method (Time Constraints)
59
GPRS
Example for Multislot Class 8 to 12

4 Receive : 1 Transmit - Configuration
The example illustrates a mobile phone with either multislot class 8 or multislot class 12 being involved
in a transaction where the mobile phone receives on four timeslots and transmits on one timeslot.
For the determination of Tta, Ttb, Tra and Trb the respective timing advance
values shall remain unconsidered.
60
GPRS
Example for Multislot Class 8 to 12
T____= T____=
NC NC
DL Receive on 4 TSs Monitoring Receive on 4 TSs Monitoring
Transmit on 1 TS Transmit on 1 TS
UL
Please fill in the

time constraints!
61
GPRS
Example for Multislot Class 11 and 12

The example illustrates a mobile phone with multislot class 12 being involved in a transaction
where the mobile phone receives on two timeslots and transmits on three timeslots.
62
GPRS
Example for Multislot Class 11 and 12
T____= T____=
NC
DL Receive on 2 TSs Monitoring Receive on 2 TSs
UL Transmit on 3 TSs Transmit on 3 TSs
Please fill in the

time constraints!
63
GPRS
This page intentionally left blank.
64
Chapter 2
Terrestrial Interfaces
65
GPRS
Objectives
On completion of this chapter the student should be able to:
State the GPRS Protocols.
Explain the functions of the GPRS Protocols.
66
GPRS
The GPRS Protocol Stack between MS and Application

The Protocol Stack only presents the packet-switched view, therefore, the MSC/VLR and
the circuit-switched protocols are not presented. Also missing is the SS7/MAP-interfaces
between the GSNs and the databases VLR, EIR and HLR and the interface between the
SGSN and the SMS-IW/G-MSC for short message transfer.
GPRS is only a Bearer. From the outside world, GPRS is just providing another layer 2 mainly for IP.
Note that the IP among the GSNs has no relationship to the IP in the application layer.
67
GPRS
The GPRS Protocol Stack between MS and Application
IP/PPP IP/PPP
SMS SMS
GMM/SM GMM/SM
SNDCP SNDCP GTP GTP
Lower Layers
LLC LLC UDP UDP
RLC RLC BSSGP BSSGP IP IP

Layer 2 Layer 2
MAC MAC NS FR NS FR (fr 7) (fr 7)
GSM RF GSM RF Layer 1 Layer 1 Layer 1 Layer 1 Layer 1 Layer 1 Layer 1 Layer 1
Air Abis Internal Gb Gn

interface interface interface interface interface
BSC PCU SGSN GGSN

BTS
68
GPRS
Activity at the GGSN

Applicability of GTP-C, GTP-U and GTP
GTP-C
GTP-C is used in the control plane only. GTP-C messages are responsible for the PDP-context
activation, modification and deactivation and the management of the related GTP-tunnels
on the Gp- and Gn-interfaces. In addition, GTP-C is in charge for all mobility management
related signaling within the control plane on the Gp- and Gn-interfaces.
GTP-U
The major use GTP-U is the exchange of user payload between GSNs and between
SGSN and RNC (Radio Network Controller). In addition, GTP-U supports a few signaling
messages to check the state of a GTP-U tunnel.
GTP
GTP is the recommended protocol for the transfer of CDRs between SGSN and GGSN
on one hand and the charging gateway on the other hand.
69
GPRS
Gn
SGSN GGSN
BSS
Ga Ga
Gn CG Gp
Ga
SGSN BG
Gp
BSS
GTP
GTP-C
GTP-U
GTP-U
(only)
70
GPRS

Definition of GTP Paths and Tunnels
Path
There is at least one GTP-path between one SGSN and one GGSN or between two SGSNs, if at
least one PDP-context is active between these two GSNs. Each path allows the transmission
of G-PDUs and signaling messages between GSNs by means of UDP/IP.
Each path between two GSNs is identified through the combination of source / destination
IP-address and source / destination port number.
GTP-Tunnel
There are GTP-tunnels in the control plane and in the user plane of GTP. Each tunnel is unambiguously
identified through the TEID (Tunnel Endpoint Identifier), the UDP-port number and the IP-address
of the network node. The receiving end side of a GTP tunnel locally assigns the TEID value the
transmitting side has to use (i.e. for mobile originated PDP-context establishment the GGSN
assigns the TEID the SGSN has to use to identify the very PDP-context).
Several GTP-tunnels can be multiplexed on a single GTP-path.
Note: For each PDP-context the establishment of an independent tunnel for both,
the control plane and the user plane is required.
71
GPRS
GTP-C GTP-U
Tunnel
TEID + UDP-Port + IP Address

GGSN
SGSN Path: UDP
72
GPRS

Functions of GTP
Path Management
Path management relates to the optional alive check of an active path between two GSNs. A
path is alive, if at least one PDP-context is established between the two GSNs.
Tunnel Management
Tunnel management relates to the establishment, update and deletion of tunnels between
two SGSNs. Each tunnel serves exactly one PDP-context. Each tunnel is identified through
the tunnel identifier which is part of the GTP-message header.
Location Management
Location Management is required only if mobile terminating PDP-context activation shall be

supported and the GGSN does not have a Gc-interface (the Gc-interface is optional).
Note: For mobile terminating PDP-context activation, the GGSN needs static IP-address information to
map the IP-address of an incoming IP-packet to an IMSI and consequently to an HLR.
Mobility Management
Mobility management, in the context of the GTP, entirely relates to inter-SGSN communication. This is
applicable in two cases: The first case is the GPRS attachment when the mobile station has since last
detachment changed the SGSN and the new SGSN contacts the former SGSN to obtain subscriber
information (see GMM-chapter). The second case is the inter-SGSN Routing Area Update Procedure.
73
GPRS
GTP
Functions
Path Tunnel Location Mobility

Management Management Management Management
74
GPRS
Internet Protocol (IP) Encapsulation

At the GGSN, the next stage is the encapsulation of the T-PDU with either UDP or TCP.
Currently, UDP is the only path protocol defined to transfer GTP signalling messages and is
the recommended choice for the establishment of a connectionless path for connectionless
T-PDUs. For reliable connection orientated paths, TCP is used for T-PDUs. It should
be noted that both UDP and TCP use the services of IP.
User Datagram Protocol (UDP) Header

The UDP Header was discussed earlier and comprises of a Source Port, Destination Port, Length
Indicator and Checksum. With regards to signalling request messages, the UDP Destination Port
is set to 3386 which is reserved currently for GTP. The Source Port will be locally allocated by
the sending GSN. For signalling response messages, the Destination Port will be the same as
the Source port for the corresponding request message and the Source Port will be set once
again to 3386. In the case of encapsulated T-PDUs in connectionless mode, the UDP Destination
Port will be set to 3386 and the Source Port will once again be locally allocated.
The signalling message or T-PDU along with the UDP Header is then passed down
to the IP layer where an IP header is added.
Internet Protocol (IP)

In the GPRS Phase 1, IPv4 will be the networking technology upon which GTP tunnelling shall
be based. The IP address used for routing purposes will be independent of the "Public" Internet
and as such be considered as a GPRS Intranet linking all the GSNs in the network. Therefore,
when encapsulated data is passed down to the IP Layer from either UDP or TCP, the source and
destination IP addresses will correspond to the IP address of the subsequent GSNs to which
the data/signalling message should be tunnelled. This information is carried in the IP header
and routing is determined in accordance with standard IPv4 practices.
In summary, a packet from an external data network will be encapsulated at the GGSN with the GTP
Header, UDP Header and IP Header. If the resulting IP datagram is larger than the Maximum Transfer
Unit (MTU) on the first link, fragmentation of the IP datagram will occur. This will be performed by the
GGSN. It is desirable that the IP datagram be no larger than the path MTU value to ensure a quicker
and more reliable connection. If fragmentation does occur, it is the IP Layer of the SGSN that will
reassemble the fragments of the initial datagram before passing up the data to either TCP .
75
GPRS
Internet Protocol (IP) Encapsulation
PDU
IP/PPP
GTP PDU
GTP
UDP
UDP GTP PDU
UDP
IP IP GTP PDU
L2
L1
Gn GGSN
76
GPRS
Activity at the SGSN

Data and signalling messages arrive at the SGSN via the Gn interface. The IP datagrams are collected
by the IP Layer and are reassembled if fragmentation has occurred either at the GGSN or at any
subsequent IP router along the Gn interface. Any additional processes are carried out at this layer
before the payload is passed up to either UDP . The use of IP is indicated in the Type Field in the IP
Header and is dependent upon whether a connectionless or connection orientated path is required.
At the UDP/TCP layer, more processes are carried out such as determining the checksum
value before this payload is passed up to GTP. Once again, the exact destination to which the
payload is sent in GTP is determined by the Destination Port address.
At the GTP Layer, the GTP Header is stripped off resulting in the PDU being ready for
onward transmission across the Gb interface towards the BSS. As such, the PDU can
be said to have been tunnelled across the Gn interface.
To traverse across the Gb interface, the PDU requires further modification. This is carried out by the
Sub-network Dependent Convergence Protocol (SNDCP), the Logical Link Control (LLC) Protocol
and the Base Station System GPRS Protocol (BSSGP) before being carried towards the BSS via a
Frame Relay network. Therefore, to explain the actions of the SGSN, we shall once again discuss
the role of the above protocols with regards to a PDU traversing the GPRS network.
77
GPRS
Activity at the SGSN
IP/PPP IP/PPP
SMS SMS
GMM/SM GMM/SM
SNDCP SNDCP GTP GTP
Lower Layers
LLC LLC UDP UDP

Layer 2 Layer 2

BSC PCU SGSN GGSN

BTS
78
GPRS
Sub-network Dependent Convergence Protocol (SNDCP)

Network layer protocols are intended to be capable of operating over services derived from a
wide variety of sub-networks and data links. GPRS supports several network layer protocols
providing protocol transparency for the users of the service. Introduction of new Network
Layer protocols will, therefore, be possible without changing any of the lower GPRS protocols.
Therefore, all functions related to the transfer of Network Layer Protocol Data Units (N-PDUs)
are carried out in a transparent way by the GPRS network entities - SNDCP.
The set of protocol entities sitting above SNDCP consists of commonly used network protocols.
These all use the same SNDCP entity, which then performs multiplexing of data coming from different
sources before being sent via the services, provided by the LLC Layer. The Network Service Access
Point Identifier (NSAPI) acts as an index for the appropriate Packet Data Protocol (PDP) which is
using the services of SNDCP. Each active NSAPI uses the services provided by the SAPI in the
LLC Layer and as such several NSAPIs may be associated with the same SAPI.
79
GPRS
Sub-network Dependent Convergence Protocol (SNDCP)
Packet Data Packet Data Packet Data

Protocol Protocol Protocol
N-PDU
NSAPI
SNDCP
SN-PDU
SAPI
LLC
80
SNDCP Service Functions
The following functions are performed by SNDCP:
Transmission and reception of N-PDUs in acknowledged and unacknowledged LLC mode. In
acknowledged mode, the receipt of data shall be confirmed at the LLC layer, and the data
shall be transmitted and received in order per NSAPI. In unacknowledged mode, the receipt
of data shall not be confirmed at the SNDCP layer nor at the LLC layer.
Transmission and reception between the MS and SGSN of variable-length N-PDUs.
Transmission and reception of N-PDUs between the SGSN and MS according
to the negotiated QoS profile.
Segmentation and reassemble. The outputs of the compression functions are segmented to the
maximum length of LL-PDU. This is independent of the particular Network Layer protocol being used.
Transfer of the minimum amount of data possible between the SGSN and
MS through compression techniques.
Compression of redundant protocol control information (e.g. TCP/IP header) at the transmitting
entity and decompression at the receiving entity. Compression may be performed independently
for each QoS delay class and precedence class. If several network layers use the same QoS delay
class and precedence class, then one common compressor may be used for these network layers.
81
GPRS
SNDCP Service Functions
Network Header Data SN-DATA PDU/SN-UNIDATA request

layer
SNDCP Control
Compression
Data
Compression
SN-DATA PDU/SN-UNIDATA PDU

Segmentation
SN-DATA PDU/
SNDCP SNDCP
Segmented N-PDU SN-UNIDATA PDU
Header
LLC Data/LL-UNIDATA request

LLC LLC
LLC Header SN-DATA PDU/SN-UNIDATA PDU FCS Frame
82
GPRS
Logical Link Control (LLC)

The Logical Link Control (LLC) protocol is defined between the mobile station and the SGSN.
LLC is located on top of RLC/MAC in the mobile station while in the SGSN LLC is positioned
on top of BSSGP. Note that LLC is still considered to be part of OSI-layer 2.
LLC provides the radio interface independent logical link for the transport of short
messages, signaling messages for GPRS mobility management and session management
and for the transfer of user data via the SNDCP .
Note: Logical Link Control is the lowest protocol of the GPRS protocol stack that is independent of the
underlying radio link protocol. Accordingly, the LLC-protocol and higher layers of the GPRS protocol
stack can be adopted by alternative radio link protocols to provide packet radio service.
Provision of a Logical Link between the SGSN and the Mobile Station for higher layer
PDU Transfer
The LLC-layer within the SGSN will distinguish LLC-PDUs destined for or coming from different mobile
stations by means of the TLLI (part of the primitives from/to RLC/MAC and BSSGP). In addition,
LLC introduces a SAPI to distinguish among different PDUs for the same mobile station.
Provision of Acknowledged and Unacknowledged Operation Modes

Both operation modes are very similar to acknowledged and unacknowledged operation modes
in LAPD (Link Access Protocol for the ISDN-D-Channel). Accordingly, acknowledged operation
mode is referred to as Asynchronous Balanced Mode (ABM) and unacknowledged operation
mode is referred to as Asynchronous Disconnected Mode (ADM).
In-Sequence Delivery of higher layer PDUs

This applies to both operation modes, acknowledged and unacknowledged.
Optional Ciphering of higher layer PDUs

In GPRS, there is no A5-ciphering as known from circuit-switched GSM. Ciphering rather
becomes part of the functions of the LLC-protocol. Controlled by the SGSN, ciphering operation
is different in acknowledged and unacknowledged operation.
Negotiation of Logical Link Characteristics between the SGSN and Mobile Station
Different mobile stations and different SGSNs may support different transfer characteristics.
Therefore, mobile station and SGSN can start data transmission either after negotiation of
these transfer characteristics or by accepting the default values.
83
GPRS
Logical Link Control (LLC)

Frame
84
GPRS
Base Station System GPRS Protocol (BSSGP)

The protocol architecture, which lies between the BSS and the SGSN, is based upon
Frame Relay or IP, which utilises virtual circuits allowing data to be multiplexed from several
MSs. Sitting on top of the Frame Relay or IP protocols is another GPRS specific protocol
called the Base Station System GPRS Protocol (BSSGP).
The primary functions of the BSSGP include the provision of radio-related information, which is
to be used by the Radio Link Control (RLC), and Medium Access Control (MAC) functions. In
addition, the BSSGP must also provide the functionality to enable two physically distinct nodes,
an SGSN and a BSS, to operate node management control functions.
The figure opposite illustrates the users of BSSGP. Here we can see that it is not only
the Logical Link Control (LLC) that utilises BSSGP but also GPRS Mobility Management
(GMM) and Network Management (NM) at the SGSN.
The functions of GMM deal with paging and radio status requests, whilst the NM functions
deal with such aspects as flow control and resets.
At the BSS, a Relay (RL) provides the functions for controlling the transfer of LLC frames
between the RLC/MAC Layer and the BSSGP Layer.
BSSGP Virtual Connections (BVC) provide communication paths between the BSSGP entities at
the SGSN and the BSS. Each BVC is used in the transport of the BSSGP PDUs between peer
Point-To-Point (PTP) functional entities and peer signalling functional entities. A PTP functional entity is
responsible for PTP user data transmission and as such there is one PTP functional entity per cell.
Each BVC is identified by means of a BSSGP Virtual Connection Identifier (BVCI) which has end-to-end
significance across the Gb interface and as such, each BVCI is unique between two Network Service
(NS) entities. At the SGSN, the BVCIs associated with PTP functional entities are dynamically
configured where as for signalling functions, the BVCIs are configured statically and set to 0000 hex.
85
GPRS
Base Station System GPRS Protocol (BSSGP)

Interfaces
86
GPRS
The Protocol Stack on the Gb-Interface

The protocol stack on the Gb-interface is based on Frame Relay (FR) or IP as transport protocols. On
top of the generic transport protocol (FR or IP) there is the GPRS proprietary Network Service Control
protocol which interfaces Frame Relay to the Base Station System GPRS Protocol (BSSGP).
87
GPRS
The Protocol Stack on the Gb-Interface
88
GPRS
Option 1: Network Service based on Frame Relay

In GPRS, the combination of Frame Relay and Network Service Control is called Network Service
(NS). In the respect of Network Service, Frame Relay is referred to as Sub-Network Service
Protocol. Frame Relay provides the basic bearer for the Network Service PDUs and takes care of
the provisioning of virtual connections between peer users of the Network Service Protocol.
89
GPRS
Option 1: Network Service based on Frame Relay
90
GPRS
The Relationship between Network Service and Frame Relay

The interconnection between generic Frame Relay and the GPRS Network Service is given by
the PVCs. One PVC in Frame Relay corresponds to one Network Service Virtual Connection
(NS-VC). Each NS-VC is using its Network Service Virtual Link (NS-VL) for accessing the Frame
Relay network. That is, there is one NS-VL per NS-VC in a frame relay based environment. Each
NS-VC is identified by its NS-VCI (Network Service - Virtual Connection Identifier).
Note: Each NS-VC provides end-to-end connectivity over the Gb-interface. The genuine
reason to introduce a specific network service control protocol was exactly to provide this
end-to-end connectivity which cannot be assured by Frame Relay alone.
91
GPRS
The Relationship between Network Service and Frame Relay
92
GPRS
Option 2: Network Service based on IP

The figure illustrates a common physical configuration and the protocol stack
for an IP-based Gb-interface.
The physical configuration is based on a LAN (Intra-PLMN-Backbone) to which the
PCUs and the SGSNs are connected. Note that the SGSNs are already connected to
this Intra-PLMN-backbone even before Release 4. In any case, the network operator
may alternatively decide for a point-to-point connection between SGSN and PCU.
The protocol stack is IP-based but there needs to be a transport layer between IP and NS. The
selected transport layer is the unacknowledged and connection-less UDP.
Note that the layers 1 and 2 underneath IP are not specified by the 3GPP-recommendations.
93
GPRS
Option 2: Network Service based on IP
94
GPRS
The Relationship between Network Service and IP

The figure illustrates how 3GPP has defined the interworking between the generic IP-protocol
environment and the GPRS-specific Network Service protocol. Most importantly, the network
service needs to map its NS-VLs and NS-VCs to the IP-protocol stack. As the figure
illustrates, the connection between a peer (e.g. the SGSN) and the LAN is physically
provided through NICs (Network Interface Card). Each NIC supports exactly one IP-address.
Through this approach, the SGSN may simultaneously use several different IP-addresses.
Network Service Virtual Links (NS-VL)

Like in Frame Relay based network service, the NS-VL has only local significance at the very peer.
Each NS-VL is identified by its NS-VLI (Network Service Virtual Link Identifier). The NS-VLI consists
of the IP-address UDP-port number combination which is used for this NS-VL at this end. Like
in Frame Relay based Network Service several NS-VLs may exist at any given peer.
Network Service Virtual Connection (NS-VC)

In IP-based Network Service implementations, the NS-VC is identified by the IP-address / UDP-port
number combinations which are used at both ends. Example: In the figure, there is NS-VC3 which is
identified on one hand by the IP-address 1 (used at the SGSN) and UDP-port number 1 (valid only
at IP-address 1) and on the other hand by the IP-address which is used by PCU 3 in combination
with UDP-port number X which is allocated at PCU 3 for the Network Service connection.
Note:
Opposed to Frame Relay based Network Service implementations, the IP-based Network
Service implementation allows for multiple NS-VCs using one NS-VL.
In IP-based Network Service implementations, the PCU needs to be aware of one or more
pre-configured IP-address / UDP-port number combinations of at least one SGSN. However,
no well-known port numbers for Network Service are necessary.
The IP-address of the PCU may be fixed ( pre-configured) or it may be
allocated upon start-up by a DHCP-server.
95
GPRS
The Relationship between Network Service and IP
96
GPRS
The Way of an IP-Frame through the GPRS Network

The figure illustrates which addressing means are used between two vertically adjacent
protocols to route a user data packet through the GPRS network
97
GPRS
The Way of an IP-Frame through the GPRS Network
Applications
Applications
NSAPI
IMSI
NSAPI NSAPI
TLLI IMSI
SNDCP SNDCP GTP GTP

SAPI SAPI TEID
TLLI TLLI IP/UDP
LLC TLLI LLC UDP UDP
SAPI SAPI Port

TLLI TLLI Number
TFI BVCI
TLLI (NSEI) IP-
NS Address
NS
MAC MAC NS-VC L2 L2
ARFCN FR FR
TS Radio Block
DLCI
L1 L1 L1 L1 L1
L1
PCU SGSN GGSN

m
98
Chapter 3
Air Interface
100
GPRS
Objectives
Explain the Frame Hierarchy of GSM/GPRS.
State the GPRS Logical Channels.
State the GPRS coding Schemes.
State the types and explain the Resource Allocation methods.
Explain how Timing Advance is achieved in the GPRS system.
State the Quality of Service criteria.
102
GPRS
The Frame Hierarchy

With the introduction of GPRS, the 52-Multiframe is added to the GSM frame hierarchy for the
operation of Packet Data Channels (PDCH). The 52-Multiframe can be considered as two consecutive
26-Multiframes. Please note that a mobile phone will still only obtain T1, T2 and T3 from the SCH
of the serving cell to determine the respective frame number of a base station.
T1: Number of the Superframe within the Hyperframe (11 Bits) Possible Values: {0 ... 2047}
T2: Number of the 51-Multiframe within the Superframe (5 Bits) Possible Values: {0 ... 25}
T3: Number of the SCH-Frame within the 51-Multiframe minus 1 divided by 10 (3 Bits) Possible Values:
{0 ... 4} T3 = (T3 - 1) div 10 with T3 being the TDMA-frame number within the 51-Multiframe.
The 26-Multi-frame
Is exclusively used by circuit-switched traffic channels (TCH/X) and their associated control
channels (SACCH / FACCH). Each 26-Multiframe has a period of 120 ms.
The 51-Multi-frame
Is exclusively used by all other circuit-switched control channels (incl. the SACCH for
SDCCH). Each 51-Multiframe has a period of 235.38 ms.
The 52-Multi-frame
Is exclusively used by PDCHs. Each 52-Multiframe has a period of 240 ms.
At any given moment in time a timeslot may either operate 26-Multiframe, 51-Multiframe or 52-Multiframe.
103
GPRS
The Frame Hierarchy
Hyperframe
2048 Superframes / Period - = 3 hr 28 min 53s 760 ms
0 1 2 3 4 5 2044 2045 2046 2047
Superframe
51 x 26 - Multiframe oe 26 x 51 Multiframe or 25,5 x 52-Multiframe
0 1 2 3 4 47 48 49 50 <= 26-Multiframes
0 1 2 24 25 <= 51-Multiframes
0 1 23 24 25 <= 52-Multiframes
26-Multiframe
26 TDMA-Frames
Period = 120ms
(for cicuit-swithced TCHs)
51-Multiframe
0 1 2 24 25 51 TDMA-Frames
Period = 235.38ms
(for cicuit-swithced signalling) 52-Multiframe
52 TDMA-Frames
0 1 2 48 49 50 Period = 240ms
(for GPRS and EGPRS)
TDMA-Frame 0 1 2 49 50 51
8 TSs
Period = 4.615ms
0 1 2 3 4 5 6 7 1 Burst (577 s)
104
GPRS
The 52-Multiframe in Detail

12 Radio Blocks for the different Packet Data Channels (PDCH)
The 52-Multiframe has a duration of 240 ms. 12 Radio blocks are mapped on each 52-Multiframe.
Besides, there are 2 TDMA-frames ((I) called search frames ) for BSIC measurements of the 6
strongest adjacent cells *) plus 2 more TDMA-frames for timing advance control (TA).
Each Radio Block consists of 4 con-secutive appear-ances of the same timeslot within
4 con-secutive TDMA-frames
One radio block represents the basic resource to be allocated to a GPRS mobile station. Within
240 ms up to 12 different mobile stations may use the same timeslot, if each mobile station only
gets one radio block assigned. Obviously, the throughput rate would be rather low in that case
but at least GPRS provides for the sharing of one timeslot among various users.
*) The mobile station shall decode the BSIC of each of the 6 strongest adjacent cells at least
once every 10 s. If a mobile station is not able to perform these BSIC measurements within
the search frames it shall rather use inactivity periods to do so.
The Radio Blocks are organized in the Ordered List of Blocks

Note that GPRS is using an ordered list of blocks that identifies which blocks of the
52-Multiframe may be sequentially occupied by a certain PDCH type. This ordered list of
blocks is B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11. You will encounter this list
when we talk about the PDCHs and their allocation in more detail.
105
GPRS
The 52-Multiframe in Detail
12 Radio Blocks for the diffent Packet Data Channels (PDCH)
Each Radio Block consistes of 4 consecutive appearances of the

same timeslot within 4 consecutive TDMA-frames
The Radio Blocks are organized in the Ordered List of Blocks

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
T T
Block 0 Block 1 Block 2 Block 4 Block 5 Block 8 A Block 9 Block 11 I
A Block 3 I Block 6 Block 7 Block 10
106
GPRS
Packet Data Channels (PDCHin GPRS)

The PDTCH
Abbreviation for the bi-directional Packet Data Traffic Channel. Note that PDTCHs
are allocated unidirectional. Still, if an application requires it, a mobile station may use
resources in both directions but on different PDTCHs.
The PACCH
Abbreviation for the bi-directional Packet Associated Control Channel.
The PTCCH
Abbreviation for Packet Timing Advance Control Channel. The PTCCH is divided into
the downlink PTCCH/D and the uplink PTCCH/U.
The PBCCH
Abbreviation for the optional Packet Broadcast Control Channel.
The PCCCH
Abbreviation for the optional Packet Common Control Channel that summarizes the PRACH
(Packet Random Access Channel), the PAGCH (Packet Access Grant Channel), the PNCH
(Packet Notification Channel) and the PPCH (Packet Paging Channel).
107
GPRS
Packet Data Channels (PDCHin GPRS)
PDCH
PDTCHs are
assigned
undirectionally
PDTCH PTCCH/D PBCCH PCCCH

PACCH PTCCH/U
The only
bidirectional PDCH
PRACH PAGCH PNCH PPCH
= Uplink only
= Downlink only
108
GPRS
PDCHs are Logical Channels

PDCHs can be configured on one or more timeslots on one or more carriers
The actual configuration rules depend on the system manufacturer and on the preferences of
the operator. However, by no means a mobile station is able to use PDCHs on more than one
ARFCN during a packet data transfer. Still, a class A mobile station needs to be able to support a
circuit-switched transaction on one ARFCN and a packet-switched transaction on the same or another
ARFCN. Note that this requirement does not apply to a simple class A mobile station.
PDCHs use the 52-Multi-frame structure

Note that PBCCH and/or PCCCH alternatively could be mapped on 51-Multiframe with SMG28 (Rel
97). However, with SMG 29 (Rel. 98) the support of PBCCH and/or PCCCH on 51-Multiframe
was withdrawn. Therefore, all PDCHs are tied to the 52-Multiframe.
PDCHs can be allocated dynamically by the system

The OSS can dynamically react on load and reserve more or less timeslots for PDCHs.
This operation should be automatic though the administrator can still setup upper and/or
lower thresholds for the number of possible PDCHs.
Some PDCHs like the PCCCH and the PBCCH are optional
If PBCCH and PCCCH are not available in a cell, the mobile station shall use BCCH and
CCCH instead. On BCCH at least one of the SYS_INFOs 3, 4, 7 or 8 will indicate whether
SYS_INFO13 is also broadcast on BCCH [ GPRS-INDICATOR = RACC (3 Bits) + SYS_INFO
13 position (1 Bit)). The presence of SYS_INFO13 indicates to the surrounding mobile stations
whether or not a base station supports GPRS in the first place.
SYS_INFO 13 is broadcast either on BCCH normal ( Block 0 of 51-Multiframe) or BCCH ext. (
Block 1 of 51-Multiframe) at least once every 33 51-Multiframes (Period 7.75 s)
109
GPRS
PDCHs can be configured on one or more timeslots

on one or more carriers
PDCHs use the 52-Multiframe structure
PDCHs can be allocated dynamically by the system
Some PDCHs like the PCCCH and the PBCCH are optional
110
GPRS
(1) Introducing the PDCHs

PBCCH (Packet Broadcast Control Channel)
There may be only one PBCCH per cell. Opposed to the BCCH, the PBCCH can be allocated
on any timeslot and any ARFCN. The PBCCH is optional and only required in case that a
PCCCH shall be allocated. If there is no PBCCH in a cell then the mobile station shall listen
only to the BCCH (SYS_INFO13) to receive all cell-specific GPRS information. If a PBCCH
is allocated then SYS_INFO13 will only contain an allocation struct that leads the mobile
station to the timeslot and ARFCN where the PBCCH is allocated.
The PBCCH can be allocated on BS_PBCCH_BLKS (1 ... 4) per 52-Multiframe. The order in which
blocks are occupied by PBCCH with an increasing BS_PBCCH_BLKS is (B0) 1, (B0 + B6) 2,
(B0 + B6 + B3) 3, (B0 + B6 + B3 + B9) 4 (according to the ordered list of blocks).
PCCCH (Packet Common Control Channel)

The PCCCH can be mapped on any timeslot on any ARFCN but no more than 16 timeslots may
carry the PCCCH per BTS . If PBCCH is allocated on timeslot N then the same timeslot N will
also carry the (first) PCCCH. The number of timeslots carrying the PCCCH in a BTS is given
by the parameter BS_PCC_CHANS (1 ... 16) ( also referred to as KC) which is broadcast
in PACK_SYS_INFO 2. Each mobile station will use and listen to only one timeslot carrying
PCCCH. This PCCCH-timeslot is determined by means of the IMSI.
Note that GPRS-mobile stations have to use the CCCHs if there is no PCCCH in a cell available.
PRACH (Packet Random Access Channel)

The PRACH is the only uplink PCCCH. It is used by the mobile station to access the system by sending
an access burst to the BTS. Note that on PRACH, the access burst may contain 8 or 11 information
bits as defined by the parameter ACCESS_BURST_TYPE which is broadcast in SYS_INFO 13,
PACK_SYS_INFO 1 and PACK_SYS_INFO 13. Opposed to that on RACH only the 8 Bit format is viable.
A mobile station can identify a radio block that is reserved for PRACH either by the USF-Free-Value =
,111bin being sent in the previous downlink radio block or by the parameter BS_PRACH_BLKS (0 ... 12)
which is broadcast in PACK_SYS_INFO 1 on PBCCH. The respective block numbers are given by the
ordered list of blocks. This ordered list of blocks is B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11.
111
GPRS
PBCCH (Packet Broadcast Control Channel)

PCCCH (Packet Common Control Channel)
PRACH (Packet Random Access Channel)
BS_PBCCH_BLKS = 2
0 1 2 3 4 5 6 7 8 9 10 11
BS_PAG_BLKS_RES = 3
(no paging on these blocks)
Available Paging Blocks
112
GPRS

PAGCH (Packet Access Grant Channel)
The PAGCH belongs to the group of downlink PCCCHs. The PAGCH is used to allocate
dedicated resources (PDTCH) to a mobile station. The PAGCH has to share the resources
of a downlink PCCCH with the PPCH and the PNCH.
PPCH (Packet Paging Channel)

Like the PAGCH, the PPCH is a downlink PCCCH. For each PCCCH, the parameter
BS_PAG_BLKS_RES (0 ... 12) indicates which and how many radio blocks shall not be used for PPCH
on this timeslot within a 52-Multiframe. In all other radio blocks, paging may be performed. Note that on
the timeslot where PBCCH is allocated also the parameter BS_PBCCH_BLKS needs to be considered.
In the example on the previous page the radio blocks B0 and B6 are reserved for the
PBCCH (BS_PBCCH_BLKS = 2) while blocks B3, B9 and B1 shall not be used for the PPCH
(BS_PAG_BLKS_RES = 3) but can be used for PAGCH, PNCH, PDTCH and PACCH. On the other
hand, the remaining radio blocks B7, B4, B10, B2, B8, B5 and B11 may be used for PPCH, PAGCH,
PNCH, PDTCH and PACCH. The respective channel type is in any case given by the message type.
PNCH (Packet Notification Channel)

The PNCH is reserved for notifying a mobile station of an upcoming Point-to-Multipoint (PTM) transaction.
113
GPRS
PAGCH (Packet Access Grant Channel)

PPCH (Packet Paging Channel)
PNCH (Packet Notification Channel)
114
GPRS

PDTCH (Packet Data Traffic Channel)
The PDTCH is a bi-directional channel but its resources are allocated unidirectional. One
or more PDTCHs are allocated to a mobile station for a packet data transmission in uplink
and/or downlink direction. Each PDTCH represents the occurrence of all radio blocks
that are assigned to one mobile station in one direction on a certain timeslot ( PDCH).
PDTCHs can be encoded using 4 different coding schemes.
The network may only allocate PDTCHs on one ARFCN to a mobile station. Therefore, the
maximum number of PDTCHs to be allocated to a mobile station is 8. The actual number
also depends on the multislot class of the mobile station.
115
GPRS
PDTCH (Packet Data Traffic Channel)
ARFCN 1 ARFCN 2 ARFCN 3 ARFCN 4
TS 0 PDCH TS 0 TS 0
TS 1 PDCH TS 1 TS 1
TS 2 TS 2 TS 2 TS 2
PDCH PDCH TS 3 TS 3
PDCH PDCH PDCH TS 4
PDCH PDCH PDCH TS 5
TS 6 TS 6 TS 6 TS 6
TS 7 NO PDCH OK TS 7 OK TS 7
116
GPRS

PACCH (Packet Associated Control Channel)
Each unidirectional PDTCH comes with its directional PACCH. The PACCH is required to
transmit RLC/MAC control information. The PACCH will steal resources from its master
channel ( the PDTCH) in the direction where the PDTCH is allocated. In the opposite
direction resources for the PACCH are allocated dynamically.
Operation of the PACCH during an Uplink TBF:
Fixed Uplink Resource Allocation: One Timeslot is chosen by the network to be
the DOWNLINK_CONTROL_TIMESLOT. In uplink direction any timeslot of the
allocation can be used for PACCH.
Dynamic Uplink Resource Allocation: Any timeslot that belongs to the allocation
can be used for downlink and uplink PACCH.
Extended Dynamic Uplink Resource Allocation: The lowest numbered timeslot of the allocation
can be used for downlink PACCH. All timeslots can be used for uplink PACCH.
PTCCH (Packet Timing Advance Control Channel)

The PTCCH is divided into the downlink PTCCH/D and the uplink PTCCH/U. Both channels
are required for the continuous timing advance control procedure. The PTCCH/U is further
divided into 16 subchannels as will be elaborated on the following slides.
117
GPRS
PACCH
(Packet Associated
Control Channel)
PTCCH
(Packet Timing Advance
Control Channel)
118
GPRS
(1) The Different Network Operation Modes

The Network Operation Mode is broad-cast to the mobile stations in SYS_INFO13,
PACK_SYS_INFO1 and 13
Three different network operation modes (NOM I, NOM II and NOM III) are defined
dependent on whether or not the Gs-interface between SGSN and VLR is available and
dependent on whether or not a BTS is equipped with PCCCH.
119
GPRS
The Network Operation Mode is broadcast to the mobile stations in

SYS_INFO13, PACK_SYS_INFO1 and 13
|1 GPRS Cell Options

|***b2*** |Network Mode of Operation |Network Mode of Operation III
|-111- - - - |Timers 3168 3166 and 3168 |4000 ms
PCCCH Optional / no Gs-Interface
120
GPRS

Network Operation Mode I (NOM I)
In NOM I the Gs-interface is present and PCCCH may but doesnt need to be equipped. Accordingly
the SGSN is in charge not only for the packet-switched paging but also for the circuit-switched paging.
The VLR will forward the circuit-switched paging to the SGSN that will relay them on either on PPCH or
PCH to the mobile station. Note that the SGSN will use the PPCH also for circuit-switched paging if the
PPCH is equipped. It will use the PCH for both types of paging, if there is no PPCH. In either case
the mobile station class A and B is relieved from listening to both, the SGSN and the MSC/VLR for
paging. Also, in NOM I only the packet-switched DRX-parameters apply for mobile stations class A
and B (and class C in GPRS-attached mode) which is another relieve compared to NOM II.
The NOM I has the major advantage that even a class B mobile station can be alerted of an
incoming circuit-switched transaction while involved in a packet-switched transaction. In that case,
the circuit-switched paging is forwarded to the mobile station by means of the PACCH. Note that
this advantage does not apply vice versa because paging coordination is possible only from the
VLR to the SGSN: Being involved in a circuit-switched transaction, there is no requirement that
a mobile station class B still receives the packet-switched paging channel.
Another major advantage of NOM I or rather of an equipped Gs-interface is the possibility to perform
attachments and registrations in combined format towards the SGSN. Hence, IMSI- and GPRS-Attach
as well as Location Area- and Routing Area-Updating and IMSI- and GPRS-Detachments are done
combined. It is the responsibility of the SGSN to inform the VLR of any of these procedures.
Note that in NOM I a mobile station will only perform Periodic Routing Area Updating but no Periodic
Location Area Updating. It is the responsibility of the SGSN to update the VLR.
Note: Whether or not a mobile station class A/B performs a combined IMSI/GPRS-attachment upon
power on also depends on the setup of the mobile station: Some manufacturers prevent automatic
GPRS attachment, since there is the possibility that an operator already charges for GPRS attachments.
121
GPRS
Network Operation Mode I (NOM I)
CS-Paging and PS-Paging for GPRS Mobile Station Class A and Class B is done:
=> on PPCH (if configured and only in idle mode)
=> on PCH (if no PPCH is available and only in idle mode)
=> on PACCH (while involved in a packet data transfer) Circuit_Switched (CS) paging
=> on FACCH (call Waiting Indication while involved in a call)
VLR ISDN / PTSN
G-MSC
GPRS-Attach and IMSI-Attach / Location Area Updating and

Routing Area Updating are performed in one procedure
towards the SGSN (<=> combined) Gs-Interface
CS-Paging is done by the
BSSGP-Message:
PAGING-CS
Packet Data Network
BSS SGSN GGSN
PS-Paging is done by the Packet-Switched (PS) Paging

BSSGP-Message:
PAGING-PS
SGSN is responsible for CS-Paging

and PS-Paging
122
GPRS

Network Operation Mode II (NOM II)
In NOM II there is no Gs-interface between VLR and SGSN and besides there is no PCCCH
equipped in the cell. Accordingly, there can be no coordination between VLR and SGSN.
Therefore all circuit-switched paging are sent by the VLR via the MSC over the A-Interface
to the BSC and further down on the PCH to the mobile station. The BSC will consider
the circuit-switched DRX-parameters of the mobile station.
On the other hand the SGSN is responsible for the packet-switched paging and will forward
these paging to the BSC/PCU. The BSC will forward the packet-switched paging message
on the PCH to the mobile station. Note that in case of packet-switched paging different DRX
parameters may apply . In NOM II the mobile stations have to perform IMSI- and GPRS-Attach,
Location Area- and Routing Area-Updating, IMSI- and GPRS-Detachments, Periodic Routing
Area Updating and Periodic Location Area Updating independently.
Note: A class B mobile station which is involved in a TBF (uplink and/or downlink) can not listen to
the paging channel and therefore is not reachable for CS services in NOM2! Vice versa a class
B mobile station in dedicated mode can not be reached for PS services in NOM2.
123
GPRS
Network Operation Mode II (NOM II)

Circuit-Switched (CS) Paging
B-Interface / CS-Paging
G-MSC ISDN/PSTN
MSC
VLR
A-Interface/CS-Paging
CS-Paging is done by the Gs-interface
BSSGP - Message:
PAGING-PS
BSS SGSN GGSN Packet Data Network
Packet-Switched (PS) Paging
CS-Paging:
=> on PCH (considering the CS-DRX-parameters)
=> on FACCH (Call Waiting Indication during a call)
IMSI-Attach/Location Area Updating are performed SGSN is responsible only for PS-Paging
towards the VLR
PS-Paging:
=> on PCH (considering the PS-DRX-parameters)
=> on PACCH (while involved in a packet data transfer)
GPRS-Attach / Routing Area Updating are performed towards the SGSN
124
GPRS

Network Operation Mode III (NOM III)
In NOM III there is no Gs-interface between VLR and SGSN but opposed to NOM II there may
be a PCCCH equipped in the cell. Like in NOM II there is no coordination possible between
VLR and SGSN. The mobile station class A has to listen to both, the circuit-switched PCH and
the packet-switched PPCH which may be allocated on different timeslots and different ARFCNs.
In NOM III, the mobile station class B may fall back to class C mode of operation (with priority
on circuit-switched operation) if it cannot follow both paging channels.
In NOM III the mobile stations have to perform IMSI- and GPRS-Attach, Location Area- and
Routing Area-Updating, IMSI- and GPRS-Detachments, Periodic Routing Area Updating
and Periodic Location Area Updating independently.
Note: The difference between a NOM II and NOM III without PCCCH is as follows:
The NOM can only be configured on a per routing area base! Therefore, if NOM II is used no PCCCH
can be allocated in any of the cells in the routing area. But if the PCCCH shall be available in some/all
of the cells in the routing are, NOM III is used, since the PCCCH can be allocated per cell base.
125
GPRS
Network Operation Mode III (NOM III)

CS-Paging:
Circuit-Switched (CS) Paging
=> on PCH (considering the CS-DRX-parameters) B-Interface / CS-Paging
=> on FACCH (Call Waiting Indication during a call) ISDN/PSTN
G-MSC
IMSI-Attach/Location Area Updating are performed MSC
towards the VLR VLR
A-Interface/CS-Paging
CS-Paging is done by the Gs-interface
BSSGP - Message:
PCH PAGING-CS
PPCH BSS SGSN GGSN Packet Data Network
PS-Paging: Packet-Switched (PS) Paging
=> on PPCH (considering the PS-DRX-parameters) Optional
=> on PACCH (while involved in a packet data transfer)
GPRS-Attach / Routing Area Updating are performed towards the SGSN
SGSN is responsible only for PS-Paging
126
GPRS
The Coding Schemes 1 - 4 in GPRS

In addition to the channel coding schemes used in GSM, GPRS introduces three
new coding schemes (CS-2 - CS-4)
Please note that CS-1 is used in GSM for the channel coding of signaling channels like the SACCH, the
SDCCH or the AGCH. Note that interleaving in GPRS is done for all coding schemes CS-1, CS-2, CS-3
and CS-4 according to the rules that are defined for the SACCH ( Block-Interleaving only).
CS-2 - CS-4 offer higher throughput rates but less protection against transmission errors.
As will be seen CS-2 and CS-3 also use a 1/2-rate convolutional coder (the same that is used
for the SACCH) but apply puncturing to reduce the number of bits to be transmitted. Therefore
data transmissions using CS-2 - CS-4 are more vulnerable against radio interference.
Note that coding schemes CS-2 - CS-4 are applicable only for PDTCHs while information
on all other PDCHs will be encoded using CS-1.
Therefore the PBCCH, the PACCH, the PTCCH/D and the PCCCH (PAGCH, PNCH and PPCH) are
encoded using CS-1. Note that CS-1 may also be used for the encoding of PDTCHs.
The mobile station needs to be able to process all coding schemes while the network
is only required to support coding scheme 1.
The GSM/GPRS-standard requires the mobile station to support all coding schemes CS-1
- CS-4 in receive and transmit mode as requested by the network. Opposed to that the
network (BTS / PCU) is only required to support CS-1.
The network selects the coding scheme to be used.

The network initially selects the coding scheme to be used in either direction. The network will also
adjust the coding scheme during a data transfer in uplink or downlink direction based on the channel
quality reports of the mobile station and the measurements being performed by the BTS.
127
GPRS
The Coding Schemes 1 - 4 in GPRS
Protection
Mandatory
for the mobile station
CS-1
CS-2
Mandatory
for the BTS
CS-3
CS-4
Throughput
128
GPRS
Details of CS-1
Initial Situation
In case of CS-1, 184 bits are delivered to the encoder. These 184 bits are divided into 8
bits for the MAC-header plus 176 bits for the RLC-data or control block. Please note that in
any case the RLC-data or control block contains at least 16 bits of the RLC-header. While
in downlink direction the first three bits of the MAC-header are the USF (Uplink State Flag),
in uplink direction there are three different control bits ( MAC).
Step 1: Block Coding & Tail Bits

In the first step the fire code is applied. The fire code will add 40 check bits for BEC (Backward
Error Correction) to the 184 input bits. Before the convolutional coding process starts, 4
tail bits (,0000) are appended to the RLC/MAC-block and the 40 check bits. These tail bits
serve as reset signal for the encoder and they help to push out the 8 last encoded bits of the
RLC/MAC-block. Finally, 228 bits are sent to the convolutional coder.
Step 2: Convolutional Coding

The convolutional coder (the same that is used for SACCH) will double the number of input bits
and therefore 456 bits is the output of the channel coding process in CS-1.
Step 3: Interleaving
After the channel coding process the 456 output bits are interleaved according to the rules of
the SACCH. Note that for GPRS only block interleaving is applicable because transmission
is based on radio blocks which represent 4 consecutive occurrences of the same timeslot.
Therefore, interleaving over more than 4 TDMA-frames is not possible.
129
GPRS
Details of CS-1
184 bits
MAC-Header
8 bits RLC - Data / Control Block
USF applicatble 3 bits
for downlink only
USF 5 bits 176 bits / (22 octets)
Fire Code
40 bits Tail
184 Data Bits Check Bits 0000
228 bits
1
/2 Rate Convolutional Coder
456 Coded Bits (4 Bursts / 1 Radio Block)
130
GPRS
Details of CS-2 and CS-3

Initial Situation
In case of CS-2 / CS-3, 271 bits / 315 bits are delivered to the encoder. These 271 bits / 315 bits
are divided into 8 bits for the MAC-header, 256 bits / 304 bits for the RLC-data block and 7 spare
bits / 3 spare bits. Please note that in any case the RLC-data block contains at least 16 bits of the
RLC-header. While in downlink direction the first three bits of the MAC-header are the USF (Uplink
State Flag), in uplink direction there are three different control bits ( MAC).
Step 1: Precoding of the first 3 Bits of the MAC-Header

To provide special protection to the uplink state flag, the first three bits of the MAC-header in downlink
direction ( USF) are precoded to six bits. The six output bits of the respective precoding table are
chosen in a way to simulate the behavior of the 1/2-rate convolutional coder being applied to the three
bits of the USF. Note that the precoding is also performed in uplink direction even though there is
no requirement for a special protection of the first three bits of the MAC-header in uplink direction.
Precoding in uplink direction is done to use the same channel coding process in either direction.
Step 2: Parity & Tail Bits

In the next step 16 parity bits for BEC are added. Before the convolutional coding process
starts, 4 tail bits (,0000) are appended to the RLC/MAC-block and the 16 parity bits.
Finally, 294 bits / 338 bits are sent to the convolutional coder.
Step 3: Convolutional Coding

The convolutional coder (the same that is used for SACCH) will double the number of input bits and
therefore 588 bits / 676 bits is the output of the channel coding process in CS-2 / CS-3.
Step 4: Puncturing
Puncturing will delete 132 bits / 220 bits of the output of the convolutional coder
to fit the 456 output bits into one radio block.
Step 5: Interleaving
131
GPRS
Details of CS-2 and CS-3
271 / 315 bits
MAC-Header 7 Spare bits (CS-2)

8 bits RLC - Data Block 3 Spare bits (CS-3)
for downlink only
USF 5 bits 256 / 304 bits (32 / 38 octets) 7/3
Pre-
Coding Tail
6 bits 16 bits
USF 268 / 312 Data Bits Parity Bits 0000
294 / 338 bits
1
/2 Rate Convolutional Coder
588 / 676 Coded Bits (Puncturing required)
132
GPRS
Puncturing
Puncturing in GSM
Puncturing is not a new technology with GPRS. Puncturing has already been used in GSM in the
channel coding process of the TCH/F 9.6 and the TCH/F 14.4. In GPRS, puncturing is used for CS-2
and CS-3 and for the channel coding process of access bursts with 11 information bits.
Introduction to Puncturing
Puncturing provides for more flexible code rates than the simple 1/2- or 1/3-convolutional
coders allow. Please remember: The code rate is the number of input bits to the
convolutional coder divided by the number of output bits.
In CS-2 we therefore calculate the code rate to 294 bits 456 bits = 0.645 2/3.
For CS-3 we apply the same formula and get 338 bits 456 bits = 0.741 3/4. For CS-1
we can do the same calculation and will figure out a code rate of 1/2.
Most importantly: Puncturing provides for the transmission of data blocks, encoded with
CS-2 and CS-3 with just one radio block of 456 bits.
The Perspec-tive of the Receiver

The puncturing process does not randomly delete bits at the output of the convolutional coder.
Puncturing will rather delete bits at predefined positions. These positions are obviously known
at both peers, the sender and the receiver. Therefore puncturing will not introduce bit errors
at random positions like interference on the radio path would do.
Puncturing rather requires the receiver to interpolate the missing bit values based on the
remaining bit values. Provided there are no or only modest random bit errors the receiver
will be able to recover the original bitstream including the punctured bits. However, with an
increasing bit error rate the probability of wrong bit interpolations increases, too. Consequently,
puncturing can only be applied under good radio conditions.
133
GPRS
Puncturing
Puncturing in GSM
Introduction to Puncturing
The Perspective of the Receiver
588 / 676 Coded Bits
Puncturing
456 Coded Bits (4 bursts)
134
GPRS
Details of CS-4
Initial Situation
In case of CS-4, 431 bits are delivered to the encoder. These 431 bits are divided into 8
bits for the MAC-header, 416 bits for the RLC-data block and 7 spare bits. Please note
that in any case the RLC-data block contains at least 16 bits of the RLC-header. While in
downlink direction the first three bits of the MAC-header are the USF (Uplink State Flag),
in uplink direction there are three different control bits ( MAC).
Step 1: Pre-coding of the first 3 Bits of the MAC-Header

To provide special protection to the uplink state flag, the first three bits of the MAC-header
in downlink direction ( USF) are precoded to 12 bits. The 12 output bits of the respective
precoding table are chosen in a way to simulate the behavior of the 1/2-rate convolutional coder
being applied two consecutive times to the three bits of the USF. Note that the precoding is
also performed in uplink direction even though there is no requirement for a special protection
of the first three bits of the MAC-header in uplink direction. Precoding in uplink direction is
done to use the same channel coding process in either direction.
Step 2: Parity & Tail Bits

In the next step 16 parity bits for BEC are added. Now the data block is 456 bits long
and will fit exactly into one radio block ( 4 normal bursts).
Step 3: No Con-volutional Coding
Step 4: Inter-leaving
Note: In CS-2 and CS-3 the already precoded USF ( 6 bits) is sent through the 1/2-rate convolutional
coder and is extended to 12 bits. The puncturing process will never affect these first 12 bits. In
CS-4 the precoding table simulates the behavior of the 1/2-rate convolutional coder being applied
two consecutive times to the three bits of the USF. Therefore, the first 12 bits of a channel coded
block in CS-2, CS-3 and CS-4 depend only on the USF but not on the coding scheme.
135
GPRS
Details of CS-4
431 bits
MAC-Header 7 Spare bits (CS-4)

8 bits RLC - Data Block
for downlink only
USF 5 bits 416 bits (52 octets) 7
Pre-
Coding Tail
12 bits 16 bits
USF 428 Data Bits Parity Bits
456 bits (4 Bursts / 1 Radio Block)
No Convolutional Coding!
136
GPRS
Why is USF-Precoding done for CS-2, CS-3 and CS-4 ?

Only in case of CS-2, CS-3 and CS-4 the first three bits of the MAC-header, which is the
USF in downlink direction, are specially protected through additional redundancy bits. Note
that in case of CS-1, there is no special protection provided.
Frequently, there is the question: Why? The answer can be found in a very important feature of GPRS:
While the downlink data or control block is destined to mobile station A, the USF of this
block is most likely destined to another mobile station. Always remember that the USF is
needed for uplink resource allocation and PRACH-notification. In that respect, the USF
is "abusing" the downlink data or control block as bearer.
In general, for downlink transmissions to mobile stations which are close to a base station, a high
coding scheme (> CS-1) is more applicable because the C/I-requirements can be met. Also, the
downlink power for data blocks which are destined to mobile stations which are rather close, can be low.
Consequentially, it can happen that a mobile station which is very far away shall receive the
USF (for uplink resource allocation or PRACH notification) while the mobile station which shall
receive the content is very close. In any case, the network has no means to determine the
distance to all mobile stations which potentially have to receive the USF.
In this case, there is a good probability that a "far-away" mobile station can hardly receive the USF of
a data block which is encoded in CS-2, CS-3 or CS-4 and which uses a low transmission power. In
this case, USF-precoding increases the chances that the "far-away" mobile station can still receive
the USF. Obviously, this feature is only meaningful with enabled downlink power control.
137
GPRS
Why is USF-Precoding done for CS-2, CS-3 and CS-4 ?
138
GPRS
The Stealing Flags identify the Coding Scheme

In GPRS, the stealing flags are not required for their genuine GSM-function ( FACCH-denoting).The
8 stealing flags within the 4 normal bursts that together form one radio block can be used to
identify the coding scheme. This measure eases the task of the receiver.
CS-1 1111 1111
CS-2 1100 1000
CS-3 0010 0001
CS-4 0001 0110
139
GPRS
The Stealing Flags identify the Coding Scheme
1 1
0 0 4 alternating bursts,
belonging to one
radio block
1 0
0 0
Stealing Flags identify

Coding Scheme 2 (CS-2)
140
GPRS
Transmission Rates for CS-1 to CS-4

The formulas are based on the following facts:
The maximum number of data bits in one data block CS-1 is 184 bits - 8 bits (MAC-header)
- 16 bits (minimum size of RLC-header) = 160 bits
The maximum number of data bits in one data block CS-2 is 271 bits - 7 spare bits - 8 bits
(MAC-header) - 16 bits (minimum size of RLC-header) = 240 bits
One PCU-frame is delivered to the encoder every 20 ms
The formulas apply in both directions, uplink and downlink.
Note: These values represent the SDU-throughput rate for RLC/MAC which is also the net
throughput rate for RLC/MAC. These values still do not present the throughput rate as perceived
by the user or by the application because possible data compression as well as limiting factors
like LLC- or SNDCP-headers and retransmissions are not considered.
141
GPRS
Transmission Rates for CS-1 to CS-4
160 bit 240 bit

CS-1: = 8000 bit/s CS-2: = 12000 bit/s
0.02 s 0.02 s
288 bit 400 bit

CS-3: = 14400 bit/s CS-4: = 20000 bit/s
0.02 s 0.02 s
142
GPRS
Transmission Rates and Timeslot Bundling

The table considers the maximum throughput rates from the previous calculation and applies
them to multislot transmission. The indicated values do not consider:
data compression on SNDCP-layer
possibly other users who are currently using the same timeslot(s).
retransmissions on RLC/MAC-layer.
RLC/MAC-signaling messages which will cause a slightly lower throughput rate.
143
GPRS
Transmission Rates and Timeslot Bundling
1 Timeslot 4 Timeslots 8 Timeslots
CS-1: 8 kbit/s 32 kbit/s 64 kbit/s
CS-2: 12 kbit/s 48 kbit/s 96 kbit/s
CS-3: 14.4 kbit/s 57.6 kbit/s 115.2 kbit/s
CS-4: 20.0 kbit/s 80 kbit/s 160 kbit/s
144
GPRS

PDCHs can be configured on one or more timeslots on one or more carriers. The actual
configuration rules depend on the system manufacturer and on the preferences of the operator.
However, by no means a mobile station is able to use PDCHs on more than one ARFCN during
a packet data transfer. Still, a class A mobile station needs to be able to support a circuit-switched
transaction on one ARFCN and a packet-switched transaction on the same or another ARFCN.
Note that this requirement does not apply to a simple class A mobile station.
Allocation of Resources
A cell supporting GPRS may allocate resources on one or several physical channels in order to support
the GPRS traffic. Those physical channels shared by the GPRS MSs are taken from a common pool of
physical channels available in the cell. This allocation of physical channels to circuit switched services
and GPRS is carried out dynamically according to the capacity on demand principles.
The capacity on demand principles refer to the fact that PDCHs need not be permanently allocated in
order to support GPRS and the way in which the network allocates available resources as required.
Common control signalling that is required by GPRS in the initial phase of packet transfer is conveyed
on the PCCCH, when allocated, or on the CCCH. This saves on GPRS specific capacity for the
operator. Should the last available PCCCH be allocated then the MS would perform cell re-selection.
At least one PDCH, acting as the master, carries the PCCCH as well as PDTCH and PACCH. Other
PDCHs, acting as slaves, are used for user data transfer and for dedicated signalling.
Release of PDCH
The fast release of PDCH is an important feature to enable the dynamic sharing of
the physical radio resources between packet and circuit switched servics. To enable
this three PDCH release options are available:
Wait for all assignments to terminate on that PDCH.
Individuaklly notify all the users that have assignments on that PDCH.
Broadcast the notification about de-allocation.
145
GPRS

GPRS Timeslot Configurations
Example A Example B Example C

0 BCCH TCH BCCH SW BCCH SW
1 TCH TCH TCH SW TCH SW
2 TCH TCH TCH SW TCH SW
3 SW TCH TCH RES TCH SW
4 SW TCH TCH RES TCH SW
5 RES TCH TCH RES TCH SW
BCCH CARRIER BCCH CARRIER BCCH CARRIER

CARRIER 2 CARRIER 2 CARRIER 2
146
GPRS
Uplink Resource Allocation

Allocation of resources on the Uplink is vital, as the data transmissions from 2 MS could collide.
There are 2 methods of implementing Uplink Resource allocation at present.
1. Fixed Allocation of Uplink Resources.
2. Dynamic Allocation of Uplink Resources.
Downlink Resource Allocation

Downlink resources are allocated to the MS via the Packet Downlink Assignment message. This
message will detail all the timeslots that the MS may receive data on for this particular transaction.
Each complete data transfer is allocated a Temporary Block Flow (TBF), known by its identifier,
the Temporary Flow Identifier (TFI). The TFI is part of each Uplink/Downlink RLC Data Block
and is composed of 7 bits in the Uplink and 5 bits in the Downlink.
The TFI for a particular MS is also specified in the Packet Downlink Assignment message.
The MS then has to receive and decode all the RLC/MAC blocks on its allocated timeslots to
ascertain if the TFI contained in the block is the TFI allocated to the MS. When the MS identifies
a block containing its allocated TFI the MS will decode and process the data block.
Dynamic Allocation
The dynamic allocation of Uplink resources is based upon the use of the Uplink State Flag (USF).
The USF forms part of each downlink Data or Control Block that is sent.
The USF is transmitted in the downlink to indicate an invitation to transmit to mobiles. A
mobile is allocated a number of uplink time-slots (shared with other mobiles) and each is
told when they may be allowed to transmit. Although up to the maximum 8 time-slots may
be allocated, this would require the phone to have a duplexer.
The USF has a fixed length of 3 bits, so that up to 7 MS can be distinguished on a particular timeslot. A
MS having multiple timeslots allocated may have different USFs allocated for each timeslot.
A USF value of 111 is used to denote that the next uplink block is reserved for PRACHs.
Once the MS detects its USF in the downlink RLC Data Blick it will transmit on the next uplink block
or the next 4 uplink blocks dependent upon the value of the USF_GRANULARITY.
The USF_GRANULARITY is also included in the Packet Uplink Assignment. The
USF_GRANULARITY has two values, 0 and 1.
If the USF_GRANULARITY is set to 0 the MS will transmit on the next uplink block
following the appearance of its USF value.
If the USF_GRANULARITY is set to 1 the MS will transmit on the next four uplink
blocks following the appearance of its USF.
In the diagram opposite two MSs have been allocated uplink resources dynamically.
MS 1 will look for a USF value of 5 on timeslot 6 and a USF value of 3 on timeslot 7.
MS 2 will look for a USF value of 4 on timeslot 6 and a USF value of 2 on timeslot 7.
Following the appearance of these respective values each MS will transmit on
the next available uplink block.
147
GPRS

PDTCHs Dynamic Allocation
LLC
FH Information Field FCS
RLC/MAC
BH Information BCS BH Information BCS BH Information BCS
NB NB NB NB
5 5 5 I 4 5 5 I 4 4 I I DL
TS6
5 5 I 5 4 5 I 5 4 4 I I UL
3 3 2 I 2 3 3 I 2 2 I I DL
TS7
3 3 I 2 2 3 I 3 2 2 I I
UL
148
GPRS

Problems of Dynamic Allocation
The principle of dynamic allocation is that the mobile station has to listen to the downlink direction of
those timeslots which have been allocated in uplink direction. Taking into account that all multislot
class type 1 mobile stations require at least one timeslot to switch from reception to transmission (Tta
or Ttb) it becomes impossible to allocate more than 2 timeslots to such a mobile station.
Consequentially, transmission on more than 2 timeslots for multislot class type 1 mobile stations
is only applicable if fixed or extended dynamic allocation is used by the network. And finally, only
extended dynamic allocation remains an option as support for fixed allocation is declining.
149
GPRS
Listen to USF no time to switch from

receive to transmit!
DL 0 1 2 3 4 5 6 7
UL 5 6 7 0TA 1 2 3 4
Transmit
SYS101_ch03_148
150
GPRS

The Extended Dynamic Resource Allocation Method
Extended Dynamic allocation basically works like dynamic resource allocation. The PCU will
only set the EXTENDED_DYNAMIC_ALLOCATION parameter = ,1 in the PACK_UL_ASS- or
PACK_TS_RECONF-message to indicate extended dynamic allocation. Opposed to dynamic
allocation, extended dynamic allocation works as follows (see figure):
Whenever the mobile station detects an allocated USF (may be different per timeslot) in
downlink block K on an allocated timeslot N then not only uplink block (k+1) on the same
timeslot N but uplink block (k+1) on timeslot N and all higher numbered timeslots that
belong to the allocation, shall be used by the mobile station.
After detecting an allocated USF on timeslot N in downlink block k the mobile station shall
not listen for the USFs in downlink block k on the higher numbered timeslots and neither to
the USFs in those higher numbered timeslots in downlink block (k+1).
In case of extended dynamic allocation the PACK_UL_ASS- or
PACK_TS_RECONF-message will contain:
The information whether EXTENDED_DYNAMIC_ALLOCATION (m) shall be applied.
The information whether or not downlink power control is used and what the offset
downlink power level (P0 (o)) relative to BCCH is.
The information which power reduction mode shall be used for this TBF (PR_MODE
(o)) ( only if downlink power control is used).
The information whether USF-detection authorizes the mobile station to transmit only in the next
or in the next four uplink radio blocks on this timeslot (USF_GRANULARITY) (m).
The assignment of the uplink TFI (o)
The possible limitation of a TBF. By means of RLC_DATA_BLOCKS_GRANTED (o) the mobile
station can be limited to transfer only the indicated number of uplink radio blocks.
The delay between the assignment message and the allocation (TBF_STARTING_TIME (m))
The USF (m) per timeslot number plus the information of the uplink power control parameters
(ALPHA (o) and GAMMA (o). Note that GAMMA is included per timeslot.
(m) mandatory parameter
(o) optional parameter
(c) parameter is present under certain conditions
Note that Extended Dynamic Allocation makes only sense in case of multiple timeslots being
allocated. Extended Dynamic Allocation is mandatory only for mobile phones with multislot
classes 22, 24, 25, 27. It is an optional feature for the PCU.
151
GPRS
152
GPRS

(1) Operation of Extended Dynamic Allocation
The figure illustrates a typical example for the operation of the extended dynamic allocation
feature. In this case, a multislot class 12 mobile station has previously received an
allocation of TS 0, 1, 2 and 3 on a given ARFCN.
Following the rules of extended dynamic allocation, the mobile station is listening in block n to timeslots 0,
1, 2 and 3 in downlink direction. In example 1, the mobile station receives its own USF-value on timeslot
0 (note that the mobile station has to receive all parts of downlink block n on TS 0 before the USF-value
can be determined because of interleaving). Accordingly, the mobile station is allocated uplink radio
block n + 1 on TS 0 and all higher numbered timeslots which belong to the allocation (TS 1, 2 and 3).
In radio block n + 1 and according to the rules of extended dynamic allocation the mobile station only
needs to listen to TS 0 in downlink direction plus it shall transmit on TS 0, 1, 2 and 3.
Note that the time constraints Tta and Trb are met.
153
GPRS
Multislot Class 12 / PACK_UL_ASS [Ext_Dyn = yes, TS 0, 1, 2, 3]

Example 1: Allocation of TS 0,1,2,3 in Downlink Block n
Listen to USF no time to switch from

receive to transmit!
DL 0 1 2 3 4 5 6 7
UL 5 6 7 0TA 1 2 3 4
Transmit
SYS101_ch03_148
154
GPRS
Medium Access Control (MAC) Layer

The main function of the MAC layer is the control of multiple MSs sharing a common resource on the
GPRS air interface. The RLC data block is passed down to the MAC layer where a MAC header is added.
The format of the MAC header is dependent upon the direction of data transfer.
The fields in the MAC header are:-
USF - Uplink State Flag is used to indicate which MS is allocated

the GPRS resource.
S/P - Supplementary/Polling bit is used to indicate whether the
RRBP field is active.
RRBP - Relative Reserved Block Period is used to specify that a
single uplink block is being used as a Packet Associated
Control Channel (PACCH).
Payload Type - defines the type information in the payload area, that is
either data or signalling.
SI - Stall Indicator is used to signal whether the transmission
has stalled.
Countdown Value - is sent by the mobile (uplink) to the network so that it can
calculate the number of radio blocks remaining in the
current uplink allocation of resources.
R - Retry bit which indicates whether the MS transmitted the
Channel.
155
GPRS
Medium Access Control (MAC) Layer

Downlink RLC data block with MAC header
Bit
8 7 6 5 4 3 2 1
Payload Type RRBP S/P USF MAC header
PR TFI FBI Octet 1
BSN E Octet 2
Length indicator M E Octet 3 (optional)
. .
. .
. .
Length indicator M E Octet M (optional)
Octet M+1
.
RLC data .
.
Octet N-1
Octet N
spare spare (if present)
Uplink RLC data block with MAC header
Bit
8 7 6 5 4 3 2 1
Payload Type Countdown Value SI R MAC header
TFI TI Octet 1
BSN E Octet 2
Length indicator M E Octet 3 (optional)
. .
. .
. .
Length indicator M E Octet M (optional)
Octet M+1 \
Octet M+2 } (optional)
TLLI Octet M+3 /
Octet M+4 /
Octet M+5
.
.
RLC data .
Octet N-1
Octet N
spare spare (if present)
156
GPRS
Uplink Resource Release

Overview
Non-Extended TBF-Operation Mode
In non-extended TBF-operation mode, an uplink TBF will end at the earliest possible time,
once that all RLC-data blocks have been received correctly by the PCU.
Extended TBF-Operation Mode

In this operation mode, the PCU keeps the uplink TBF alive even after the countdown
procedure has counted down to CV = 0. The extended uplink TBF operation mode has
been provided to avoid the time-consuming new establishment of an uplink TBF shortly or
even immediately after another uplink TBF has been terminated.
Support for the extended TBF-operation mode in uplink direction is mandatory for the GPRS-mobile
station with 3GPP Release 4. The network indicates its support for this feature through the
parameter NW_EXT_UTBF which is part of the GPRS-Cell Options.
157
GPRS
Uplink Resource Release
158
GPRS
Downlink Resource Release

Options
Immediate Downlink TBF-Release
In this case, a downlink TBF is released immediately when the PCU has no more RLC-data
waiting in the output queue for that mobile station.
Delayed Downlink TBF-Release

In this case, the release of a downlink TBF is delayed when the PCU has no more RLC-data
waiting in the respective output queue. The PCU pretends to the mobile station that data still
are there by transmitting LLC-dummy frames with a wrong checksum.
159
GPRS
Downlink Resource Release
160
GPRS
GPRS Mobility Management State Diagram

Looking at the state diagram, it can be seen that the model is similar at both the Mobile
Station (MS) and the Serving GPRS Support Node (SGSN).
Idle to Ready
When moving from an Idle State to a Ready State a mobile must first perform a GPRS
Attach. If successful this will make the mobile known to the network, i.e. SGSN. If
unsuccessful the mobile will fall back to the Idle State.
Following the attach sequence a MM context is said to be active at the MS and the SGSN.
Once in the Ready State, a PDP context may be activated which allows the MS to establish
a packet data session with the associated packet data networks (PDNs). In particular this
will associate a PDN address within the MS and the GGSN.
With a valid PDP context it is possible to transfer Protocol Data Units (PDUs). Once the transmission
of PDUs has finished then a Ready Timer is started (which starts with a default value, but may be
changed by the SGSN). Both the MS and SGSN should be using the same value.
Whilst in this state the MS will perform both Cell and Routing Area updates.
Ready to Standby
A move from a Ready State to Standby State will follow the expiry of the Ready Timer
or a Force to Standby from an MS or SGSN.
Alternatively if a problem is encountered on the RLC/MAC interface, then the
MS could enter the Standby State.
Whilst in this state only Routing Area Updates will be performed.
Standby to Idle
Once in the Standby Stat e a second timer is started and when this expires or a MAP message,
Cancel Location is received from the HLR, then the return to the Idle State is performed
and the MM context are removed from the MS, SGSN, and GGSN.
Ready to Idle
Either a GPRS detach or a Cancel location would change the state from Ready to Idle and in doing so,
both MM and PDP contexts would be removed as the MS is no longer connected to the GPRS network.
Standby to Ready
Once there are PDUs to transmit/receive the MS and SGSN will enter the Ready State.
To enable this a PDP context must have been activated.
161
GPRS
GPRS Mobility Management State Diagram
Idle Idle
GPRS
GPRS GPRS
GPRS detach
attach attach
detach or cancel
location
Ready Ready
Standby
Standby timer
timer expiry
expiry or cancel Ready timer expiry or
Ready timer location
expiry or force to standby or
abnormal RLC PDU
force to PDU
condition reception
standby transmission
Standby Standby
162
GPRS
Mobile Identity
The P-TMSI and the TLLI
The TLLI (Temporary Logical Link Identifier) is actually no GMM-parameter. However, at least two
(Local-TLLI and Foreign-TLLI) of the four defined TLLIs are built from the P-TMSI. The TLLI is used
between mobile station and SGSN for the identification of the logical link (LLC-protocol). Note that at
any moment in time there may be only one logical link between a mobile station and the SGSN.
Local TLLI
The Local TLLI is an exact copy of the P-TMSI. The mobile station shall use the Local TLLI for
logical link identification only a) in the routing area where the related P-TMSI was allocated
(unless the procedure to be performed is a GPRS Attach) or b) after a routing area update
scenario in the new routing area when no new P-TMSI was allocated during the routing area
update scenario or c) for a periodic routing area update scenario.
Foreign TLLI
The mobile station shall use the Foreign TLLI only during GPRS Attachment
and for Routing Area Updating (not periodic).
Random TLLI
The Random TLLI is used by the mobile station during anonymous PDP context activation
or when no P-TMSI is currently available in the mobile station.
Note: TMSI and the LAI need to be stored on the SIM mandatorily .However, the storage of P-TMSI
and RAC on the SIM is optional and not possible for older SIM cards (< Phase 2+). Therefore the
mobile equipment (ME) needs to be able to store P-TMSI and RAC in a non-volatile memory. In this
case the mobile equipment needs to check upon every power on whether or not the old SIM is still in
use. If this check indicates a new SIM (IMSI-check) then the ME needs to erase the stored P-TMSI and
RAC.Accordingly, there are many instances when a mobile station has no P-TMSI available.
Auxiliary TLLI
The Auxiliary TLLI is allocated by the SGSN upon reception of an anonymous PDP context
activation request by the mobile station. The use of the Auxiliary TLLI shall avoid ambiguities of
Random TLLIs for anonymous PDP contexts in one SGSN area. (R97 only)
163
GPRS
Mobile Identity
Identity
GPRS
IMSI Network
P-TMSI
TLLI
MS TLLI
"
"
P-TMSI
TLLI
164
GPRS
Activity at the BSS

Data and signalling messages arrive at the BSS via the Gb interface and by using the Network
Service / Frame Relay. The frames arriving at the Packet Control Unit (PCU) pass through BSSGP
where the information and signalling messages are separated into LLC frames, GPRS Mobility
Management (GMM) information and Network Management (NM) information.
With regards to data and signalling messages destined for the GPRS MS, the LLC
frames pass through a Relay entity (LLC Relay) before entering the Radio Link Control
(RLC) and Medium Access Layer (MAC), respectively.
The RLC/MAC layer provides services for information transfer over the physical layer of the
GPRS interface. These functions include backward error correction procedures enabled by
selective retransmission of erroneous blocks of data. The MAC function arbitrates access to
the shared medium between a multitude of MSs and the GPRS network.
Radio Link Control (RLC) Layer

The RLC function is responsible for the transfer of PDUs from the LLC layer and the MAC function,
segmentation/re-assembly of LLC PDUs into/from RLC data blocks and backward error correction.
The RLC data block consists of an RLC Header, and RLC Data Field and spare bits. Each RLC
data block may be encoded using any of the available channel coding schemes CS-1, CS-2, CS-3
and CS-4 and as such, will effect the degree of segmentation and subsequent re-assembly. If the
contents of an LLC PDU do not fill an entire RLC data block, the beginning of the next LLC PDU
will be used to fill the remaining bit positions. However, if the LLC PDU was the last in the current
transmission block, the RLC data block will be completed by the insertion of spare bits.
The structure of the RLC Data Blocks are dependent upon the transmission
direction; i.e. Uplink or Downlink.
165
GPRS
Activity at the BSS

GPRS Application Protocols
IP/PPP IP/PPP
SMS SMS
GMM/SM GMM/SM
SNDCP SNDCP GTP GTP
Lower Layers
LLC LLC UDP UDP

Layer 2 Layer 2

BSC PCU SGSN GGSN

BTS
166
GPRS
Activity at the GPRS MS

At the GPRS MS, the PDUs pass through the protocol stack in the reverse order. The four
consecutive air interface bursts are re-assembled and passed to the RLC/MAC Layer. Once all the
RLC data blocks for a particular LLC PDU have been received, the LLC frame is re-assembled and
passed up to the LLC Layer. Here, the FCS is calculated and any re-transmissions are activated
if necessary, otherwise the payload area is passed up to the SNDCP layer.
167
GPRS
Activity at the GPRS MS
Application
IP/PPP PDU
SNDCP SNDCP Segmented PDU
LLC LLC SNDCP Segmented PDU FCS
Segmented / re-assembly
R
RLC L RLC DATA
C
R
MAC MAC L RLC DATA
C
GSM RF Burst Burst Burst Burst
114 bits 114 bits 114 bits 114 bits
168
GPRS
Applicability of the QoS-Profile

During the PDP-context activation process there is also the negotiation of the QoS-profile to be
used during this PDP-context. In any case, the mobile station will suggest a certain QoS-profile
by providing specific settings for each of the parameters but finally it is the SGSN and the GGSN
that have to confirm the suggested values or to provide different values.
Both GSNs will base their decision on the users subscribed QoS-profile which also represents the
maximum QoS available for one PDP Context of the user, and the current capabilities of the network.
All measurements related to the QoS-profile applicability are performed between the R-interface
at the mobile station and the Gi-interface on the network side. The GPRS/UMTS Bearer Service
parameters obviously also determine the QoS parameters for the Radio Access Bearer Service.
Note: There is no one-to-one relationship between the different parameters of the QoS-profile
on one hand and the TOS-field (Type of Service) in the IP-frames of the intra-PLMN
backbone on the other hand. Operators have to provide enough resources in the intra-PLMN
backbone so that overload in the backbone is unlikely to occur.
169
GPRS
Applicability of the QoS-Profile
R - Interface Gb - Interface Gi - Interface
BSS SGSN GGSN PDN
Radio Access Bearer Service
GPRS / UMTS Bearer Service
QoS Applicability
170
GPRS
The QoS Parameters in Release 99

Traffic Class
The Traffic Class in GPRS specifies the delay sensitivity of the service using the bearer.
By adding the Traffic Class as an parameter, the network can do assumptions about the
traffic source and optimize the transport for that traffic type.
Delivery Order
This attribute specifies whether out-of-sequence SDUs are acceptable or not. If out of sequence SDUs
can not be accepted, the SGSN / GGSN will perform reordering, before the SDUs are forwarded.
Delivery of erroneous SDU
This parameter decides whether erroneous SDUs shall be delivered to higher layer or rather
discard. Since in GPRS LLC will always discard frames which are considered as erroneous,
this parameter has influence on the error detection mechanism of LLC only.
Maximum SDU size
Gives the maximum size of an SDU for the PDP context. This parameter is used
for admission control and policing.
Maximum Bitrate (UL/DL)
Gives the maximum bitrate needed for the PDP Context. Uplink- and Downlink-data
rates are configured independently.
Residual BER (Bit Error Rate)
This parameter indicates the undetected bit error ratio in the delivered SDUs. It is used
to configure the parameters for the Radio Access Bearer Service.
SDU Error Ration
Is an result of the Residual BER. The parameter indicates the fraction of SDUs which
are received erroneous or lost completely.
Transfer Delay
As the name suggests, this parameter indicates the maximum for all delivered SDUs
during the lifetime of a bearer service, where delay for an SDU is defined as the time
from a request to transfer an SDU to its delivery.
Allocation / Retention Priority
Is used to specify the relative importance of a bearer compared to other bearers for
allocation and retention. The Allocation/Retention Priority attribute is a subscription
attribute which is not negotiated from the mobile terminal.
Traffic Handling Priority
The Traffic Handling Priority is a relative parameter, which gives the relative importance
of SDUs of a bearer compared to SDUs on other bearers. Since the Traffic Handling
Priority is a relative parameter, it can not be used together with absolute parameters
(Transfer Delay, Guaranteed Bitrate) on the same bearer.
Guaranteed Bitrate
As the name suggests this parameter gives the guaranteed bitrate as defined by the network. The
transfer delays and reliability parameters only apply to incoming traffic up to the guaranteed bitrate.
171
GPRS
The QoS Parameters in Release 99
Traffic Class
Guaranteed
Bitrate (UL/DL) Delivery Order
Traffic
Handling Delivery of
Priority erroneous SDU
Allocation / QoS
Retention Maximum
Priority Profile SDU size
Maximum
Transfer Delay Bitrate (UL/DL)
Residual
SDU error ratio
BER
172
Chapter 4
GPRS Signalling
173
GPRS
Objectives
Explain the GPRS MS Packet transfer procedure.
Explain the GPRS Attach/Detach signalling.
Explain the GPRS PDP Context activation procedure.
Explain the GPRS Network PDP Context activation procedure.
Explain the Allocation of the TEID during PDP-Context establishment
174
GPRS
Packet Transfer - MS Originated

An MS initiates a packet transfer by making a Packet Channel Request on PRACH or RACK The network
responds on PAGCH or AGCH respectively. It is possible to use one or two phase packet access method.
In the one phase access, the Packet Channel Request is responded by the network with the
Packet Immediate Assignment reserving the resources on PDCH(s) for uplink transfer of a number
of Radio blocks. The reservation is done accordingly to the information about the requested
resources that is comprised in the Packet Channel Request. On RACH, there is only one cause
value available for denoting GPRS and the network can assign uplink resources on 1 or 2
PDCHs. On PRACH, the Packet Channel Request may contain more adequate information
about the requested resources and, consequently, uplink resources on one or several PDCHs
can be assigned by using the Packet Immediate Assignment message.
In the two phase access, the Packet Channel Request is responded with the Packet Immediate
Assignment which reserves the uplink resources for transmitting the Packet Resource
Request. The Packet Resource Request message carries the complete description of the
requested resources for the uplink transfer. Thereafter, the network responds with the Packet
Resource Assignment reserving resources for the uplink transfer.
The Packet Immediate Assignment and the Packet Resource Assignment messages
include Timing Advance (TA) and Power Control (PC) information.
If there is no response to the Packet Channel Request within predefined time period,
the MS makes a retry after a random backoff time.
The Packet Uplink Assignment message includes the list of PDCHs and the corresponding USF value
for a particular MS. A unique TFI is also allocated and is included in each RLC data and control
block relating to that TBF. The MS monitors the USFs on the allocated PDCHs and transmits Radio
Blocks on those, which currently bear the USF value reserved for use by that particular MS.
Because each Radio Block includes an identifier (TFI), all received Radio Blocks are correctly
associated with a particular LLC frame and a particular MS, which makes the protocol highly
robust. Therefore, by altering the state of the USF, different PDCHs can be opened or closed
dynamically for certain MSs thus providing a flexible reservation mechanism.
The channel reservation algorithm can also be implemented on an assignment basis allowing
individual MSs to transmit for a predetermined amount of time without interruptions.
The MS may also be able to use the uplink resources for as long as there is queued data sitting
above on the RLC/MAC Layer. This can comprise of a number of LLC frames.
175
GPRS
Packet Transfer - MS Originated

The One-Phase and the Two-Phase Packet Access Procedure
One-Phase Packet Access Two-Phase Packet Access
PCU PCU
Phase 1
Access Messa Access Messa Phase 1
ge ge
tion Single on Multi Block

e Alloca Allocation
Resourc
Contention
Resolution:
Implicit PACK_RE
Data [TLL S _REQ
I]
llocation
ACK / NAC
K Resource A Phase 2
Contention
Resolution:
Data Explicit Data
Data Data
Data Data
176
GPRS
(1) GPRS Attach (new SGSN / NOM II / III MS Class A, B or C)

Initial Conditions
The network operates in NOM II or NOM III, the Mobile Station is Class A, B or C, The Mobile
Station has been powered on which triggers the Attach procedure, the SGSN has changed since
last power off and the former SGSN has in the meantime purged the Mobile Station.
Applicability of this Procedure

Mobile station class A, B or C is being powered on.
Mobile station class A, already involved in a circuit-switched transaction, wants to attach to GPRS.
Description
The mobile station will send an ATT_REQ-message to the SGSN and start T3310 ( 15s). If the
SGSN is unable to identify the mobile station ( P-TMSI unknown) it will request the GMM-context
of the mobile station from the former SGSN. The new SGSN will identify the former SGSN based
on the RAI that the mobile station has included in the ATT_REQ message.
If the former SGSN is inaccessible or doesnt know the mobile station either (e.g. the mobile
station has been purged by the former SGSN) the SGSN will retrieve the IMSI from the mobile
station by sending an IDENT_REQ]. Upon sending IDENT_REQ, the SGSN will start T3370 (
6 s). Accordingly the mobile station will respond by sending IDENT_RSP.
Based on the received IMSI in IDENT_RSP the SGSN will ask the HLR of the mobile
subscriber to provide authentication information.
177
GPRS
New Former
HLR
SGSN SGSN
T3310
= 15s Only if MS is unknown
in new SGSN
T3370 = 6s
to retrieve IMSI, if MS is also unknown in former SGSN
Only if Authentication
and/or Ciphering shall
be performed
178
GPRS

Description
The SGSN may initiate authentication of the mobile subscriber and / or ciphering by sending
an AUTH_CIPH_REQ -message to the mobile station and starting T3360 ( 6 s). If the
AUTN-parameter is included in the AUTH_CIPH_REQ message the MS will start T3316. The
mobile station will respond by sending AUTH_CIPH_RSP message.
If ciphering shall be started the SGSN needs to send an LLC-XID-frame to the mobile station which
includes the Input Offset Variable(s) for LLC-UI-frames ( IOV-UI) and / or LLC-I+S-frames ( IOV-I).
The mobile station confirms reception by returning and empty LLC-XID-frame (response).
Note that only after the transfer of IOV-UI / IOV-I the encryption of the respective frame
types is possible. However, if IOV-UI is conveyed to the mobile station then all the
consecutive GMM- and SM-messages can be ciphered.
If the EIR is equipped, the SGSN may retrieve the IMEI or IMEISV from the mobile station
by issuing another IDENT_REQ-message and start T3370 ( 6 s). Accordingly the mobile
station will provide its IMEI or IMEISV in an IDENT_RSP-message.
The IMEI or IMEISV, provided by the mobile station is sent to the EIR for approval. If the IMEI-check is
successful the procedure continues after the SGSN has received the END-message for IMEI-check.
179
GPRS
180
GPRS

Description
The SGSN needs to initiate the MAP updateGprsLocation procedure, because the mobile station may
still be registered in another SGSN. Accordingly the HLR will delete the entry of that mobile station in
the former SGSN (MAP cancelLocation-procedure if the mobile station hasnt been purged already).
Then the HLR will insert all relevant subscriber data into the SGSN by initiating
the MAP insertSubscriberData-procedure.
After this process is successfully completed the SGSN will send an ATT_ACC -message to the mobile
station and may start T3350 ( 6 s), if the SGSN expects the ATT_COM-message to be sent by
the mobile station. The mobile station will stop T3310 upon reception of ATT_ACC.
If the ATT_ACC-message contained a new value for T3314 0 ( Default = 44 s) and the Force to
Standby flag is not set, the mobile station will perform an initial cell update (either by transmitting any(*)
LLC frame except an LLC NULL frame or, if required, an ATT_COM message) in order to apply the new
READY timer value immediately. The ATT_COM message is only required, if a new P-TMSI and / or
TMSI is included in the ATT_ACC message in order to confirm the correct reception of the new identifier.
181
GPRS
New Former
SGSN SGSN
HLR
Only if SGSN has changed

MAP:B
EGIN/ U
pdateG
PRSLo
cation[2
3]
]
tion[3
ce lLoca
GIN/ can
P: BE
T3310
MA
MAP: END/
cancelLocation
[3]
riberData [7]
MAP: BEGIN / insertSubsc
MAP: END / insertSubs

criberData [7]
3]
MAP: END / UpdateGprsLocation[2
T_ACC
GMM: AT
T3350 = 6s
GMM: A
TT_CO
M
Only if ATT_ACC contained new TMSI and/or P-TMSI
or new T3314 value and Force to Standby is not set.
182
GPRS
(1) The GPRS Detach Procedure (Mobile Originating)

Initial Conditions
The network operates in any NOM, the Mobile Station is Class A, B or C. The Mobile
Station shall or shall not be powered off.

This procedure is applicable for all mobile originating GPRS-Detachments, possibly
combined with IMSI-Detachment.
Description
The mobile station shall initiate the detachment by sending DET_REQ to the SGSN. If the DET_REQ
does not indicate Power Off, the mobile station shall start T3321 ( 15 s).
If there is one or more PDP-context existing the SGSN shall inform the respective GGSN(s)
of the detachment by sending DEL_PDP_CT_REQ. The GGSN(s) will delete this (these)
PDP-context(s) and reply to the SGSN by sending DEL_PDP_CT_RSP .
If the network is in NOM I and the mobile station (class A or B) is both IMSI- and
GPRS-attached and wants to either detach from circuit-switched GSM only or from GPRS
and circuit-switched GSM, the SGSN shall send a BSSAP+-IMSI-DETACH-IND-message ]
to the serving MSC/VLR and start timer T9 ( 4 s (1 - 30 s)).
The serving MSC/VLR shall reply with the BSSAP+-IMSI-DETACH-ACK-message [.
183
GPRS
SGSN GGSN MSC VLR
only sent if a
PDP-context exists
T3321
T9 = 4s (1-30s)
Only sent in NOM 1 if

MS Class A/B performs
and IMSI-Detach or a
combined IMSI/GPRS
Detach
184
GPRS

Description
Otherwise, if the network is in NOM I and the mobile station (class A or B) is both IMSI-
and GPRS-attached and wants to detach from GPRS only, the SGSN shall send a
BSSAP+-GPRS-DETACH-IND -message to the serving MSC/VLR and start T8 ( 4s (1 - 30 s)).
The serving MSC/VLR shall reply with the BSSAP+-GPRS-DETACH-ACK-message.
If the detach is not due to power off, the SGSN shall send DET_ACC to the mobile station.
After an operator determined time period the SGSN may purge the detached mobile station
towards the HLR by initiating the MAP purgeMS-procedure.
185
GPRS
SGSN GGSN MSC VLR
T8 = 4s (1-30s)
Only sent in NOM 1 if

MS Class A/B performs
a GPRS-Detach only. In
that case, the VLR is from
now on responsible for
T3321
CS-Paging
HLR
Time between Detachment
and Purge MS is adjustable
by the operator.
Only sent if Detach is not due the Power Off
186
GPRS
(1) The GPRS Detach Procedure (SGSN Originating)

Initial Conditions
The network operates in any NOM, the Mobile Station is Class A, B or C and may or may
not be attached to circuit-switched and packet-switched services.

This procedure is applicable for all mobile terminating GPRS-Detachments, possibly
combined with IMSI-Detachment.
The SGSN will initiate the detachment of a particular mobile station for either GPRS
and / or circuit-switched GSM ( only in NOM I) for instance when a mobile
station is not allowed to roam in this area.
Another example is only applicable to NOM I: After VLR failure the SGSN needs to initiate
re-attachments of all mobile stations class A and B that are both IMSI- and GPRS-attached
to re-synchronize the mobile stations with the network. To do so, the SGSN will send
DET_REQ-messages to these mobile stations (indicating that re-attach is required).
Description
The SGSN shall initiate the detachment by sending DET_REQto the mobile station. The
SGSN shall start T3322 ( 6 s). Note that the Detach Type information element may indicate
that the mobile station shall immediately re-attach to the SGSN.
of the detachment by sending DEL_PDP_CT_REQ message.
The GGSN(s) will delete this (these) PDP-context(s) and reply to the SGSN
by sending DEL_PDP_CT_RSP.
If the network is in NOM I and the mobile station (class A or B) is both IMSI- and GPRS-attached and
shall be detached from GPRS only, the SGSN shall send a BSSAP+-GPRS-DETACH-IND-message
to the serving MSC/VLR and start timer T8 ( 4s (1 - 30 s)).
The serving MSC/VLR shall reply with the BSSAP+-GPRS-DETACH-ACK-message . From
now on the MSC/VLR wont forward circuit-switched paging for that mobile station to the
SGSN for further processing but operate autonomously.
187
GPRS
SGSN GGSN MSC VLR

T3322=6s only sent if a
PDP-context exists
T8 = 4s (1-30s)
Only sent in NOM 1if

SGSN performs a
GPRS-Detach only.
In that case, the VLR is
from now on responsible
for Cs-Paging for MS
Class A/B
188
GPRS

Description
Finally, the mobile station shall send DET_ACC to the SGSN.
After an operator determined time period the SGSN may purge the detached mobile station
towards the HLR by initiating the MAP purgeMS-procedure.
189
GPRS
SGSN GGSN HLR
T3322
Time between Detachment

and Purge MS is adjestable
by the operator
190
GPRS
(1) The GPRS Detach Procedure (HLR Originating)

Initial Conditions
The network operates in any NOM, the Mobile Station is Class A, B or C and may or may
not be attached to circuit-switched and packet-switched services. The HLR needs to delete a
subscribers information in the SGSN (e.g. Subscription Withdrawn).

This procedure is only applicable for Detachments that are due to operator determined
deletions of subscribers GMM- and PDP-contexts.
Description
The HLR shall initiate the detachment of a mobile station by sending the MAP cancelLocation-message
(Cause value: subscription withdrawn) to the SGSN. The SGSN shall initiate the detachment by
sending DET_REQ to the mobile station. The SGSN shall start T3322 ( 6 s).
of the detachment by sending DEL_PDP_CT_REQ. The GGSN(s) will delete this (these)
PDP-context(s) and reply to the SGSN by sending DEL_PDP_CT_RSP.
191
GPRS
SGSN GGSN HLR
T3322 = 6s [3]
lLocation
IN / cance
MAP: BEG
T_REQ
GMM: DE
only sent if a PDP

Context exists
GTP: DE
L_PDP_C
T_REQ
T_RSP
L_PDP_C
GTP: DE
192
GPRS

Description
If the network is in NOM I and the mobile station (class A or B) is both IMSI- and GPRS-attached and
shall be detached from GPRS only, the SGSN shall send a BSSAP+-GPRS-DETACH-IND-message
to the serving MSC/VLR and start timer T8 ( 4s (1 - 30 s)).
The serving MSC/VLR shall reply with the BSSAP+-GPRS-DETACH-ACK-message. From
now on the MSC/VLR wont forward circuit-switched paging for that mobile station to the
SGSN for further processing but operate autonomously.
The mobile station shall confirm the detachment by sending the DET_ACC-message at any time.
The procedure ends with the SGSN returning the MAP cancelLocation-message to the HLR.
193
GPRS
SGSN GGSN VLR

MSC
T3322
T8 = 4 s (1-30s)
Only set in NOM 1 if MS
Class A/B remains IMSI
Attached after HLR
iniciated GPRS Detach.
In that case the VLR is
from now on responsible
for CS-Paging
194
GPRS
PDP Context Activation

(1) The Mobile Originating PDP-Context Activation Procedure
Initial Conditions
The mobile station is of any class A, B or C and has already established a
GMM-context ( GPRS-attached).

This procedure is applicable for all mobile originating PDP-context activation with PDP-type
IP, in particular with dynamic IP-address allocation
Description
The terminal equipment (e.g. laptop) first needs to define the
PDP-context to be established through the transfer of the AT-command
+CGDCONT . The mobile station shall confirm the reception of this AT-command.
Optionally, the terminal equipment may specify a specific QoS-profile to be requested for this
PDP-context. In this case, the terminal equipment shall send another AT-command to the mobile
station. The mobile station shall confirm the reception of this AT-command.
To initiate the PDP-context activation procedure, the terminal equipment will send another
AT-command to the mobile station. The mobile station shall confirm the reception of this
AT-command and start the PDP-context activation procedure.
After the dial command, the PPP (Point-to-Point Protocol) will establish a layer 2 connection
between terminal equipment and mobile station. This is done through the PPP LCP (Link Control
Protocol). In addition, terminal equipment and mobile station shall negotiate a PPP authentication
protocol (either CHAP or PAP with preference on CHAP), if user authentication to the PDN and
/ or between the terminal equipment and the mobile station is required.
195
GPRS
SGSN GGSN
Radius
AT +CGD
CONT PDP-Context Definition
OK
If Rel. 98 QoS
Parameters
are requested
AT +CGQ
REQ
If Rel. 99 QoS
Parameters
are requested If TE requests specific
AT +CGE
QREQ QoS profile
OK
ATD *99#
Connect
PPP/LCP: Link
Discussion
Authentication
PPP/CHAP: PAP Provision of Protocol

Authentification Configuration Options
196
GPRS

Description
Finally, the terminal equipment will convey an IPCP CONFIGURE REQUEST-message to the mobile
station which most likely tells the mobile station that a dynamic PDP-address is required. In this
case, the IP-address in the IPCP CONFIGURE REQUEST is set 00 00 00 00hex.
The mobile station will start the PDP-context activation procedure through the transmission of an
ACT_PDP_CT_REQ-message. The information element Protocol Configuration Options may contain
PPP-information (e.g. for PAP, CHAP, LCP or IPCP). The mobile station will start timer T3380 = 30 s.
The SGSN will evaluate the ACT_PDP_CT_REQ-message and select a suitable GGSN,
based on the APN provided by the mobile station and / or the subscription options of the
mobile station. Consequently, the SGSN will transmit a CT_PDP_CT_REQ-message to this
GGSN. Note that the SGSN may have altered the requested QoS-profile, if it did not match
the capabilities of the SGSN and / or the subscribed QoS-profile.
The GGSN will evaluate the CT_PDP_CT_REQ-message and may then authenticate the mobile station
through a RADIUS-server, using the information provided through the protocol configuration options.
For dynamic IP-address allocation the GGSN may either use RADIUS (which in turn may
request the allocation from a DHCP-server) or DHCP. In the latter case, the GGSN will send
UDP/IP: DHCPDISCOVER messages to several DHCP-servers. Some of these servers will
offer their service by responding with UDP/IP: DHCPOFFER-messages.
197
GPRS
SGSN GGSN
Radius
Only for Authentication

PPP/IPCP
: CONFIGU
REQUEST RE
ACT_PDP
_CT_REQ
GTP: CT_P
DP_CT_REQ
UDP/IP: R
Access-R ADIUS:
equest
Provision of Protocol
Configuration Options
T3380 = 30s DIUS:
UDP/IP: RAAccept
Start Access-
Broadcast
DHCP
DHCP
UDP/IP: DHCP
DHCPDIS
COVER
DHCP is used for
IP-address allocation
DHCP
DHCP
DHCP
UDP/IP: ER
F
DHCPOF
198
GPRS

Description
The GGSN will select one DHCP-server to provide an IP-address by sending a UDP/IP:
DHCPREQUEST-message to this server. Finally, this server will provide an IP-address to the GGSN
by sending a UDP/IP: DHCPACK-message back to the GGSN. This address is the dynamic and
(possibly) public IP-address which the mobile station / terminal equipment shall use.
The GGSN will include this IP-address into the CT_PDP_CT_RSP-message and transmit it to the SGSN.
Finally, the SGSN will confirm PDP-context activation by sending a ACT_PDP_CT_ACC-message to
the mobile station. Upon reception of this message the mobile station shall stop T3380.
The mobile station will convey the received dynamic IP-address in an IPCP CONFIGURE
ACK-message to the terminal equipment.
Now, the terminal equipment is able to exchange IP-frames over PPP with the external PDN.
199
GPRS
SGSN GGSN
Radius
T3380
UDP/IP: D
HCPREQU
EST
K
UDP/IP: DHCPAC
RSP
GTP: CT_PDP_CT_
ACT_PDP_CT_ACC
PPP/IPCP:ACK Internet/
E
CONFIGUR
Intranet
Provision of
IP-Address
Transfer of IP-Frames
200
GPRS
Secondary PDP Context Activation

(1) The Secondary PDP Context Activation Procedure
Initial Conditions
The mobile station is of any class A, B or C and has already established a GMM-context (
GPRS-attached) and has at least one active PDP context. The PDP context to be established will
use IP or IP over PP and header compression on application layer is not activated.

The purpose of this procedure is to establish an additional PDP context between the MS
and the network for a particular PDP Address with a different QoS.. This requires that one
or more PDP contexts has/have already been established for the particular PDP address in
the MS. In order to support for different QoSs between the SGSN and the GGSN the Traffic
Flow Template (TFT) is introduced. The MS shall include a request for a TFT if a PDP context
without a TFT is presently active, for the particular PDP address.
Description
The terminal equipment (e.g. laptop) first needs to define the Secondary
PDP-context to be established through the transfer of the AT-command
+CGDSCONT . The mobile station shall confirm the reception of this AT-command.
If there is one PDP-context without a TFT, the +CGDTFT is sent to the MS in order to activate a traffic
flow template which allows to support for different QoSs in the GGSN in downlink direction.
The terminal equipment may specify a specific QoS-profile to be requested for this PDP-context.
In this case, the terminal equipment shall send another AT-command to the mobile station.
The mobile station shall confirm the reception of this AT-command.
To initiate the PDP-context activation procedure, the terminal equipment will send another AT-command
to the mobile station. The mobile station shall confirm the reception of this AT-command and start the
PDP-context activation procedure. If the PDP-context identifier of the PDP context to be activated shall
be included then the command will be ATD *99**x# with x = cid in the +CGDSCONT command.
201
GPRS
Internet/
Intranet
SGSN GGSN
Secondary
AT +CGD PDP-Context Definition
SCONT
OK
Traffic Flow
AT +CGT Template Definition
F T
OK
QoS Request
AT +CGQ
R EQ
OK
ATD *99#
Connect
202
GPRS

(2) The Secondary PDP Context Activation Procedure
Description
After the dial command, the PPP (Point-to-Point Protocol) will establish a layer 2 connection
between terminal equipment and mobile station. This is done through the PPP LCP (Link Control
Protocol). In addition, terminal equipment and mobile station shall negotiate a PPP authentication
protocol (either CHAP or PAP with preference on CHAP), if user authentication to the PDN and
/ or between the terminal equipment and the mobile station is required.
Finally, the terminal equipment will convey an IPCP CONFIGURE
REQUEST-message to the mobile station.
The mobile station will start the PDP-context activation procedure through the transmission of an
ACT_SEC_PDP_CT_REQ-message . The mobile station will start timer T3380 = 30 s.
The SGSN will evaluate the ACT_SEC_PDP_CT_REQ-message and select a suitable GGSN, based
on the Linked Transaction Identifier (TI) provided by the mobile station. Consequently, the SGSN will
transmit a CT_PDP_CT_REQ-message to this GGSN. Note that the SGSN may have altered the
requested QoS-profile, if it did not match the capabilities of the SGSN and / or the subscribed QoS-profile.
The GGSN will transmit the CT_PDP_CT_RSP-message to the SGSN.
Finally, the SGSN will confirm PDP-context activation by sending a ACT_SEC_PDP_CT_ACC to
The mobile station will indicate the successful PDP context activation by conveying an
IPCP CONFIGURE ACK-message to the terminal equipment.
203
GPRS
Internet/
Intranet
SGSN GGSN
PPP/LCP: Link
Discussion
PPP/CHAP/PAP Authentication
Authentification
PPP/IPCP
: CONFIGU
REQUEST RE
ACT_SEC
_PDP_CT_R
EQ
GTP: CT_P
D P_CT_REQ
T3380 = 30s
_RSP
GTP:CT_PDP_CT
_ACC
PPP/IPCP: ACT_SEC_PDP_CT
CONFIGURE ACK
204
GPRS
Network-Requested PDP Context Activation

(1) The Mobile Terminating PDP-Context Activation Procedure
Initial Conditions
The mobile station is of any class A, B or C and has already established a GMM-context (
GPRS-attached). No PDP-context of type IP is established and the GGSN is receiving IP-frames
for that mobile station. The terminal equipment has previously setup the mobile station to
either automatic answering mode (ATS0 = 1) or not. In the latter case, manual interaction is
required to confirm the establishment of the respective PDP-context.
Note that the mobile station requires a static and public IP-address to allow for mobile terminating
PDP-context activation. Otherwise, the HLR has no means to obtain information about the HLR
of that subscriber (which needs to be obtained through some sort of DNS-server).

This procedure is applicable for all mobile terminating PDP-context activation with PDP-type IP.
Description
The GGSN receives IP-frames for a specific mobile station. The mobile station is identified
by its static IP-address. If the GGSN does not have a Gc-interface, it needs to send a
SEND_ROUT_INFO_FOR_GPRS_REQ-message to a GSN ( SGSN or GGSN) with GTP
MAP conversion capability. This GSN will forward the GGSNs request to the HLR (MAP
sendRoutingInfoForGprs-procedure) of the requested subscriber to obtain information about
the SGSN that currently serves the subscriber. If the GGSN does have a Gc-interface, it
will directly contact the HLR through the indicated MAP-procedure.
If the subscriber is not detached from GPRS, the HLR will convey a positive response to the requesting
GSN which will relay it back to the GGSN within a SEND_ROUT_INFO_FOR_GPRS_RSP-message .
205
GPRS
SGSN or GGSN with Internet

GTP MAP Converting Capability
HLR GSN GGSN
IP-Frames for
n
Mobile Statio
FO
_ROUT_IN Only if no Gc-Interface
GTP:SEND PRS_REQ
/ send O R _G is equipped in this GGSN
MAP: BEGIN prs [24] _F
orG
RoutingInfoF
MAP: EN GTP:SEN
RoutingInfoFD / send D_R
orGprs [24] _FOR_GP OUT_INFO
RS_RSP
206
GPRS

Description
Now the GGSN can send a PDU_NOT_REQ-message to the SGSN that currently serves
the subscriber to initiate the PDP-context activation procedure.
If the SGSN is able to locate the mobile station and if no other restrictions (e.g. no roaming allowed)
apply, the SGSN shall send a REQ_PDP_CT_ACT-message to the mobile station, start timer
T3385 ( 8 s) and reply to the GGSN by sending a PDU_NOT_RSP-message.
Note that in the presented case the terminal equipment has previously configured the mobile station
to automatic answering: ATS0 = 1. Otherwise user interaction is required when the mobile station
receives the REQ_PDP_CT_ACT-message which will send a "RING" to the terminal equipment. In
the presented case the terminal equipment automatically responds with "CONNECT".
Consecutively, the PPP (Point-to-Point Protocol) will establish a layer 2 connection between terminal
equipment and mobile station. This is done through the PPP LCP (Link Control Protocol).
In addition, terminal equipment and mobile station shall negotiate a PPP authentication protocol
(either CHAP or PAP with preference on CHAP), if user authentication to the PDN and / or
between the terminal equipment and the mobile station is required.
207
GPRS
Internet
SGSN GGSN
Automatic answering
enabled
ATSO =
1
Q
GTP: PDU_NOT_RE
REQ_PDP_CT_ACT
RING
GTP: PDU
_NOT_RSP
CONNECT
T3385 = 8 s
PPP/LCP:
Link Discussion
Authentication
PPP/CHAP/PAP:
Authentification
208
GPRS

Description
Finally, the terminal equipment will convey an IPCP CONFIGURE REQUEST-message to the mobile
station which includes the offered IP-address from the REQ_PDP_CT_ACT message.
The mobile station will now start the mobile originating PDP-context activation procedure through
the transmission of an ACT_PDP_CT_REQ-message. The mobile station will start timer
T3380 = 30 s. On the other hand, the SGSN will stop timer T3385.
The SGSN will evaluate the ACT_PDP_CT_REQ-message and confirm that the APN provided
by the mobile station matches the respective GGSN. Consequently, the SGSN will transmit a
CT_PDP_CT_REQ-message to this GGSN. Note that the SGSN may have altered the requested
QoS-profile, if it did not match the capabilities of the SGSN and / or the subscribed QoS-profile.
The GGSN will evaluate the CT_PDP_CT_REQ-message and may then authenticate the mobile station
through a RADIUS-server, using the information provided through the protocol configuration options.
The GGSN will send a CT_PDP_CT_RSP- CT_PDP_CT_RSP-message and transmit it to the SGSN.
Finally, the SGSN will confirm PDP-context activation by sending a ACT_PDP_CT_ACC-message to
The mobile station will confirm the IP link setup by sending an IPCP CONFIGURE
ACK-message to the terminal equipment.
209
GPRS
SGSN GGSN
Radius
T3385 = 8 s
PPP/IPCP
CONFIGU :
RE_REQ UEST ACT_PDP
_CT_REQ
GTP: CT_P
D P_CT_REQ
UDP/IP: R
Access-R ADIUS:
T3380 = 30 s equest
Authentication
DIUS:
UDP/IP: RAccept
Access-A
RSP
GTP: CT_PDP_CT_
ACT_PDP_CT_ACC
PPP/IPCP:
CONFIGURE_ACK
Internet
210
GPRS
Allocation of the TEID during PDP-Context establishment

Initial Conditions
The MS may, or may not, have one or more already activated PDP-contexts.

This procedure is applicable for a MS establishing a(n) (additional) PDP-Context. This
PDP-Context can either have an own IP-address, or be established using the secondary
PDP-Context activation ( Session Management) procedure.
Description
The SGSN sends a CT_PDP_CT_REQ message to the GGSN, which is identified on the lower layer by
its IP address (mapping of APN IP address). The TEID in the header of the GTP-C message is set to
"0" since the TEID for the tunnel is not known yet by the SGSN. Further this message includes the TEIDs
for both, the GTP-C and GTP-U tunnel, which the GGSN shall use when communicating with the SGSN.
The GGSN includes in the header of the CT_PDP_CT_RESP message the TEID the SGSN has
chosen for the GTP-C tunnel. Further the GGSN informs the SGSN, which TEIDs to use for
the GTP-U and the GTP-C tunnel when sending data/signaling to the GGSN.
Both, the SGSN and the GGSN will use the allocated TEIDs for all data and control procedures
on the involved GTP-C- and GTP-U tunnels for each PDP-context.
211
GPRS
Allocation of the TEID during PDP-Context establishment
SGSN GGSN
SM: ACT_PD
P_CT_REQ
(APN)
Mapping of
APN IP Address
of GGSN
GTP-C: CT_P
Header TEID DP_CT_REQ
= "0" / TEID-D
(SGSN) / TEID
-C(SGS N)
DP_CT_RSP GSN)
GTP-C: CT_P N) / TEID-C(G
C( SG SN )" / TEID-D(GGS
ID = "T EI D-
Header TE
P_CT_RSP
SM: ACT_PD
GTP-U: G-PD
Header TEID U
= "TEID-D(GG
SN)"
U
GTP-U: G-PD
ID = "T EI D- D(SGSN)"
Header TE
SM: DEACT_
PDP_CT_REQ
GTP-C: DEL_
PDP_CT_REQ
Header TEID
= "TEID-C(GG
SN)"
PDP_CT_RSP
GTP-C: DEL_ )"
= "TEID-C(SGSN
Header TEID
PDP_CT_ACC
SM: DEACT_
212
GPRS
PDP-Context Deactivation - Mobile Originating

Initial Conditions
The mobile station is of any class A, B or C and has activated one or more
PDP-contexts of which one shall be deactivated.

This procedure is applicable for all mobile originating PDP-context deactivation procedures
with PDP-type IP, in particular with dynamic IP-address allocation
Description
The terminal equipment (e.g. laptop) will initiate the PDP-context deactivation by initiating
a tear-down of the PPP-link towards the mobile station. A graceful shutdown is achieved
through the transfer of a PPP LCP TERMINATE REQUEST-frame.
Consequentially, the mobile station will transmit a DEACT_PDP_CT_REQ-message to the SGSN.
The PDP-context to be deactivated is identified by means of the transaction identifier. The Tear down
indicator indicates whether all PDP contexts with the same IP Address shall be terminated or only
the one indicated in the TI. In addition, the mobile station will start timer T3390 = 8 s.
The SGSN will forward the request of the mobile station to the GGSN through the
transfer of a DEL_PDP_CT_REQ-message.
If a dynamic IP-address is linked to this PDP-context, the GGSN will release this dynamic IP-address
through the transfer of a UDP/IP: DHCPRELEASE-message to the DHCP-server.
The GGSN will confirm the deactivation of the PDP-context by sending a
DEL_PDP_CT_RSP to the SGSN.
Note: Between the SGSN and the GGSN, the PDP-context is identified through the TEID (Tunnel
Endpoint Identifier Data) and the NSAPI. Between mobile station and SGSN, different PDP-contexts
are distinguished by means of the transaction identifier (TI). The NSAPI in the DEL_PDP_CT_REQ
message indicates to the GGSN which PDP context shall be deactivated if there are more than one
PDP contexts per TEID. The Tear Down Indicator indicates whether all PDP-Contexts with the same
PDP-Address shall be deleted or only the one identified by the TEID and the NSAPI.
The SGSN will confirm the deactivation of the PDP-context by sending a
DEACT_PDP_CT_ACC-message to the mobile station. Finally the mobile station can
confirm the initial PPP LCP TERMINATE REQUEST-frame by sending a PPP LCP
TERMINATE ACK-frame to the terminal equipment.
213
GPRS
PDP-Context Deactivation - Mobile Originating
SGSN GGSN
DHCP
PP
TERMINATP/LCP:
E REQUES
T DEACT_P
DP_CT_RE
Q GTP: DEL_
PDP_CT_RE
Q UDP/IP: D
HCPRELE
ASE
T3390 = 30 s
_RSP
GTP: DEL_PDP_CT
CC
DEACT_PDP_CT_A
PPP/LCP:
TERMINATE_ACK
214
GPRS
PDP-Context Deactivation - SGSN Originating

Initial Conditions
The mobile station is of any class A, B or C and has activated one or more PDP-contexts
of which one shall be deactivated by the SGSN.

This procedure is applicable for all SGSN originating PDP-context deactivation procedures
Description
The SGSN will send a DEL_PDP_CT_REQ-message to the GGSN. Without waiting for the
reply from the GGSN, the SGSN may already send a DEACT_PDP_CT_REQ-message
to the mobile station and start timer T3395 = 8 s.
The mobile station will indicate the PDP-context deactivation to the terminal equipment
by initiating a tear-down of the PPP-link. A graceful shutdown is achieved through the
transfer of a PPP LCP TERMINATE REQUEST-frame.
The terminal equipment may confirm the tear-down by sending a PPP LCP
TERMINATE ACK-frame to the mobile station.
The mobile station will confirm the deactivation of the PDP-context by sending a
DEACT_PDP_CT_ACC-messageto the SGSN. The SGSN will stop T3395 upon
reception of DEACT_PDP_CT_ACC.
In the meantime the GGSN has initiated the release of the dynamic IP-address through the
transfer of a UDP/IP: DHCPRELEASE-message to the DHCP-server.
In addition the GGSN will confirm the deactivation of the PDP-context by sending
a DEL_PDP_CT_RSP to the SGSN.
215
GPRS
PDP-Context Deactivation - SGSN Originating
SGSN GGSN
DHCP
GTP: DEL_
PDP_CT_RE
Q UDP/IP: D
HCPRELE
ASE
EQ
PPP/LCP: DEACT_PDP_CT_R
UEST
TERMINATE_REQ
T3395 = 8 s GTP: DEL_PDP_CT

_RSP
PPP/L
TERMINATCP:
E ACK
DEACT_P
DP_CT_AC
C
216
GPRS
PDP-Context Deactivation - GGSN Originating

Initial Conditions
The mobile station is of any class A, B or C and has activated one or more PDP-contexts
of which one shall be deactivated by the GGSN.

This procedure is applicable for all GGSN originating PDP-context deactivation procedures
Description
The GGSN will send a DEL_PDP_CT_REQ-message .to the SGSN.
The SGSN shall send a DEACT_PDP_CT_REQ-message to the mobile station
and start timer T3395 = 8 s.
The mobile station will indicate the PDP-context deactivation to the terminal equipment
by initiating a tear-down of the PPP-link. A graceful shutdown is achieved through the
transfer of a PPP-LCP TERMINATE REQUEST-frame.
The terminal equipment may confirm the tear-down by sending a PPP LCP
TERMINATE ACK-frame to the mobile station.
The mobile station will confirm the deactivation of the PDP-context by sending
a DEACT_PDP_CT_ACC-message to the SGSN. The SGSN will stop T3395
upon reception of DEACT_PDP_CT_ACC.
The SGSN will confirm the deactivation of the PDP-context by sending a
DEL_PDP_CT_RSPto the GGSN.
Finally, the GGSN has initiated the release of the dynamic IP-address through the transfer
of a UDP/IP: DHCPRELEASE-message to the DHCP-server.
217
GPRS
PDP-Context Deactivation - GGSN Originating
SGSN GGSN
DHCP
_REQ
EQ GTP: DEL_PDP_CT
PPP/LCP: DEACT_PDP_CT_R
UEST
TERMINATE_REQ
T3395 = 8 s
PPP/L
TERMINATCP:
E ACK
DEACT_P
DP_CT_AC
C GTP: DEL_
PDP_CT_RS
P
UDP/IP: D
HCPRELE
ASE
218

Ii GPRS

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ii GPRS

Enviado por

Direitos autorais:

Formatos disponíveis

Introduction to GPRS

Circuit and Packet Switching

Circuit and Packet Switching

Circuit Switching Packet Switching

A complete resource allocated Devices share the available

Its All Mine!

Which exit did you say?

Physical L1 Physical Physical Physical Physical

Datagrams and Virtual Circuits

Permanent Virtual Circuit (PVC)

Datagrams and Virtual Circuits

Routing Table - PSE1

The Interconnection of the Various Network Elements

Interfaces within the BSS and towards the NSS

The Interconnection of the Various Network Elements

VLR C-Interface VLR

Introducing the GPRS Network Architecture

SGSN (Serving GPRS Support Node)

GGSN (Gateway GPRS Support Node)

Introducing the GPRS Network Architecture

(1) Tasks and Functions of the PCU

(1) Tasks and Functions of the PCU

(2) Tasks and Functions of the PCU

(2) Tasks and Functions of the PCU

Responsibility for RLC/MAC

(1) Tasks and Functions of the SGSN

(1) Tasks and Functions of the SGSN

Routing of Data Packets between the GGSN

(2) Tasks and Functions of the SGSN

(2) Tasks and Functions of the SGSN

(3) Tasks and Functions of the SGSN

(3) Tasks and Functions of the SGSN

SGSN GGSN Packet Data Network

(4) Tasks and Functions of the SGSN

(4) Tasks and Functions of the SGSN

BSS SGSN GGSN

(5) Tasks and Functions of the SGSN

(5) Tasks and Functions of the SGSN

(6) Tasks and Functions of the SGSN

(6) Tasks and Functions of the SGSN

(7) Tasks and Functions of the SGSN

(7) Tasks and Functions of the SGSN

Header Compression ( RFC 1144 and RFC 2507)

Header Compression (RFC 1144 and RFC 2507)

Data TCP/IP Data Data TCP/IP

(1) Tasks and Functions of the GGSN

(1) Tasks and Functions of the GGSN

Interface between the PLMN

Packet Packet Packet

(2) Tasks and Functions of the GGSN

(2) Tasks and Functions of the GGSN

(3) Tasks and Functions of the GGSN

(3) Tasks and Functions of the GGSN

Charging (foreign network resources)

There are Different Types of GGSNs

GGSN Type A (Transparent Access)

GGSN Type B (Non-Transparent Access)

GGSN Type C (Corpoate GGSN)

There are Different Types of GGSNs

Tasks and Functions of the BG

Tasks and Functions of the BG

Interface for Packet Data Transmission between PLMNs

(1) The Mobile Station in GPRS