GSM Association Unrestricted - Industry

Permanent Reference Document:

IR.33

PRD IR.33

Title GPRS Roaming Guidelines

Version 3.2.0
Date 3rd April 2003

GSM Association Classifications

Non-Binding

Core
Security Classification Category:
Unrestricted – Industry
X

Information Category Roaming - Technical

Unrestricted
This document is subject to copyright protection. The GSM MoU Association (“Association”) makes no representation, warranty or
undertaking (express or implied) with respect to and does not accept any responsibility for, and hereby disclaims liability for the
accuracy or completeness or timeliness of the information contained in this document. The information contained in this document
may be subject to change without prior notice. Access to and distribution of this document by the Association is made pursuant to
the Regulations of the Association.
© Copyright of the GSM Association 1999

IR33 Version 3.2.0 Page 1 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

Document History

Version Date Brief Description

0.0.1 22.06.1999 Table of Contents presented at IREG GPRS #4 meeting and
commented upon
0.0.2 20.08.1999 First draft of document for IREG GPRS group discussion (5th
Meeting)
1.0 21.09.1999 Issued First Version for approval
1.0.1 22.09.1999 Modified Section 8.2 for approval
2.0.0 23.09.1999 Approved by IREG#37
3.0.0 October 1999 PL Doc 162/99. Approved at Plenary 42
3.1.0 27th April 2000 CR#01, PL Doc 032/00 approved at Plenary 43
3.2.0 3th April 2003 SCR 02
Changes Since Last Version

Addition of DNS security improvement recommendations

Summary
This document aims to provide a standardised view on how GPRS networks can interwork
in order to provide GPRS roaming capabilities when users roam onto foreign networks.
It will make references to current ETSI GSM specifications for GPRS, and also other GSM
Association document where necessary.
This document should be used in conjunction with two other IREG GPRS documents;
PRD IR.34 & IR.35.
Also documents generated by SERG and BARG are referenced in this document.

IR33 Version 3.1.0 Page 2 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

1. INTRODUCTION.......................................................................................................................................................4
1.1. MS REGISTRATION AND CONTEXT A CTIVATION OVERVIEW ................................................................4
2. ROAMING SCENARIOS .........................................................................................................................................5
2.1. SCENARIO 1 - MS REGISTERED ON VPLMN USING VSGSN AND HGGSN...............................................5
2.2. SCENARIO 2 - MS REGISTERED ON VPLMN USING VSGSN AND VGGSN................................................5
3. ROAMING INTERFACES AND PROTOCOLS ..................................................................................................6

4. GPRS AND THE DOMAIN NAME SYSTEM - DNS............................................................................................6

4.1. DNS INTRODUCTION .......................................................................................................................................6
4.2. GPRS AND DNS.................................................................................................................................................7
4.3. DNS QUERYING WHILST ROAMING...............................................................................................................7
4.3.1. Roaming Scenario 1 (HGGSN used) DNS Querying............................................................................8
4.3.2. Roaming Scenario 2 (VGGSN used) DNS Querying ......................................................................... 12
4.4. THE A CCESS POINT NAME - APN................................................................................................................13
4.4.1. APN Resolution using the Network Identifier .................................................................................... 13
4.4.2. Service APN............................................................................................................................................... 15
4.4.3. Wildcard APN ........................................................................................................................................... 16
4.5. GPRS ROUTING A REA IDENTITIES .............................................................................................................16
5. IP ADDRESS MANAGEMENT............................................................................................................................. 17
5.1. IP NODAL A DDRESS A LLOCATION .............................................................................................................17
5.2. USER IP A DDRESS A LLOCATION .................................................................................................................17
5.2.1. Static User IP Address Allocation......................................................................................................... 17
5.2.2. Dynamic User IP Address Allocation ................................................................................................... 17
5.3. IP A DDRESSES M ANAGEMENT AND A LLOCATION ..................................................................................17
5.3.1. Public IP Addresses ................................................................................................................................. 18
5.3.2. Private IP Addresses................................................................................................................................ 18
6. BORDER GATEWAYS .......................................................................................................................................... 18
6.1. INTRODUCTION ..............................................................................................................................................18
7. INFORMATION EXCHANGE FOR GPRS ROAMING................................................................................... 18
7.1. DNS INFORMATION .......................................................................................................................................18
7.2. IMSI - HLR A DDRESS M APPING ..................................................................................................................19
7.3. GPRS NODAL A DDRESSING RANGE .............................................................................................................19
8. REFERENCES.......................................................................................................................................................... 19

