Tackling the Mobile Addressing Problem

Kim Fullbrook, GPRS Network Technical Architect, BT Cellnet

A White Paper on IP addressing for GPRS mobile Terminals and the implications for Network Operators. 22^nd August 2000

Introduction

The world's two biggest technological growth areas are the use of mobile phones and accessing the Internet. The launch of GPRS services which combine these two technologies has lead some industry commentators to predict an upcoming crisis due to the number of mobile devices exceeding the number of available Internet IP addresses. Is this crisis a real threat or can it be avoided ? In this paper the author demonstrates how, with the use of a design model featuring private addressing, the scale of the problem can be reduced to the point where it is no longer significant providing the scheme is adopted by all GPRS network operators worldwide.

Scope

This document discusses IP addressing for GPRS mobiles and does not deal with GPRS infrastructure for which an addressing policy featuring registered addresses has already been agreed with the Internet authorities. It covers only IP version 4 addressing because although the facility for IP version 6 has been included in the GPRS standards no GPRS equipment manufacturers presently support it. 3^rd generation cellular systems (UMTS or 3G) will not be covered although the basic principles described here can be adopted for current applications such as WAP running on 3G. As background it should be noted that the first versions of UMTS systems to be deployed by the "early adopter" networks from 2002 onwards are expected to be IP version 4 only, and also that GPRS systems are expected to exist in parallel with UMTS for many years.

Certain specialist areas of GPRS system design such as Customer Interconnect (also known as APN design) and WAP security are described in some detail but cannot be covered in depth in such a brief paper.

Background

Up to now mobile phones have been used predominantly for voice calls but the phenomenal growth of SMS messaging in the last two years has demonstrated a huge customer demand for services that are not voice-based. Technical advances such as GPRS are now making Internet access from mobile devices feasible for the mass market where previously it had been fraught with difficulties and used in practice only by the committed Internet enthusiast. The telecommunications industry expects a huge demand for GPRS Internet services among both business and consumer users when sufficient handsets become available.

GSM Association Policy Guidelines

Up to now there has been no intention by the GSM Association to create a policy in the area of IP addressing for mobiles. However, discussions with the Internet authorities have indicated the need for such a policy so that the Registries can refer to it when processing IP address requests from GPRS operators. It is also apparent that some operators considering offering GPRS do not appreciate the significance of the IP addressing issues, and the policy can assist them in understanding the options they face. Obviously any policy would need to be agreed between the operators representatives and the Internet authorities, and it is proposed that the existing GPRS subgroup within the GSM-A IREG (Internet Roaming Experts Group) be used for this purpose. Time is short as some GPRS networks have launched commercial service and the Internet authorities have already received a number of IP address requests which are waiting to be processed. Although the number of GPRS customers is presently relatively small, their number is expected to increase rapidly. The author suggests that the recommendations in this White Paper be used as the basis for a policy. Hence it is essential for all GPRS operators to examine this paper and discuss its proposals & implications so that they can contribute within the various IREG forums to the formulation of the addressing policy.

GPRS

GPRS is a service which can be added to existing GSM cellular networks and allows customers with a GPRS-capable handset and an appropriate subscription to access various IP networks and services such as the Internet. It allows users to be continuously connected to their chosen service - subject to having good radio coverage - even when they are not sending or receiving data. In other words "always on".

IP Address Usage

Historically Internet access has traditionally required the accessing device - generally a PC using a PSTN phone connection - to have an Internet IP address temporarily allocated to it for the duration of its connection, typically for a few hours. Once the user has disconnected, this IP address is released for re-allocation to another user. The Internet Service Provider (ISP) industry has relied on the statistical behaviour on this type of connection whereby only about 1 in 20 of its subscribers (or less) will want to be on line and connected at any given time. Therefore, even a large ISP with a million customers only requires 50,000 IP addresses. However, with GPRS the connection pattern is expected to change dramatically. Once users have switched their phone on and are connected to the network they are likely to stay connected for much longer. Hence any temporarily allocated IP address will be required to stay allocated to an individual user for a much longer period. Historical behaviour in the BT Cellnet network shows more than half of all its subscribers cellular phones switched on during the busiest period. Today BT Cellnet has over 8 million customers and the number is increasing at a considerable rate. Handset manufacturers have indicated that within two years virtually all their products will have WAP browsers and be capable of GPRS service. Even if only 5 million BT Cellnet customers signed up for Internet services, this represents a potential demand of at least:

