10 PPP Based Services

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

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

By means of the PDP type ‘PPP’ the Packet Domain may support interworking with networks based on the point-to-point protocol (PPP), as well as with networks based on any protocol supported by PPP through one of its Network Control Protocols (NCPs). It may also support interworking by means of tunnelled PPP, by e.g. the Layer Two Tunnelling Protocol (L2TP). The protocol configurations are depicted in figures 8a and 8b.

Figure 8a: PPP Based Services (transparent PPP negotiation)

Figure 8b: PPP Based Services (relayed PPP negotiation)

The ‘L3’ protocol is a network layer protocol supported by one of the PPP NCP’s. All protocols currently supported by NCP’s are listed in [36].

The 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 GGSN shall comply with [34]. The Domain Name Server information shall be delivered as defined in [40]. The delivery of any vendor-specific packets and options shall conform to [41].

The ‘L2’ protocol may be the link layer protocol defined for the PPP suite [35]. As an alternative an ‘L2’ protocol can be used which is defined as a manufacturer’s operating system dependent protocol capable of carrying PPP frames over the R reference point. In case the link layer protocol defined for the PPP suite [35] is used as ‘L2’ protocol, the MT may negotiate LCP options related to the ‘L2’ framing (e.g. ‘ACCM’ [35], ‘ACFC’ [34] and ‘FCS-Alternatives’ [37]), with the TE. The MT shall remove the ‘L1’ and ‘L2’ specific framing from PPP frames in the uplink direction and add it in the downlink direction (see figure 8b).

10.1 Example mapping of functions between the R reference point and the Packet Domain bearer (transparent PPP negotiation)

The following example illustrates the case when the PPP negotiation is carried out transparently between the TE and the GGSN. The example does not include all the details of PPP, but only describes the logical operation of PPP LCP, host authentication and PPP NCP negotiations.

Figure 9a: PPP Based Service (transparent PPP negotiation)

1) The TE issues AT commands to set up parameters and activate a PDP Context (refer to sub-clause on AT commands for further details).

2) The MT performs a PDP Context Activation as described in 3GPP TS 23.060.

3) The MT sends AT responses to the TE.

4) The PPP protocol in the TE sends an LCP Configure-Request. This command establishes a PPP link between the TE and the GGSN.

5) The GGSN returns an LCP Configure-Ack to the TE to confirm that the PPP link has been established. The GGSN might previously have sent an 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.

6) The PPP protocol in the GGSN sends an LCP Configure-Request in order to negotiate for the authentication protocol used for authentication of the host TE towards the GGSN.

7) The TE returns an LCP Configure-Ack to the GGSN to confirm the use of the specified authentication protocol. The GGSN might previously have sent an 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.

8) The TE authenticates itself towards the GGSN by means of the negotiated protocol. If no authentication protocol can be negotiated the GGSN may reject the PPP connection. Refer to 3GPP TS 09.61 for further details on the authentication.

9) The PPP protocol in the TE sends to the GGSN an NCP Configure-Request. This command activates the network layer protocol.

10) The GGSN acknowledges to the PPP protocol in the TE that the network layer protocol is now activated by sending an NCP Configure-Ack command. Before sending an NCP Configure-Ack, the GGSN might previously have sent an NCP Configure-Nak in order to reject some parameters proposed by the TE. This in turn might have triggered a retransmission of the NCP Configure-Request with different parameter values.

10.2 Example mapping of functions between the R reference point and the Packet Domain bearer (relayed PPP negotiation)

The following example illustrates the case where the link layer protocol defined for the PPP suite [35] is used as ‘L2’ protocol. The LCP options related to the ‘L2’ framing (e.g. ‘ACCM’, ‘ACFC’ and ‘FCS-Alternatives’) are negotiated between the TE and the MT. All other PPP negotiation is relayed transparently between the TE and the GGSN. The example does not include all the details of PPP, but only describes the logical operation of PPP LCP, host authentication and PPP NCP negotiations.

Figure 9b: PPP Based Service (relayed PPP negotiation)

1) The TE issues AT commands to set up parameters and activate a PDP Context (refer to sub-clause on AT commands for further details).

2) The MT performs a PDP Context Activation as described in 3GPP TS 23.060.

3) The MT sends AT responses to the TE.

4) The PPP protocol in the TE sends an LCP Configure-Request. If the request contains options related to the ‘L2’ framing these are negotiated by the MT. The LCP Configure-Request shall subsequently be relayed to the GGSN.

5) The GGSN returns an LCP Configure-Ack to the MT. The MT may change the value(s) of any options related to ‘L2’ framing and thereafter return an LCP Configure-Ack to the TE to confirm that the PPP link has been established. The MT might previously have sent an LCP Configure-Nak to the TE 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.

6) The PPP protocol in the GGSN sends an LCP Configure-Request in order to negotiate for e.g. the authentication protocol used for authentication of the host TE towards the GGSN. The request is relayed to the TE.

7) The TE returns an LCP Configure-Ack to the MT to confirm the use of e.g. the specified authentication protocol. The acknowledgement is relayed to the GGSN. The GGSN might previously have sent an 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.

8) The TE authenticates itself towards the GGSN by means of the negotiated protocol. The messages are relayed transparently by the MT. If no authentication protocol can be negotiated the GGSN may reject the PPP connection. Refer to 3GPP TS 29.061 for further details on the authentication.

9) The PPP protocol in the TE sends an NCP Configure-Request to the MT, which relays it transparently to the GGSN.

10) The GGSN acknowledges to the PPP protocol in the TE that the network layer protocol is now activated, by sending an NCP Configure-Ack command, transparently relayed by the MT. Before sending an NCP Configure-Ack, the GGSN might previously have sent an NCP Configure-Nak in order to reject some parameters proposed by the TE. This in turn might have triggered a retransmission of the NCP Configure-Request with different parameter values.