9 IP Based Services

27.0603GPPMobile Station (MS) supporting Packet Switched servicesPacket domainRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

All protocols that are supported by the underlying IP protocol are applicable in the Packet Domain environment. However there may be some limitations due to the RF environment.

The IP protocol can be run over various underlying protocols as shown in the figure 6.

Figure 6: IP Based Services

PPP is a widely supported protocol in numerous operating systems and this alleviates the need for any Packet Domain specific protocol at the TE. PPP at the MT shall comply with the following specifications IETF STD 51 (RFC 1661, RFC 1662), RFC 1570, RFC 1989, RFC 1332 for IPv4, and optionally RFC 2472 for IPv6. Additionally for IPv4 any Domain Name Server information shall be delivered as defined in RFC 1877, and the delivery of any vendor-specific packets and options shall conform to RFC 2153.

As an alternative to PPP, an L2 protocol can be used which is defined as a manufacturer’s operating system dependent protocol capable of carrying IP frames over the R reference point. An example for such an L2 protocol is the Multi-Class Multi-Link (MCML) PPP. The MCML is defined in RFC 2686 and is based on Multi-Link (MP) PPP which is defined in RFC 1990. For IPv6 the L2 protocol shall support negotiation of the IPv6 Interface-Identifier between the TE and the MT.

With IPv6, the process of setting up the IP connectivity is somewhat different than with IPv4 as it involves two distinct signalling phases. The first signalling phase is done in the control plane, followed by a second signalling phase done in the user plane. The control plane signalling phase, in the case of IPv6 over PPP, is described in section 9.1.2. The user plane signalling phase can be either stateless or stateful and is described in 3GPP TS 29.061 [17]. Support of the stateful address autoconfiguration procedure in the MS is optional.

Stateful and Stateless Autoconfiguration may also co-exist. In that case, the MS shall use Stateless to configure the address and Stateful to configure additional parameters only. The MS shall not use Stateless and Stateful Address Autoconfiguration simultaneously since GPRS only supports one prefix per PDP Context (see 3GPP TS 29.061 [17]).

Besides what is specified in the present document and in 3GPP TS 29.061, an MS supporting IPv6 shall comply with the guidelines specified in 3GPP TS 23.221 [48], subclause "UE support of IPv6".

9.1 Example mapping of functions between the R reference point and the Packet Domain bearer for IP over PPP

The following examples illustrate the case when the IP over PPP functionality is used in the MT. The example does not include all the details of PPP, but only describes the logical operation of PPP connection establishment, host authentication and IP configuration.

Each interface at the R reference point can support only one PPP connection and each PPP connection can support only one IP session. Therefore, in PPP mode only one IP PDP context can be activated per interface at the R reference point. However, it is possible for a PCMCIA card (or other multiplexed interfaces) to support multiple virtual interfaces (communications ports) at the R reference point. Multiple PPP connections and IP contexts are possible in this case.

9.1.1 IPv4 over PPP

Figure 7a: IPv4 Over PPP Based Service

1) The TE issues AT commands to set up parameters and enter PPP mode (refer to subclause on AT commands for further details).

2) The MT sends AT responses to the TE.

3) The PPP protocol in the TE sends a LCP Configure-Request. This command is to establish a PPP link between the TE and the MT.

4) The MT returns LCP Configure-Ack to the TE to confirm that the PPP link has been established. The MT might previously have sent a LCP Configure-Nak in order to reject some options proposed by the TE. This in turn might have triggered a retransmission of the LCP Configure-Request with different options.

5) The PPP protocol in the MT sends a LCP Configure-Request in order to negotiate for the authentication protocol used for authentication of the host TE towards the MT. The MT shall initially negotiate for CHAP, and if this is unsuccessful, for PAP.

6) The TE returns a LCP Configure-Ack to the MT to confirm the use of the specified authentication protocol. The MT might previously have sent a LCP Configure-Nak in order to reject the protocol proposed by the TE. This in turn might have triggered a retransmission of the LCP Configure-Request with different options.

7) 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 locally generated positive acknowledgement of the authentication to the TE. If none of the protocols is supported by the host TE no authentication shall be performed. Refer to 3GPP TS 29.061 for further details on the authentication.

8) The PPP protocol in the TE sends to the MT a NCP Configure-Request. This command activates the IP protocol.

9) If the MS is not yet PS attached, the MT performs the PS Attach procedure as described in 3GPP TS 23.060.

10) The MT performs a PDP Context Activation as described in 3GPP TS 23.60. IP configuration parameters may be carried between the MT and the network in the Protocol Configuration Options IE in PDP Context Activation messages. The Protocol Configuration Options IE sent to the network may contain zero or one NCP Configure-Request packet (in addition to any LCP and authentication packets). The Protocol Configuration Options IE received from the network may contain zero or one NCP Configure-Ack, zero or one Configure-Nak and/or zero or one Configure-Reject packets (in addition to any LCP and authentication packets).