5 million customers x ?of them switched on and connected = 2.5 million customers and hence IP addresses required in the busiest period !

World GSM Demand

Current statistics from EMC - as displayed on the GSM Association web site (www.gsmworld.com) -for numbers of GSM subscribers are shown in the following table. It should be noted that there are several competing non-GSM cellular standards in the world (which are popular in North America and Asia), so the figures do not denote the total number of world cellular subscribers.

Internet IP Addresses Availability

There is currently a widely-held belief that Internet registered IP addresses are in short supply. However, the reality is that there are still large numbers available but they will only be released to organisations that can demonstrably satisfy the necessary criteria including a genuine need for registered addresses that cannot be satisfied by private addressing, and a planned high utilisation of the requested range. At the present time more than half the sixty four available /8 (formerly known as Class A) address ranges are unallocated representing roughly 32 x 256 x 256 x 256 = 530 million addresses. Compare this with the estimated GSM population of 564 million subscribers by December 2002 - which will increase further in subsequent years. Given that many of the presently unallocated IP addresses will be required by fixed line Internet customers, it is easy to see that even if only half of these GSM/GPRS subscribers require a registered IP address the GPRS demand cannot be satisfied. This point is extremely important. The intention is not to say whether the number of unallocated addresses is 400, 500 or 600 million addresses or some other comparable figure. Rather it is to show that by comparing the approximate number of GPRS users with the number of available addresses using simple arithmetic and taking into account the fact that there are many other Internet engineering applications which require registered IP addresses it will be impossible to satisfy the principle of supplying a registered IP address to every on-line GPRS phone. Some alternative method must be found and applied now. The proposed solution is discussed in later paragraphs of this paper.

Registered / non-Registered IP Addresses

The architects of the Internet in the 1970s did not envisage the extent to which it would grow in the 1990s and beyond. Their expectation was that all devices connecting to the Internet and accessing available services would require an IP address. These addresses were acquired free of charge by organisations by applying to the relevant Internet registry and were known as "Registered addresses". The criteria for acquiring them were in retrospect pretty loose. By the mid-1990s it was clear that this model could no longer apply as the supply of available IP addresses would rapidly be exhausted. A new addressing model was created consisting of several components. Firstly the concept of "non-registered" or "private" IP address ranges was introduced. Certain ranges were set aside for anyone to use however they wished, with the only criteria being that these ranges would not be routed on the Internet. Secondly the technique of "Network Address Translation" (NAT) was introduced where an NAT device would sit between a private network and the Internet. In addition, companies began to use sophisticated security devices known as firewalls which sit between the private network and the Internet. These would allow through any permitted traffic while preventing unauthorised users to probe or attack the private network. Firewall and NAT are distinct functions but are frequently combined in a single device.

Network Address Translation (NAT)

NAT works as follows: Any device on the private network wishing to send traffic to an Internet-connected device could do so but as the individual packets passed through the NAT device the source address of the device is replaced with a registered Internet address - usually that of the NAT device. When the Internet device responds, the NAT device receives the packet and then works out from the port numbers and sequence numbers which device inside the private network had sent the packet. The packet then has the correct destination address replaced and is then forwarded to its destination. Below is a diagram showing an example of user PC in a corporate network requesting information from an Internet web server, with NAT being performed at the corporate firewall. The role of the firewall is in some ways similar to that of a web proxy server.

In this example the setup always works when requests are initiated by the User PC. If, hypothetically, communication was initiated from the web server how would it work ? The simple answer is that it can't because it can't route data to a "private" address and there is no way for the web server to indicate the identity of the User PC with which it wishes to communicate. Is this a problem ? No. With existing web access isn't a problem because communication is always initiated from the user. However, especially in the mobile world there is a huge demand for "push" technology where remote servers may send unrequested messages to a user. For example "You have new mail" when new mail arrives at their central mail store, or notification when a share price reaches a particular level.

