Radio access networks (RANs) connect mobile base stations to the mobile backhaul network. RANs have evolved from second-generation (2G) networks with GSM handsets to third-generation (3G) networks, which introduce IP. However, 3G networks do not offer true IP-based service. Rather, SSGN tunnels the data portion of the traffic to general packet radio service (GPRS) routers, which act as gateways to IP-based networks. The next phase, fourth-generation (4G) networks, commonly called Long-Term Evolution (LTE), introduces more IP into mobile backhaul networks, transforming RANs into IP RANs. In LTE networks, voice packets are encapsulated into IP packets and are transmitted over IP RAN, not over the legacy public switched telephone network (PSTN) as is the case with 3G networks.

This case study examines the recently evolved LTE network, with a focus on packet-based QOS. It starts by discussing the components of 2G and 3G networks, how traffic is carried on these networks, and how they have evolved to LTE. The case study then describes the LTE network components and traffic and offers guidelines and suggestions for using QOS.

11.1 Evolution from 2G to 4G

This book focuses on QOS in packet-based networks, and this chapter presents a QOS case study for IP-based RAN as part of a mobile backhaul network. However, a brief introduction of 3G network evolution to 4G and LTE is necessary to describe the fundamental changes that occur with LTE and the packet transport for this service. We must discuss some basic mobile functions and features before explaining the QOS scenario for IP RAN and mobile backhaul. This discussion touches on the packet-handling services in 3G and 4G networks. Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), and any other pure mobile voice and signaling architectures are described only briefly. Also, the 3rd Generation Partnership Project (3GPP) evolution is covered only in generic terms.

11.2 2G Network Components

2G mobile networks and GSM are synonymous, but GSM is widely seen as one of the key components within 2G mobile phone systems. With GSM, both signaling and speech channels are digital. This facilitates the widespread implementation of data communication applications into the mobile network. GSM is a cellular network, which means that mobile phones connect to it by searching for cells in the immediate area. A cell is a part of a base station, and several base stations form the cellular network. GSM networks operate in a number of different carrier frequency bands, normally within the 900- or 1800-MHz band, although this varies from country to country. The frequencies are divided into timeslots. The elements in a GSM mobile network can be seen in Figure 11.1.

The mobile system (MS) includes a mobile equipment (ME) and a subscriber identity module (SIM). The SIM contains the subscriber’s International Mobile Subscriber Identity (IMSI), which carries information about the area code, the country code, the identity, and so forth. The SIM also holds the subscriber’s cryptographic key, which is used for authentication and security.

The Base Transceiver Station (BTS), which is basically a radio receiver, handles functions related to radio access between the mobile phone and the BTS. Each BTS covers a cell, which is a radio access area. Normally, BTSs are grouped in an overlapping design so that they span several cell areas. A group of BTSs is commonly referred to as a “site.” In IP terminology, the BTS is the GSM’s customer premises equipment (CPE) gear.

The Base Station Controller (BSC) offloads the mobile switching center (MSC) of radio-related items, such as radio call setup, administration of channels, and handover (roaming) between cells (BTS coverage).

The MSC is the actual traffic or call route switch and performs the switching between the 64-kbps channels. The MSC is also responsible for monitoring and registering calls.

The Visitor Location Register (VLR) is a database located in the MSC. It maintains a list of the subscribers for those mobile phones that currently exist within the MSC coverage area.

The Home Location Register (HLR) is the main database that maintains a list of each GSM operator’s subscribers. The HLR performs several functions related to maintaining and administering mobile services and is supported by other databases, including:

• Authentication Center (AUC): All GSM operators maintain this database, which contains information for subscriber authentication, including all subscribers’ cryptographic keys.
• Equipment Identity Register (EIR): When subscribers log in to a GSM operator, the operator registers the IMSI that exists on the MS. The operator also transmits the unique mobile phone identifier, called the International Mobile Equipment Identity (IMEI), to enable an operator to lock out “missing” units.
• Central Equipment Identity Register (CEIR): In this database, operators report all IMEIs that should be locked out from the network.