11) Based on the information received in the Protocol Configuration Options IE, the MT acknowledges to the PPP protocol in the TE that the IP protocol is now activated by sending a NCP Configure-Ack command. Before sending a NCP Configure-Ack, the MT might previously have sent a NCP Configure-Nak and/or Configure-Reject in order to reject some IP parameters proposed by the TE. This in turn might have triggered a retransmission of the NCP Configure-Request with different parameter values. The decision to reject a specific parameter or parameter value may be based on the information received from the network in the Protocol Configuration Options IE. NCP Configure-Ack may also carry IP protocol related parameters such as dynamic IP address to the TE. The MT shall also pass name server information to the TE if the TE has requested for it and if this information is provided by the GGSN. Other packet types and options may optionally be delivered. The MT may choose to immediately deactivate the PDP context due to the information received from the network in the Protocol Configurations Options IE.

9.1.2 IPv6 over PPP

Figure 7b: PDP Context Activation for the IPv6 over PPP based services

1) The TE issues AT commands to set up parameters and enter PPP mode (refer to subclause on AT commands for further details).

2) The MT sends AT responses to the TE.

3) The PPP protocol in the TE sends a LCP Configure-Request. This command is to establish a PPP link between the TE and the MT.

8) The TE requests IPv6 Interface-Identifier negotiation by sending the IPV6CP Configure-Request message to the MT indicating the tentative Interface-Identifier chosen by the TE. The tentative Interface-Identifier has only local significance in the MT and shall not forwarded to the GGSN.

9) If the MS is not yet PS attached, the MT performs the PS Attach procedure as described in 3GPP TS 23.060.

10) The MT sends the Activate PDP context request message to the network, including the PDP Type, PDP Address and 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 as described in 3GPP TS 29.061 [17]. The MS shall leave PDP Address empty and set PDP Type to ‘IPv6’.
Note: The protocol between the TE and MT may not support the same set of information as the interface from the MT to the network (e.g. DNS).

The network responds with an Activate PDP Context Accept or an Activate PDP Context Reject, to the MS. The Protocol Configuration Options IE may contain configuration data such as a list of DNS server IPv6 addresses as described in 3GPP TS 29.061 [17]. In cases where the MS receives more than one server address, the MS shall adhere to the explicit prioritisation order of the list. The PDP Address shall contain an IPv6 address composed of a Prefix and an Interface-Identifier. 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 2373 [49]. The Interface-Identifier shall be used to create a link-local IPv6 address, to be used in continued MS – GGSN user-plane signalling. The Prefix in the PDP Address shall be ignored by the MS.

11) In case a PDP Context Accept was sent to the MS, 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. Finally the MT responds with an IPV6CP Configure Ack packet. The negotiated Interface-Identifier shall be used in the TE to create a link-local address.

After finalisation of the IPV6CP negotiations between TE and MT, the user plane link is established. Before the MS can communicate with other hosts on the Intranet/ISP it shall obtain an IPv6 Global or a Site-Local Unicast address. Given that exactly one Prefix is included in the Router Advertisement, depending upon whether the advertised Prefix is globally unique or Site-local unique, the MS can only generate either IPv6 Global address(es) or Site-local address(es) using this Prefix during the lifetime of a particular PDP Context. This is done using either Stateless or Stateful Address Autoconfiguration as described in 3GPP TS 29.061 [17].

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 uniqueness of the Interface-Identifier of the Global or Site-Local Unicast Address, since the Prefix itself is unique. Interface-Identifiers shall in any case be 64-bit long and follow standard interface-identifier guidelines as per IETF RFC 2373 [49] and RFC 2472 [46].

In case a PDP Context Reject was sent to the MS the MT sends an LCP Terminate-Request to the TE, the TE and MT negotiate for link termination. The MT may then send a final AT-response to inform the TE about the rejected PDP Context activation.

9.2 Example mapping of functions between the R reference point and the Packet Domain bearer for IP over MCML PPP

When MCML is used instead of standard PPP [34] at the R-reference point, it is possible to support multiple IP sessions on one MCML connection. This is achieved by using an additional MP header after the standard PPP header. MCML provides two different MP headers, a 2-byte header to have four IP sessions and a 4-byte header to have sixteen IP sessions multiplexed over the MCML connection.

Since both MP and MCML closely follow the PPP connection establishment and negotiation model described in subclause 9.1, it is not replicated in this subclause. The major difference is the additional negotiation capabilities used during the LCP configuration negotiation [44], [45].