Internet Access over GPRS

[CyberGuru]

Internet Access over GPRS


Introduction

I will explain how the General Packet Radio Service (GPRS) technology is used for providing mobile/wireless access to the Internet. We explain the fundamental GPRS concepts, protocols, and procedures and demonstrate the main functionality provided by the GPRS network. The key procedures examined are the registration procedure, the routing/tunneling procedure, and the mobility management procedure, all of which enable mobile/wireless IP sessions.
GPRS is a bearer service of the Global System for Mobile (GSM) communications, which offers packet data capabilities. The key characteristic of the data service provided by GPRS is that it operates in endto- end packet mode. This means that no communication resources are exclusively reserved for supporting the communication needs of every individual mobile user. On the contrary, the communication resources are utilized on a demand basis and are statistically multiplexed between several mobile users. This characteristic renders GPRS ideal for applications with irregular traffic properties (such as Web browsing), because, with this type of traffic, the benefits of statistical multiplexing are exploited; that is, we obtain high utilization efficiency of the communication resources. A direct effect of this property is the drastically increased capacity of the system in the sense that we can support a large number of mobile users with only a limited amount of communication resources. The increased capacity offered by GPRS, combined with the end-to-end packet transfer capabilities, constitute the main factors that drive the use of GPRS in providing wide-area wireless Internet access.


GPRS Overview

In general, a GPRS network can be viewed as a special IP network, which offers IP connectivity to IP terminals on the go. To provide such a mobile connectivity service, the GPRS network must feature additional functionality compared with standard IP networks. However, from a high-level point of view, the GPRS network resembles a typical IP network in the sense that it provides typical IP routing and interfaces to the external world through one or more IP routers.

By using shared radio resources, mobile users gain access to remote Packet Data Networks (PDNs) through a remote access router, which in GPRS terminology is termed Gateway GPRS Support Node (GGSN). You can think of access to a remote PDN as being similar to a typical dial-up connection. Indeed, as discussed in Section 3.3, a user establishes a virtual connection to the remote PDN. However, with GPRS a user may “dial up” to many remote PDNs simultaneously and can be charged by the volume of the transferred data, not by the duration of a connection. GPRS can offer both transparent and nontransparent access to a PDN. With transparent access, the user is not authenticated by the remote PDN, and he or she is assigned an IP address (private or public) from the address space of the GPRS network. On the other hand, with nontransparent access the user’s credentials are sent to the remote PDN and the user is permitted to access this PDN only if he or she is successfully authenticated. In this case, the user is typically assigned an IP address (private or public) from the address space of the PDN he or she is accessing. Note that, irrespective of the type of access to a PDN, a user is always authenticated by the GPRS network before being permitted access to GPRS services (this is further discussed in Section 3.2.3). The nontransparent access is particularly useful for accessing secure intranets (e.g., corporate networks) or Internet Service Providers (ISPs), whereas the transparent access is most appropriate for users who do not maintain subscriptions to third-party ISPs or intranets. As illustrated in Figure 3.1, the GPRS network forms an individual subnet, which (from an address-allocation point of view) contains all users who use transparent access to remote PDNs. External PDNs perceive this subnet as being a typical IP network.


GPRS Bearers

GPRS network effectively provides a GPRS bearer — that is, it provides a communication channel with specific attributes between the MS (the terminal) and the GGSN (the router). Over the GPRS bearer, the MS may send IP packets to the GGSN, and it may receive IP packets from the GGSN. As explained below, the GPRS bearer is dynamically set up at the beginning of an IP session (when the user “dials” to a specific PDN), and it can be tailored to match the specific requirements of an application. In other words, it can be set up with specific Quality of Service (QoS) attributes, such as delay, throughput, precedence, and reliability.

The PCU communicates with the Serving GPRS Support Node (SGSN) over a frame relay interface (Gb). The SGSN provides mobility management functionality, session management, packet scheduling on the downlink, and packet routing/tunneling. The interface between the SGSN and the GGSN (Gn) is entirely based on IP, typically on IPv4. The GGSN provides mainly routing and optionally screening functionality and can be considered to be a remote access router interfacing with the external PDNs. The fact that we have two IP layers within the GGSN implies that some sort of IP-to-IP tunneling is applied across the Gn interface.

[CyberGuru]

GPRS Protocols


The Subnetwork Dependent Convergence Protocol (SNDCP) runs between the MS and the SGSN, and it is specified in reference 17. It is the first layer that receives the user IP datagrams for transmission. SNDCP basically provides (1) acknowledged and unacknowledged transport services, (2) compression of TCP/IP headers (conformant to RFC 1144; see reference 15), (3) compression of user data (conformant to either V.42bis [reference 16] or V.44), (4) datagram segmentation/reassembly, and (5) PDP context multiplexing (see Section 3.4). The segmentation/ reassembly function ensures that the length of data units sent to LLC layer does not exceed a maximum prenegotiated value. For example, when this maximum value is 500 octets, then IP datagrams of 1500 octets will be segmented into three SNDCP data units. Each one will be transmitted separately and reassembled by the receiving SNDCP layer.