GSM is a cellular telephony system that supports mobility over a large area. Unlike cordless telephony systems, it provides roaming and handover functionality. The GSM system is capable of international roaming; that is, it can make and receive phone calls to and from other nations or locations as if the user had never left home. This is possible because of bilateral agreements signed between the different operators to allow GSM mobile clients to take advantage of GSM services with the same subscription when traveling to different countries and locations, as if they had a subscription to the local network. To allow this, the SIM card contains a list of the networks with which a roaming agreement exists. When a user is roaming, the mobile phone automatically starts a search for a network stipulated on the SIM card list. The choice of a network either is performed automatically or can be selected by the user. The home Public LAN Mobile Network (PLMN) is the network to which the user is subscribed, while the visited PLMN is the one in which the user is roaming. When the user is moving from one cell to the other during a call, the radio link between BTS and the MS can be replaced by another link to another BTS. The continuity of the call can be performed in a seamless way for the user. In brief, this is the handover process.

GSMs have been improving year by year, with new features and enhancements to existing features defined in annual releases named after the year of introduction (release 96, 97, 98, 99, and so forth). The GSM responsibilities have been managed by the 3GPP. An example of an enhancement managed by 3GPP is GPRS; CDMA is different from GSM. CDMA is not discussed in this chapter because there is no value when describing the QOS aspects of 4G networks in pointing out the differences and similarities between GSM and CDMA.

11.3 Traffic on 2G Networks

The traffic on 2G networks passes through timeslot- or cell-based networks as it heads towards the PSTN. The RAN provides no packet processing for any application. All traffic is handled within 64-kbps timeslots or SDH/ATM trunks; only circuit-switched mode is used for any type of traffic. Figure 11.2 shows the 2G network transport elements.

11.4 3G Network Components

The 3G network represents an evolution of the 2G network and GSM. 3G networks allow data transmission in packet mode rather than the circuit- and timeslot-switched modes of 2G networks. Packet mode is made possible by GPRS. GPRS still uses the GSM principles of a radio interface and its notions of timeslots. The system design goal of GPRS is to provide higher data-rate throughput and packet-switched services for data traffic without affecting pure voice and speech traffic and minimizing the impact on the existing GSM standard and networks.

The GPRS network architecture reuses the GSM network nodes such as MSC/VLR, HLR, and BSC. It introduces two new network nodes for the transport of packet data: the gateway GPRS support node (GGSN) and the serving GPRS support node (SGSN). GPRS also defines new interfaces between the GSM network nodes and the different elements of the GPRS core network (see Figure 11.3).

This book makes no distinction between acronyms that mean more and less the same thing. An example is 3G versus Universal Mobile Telecommunications System (UMTS). UMTS is one of the 3G mobile telecommunications technologies, which is also being developed into a 4G technology. With UMTS, the BTS or NodeB still handles the radio access. Both packet-oriented services such as GPRS and circuit-switched services such as voice can use the same cell from the NodeB.

The BSC or Radio Network Controller (RNC), as it is called in 3G, has the same function as in 2G, although some 3G functionality has been added to route voice traffic to circuit-switched networks and data traffic to packet-based networks. RNC uses acronyms for its interfaces towards NodeB, all of which start with “lu” and a letter, for example, “b.” Figure 11.4 shows the interface naming for radio elements.

The SGSN is the node that serves the MS. It delivers packets to and from the MS and communicates with the HLR to register, to authenticate, and to obtain the GPRS profile of the subscriber. The SGSN also performs accounting. The SGSN can be connected to one or several BSCs or RNCs. Also, the SGSN is the device that manages mobility if the subscriber moves, finding the user’s “home” GGSN with assistance from the HLR. The SGSN functions very much the same way as the MSC does for voice. In a nutshell, the IP part from the SGSN starts with the packet service that the GPRS provides. In GPRS terms, the network interface between the SSGN and NodeB is called Gb.

A GGSN provides interworking with external Packet Data Networks (PDNs). The GGSN can be connected to one or several data networks, for example, to an operator’s Internet or to a company virtual private network (VPN). It connects to the SSGN using an IP-based GPRS backbone network, commonly called the mobile backhaul. The GGSN is a router that forwards incoming packets from the external PDN to the SGSN of the addressed MS, or vice versa. Once a packet leaves the GGSN towards a PDN, it is a pure IP packet. Thus, the other routers in the Internet or company VPN see the GGSN as just another router. The GGSN communicates with other services such as RADIUS to achieve the correct user profiles, and it also performs accounting.

