09.613GPPGeneral Packet Radio Service (GPRS)Interworking between the Public Land Mobile Network (PLMN) supporting GPRS and Packet Data Networks (PDN)TS
GPRS shall support interworking with networks based on the Internet Protocol (IP). These interworked networks may be either intranets or the Internet.
11.2 PDN Interworking Model
When interworking with the IP networks, GPRS can operate IPv4 or IPv6. The interworking point with IP networks is at the Gi reference point as shown in figure 7.
Figure 7: IP network interworking
The GGSN for interworking with the IP network is the access point of the GSM GPRS data network (see figure 8). In this case the GPRS network will look like any other IP network or subnetwork.
Figure 8: The protocol stacks for the GiIP reference point
Typically in the IP networks, the interworking with subnetworks is done via IP routers. The Gi reference point is between the GGSN and the external IP network. From the external IP network’s point of view, the GGSN is seen as a normal IP router. The L2 and L1 layers are operator specific.
It is out of the scope of the present document to standardise the router functions and the used protocols in the Gi reference point.
Interworking with user defined ISPs and private/public IP networks is subject to interconnect agreements between the network operators.
No user data or header compression is done in the GGSN.
The following working assumptions are valid in the generic case:
– A firewall is configured by the GPRS operator. In general, all applications that are using IP as the underlying protocol are supported, but the GPRS operator may restrict their usage.
– A Domain Name Server is managed by the GPRS operator. Alternatively, the Domain Name Server can be managed by the external IP network operator.
– From the GPRS network’s point of view, the allocation of a dynamic IP address is done by the GGSN as described in 3GPP TS 03.60 . The GGSN may allocate these addresses by itself or use an external device such as an DHCP server. This external device may be operated by an external organisation such as an ISP or Intranet operator.
11.2.1 Access to Internet, Intranet or ISP through GPRS
The access to Internet, Intranet or ISP may involve specific functions such as : user authentication, user’s authorization, end to end encryption between MS and Intranet/ISP, allocation of a dynamic address belonging to the PLMN/Intranet/ISP addressing space, etc.
For this purpose the GPRS PLMN may offer:
– either direct transparent access to the Internet; or
– a non transparent access to the Intranet/ISP. In this case the GPRS PLMN, i.e. the GGSN, takes part in the functions listed above.
220.127.116.11 Transparent access to the Internet
Figure 9: Example of the PDN Interworking Model, transparent case
In this case (see figure 9):
– The MS is given an address belonging to the operator addressing space. The address is given either at subscription in which case it is a static address or at PDP context activation in which case it is a dynamic address. This address is used for packet forwarding between the Internet and the GGSN and within the GGSN.
– The MS need not send any authentication request at PDP context activation and the GGSN need not take any part in the user authentication/authorization process.
The transparent case provides at least a basic ISP service. As a consequence of this it may therefore provide a bearer service for a tunnel to a private Intranet.
NB The remainder of this subclause deals with this specific case.
– The user level configuration may be carried out between the TE and the intranet, the GPRS network is transparent to this procedure.
The used protocol stack is depicted in figure 10.
Figure 10: Transparent access to an Intranet
The communication between the GPRS PLMN and the Intranet may be performed over any network, even an insecure network e.g. the Internet. There is no specific security protocol between GGSN and the Intranet because security is ensured on an end to end basis between MS and the intranet by the "Intranet Protocol".
User authentication and encryption of user data are done within the "Intranet Protocol" if either of them is needed. This "Intranet Protocol" may also carry private (IP) addresses belonging to the address space of the Intranet.
An example of an "Intranet Protocol" is IPsec (see RFC 1825 ). If IPsec is used for this purpose then IPsec authentication header or security header may be used for user (data) authentication and for the confidentiality of user data (see RFC 1826  and RFC 1827 ). In this case private IP tunnelling within public IP takes place.
18.104.22.168 Non Transparent access to an Intranet or ISP
In this case:
– the MS is given an address belonging to the Intranet/ISP addressing space. The address is given either at subscription in which case it is a static address or at PDP context activation in which case it is a dynamic address. This address is used for packet forwarding within the GGSN and for packet forwarding on the Intranet/ISP. This requires a link between the GGSN and an address allocation server, like Radius, DHCP, …, belonging to the Intranet/ISP;
– the MS shall send an authentication request at PDP context activation and the GGSN requests user authentication from a server, like Radius, DHCP, …, belonging to the Intranet/ISP;
– the protocol configuration options are retrieved (if requested by the MS at PDP context activation) from some server (Radius or DHCP, …) belonging to the Intranet/ISP;
– the communication between the GPRS PLMN and the Intranet/ISP may be performed over any network, even an insecure e.g. the Internet. In case of an insecure connection between the GGSN and the Intranet/ISP there may be a specific security protocol in between. This security protocol is defined by mutual agreement between GPRS PLMN operator and Intranet/ISP administrator.
Figure 11: Signalling plane of non transparent case
The following description bullet items describe the signal flow.
1) The TE sends an AT-command to the MT to set up parameters and enter PPP mode. The MT responds with an AT-response.
2) LCP negotiates Maximum-Receive-Unit and authentication protocol. The negotiated authentication protocol is, either CHAP, PAP or ‘none’. The MT shall try to negotiate for CHAP as first priority.
3) If the negotiated authentication protocol is either of CHAP or PAP, the TE authenticates itself towards the MT by means of that protocol. The MT stores the necessary authentication data and sends a forced positive acknowledgement of the authentication to the TE.
4) The TE requests IP configuration by sending the IPCP Configure-Request message to the MT indicating either the static IP address that shall be used or that an IP-address shall be dynamically allocated.
5) The MT sends the Activate PDP context request message to the SGSN, including the Protocol Configuration Options. The SGSN sends the Create PDP context req message to the chosen GGSN including the unmodified Protocol Configuration Options.
6) The GGSN deduces from the APN:
– the server(s) to be used for address allocation, authentication and protocol configuration options retrieval;
– the protocol like Radius, DHCP, … to be used with this / those server(s);
– the communication and security feature needed to dialogue with this / those server(s) e.g. tunnel ,IPSec security association, dial-up connection (using possibly PPP), ….
As an example the GGSN may use one of the following options:
– RADIUS for authentication and IP-address allocation.. The RADIUS server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN.
– RADIUS for authentication and DHCP for host configuration and address allocation. The RADIUS server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN. After a successful authentication, the DHCP client discovers the DHCP server(s) in the ISP/Intranet and receives host configuration data.
If the received Protocol Configurations Options IE contains a PPP IPCP Configure-Request packet, the GGSN shall analyse all the contained IPCP options and their requested values. In accordance with the relevant PPP RFC 1661 the GGSN shall respond with the following messages:
– zero or one PPP IPCP Configure-Reject packet containing options not supported and options which values cannot be returned;
– zero or one PPP IPCP Configure-Nak packet containing options that are supported but has requested values that are incorrect/unsupported; and
– zero or one PPP IPCP Configure-Ack packet containing options that are supported and has requested values that are correct/supported.
Any returned PPP IPCP packets shall be contained in the Protocol Configurations Options IE.
7) The GGSN sends back to the SGSN a Create PDP Context Response message, containing the Protocol Configuration Options IE. The cause value shall be set according to the outcome of the host -authentication and -configuration. A PDP context activation shall not be rejected solely due to the presence of unsupported or incorrect PPP IPCP options or option values, received from the MS in the Protocol Configurations Options IE. The MS may however later decide to immediately deactivate the activated PDP context due to the information received in the Protocol Configurations Options IE received from the network.
8) Depending on the cause value received in the Create PDP Context Response the SGSN sends either an Activate PDP Context Accept or an Activate PDP Context Reject, to the MS.
If Protocol Configuration Options are received from the GGSN, the SGSN shall relay those to the MS. The MT sends either the configuration-ack packet (e.g. IPCP Configure Ack in PPP case), the configure-nak packet in case of dynamic address allocation (e.g. IPCP Configure Nak in PPP case), or a link Terminate request (LCP Terminate-Request in PPP case) back to the TE. In the case where a configure-nak packet was sent by the MT, a local negotiation may take place at the R reference point (i.e. the TE proposes the new value to the MT), after which a configuration-ack packet is sent to the TE.
9) In case a configuration-ack packet was sent to the TE, the link from the TE to the external ISP/Intranet is established and IP packets may be exchanged.
In case a link terminate request packet was sent to the TE, the TE and MT negotiates for link termination. The MT may then send a final AT-response to inform the TE about the rejected PDP Context activation.
A link terminate request packet (such as LCP Terminate-request in PPP case) causes a PDP context deactivation.
EXAMPLE: In the following example PPP is used as layer 2 protocol over the R reference point (figure 11a).
The MT acts as a PPP server and translates Protocol Configuration Options into SM message IEs. GTP carries this information unchanged to the GGSN which uses the information e.g. for DHCP or RADIUS authentication and host configuration. The result of the host authentication and configuration is carried via GTP to the SGSN which relays the information to the MT. The MT sends an IPCP Configure-Ack to the TE with the appropriate options included.
Figure 11a: Example where PPP is used as layer 2 protocol over the R reference point
11.3 Numbering and Addressing
In the case of interworking with the public IP networks (such as the Internet), the GPRS operator shall use public network addresses. These public addresses can be reserved from the responsible IP numbering body, or from an ISP with which the GPRS operator has an agreement. In the case of interworking with the private IP networks, the GPRS operator manages internally the subnetwork addresses.
The GPRS operator allocates the IP addresses for the subscribers in either of the following ways.
– The GPRS operator allocates a static IP address when the subscription record is built. The IP address is reserved from a pool of free IP addresses.
– The GPRS operator allocates (either on its own or in conjunction with an ISP) a dynamic IP address when the MS performs the PDP Context Activation procedure with dynamic address allocation as described in 3GPP TS 03.60 .
The GPRS operator may define the accuracy of the charging mechanism using one of the following categories:
– Every source/destination pair is logged separately.
– Source/destination pairs are logged to an accuracy of subnetworks.
– Source/destination pairs are logged to an accuracy of connection types (e.g. external data network, corporate network, another mobile).
11.5 Domain Name Server (DNS)
Provision of Domain Name services shall be provided by the GPRS operators in the transparent case and the ISP in the non transparent case. Domain name registration is handled by RIPE (Réseaux IP Européens) in Europe (DNS documentation is provided in RFC 1034  and RFC 1035 ).
The way the GPRS operator is performing the operator controlled screening and the subscription controlled screening is out of the scope of the present document. These functions may be done, for example, in a firewall.