4.4.1 PPP over E1/T1/JT1
PPP (Point-to-Point Protocol) defines an encapsulation method assuming a full-duplex communication. The frame format is HDLC-like (High level data link control). From 3GPP standards viewpoint, PPP is one option for Layer-2, below the IP as a network layer protocol. PPP in HDLC-like framing is defined in RFC1662 [25].
The L2 frame format is shown in Figure 4.8.
Figure 4.8 PPP frame format [24].
A flag marks the start of the frame with a bit sequence ‘01111110’. Address field is typically a broadcast field of all ‘1’s, meaning all stations. Control fields consists of ‘00000011’, other values may be used if so agreed. Protocol indicates the protocol carried in the information field. Information consists of data to be transmitted, and padding may be included. Together the information and padding may include up to 1500 octets, which is the default value for the Maximum Receive Unit (MRU). Other values may be negotiated.
Frame Check Sequence (FCS), is calculated over the entire frame. 2 byte FCS is the default, 4 byte FCS may be negotiated. In case of mobile backhaul, IP is encapsulated into PPP by marking the protocol field accordingly, and then including data and optional padding.
In IP addressing, the PPP link can be treated as an unnumbered serial interface (no IP address assigned) or then as a network. In the latter case, the network consumes one address in addition to the interface addresses.
In the control plane, Link Control Protocol (LCP) may be utilized. Link control protocol functions include establishing, configuring and testing the connection, with the target of supporting ease of configuration with an auto-negotiation of parameters.
Authentication is also possible with the PPP protocol. For this purpose, Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) can be used. In the dial-up Internet connectivity, the Internet service provider may authenticate the user with this method.
4.4.2 ML-PPP
In order to increase the data rate capability with the IP over PPP over E1/T1/JT1s, it is possible to combine a number of these lines to create a higher capacity service. This is accomplished through the use of multi-link point-to-point (ML-PPP) protocol. Aggregating for example eight E1 lines into a group results in a IP/ML-PPP over 8xE1 interface, with the physical layer rate of 8 × 2.048 Mbit/s or 16.384 Mbit/s. ML-PPP may be negotiated using the LCP.
Figure 4.9 shows an application of IP based NodeBs connected via E1/T1 based TDM network to the RNC.
Figure 4.9 Using ML-PPP over E1/T1s for IP Iub.
With ML-PPP, multiple E1/T1 lines are aggregated into a single higher capacity interface. In the example eight lines were used for each NodeB. In the TDM network E1/T1s are collected with a Sonet/SDH multiplexer, so that the traffic can interface the RNC via a few channelized STM-1/OC3 interfaces, instead of a large number of E1/T1 ports.
Another possibility is to have a ML-PPP gateway terminating the PPP protocol, and supporting an Ethernet interface towards the RNC. In this case the ML-PPP gateway provides the conversion from the E1/T1 infrastructure into packet networking.
In the mobile backhaul application in the BTS access area, ML-PPP interfaces provide capacity up to a few tens of Mbit/s, depending on the amount of TDM lines available. Instead of using E1/T1/JT1 lines all the way from the BTSs to the controllers, they can be terminated in an aggregation device. This device interfaces the higher aggregation layer, e.g. with an Ethernet interface.
With ML-PPP, large packets may be fragmented into multiple segments, which then are transmitted over the physical links constituting the bundle. Segment sizes can be optimized to match the speed of the links, in case links have unequal speeds.
For ML-PPP, the fragments are encapsulated as shown in the header of ML-PPP in Figure 4.10. The left hand side shows a long sequence field format (4 bytes). Short sequence format (2 bytes), depicted on the right hand side, may be negotiated using the LCP. A protocol ID of 003DH is reserved for the ML-PPP. The ML-PPP header consists of Begin/End bits and the sequence number field. Begin/End bits tell whether the fragment begins or ends the packet carried as data. Sequence field is incremented for transmitted fragments.
Figure 4.10 ML-PPP header [28].
In order to reduce blocking for voice due to large data packets, optimization is possible with a Multi-Class Extension. Multi-Class Extension essentially supports running multiple instances of the ML-PPP protocol. Each class operates on its own instance, with separate sequence numbering. The classes are identified with two unused bits in the short sequence header, and with four of the six unused bits of the long sequence header. This arrangement allows for four classes in the case of short sequence headers, and 16 classes in the case of the long sequence header. With the classes, voice can be separated from data, as an example.
IP Control Protocol (IPCP) for the PPP allows configuration of the IP layer protocol parameters. One of such options is IP header compression. Header compression method can be RFC1144 for TCP/IP, which is included in the original IP CP RFC. More recently, Robust Header Compression (ROHC) defines profiles for compressing IP, UDP, RTP, and ESP protocols.
Header compression saves bandwidth on the low-speed links, as headers can be substantially compressed. The main drawback is the added complexity and cost. If header compression is implemented for 3G as an example, each NodeB needs a counterpart which terminates the header compression function. Header compression is computing intensive and increases cost of the elements.
Another PPP supported means of increasing efficiency on low speed links is PPP multiplexing [30]. This allows multiplexing several PPP encapsulated packets within a single PPP frame. PPP multiplexing adds a delimiter to separate the PPP packets at the de-multiplexing end. A PPP Mux control protocol is used to negotiate this option. PPP multiplexing occurs before the ML-PPP encapsulation, so that PPP multiplexing is then used for the whole ML-PPP bundle.
4.4.3 PPP over Sonet/SDH
Similarly to the IP over PPP (or ML-PPP) over E1/T1s, IP can be mapped into PPP and further to the Sonet/SDH containers, as Sonet/SDH essentially is a point-to-point full-duplex link. Often the solution is called Packet over Sonet.
There are no major differences in Sonet and SDH concerning PPP operation. HDLC-like framing is used as discussed for PPP over E1/T1/JT1. IP over PPP is mapped into Sonet STS-3c-SPE or SDH VC-4, in the case of the STS-3/STM-1 interface. The payload is scrambled before inserting into the Sonet/SDH container, due to issues discovered with the original RFC1619 specification.
Note that for carrying IP in Sonet/SDH network, NG-SDH allows the use of an Ethernet port, and the Ethernet is then mapped to the Sonet/SDH containers, possibly with virtual concatenation.