PDP context essentially represents a virtual connection between an MS and an external PDN. The PDP context multiplexing is a function that (1) routes each data unit received on a particular PDP context to the appropriate upper layer and (2) routes each data unit arriving from an upper layer to the appropriate PDP context. For example, let us assume a situation where the MS has set up two PDP contexts, both with type IP but with different IP addresses. One PDP context could be linked to a remote ISP, and the other could be linked to a remote corporate network. In this case, there are two different logical interfaces at the bottom of the IP layer, one for each PDP context. The SNDCP layer is the entity that multiplexes data to and from those two logical interfaces.

The Logical Link Control (LLC) protocol runs also between the MS and the SGSN, and it is specified in reference 12. LLC basically provides data-link services, as specified in the Open System Interconnection (OSI) seven-layer model.18 In particular, LLC provides one or more separate logical links (LLs) between the MS and the SGSN, which can be broken down into user-LLs (used to carry user data) and control- LLs (used to carry signaling). There can be up to four simultaneous user-LLs, whereas there are basically three control-LLs: one for exchanging GPRS mobility management and session management signaling,another to support the Short Message Service (SMS),19 and a third to support Location Services (LCS).20 A user-LL is established dynamically, via the PDP context activation procedure (see Section 3.3), and its properties are negotiated between the MS and the SGSN during the establishment phase. Negotiated properties typically include (1) the data transfer mode (acknowledged versus unacknowledged), (2) the maximum length of transmission units, (3) timer values, (4) flow control parameters, and so forth. A part of these properties defines the QoS that will be provided by the user-LL. On the other hand, the control-LLs have predefined properties, and they are automatically set up right after the MS registers to the GPRS network

Control-LLs operate only in unacknowledged mode, which basically provides an unreliable transport service. On the other hand, user-LLs operate either in unacknowledged mode or in acknowledged mode, depending on the reliability requirements. The latter mode provides reliable data transport by (1) detecting and retransmitting erroneous data units, (2) maintaining the sequential order of data units, and (3) providing flow control.

The Radio Link Control (RLC) and Medium Access Control (MAC) protocols run between the MS and the PCU, and they are specified in reference 13. The RLC makes available the procedures for unacknowledged or acknowledged operation over the radio interface. It also provides segmentation and reassembly of LLC data units into fixed-size RLC/MAC blocks. In RLC acknowledged mode of operation, the RLC also provides error-correction procedures that enable the selective retransmission of unsuccessfully delivered RLC/MAC blocks. Additionally, in this mode of operation, the RLC layer preserves the order of higher-layer data units supplied to it. Note that whereas LLC provides transport services between the MS and the SGSN, the RLC offers similar transport services between the MS and the PCU.

The MAC layer implements the procedures that enable multiple MSs to share a common radio resource, which may consist of several physical channels. In particular, in the uplink direction (MS to network), the MAC layer provides the procedures, including contention resolution, for the arbitration among multiple MSs that simultaneously attempt to access the shared transmission medium. In the downlink direction (network to MS), the MAC layer supplies the procedures for queuing and scheduling of access attempts. More details are provided below.

The MAC function in the network maintains a list of active MSs, which are mobile stations with pending uplink transmissions (they have uplink data to transmit). These MSs have previously requested permission to content for uplink resources, and the network has responded positively to their request. Each active MS is associated with a set of committed QoS attributes, such as delay or throughput. These QoS attributes were negotiated when the MS requested uplink resources. The main function of the MAC layer in the network is to implement a scheduling function (in the uplink direction), which successively assigns the common uplink resource to active MSs in a way that guarantees that each MS receives its committed QoS. A similar scheduling function is also implemented in the downlink direction. From the previous discussion, it is obvious that every GPRS cell features a central authority (the PCU), which (1) arbitrates the access to common uplink resources by providing an uplink scheduling function, and (2) administers the transmission on the downlink resources by providing a downlink scheduling function. These scheduling functions are part of the functions required to guarantee the provisioning of QoS on the radio interface and are implementation dependent.

