Cellular Data Networks

The general principle of cellular data systems is to separate the data stream bearer from the voice stream bearer and process it in a manner that is tailored specifically for data so that it can exit via a gateway into the wider Internet. How this separation of voice and data traffic is actually achieved is different depending on the access technology deployed; however, the concepts and principles of linking an IP location function into these environments are the same.

The IP address allocated to a mobile device in a cellular data network can come from a variety of sources, including private enterprises and ISPs, but more often than not, comes from the cellular operator. Regardless of where the IP address is allocated, the gateway router in the cellular network needs to be able to map the IP address to a physical cellular device to ensure data packets are delivered to and from the device correctly. If a device is to be able to request its location from a LIS based on the device's IP address, then the LIS will need to have an association with, or have access to, some of the same information as, the cellular operator's packet data gateway. This leads us to the general architecture shown in Figure 8.1.

Figure 8.1: Packet data location architecture.

Location in GPRS Networks

The General Packet Radio Service (GPRS) is the access technology used to provide packet data capabilities to 2G (GSM), and with some software upgrades provides support for 2.5G (EDGE) and 3G (UMTS) cellular devices. GPRS is specified under the 3GPP suite of protocols and integrates with the GSM and UMTS standards. The general architecture for a GPRS network is shown in Figure 8.2.

Figure 8.2: The GPRS architecture.

Figure 8.2 shows the core interfaces that are of interest to us in a GSM GPRS network. The general concepts are the same in a UMTS network, and we shall look at this a little later. While this is not a GPRS tutorial, it is necessary to understand some of the basics of a GPRS network before we can look at the options for location. First and foremost, GPRS is a way to provide packet data services to a GSM cellular network, consequently it is able to make use of some resources and information already available in the cellular network.

The heart of the GPRS network is controlled by two nodes: the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). GPRS is viewed as being an always-on connection, and when a GPRS mobile first registers in a network, it is the SGSN that takes care of most of this. The SGSN is responsible for authentication, registration, and mobility management functions, very much like how the VLR is for cellular voice services. The SGSN is also responsible for the protocol conversions required between the mobile over the air interface, and core IP protocols used over the carrier's backbone network. All data sent by the mobile over the GPRS network, or to the mobile from the GPRS networks is transported by the SGSN.

The GGSN, on the other hand, connects from the carrier's GPRS network to other networks, such as the Internet, corporate LANs, or third-party ISPs. As a result, the GGSN may allocate IP addresses itself, solicit aid from a RADIUS or DHCP server, or it may broker the request to the enterprise or ISP to authenticate and assign IP address information. The GGSN is a router and hides visibility of the GPRS network from external entities and networks. In order for the GGSN to be able to route packets between the GPRS network and the external network, it needs to have a context that allows it to associate the mobile in both networks. This context is called a Packet Data Protocol (PDP) context and it provides a binding between the mobile device using, amongst other things, the IMSI and MSISDN and the external network identifier. GPRS supports general packet protocol but, in practice, the PDP is IP, and this is the assumption that we shall use for the remainder of this chapter.

Figure 8.2 shows the GGSN connecting through a firewall to the Internet. In reality the GGSN can provide a connection to networks other than the Internet, including a corporate LAN, or a third-party ISP. The connecting node must inform the SGSN, and by association the GGSN, which network they wish connect to. To do this, the GRPS handset includes a specific Access Path Name (APN), which is used to identify the type of connection the handset requires. For each connection, a PDP context is created on the GGSN, and a new IP address is allocated. It is therefore possible that a terminal in a GPRS network may have more than one IP address assigned to it. We shall only consider the Internet PDP context type.

The control-plane location specification includes support for determining the location of a data device since the GMLC is able to use the Lg interface to request location information from the SGSN. The GMLC is able to determine which SGSN to query since this information is maintained in the HLR as part of the mobility management function. The SGSN is then able to send a BSSAP provide location request (PLR) to the BSC, which in turn sends a BSSAP-LE PLR to the SMLC. At the time of writing, not all the major suppliers of SGSN equipment support this functionality, consequently the GMLC may need to send the PLR to the MSC in the same way it would for a voice-based location request. This assumes that GPRS handsets also operate as voice terminals, which is generally true today.