Solving the Problem

To solve the problem for GPRS requires that we look beyond the immediate situation and examine the services that will be offered to users. This involves identifying the user groups and forecasting those services that will be in most demand based on today's understanding.

The GPRS users can be divided simply into the following groups:

1. Business users accessing their company network via a direct link
2. Those accessing the Internet. This group needs to be further divided:

1. Those using WAP only. It is expected that overwhelmingly the demand will be from users in this group.
2. Those using WAP plus a "standard" service such as Web or POP3 email
3. Those with non-standard needs which probably involves using a PC-type device. One example would be someone using VPN encryption services to connect to a corporate firewall via the Internet.

Dealing with each of these cases in turn:

1. Business users. IP addressing for business users accessing their company network is simple: addresses are allocated from the company network. Effectively the user device is on its own private extension to the company network. The majority of companies today make use of private IP addressing although GPRS does not care what scheme is used. Even though hundreds of companies may all be using the same private 10.x.x.x address space, GPRS's design keeps them separate. Therefore every company can use their own preferred IP addresses even if based around private addressing.

2i. Internet WAP users. These will work quite happily with private addressing.

2ii. Internet WAP users with standard services such as e.g. Web or POP3 email. Again these will work quite happily with private addressing.

2iii. Internet users with PCs accessing non-standard services. These are best served with registered addresses.

All these options will be explained more fully in the subsequent sections.

It could be the case that some other application (i.e. not WAP or web) becomes popular in future which is incompatible with private addressing. The purpose of this paper is to suggest a solution to today's problem and not worry about something which is not known. Unlike PCs, the majority of handsets have fixed capabilities and cannot have new applications loaded on to them. Although IPv6 is not a viable solution today, it might be appropriate in the future when these "other" applications appear.

IP Addressing for GPRS Internet WAP Users

Is private addressing sufficient to deal with the needs of Internet WAP users ? The forthcoming version of WAP - 1.2 - provides "push" technology, and obviously this must be supported by any IP addressing proposal. To properly answer the question requires examining how WAP works in more detail and this is covered in the following sections: firstly standard WAP request and response, and then WAP "push".

A diagram of a regular WAP request and response is shown below.

A fundamental point is that a WAP browser can only communicate with a WAP Gateway and not directly with a WAP server. In this example, two types of WAP server have been shown: a local server, which could be the same physical machine as the WAP gateway, and a remote server out on the Internet. In both cases communication between WAP phone and WAP server is via the WAP Gateway. It can be seen that the pattern of data flow is very similar to the NAT example given earlier in this document. Private addressing can be used and there are several alternative ways of implementing it depending on the security preferences of the organisation. One way would be as follows:

This example includes a firewall that performs NAT. Everything inside has private addresses while everything outside i.e. on the Internet needs registered addresses. Traffic through the firewall in both directions between "inside" and "outside" automatically has its IP addresses converted by the NAT.

WAP Push

How does this work with WAP Push services? To answer this requires examining WAP push in more detail. Obviously a "push" has to be set up in advance and it's worth mentioning as an aside that there are various security provisions to ensure that only authorised pushes reach the mobile user. Part of the setup process is to specify the user's address for the push. There are four different alternatives formats for this allowed by the WAP standards:

The push message starts at the WAP Push Initiator and is sent to the Push Proxy Gateway specified in the destination address of the push message. The important point to note is that all addresses are relative to the WAP push proxy gateway (PPG). Therefore any push addressing scheme can be used that the PPG understands, and this is implementation-dependent i.e. it could use any of the four types specified. For IP addressing purposes we can note that it is the PPG which communicates with the WAP phone and not the initiator of the push. Therefore we can use private IP addressing and the whole setup will still work.

The following diagram shows WAP push together with the associated IP addressing schemes.

