11.2.1 Access to Internet, Intranet or ISP through Packet Domain

29.0613GPPInterworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)Release 17TS

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, IPv6 address autoconfiguration, etc.

For this purpose the Packet Domain may offer:

– either direct transparent access to the Internet; or

– a non transparent access to the Intranet/ISP. In this case the Packet Domain, i.e. the GGSN/P-GW, takes part in the functions listed above.

The mechanisms for host configuration and user authentication described in this subclause and its subclauses are applicable for the initial IP-CAN session establishment to allocate IP addresses (IPv4 and/or IPv6) to the MS. For GTP based access, the activation of any subsequent IP-CAN bearers for that IP-CAN session, (i.e.secondary PDP context activation Procedure’, dedicated bearer activation), as well as the use of TFTs, is described in 3GPP TS 23.060 [3], 3GPP TS 23.401 [77].

11.2.1.1 Transparent access to the Internet

Figure 9: Example of the PDN Interworking Model, transparent case

In figure 9, an example PDN interworking model for transparent access to the Internet is provided for a GGSN and its Gi reference point.

In transparent access to the Internet case:

– the MS is given an IPv4 address and/or an IPv6 prefix belonging to the operator addressing space. The IPv4 address and/or IPv6 prefix is assigned either at subscription in which case it is a static address or at IP-CAN session establishment in which case it is a dynamic address. This IPv4 address and/or IPv6 prefix if applicable is used for packet forwarding between the Internet and the GGSN/P-GW and within the packet domain. With IPv6, Stateless Address Autoconfiguration shall be used to assign an IPv6 address to the MS. These procedures are as described in the IPv6 non-transparent access case except that the addresses belong to the operator addressing space.

– the MS need not send any authentication request at IP-CAN session establishment procedure and the GGSN/P-GW 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.

Note that the remainder of this subclause deals with this specific use-case as depicted in figure 10.

– The user level configuration may be carried out between the TE and the intranet, the Packet Domain network is transparent to this procedure.

The used protocol stack is depicted in figure 10.

Figure 10: Transparent access to an Intranet

In figure 10, an example for transparent access to an Intranet is provided for a GGSN and its Gi reference point, but the same principle is applicable to EPC.

The communication between the 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 the GGSN and the Intranet because security is ensured on an end to end basis between the 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 [61]). 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 [62] and RFC 1827 [63]). In this case private IP tunnelling within public IP takes place.

11.2.1.2 IPv4 Non Transparent access to an Intranet or ISP

11.2.1.2.1 non-EPC based IPv4 Non Transparent access

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 AAA, 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 AAA, DHCP, …, belonging to the Intranet/ISP;

– the protocol configuration options are retrieved (if requested by the MS at PDP context activation) from some server (AAA or DHCP, …) belonging to the Intranet/ISP;

– the communication between the Packet Domain 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 PLMN operator and Intranet/ISP administrator.

Figure 11a: Signalling plane of non transparent case

NOTE: The transport protocol UDP is used for DHCP and RADIUS, and TCP or SCTP are used for Diameter.

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 AAA 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 AAA 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 [21a] and RFC 1662 [21b] 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-nack packet in case of dynamic address allocation (e.g. IPCP Configure Nack in PPP case), or a link Terminate request (LCP Terminate-Request in PPP case) back to the TE. In the case where a configure-nack 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.

The MT acts as a PPP server and translates Protocol Configuration Options into SM message Ies. GTP-C 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-C 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 11b: PDP Context Activation for the IPv4 Non-transparent case

11.2.1.2.2 EPC based IPv4 Non Transparent access

In this case:

– a static or a dynamic IPv4 address belonging to the Intranet/ISP addressing space is allocated to a UE at IP-CAN session establishment. The methods of allocating IP address to the UE are specified in 3GPP TS 23.060 [3], 3GPP TS 23.401 [77] and 3GPP TS 23.402 [78]. The allocated IPv4 address is used for packet forwarding within the P-GW and for packet forwarding on the Intranet/ISP;

– as a part of the IP-CAN session establishment, the P-GW may request user authentication from an external AAA server (i.e. RADIUS, Diameter) belonging to the Intranet/ISP;

– the IPv4 address allocation to the UE may be performed based on the subscription or a local address pool, which belongs to the Intranet/ISP addressing space, provisioned in the P-GW. The IPv4 address allocation to the UE may also be done via the address allocation servers (i.e. DHCPv4, RADIUS AAA, Diameter AAA) belonging to the Intranet/ISP;

– if requested by the UE at IP-CAN session establishment, the P-GW may retrieve the Protocol Configuration Options or IPv4 configuration parameters from a locally provisioned database in P-GW and/or from some external server (i.e. DHCPv4, RADIUS AAA, Diameter AAA) belonging to the Intranet/ISP;

– the communication between the Packet Domain and the Intranet/ISP may be performed over any network, even an insecure network ,e.g. the Internet. In case of an insecure connection between the P-GW and the Intranet/ISP, there may be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN operator and Intranet/ISP administrator.

Table 0 summarizes the IPv4 address allocation and parameter configuration use cases between the UE and the P-GW that may lead the P-GW to interwork with the external DHCPv4, RADIUS AAA and Diameter AAA servers over Sgi reference point. For detailed description of the signalling flows between the UE and the P-GW, see the references in the table. The detailed description of the signalling use cases that may be triggered between the P-GW and the external servers are specified in this document, as referenced in the table.

Table 0 : IPv4 address allocation and parameter configuration use cases

Signalling use cases between UE and P-GW

Signalling use cases between P-GW and external servers

Authentication via RADIUS or Diameter server (Clauses 16 or 16a)

(NOTE 1,2,5)

IPv4 Address allocation via DHCPv4 or RADIUS or Diameter server (Clauses 13.3, 16 or 16a)

(NOTE 1 and 2)

IPv4 parameter configuration via DHCPv4 or RADIUS or Diameter server
(Clauses 13.3, 16 or 16a)

(NOTE 1 and 2)

(1) IPv4 address allocation and parameter configuration via default bearer activation

(2) IPv4 address allocation and parameter configuration via DHCPv4 signalling from UE towards P-GW (NOTE 3 and 4)

deployment options applicable to both use cases (1) and (2):

– GTP-based S5/S8 (Subclauses 5.3.1, 5.3.2, 5.10.2 in TS 23.401 [77])

– PMIP-based S5/S8 (Subclauses 4.7.1, 5.2, 5.6 in TS 23.402 [78])

X

X

X

(3) IPv4 adress allocation and parameter configuration during primary PDP context activation using S4-based SGSN