The Base Station Subsystem GPRS Protocol (BSSGP) runs across the Gb interface; it is specified in reference 21. BSSGP basically provides (1) unreliable transport of LLC data units between the PCU and the SGSN, and (2) flow control in the downlink direction. The flow control attempts to prevent the flooding of buffers in the PCU and to conform the transmission rate on Gb (from SGSN to PCU) to the transmission rate on the radio interface (from PCU to MS). Flow control in the uplink direction is not provided because it is assumed that uplink resources on the Gb interface are suitably dimensioned and are significantly greater than the corresponding uplink resources on the radio interface. BSSGP provides unreliable transport because the reliability of the underlying frame relay network is considered sufficient enough to meet the required reliability level on the Gb. BSSGP also provides addressing services, which are used to identify a given MS in uplink and downlink directions, and a particular cell. In the downlink direction, each BSSGP data unit typically carries an LLC data unit, the identity of the target MS, a set of radio-related parameters (identifying the radio capabilities of the target MS), and a set of QoS attributes needed by the MAC downlink scheduling function. The identity of the target cell is specified by means of a BSSGP Virtual Channel Identifier (BVCI), which eventually maps to a frame relay virtual channel. In the uplink direction, each BSSGP data unit typically carries an LLC data unit, the identity of the source MS, the identity of the source cell, and a corresponding set of QoS attributes. The mobility management function in the SGSN uses the source cell identity to identify the cell where the source MS is located.

GPRS Tunneling Protocol (GTP) runs between the SGSN and the GGSN. In general, however, GTP also runs between two SGSNs. GTP provides an unreliable data transport function (it usually runs on top of UDP) and a set of signaling functions primarily used for tunnel management and mobility management. The transport service of GTP is used to carry user-originated IP datagrams (or any other supported packet unit) into GTP tunnels. GTP tunnels are needed between the SGSN and the GGSN for routing purposes. (This is further explained in Section 3.4.) They are also necessary for correlating user-originated IP datagrams to PDP contexts. By means of this correlation, a GGSN decides how to treat an IP datagram received from an SGSN (e.g., to which external PDN to forward this datagram), and an SGSN decides how to treat an IP datagram received from a GGSN (what QoS mechanisms to apply to this datagram, to which cell to forward this datagram, and so forth). Now that we have discussed the fundamental concepts and protocols of GPRS, let us investigate the typical procedures carried out to enable wireless IP sessions over GPRS. In particular, we describe the registration procedure, the routing/tunneling procedures, and the mobility management procedures.

[CyberGuru]

The Attach Procedure


Before a mobile station can start a wireless IP session or any other packet data session over the GPRS network, it has to perform the registration procedure. In the GPRS specifications,8 the registration procedure is formally referred to as an attach procedure. During this procedure, the mobile station is actually informing an SGSN that it wants to have access to the GPRS network, and at the same time it identifies its comprehensive set of capabilities. In response, the SGSN authenticates the mobile station, retrieves its subscription data, and checks whether it is authorized to have access to the GPRS network from its current routing area (i.e., one or more cells served by the same SGSN8). If none of the checks fails, the SGSN accepts the attach request of the mobile and it returns an accept message. After that, the SGSN becomes the serving SGSN of that particular mobile.

In step 1, the MS sends an Attach Request message to the SGSN (labeled as new SGSN), which serves the routing area where the mobile station is located. In the Attach Request message, the MS typically includes a temporary identifier, called the Packet Temporary Mobile Station Identity (P-TMSI). This PTMSI has previously been allocated, possibly by another SGSN (e.g., the old SGSN shown in Figure 3.3) and, possibly, in another routing area. However, the P-TMSI is stored in the nonvolatile memory of the MS, and as long as it is valid, it is used as an MS identity. The use of a temporary identity instead of the permanent MS identity (i.e., the International Mobile Station Identity [IMSI]) provides user identity confidentiality.9 As explained below, the GPRS network allocates a new P-TMSI value to the MS whenever appropriate. Along with the P-TMSI, the Attach Request includes the identity of the routing area where this P-TMSI was allocated, as well as information related to the MS capabilities — for example, supported frequency bands, multislot capabilities, and ciphering capabilities.

In step 2, the new SGSN tries to acquire the permanent MS identity — that is, its IMSI. If the P-TMSI included in the Attach Request message has previously been allocated by the new SGSN, then the new SGSN also knows the IMSI of the MS. However, in the example shown in Figure 3.3, we assume that the P-TMSI has previously been allocated by the old SGSN. Therefore, the new SGSN may try to contact the old SGSN and request the IMSI value that corresponds to the P-TMSI reported by the MS. This is accomplished in step 2a with the Identification messages exchanged between the two SGSNs. Note that the address of the old SGSN is derived by the new SGSN with the aid of the routing area identity (RAI) included in the Attach Request. The exact mapping between an RAI and an SGSN IP address is implementation specific and can typically be based on preconfigured mapping tables or DNS queries.
If the new SGSN cannot acquire the MS’s IMSI value in step 2a (e.g., because the old SGSN has deleted the relevant information, or because the IP address of the old SGSN cannot be resolved), then the new SGSN requests that the MS send its permanent identity. This is accomplished in step 2b. The obvious drawbacks of this step are that it introduces additional signaling over the radio interface and that it compromises the user identity confidentiality (because the IMSI is transmitted unciphered on the radio interface).