So how is the data traffic handled between the SSGN and GGSN? This is where the GPRS Tunneling Protocol (GTP) comes into the picture. The SSGN uses GTP to create a tunnel to the GGSN, which means that native IP processing of end user starts at the GGSN. Figure 11.5 illustrates GTP tunneling in the GPRS network.

There are two types of GTP tunnels. The tunnel for control traffic, called GTP-C, uses UDP port 2123. The second type of tunnel, for user traffic, called GTP-U, uses UDP port 2152. Figure 11.6 shows the GTP header.

Control traffic over the GTP-U is exchanged between the MS and the GPRS network components to establish a Packet Data Protocol (PDP) context, defined in RFC 3314 [1]. The traffic over the GTP-U, which is the actual user traffic, is exchanged between the MS and the GGSN. The PDP context is the microflow entity for the user session. The mobile world does not talk about sessions; it talks instead about PDP context. Several PDP contexts can be active between the MS and the GGSN. The primary PDP context defines the connection to the GGSN, and the secondary context can have different attributes such as QOS because it can support different services. The PDP context can be seen as a mix between service and application, because each context established on the MS is assigned its own IP address. In this way, the PDP context is not similar to TCP, for example, which uses sockets and port numbers on the host itself to separate established applications from each other. Three basic actions can be performed on a PDP context: activation, modification, and deactivation. Figure 11.7 illustrates the PDP context activation.

Mobile users and their PDP contexts are grouped on the GGSN into an Access Point Name (APN). An APN is the mobile realm’s parallel of a VPN. The APN manages the IP address ranges that have been allocated to each PDP context. An example of an APN is Internet access or a private VPN, towards which the GGSN tunnels packets using IPsec or GRE tunnels.

11.5 Traffic on 3G Networks

Voice traffic on a 3G network continues to be circuit switched, so in this sense it is identical to voice traffic on a 2G network. The difference lies in the data service packets, which are routed in a packet-based network structure. As we have discussed, an end user packet is not processed as a native IP packet until it reaches the GGSN. IP traffic between the SSGN and the GGSN travels in a GTP tunnel over the Gn interface or, in a roaming situation, over the Gp interface so the user can be routed over another operator’s network to their home GGSN.

From a QOS perspective, this mobile traffic is clearly handled as a best-effort (BE) service, because it is transported through a tunnel and because traffic in a GPRS network is generally placed in a BE class of service. Examples of GPRS network traffic include UDP-based name queries and lookup and TCP-based HTTP downloads. Another common traffic type is webcasting traffic, which gives the impression of being a real-time service when, in fact, it is just a streamed file that is being downloaded. QOS could be used here to map the radio QOS classes to the GTP header and appropriate DSCP class in the IP header for the GTP packet, but in 3G and GPRS network, this is more theoretical rather than an actual implemented service. Figure 11.8 shows a GTP packet and delineates the QOS extension header from the DSCP part of the IP packet.

GPRS traffic flows in a hub-and-spoke pattern because each subscriber is assigned to a home GGSN. This “all roads lead to Rome” traffic pattern means that the subscriber always enters and exits the network through the same GGSN regardless of whether the user is at home or is traveling.

The SSGN connected to the RNC performs a lookup of the subscriber by querying the HLR. If the subscriber is on their home GGSN, the SSGN routes the traffic to its destination. If the subscriber is roaming, the SSGN routes the traffic to their home GGSN. The result is the creation of GTP tunnels on the Gn or Gp interface in a GPRS network. Clearly, it is as hard to manage QOS functions across operators in roaming situations as it is to maintain QOS in Internet for packets that traverse service provider boundaries.

In summary, it is possible to implement IP QOS solutions in GPRS networks, but in most cases, no transparent QOS mappings between radio and IP traffic are implemented for GPRS traffic passing over the mobile backhaul on the Gn or Gp interface between the SSGN and the GGSN. The most common approach is to implement a QOS mapping on the GGSN when the packets leave the mobile network, creating a mapping between the 3GPP and other IP QOS classes such as DiffServ and IP DSCP.