(4) IPv4 address allocation and parameter configuration using DHCPv4 signalling from UE towards P-GW (NOTE 3 and 4)

and using

– GTP-based S5/S8 (Subclauses 9.2, 9.2.2.1A in TS 23.060 [3])

– PMIP-based S5/S8 (Subclauses 4.7.1, 5.2, 5.6, 5.10 in TS 23.402 [78])

X

X

X

(5) IPv4 address allocation in trusted non-3GPP IP access using on S2a (NOTE 4)

– PMIPv6 (Subclauses 4.7.2, 6.2.1, and 6.2.4 in TS 23.402 [78])

– GTPv2 (Subclauses 16.1.5, and 16.2 in TS 23.402 [78])

and using

– achoring in P-GW

– chained S2a and PMIP-based S8

(6) IPv4 address allocation in trusted non-3GPP IP access using MIPv4 FACoA on S2a and anchoring in P-GW (NOTE 4)
(Subclause 6.2.3 of TS 23.402 [78])

(7) IPv4 address allocation and parameter configuration via DHCPv4 signalling in non-3GPP IP access on S2a (NOTE 3 and 4)
(Subclauses 4.7.2 in TS 23.402 [78])

X

X

X

(8) IPv4 address allocation and parameter configuration in untrusted non-3GPP IP access using on S2b (NOTE 4)

– PMIPv6 (Subclauses 4.7.3, 7.2.1, and 7.2.3 in TS 23.402 [78])

– GTPv2 (Subclauses 7.2.4 in TS 23.402 [78])

and using

– anchoring in P-GW

– chained S2b and PMIP-based S8

X

X

X

(9) IPv4 parameter configuration via DHCPv4 with DSMIPv6 on S2c (Subclauses 4.7.4 in TS 23.402 [78])

(10) IPv4 address allocation with DSMIPv6 on S2c

– in trusted non-3GPP IP access

– in untrusted non-3GPP IP access

(Subclauses 4.7.4, 6.3 and 7.3 of TS 23.402 [78])

X

X

X

NOTE 1: When the P-GW interworks with AAA servers, the APN may be configured to interwork with either Diameter AAA or RADIUS AAA server.

NOTE 2: If RADIUS AAA or Diameter AAA server is used, the authentication, IPv4 address allocation and parameter configuration signalling may be combined. Similarly, if DHCPv4 server is used for IPv4 address allocation and parameter configuration, the signalling towards the DHCPv4 server may be combined.

NOTE 3: If the authentication procedure towards RADIUS AAA or Diameter AAA is required, it is performed by the PGW before the DHCPv4 signalling when it receives the initial access request (e.g. Create Session Request, or Proxy Binding Update).

NOTE 4: For PMIP-based S5/S8, S2a and S2b, the P-GW shall obtain the IPv4 address from the external server after receiving Proxy Binding Update and before sending the Proxy Binding Ack. See 3GPP TS 23.402 [78] for details.

NOTE 5: The UEs may provide PAP/CHAP user credentials in the PCO IE when accessing to EPS on 3GPP and non-3GPP IP accesses. If such information is provided to the P-GW, the P-GW may perform user authentication based on these credentials. For S2c, the P-GW may receive such credentials from the UE based on IETF RFC 4739 [91] during the establishment of security association signalling via IKEv2. For S2b, the UEs may provide such credentials in the IKEv2 protocol as specified in IETF RFC 4739 [91], and if the ePDG supports multiple authentications, it shall include such credentials in the APCO IE (see 3GPP TS 29.275 [103] subclause 12.1.1.19) on the S2b interface.

11.2.1.3 IPv6 Non Transparent access to an Intranet or ISP

When using IPv6 Address Autoconfiguration, the process of setting up the access to an Intranet or ISP involves two signalling phases. The first signalling phase is done in the control plane and consists of the PDP context activation or initial attach (e.g. create default bearer) for EPC based access, followed by a second signalling phase done in the user plane.

The user plane signalling phase shall be stateless. The stateless procedure, which involves only the MS/UE and the GGSN/P-GW, is described in subclause "IPv6 Stateless Address Autoconfiguration".

For APNs that are configured for IPv6 address allocation, the GGSN/P-GW shall only use the Prefix part of the IPv6 address for forwarding of mobile terminated IP packets. The size of the prefix shall be according to the maximum prefix length for a global IPv6 address as specified in the IPv6 Addressing Architecture, see RFC 4291 [82].

The GGSN/P-GW indicates to the MS/UE that Stateless Autoconfiguration shall be performed by sending Router Advertisements as described in the corresponding subclause below and according to the principles defined in RFC 4861 [89] and RFC 4862 [83].

For MS/UE having IPv6, IPv6 Stateless Address Autoconfiguration is mandatory.

11.2.1.3.1 IPv6 PDP Context Activation

In this case:

– The GGSN provides the MS with an IPv6 Prefix belonging to the Intranet/ISP addressing space. A dynamic IPv6 address shall be given using stateless address autoconfiguration. This IPv6 address is used for packet forwarding within the packet domain and for packet forwarding on the Intranet/ISP;

– the MS may send an authentication request at PDP context activation and the GGSN may request user authentication from a server, e.g. AAA, …, belonging to the Intranet/ISP;

– the protocol configuration options are retrieved (if requested by the MS at PDP context activation) from some server, e.g. AAA, …, belonging to the Intranet/ISP;

– in order to avoid any conflict between the link-local address of the MS and that of the GGSN, the Interface-Identifier used by the MS to build its link-local address shall be assigned by the GGSN. The GGSN ensures the uniqueness of this interface-identifier. The MT shall then enforce the use of this Interface-Identifier by the TE.

– the communication between the Packet Domain 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 over the insecure connection. This security protocol is defined by mutual agreement between PLMN operator and Intranet/ISP administrator.

– the MS may request for DNS server IPv6 addresses using the PCO IE in e.g. the PDP Context Request message. In that case the GGSN may return the IP address of one or more DNS servers in the PCO in the PDP Context Response message. The DNS address(es) shall be coded in the PCO as specified in 3GPP TS 24.008 [54]. If a list of servers is received, the MS shall adhere to the explicit prioritisation order of the list.

In the following signalling flow example, PPP is used as layer 2 protocol over the R reference point. The MT behaves as a PPP server and translates Protocol Configuration Options into SM message Ies. GTP-C carries this information unchanged to the GGSN which uses the information e.g. for RADIUS authentication. The result of the host authentication is carried via GTP-C back to the SGSN, which then relays the result to the MT. The MT finalises the IPV6CP negotiation by sending an IPV6CP Configure-Ack message to the TE with the appropriate options included, e.g. Interface-Identifier. The Interface-Identifier shall be used in the TE to create a link-local address to be able to perform the IPv6 address autoconfiguration (see subclauses 11.2.1.3.2 and 11.2.1.3.3).

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 IPv6 Interface-Identifier negotiation by sending the IPV6CP Configure-Request message to the MT.