In step 3, the authentication and key agreement procedure is executed. During this procedure, the new SGSN contacts a Home Location Register (HLR), which maintains the subscription data of the identified IMSI and requests from this HLR the authentication data required to authenticate the MS. The address of the appropriate HLR is derived by translating the routing information contained in IMSI value. Note that an HLR is typically accessible over the international SS7 network and either the Message Transfer Part (MTP) transport or IP transport can be used for SS7 signaling.14 The authentication and key agreement procedure is identical to the one used in GSM, and more details about it can be found in the GSM technical specifications9 as well as in other references, such as reference 10 or 11. Typically, after the authentication and key agreement procedure, ciphering is enabled on the radio interface, and therefore, further messages transmitted on this interface are enciphered. In GPRS, the ciphering function is performed at the LLC layer. Further details can be found in the LLC specification.12

In step 4 , the new SGSN tries to update the HLR database with the new location of the MS. For this purpose, it sends an Update Location message to the HLR containing its own IP address, its own SS7 address, and also the IMSI value of the MS. Subsequently, the HLR informs the old SGSN that it can now release any information stored for this MS. This is done with the Cancel Location message. Typically, when the old SGSN receives this message, it will release the previously allocated P-TMSI for this MS (and make it available for reallocation), delete any other information possibly stored for this MS, and respond with a Cancel Location Ack message. In step 4c, the HLR sends to the new SGSN the GPRS subscription data of the MS. At this point, the new SGSN may perform several inspections; for example, it may check whether the MS is allowed to roam in its current routing area. If none of the checks fails, then the new SGSN builds up a GPRS Mobility Management (GMM) context for this MS and returns a positive acknowledgment to the HLR. On the other hand, if an inspection routine fails (e.g., due to roaming restrictions), the new SGSN sends a negative response to the HLR and subsequently it sends an Attach Reject message to the MS, including the specific reason for rejecting the attach request. The GMM context can be considered a database record that holds GPRS mobility management information pertaining to a specific MS. Such information includes the IMSI value of the MS, the routing area and the cell where the MS is currently located, the P-TMSI allocated to the MS, the ciphering algorithm used to encipher packets for this MS, the GPRS capabilities of the MS, and data that can be used to authenticate the MS in the future. In step 4d, the HLR acknowledges the location update that was requested earlier in step 4a.

In step 5a, the new SGSN sends an Attach Accept message to the MS to indicate that the MS has successfully been registered for GPRS services. Typically, with the Attach Accept message, the new SGSN assigns a new P-TMSI value to the MS. At the final step (5b), the MS responds with an Attach Complete message, which acknowledges the correct reception of the new P-TMSI value. Note that the messages transmitted in steps 5a and 5b are typically enciphered; therefore, the new P-TMSI value cannot be eavesdropped on.

[CyberGuru]

Setting Up PDP Contexts



After a successful GPRS attach procedure, the mobile station is permitted to use the mobile GPRS services in a secure fashion (a security context is established between the mobile and the network). However, further actions are needed for accessing an external PDN. In particular, a virtual connection has to be set up with that PDN. This is accomplished with the (formally referred to) PDP context activation procedure. (The term PDP [Packet Data Protocol] context, used instead of IP context, emphasizes the fact that GPRS supports not only IP contexts but also other types of packet contexts, such as X.25 and PPP.) Roughly speaking, this procedure can be conceptually associated to the well-known dial-up procedure used over the Public Switched Telephone Network (PSTN) to establish connectivity (e.g., with ISPs). However, GPRS PDP contexts (virtual connections) operate in connectionless mode, as opposed to the connection-oriented mode of the PSTN dial-up connections. In this section, we discuss the concepts behind GPRS PDP contexts and the PDP context activation procedure.
As mentioned before, you can think of the GPRS network as an access network that offers connectivity between a number of mobile stations and a number of external PDNs. For this purpose, the GPRS network offers access ports where the mobile stations can be connected and access ports where the external PDNs can be connected.

Each PDP context is characterized by:
• A specific PDP type, e.g., IPv4, IPv6, X.25, or PPP, which specifies the type of the payload
transferred on the PDP context
• A specific APN, which represents an external PDN
• A specific GPRS bearer, i.e., by specific transmission properties