11.6 LTE Network Components

3GPP, or LTE, is the next evolutionary step in radio networks. (Note that LTE and 4G are synonyms.) With LTE, the radio interface is not redirected to a PSTN, but is instead IP based. Voice is seen like any other application in an LTE network.

As an aside, LTE networks can be data-only networks that mix 3G and LTE traffic. On these networks, only the data is handled as LTE traffic, while the voice traffic remains as GSM/CDMA. Also, there are a number of variations of the voice traffic. For example, the 3GPP voice solution is generally IP Multimedia System (IMS). Discussing all the possibilities is beyond the scope of this book.

Compared to a GPRS network, the LTE network is flat. LTE has no radio control node like an RNC that collapses and aggregates the traffic. The LTE NodeB, sometimes also called the eNodeB, connects directly to an IP network, towards the Serving Gateway (S-GW), Mobility Management Entity (MME), and Packet Data Network Gateway (PDN-GW). The MME handles signaling, while the S-GW and PDN-GW handle the actual termination of tunnels and forwarding of traffic (we discuss these later).

The S-GW is the anchor point for the termination of mobile users in the packet network. It is the end point for the GTP tunnel between eNodeB and manages roaming to other networks.

The PDN-GW, or just P-GW, is the gateway between the LTE network and other networks. It acts very much like GGSN with regard to managing how it forwards users to either the Internet or a private VPN. The PDN-GW also manages the IP addressing for the end users. Note that the S-GW and PDN-GW functions can be on the same node, which often makes more sense than splitting them. Other network functions can also be running on the PDN-GW, such as NAT to map IPv6 addresses to IPv4 addresses.

The MME provides the control plane function for LTE. It is responsible for authentication and management.

System Architecture Evolution (SAE), as the LTE core network architecture is called, is an all-IP network that includes both mobile backhaul and RAN. The main components of the SAE architecture are the Evolved Packet Core (EPC), MME, S-GW, and PDN-GW.

The LTE interface names change, of course, from GPRS. Figure 11.9 illustrates the LTE S1 and Si interfaces, which are equivalent to the GPRS Gn and Gi interfaces, respectively. Figure 11.9 also separates the S-GW and PDN-GW functions to explain the interface naming simply. However, as stated earlier, the S-GW and PDN-GW can be on the same device.

One major difference between LTE and 3G, apart from the network topology, is that LTE is all IP. So, for instance, the voice is handled as VoIP. This means that all LTE operators run an IP transport network, starting from the eNodeB. The GTP tunnel between the eNodeB and the S-GW is more for administrative purposes, such as tracking and controlling users. Also, there is only one tunnel between the eNodeB and the S-GW, unlike the several tunnels present with GPRS. The TEID information differentiates the users in the GTP tunnel.

The S1 and x2 interfaces shown in Figure 11.9 are considered to be RAN interfaces. These interfaces are transported over the IP RAN as part of the mobile backhaul network, possibly using public networks, such as E-Line or E-LAN. These networks are not considered secure enough to transport unencrypted data. The security is provided by IPsec, whose use is mandatory to protect the integrity for the traffic.

IPsec tunnels carry encapsulated voice and data traffic, plus signaling, between the eNodeB and the MME. The requirement for IPsec tunnel and key management is defined in the 3GPP documents TS 33.210 [2] and TS 33.31, which discuss the Layer 3 security and authentication framework. These documents require that IPsec ESP conform to RFC 4303 [3] to support integrity and replay protection and that certificate authentication be done by IKEv2.

The 3GPP mandates that IPsec be implemented on the eNodeB, and the two specifications mentioned above detail the IPsec implementation requirements. IPsec must be supported, but deploying it is not mandatory. After performing a risk assessment, the operator must decide whether to use IPsec.

However, the IPsec requirements are currently the subject of much debate. One current question is whether IPsec is necessary if the operator manages the network, end to end, from the eNodeB to the S-GW. Another question is whether IPsec is mandatory just because no authentication or encryption exists, by default, for voice traffic on an LTE network.