5) The MT sends the Activate PDP Context Request message to the SGSN, including the Protocol Configuration Options. The Protocol Configuration Options IE may contain negotiated LCP options such as negotiated Authentication Protocol as well as any authentication data previously stored in the MT. It may also contain a request for dynamic configuration of DNS server IPv6 addresses. The MS shall for dynamic address allocation leave PDP Address empty and set PDP Type to IPv6 or IPv4v6. The SGSN sends the Create PDP context request message to the chosen GGSN including the unmodified Protocol Configuration Options.

6) The GGSN deduces from local configuration data associated with the APN:

– the source of IPv6 Prefixes (GGSN internal prefix pool, or external address allocation server);

– any server(s) to be used for address allocation, authentication and/or protocol configuration options retrieval (e.g. IMS related configuration, see 3GPP TS 24.229 [47]);

– the protocol e.g. RADIUS, to be used with the server(s);

– the communication and security feature needed to communicate with the server(s);

As an example the GGSN may use one of the following options:

– GGSN internal Prefix pool for IPv6 prefix allocation and no authentication;

– GGSN internal Prefix pool for IPv6 prefix allocation and RADIUS for authentication. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN;

– RADIUS for authentication and IPv6 prefix allocation. The AAA server responds with either an Access‑Accept or an Access-Reject to the RADIUS client in the GGSN;

NOTE: DHCPv6 may be used for IPv6 prefix allocation.

IPv6 Prefixes in a GGSN internal Prefix pool shall be configurable and structured per APN.

The GGSN shall in the PDP Address IE in the Create PDP Context Response return an IPv6 address composed of a Prefix and an Interface-Identifier. The Interface-Identifier may have any value and it does not need to be unique within or across APNs. It shall however not conflict with the Interface-Identifier the GGSN has selected for its own side of the MS-GGSN link. The Prefix assigned by the GGSN or the external AAA server shall be globally or site-local unique.

The GGSN shall analyse the requested values of all the protocol options contained in the received Protocol Configurations Options IE. The contents of the Protocol Configurations Options IE sent in the GGSN response shall be in accordance with the relevant standards e.g. the PPP standard RFC 1661 [21a] and RFC 1662 [21b].

7) The GGSN sends back to the SGSN a Create PDP Context Response message, containing the PDP Address IE and the Protocol Configuration Options IE. The Protocol Configuration Options IE may contain configuration data such as a list of DNS server IPv6 addresses. The cause value shall be set according to the outcome of the host authentication and configuration.

8) Depending on the cause value received in the Create PDP Context Response, the SGSN either stores the PDP Address and sends an Activate PDP Context Accept to the MS or, sends 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.

9) The MT extracts the Interface-Identifier from the address received in the PDP Address IE and ignores the Prefix part. If this Interface-Identifier is identical to the tentative Interface-Identifier indicated in the IPV6CP Configure-Request message sent from the TE, the MT sends an IPV6CP Configure Ack packet, indicating this Interface-Identifier, to the TE.

If the Interface-Identifier extracted from the address contained in the PDP Address IE is not identical to the tentative Interface-Identifier indicated in the IPV6CP Configure-Request message sent from the TE, the MT sends an IPV6CP Configure-Nak packet, indicating the Interface-Identifier extracted from the address contained in the PDP Address IE, to the TE. The TE then sends a new IPV6CP Configure-Request message to the MT, indicating the same Interface-Identifier as was indicated in the received IPV6CP Configure Nak (as indicated by the dotted IPV6CP Configure-Request and Configure-Ack in the figure below). Finally the MT responds with a IPV6CP Configure Ack packet.

In case a PDP Context Reject was sent to the MS the MT sends an LCP Terminate-Request to the TE.

10) When the TE has accepted the Interface-Identifier given by the MT, the user plane link from the TE to the GGSN and the external ISP/Intranet is established and the IPv6 address autoconfiguration may proceed.

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.

An LCP Terminate-request causes a PDP context deactivation.

NOTE: DHCPv6 may be used for IPv6 prefix allocation.

Figure 11ba: PDP Context Activation for the IPv6 Non-transparent case

11.2.1.3.1a IPv6 EPC based Bearer Activation

In this case, the P-GW provides the UE with an IPv6 Prefix belonging to the Intranet/ISP addressing space. A dynamic IPv6 address is given using stateless address autoconfiguration. This IPv6 address is used for packet forwarding within the packet domain and for packet forwarding on the Intranet/ISP.

When a P-GW receives an initial access request (e.g. Create Session Request or Proxy Binding Update) message, the P-GW deduces from local configuration data associated with the APN:

– The source of IPv6 Prefixes (P-GW internal prefix pool, or external address allocation server);

– Any server(s) to be used for address allocation, authentication and/or protocol configuration options retrieval (e.g. IMS related configuration, see 3GPP TS 24.229 [47]);

– The protocol, i.e. RADIUS, Diameter or DHCPv6, to be used with the server(s);

– The communication and security feature needed to communicate with the server(s);

As an example the P-GW may use one of the following options:

– P-GW internal Prefix pool for IPv6 prefixes allocation and no authentication;

– P-GW internal Prefix pool for IPv6 prefixes allocation and RADIUS for authentication. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the P-GW;

– RADIUS for authentication and IPv6 prefix allocation. The AAA server responds with either an Access‑Accept or an Access-Reject to the RADIUS client in the P-GW;

The P-GW includes the PDP Address IE in the the initial access response (e.g. Create Session Response or Proxy Binding Acknowledgement) and return an IPv6 address composed of a Prefix and an Interface-Identifier. The Interface-Identifier may have any value and it does not need to be unique within or across APNs. It shall however not conflict with the Interface-Identifier that the P-GW has selected for its own side of the UE-P-GW link. The Prefix assigned by the P-GW or the external AAA server shall be globally or site-local unique (see the Note in subclause 11.3 of this document regarding the usage of site-local addresses).

Table 0.a summarizes the IPv6 prefix allocation and parameter configuration use cases between the UE and the P-GW that may lead the P-GW to interwork with the external RADIUS AAA, Diameter AAA and DHCPv6 servers over Sgi reference point. For detailed description of the signalling flows between the UE and the P-GW, see the references in the table. The detailed description of the signalling use cases that may be triggered between the P-GW and the external servers are specified in this document, as referenced in the table.

