. 31
( 132 .)


The IP packet is now transported to the mobile station using a number of LLC layer
packets. Between the SGSN and the BSC, the LLC is itself carried over a frame relay
network. At the BSC the LLC packets are extracted from the frame relay packets and
transported to the correct BTS, usually over the TDM slots of an E1 or T1 line. The
BSC will segment the LLC frames into a number of smaller RLC/MAC frames. These
will be transported via the BTS to the mobile device, where they will be grouped to
reconstruct the original LLC frame. Once the BTS has received the RLC/MAC frames, it
then transmits them across the air interface to the mobile device. When the LLC packets


GPRS Backbone


Station GTP HDR IP Get Page Reply IP Get Page Reply

Figure 4.42 IP transport across GPRS infrastructure

arrive at the mobile device, the IP packet is reassembled, and processed by the application
on the device.
A mobile device may have a number of PDP contexts active at any one time. These
may or may not be to the same GGSN, but are given separate tunnel identities, and
the mobile device will have a number of addresses associated with it, for example IP
addresses. It will have one address for each primary PDP context activated. When a PDP
context exists and another context is de¬ned which uses the same address, and possibly
some of the same context information, this is referred to as a secondary context. The
secondary PDP context procedure can be used to make an alternative connection to an
already active context but with different QoS. The PDP address and other PDP context
information already established are reused. Since an access point must have been de¬ned
for the primary context, procedures for access point name (APN) selection and PDP
address negotiation are not executed. The secondary PDP context will use the same IP
address as the primary context; it will be identi¬ed through a unique transaction identi¬er
and its own NSAPI. As an example, consider a videoconferencing application. This can
consist of a video stream and a whiteboarding application. Here, the video traf¬c presents
quite stringent QoS requirements, whereas the whiteboarding is non-real-time and thus
has looser QoS demands, since it can tolerate delays.
Figure 4.43 illustrates the procedures for a mobile-originated PDP context activation.

1. The mobile device sends the PDP request, which contains the NSAPI, PDP type, PDP
address, APN, QoS requirements and any PDP con¬guration options. The NSAPI
identi¬es the service access point in the mobile device, which will be dealing with
this speci¬c PDP context. The PDP type indicates if this is an X.25 or IP connection6
and the PDP address indicates the actual address. In the case of IP this will be an IP
address for the mobile device. If the mobile device does not have a static IP address


Activate PDP Context Request

Security Functions 2
Create PDP Context Request
Create PDP context Reponse
BSS Packet Flow
Context Procedures
Activate PDP Context Response

Figure 4.43 UE-originated PDP context activation

X.25 was originally supported in GTP version 0 but has been removed from GTP version 1.
It has been replaced with PPP, which can carry many types of protocol transparently.

then this ¬eld will consist of and the GGSN will allocate the IP address. It
practical situations it is more common that dynamic addresses are allocated since this
provides greater ¬‚exibility. The APN, described in Section 4.9.4, is the mobile
operator™s external connection point. This is a text name and has local signi¬cance
only. Examples of this could be Internet, Corporation-1 etc. Each PDP context may
have a different QoS requirement; perhaps higher QoS may mean that the subscriber
has to pay a premium price. The options ¬eld is transparently transported through the
SGSN to the GGSN where optional parameters may be implemented.
2. Once the SGSN has received the request it will most likely invoke the security
procedures to authenticate the mobile subscriber and device. These are very similar
to the GSM security procedures. The SGSN will validate the subscriber™s request
with those permitted through the subscription records in the HLR. For example, if
the subscriber has asked for a higher level of QoS than they have subscribed for in
their service level agreement, then this QoS value may be reduced. Also checked is
the use of static IP addresses, as well as whether the requested APN is de¬ned in the
HLR for that subscriber.
3. The SGSN generates a TEID consisting of the IMSI and NSAPI or a link to it, and
checks whether it has the resources available to allow the requested QoS. If not, it
may restrict the requested QoS. The SGSN locates a GGSN which has access to the
access point and sends a create PDP context request. This message consists of the
TEID, MSISDN, selection mode (as described in Section 4.9.4 for the APN), PDP
type, PDP address, APN, negotiated QoS, charging characteristics and any PDP
con¬guration options. The charging characteristics are checked with the HLR to
ascertain how the subscriber will be billed for this connection. The GGSN will create
a new entry in its PDP context table and generate a charging ID. The GGSN may
also restrict the QoS for this connection if it does not have the required resources
available. If the mobile device has been allocated an IP address then this may be
con¬gured by the GGSN (see Section 4.9.3).
4. The GGSN will send a create PDP context response to the SGSN including the
charging ID and any modi¬cations to the QoS.
5. The BSS packet ¬‚ow procedures may be executed to ensure that the QoS
requirements are met. All the packet ¬‚ows related to a single mobile device are
stored in a speci¬c BSS context. Individual contexts are identi¬ed by a unique packet
¬‚ow identi¬er which is allocated by the SGSN. As was discussed, there are three
packet ¬‚ows that are prede¬ned: SMS, signalling and best effort. In these cases, no
negotiation of BSS packet ¬‚ow contexts is required. Both the best effort and SMS
packet ¬‚ows can be assigned to a PDP context and PDP data packets will be carried
across the BSS with the same QoS as the prede¬ned ¬‚ows. To ensure QoS is
guaranteed, the SGSN divides the transfer delay between the BSS and core network
part. It can do this since it can estimate the transfer delay over the core network to
the GGSN. The SGSN can then convert the maximum SDU size, SDU error ratio,
residual bit error ratio, maximum bit rate, guaranteed bit rate and thus the transfer
delay to that applicable for this transfer. The SGSN inserts the NSAPI and the
GGSN address into its PDP context and selects the radio priority and packet ¬‚ow ID
based on the QoS negotiated.