The extensive usage of IPsec makes traffic paths and QOS a tough challenge. In the case of a centralized S-GW using IPsec, x2 to x2 traffic termination might result in a slow or difficult handover for roaming mobile users.

While the design of LTE networks is beyond the scope of this book, it needs to be mentioned that LTE networks have a significant overhead because of the security information (based on the IPsec header) and because of the control and user tracking (based on the GTP header) of traffic between the eNodeB and the S-GW. To scale and segment, the network probably needs to be provisioned similarly to large access and distribution metro networks, with extensive usage of virtual LAN (VLAN) and Multiprotocol Label Switching (MPLS) stack labels to scale the provisioning of the eNodeB. Figure 11.10 shows the header overhead involved. The first packet is Layer 3 only, the second is for Ethernet aggregation using VLAN/S-VLAN, and the third shows the MPLS dual stack that is used with MPLS VPN technologies, such as L3VPN, VPLS, and pseudowires.

11.7 LTE Traffic Types

LTE networks have more traffic types than 3G networks, because all traffic is transported natively as IP packets. GTP tunneling exists, but all services and thus traffic run over the IP network. LTE traffic types can be divided into two groups: control plane and signaling, and user traffic.

On LTE networks, a vast amount of signaling and control plane traffic passes through the IP network compared with the packet-based network portion of 3G networks. Control plane and signaling traffic can be direct, indirect, or something in between.

An example of a direct control plane and signaling protocol is the mobile signaling Stream Control Transmission Protocol (SCTP), which is used to encapsulate signaling between eNodeB and MME across the Non-Access Stratum (NAS).

Indirect control plane and signaling protocols are related to the devices in the packet-based transport layer. They include the Layer 2 protocols such as ARP, spanning tree, and other resiliency protocols. Other examples are the Ethernet OAM protocols, which are used when the dominant media type is Ethernet. Examples of Ethernet OAM protocols are IEEE 802.3ah (Link OAM) and IEEE 802.1ag (Connectivity Fault Management). The indirect control plane and signaling protocols also include the traditional Layer 3 protocols, such as the IGPs (ISIS and OSPF), BGP, and MPLS, and link-local protocols, such as VRRP and PIM.

One example of both direct and indirect control plane and signaling traffic is time signaling. In 3G networks, time synchronization is built into the transport media, for example, TDM serial links or ATM networks. Unlike TDM and cell-based networks, Ethernet carries no synchronization information in its media. When the IP RAN and mobile backhaul network is upgraded to Ethernet, the base stations are isolated from the synchronization information that used to be carried over the TDM. With LTE, voice packets in need of time and clock synchronization pass in the very same IP network in the IP RAN and mobile backhaul as data traffic, for example, HTTP traffic. The classic time service synchronization is provided by either the NTP protocol, IEEE 1588, or Synchronous Ethernet as part of power over Ethernet (IEEE 802.3af).

LTE user traffic consists of both voice and Internet applications running over TCP and UDP. Traffic is both unicast and multicast, the latter including videoconferencing and online streaming media. One point to mention is that voice is just user data-plane traffic for the LTE network. An example is SIP. A VoIP packet that uses SIP for call setup is still data, just as when the call is established with UDP packets with an RTP header.

11.8 LTE Traffic Classes

A GRPS session is referred to as a PDP context. In LTE, the equivalent is generally called the bearer, which reflects a context or session. LTE networks can have several bearers, which are used at different stages along a path in the LTE network. Figure 11.11 shows the relation between the bearer services.

The LTE network is divided into different areas, with new names, including Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), which reflects the radio-only part, and EPC, which handles the packet-based networks.

A session that starts from the User Equipment (UE) and traverses the RAN and mobile backhaul towards S-GW/PDN-GW forms an EPC bearer. The focus of this discussion is on the EPC bearer, not on the end-to-end bearer, because the external barrier that is part of the end-to-end bearer might go over the Internet, crossing AS boundaries, so it needs to interact with other QOS policy domains. The assumption is that the EPC bearer runs within the same operator entity and thus within a single managed network.

Before trying to map the 3GPP and IETF QOS functions and classes for the EPC bearer, let us look at the specifics of 3GPP QOS. We briefly examine traffic separation, the types and numbers of traffic classes needed, and the QOS classes of service needed for radio traffic.