Table 0.a : IPv6 prefix allocation and parameter configuration use cases

Signalling use cases between UE and P-GW

Signalling use cases between P-GW and external servers

Authentication via RADIUS or Diameter server (Clauses 16 or 16a)

(NOTE 1, and 2, 3)

IPv6 prefix allocation via DHCPv6 or RADIUS or Diameter server (Clauses 13.3, 16 or 16a)

(NOTE 1 and 2)

IPv6 parameter configuration via DHCPv6 or RADIUS or Diameter server
(Clauses 13.3, 16 or 16a)

(NOTE 1 and 2)

(1) IPv6 address allocation and parameter configuration

(2) IPv6 parameter configuration via stateless DHCPv6

deployment options applicable to both use cases (1) and (2):

– GTP-based S5/S8 (Subclauses 5.3.1, 5.3.2, 5.10.2 in TS 23.401 [77])

– PMIP-based S5/S8 (Subclauses 4.7.1, 5.2, 5.6 in TS 23.402 [78])

X

X

X

(3) IPv6 address allocation and parameter configuration via S4-based SGSN

(4) IPv6 parameter configuration via stateless DHCPv6

and using

– GTP-based S5/S8 (Subclauses 9.2, 9.2.2.1A in TS 23.060 [3])

– PMIP-based S5/S8 (Subclauses 4.7.1, 5.2, 5.6, 5.10 in TS 23.402 [78])

X

X

X

(5) IPv6 address allocation and parameter configuration in trusted non-3GPP IP access using on S2a

– PMIPv6 (Subclauses 4.7.2, 6.2.1, and 6.2.4 in TS 23.402 [78])

– GTPv2 (Subclauses 16.1.5, and 16.2 in TS 23.402 [78])

(6) IPv6 parameter configuration via stateless DHCPv6

and using

– achoring in P-GW

– chained S2a and PMIP-based S8

X

X

X

(7) IPv6 address allocation and parameter configuration in untrusted non-3GPP IP access using on S2b

– PMIPv6 (Subclauses 4.7.3, 7.2.1, and 7.2.3 in TS 23.402 [78])

– GTPv2 (Subclauses 7.2.4 in TS 23.402 [78])

and using

– anchoring in P-GW

– chained S2b and PMIP-based S8

X

X

X

(8) IPv6 address allocation and parameter configuration on S2c

– in trusted non-3GPP IP access

– in untrusted non-3GPP IP access

(Subclauses 4.7.4, 6.3 and 7.3 of TS 23.402 [78])

(9) IPv6 parameter configuration via stateless DHCPv6 on S2c (Subclauses 4.7.4 in TS 23.402 [78])

X

X

X

NOTE 1: When the P-GW interworks with AAA servers, the APN may be configured to interwork with either Diameter AAA or RADIUS AAA server.

NOTE 2: If RADIUS AAA or Diameter AAA server is used, the authentication, IPv6 prefix allocation and parameter configuration signalling may be combined. Similarly, if DHCPv6 server is used for IPv6 prefix allocation and parameter configuration, the signalling towards the DHCPv6 server may be combined.

NOTE 3: The UEs may provide PAP/CHAP user credentials in the PCO IE when accessing to EPS on 3GPP and non-3GPP IP accesses. If such information is provided to the P-GW, the P-GW may perform user authentication based on these credentials. For S2c, the P-GW may receive such credentials from the UE based on IETF RFC 4739 [91] during the establishment of security association signalling via IKEv2. For S2b, the UEs may provide such credentials in the IKEv2 protocol as specified in IETF RFC 4739 [91], and if the ePDG supports multiple authentications, it shall include such credentials in the APCO IE (see 3GPP TS 29.275 [103] subclause 12.1.1.19) on the S2b interface.

11.2.1.3.2 IPv6 Stateless Address Autoconfiguration

As described in 3GPP TS 23.060 [3], the IPv6 prefix of a PDP Context of PDP type IPv6 or IPv4v6 activated by means of the IPv6 Stateless Address Autoconfiguration Procedure is uniquely identified by the prefix part of the IPv6 address only. The MS may select any value for the Interface-Identifier part of the address. The only exception is the Interface-Identifier for the link-local address used by the MS (see RFC 4291 [82]). This Interface-Identifier shall be assigned by the GGSN to avoid any conflict between the link-local address of the MS and that of the GGSN itself. This is described in subclause "IPv6 PDP Context Activation" above.

For IPv6 the PDP Context Activation phase is followed by an address autoconfiguration phase. The procedure describing APNs configured to use Stateless Address Autoconfiguration, may be as follows:

1) After the first phase of setting up IPv6 access to an Intranet or ISP, the MS shall use the IPv6 Interface-Identifier, as provided by the GGSN, to create its IPv6 Link-Local Unicast Address according to RFC 4291 [82].

Before the MS can communicate with other hosts or Mses on the Intranet/ISP, the MS must obtain an IPv6 Global or Site-Local Unicast Address. The simplest way is the IPv6 Stateless Address Autoconfiguration procedure described below and in 3GPP TS 23.060 [3]. The procedure is consistent with RFC 4862 [83].

The procedure below takes place through signalling in the user plane. It is done on the link between the MS and the GGSN. From the MS perspective the GGSN is now the first router on the link.

2) After the GGSN has sent a Create PDP Context Response message to the SGSN, it shall start sending Router Advertisements periodically on the new MS-GGSN link established by the PDP Context. The MS may issue a Router Solicitation directly after the user plane establishment. This shall trigger the GGSN to send a Router Advertisement immediately.

To indicate to the MS that stateless address autoconfiguration shall be performed, the GGSN shall leave the M‑flag cleared in the Router Advertisement messages. The GGSN may set the O-flag if there are additional configuration parameters that need to be fetched by the MS (see below).

The Prefix sent in the Router Advertisements shall be identical to the Prefix returned in the Create PDP Context Response. The Prefix is contained in the Prefix Information Option of the Router Advertisements and shall have the A-flag set ("Autonomous address configuration flag") and the L-flag cleared (i.e. the prefix should not be used for on-link determination). The lifetime of the prefix shall be set to infinity. In practice, the lifetime of a Prefix will be the lifetime of its PDP Context. There shall be exactly one Prefix included in the Router Advertisements.