Chapter 1 described the GMLC and its main query interface, the Le interface, which uses the OMA-defined Mobile Location Protocol (MLP) (see Reference 2). MLP provides an array of ways to identify a device, including IMSI, IMEI, MSISDN, and IP address. The problem is that the GMLC must be able to take the identifier provided in the MLP query, and map it to an SGSN or MSC, and to do this it must get information from the HLR. The GMLC obtains this information from the HLR by sending it a 3GPP MAP (see Reference 3) Send Routing Information (SRI) message, and this message must contain either the MSISDN or the IMSI so that the device can be identified. Hence the GMLC must be provided with either the IMSI or the MSISDN over the MLP interface.

In the networks we have described so far, the end-point has used a HELD request to a LIS to obtain location information, either as a reference location URI or a literal, PIDF-LO. Ideally, therefore, an IP-based handset can request location from a cellular IP network in the same way. If we want to do this in such a way as to leverage an existing control-plane infrastructure, then we need to introduce a LIS into the network, and we need to be able to obtain a binding between IP address and either MSISDN or IMSI. There are two ways to obtain this binding: either learn it from the network somehow, or have it provided by the end-point. The safest option is to learn it from the network but there is no standard defined on how to perform this. GGSN vendors may make this information available by providing a proprietary query interface, or indirect methods obtaining the data the DHCP server, RADIUS server, or charging records may be employed. The LIS may not be able to learn the IP-to-IMSI/MSISDN mapping from the network in all circumstances, however, and where it can't it will be dependent on the end-point providing the mapping. GPRS is a mobile network, and in most cases the end-point will create a HELD context and use a location URI to facilitate location retrieval. The end-point can therefore provide the IMSI/MSISDN-to-IP address binding when the HELD context is created using the HELD identity extensions schema defined in Appendix E. A HELD context creation message providing this mapping would look similar to the following code fragment.

 <createContext xmlns="http://sitacs.uow.edu.au/ns/location/held">    <lifetime>PT10M</lifetime>    <profile>      <presentity>pres:[e-mail]</presentity>      <retentionExpiry>2006-01-01T13:00:00</retentionExpiry>      <retransmission>alse</retransmission>    </profile>    <rules>      <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">         <rule >           <conditions>             <identity>               <one />             </identity>           </conditions>         </rule>      </ruleset>    </rules>    <heldDevice      xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">      <msisdn>612448266004</msisdn>      <imsi>50501997844001</imsi>      <ipv4>47.181.192.205</ipv4>    </heldDevice> </createContext> 

A LIS deployment in a GPRS network is shown in Figure 8.3. The DHCP protocol defined in Reference 4 allows a DHCP client to specify a particular Client-Identifier to the DHCP server that the server should use as a handle to the client-host's configuration data. This is DHCP option 61 and is defined in detail in Reference 5. The GGSN in a GPRS network acts as a client for a great many DHCP leases, one per PDP context, so the GGSN needs a way to associate a particular context with a DHCP lease and the easiest way to do this is to use the Client-Identifier DHCP option 61. One implementation option a GGSN vendor can use is to create the Client-Identifier for a PDP context in the IMSI or MSISDN concatenated with Network Service Access Point Identifier (NSAPI), where NSAPI defines the type and possibly quality of service associated with the PDP context (this approach is used by at least one commercial GGSN vendor). Using this approach, a DHCP lease query ALE can be used to extract the Client-Identifier information from the DHCP server and subsequently provide the required IMSI/MSISDN-to-IP mapping.

Figure 8.3: The LIS in a GPRS network.

Where RADIUS is used to provide the IP address, RADIUS accounting messages similar to those described in Chapter 6 can be used to obtain the necessary attribute associations. In Chapter 6, the RADIUS ALE was mapping IP address to circuit identifiers and correlators. In this case, the RADIUS ALE needs to map IP address to IMSI or MSISDN, which it can do using the Framed-IP-Address and Callback-Number RADIUS attributes defined in Reference 6. Essentially, this same method is used by a number of commercial WAP gateways that have to deal with a similar problem. In WAP gateway deployments, the RADIUS accounting messages are sent directly from the GGSN to the WAP gateway.

