10 PPP Based Services

07.603GPPGeneral Packet Radio Service (GPRS)Mobile Station (MS) supporting GPRSTS

By means of the PDP type ‘PPP’ GPRS 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 configuration is depicted in figure 8.

Figure 8: PPP Based Services

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 GPRS 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.

10.1 Example mapping of functions between the R reference point and the GPRS bearer

The following example illustrates the case when the PPP negotiation is carried out 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.

Figure 9: PPP Based Service

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 GSM 03.60.

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 GSM 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.