The handling of Router Advertisements shall be consistent with what is specified in RFC 4861 [89]. For the MS-GGSN link however, some specific handling shall apply. The randomisation part to determine when Router Advertisements shall be sent may be omitted since the GGSN is the only router on the link. Furthermore, some 3GPP specific protocol constants and default values shall apply (see subclause "IPv6 Router Configuration Variables in the GGSN"). These relate to the periodicity of the Router Advertisements initially and during continued operation. The motivation for this is to have a faster user-plane set-up even in bad radio conditions and to minimize MS power consumption during long continued operation.

3) When creating a Global or Site-Local Unicast Address, the MS may use the Interface-Identifier received during the PDP Context Activation phase or it may generate a new Interface-Identifier. There is no restriction on the value of the Interface-Identifier of the Global or Site-Local Unicast Address, since the Prefix is unique. Interface-Identifiers shall in any case be 64-bit long.

Since the GGSN guarantees that the Prefix is unique, the MS does not need to perform any Duplicate Address Detection on addresses it creates. That is, the ‘DupAddrDetectTransmits’ variable in the MS should have a value of zero. If the MS finds more than one Prefix in the Router Advertisement message, it shall only consider the first one and silently discard the others. The GGSN shall not generate any globally unique IPv6 addresses for itself using the Prefix assigned to the MS in the Router Advertisement.

If the O-flag ("Other configuration flag") was set in the Router Advertisement, the MS may start a DHCP session to retrieve additional configuration parameters. See subclause 13.2.2 "Other configuration by the Intranet or ISP". If the MS is not DHCP capable, the O-flag may be ignored.

Figure 11bb: IPv6 Stateless Address Autoconfiguration

11.2.1.3.2a IPv6 Stateless Address Autoconfiguration for EPC

This subclause describes the signalling flows for the IPv6 Stateless Address Autoconfiguration procedures for EPC, in the case of using GTP-based S5/S8/S2a, and PMIP-based S5/S8/S2a. The procedures are based on the descriptions in TS 23.401 [77] and TS 23.402 [78]. Subclause 11.2.3.1a lists the use cases between the UE to the P-GW that may trigger the P-GW to interwork with the external PDNs for IPv6 Prefix allocation.

IPv6 prefix is delivered to UE in Router Advertisement message from the access router, in the process of IPv6 Stateless Address Autoconfiguration.

In the procedure in the cases of using GTP-based S5/S8, P-GW acts as an access router, and allocates to a UE a globally unique /64 IPv6 prefix if the PLMN allocates the prefix, or P-GW retrieves IPv6 prefix from an external PDN if one is allocated by the external PDN and advertises it to the UE. In the latter procedure, P-GW uses RADIUS, Diameter or DHCPv6 protocol for the retrieval of an IPv6 prefix.

Following is the flow for IPv6 Stateless Address Autoconfiguration for EPC using GTP-based S5/S8.

1. UE initiates the Attach procedure, indicating ‘IPv6’ or ‘IPv4v6’ for PDN type in PDP type information element.

2. MME requests for Default Bearer creation by sending Create Session Request to the S-GW.

2x. The S-GW sends Create Session Request to the P-GW.

3. P-GW retrieves IPv6 prefix using RADIUS, Diameter, or DHCPv6 mechanism. This procedure is performed when an external PDN allocates an IPv6 prefix.

4. The P-GW sends Create Session Response. It includes the IPv6 interface identifier I IPv6 prefix.

5. S-GW sends Create Session Response message to the MME. It includes the IPv6 interface identifier I IPv6 prefix.

5x. The MME sends Attach Accept message to the UE without the IPv6 prefix. The UE shall ignore the IPv6 prefix if it receives one in the message.

6. After receiving the Attach Accept message, the UE may send a Router Solicitation to the P-GW to solicit a Router Advertisement message.

7. The P-GW sends a Router Advertisement message to the UE, solicited or unsolicited. It shall include an IPv6 prefix in Prefix Information option field of the message. The prefix is the same as the one in the Attach Accept message, if it is provided during the default bearer establishment. For the handling of M, O, L and A flags, and the lifetime of the prefix in the Router Advertisement message, follow the description in subclause 11.2.1.3.2.

Figure 11bc: IPv6 Stateless Address Autoconfiguration for GTP-based S5/S8

If PMIP-based S5/S8 is used, S-GW acts as an access router. Therefore, it is responsible for receiving Router Solicitation from and sending Router Advertisement message to the UE. Other than this, procedure is the same as the case of using GTP-based S5/S8; P-GW allocates, or retrieves an IPv6 prefix from the external PDN. The prefix is delivered from the P-GW to the S-GW in the IPv6 Home Network Prefix Option IE of a Proxy Binding Ackowledgement message.

In addition, the S-GW shall initiate sending the IPv6 Router Advertisement message (either solicited or unsolicited) to the UE once the PDN connection with PDN type IPv4v6 or IPv6 is setup after the procedure of E-UTRAN initial Attach, UE requested PDN connectivity, intra-3GPP access handover with Serving GW relocation, or handover from non-3GPP IP Access with S2a/S2b to 3GPP Access.

Following diagram shows the case where PMIP-based S5/S8 is used.

Figure 11bd: IPv6 Stateless Address Autoconfiguration for PMIP-based S5/S8

For trusted non-3GPP accesses, the non-3GPP network supports prefix advertisement for IPv6 prefix received from the P-GW in PMIPv6 Proxy Binding Acknowledgement. If the trusted non-3GPP access network is a WLAN network, for GTP/PMIP –based S2a, TWAN acts as an access router. Therefore, TWAN is responsible for receiving Router Solicitation from and sending Router Advertisement message to the UE. Other than this, procedure is the same as the case of using GTP/PMIP-based S5/S8; P-GW allocates, or retrieves an IPv6 prefix from the external PDN. The prefix is delivered from the P-GW to the TWAN in the IPv6 Home Network Prefix Option IE of a Proxy Binding Ackowledgement message or in the PDN Address Allocation IE of Create Session Response message.

Following diagram shows the case for trusted non-3GPP access network for WLAN access where GTP/PMIP-based S2a is used.

Figure 11be: IPv6 Stateless Address Autoconfiguration for trusted WLAN access for GTP/PMIP-based S2a

The P-GW ensures that the advertised IPv6 prefix is globally unique. Regarding the handling of Duplicate Address Detection, follow subclause 11.2.1.3.2.

The UE constructs its full IPv6 address in accordance with RFC 4862[83]. For the handling of IPv6 interface identifier, refer to subclause 11.2.1.3.2.

If the P-GW, S-GW and TWAN receive Neighbor Solicitation message from the UE, it shall answer with Neighbor Advertisement message.