The push message starts at the WAP Push Initiator and is sent to the Push Proxy Gateway specified in the destination address of the push message. In turn this forwards the message to the phone, which in this case has been identified using its MSISDN: +447802123456. The important point to note is that all phone identifiers/addresses are relative to the WAP push proxy gateway (PPG). Therefore any addressing scheme can be used that the PPG understands, and this is implementation-dependent i.e. it could use any of the four types specified (arbitrary name, phone number, IPv4 address or IPv6 address). For IP addressing purposes we can note that it is the PPG which communicates with the WAP phone and not the initiator of the push. Therefore we can use private IP addressing and the whole setup will still work.

This paper is not intended to be a tutorial on WAP architecture or APN provisioning. However, it is worth pointing out that the IPv4 and IPv6 types of WAP Push message are not recommended by this author for Internet deployment. This is because dynamic IP addressing for mobiles is considered more suitable due to IP routing considerations (to GGSNs) and overall reduction of the number of IP addresses needed. Use of the aforementioned types of WAP Push message would fail once a mobile had disconnected from GPRS and the IP address had been re-allocated to another mobile. It is envisaged that WAP Push messages relying on fixed IP addresses might be appropriate in some applications on corporate networks.

Web and POP Email Services

If web and POP email are required by certain higher-end phones, will this be compatible with the suggested private IP addressing model ? Fortunately the answer is "yes". Both web and POP3 email are completely user-driven i.e. no "push", and are fully compatible with private IP addressing and NAT. The web and POP servers can be either within the private network or else somewhere on the Internet reachable via NAT.

Other Internet Services