IR33 Version 3.1.0 Page 3 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

1. Introduction
GPRS roaming shall be achieved using the standardised interfaces detailed in GSM 03.60
[1]. The GPRS architecture is shown below in Figure 1.

SMS-GMSC
SMS-IWMSC SM-SC

E C
Gd

MSC/VLR HLR
D
Gs
A Gc
Gr
Gb Gi
TE MT BSS SGSN GGSN PDN TE
Gn
R Um Gn Gf
Gp
EIR

SGSN GGSN

Other PLMN

Signalling Interface
Signalling and Data Transfer Interface

Figure 1: Overview of the GPRS Logical Architecture

GPRS networks can support two basic roaming scenarios: -
• MS connects via VSGSN and HGGSN
• MS connects via VSGSN and VGGSN
The services which networks may support are detailed in [10].
The charging issues for GPRS in a roaming environment are detailed in [11]

1.1. MS Registration and Context Activation Overview

The MS shall always perform a ”GPRS attach” to the SGSN in the visited in order to
register on to the network. If this is the initial attachment in the new PLMN, then the SGSN
shall communicate with the HLR in the Home PLMN. At this point the user is validated as
to whether they are allowed to roam or not.
If the user is allowed to roam, then the VSGSN shall confirm this to the MS. Once the user
is attached, then MO and MT SMS transfer can take place.
The user can then decide to perform a ”PDP Context Activation”. This procedure,
together with the data sent by the MS and the subscribed data stored in the SGSN, will
determine which “roaming scenario” the user will activate. This will be explained in detail in
subsequent text.

IR33 Version 3.1.0 Page 4 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

Once the “PDP context” is activated, then GPRS data transfer can commence. This is
detailed in GSM 03.60 [1]. The mandatory “PDP type” in the roaming environment will be
IP. (i.e. not X.25 or PPP)

2. Roaming Scenarios
2.1. Scenario 1 - MS registered on VPLMN using VSGSN and HGGSN
This scenario applies to: -
• inbound roamers
• outbound roamers
In this scenario, the user will roam on to a VPLMN, and register using a SGSN in the
visited network – the VSGSN. The user shall then activate a context using a GGSN in their
home network - the HGGSN. There will be data and signalling exchanges across the Inter
PLMN Backbone in order to establish the context (Gp Interface required.)
To allow interworking via Gp interface between foreign PLMNs having different GSN
suppliers, it is necessary to agree on compliance to a certain level of GSM specifications.
As a baseline, roaming operators shall conform to GPRS Release 97 level SMG#29 or
higher.
This scenario is shown in Figure 2, and requires: -
• SGSN – HLR interactions via the Gr interface, using Inter network C7/SCCP links
• Inter network DNS exchanges and possible “.gprs root” DNS exchanges. (See Note1)
• Inter PLMN Backbone connectivity and address management
• Border Gateway involvement, which may provide firewall and additional security
functionality.

HGGSN
VSGSN
The Inter GPRS
Backbone External PDN
BG BG

Roaming MS

