Вы находитесь на странице: 1из 20

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

Reference Document: IR.33 Unrestricted - Industry PRD IR.33 Title GPRS Roaming Guidelines Version

PRD IR.33

Title

GPRS Roaming Guidelines

Version

3.2.0

Date

3 rd April 2003

GSM Association Classifications

Non-Binding

Core

Security Classification Category:

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 (5 th 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

27 th 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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

1. INTRODUCTION

4

1.1.

MS REGISTRATION AND CONTEXT ACTIVATION 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.

T HE A CCE SS 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 MANAGEMENT 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 MAPPING

19

7.3. GPRS NODAL A DDRESSING RANGE

19

8. REFERENCES

19

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 SM-SC SMS-IWMSC E C Gd MSC/VLR HLR D Gs A Gc Gr Gb Gi
SMS-GMSC
SM-SC
SMS-IWMSC
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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 BG BG
VSGSN
The Inter GPRS
Backbone
BG
BG
External PDN
External PDN

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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
VSGSN
Visited PLMN’s
GPRS Backbone
External PDN
External PDN
VGGSN VSGSN Visited PLMN’s GPRS Backbone External PDN Roaming MS Figure 3: Scenario 2 - VSGSN

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

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

i.e.

.com, .org etc. Logical “domain names” allow

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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).

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 3 4 VPLMN DNS BG The Inter GPRS BG 2 5
GPRS “Root” DNS
2a
3
4
VPLMN DNS
BG
The Inter GPRS
BG
2
5 Backbone -
Private IP
VSGSN

BSS

1The Inter GPRS BG 2 5 Backbone - Private IP VSGSN BSS HPLMN DNS Figure 4:

HPLMN DNS

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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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

1
1

VPLMN

DNS-Gn

DNS Root

HPLMN

DNS-Gn

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

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

VPLMN DNS Root DNS-Gn 1 HPLMN 3 DNS-Gn 2 4 VSGSN 7 5 VPLMN HSGSN
VPLMN
DNS Root
DNS-Gn
1
HPLMN
3
DNS-Gn
2
4
VSGSN
7
5
VPLMN
HSGSN
BG
6 GRX
BG
HPLMN
VGGSN
VSGSN
HSGSN
HGGSN

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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 PLMN 1 4 DNS -Gn GRX 2 BG
PLMN 2
DNS Root 2
1
BG
PLMN 1
4
DNS -Gn
GRX 2
BG
PLMN 1

HPLMN

DNS Root 1

DNS-Gn 2 HPLMN BG 3 BG GRX 1
DNS-Gn
2
HPLMN
BG
3 BG
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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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

2 3
2
3

BSS

the Inter GPRS Backbone network. This is shown in Figure 5 2 3 BSS 1 VPLMN

1

VPLMN DNS

VSGSN

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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
“<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)

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

VPLMN HPLMN HLR APN:ib .com.mnc789.mcc88.gpr VPLMN add. allowed SGSN DNS DNS DNS mnc789.mcc888 gprs
VPLMN
HPLMN
HLR
APN:ib .com.mnc789.mcc88.gpr
VPLMN add. allowed
SGSN
DNS
DNS
DNS
mnc789.mcc888 gprs
mnc123.mcc456 gprs
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 HLR APN:ib .co VPLMN add. allowed flag=NO SGSN DNS DNS DNS mnc789.mcc888 gprs
VPLMN
HPLMN
HLR
APN:ib .co
VPLMN add. allowed flag=NO
SGSN
DNS
DNS
DNS
mnc789.mcc888 gprs
mnc123.mcc456 gprs
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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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 APN:ib .co SGSN DNS DNS mnc123.mcc456 gprs VGGSN AP:ibm.co
VPLMN
APN:ib
.co
SGSN
DNS
DNS
mnc123.mcc456 gprs
VGGSN
AP:ibm.co

HPLMN

HLR
HLR

VPLMN add. allowed flag=YES

DNS

mnc789.mcc888 gprs

HGGSN

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

in the permanent document SE.20 “GPRS and WAP Service Guidelines” [10].

The domain names shall be listed

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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.

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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

Dynamic address allocated, and this is valid the whole time the user has the context activated.

or

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: -

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry

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

GSM Association Permanent Reference Document:

IR.33

Unrestricted - Industry