The 3GPP specification (see Reference 7) deals with the generation of charging records, referred to as call detail records (CDR) in GPRS networks. The node that is generating the CDR determines the prefix given to the CDR; G-CDRs, for example, are generated by the GGSN. G-CDRs are created and sent to a charging server based on various triggers that occur through the lifetime of an attachment; two such triggers are the creation and subsequent deletion of a PDP context. A G-CDR will generally contain the IMSI, MSISDN, and IP address assigned to the PDP context. These G-CDRs can be intercepted by an ALE and converted into FLAP correlation measurement messages and then subsequently used by the LIS to acquire the necessary client IMSI/MSISDN-to-IP binding.

Location in CDMA 1xEVDO

Evolution Data Optimized (1xEVDO) is a Code Division Multiple Access (CDMA) cellular-based technology used to provide a high-speed data service to mobile devices. The standards for this technology have been developed within 3GPP2 and are capable of supporting peak rates of 3072 kbps on the forward link (to a handset) and 1843.2 kbps on the reverse link (toward the network). It is a fully IP-based packet data architecture that is founded on the IETF mobile IP architecture. 1xEVDO is being deployed by a number of carriers in the United States and around the world to augment existing residential broadband service offerings with typical data download speeds of between 300 kbps and 700 kbps. Unlike existing residential broadband offerings such as DSL and cable, 1xEVDO supports fully mobile users, which adds to the complexity of systems that need to locate an end-device attached to the network.

Figure 8.4 shows the general mobile IP architecture, and the nodes perform similar functions to nodes in the GPRS network. The Access Network (AN) is made up of a base station controller and a set of base stations and is responsible for authenticating the mobile device and providing RF connectivity. The Packet Control Function (PCF) is responsible for managing data sessions seamlessly across ANs, this is equivalent to the SGSN in a GPRS environment. The Packet Data Serving Node (PDSN) is responsible for establishing a context, providing an IP address for the mobile device, and routing IP packets to and from the IP device and the network. The PDSN is equivalent to the GGSN in a GPRS network. The Home Agent (HA) is responsible for acting as a point of contact for the mobile device should a third party wish to reach the mobile; this provides the functionality that was added to the HLR to support GPRS in a 3GPP network. The HA is also required to support inter-PDSN/FA handovers. The resulting network will look something like Figure 8.5.

Figure 8.4: Mobile IP architecture.

Figure 8.5: The 1xEVDO network.

In Figure 8.5, a mobile device connects to the network and proceeds to establish a PPP session with the PDSN. The PDSN proceeds to authenticate the mobile device using the foreign and home AAA servers, in 3GPP2 these are DIAMETER servers, which are viewed as a successor to RADIUS. The home AAA will authenticate the mobile device, based on CHAP and the device's Mobile Identification Number (MIN), which is a number associated with an actual mobile device. If the mobile device is authenticated, then a home agent is assigned and a Home-IP-Address for the device is provided. The result of the authentication, along with the identity of the home agent, if the authentication is successful, is returned to the PDSN. The PDSN foreign agent (FA) can then provide update information to the home agent, including the care-taker IP address allocated to the mobile device while it is in the visited network. The PDSN will also start generating accounting messages, which will include the care-taker IP address and the MIN of the mobile device.

The mobile device can learn the address of the LIS in this configuration using the DNS mechanism described in Chapter 4. The LIS is able to learn the IP address-to-MIN mapping through an ALE looking at accounting records, in much the same way as was described for GPRS (see Figure 8.6.). Unlike GPRS, no control plane location specification exists for the EVDO architecture; the only mechanism specified is to use the Secure User Plane Location (SUPL) standard, which is described in Chapter 9. In this environment, when a LIS needs to obtain the location of a mobile device, it will need to send an MLP request to a SUPL Location Platform (SLP). In reality, many mobile devices, particularly handheld devices, will also have CDMA voice capabilities. In this case, the LIS can query a Mobile Positioning Center (MPC) and IS-41 control-plane solutions can be used to determine the location of the mobile.