The 3GPP has defined QOS aspects in several specifications. One of the original documents, TS 23.107, “QOS Concept and Architecture,” describes a framework for QOS within UMTS. This specification defines the four traffic classes shown in Figure 11.12.

The 3GPP TS 23.203 [4] and TS 23.207 [5] specifications go further, introducing QOS Class Identifier (QCI) and nine classes for LTE. QCI is an identifier that controls the QOS details on the eNodeB, and it divides the bearers into two groups: guaranteed bit rate (GBR) bearers and non-GBR bearers. Figure 11.13 describes the nine QCI groups. Figure 11.13 shows that some of the services are backward-compatible between the UMTS and LTE specifications.

Note that the 3GPP QOS models can be adapted by the IntServ and DiffServ model. This book focuses on the DiffServ and PHP QOS models; the IntServ QOS model is beyond the scope of this book.

For packet network designers, the ratio of over-provisioning is a key topic of interest, but for radio network designers, the key topic is quality of service. IP RAN and QOS designs need to satisfy both world views simultaneously. The micro versus macro angle is very much in the spotlight here regarding how to achieve quality for the service while offering a good business model. The macro model very much adapts to GBR, while the micro model is non-GBR. The GBR model can be translated to the expedited-forwarding (EF) class in the IETF DiffServ model, using high priority and weight and buffer tuning to achieve absolute service.

Returning to the LTE QOS and the E-UTRAN and EPC, one question is whether four to nine classes in radio QOS can be mapped to the classic packet-based well-known classes following the IETF DiffServ model. If we step back from academic solutions and demands to a practical approach, we see that LTE has four classes and two or three priority levels, a number that is very similar to the well-known QOS classes in today’s packet-based networks: network-control (NC), EF, assured-forwarding (AF), and BE.

Control and signaling, and voice are two classes (NC and EF) that can be grouped into the same priority. These two traffic types cannot be over-provisioned or dropped. Instead, they require guaranteed delivery to achieve the desired quality level. Traffic volume estimates for voice on LTE networks are similar VoIP and SIP, as discussed in Chapter 4. For example, if each SIP call requires 80 kbps in one direction, the estimated number of VoIP sessions needs to fall within these bandwidth and delay demands.

The bulk of traffic, that is, the TCP traffic, is in the BE class. Surfing the web, email, chat, and so forth are all classic BE applications. With mobile networks, handheld TVs and video clips are two interactive services that are driving the increased bandwidth demands and that are used to justify GGSN and LTE capabilities. However, streamed compressed media content in unicast format and long-lasting sessions are a perfect fit for the BE class of service because neither is a true real-time broadcasting service. Instead, they are long-lasting TCP sessions used to download and watch compressed video content. Neither is very different from ordinary web service usage, and they can be managed well with TCP mechanisms. In practice, there are no differences between buffered and background TCP content if we speak in terms of QCI classes.

One of the real challenges is handling true broadcasting in the form of real-time, multicast streaming media. An example of one such application is video conferencing. This traffic follows the same structure as streamed media, as discussed in Chapter 4. It is loss sensitive, but to some extent can handle delay that results from local playback and buffering. QOS for online broadcasting is probably one of the biggest challenges for mobile solutions.

Figure 11.14 shows an example of mapping traffic classes in an LTE/UTRAN between radio and packet QOS.

Let us follow a packet between eNodeB and S-GW/PDN-GW. Figure 11.15 shows the QOS PHB changes to this packet. Many media and headers can be involved, including DSCP, 802.1p, and MPLS EXP.

11.9 Conclusion

Packet network designers are concerned with the ratio of over-provisioning, while radio network designers focus on quality of service. IP RAN and QOS design needs to fulfill both of these world views at the same time. The micro and macro angles are very much in the spotlight here regarding how to achieve quality for the service while supporting a good business model.

QOS in an LTE RAN and backhaul network depends on QOS policies such as marking and queuing, as well as handling resilience and fault recovery. The following points should always be considered for QOS with IP RAN and mobile backhaul:

• Protection and fault recovery, and Ethernet OAM
• Synchronization
• Traffic separation and services