Some Internet services are not compatible with private addressing. For example IPsec VPNs will not work properly through Network Address Translation. Consequently this group of users will need to have public registered addresses allocated. However, the number of users in this category is expected to be relatively small: less than 5% of all users (author's estimate). This number is expected to drop further as terminal devices become more sophisticated by web & WAP browsers providing their own SSL or WTLS encryption which is compatible with NAT and proxying. It might be appropriate to charge customers a small premium for GPRS services that require registered addressing.

How many Registered Addresses ?

Registered addresses will be required in two main areas, excluding the GPRS infrastructure itself:

The first is for those mobiles that genuinely require registered addresses because of the nature of what they are doing. The author estimates that no more than 5% of the customer base will fit into this category. Taking BT Cellnet as an example again, if 5% of its 8 million customer base needs registered addressing, the maximum need is for 400,000 addresses. Based on this assumption, taking the Dec 2004 GSM subscriber forecast, a community of 733 million customers would need a maximum of 737 million x 5% = 36 million IP addresses, which is only a little over 2 "/8" networks. Therefore the problem is diminished to a level where it can be managed using today's IP address allocation processes.

The second is for the NAT devices that serve the WAP mobiles. The author suggests the following assumptions for estimating how many addresses are required:

• a typical NAT device can serve 4000 simultaneously active "sessions"
• half of the mobiles connected to a WAP service will actually connect out to servers located on the public Internet and therefore have active sessions through the NAT device. Of these, the timeouts on the NAT device can be set so that effectively only half of these (i.e. one quarter in total) are actually simultaneously active at the busiest time.

So taking BT Cellnet as an example. In an earlier estimate we assumed there would be 2.5 million customers out of the total customer base of 8 million active at the busiest time.

Hence max number of NAT addresses required = (2.5 million x 1 quarter) / 4000 = 156

This figure - 156 - is low.

Scaling up to the global scenario, assuming a figure of 1 billion GPRS mobiles of which, say half are active and connected at the busiest time, this would require 500,000,000 / 4000 = 125,000 IP addresses for NAT purposes, which represents approximately 2 "/16" networks (formerly known as Class B). Even allowing for wastage of addresses due to the half billion users being spread acrosss several hundred GPRS operators around the world, this shows that the recommendation to use private addressing for mobiles in conjunction with NAT is viable.

Distinguishing between the services

If a GPRS network operator decides to offer all the services previously suggested, how should they distinguish between them ? At a technical level this is simple: each one has its own Access Point Name (APN) e.g. wap.genie.co.uk for the WAP service, and open.genie.co.uk for the unrestricted "open pipe" service. Having two or more separate APNs in this way is considered by the author to be the minimum necessary if a full range of Internet services is to be offered to customers.

Fixed vs Dynamic IP Addressing

When designing a connection scenario the GPRS network operator has the choice of specifying either fixed IP addressing for mobiles (via the user's subscription record in the Home Location Register [HLR]) or dynamic addressing. In the latter case the address is allocated to a mobile only when it successfully connects to an APN, and is released for re-allocation once the mobile disconnects. There are no "right" or "wrong" answers when designing an Internet connection scenario. However, the use of dynamic IP addressing is recommended for a number of reasons. Firstly it reduces the size of IP address pool required. Secondly it ensures the IP routing is workable in setups where multiple GGSNs are deployed to serve a single APN. There are some cases in corporate networks where fixed addressing may be appropriate but these are not covered here, and in any case corporate networks are generally implemented with (or are compatible with) private addressing.

GPRS Roaming

How does the proposed scheme work with GPRS roaming i.e. when a subscriber travels to another country or uses another network in the same country ? There are two variations of roaming. The first is where the user accesses their chosen service in the visited country. The second is where they access their chosen service in their home country. Which of these options is available to the user will depend on their subscription and the design of the service being offered. As an example many UK companies would have GPRS gateways in the UK, but a global company such as AOL might have GPRS gateways in many major countries. How do the various scenarios compare in practice ? As in previous sections it is important to look at the service being offered to the Internet customer in more detail.

The overwhelming majority of customers will have WAP-based handsets, with a relatively small number using more sophisticated devices such as PCs. The design of the WAP service involves burning the IP address of the desired WAP gateway into the handset so that in practice it is something that will be changed only in exceptional circumstances and not when roaming. In other words the WAP customer will always connect to the same WAP gateway irrespective of their location in the world. One benefit of this is so that a user can access their WAP personalisations which are stored on a specific server or family of servers at their home WAP provider.

The straightforward case to consider is the "home" connection i.e. when a customer's roaming access is back to the home country. This is shown in the following diagram.

The customer's WAP traffic between handset and WAP gateway will traverse the private inter-PLMN network backbone inside GPRS's GTP tunnels and therefore private IP addressing allocated from the home network will be sufficient. There are no special routing or security considerations needed for the mobiles and WAP Gateway, and this is consequently the preferred option.

On the other hand, if the customer's roaming Internet access is local within the visited country, their WAP traffic will need to traverse the Internet in order to reach their WAP Gateway. This is shown in the following diagram.

In this case the APN could the the service APN named "Internet" which has been agreed by SERG as an APN which all operators need to provide. Its purpose is to ensure that a user roaming on to another network can guarantee open access to the Internet using this APN. The IP address given to the mobile would need to be Internet registered and this has to be dynamically allocated because of IP routing considerations. Note that the WAP gateway has to be accessible for incoming handset connections across the Internet which is undesirable for security reasons as it increases the risk of a denial-of-service attack on the WAP server from a malicious Internet user. The WAP provider has no control of the quality of service for traffic between WAP handset and WAP gateway because the connection travels over the wider Internet.

In summary although this scenario is technically possible it has undesirable features and the author considers it to be unattractive to WAP operators and for use mainly by "power users" with PCs or similar powerful devices. Note that the APN must be provided by all operators.

The last scenario to consider is where the customer connects to a WAP provider that has local gateways (APNs) in various foreign networks. This could potentially be a scenario adopted by a global company such AOL.

The customer's WAP traffic travels between countries to their home WAP gateway via that company's internal network. This scenario is compatible with private addressing. In practice it is likely to be adopted only by those very large companies who have a presence in multiple countries.

In summary this section shows how private addressing is compatible with GPRS roaming but there are implications for the way that the connections are designed.

How many mobiles ?

Internet standards are created by the Internet Engineering Task Force and documented using the "Request For Comment" (RFC) system. RFC 1918 describes the address ranges available for private use. The largest of these is the /8 network (formerly known as Class A) range: 10.x.x.x

This allows slightly more than 16 million addresses. Hence a WAP gateway operator could have up to 16 million mobiles actively served from a single Push Proxy Gateway at any given time. This is enough for the largest GSM operators at the present time but might prove to be a barrier in the future. The author does not consider this as a serious problem as there are several potential solutions to this particular scaling problem which are beyond the scope of this paper. However a more pressing issue is how to scale the various NAT devices and WAP gateways to be able to handle these volumes while still delivering adequate performance.

Benefits of Private Addressing

What are the benefits of adopting private addressing for GPRS WAP services ?

The major one presented in this paper is that it is simply not possible to adopt the alternative of registered IP addressing due to the sheer number of addresses required.

Adopting private addressing ensures that the valuable resource of registered IP addresses is not utilised where it is not needed, and consequently more can be made available to those services which can be demonstrated to require them. However there are other more tangible benefits for an operator:

1. Rapid deployment. Because registered addresses are not required it is no longer necessary to go through a request process which might have unforeseen delays. If there is a sudden and unexpected uptake in demand for the WAP service it can be provisioned without depending on the granting of new IP address ranges by an external registry
2. Better security. Private addresses are not directly accessible from the Internet and by using an NAT device which includes basic firewalling functionality the users are not vulnerable to direct attacks from the Internet. This becomes significant if a GPRS operator chooses to bill its WAP customers on the basis of the amount of data that they send over the air.

Downsides of Private Addressing

There are a few disadvantages to using private addressing.

1. NAT devices must be utilised. These cost money, can have a performance impact and must be maintained. However, either Internet security devices such as firewalls or WAP gateways have to be employed and therefore the addition of NAT functionality to them represents only a small increment.
2. For a very large network operator with more than 16 million customers likely to be on line with their WAP service at any one time, there are insufficient private addresses available to have a unique address for each customer. This scenario needs to be further explored but is considered by the author to be solvable from an addressing perspective. In any case, relatively few ISP/WAP services are large enough to be affected and there are alternative design options which can eliminate the problem.

Implications for GPRS Operators

The design options described in this paper provide a suitable solution for any GPRS operator providing WAP services. In order for this solution to be fully effective i.e. minimising the total number of registered IP addresses required, it needs to be adopted by all GPRS / WAP operators globally. Another way of looking at this is that a GPRS operator cannot justify the use of registered IP addresses for WAP users and the Internet Registries can reasonably decline a request for registered IP addresses in this case.

The implications for GPRS / WAP operators can be summarised as follows:

• they must use private addressing when offering WAP and NAT-compatible services. Once an addressing policy is agreed between the GSM Association and the Internet authorities, any operator applying for registered IP addresses for this purpose will probably have that application refused because private addressing has been demonstrated by other operators to be sufficient. (Assuming the recommendations in this paper are accepted)
• if operators want to support other types of Internet access services, some of which may genuinely require registered IP addresses, they will have to differentiate them from those using private addressing with NAT i.e. the WAP family of services. In GPRS technology this is achieved by the use of a different APN (Access Point Name).
• WAP roaming is best achieved via the inter-PLMN backbone from the connection point (APN) in the visited network to the home network. This can use private addressing. Operators need to set up the customers' HLR subscription and APN permissions with this in mind
• The general "Internet" APN is really only suitable for low-volume specialist use, otherwise high numbers of registered IP addresses will be required.

Summary

WAP services can be implemented using a private IP addressing scheme on the mobiles. The advantages of using a private scheme outweigh the disadvantages and in any case the use of a registered IP address for every GPRS user is simply not possible. The recommended scheme will reduce the pressure on the available stock of registered IP addresses. It also decreases the need to migrate from IP version 4 to IP version 6 with its increased address space. Although there are scaling problems to be solved in very large networks, it will be more difficult to scale the WAP servers than the IP addressing. The proposal does require acceptance by all GPRS / WAP operators globally to achieve its full potential, in which case the number of registered IP addresses required for mobile services will be relatively small.

References

"Wireless Application Protocol Push Proxy Gateway Service Specification" by the WAP Forum. www.wapforum.org
"Wireless Application Protocol Push Architectural Overview" by the WAP Forum. www.wapforum.org
"RFC 1918: Address Allocation for Private Internets." by Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear
"Understanding Security on the Wireless Internet" by Phone.com

Jargon Buster

Back to Documents Index

Back to SIG Index