Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


Establishing a PDP Context

Jan 20,2011 by alperen

image

The transfer of packet data is
through the establishment of a Packet Data Protocol (PDP) context, which
is effectively a data session. Normally, such a context is initiated by the MS,
as would happen, for example, when a browser on the MS is activated and
the subscriber’s home page is retrieved from the Internet. When an MS or
the network initiates a PDP context, the MS moves from the standby state
to the ready state. The initiation of a PDP context is illustrated in Figure 5-7.
An MS-initiated PDP context begins with a request from the MS to activate
a PDP context. This request includes a number of important information
elements, including a requested Network Service Access Point Identifier
(NSAPI), a requested LLC Service Access Point Identifier (SAPI), a
requested Quality of Service (QoS), a requested PDP address, and a
requested Access Point Name (APN).

The NSAPI indicates the specific service within the MS that wants to use
GPRS services. For example, one service might be based on IP; another
might be based on X.25.
The LLC SAPI indicates the requested service at the LLC layer. Recall
that LLC is used both during data transfer and during signaling. Consequently,
at the LLC layer, it is necessary to identify the type of service being
requested, such as GPRS mobility management signaling, a user data
transfer, or a short message service (SMS), which can be supported over
GPRS as well as over GSM.

The requested QoS indicates the desires of the MS regarding how the
session should be handled. Components of QoS include reliability (including
the maximum acceptable probabilities of packet loss, packet corruption, and
out-of-sequence delivery), delay, mean throughput, peak throughput, and
precedence (which is used to determine the priority of the MS’s packets in
case of network congestion where packets may need to be discarded).
The requested PDP address will typically be either an IP address or will
be empty. The network will interpret an empty address as a request that
the network should assign an address. In such a case, the Dynamic Host
Configuration Protocol (DHCP) should be supported in the network. The
address is assigned by the GGSN, which must either support DHCP capabilities
itself or must interface with a DHCP server.

The access point name indicates the GGSN to be used and, at the GGSN,
it may indicate the external network to which the MS should be connected.
The APN contains two parts—the APN network identifier and the APN operator identifier. The APN network identifier appears like a typical Internet
URL according to Domain Name Service (DNS) conventions—a number
of strings separated by dots, such as host.company.com. The APN operator
identifier is optional. When present, it has the format operator.operatorgroup.
gprs. Each operator has a default APN operator identifier, which has
the form MNC.MCC.GPRS. The Mobile Country Code (MCC) and the
Mobile Network Code (MNC) are part of the International Mobile Subscriber
Identity (IMSI) that identifies the subscriber and is available at the
SGSN. The default APN operator identifier is used to route packets from a
roaming subscriber to a GGSN in the home network in case the APN from
the subscriber does not include an APN operator identifier.

Based on the APN received from the subscriber, the SGSN determines
the GGSN that should be used. The SGSN normally does this by sending a
query to a DNS server (not shown in Figure 5-7). The query contains the
APN, and the DNS server responds with an IP address for the appropriate
GGSN.

Next, the SGSN creates a tunnel ID (TID) for the requested PDP context.
The TID combines the subscriber IMSI with the NSAPI received from the
MS and uniquely identifies a given PDP context between the SGSN and the
GGSN. The SGSN sends a Create PDP Context Request message to the
GGSN. This contains a number of information elements, including the TID,
the PDP address, the SGSN address, and the QoS profile. Note that the QoS
profile sent from the SGSN to the GGSN may not match that received from
the MS. The SGSN may choose to override the QoS parameters received
from the MS based upon the QoS subscribed (as received from the HLR) or
based upon the resources available at the SGSN. If the PDP address is
empty, then the GGSN is required to assign a dynamic address.
The GGSN returns the message, Create PDP Context Response to the
SGSN. Provided that the GGSN can assign a dynamic address and provided
that it can support connection to the external network as specified by the
APN, then the response is a positive one. In that case, the response includes,
among other items, GGSN addresses for user traffic and for signaling, an
end user address (as received from DHCP), the TID, a QoS profile, a charging
ID, and a charging gateway address.

Upon receipt of the Create PDP Context Response message from the
GGSN, the SGSN sends Activate PDP Context Accept to the MS. This contains
the PDP address for the MS (in the case that a dynamic address has
been assigned by the network), the negotiated QOS, and the radio priority
(which indicates the priority the MS shall indicate to lower layers, and
which is associated with the negotiated QOS). Note that the network shall attempt to provide the MS with the requested QoS, or at least come close.
If the QoS returned by the SGSN is not acceptable to the MS, then the MS
can deactivate the PDP context.

Once the MS has received the PDP Context Accept message from the
SGSN, then everything necessary is in place to route packets from the MS
through the SGSN to the GGSN and on to the destination network.The MS
sends the user packets as SNDCP PDUs. Each such PDU contains the TLLI
for the subscriber and the NSAPI indicates the service being used by the
subscriber, plus the user data itself. The TLLI and NSAPI enable the SGSN
to identify the appropriate GTP tunnel towards the correct GGSN. The
SGSN encapsulates the user data within a GTP PDU, including a TID, and
forwards the user data to the GGSN. At the GGSN, the GTP tunnel “wrapper”
is removed and the user data is passed to the remote data network
(such as the Internet).

Packets from the external network back to the MS first arrive at the
GGSN. These packets include a PDP address for the MS (such as an IP
address), which enables the GGSN to identify the appropriate GTP tunnel
to the SGSN. The GGSN encapsulates the received PDU in a GTP PDU,
which it forwards to the SGSN. The SGSN uses the TID to identify the subscriber
and service in question (that is, the TLLI and NSAPI). It then forwards
an SNDCP PDU to the MS via the BSS.

Note again, that access to and from the MS over the air interface
requires the request and allocation of resources for use by the MS. In other
words, the PDTCH(s) that the MS may be using are not dedicated solely to
the MS either during the PDP context establishment or during a packet
transfer to or from the external packet network. 191

1643 times read

Related news

No matching news for this article
Did you enjoy this article?
Rating: 5.00Rating: 5.00Rating: 5.00Rating: 5.00Rating: 5.00 (total 6 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author