Protection and fault recovery of paths and links are essential for QOS services. Having an IP RAN that is dependent on a spanning tree is simply not good enough. In the case of Ethernet media, Ethernet OAM is the protocol that mimics the mature resilience of SDH and optical networks. While Ethernet OAM adds more features to the toolbox compared to plain Ethernet, which from the start was designed to be cheap and to allow easy provisioning of access media, it is not a good solution for transporting sensitive real-time applications. If the access between the NodeB and S-GW is a simple path provided by a carrier, the design needs to be adapted accordingly. If you have no control of the Layer 2 media because you rent an E-Line, VLAN, or something similar, more demands are placed on the end-to-end next layer, which is IP. If the eNodeB has an IP stack, why handle it like Layer 2? Layer 3-based OAM protocols are probably better suited to provide secure fault protection by triggering rerouting to an alternative path. An example is using BFD in conjunction with routing, either static or dynamic, to achieve dual-homed access for the eNodeB.

Clock synchronization design always comes down to using the design of choice. You can have an all-packet-based design such as RFC 1588 and NTP. Another option is to involve the media by using synchronous Ethernet. In this case, handling the clock handle requires some planning. Obviously, synchronous Ethernet is useful only if you have some control of the end-to-end Layer 2 paths. Otherwise, protocols that are more packet based, such as NTP, are more suitable.

As with most things in the telecom business, the most practical advice for the QOS policy design is “less is more.” A good start is to separate the protocols and services into the three or four classes described earlier. Choosing these classes addresses the demands of both the architecture and the design of the IP RAN and mobile backhaul transport elements. If two levels of priority are enough, separating classes with the same weight can work. However, the cost and demands need to be taken into account. If you have control of the IP RAN and backhaul, a Layer 2 design could be sufficient and cost-efficient. Another consideration is network scaling. The same lessons from Internet growth need to be applied: Layer 3-based networks tend to scale well, while Layer 2-based networks do not. And the need for a Layer 3 network can happen faster than planned. If you do not control the paths, but instead rent an E-Line service, the demands and contracts need to be tight to secure sufficient uptime. Layer 3 processing is probably the only way to achieve good link management. The result of the cost savings of not having your own managed transport core is that your access equipment gets flooded with demands to handle protocols and management on layers above Layer 2 to compensate for the lack of end-to-end equipment control, for example, by adding routing and high-availability capability on the eNodeB access point to secure good availability on the path towards the S-GW and PDN-GW.

Earlier, we mentioned the protocol overhead for LTE networks because many protocols are involved for the traffic traveling between the NodeB and the S-GW. Several encapsulations can affect the eNodeB performance and QOS policy. Figure 11.16 illustrates the rewriting of code points into Ethernet and IP headers for a packet with Ethernet, 802.1q, IPsec, and GTP headers, resulting in multiple DSCP fields. The rewriting can result in many instructions to be performed if the forwarding capacity uses a central CPU-based arbitration on the eNodeB, or even on the S-GW.

The IP RAN and mobile backhaul network QOS design in a DiffServ model, that is, the model we describe in this book, is not that different from QOS in any other packet-based network. The scheduling and bandwidth ratio need to be adapted to the expected traffic volumes and to the business model. The QOS policy needs to be adapted to the traffic types. For example, real-time traffic cannot be over-provisioned or exposed to delay or packet loss to maintain quality.

At the same time, end user demands on services need to be in line with user contracts. If a user pays a fixed fee just to have Internet access and runs SIP as an application on their mobile handheld device, should the SIP traffic get better treatment than web surfing on that handheld? LTE networks will probably introduce differentiation on service levels even for real-time traffic based on subscriber policies.

To manage the policies and QOS profiles in a more dynamic way, a function called Policy and Charging Rules Function (PCRF) has been discussed for LTE networks. PCRF will work with MME to assist bearers in obtaining their QOS requirements and will be enforced on the S/PDN-GW. The idea is that when bearers are established, the QOS requirement from that bearer will be identified and negotiated with the PCRF. Then proper dynamic QOS profiles will be installed on the devices with which the PCRF communicates. PCRF is, however, still a work in progress.