To renew the allocated IPv6 prefix, the P-GW (GTP based S5/S8), S-GW (PMIPv6 based S5/S8) or TWAN (GTP/PMIP based S2a) shall send an IPv6 Router Advertisement (solicited or unsolicited) to the UE with the same assigned IPv6 prefix and and new non-zero values in preferred and valid lifetime fields for the PDN connection (PDN type IPv4v6 or IPv6), before the Router Advertisement lifetime and prefix lifetime expiry, as specified in IETF RFC 4861 [89]. When sending the IPv6 Router Advertisement message, the S-GW may trigger the paging (e.g. by sending a Downlink Data Notification message to the MME) if the UE is in idle state. In order to reduce paging an idle UE to deliver RA, the Router Advertisement lifetime and IPv6 prefix lifetime shall be configured accordingly.

If a UE supports multiple PDN connections functionality, it can connect to multiple P-GWs simultaneously, or it can access multiple PDNs through a single P-GW. In the former case, the IPv6 prefix allocated for its default bearer is used for the UE’s dedicated bearers toward the same PDN. In the latter case, IPv6 Stateless Address Autoconfiguration procedure is applied for each PDN connection.

11.2.1.3.3 IPv6 Stateful Address Autoconfiguration

Void.

Figure 11bc : Void

11.2.1.3.4 IPv6 Router Configuration Variables

For IPv6 Address Autoconfiguration to work properly , network entities which act as an access router towards the MS/UE, i.e. PDN GW, Serving GW, ePDG and TWAN, shall be consistent with the RFCs specifying this process (for example RFC 4862 [83] and RFC 4861 [89]), unless stated otherwise in this or other 3GPP specifications.

RFC 4861 [89] specifies a set of conceptual router configuration variables. Some of these variables require particular attention in GPRS and EPC in order to preserve radio resources and MS/UE power consumption while still allowing for appropriate robustness and fast user-plane set-up time even in bad radio conditions, or simply because they have a particular meaning in GPRS and EPC. These particular variables are listed below with appropriate (default) values and shall be configurable per APN. The values specified hereafter are specific to GPRS and EPC, and supersede those specified in RFC 4861 [89].

MaxRtrAdvInterval

Shall have a default value of 21 600 s (6 h).

MinRtrAdvInterval

Shall have a default value of 0,75 × MaxRtrAdvInterval i.e.16 200 s (4,5 h).

AdvValidLifetime

Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF. The assigned prefix remains Preferred until PDP Context/Bearer Deactivation.

AdvPreferredLifetime

Shall have a value giving Prefixes infinite lifetime, i.e. 0xFFFFFFFF. The assigned prefix remains Preferred until PDP Context/Bearer Deactivation.

RFC 4861 [89] also specifies a number of protocol constants. The following shall have specific values for GPRS and EPC:

MAX_INITIAL_RTR_ADVERT_INTERVAL

This constant may be a variable within GPRS and EPC. It may have a value that gradually increases (exponentially or by some other means) with the number of initial Router Advertisements sent. This will enable a fast set-up of the MS-GGSN or MS/UE-PDN GW/Serving GW/ePDG/TWAN links in most cases, while still allowing the MS/UE to receive a Router Advertisement within the initial phase, even in case of bad radio conditions or slow response time, without having to send a large number of initial Router Advertisements.

MAX_INITIAL_RTR_ADVERTISEMENTS

This is the number of Router Advertisements sent during the initial phase after the MS-GGSN or MS/UE-PDN GW/Serving GW/ePDG/TWAN links have been established. The value of this constant shall be chosen carefully, and in conjunction with MAX_INITIAL_RTR_ADVERT_INTERVAL, so as to not overload the radio interface while still allowing the MS/UE to complete its configuration in a reasonable delay. For instance, the default value could be chosen so that initial Router Advertisements are sent for at least 30 s.

After the initial phase, the periodicity is controlled by the MaxRtrAdvInterval and the MinRtrAdvInterval constants.

11.2.1.3.5 IPv6 Prefix Delegation via DHCPv6

Optionally, a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDN connection using prefix delegation after the PDP context activation/default bearer establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 11.2.1.3.2/11.2.1.3.2a. When PLMN based parameter configuration is used, the GGSN / PDN GW provides the requested IPv6 prefix from a locally provisioned pool. When external PDN based IPv6 prefix allocation is used, the GGSN / PDN GW may obtain the prefix from the external PDN as per subclauses 16.4 and 16a.4.

For the detailed description of the UE uses DHCPv6 to request additional IPv6 prefixes refer to 3GPP TS 23.060 [3] and 3GPP TS 23.401 [77].

11.2.1.4 Access to Internet, Intranet or ISP with Mobile IPv4

General

A way to allow users to roam from one environment to another, between fixed and mobile, between public and private as well as between different public systems is to use Mobile IP RFC 3344 [30]. Mobile IP (MIP) is a mobility management protocol developed by IETF. The Mobile IP Foreign Agent (FA) RFC 3344 [30] is located in the Core Network in the GGSN. MIP also uses a Home Agent (HA) RFC 3344 [30] which may or may not be located in a PLMN network.

Interworking model for MIP

A FA is located in the GGSN. The interface between the GGSN and the FA will probably not be standardised as the GGSN/FA is considered being one integrated node. The mapping between these two is a matter of implementation. Each FA must be configured with at least one care-of address. In addition a FA must maintain a list that combines IP addresses with TEIDs of all the visiting MSs that have registered with the FA. IP packets destined for the MS are intercepted by the HA and tunneled to the MS’s care-of address, i.e. the FA. The FA de‑tunnels the packets and forwards the packets to the MS. Mobile IP related signalling between the MS and the FA is done in the user plane. MIP registration messages RFC 3344 [30] are sent with UDP.

Figure 11c: The protocol stacks for the Gi IP reference point in the MIP signalling plane

Figure 11d: Protocol stacks for user access with MIP

In figure 11d: "(Tunneling)" is intended to show asymmetric traffic flow. Tunneling (IP-in-IP) is only used in the direction from the ISP towards the MT.

Authentication of the user is supported in Mobile IPv4. This authentication mechanism may involve communication with an authentication server (e.g. RADIUS), although this is not shown in figure 11d.

Address allocation – at PDP context activation no IP address is allocated to the MS indicated by 0.0.0.0. in the "Requested PDP Address" field. If the MS does not have a static IP address which it could register with the HA, it will acquire a dynamic IP address from the HA RFC 2794 [25]. After completion of the PDP activation the SGSN is informed of the assigned IP address by means of the GGSN initiated PDP Context Modification Procedure.