Figure 2: Scenario 1 - VSGSN and HGGSN using the International Inter PLMN
Backbone
Note 1 – The gprs root refers to a `root DNS server´ which resides inside the GPRS
PLMN or the “root” DNS server may be held outside of the GPRS PLMN and controlled
by an external organisation, such as the GSM Association. This will enable all GPRS
operators to specify their information in one place only, and from there the information is
distributed by DNS.

2.2. Scenario 2 - MS registered on VPLMN using VSGSN and VGGSN

This scenario applies to: -
• inbound roamers

IR33 Version 3.1.0 Page 5 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

• outbound roamers
In this scenario, the user will roam on to a VPLMN, and register using a SGSN in the
visited network – the VSGSN. The user shall then activate a context using a GGSN in their
visited network - the VGGSN.
There will be NO data and signalling exchanges across the Inter PLMN Backbone, as
these will use the Intra PLMN Backbone to establish the context..
This scenario is shown in Figure 3, and requires: -
• SGSN – HLR interactions via the Gr interface, using Inter network C7/SCCP links
• Dynamic address allocation for the subscriber
• Transparent i.e. non-authenticated network access-point access (see Note 2)
• NO inter network DNS exchanges.
• NO Inter PLMN Backbone connectivity or address management
• NO Border Gateways involvement or firewall configuration
VGGSN
VSGSN
Visited PLMN’s
GPRS Backbone External PDN

Roaming MS

Figure 3: Scenario 2 - VSGSN and VGGSN using VPLMN Intra GPRS Backbone
Note 2 – Non-transparent network access-point access is possible, but it requires
authentication servers at the visited network access-point and the home-network access
having the same authentication data. i.e. It is the responsibility of the external PDN to not
fail the users connection when Non-transparent access is encountered.

3. Roaming Interfaces and Protocols

All the GPRS interfaces are standardised in the ETSI GSM recommendations. These are: -
• SGSN – HLR interface “Gr” -> GSM 03.60 [1] and 09.02 [3]
• SGSN – SMS-GWMSC “Gd” -> GSM 03.60 [1] and 09.02 [3]
• SGSN – GGSN – “Gn” (Intra Network) & “Gp” (Inter Network) -> GSM 03.60[1] and
09.60 [4]
The Inter Network DNS – DNS communications shall be performed as per IETF RFC
1034 [5] and RFC 1035 [6]. DNS uses IP to transfer the information exchange.

4. GPRS and the Domain Name System - DNS

4.1. DNS Introduction
With the Internet today, there are a number of Top Level Domains (TLDs) registered for
use by organisations and companies i.e. .com, .org etc. Logical “domain names” allow
users to easily address these domains for www browsing or e-mail transfer. However, in
order for www packets and e-mail packets to be sent, the sender requires the “destination

IR33 Version 3.1.0 Page 6 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

IP address” of the machine to send them to. DNS provides this “look up table” between
logical names and IP addresses. i.e. www.btcellnet.co.uk -> 1.2.3.4
As there are many millions of users out there and also many thousands of domains. DNS
uses a hierarchical system to search and resolve thousands of global DNS entries
systematically. Currently there are 7 generic TLDs, as well as many more country TLDs.
There are 13 “root nameservers” around the world. These nameservers have entries for all
“top level domain servers” e.g. “.com”. The “.com” top level domain server lists all the
known domains that end in “.com” e.g. ibm.com. The ibm.com entry in the root server will
have the ibm.com DNS server(s) (there are usually more than one in case one fails) IP
addresses. The ibm.com DNS server will have all the addresses of the hosts in the
ibm.com domain e.g. www servers and e-mail servers to which the user may wish to send
packets to.
The global DNS system works in this hierarchical way, and nearly all company or ISP DNS
servers “cache” information to save constantly asking the root DNS servers the same
query.

4.2. GPRS and DNS

GPRS is also a DNS based lookup system, and as such will require systematic DNS
“lookups” to be performed. The SGSN shall perform these using the Access Point Name.
The APN will be constructed using information from: -
• User input
• User’s subscription record
• Default SGSN data
The construction of the APN is performed by the SGSN and is detailed in GSM 03.60
Annex A [1]. The SGSN uses the APN to query the DNS, and expect back the IP address
(or addresses) of the GGSN(s) to use to connect the user. The SGSN shall then select a
single IP address to create the GTP tunnel.
PLMNs will be responsible for populating and maintaining the data build of their own DNS
servers.
Each PLMN shall provide a primary and secondary DNS server for roaming APN
resolution.
The GPRS DNS system will be a private network and not have any interaction with the
Internet’s DNS system.
PLMNs GPRS DNS shall allow inverse queries of DNS records in accordance with IETF
RFC 1034 [5] and RFC 1035 [6].

4.3. DNS querying whilst roaming

When users roam, the Visited SGSN will query the local DNS server. The local VPLMN
DNS will try and resolve the APN into the IP address of the GGSN to use.
It is at this point that one of two alternative courses of action can be taken:-
1. If the VPLMN DNS cannot resolve the APN into a GGSN IP address it then needs to
query the DNS in the HPLMN. This should provide the HGGSN IP address to use
(Roaming Scenario 1 – see Figure 2).

IR33 Version 3.1.0 Page 7 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

2. If the VPLMN DNS resolves the APN into a GGSN in the VPLMN – the VGGSN
(Roaming Scenario 2 – see Figure 3).

The following terminology will be used in the rest of the document:

GPRS-DNS DNS belonging to a GPRS operator, i.e. providing APN resolution
GRX-DNS DNS belonging to a GRX provider (no APN resolution)
HPLMN-DNS DNS of the Home PLMN
VPLMN-DNS DNS of the Visited PLMN

4.3.1. Roaming Scenario 1 (HGGSN used) DNS Querying

This scenario is more complex and involves international DNS/IP and GPRS signalling. This
is shown in Figure 4.

GPRS “Root” DNS

2a

VPLMN DNS 4 HPLMN DNS

BG

The Inter GPRS BG

2 5 Backbone -
Private IP

VSGSN

BSS
1

Figure 4: APN Resolution using DNS in HPLMN

1. The MS send a “PDP Context Activation” message to the VSGSN in the Visited
PLMN. This may or may not include an APN. (If no APN is found a “Default APN” is
resolved to which is contained in VSGSN)
2. The VSGSN checks the APN against the user subscription record, and generates a
DNS Query (as detailed in GSM 03.60 Annex A). This is sent to the DNS server
address configured in the VSGSN.
2a. If the DNS does not have the user’s HPLMN DNS IP address within its local records,
then the DNS may query the “.gprs” Root DNS.
3. The VPLMN DNS forwards the query to the HPLMN DNS. Only iterative DNS
queries should be used (see § DNS interrogation mode).
4. The HPLMN DNS returns the result of the query to the VPLMN DNS.

IR33 Version 3.1.0 Page 8 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

5. The VPLMN DNS returns the result to the VSGSN. The SGSN can either use the
HGGSN IP address to connect the user, or fail the context activation (i.e. no IP address
provided).
RFC 1034 [5] and 1035 [6] detail the messages and exchanges required for DNS Name
Server communications.

4.3.1.1 DNS interrogation mode

Two interrogation modes are defined in the DNS specifications: iterative and recursive.
They are described in the following figures (applied to the GPRS case)

Recursive mode

VPLMN DNS Root

DNS-Gn
HPLMN
1
2 DNS-Gn
3
VSGSN 7 4

6
VPLMN 5 HSGSN
BG
GRX BG HPLMN
VGGSN
VSGSN
HGGSN HSGSN

Figure 4 - Recursive interrogation mode

The VPLMN DNS interrogates its Root DNS, which relays the request to the HPLMN
DNS and appears as request originator to the HPLMN DNS. The response goes through
the same path. The HPLMN has no way of being sure which PLMN is the original source
of the requests (i.e. the VPLMN address is not included in the request).

Iterative mode

IR33 Version 3.1.0 Page 9 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

VPLMN DNS Root

DNS-Gn
1 HPLMN
3
2 DNS-Gn

4
VSGSN 7
5
VPLMN HSGSN
BG
6 GRX BG HPLMN
VGGSN
VSGSN
HGGSN HSGSN

Figure 5 - Iterative interrogation mode

The VPLMN DNS interrogates its Root DNS, which provides the address of the HPLMN
DNS. The VPLMN-DNS interrogates directly the HPLMN-DNS. The HPLMN is able to
identify the source of the request. Alternatively, if the VPLMN has no Root DNS, the
VPLMN DNS sends the requests directly to the HPLMN DNS.

The iterative mode is generally the default mode which is configured in the DNS servers.

Iterative interrogation mode may be realised in two different ways:

- the VPLMN DNS sets the interrogation type of the requests sent to the root
DNS to "iterative"
- the root DNS is configured to work in iterative mode; it will then behave as
described in Figure 5 regardless of the VPLMN DNS query type (iterative or
recursive).

A GPRS operator shall accept only DNS requests coming from his roaming partners by
applying source IP address checking (for example at the Border Gateway), and reject any
other request. In order to do this, the HPLMN has to be able to determine the Visited
PLMN which has emitted a DNS request.
If recursive interrogation mode is used, the DNS queries will be sent to the HPLMN-DNS
by the GRX-DNS, and the identity of the VPLMN is masked to the HPLMN.
Therefore only iterative interrogation mode should be used between GPRS DNS
servers.

IR33 Version 3.1.0 Page 10 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

In addition, even if a GPRS-DNS responds only to requests coming from roaming

partners, there is still a possibility for a PLMN to obtain information on a network it
has no roaming agreement with: this is described on the following figure.

PLMN 2
DNS-Gn

PLMN 2
DNS Root 2
1
BG
HPLMN
DNS Root 1
DNS-Gn PLMN 1
DNS -Gn 4

GRX 2
2
BG
HPLMN
BG
3 BG
PLMN 1
GRX 1

Figure 6 – Recursive query to a non-roaming partner

In order to avoid this case, it is recommended that GPRS-DNS accept only

request concerning the operator's APNs. All other requests should be
rejected.

4.3.1.2. Additional security considerations

This section provides some additional recommendations in order to limit the
information disclosed to third parties to only the necessary one, and hence limit the
provided information in case of security break.
Indeed, the DNS protocol allows not only domain name resolution, but also gives
the possibility to obtain information on servers' hardware and software, in case of
malicious intrusion in a GRX or GPRS network.
Therefore, it is recommended that:
§ Only actually necessary interrogation types (e.g. A and NS for GPRS,
MX for MMS, etc) should be used. Any new type of request should be
subject to prior bilateral agreement.
§ Only "normal", i.e. not reverse (that is obtaining of a DNS name or a
name of another type of machine from an IP address) queries are
necessary in normal operation. Therefore the DNS messages should
exclusively refer to a "normal" query. The DNS reverse resolution may

IR33 Version 3.1.0 Page 11 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

be authorised subject to bilateral agreement if needed (e.g. for

troubleshooting purposes)..

4.3.1.3. DNS Security recommendations

In the case of inter-PLMN DNS interrogation, it is strongly recommended that:
§ Only Iterative interrogation mode as defined in §4.3.1.1 should be used
between GPRS operators' DNS servers
§ A GPRS operator should respond only to DNS queries coming from
roaming partners and should reject any other query. This would
typically be done by protecting DNS servers from external accesses
using a security system (such as a firewall), which allows only
standard DNS protocols (DNS lookup 53/udp).
§ A GPRS operator should respond only to requests concerning his own
APNs, any other requests should be rejected.
§ Ensure DNS servers are running an appropriately secure version of
Bind (i.e. the DNS software) and are up to date with latest security
patches.

Additionally, the following recommendations will help to improve the overall security in
GPRS roaming environment:
§ A GPRS operator should respond only to iterative queries
§ Only requests of type A (name resolution), MX (for MMS) and NS
should be used. Use of any other request type should be subject to
prior bilateral agreement.
§ Only normal domain name resolution queries should be used, i.e.
reverse resolution should be subject to prior bilateral agreement.

4.3.2. Roaming Scenario 2 (VGGSN used) DNS Querying

This scenario is very similar to the case where the user is on the home network, and only
the local DNS is queried. The DNS/IP and GPRS signalling exchanges are carried over the
visited PLMNs GPRS backbone and do not enter the Inter GPRS Backbone network. This
is shown in Figure 5

VPLMN DNS

2 3

VSGSN

BSS
1

IR33 Version 3.1.0 Page 12 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

Figure 5: APN Resolution using DNS in VPLMN

1. The MS send a “PDP Context Activation” message to the VSGSN in the Visited
PLMN. This may or may not include an APN. (If no APN is found a “Default APN” is
resolved to which is contained in the VSGSN)
2. The VSGSN checks the APN against the user subscription record, and generates a
DNS Query (as detailed in GSM 03.60 [1] Annex A). This is sent to the DNS server
address configured in the VSGSN.
3. The VPLMN DNS returns the result to the VSGSN. The SGSN can either use the
VGGSN IP address to connect the user, or fail the context activation (i.e. no IP address
provided).

4.4. The Access Point Name - APN

The Access Point Name contains the user’s and network’s desired routing access
preference and is used to create the logical connection between MS and External PDN.
The APN consists of both :-
• Network ID – points to the access point within a GPRS PLMN
• Operator ID – points to a GPRS PLMN
The complete APN shall be of the format:-
“<network id>.mnc<MNC>.mcc<MCC>.gprs”

Network Id Operator Id
This is all detailed in GSM 03.03 [2].

4.4.1. APN Resolution using the Network Identifier

The APN Network Identifier can refer to different GGSNs in different PLMNs; therefore
a naming convention for Network Identifiers could be agreed between the PLMNs to avoid
conflicts. A conflict occurs if more than one operator uses the same APN for different
external packet data networks causing a roamer to establish a PDP context through the
Visited GGSN instead of the Home GGSN. However, this may be overcome if the roamer
appends the Operator Id of their home network.. (See Figure 6)

IR33 Version 3.1.0 Page 13 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

VPLMN HPLMN

APN:ib .com.mnc789.mcc88.gpr HLR

VPLMN add. allowed

SGSN
DNS

DNS DNS
mnc789.mcc888gprs
mnc123.mcc456gprs

VGGSN HGGSN
AP: ibm.co AP: ibm .co

Figure 6: Subscriber enters Operator Id.

The network operator can force their subscriber to use the Home GGSN by disabling a flag
(VPLMN address allowed) in the HLR on a per APN basis. In this case the roamer will
always use HGGSN access point. (See Figure 7)
VPLMN HPLMN

APN:ib .co HLR

VPLMN add. allowed flag=NO

SGSN
DNS

DNS DNS
mnc789.mcc888gprs
mnc123.mcc456gprs

VGGSN HGGSN
AP: ibm .co AP: ibm .co

Figure 7: Subscriber has APN of ibm.com set with VPLMN allowed flag set to No.

To guarantee the uniqueness of APN network identifiers two solutions are possible: a) using
public Internet domain names, and b) the introduction of internal domain names. Both
solutions can be used in parallel for APN resolution depending on the operator’s
requirements.

IR33 Version 3.1.0 Page 14 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

4.4.1.1. Public Internet Domain Names

The ETSI standard GSM 03.60 states:
“In order to guarantee the uniqueness of APN network identifier within GPRS
PLMNs, an APN Network Identifier containing more than one label corresponds to an
Internet domain name. This name should only be allocated by the PLMN to an
organisation that has officially reserved this name on the Internet.”
This proposal has the disadvantages that the customer (company or ISP) is responsible for
the uniqueness of the APN Network Identifier. The correct operation of the GPRS service
depends on the careful behaviour of the customers.
In particular problems can occur if a company or ISP is registered in a generic top-level-
domain (.com or .net for example). These companies may request the same network
identifier in different GPRS networks. This problem becomes more visible with countries
offering National Roaming. (See Figure 8)
VPLMN HPLMN

APN:ib .co HLR

VPLMN add. allowed flag=YES

DNS
SGSN

DNS DNS
mnc789.mcc888 gprs
mnc123.mcc456gprs

VGGSN HGGSN
AP: ibm .co AP: ibm .co

Figure 8: Visited and Home network have IBM.com as a registered Network Id

4.4.1.2.Internal GPRS Domain Names

To overcome the problem of public Internet domain names, the GSM Association owns an
internal naming convention for APN network identifiers.. The domain names shall be listed
in the permanent document SE.20 “GPRS and WAP Service Guidelines” [10].

4.4.2. Service APN

The Service APN is recognised by the APN Network Id name being just one label without
separating dots. This way a Service APN can be differentiated from a normal Network Id
which is separated by at least one dot.
The Service APN when sent from the user is resolved by the DNS, allowing the SGSN to
connect the user to a suitable GGSN supporting the requested service. The services to be
supported, and their Service APN names is described in [10]
If the service is not supported in the visited network, a GGSN in the home network will be
used instead. The service APN is added in the DNS, eventually with several IP address

IR33 Version 3.1.0 Page 15 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

resolutions. In this case the IP address resolved to could vary dependent on the SGSN that
makes the request (location based) or dependent on the workload of the GGSN.
The GGSN which the service APN has resolved to must provide the service agreed upon
as specified by SERG “GPRS Service Support” document.
The service APN may provide a subscriber with transparent access to the service
requested, thus removing the requirement for authentication, policing or packet filtering
whether a public or private IP address is being used.
No guaranteed quality of service can be associated with a Service APN.

4.4.3. Wildcard APN

A Wildcard APN is an APN which contains a wildcard character ‘*’ stored in the
subscribers profile in the HLR. This allows the Wildcard functionality i.e. enabling any
Network Id or Operator Id to substitute the wildcard character in an APN, when access
rights to the Access Point are checked in the procedure to establish a PDP context. The
wildcard functionality may be used by an operator to provide service APN resolution.
GGSN’s have the ability to recognise if a subscriber is using the wildcard functionality, and
may block the attempted PDP context activation. This is a security mechanism which
would block subscribers attempting to fraudulently access PDN’s which are not in their
own subscriber profile. This function uses the “Selection Mode” field, which is included in
the PDP Context Activation Request message.

4.5. GPRS Routing Area Identities

In explaining how GPRS utilises the DNS to find the IP address of old SGSNs based around
their ‘logical address’ GSM 09.60 Annex A.1 states:
“When an MS roams between two SGSNs within the same PLMN, the new SGSN finds
the address to the old SGSN by the association old RA - old SGSN. Thus, each SGSN
knows the address to every other SGSN in the PLMN.
When an MS roams from an SGSN to an SGSN in another PLMN, the new SGSN may
not itself have access to the address to the old SGSN. Instead, the SGSN transforms
the old RA information to a logical name of the form:
RACxxxx.LACyyyy.MNCzzzz.MCCwwww.GPRS; x,y,z and w shall be Hex coded
digits.
The SGSN may then acquire the IP address of the old SGSN from a DNS server, using
the logical address. Every PLMN should include one DNS server each. Note that
these DNS servers are GPRS internal entities, unknown outside the GPRS system.”
and later:
“Introducing the DNS concept in GPRS gives a general possibility to use logical
names instead of IP addresses when referring to e.g. GSNs, thus providing flexibility
in addressing of PLMN nodes.

IR33 Version 3.1.0 Page 16 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

5. IP Address Management
5.1. IP Nodal Address Allocation
IP address management is described in IR.34: “Inter-PLMN Backbone Guidelines” [8].
Each node, which has access to the Inter PLMN Backbone, shall have unique addresses.
These can be registered Public IP Addresses, which are managed and distributed by a
single management entity. GSM 03.60 states:-
“The IP addresses of GSNs and other GPRS backbone nodes of all PLMNs build a
private address space that is not accessible from the public Internet. For the GGSN
and the SGSN, this IP address may also correspond to one or more DNS-type logical
GSN names.”

5.2. User IP Address Allocation

The user’s IP address is allocated at “PDP context activation”. These IP addresses are
not associated with the PLMN backbone IP addresses. The user can either have a Static
or Dynamic address allocated, and this is valid the whole time the user has the context
activated.

5.2.1. Static User IP Address Allocation

Static User IP Address allocation is strongly discouraged, as it will restrict a user whilst
roaming.
A Static User Address is mapped to a user, and held in the user’s subscription record within
the HLR. A copy of the users subscription details are sent to the SGSN at “GPRS Attach”.
At PDP Context Activation, this address is passed to the HGGSN in order for it to be used
to create the correct routing table entry in the HGGSN PDP Context Record. If the user is
able to use the Static IP address (after certain “data checks” have occurred, i.e. checking if
the APN used only allows a specific user IP address, in order to allow the context
activation), then it is returned to the MS at “PDP Context Activation Accept”. A Static
user IP address will restrict the user to only use PDP contexts in their HPLMN (HGGSN)
with specified APNs. The user will have to have an IP address dynamically allocated by
the VPLMN in order to allow use of local PDP contexts through a VGGSN.

5.2.2. Dynamic User IP Address Allocation

A Dynamic User Address is mapped to a user only at context activation, and could possible
change with each new “PDP Context Activation”. The SGSN shall pass an “empty” PDP
Address field to the GGSN at “PDP Context Request” to request a dynamic address from
the GGSN. The GGSN can either: -
• allocate the same address from a “pool” at every PDP context activation
• allocate an address randomly picked from an “address pool” at every PDP context
activation.
This address is then returned to the MS at “PDP Context Activation Accept”.

5.3. IP Addresses Management and Allocation

IP addresses can be classified as one of two types: -

IR33 Version 3.1.0 Page 17 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

• Public IP Addresses
• Private IP Address

5.3.1. Public IP Addresses

The ‘Internet Naming & Addressing Authority’ (IANA - http://www.iana.org/) has
authority over all number spaces used in the Internet. This includes IP address space. (In
the future the authority is going to move to ‘Internet Corporation for Assigned Names and
Numbers’ (ICANN – http://www.ican.org/).) IANA allocates public Internet address space
to Regional Internet Registries e.g. for Europe this is RIPE –(http://www.ripe.net/).
Public IP addresses make up the Internet address space. They are assigned to be globally
unique. The main purpose of this address space is to allow end to end communications using
the Internet. The Internet is only aware of public addresses, and can only route public
addresses.
A secondary purpose is to allow communications over interconnected private Intranets.

5.3.2. Private IP Addresses

Some address ranges have been set aside for the operation of private networks using IP.
Anyone can use these addresses in their private networks without any registration or co-
ordination. Hosts using these addresses can not be reached from the Internet. For a
thorough description of private address space, please refer to IETF RFC 1918 [7].

6. Border Gateways
6.1. Introduction
The Border Gateway’s (BG) main purpose is to preserve the security of the PLMN’s
GPRS network from: -
• Unwanted traffic / signalling from other GPRS PLMNs
• Inter PLMN Backbone traffic from a fraudulent source (IP attacks.)
The Border Gateway may provide: -
• Inter Network Secure Tunnelling and encryption. This may be established on a per-
roaming agreement basis to maintain the security of the data being transferred between
PLMNs.

7. Information Exchange For GPRS Roaming

7.1. DNS Information
The VPLMN GPRS DNS shall be able to locate the HPLMN via the use of the HPLMN
Operator ID part of the APN.
Upon roaming agreement establishment, the VPLMN shall either: -
• Insert data into the VPLMN DNS to allow the DNS queries with APNs ending in the
Operator ID of the HPLMN, to be forwarded to the HPLMN’s DNS system,
or

IR33 Version 3.1.0 Page 18 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

• Use the “.gprs ” root DNS to locate the IP addresses of the HPLMN’s DNS servers,
for resolution.
The data exchange at roaming agreement establishment may include the Primary and
Secondary DNS IP addresses, or this information may be held by the “.gprs ” root DNS.
This is also detailed in PRD IR.21 [12].

7.2. IMSI - HLR Address Mapping

PLMNs wishing to support inbound GPRS roamers must be provided with: -
• IMSI code (MCC + MNC) to HLR Global Title (E.164 number) mapping. (Note 3)
This is detailed in GSM 09.02, and is used today to allow MSCs to communicate with
HLRs for GSM circuit switched voice / data roaming today.
Note 3: Applies only to GSM900 & 1800 network operators. IMSI – HLR Global Title
mapping is not applicable for North American PCS1900 network operators.
This information must also be reciprocated with the other networks to allow “outbound
GPRS roaming”.

7.3. GPRS Nodal Addressing Range

The VPLMN shall provide the HPLMN the IP address ranges that the VPLMNs SGSNs,
GGSNs and DNSs will use when communicating over the Inter PLMN GPRS Backbone.
This may be used in the Border Gateway to allow Inter DNS, Inter GSN signalling and
GPRS Data to pass into the HPLMN.

8. References
[1] GSM 03.60 : - "Digital cellular telecommunications system (Phase 2+); GPRS Service
Description; Stage 2 ", ETSI.
[2] GSM 03.03 : - "Digital cellular telecommunications system (Phase 2+); Numbering,
addressing and identification", ETSI.
[3] GSM 09.02 : - "Digital cellular telecommunications system (Phase 2+); Mobile
Application Part (MAP) specification”, ETSI.
[4] GSM 09.60 : - "Digital cellular telecommunications system (Phase 2+); General Packet
Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp
Interface", ETSI.
[5] IETF RFC 1034 "Domain Names – Concepts and Facilities"
[6] IETF RFC 1035 “ Domain Names – Implementation and Specification”
[7] IETF RFC 1918 “Address Allocation for Private Intranets”
[8] PRD IR.34: “Inter-PLMN Backbone Guidelines”
[9] PRD IR.35: “End to End Functional Capability specification for Inter-PLMN GPRS
Roaming”
[10] PRD SE.20 “GPRS and WAP Service Guidelines”
[11] PRD BA.27
[12] PRD IR.21

IR33 Version 3.1.0 Page 19 of 15

GSM Association Unrestricted - Industry
Permanent Reference Document:
IR.33

IR33 Version 3.1.0 Page 20 of 15