The GPRS bearer is a key characteristic of a PDP context because it specifies QoS properties such as the reliability, delay, throughput, and precedence of the packets transmitted on the PDP context. It is important to note that a GPRS mobile may have one or more simultaneously active PDP contexts. This means that one GPRS mobile may simultaneously exchange data with one or more external PDNs — for instance, with one that provides Internet access and with another one that provides access to a corporate intranet. Of course, this is not possible with a single PSTN dial-up connection.
When an MS wants to establish a new PDP context, it sends a specific signaling message (Activate PDP Context Request) to its serving SGSN. This message specifies all the previously mentioned characteristics of the requested PDP context. The SGSN checks the requested APN and identifies (e.g., by using the DNS system) the IP address of the GGSN that provides access to that APN. This GGSN may be located either in the serving GPRS network or in the home GPRS network If the MS specifies only the PDN_name (e.g., Internet) instead of the full APN name, the SGSN will first try to use a GGSN in the serving GPRS network. If that fails, it will then try to locate a GGSN in the home GPRS network. If, on the other hand, the MS specifies the full APN name in the Activate PDP Context Request (e.g., Internet.PLMNA.gprs), a GGSN in PLMN A may be used only to offer connectivity to the Internet. It is evident that, for establishing a PDP context like the one shown in Figure 3.4 for MS B, specific inter- PLMN connectivity means must exist and the operators of PLMN A and PLMN B must have established a roaming agreement.

After identifying a GGSN, the SGSN sends a GTP signaling message (Create PDP Context Request) to that GGSN to request the activation of the requested PDP context. Typically, the GGSN checks whether the MS is authorized to access the requested APN, and if so, it allocates a new IPv4 address to this PDP context (assuming that the requested PDP type is IPv4). It must be pointed out that the GGSN may request a new IPv4 address either from an internal Dynamic Host Configuration Protocol (DHCP) server or from an external DHCP server located in the requested PDN. In the first case, the MS is allocated an IPv4 address from the address space of the serving or home GPRS network, and the MS becomes a new IPv4 node within this network. In the latter case, however, the MS is allocated an IPv4 address from the address space of the external PDN, and effectively it becomes a new IPv4 node inside this PDN. This is equivalent to the case where access to the PDN is accomplished through a dial-up connection. It is typically used when the external PDN is an intranet, which may use private (rather than public) IP addresses. Under normal conditions, the GGSN accepts the request to create the new PDP context and returns a positive GTP response (Create PDP Context Response) to the SGSN. Subsequently, the SGSN returns an accept message (Activate PDP Context Accept) to the MS, which includes the IPv4 address allocated to the new PDP context. At this point, a new PDP context (i.e., a new virtual connection) has been established. Note that the establishment of a PDP context does not involve the reservation of dedicated communication resources in the GPRS network. This applies to both the radio interface and the wireline part of the GPRS network. The establishment of a PDP context involves only the storage of new information in the GPRS nodes (i.e., the creation of new PDP context records in the SGSN and the GGSN). This new information is subsequently used to route the packets correlated with that PDP context.

[CyberGuru]

Routing and Tunneling

After we have established a PDP context, we use a tunneling procedure to transfer PDP packets from the MS to the GGSN. Assume, for instance, that a PDP context of type IPv4 has been established between the MS and the GGSN In this case, each IP packet transmitted from the MS is put into an envelope that carries two important addressing identifiers: the Traffic Flow Identity (TFI; see reference 13) and the Network Service Access Point (NSAPI). The TFI effectively identifies an active GPRS MS in a certain cell, and the NSAPI identifies one of the PDP contexts that has been activated by that GPRS MS. The PCU that receives this packet translates the TFI into a Temporary Logical Link Identifier (TLLI) and forwards the packet to the SGSN. The TLLI is another MS identifier, which, as opposed to TFI, is decoupled from the cell where the MS is located. In particular, the TLLI is a unique identifier in the SGSN and is used to identify a specific MS served by that SGSN. It is essentially derived from P-TMSI, which is another identifier for the MS. The difference between TLLI and P-TMSI is their range of applicability: The first is applied as an identifier at the LLC protocol, whereas the second is applied as an identifier at the GMM protocol (this is a special signaling protocol that handles GPRS mobility management issues; see reference 8). Because TLLI is derived from P-TMSI, a unique TLLI is also assigned to every MS when it is registered with an SGSN.

The SGSN that receives the packet from the PCU tries to correlate this packet with a preestablished PDP context. For this purpose, the SGSN searches its PDP context database and identifies the PDP context that has stored TLLI and NSAPI values matching the TLLI and NSAPI values contained in the envelope of the received packet. From the information contained in the identified PDP context, the SGSN finds out the IP address of the GGSN associated with this PDP context. Subsequently, it makes up a new IP packet, addresses this packet to the identified GGSN, and encapsulates in it the original IP packet transmitted from the MS (this is called IP-IP encapsulation, or tunneling). Afterward, this new packet is transported through the GPRS IP backbone to the addressed GGSN. Note that, in general, the new IP packet may have encapsulated other types of payload, such as X.25, PPP, and IPv6. The type of the payload will match the type of the PDP context.