An example of a signalling scheme, shown in figure 11e, is described below. In this example the MS is separated into a TE and MT, with AT commands and PPP used in-between (see 3GPP TS 27.060 [10]). The PS attach procedures have been omitted for clarity.

Figure 11e: Example of PDP Context activation with Mobile IP registration
(the PS attach procedure not included)

1. The AT command carries parameters that the MT needs to request the PDP Context Activation. The important parameter here, is the APN (Access Point Name), see clause A below. The AT command is followed by a setup of the PPP connection between the MT and the TE.

2. As part of the PPP connection, LCP negotiates Maximum-Receive-Unit between the TE and the MT. No PPP authentication is required when using MIPv4.

3. As part of the PPP connection, the TE sends an IPCP Configure Request using the MIPv4 configuration option (see RFC 2290 [37]). The TE sends either its Home Address or a null address (i.e. 0.0.0.0) if the Network Address identifier is used (see RFC 2794 [25]).

4. The MT sends the "Activate PDP Context Request" to the SGSN. The message includes various parameters of which the "APN" (Access Point Name) and the "Requested PDP Address" are of interest here. The TE/MT may use APN to select a reference point to a certain external network or to select a service. APN is a logical name referring to the external packet data network or to a service that the subscriber wishes to connect to. The "Requested PDP Address" should be omitted for all MSs using Mobile IP. This is done irrespective of if the TE has a permanently assigned Mobile IP address from its Mobile IP home network, a previously assigned dynamic home address from its Mobile IP home network or if it wishes the Mobile IP home network to allocate a "new" dynamic home address.

A. The SGSN will base the choice of GGSN based on the APN that is given by the MS.

5. The SGSN requests the selected GGSN to set up a PDP Context for the MS. The PDP address and APN fields are the same as in the "Activate PDP Context Request" message.

6. A Create PDP Context Response is sent from the GGSN/FA to the SGSN. If the creation of PDP Context was successful, some parameters will be returned to the SGSN, if not, an error code will be returned. If the GGSN has been configured, by the operator, to use a Foreign Agent for the requested APN, the PDP address returned by the GGSN shall be set to 0.0.0.0. indicating that the PDP address shall be reset by the MS with a Home Agent after the PDP context activation procedure.

7. The Activate PDP Context Accept message is sent by the SGSN to the MT and contains similar information as the Create PDP Context Response message.

8. The MT sends an IPCP Configure Ack to the TE in order to terminate the PPP connection phase.

9. The Agent Advertisement RFC 3344 [30] is an ICMP (Internet Control Message Protocol) Router Advertisement message with a mobility agent advertisement extension. The latter part contains parameters of the FA that the mobile node needs, among those are one or more care-of addresses that the FA offers. This message should be sent, in the Packet Domain user plane, as an IP limited broadcast message, i.e. destination address 255.255.255.255, however only on the TEID for the requesting MS to avoid broadcast over the radio interface.

10. The Mobile IP Registration Request is sent from the mobile node to the GGSN/FA across the Packet Domain backbone as user traffic. The mobile node includes its (permanent) home address as a parameter RFC 3344 [30]. Alternatively, it can request a temporary address assigned by the home network by sending 0.0.0.0 as its home address, and include the Network Access Identifier (NAI) in a Mobile-Node-NAI Extension RFC 2794 [25] and RFC 2486 [31].

11. The FA forwards the Mobile IP Registration Request to the home network of the mobile node, where a home agent (HA) processes it. Meanwhile, the GGSN/FA needs to store the home address of the mobile node or the NAI and the local link address of the MS, i.e. the TEID (Tunnel Endpoint ID).

12. The Registration Reply is sent from the home network to the FA, which extracts the information it needs and forwards the message to the mobile node in the Packet Domain user plane. As the FA/GGSN knows the TEID and the NAI or home address, it can pass it on to the correct MS.

B. The GGSN/FA extracts the home address from the Mobile IP Registration Reply message and updates its GGSN PDP Context.

13. The GGSN triggers a "GGSN initiated PDP Context modification procedure" in order to update the PDP address in the SGSN and in the MT.

11.2.1.5 IP Fragmentation Across Gi/Sgi

3GPP and non-3GPP accesses provide IP services for a MS/UE. The GGSN/P-GW endpoint is a GTPv1-U tunnel (controlled by GTP Gn/Gp or S5/S8/S2a/S2b) or IP tunnel (controlled by S5/S8/S2a/S2b PMIPv6 or employed by a UE with MIPv4 or DSMIPv6).

The MTU of the IP tunnel on the MS/UE side of the IP link may be different than the MTU of the IP link connecting the GGSN/P-GW to the PDN. As a result IP packets crossing the Gi/Sgi interface may need to be fragmented. Unnecessary fragmentation should be avoided when possible due to the following;

– Fragmentation is bandwidth inefficient, since the complete IP header is duplicated in each fragment.

– Fragmentation is CPU intensive since more fragments require more processing at IP endpoints and IP routers. It also requires additional memory at the receiver.

– If one fragment is lost, the complete IP packet has to be discarded. The reason is there is no selective retransmission of IP fragments provided in IPv4 or IPv6.

To avoid unnecessary fragmenting of IP packets the MS/UE, or a server in an external IP network, may find out the end-to-end MTU by path MTU discovery and hence fragment correctly at the source. IP Fragmentation on Gi/Sgi shall be handled according to IETF RFC 791 [16] and IETF RFC 2460 [49]. The GGSN/P-GW shall enforce the MTU of IP packets to/from the MS/UE based on IETF RFC 791 [16] and IETF RFC 2460 [49].

11.2.1.6 Support for CUPS across SGi

Control plane and user plane separation of PGW as PGW-C and PGW-U, has been introduced as described in 3GPP TS 23.214 [117].

For UE IP address from the DN AAA server in the external PDN: If the AAA server in the external PDN is reachable only via the PGW-U, the PGW-U forward all the Diameter or RADIUS messages between the DN AAA server in the external PDN and the PGW-C, according to 3GPP TS 29.244 [114].

For UE IP address from DHCPv4/v6 server in the external PDN: If the DHCPv4/v6 server in the external PDN is reachable only via the PGW-U, the PGW-U forward all the DHCPv4/v6 messages between the DHCPv4/v6 server in the external PDN and the PGW-C. according to 3GPP TS 29.244 [114].

NOTE: If the DN AAA server or the DHCPv4/v6 server in the external PDN is reachable directly, then the PGW-C communicates with it directly, without involving the PGW-U.

11.2.1.7 Support L2TP for CUPS across SGi

