Roaming Techology

GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.2.0 Page 1 of 15
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
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 2 of 15
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.
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 3 of 15
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. THE ACCESS 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 AREA IDENTITIES.............................................................................................................16
5. IP ADDRESS MANAGEMENT.............................................................................................................................17
5.1. IP NODAL ADDRESS ALLOCATION .............................................................................................................17
5.2. USER IP ADDRESS ALLOCATION .................................................................................................................17
5.2.1. Static User IP Address Allocation.........................................................................................................17
5.2.2. Dynamic User IP Address Allocation ...................................................................................................17
5.3. IP ADDRESSES MANAGEMENT AND ALLOCATION..................................................................................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 ADDRESS MAPPING..................................................................................................................19
7.3. GPRS NODAL ADDRESSING RANGE.............................................................................................................19
8. REFERENCES..........................................................................................................................................................19
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 4 of 15
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.
Gf
D
Gi
Gn
Gb
Gc
E C
Gp
Gs
Signalling and Data Transfer Interface
Signalling Interface
MSC/VLR
TE MT BSS PDN TE
R Um
Gr
A
HLR
Other PLMN
SGSN
GGSN
Gd
SM-SC
SMS-GMSC
SMS-IWMSC
GGSN
EIR
SGSN
Gn
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
IR33 Version 3.1.0 Page 5 of 15
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. VSGSN
HGGSN
The Inter GPRS
Backbone
Roaming MS
BG BG
External PDN
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
IR33 Version 3.1.0 Page 6 of 15
· 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
VSGSN
VGGSN
Visited PLMN’s
GPRS Backbone
Roaming MS
External PDN
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
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 7 of 15
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
IR33 Version 3.1.0 Page 8 of 15
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.
VSGSN
BSS
VPLMN DNS HPLMN DNS
GPRS “Root” DNS
The Inter GPRS
Backbone -
Private IP
2 5
2a
4
3
BG
BG
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.
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 9 of 15
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
BG
VSGSN
BG
HGGSN
VGGSN
HSGSN
VSGSN
HSGSN
VPLMN
DNS-Gn HPLMN
DNS-Gn
DNS Root
VPLMN
HPLMN
GRX
3
5
1
6
2
7 4
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
IR33 Version 3.1.0 Page 10 of 15
BG
VSGSN
BG
HGGSN
VGGSN
HSGSN
VSGSN
HSGSN
VPLMN
DNS-Gn HPLMN
DNS-Gn
DNS Root
VPLMN
HPLMN
GRX
1
6
2
3
5
7
4
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
IR33 Version 3.1.0 Page 11 of 15
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.
BG
BG
HPLMN
DNS-Gn PLMN 1
DNS -Gn
DNS Root 1
HPLMN
PLMN 1
GRX 1
BG
BG
PLMN 2
DNS-Gn
DNS Root 2
PLMN 2
GRX 2
2
3
1
4
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
IR33 Version 3.1.0 Page 12 of 15 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
1
BSS
VSGSN
VPLMN DNS
2 3
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 13 of 15
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:-
“.mnc.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
IR33 Version 3.1.0 Page 14 of 15
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)
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. SGSN
VGGSN
AP: ibm.co
DNS
mnc123.mcc456gprs
DNS
mnc789.mcc888gprs
HGGSN
AP:ibm.co
HLR
VPLMN HPLMN
APN:ib .com.mnc789.mcc88.gpr
DNS
SGSN
VGGSN
AP: ibm.co
DNS
mnc123.mcc456gprs
DNS
mnc789.mcc888gprs
HGGSN
AP: ibm.co
HLR
VPLMN HPLMN
APN:ib .co
VPLMN add. allowed flag=NO
DNS
VPLMN add. allowed
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 15 of 15
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-leveldomain
(.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)
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
SGSN
VGGSN
AP:ibm.co
DNS mnc123.mcc456gprs DNS mnc789.mcc888gprs HGGSN
AP: ibm.co
HLR
VPLMN HPLMN
APN:ib .co
VPLMN add. allowed flag=YES
DNS
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 16 of 15 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
IR33 Version 3.1.0 Page 17 of 15
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: -
GSM Association
Permanent Reference Document:
IR.33
Unrestricted - Industry
IR33 Version 3.1.0 Page 18 of 15
· 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 coordination.
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 perroaming 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
IR33 Version 3.1.0 Page 19 of 15
· 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
IR33 Version 3.1.0 Page 20 of 15