The envelope of the IP packet transmitted by the SGSN contains a Tunnel Identifier (TI), which is the concatenation of the MS’s IMSI and the NSAPI. The TI is used by the receiving GGSN to correlate this packet with the correct PDP context. When the GGSN identifies the PDP context that has a stored TI that matches the TI in the envelope of the received packet, it discovers the APN associated with this packet and effectively knows the external PDN that the payload (i.e., the original IP packet transmitted by the MS) should be forwarded to. In the downlink direction, the routing procedures carried out in the GGSN and the SGSN are similar. In this case, the GGSN identifies from the destination address of an inbound packet the PDP context associated with this packet. It then identifies the SGSN address associated with this PDP context and forwards this packet to that SGSN, after including in the header the correct TI value. In a sense, the packet is sent to the SGSN over a particular tunnel, identified by the TI value. The SGSN uses the TI to identify the associated PDP context record in its database. From the contents of the identified record, the SGSN finds out the TLLI of the target MS and finally forwards the packet to that MS through the correct PCU. The correct PCU is the one where the last uplink packet from that MS was received.

[CyberGuru]

Mobility Handling

Throughout this section, we consider an MS, which is communicating with an Internet host; say, it is downloading a file from that host. Our main effort is to illustrate how the file transfer can be sustained when the MS is on the move and roams among different radio access points (i.e., base stations). In such situations, the GPRS network has to dynamically cope with the location changes of the MS and carry out procedures to modify the associated PDP contexts according to the identified location changes. All these procedures are typically termed mobility management procedures and are the basis for all mobile networks. In this section, we focus on only the mobility management procedures executed when an MS is in the packet transfer mode. The mobility management procedures executed when an MS is in the idle mode (i.e., involved with no packet transfer) are not discussed.
In this figure, the lines connecting the various network elements are used merely to illustrate the connectivity among these network elements. They do not imply, however, that the network elements are physically interconnected by point-to-point links. For efficiency and cost reasons, it is common in practice to deploy sophisticated transport means to interconnect the network elements. For instance, between an SGSN and a PCU there is typically a frame relay network. In this case, the line connecting an SGSN with a PCU corresponds to a permanent virtual circuit of the frame relay network.

At this point, we assume that the MS has established an appropriate PDP context and is currently within the coverage area of BTS1 receiving a series of downlink packets, each one belonging to the ongoing file transfer session. From Figure 3.7, we note that every downlink packet traverses a series of network nodes in order to be delivered to the MS — i.e., from the GGSN to SGSN1, to PCU1, and finally to BTS1. (The routing procedures used to transfer the packets among successive nodes were explained in Section 3.4.1.) The series of network nodes traversed by the packets belonging to the same PDP context define the transmission path of the PDP context. As you will see below, the transmission path of a PDP context changes dynamically (e.g., from one SGSN to another) in order to facilitate the location changes of the MS. However, the GGSN in the transmission path of a PDP context can never change and therefore serves as an anchor point. This anchor point effectively hides the mobility of the mobile stations and makes it possible for an external PDN to reach a specific MS through the same GGSN no matter where the MS is located.


Cell Change

Let us now assume that the MS starts moving toward the BTS2 (see arrow 1 in Figure 3.7). At some instant, the Radio Resource (RR) layer in the MS will recognize that BTS2 can provide better communications quality and will camp on a Radio Frequency (RF) channel controlled by BTS2. This will happen by suddenly switching RF channels and camping on a new one. This procedure is referred to as mobileoriginated handover because the handover from one cell to another is decided by and performed by the MS alone. In GPRS, this procedure is also referred to as cell reselect. According to reference 13, “when the conditions are fulfilled to switch to the new cell, the mobile station shall immediately cease to decode the downlink, cease to transmit on the uplink, and stop all RLC/MAC timers except for the timers related to measurement reporting. The mobile station shall then switch to the new cell and shall obey the relevant RLC/MAC procedures on this new cell.”

Note now that neither PCU1 nor SGSN1 will know that the MS has moved to another cell until the MS makes an uplink transmission in the new cell. Therefore, for some time, the connection with the MS is inevitably lost, and consequently, downlink packets that may be sent by PCU1 are not received by the MS. This means that, during a handover, the packets transmitted by SGSN1 in unacknowledged LLC mode will be lost. On the other hand, packets transmitted by SGSN1 in acknowledged LLC mode (remember that the LLC mode is specified during the establishment of a PDP context) will not be lost but will stay unacknowledged and will be retransmitted later, when the communication with the MS is made feasible. These recovery procedures are handled by the LLC layer, which copes with the occasional “blackouts” that may occur due to the MS mobility. Here we observe that, even when all single-hop links between the MS and the SGSN1 are perfectly reliable (which means they can transfer data with no errors), the link between the MS and the SGSN can still be unreliable. This observation explains the need for the LLC protocol, a reliable data-link protocol between the MS and the SGSN.