Send Routing info for GPRS
Send Routing info for GPRS Ack
PDP Notification Request
PDP Notification Response
Request PDP Context
PDP Context Activation Procedures 6

Figure 4.44 GGSN-originated PDP context activation

6. Finally, the activate PDP context accept message is sent to the mobile device from
the SGSN, indicating that the request has been accepted.

A network-requested PDP context activation procedure is illustrated in Figure 4.44. Here
a PDU arrives at the GGSN from an external source for a mobile device. This system
only works when the GGSN knows the IP address of the mobile device, i.e. the mobile
device has a static IP address.

1. If there is no PDP context activated then the GGSN may query the HLR for
connection information. To limit the number of queries to the HLR, the mobile
station not reachable for GPRS ¬‚ag (MNRG) message may be set in the GGSN. In
this case the GGSN will not query the HLR. The send routing information for GPRS
message will request the IMSI of the intended recipient.
2. The HLR will respond with the IMSI and the SGSN address of the mobile device in
the send routing information for GPRS acknowledge message.
3. Once the GGSN has this information, it can send a PDU noti¬cation request
message to the SGSN which contains the IMSI number of the mobile device, the
APN, PDP type and PDP address of the mobile device.
4. The PDU noti¬cation response message is returned to the GGSN to indicate that it
will try to reach the mobile device. If the mobile device is not known then an
unsuccessful response such as IMSI not known may be returned to the GGSN.
5. The SGSN can send a request PDP context activation message to the mobile device
to request the device to activate the indicated PDP context.
6. This is followed by the regular PDP context activation procedures as highlighted in
Figure 4.43.

The issues with regard to this type of mobile-terminated data access stretch beyond
the technical capabilities of the network. Allowing external sources to activate a PDP
context presents a number of consequences, some of which may be undesirable for both

subscriber and network operator. In comparison, the Internet is essentially a pull medium,
meaning that information is accessed by the user, and can not generally be network
originated. One exception to that is unsolicited email, or spam, which is already presenting
problems in both ¬xed-line and mobile networks. If information push is permitted, it
is dif¬cult to identify which traf¬c is wanted and which is not. The central issue is
with regard to payment. A subscriber would understandably be unhappy if not only had
they received unsolicited data, perhaps advertising, but also that they had been billed
for this receipt. This issue is non-trivial if one considers that blocking of particular IP
addresses or domain names in the context of the Internet is a laborious task with arguable
Figure 4.45 shows the full trace of the PDP context request from the SGSN and the
response from the GGSN.
Figure 4.46 illustrates how the PDP context can be deactivated. The diagram shows
how this is achieved from the mobile device; however, the SGSN and GGSN can also
deactivate the PDP context.

1. The mobile device sends a deactivate PDP context request to the SGSN.
2. The SGSN may request for security functions to be executed.
3. The SGSN sends a delete PDP context request to the GGSN indicating the TEID.
The GGSN deletes the context at its end and returns any dynamic IP addresses to the
pool so that they can be allocated to other subscribers.
4. The GGSN then responds with the delete PDP context response indicating the TEID
that has been released.
5. The SGSN can now send a reply to the mobile device stating that the deactivation
has been complete.

Figure 4.47 shows a trace of the PDP context deletion. This procedure can be executed
by either the SGSN or the GGSN, hence the identi¬er GSN above the traces.

4.9.3 Transparent and non-transparent mode
Figure 4.48, shows how a mobile device may obtain an IP address directly from the
GGSN. This is referred to as transparent mode. Alternatively, the GGSN may ask an
external dynamic host con¬guration protocol (DHCP) or remote authentication dial-in
user service (RADIUS) server from the subscriber™s home intranet for an IP address for
the mobile device. This is referred to as non-transparent mode.

4.9.4 Access point name (APN)
The access point is the external connection point for the mobile operator™s network. A
subscriber will indicate the access point to which they would like to connect. This is
typically performed either through selecting an item on a list presented on the mobile

IP1 1 15:58:14.241
Source address :
Destination address :
Source port: 2123
Destination port: 2123
IP1 2 15:58:14.251
- Version number: 1 (1h)
- Protocol type: 1 (1h)
Source address :
- Extension header flag: 0 (0h)
Destination address :
- Sequence number flag: 1 (1h)
- N-PDU number flag: 0 (0h)
Source port: 2123
Destination port: 2123
- Header Length: 106 (6ah)
- Tunnel endpoint id: 0 (00000000h)
- Version number: 1 (1h)
- Sequence number: 49 (31h)
- Protocol type: 1 (1h)
- No extension header
- Extension header flag: 0 (0h)
- Sequence number flag: 1 (1h)
- MCC : 310
- N-PDU number flag: 0 (0h)
- NMSI : 010000000030
- Message Type: 17 (CREATE PDP CONTEXT


. 31
( 132 .)