L2TP (described in IETF RFC 2661 [118]) is a standard method for tunneling encapsulated Point-to-Point Protocol (PPP) frames over an IP network. L2TP operates between two L2TP endpoints (LAC and LNS), and tunnels PPP-encapsulated IP traffic between these endpoints. L2TP runs over UDP/IP and was originally defined for systems where PPP is used by an end-device to connect to a network (e.g. via DSL connections, or 2G/3G PPP PDP context). In these cases, a LAC could be deployed in the network (e.g. in a BNG or GGSN/PGW) to tunnel the PPP traffic to a server (LNS) over an IP network.

For CUPS with the UE using IP PDN connection, the PPP functionality that is required to use L2TP is instead supported by the PGW-U, as illustrated in below figure. Upon receiving a PDN connection session establishment request from the UE via MME and SGW-C, PGW-C may depend on local L2TP configuration per APN or the received L2TP information from a DN AAA server in Access-Accept message, request the PGW-U to setup L2TP tunnel towards an L2TP network server (LNS) in the external DN and tunnel the PDN Connection user plane traffic in this L2TP tunnel. In this case the PGW-U acts as a L2TP access concentrator (LAC).

To enable this, the PGW-C may provide L2TP tunnel information to the PGW-U as LAC, such as LNS IP address as described in 3GPP TS 29.244 [114]. This L2TP tunnel information may be configured on the PGW-C as part of the APN configuration or received from the DN-AAA server. Alternatively, the L2TP tunnel parameters may be configured in the PGW-U. The L2TP tunnel parameters include necessary parameters for setting up L2TP tunnel towards the LNS (e.g. LNS address, tunnel password).

In addition, the PGW-C may provide PAP/CHAP authentication information to the PGW-U, for use in L2TP session establishment, in case it was received from the UE in the PCO or ePCO IE of the PDN Connection establishment request message.

When L2TP is to be used for a PDN Connection, the PGW-C may select a PGW-U and requests the UE IP address to be allocated by LNS according to 3GPP TS 29.244 [114], the PGW-U (LAC) may retrieve this IP address from the LNS.

Figure 11f: L2TP Tunnel between CUPS and external DN

Below figure describes the L2TP connection procedures between CUPS and external DN, upon the UE is accessed in EPS and the PGW-C and PGW-U has been negotiated supporting L2TP feature.

Figure 11g: L2TP connection procedures between CUPS and external DN

0. The PGW-C and the PGW-U negotiated supporting L2TP feature as specified in 3GPP TS 29.244 [114].

1. The PGW-C receives a PDN Connection session establishment request from the UE via MME and SGW-C.

The UE may include the authentication information for PAP and/or CHAP in PCO or ePCO IE. The PGW-C may locally configure the UE authentication information for a given APN.

The PGW-C may determine that an L2TP session is required for the PDN Connection session based on local configured L2TP parameters per APN.

2. The PGW-C may receive the L2TP Tunnel parameters (e.g. LNS IP address or FQDN, tunnel password) from the DN-AAA server in Access-Accept message or Diameter AAA message, or local configured.

3. If L2TP protocol is determined to support the PDN connection, the PGW-C selects a PGW-U supporting L2TP and be configured with the LAC name/addresses and then requests the PGW-U to setup an L2TP tunnel if needed and/or L2TP session towards the L2TP network server (LNS).

The PGW-C sends PFCP Session Establishment Request to the PGW-U, which may include L2TP Tunnel Information for setting up a L2TP tunnel and L2TP session information to setup a L2TP session, together with the information for authentication used during L2TP Tunnel setup, as well as for L2TP session.

The L2TP Tunnel Information includes LNS IPv4 address or IPv6 address of LNS, Tunnel Password.

The L2TP Session Information includes specific information related to the PDN Connection, e.g. a Calling Number which may be set to UE’s MSISDN, an indication to instruct that the PGW-U shall request the LNS to allocate an IP address for the PDN session, indications to instruct that the PGW-U shall request the LNS to provide DNS server addresses or NBNS server addresses etc. as specified in 3GPP TS 29.244 [114].

4. The PGW-U checks if any existing L2TP tunnel can be used to serve the PDN Connection according to the information provided in the L2TP Tunnel Information.

If the PGW-U decides to setup a new L2TP tunnel, it initiates L2TP Tunnel establishment by sending an SCCRQ (Start-Control-Connection-Request) message towards the LNS, the PGW-U will allocate a Tunnel ID, and it may include a CHAP Challenge to authenticate the LNS. The Challenge and Challenge Response (to be included in SCCCN) is produced by the PGW-U using the Tunnel Password received from the PGW-C.

The LNS responds with an SCCRP (Start-Control-Connection-Reply) message, containing its allocated Tunnel ID and a CHAP Challenge Response to the Challenge in SCCRQ.

The PGW-U then responds with a Challenge response for tunnel authentication in the SCCCN (Start-Control-Connection-Connected) message. An L2TP tunnel is established after the tunnel authentication is successful, with the reception of the SCCCN message sent by the PGW-U to the LNS.

If the PGW-U decides to use an already existing L2TP tunnel for the requested PDN Connection from the PGW-C, it proceeds with step 5 below directly without current step.

5. Once the L2TP Tunnel is established (or already present) between the PGW-U and the LNS for the PDN Connection requested by the UE, the PGW-U proceeds with L2TP session setup towards the LNS.

The PGW-U sends an ICRQ (Incoming-Call-Request) message towards the LNS, which contains the Tunnel ID assigned by the LNS, its assigned Session ID, and optionally, the Calling Number and Called Number. The LNS responds with an ICRP (Incoming-Call-Reply) message and provides the Session ID assigned by it to the LAC.

The PGW-U then sends an ICCN (Incoming-Call-Connected) message. If proxy LCP and authentication are employed, the ICCN message includes the link control parameters (e.g. MRU) and UE authentication information sent from the PGW-C which was received via PCO or ePCO IE in step 1. In addition, the PGW-U (LAC) will act as a PPP endpoint to use IPCP to request UE IP Address, DNS server address and/or NBNS server address(es).

The LCP renegotiation may by triggered by the LNS after receiving the ICCN message. If so, the LAC and LNS will use PPP LCP to communicate link specific control parameter (e.g. MRU), and indicate authentication type, then either PPP PAP/CHAP takes place. The PPP IPCP transactions takes places to retrieve UE IP Address, DNS server address and/or NBNS server address.

6. The status of the L2TP session setup is sent by the PGW-U to the PGW-C in a PFCP Session Establishment Response.

7. The PGW-C sends a PDU Session Establishment Response to the UE and the user data session is initiated, which may contain the DNS and NBNS Server information.