Figure 8.6: A LIS in the 1xEVDO network.

Unlicensed Mobile Access

A specific form of VoIP has been implemented in cellular networks in recent years called Unlicensed Mobile Access (UMA). UMA is generally provided in conjunction with cellular access so that the device, by policy or where cellular coverage is not available, may utilize Internet connectivity to perform mobile calling. Using a broadband access means not needing to provide voice service over the licensed radio frequency coverage used by the cellular operator-hence the "unlicensed" term in the label. This requires the operator to provide an IP-accessible UMA server to provide the VoIP functionality.

Rather than implement the call processing within the UMA server, the server acts as a BSC emulator interfacing into the core cellular network; thus, the call processing is done by the MSC in the cellular network and connectivity to other cellular and PSTN subscribers is provided transparently by the core network. For example, a UMA server in a GSM network emulates a traditional BSC and connects to the MSC over the A-interface.

Since the MSC expects to see mobility-related information, such as the current serving cell identifiers, the UMA server creates "virtual cell identifiers" to allocate to a given call in progress. If the user is on an access network that the UMA server is coupled with (for example, if the cellular operator is also the provider of the broadband IP access), the virtual cell identifiers may convey a specific significance as far as the location of the caller is concerned. However, if the user is connecting to the UMA server from an arbitrary Internet connection point-one which the UMA operator has no relationship with-then the virtual cell identifier needs to be relatively arbitrary, as long as it's unique and cannot imply any location information.

Looking once more at the GSM deployment scenario (see Figure 8.7), a typical mobile-terminated location request through the GMLC, or a network-initiated location request in response to an emergency call, will result in a location request being routed through to the UMA server. The MSC will do this since the UMA server appears to be a BSC and location requests are typically routed through the BSC to the SMLC. UMA server implementations typically integrate the SMLC functionality internally. Clearly measurements such as "timing advance" or "signal strength" as seen on a normal GSM base station do not apply to a device connecting through, for example, a DSL broadband service. Recalling that a UMA device is also generally a GSM cellular phone capable device, however, the UMA server may request the device to provide measurements from the cellular network if it is still visible, or from the latest time prior to losing contact with the cellular network. This request is made using UMA VoIP client-specific messaging. Thus, the SMLC function integrated into the UMA server may have a degree of sophistication in terms of making a "best guess" at a current location based on any available knowledge of the serving Internet access, or by an assessment of how current any cellular network measurements may be. Ultimately, this "best guess" becomes less useful the longer the device is only connected to an arbitrary and unassociated Internet access point and in a location that does not fall under the operator's cellular coverage. For example, if the user powers up their device in a WiFi hotspot in a foreign country, the UMA server will have no information which it can utilize in location determination.

Figure 8.7: A UMA in a GSM network.

UMA deployments, then, have already encountered the challenge of convergence and the service-provider access-provider separation associated with the Internet services model. Since the voice service provider-the UMA operator-does not necessarily control all access networks, a dependency on the access network provider to make location information available arises.

Using the LIS architecture (see Figure 8.8), which assumes that location determination and acquisition is done by the access provider, the UMA client would be responsible for providing the UMA server with location information. A UMA client which is also a HELD client would consult with the access network LIS, obtain location, and convey that location information as part of the UMA VoIP-specific messaging. Location may be provided as a literal location value or it may be provided by reference. In the case of the latter, the UMA server would also act as a HELD client and be able to retrieve the location information directly from the LIS for as long as the location reference remained valid. From the cellular network perspective, in terms of the mobile-terminated requests through the GMLC or network-initiated requests from the MSC, normal location procedures would apply transparently. The UMA server and, in particular, the integrated SMLC function may then invoke HELD requests to the LIS in response to any location requests originating from the MSC. A complete UMA-SMLC implementation would utilize this mode while still supporting the "best guess" procedures as a fallback where the UMA client is not in an LIS-equipped access network.

Figure 8.8: A UMA using LIS functionality.