After the handover procedure, the RR layer monitors the broadcast control channel of the new cell. Over this channel, BTS2 transmits the cell ID of the new cell and a Routing Area ID (RAI), which identifies the Routing Area (RA) where this cell belongs. The RR layer will inform the GMM layer that the cell ID has changed but that the RAI is still the same BTS1 and BTS2 belong to the same RA). In response, the GMM layer will command the LLC layer to transmit a NULL frame on the uplink (arrow 2). This is a special LLC frame, whose goal is to notify the network of the cell change. When this NULL frame is received by the LLC layer in SGSN1, the cell change is recorded and subsequent downlink packets are forwarded via BTS2 (arrow 3). This procedure is illustrated in Figure 3.7. Any downlink packets that were sent from SGSN1 to PCU1 during the blackout period are transmitted in the old cell and are never acknowledged by the RLC layer. Typically, these packets are discarded as soon as their “lifetime” expires.

[CyberGuru]

Intra-SGSN Routing Area Change

Suppose now the MS moves further, and suddenly, the RR layer makes another handover, this time from BTS2 to BTS3 This is again a cell change, and what was mentioned in the previous section applies here as well. However, in this case, the RA changes, too, and the RR layer in the MS informs the GMM layer that the mobile station has entered into a new RA. In response, the GMM layer does not send a NULL frame but rather an RA Update (RAU) Request message (arrow 2). This is done because the MS does not know if the new RA is handled by the same SGSN (SGSN1), and therefore it has to include additional information in its uplink transmission. This additional information is included in the RAU Request message and can be used by a new SGSN to retrieve subscription and other mobilityrelated information about that MS. This is explained in more detail in the next sub-section. In the example shown in Figure 3.8, the RAU Request will reach SGSN1 and will be treated merely as a cell change. That is, it will simply notify the SGSN1 that the MS can now be reached in a new RA (i.e., through PCU2 and BTS3). The SGSN1 will confirm that the MS is eligible to roam to the new RA and will accept the RAU Request by replying with a RAU Accept message. Subsequently, it will change the transmission path of the PDP context from PCU1 to PCU2 (arrow 3). This means that further downlink packets related to that PDP context are sent via PCU2.


Inter-SGSN Routing Area Change

When the MS performs a handover from BTS3 to BTS4, it will again transmit a RAU Request message (arrow 2). This time, however, the new RA is controlled by another SGSN, namely SGSN2. At this point, SGSN2 has to acquire some information about the MS. For this purpose, it sends an SGSN Context Request message to SGSN1, asking for the needed information (arrow 3). The address of SGSN1 is effectively derived from the RAI parameter included in the RAU Request message. Now, however, SGSN1 recognizes that the MS has moved to another RA and stops sending downlink packets to the MS (point 3a).

Note that between the instant where the handover took place and the instant where SGSN1 received the SGSN Context Request message, another “blackout” period exists. During that period, SGSN1 could have been transmitting downlink packets to the MS in the context of the ongoing file transfer. These packets would be unacknowledged and would need to remain buffered at SGSN1. It is also important to note that the GGSN still believes that the MS is reachable through SGSN1 and could be transmitting new downlink packets to SGSN1. The latter would need to buffer these packets as well. Observe that if the transport protocol in the GPRS backbone is based on User Datagram Protocol (UDP) — which does not support any flow control — when SGSN1 is out of buffering resources, it has no means to signal that to the GGSN; therefore, downlink packets can actually be lost due to limited buffering capabilities in SGSN1. That observation justifies that the UDP transport is unreliable, even when no transmission errors occur in the backbone links. If during the PDP establishment no reliable transport in the GPRS backbone was requested, then the applications running at the MS and the host are responsible for correcting the packet drops that may take place in the GPRS backbone. In our example, the MS and the host could deal with such potential drops by carrying out the file transfer over a reliable transport protocol, such as the Transport Control Protocol (TCP). If the MS and the host could not provide their own reliable transport protocol and if they were running applications vulnerable to packet drops, they would have to establish a highly reliable PDP context, which would also support reliable transfer in the GPRS backbone (e.g., by using TCP instead of UDP to transport packets between the SGSN and the GGSN)

Again, any potential downlink packets that were transmitted to PCU2 before SGSN1 was informed about the RA change will be discarded after their lifetime expires. An interesting situation arises when the RAU Request message sent by the MS (arrow 2) is lost due to bad radio conditions, for instance. (Typically, another RAU Request would be transmitted after 15 sec.) In this case, it would take quite a long while for SGSN1 to realize that the MS has changed routing areas. During this period, SGSN1 would (1) keep buffering any new packets sent by the GGSN, and (2) periodically retransmit the buffered downlink packets that remain unacknowledged. To tackle such situations, a careful dimensioning of the buffering resources of the SGSN is required. In addition, if SGSN1 attempts the maximum number of LLC retransmissions before receiving the SGSN Context Request message, the LLC connection would be released and any activated PDP contexts would be deactivated. In this situation, the file transfer would effectively be dropped. When setting up the LLC parameters, we must take these situations into account.

Let us now continue with the normal message flow. As soon as SGSN1 receives the SGSN Context Request message (arrow 3), it will reply with an SGSN Context Response message (arrow 4) passing the requested information to SGSN2. The latter sends an SGSN Context Ack message (arrow 5), which verifies that it has received the requested information and is ready to receive any buffered packets for the MS that are still unacknowledged. At this point, SGSN1 forwards all the buffered packets for the MS to the SGSN2 (arrow 5a) within a new tunnel. At the same time, SGSN2 sends an Update PDP Context Request (arrow 6) to the GGSN to inform it that any further downlink packets for the MS should be forwarded to SGSN2. In response, the GGSN replies with an Update PDP Context Response (arrow 7). Now the transmission path of the PDP context changes (arrow 8) to accommodate the location change of the MS. Note that in the case of inter-SGSN routing area change, all the LLC connections in the MS are released and new LLC connections are established with SGSN2. After the short interruption required for modifying the PDP context and for reestablishing the new LLC connections, the ongoing file transfer is resumed.

[CyberGuru]

Summary

We discussed the key GPRS concepts and procedures, and we demonstrated how these procedures enable the provision of wireless packet data services, including wide-area wireless Internet access. In particular, we described the registration procedure, the activation of virtual connections (PDP contexts), the routing and the tunneling of the data in the GPRS backbone, and, finally, how wireless IP connectivity is sustained while a user roams between different areas. At this point, it should be apparent that the GPRS system is a versatile and cost-effective solution for the provision of wireless Internet services, such as web browsing, e-mail retrieval, text messaging, and file downloading. It provides increased capacity and efficient utilization of the communication resources, and it can support various types of packet data protocols, such as X.25, IPv4, and IPv6. In addition, it supports access to both intranets and extranets, and it can offer roaming capabilities, which would ultimately provide for ubiquitous access to data facilities. The GPRS technical specifications (available online at www.3gpp.org/ftp/specs) are continuously evolving in order to enable wireless access to more demanding Internet services, such as video streaming and voiceover IP.

[atultanwar]

How do MS to MS communications are handled? do IP packets go back and forth through the GGSN or do they transit only at the SGSN level?
Is there a way to disable MS to MS communication if we just want to allow MS to back-office communication?

I have a gm29 erricson ,modem. i would like to know how to transmit characters over gprs to a server and how can i request the server to send me data

GPRS registration is the same than GPRS attach??

How the user (MS) can establish a GPRS session?? How is the registration procedure??

I am trying to find out when the P-TMSI is deleted in the MS. i can only find refs in 24.008 that say it should be deleted under certain GMM error conditions. But is it also deleted after a Detach? It has no relevance after the detach, but nowhere can I find that it is deleted.
The key characteristic of the data service provided by GPRS is that it operates in endto- end packet mode.

[hari.krishna]

I read your information.I really like them,and i really want to appreciate you for the way of your explanation.Your information are to the point,it is very easy to understand the people who are new in this field.The charts and diagrams of the post are really wonderful.thank you for sharing such a nice article...

Can you explain EDGE GPRS i.e. Now a days service providers offering E-GPRS what the difference between existing GPRS service?

[jesse]

EGPRS Enhanced General Packet Radio Service

Enhanced Data rates for GSM Evolution (EDGE) (also known as Enhanced GPRS (EGPRS), EDGE is standardized by 3GPP as part of the GSM family, and it is an upgrade that provides more than three-fold increase in both the capacity and performance of GSM/GPRS networks. It does this by introducing sophisticated methods of coding and transmitting data, delivering higher bit-rates per radio channel.

[shabond007]

I have G-Five G3000 china phone. In this site i have tryed all option to install games, GPRS and webcam.. but in this model it is not working. i verified in the PC suite software also. but no use. can any one try to give solution for mobile games and pc suite for G-Five G3000 model.

Thanks in Advance.

[Gonzo]

I have G-Five G3000 china phone. In this site i have tryed all option to install games, GPRS and webcam.. but in this model it is not working. i verified in the PC suite software also. but no use. can any one try to give solution for mobile games and pc suite for G-Five G3000 model.

Thanks in Advance.

I think that there are no supported pc suite available for G-Five G3000 china phone model. You can download the user guide and faq for you mobile phone version from here and check it out whether it supports pc connection or not. Most of the china phone dont support third party applications installation.

[sherdavis]

THanks for the detailed information on General Packet Radio Service (GPRS). I thought it was very interesting that mobile users gain access to remote Packet Data Networks (PDNs) through a remote access router, which in GPRS terminology is termed Gateway GPRS Support Node (GGSN).
AWESOME

[CyberGuru]

never mind will surely help you if any such issues arise in the future.