LTE [1] is part of the GSM evolutionary path established by the 3rd Generation Partnership Project (3GPP) for mobile broadband, following EDGE, UMTS, HSPA and HSPA Evolution (HSPA+). The LTE standardization work within 3GPP started in 2004. The first specification (LTE Release 8) was frozen in December 2008 and was the basis for the first wave of LTE equipment that entered in the market in late 2009. From Release 8, enhancements are being introduced in subsequent releases. The production of a new 3GPP standards release usually takes between 18 and 24 months, and the introduction of new major capabilities into the standards typically spans several releases. At the time of writing, the latest frozen release is Release 11, with the core network protocols stable in December 2012 and radio access network (RAN) protocols stable in March 2013. Work is in progress towards LTE Release 12 (functional freeze date1 set for March 2015) and LTE Release 13 (functional freeze date set for March 2016). From Release 10 onwards, the technology is referred to as LTE-Advanced since it fulfils the requirements set by ITU for IMT Advanced (i.e. 4G) systems. Some new capabilities brought by LTE Release 10 such as carrier aggregation (CA) have been already commercially deployed along 2014.
The standards work developed at 3GPP is evolving today’s mobile broadband technologies by aiming to address the immense challenge facing mobile network operators in order to cope with the continued increase and high growth projections in mobile data traffic in the coming years [2]. In particular, mobile video is expected to generate much of the mobile traffic growth, increasing also the need for much higher bit rates compared to other mobile content types. In this context, the main requirements set out for LTE technology were about achieving higher spectral efficiency and higher peak data rates, as well as flexibility in frequency and bandwidth for operators to be able to deploy LTE across their diverse spectrum holdings. LTE Release 8 includes capabilities enabling downlink/uplink peak data rates of up to 300/75 Mb/s with 20 MHz bandwidth, operation in both TDD and FDD modes and supports scalable bandwidth from 1.4 up to 20 MHz. LTE-Advanced further improves the supported bit rates and spectral efficiency in a cost-efficient way, reaching peak data rates of up to 3/1.5 Gb/s over an aggregated 100 MHz bandwidth.
LTE has been designed to provide a high-rate, very-low-latency IP connectivity solution with a clear focus on the commercial business and consumer markets. The IP connectivity service delivered over LTE access can be utilized by almost any application relying on IP communications, enabling a large number of services to be provided over LTE networks. Indeed, the LTE ecosystem has matured rapidly, becoming the prevalent standard for mobile broadband communications worldwide.
However, while the aforementioned features make LTE a suitable technology for deploying a rich number of mobile broadband applications for PPDR, including video delivery, important features are still lacking to turn the LTE standard into a full mission-critical technology [3, 4] that could, in the longer term, be well positioned to replace current narrowband PMR technologies. To that end, there are several work and study items currently in progress within 3GPP aimed at extending the LTE specifications to add support for the functionalities expected by PPDR first responders as well as other mission-critical or business-critical users (e.g. utilities, transportation). These new features include:
In addition to the above features, the capabilities of LTE technology enabling the active sharing of RAN equipment by multiple operators, known as RAN sharing, are also relevant for the PPDR sector as long as they can be instrumental for the realization of PPDR service delivery models based on network sharing practices with commercial operators, as discussed in Chapter 6. In this regard, the technological enhancements being introduced in LTE RAN sharing are expected to bring further flexibility in sharing network resources so that they could permit the deployment of networks (or parts of them) that are dynamically shared between critical and non-critical users. New RAN sharing capabilities are referred to as RAN sharing enhancements and are expected to form part of Release 13.
Figure 4.1 illustrates the abovementioned list of features already supported or being introduced in LTE specifications. After a brief introduction to the LTE technology in Section 4.2, these items are further described in Sections 4.3–4.8.
Organizations such as the National Public Safety Telecommunications Council (NPSTC), TETRA and Critical Communications Association (TCCA) and the ETSI Technical Committee on TETRA and Critical Communications Evolution (ETSI TC TCCE) closely cooperate with the 3GPP to provide requirements and technical inputs to guide the specification of the necessary LTE enhancements [5]. Complementing the 3GPP work, there are other standard development organizations (SDOs) that work on application layer standards (i.e. over the top of network layer access technology standards such as LTE) with a focus for specific extensions for PPDR communications. One of these SDOs is ETSI TC TCCE, which has defined a critical communications architecture reference model [6] and, on this basis, develops the architecture for a generic mission-critical service equivalent to the existing narrowband technologies, which could be used over a broadband IP bearer, with specific focus for LTE [7]. Another SDO to playing an important role in the specification of application layer components that can be incorporated in mission-critical communications solutions is the Open Mobile Alliance (OMA). The OMA is a global organization that delivers open specifications for creating interoperable services that work across all geographical boundaries, on any bearer network. OMA has recently conducted the specification of a Push-to-Communicate for Public Safety (PCPS) application, consolidating a previous solution known as Push-to-Talk over Cellular (PoC) adopted in the commercial domain. OMA is currently working with 3GPP to find the best method for the effective transfer of this specification to 3GPP so that this can be leveraged and further continued within 3GPP to meet the requirements of the PPDR community [8]. In this regard, a new working group (WG SA6) has been set up within the 3GPP in late 2014 to specifically undertake the standardization work for applications in the mission-critical communications space [9], in what represents a major consensus effort from the industry towards the establishment of a globally recognized body for the standardization critical communications applications. In particular, WG SA6 is responsible for the definition, evolution and maintenance of the technical specifications for application layer functional elements and interfaces supporting critical communications, MCPTT being its initial focus of work. Close collaboration is expected from ETSI TCCE and OMA as well as other SDOs dealing with PPDR-related standardization (e.g. Telecommunications Industry Association (TIA) for P25) to make use of expertise available in other groups to support the development of specifications under the responsibility of WG SA6 as well as to support interworking with other critical communications applications.
It is worth highlighting that the improvements introduced in the LTE specifications, in particular proximity services and group communications, are not only relevant for the PPDR sector but also important to raise new business opportunities in the commercial and other professional sectors (e.g. transportation, utilities, government) [10]. Indeed, capitalizing and seeking synergies with the market forces in driving the evolution of the standard is a vital aspect for niche markets such as PPDR. As expressed by 3GPP officials [11], there is a need to strike a balance between more or less customization to make use of commercial products while meeting the specific requirements for PPDR and critical communications. Therefore, the approach being followed by 3GPP is to preserve the strengths of LTE in the commercial domain while adding the features needed to support critical communications and seeking to maximize technical commonality between commercial and critical communications aspects.
Once the standardization work is finalized, there is a necessary delay until the availability in the marketplace of technology that both meets the standards and is sufficiently mature to be relied upon for mission-critical communications. Typical delay in commercial LTE products and other 3GPP standards is between one and 2 years from the date that specifications are frozen by 3GPP. In this regard, some preliminary time frame expectations, according to Public Safety Communications Research (PSCR) representatives, are that prototype devices that are designed to deliver mission-critical voice over LTE will be in their labs for evaluation in 2015 [12]. In the TCCA’s opinion [3], the earliest that LTE technology suitable for PPDR and other critical data communications use could be available for purchase is 2018.
LTE is a radio access technology (RAT) designed to provide a high-bit-rate, very-low-latency IP connectivity service to IP-based packet data networks (PDNs) such as the public Internet or private networks either managed by the network operator or by a third party. LTE technology turns a mobile network into a versatile communications platform over which many applications and services built around the IP-based communications model, including real-time video and multimedia services, can be readily deployed by means of software applications running on terminals (e.g. LTE smartphones) and on servers and/or other computing devices reachable from the accessed PDNs. The LTE IP connectivity service has been designed to be able to provide differentiated treatment to IP traffic flows that might have different QoS requirements in terms of required bit rates as well as acceptable packet delays and packet loss rates. Therefore, it is said that LTE provides a QoS-enabled IP connectivity service.
An LTE network, referred to as Evolved Packet System (EPS) in the 3GPP specifications, consists of two main parts [13]: a RAN based on orthogonal frequency-division multiple access (OFDMA) technology, named Evolved UMTS Radio Access Network (E-UTRAN), and an enhanced packet-switched core network, named Evolved Packet Core (EPC). The E-UTRAN is mainly in charge of radio transmission functions, while session and mobility management functions are handled by the EPC.
The E-UTRAN consists of base stations named evolved Node Bs (eNBs) that provide the radio interface towards the UE and are directly connected to the EPC. Optionally, eNBs can be directly interconnected with each other in their vicinity for, for example, handover optimization purposes. Unlike UMTS and GSM systems in which the radio protocol stack functions were split between the base station and a central radio controller, the LTE eNB runs the full radio protocol stack. This characteristic is used to affirm that LTE follows a ‘flat’ architecture, in contrast with the hierarchical architecture of controllers and base stations used in the predecessor technologies. As part of the radio protocol stack embedded in the eNB, the Radio Resource Control (RRC) protocol is used between the UE and the eNB to control the operation of the radio interface (e.g. delivery of system information messages to UEs, activation/deactivation of bearer services, mobility control, etc.).
The EPC comprises a network entity (NE) named Mobility Management Entity (MME) to handle control functions (e.g. authentication of users and location management). Additionally, the EPC comprises two entities through which the user data traffic is transferred: a Serving Gateway (S-GW), which anchors user traffic from/to E-UTRAN into the EPC, and a PDN Gateway (P-GW), which provides the IP connectivity to the external IP networks. There is a set of protocols between the UE and the MME, referred to as non-access-stratum (NAS) protocols, to cope with session and mobility management. The operation of the EPC is assisted by the Home Subscriber Server (HSS), a central database that contains, among others, user subscription-related information.
The LTE IP connectivity service is realized through the establishment of the so-called EPS bearer services. The EPS bearer service represents the level of granularity for QoS control in E-UTRAN/EPC and provides a logical transmission path with well-defined QoS properties between the UE and the P-GW. IP-based service control platforms such as 3GPP IP Multimedia Subsystem (IMS) and related application servers can be used on top of this QoS-aware LTE connectivity service to support a diverse range of services (e.g. telephony, videoconferencing, video streaming, messaging, etc.). The IMS, also referred to as IP Multimedia Core Network (IM CN) Subsystem, enables mobile network operators to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. The IMS is mostly based on IETF ‘Internet standards’ to achieve access independence (e.g. IMS-based services can be delivered over any IP-based connectivity access network, with LTE being one of these possible access technologies) and to maintain a smooth interoperation with other terminals across the Internet. 3GPP has also specified a Policy and Charging Control (PCC) system, which provides operators with advanced tools for service-aware QoS and charging control. The PCC architecture, by means of a Policy and Charging Rules Function (PCRF) NE, enables control of the EPS bearer services (e.g. QoS settings) for both IMS and non-IMS services. Figure 4.2 illustrates the main LTE network components and interfaces among them as well as the concept of EPS bearer service between the UE and the external IP networks.
The following subsections are intended to provide an overview of the main aspects that are helpful to have a basic background and so facilitate the reading of the rest of this chapter covering the specific LTE features relevant for PPDR. For a more in-depth description of the LTE technology, the reader is referred to Refs [13–17].
The LTE radio interface, identified as Uu in Figure 4.2, is based on the orthogonal frequency-division multiplexing (OFDM) transmission technique. OFDM transmits data on a large number of parallel, narrowband subcarriers. The use of relatively narrowband subcarriers (subcarrier spacing in LTE is 15 kHz), in combination with a cyclic prefix, makes OFDM transmission inherently robust to time dispersion on the radio channel without a requirement to resort to advanced and potentially complex receiver-side channel equalization.
For the downlink, OFDM transmission simplifies the receiver baseband processing with reduced terminal cost and power consumption as consequences. This is especially important considering the wide transmission bandwidths of LTE, and even more so in combination with advanced multi-antenna transmission, such as spatial multiplexing enabled by multiple-input/multiple-output (MIMO) antenna configurations. At a given time, the set of subcarriers being transmitted can carry information addressed to different users. This multiplexing technique based on OFDM is termed as OFDMA.
For the uplink, where the available transmission power is significantly lower than for the downlink, the situation is somewhat different. Rather than the amount of processing power at the receiver, one of the most important factors in the uplink design is to enable highly power-efficient transmission. This improves coverage and reduces terminal cost and power consumption at the transmitter. For this reason, single-carrier transmission based on discrete Fourier transform (DFT)-precoded OFDM is used for the LTE uplink. DFT-precoded OFDM has a smaller peak-to-average power ratio than regular OFDM, thus enabling less complex and/or higher-power terminals. As in the downlink, user multiplexing is also supported in the uplink across the frequency domain. The transmission/multiplexing technique used in the uplink is commonly referred to as single-carrier frequency-division multiple access (SC-FDMA).
The LTE transmitted signal can be viewed as a two-dimensional entity, with a subcarrier axis (frequency dimension) and a symbol axis (time dimension), as illustrated in Figure 4.3.
In the time dimension, the transmitted signal is organized into frames of 10 ms duration. Each frame is split into 10 subframes of 1 ms duration each. The subframe is the time granularity at which users(s) can be scheduled to transmit/receive in LTE, which is known as the Transmission Time Interval (TTI). A further division of the subframe results in the slot definition, which lasts for 0.5 ms. Over this time structure, each slot has room for the transmission of seven or six OFDM symbols, depending on whether a normal or extended cyclic prefix is used (the cyclic prefix is a temporal extension of the OFDM symbol that helps to combat multipath propagation in the radio channel). The normal cyclic prefix is of 4.7 µs, suitable for most deployments, while the extended cyclic prefix of 16.7 µs can be more appropriate for highly dispersive environments. Therefore, the duration of the OFDM symbol is 71.4 or 83.4 µs, which equals to the inverse of the subcarrier spacing (1/(15 kHz) = 66.7 µs) plus the corresponding cyclic prefix.
In the frequency dimension, the total number of occupied subcarriers depends on the LTE channelization being used. In this regard, LTE defines the following set of transmission bandwidths: 1.4, 3, 5, 10, 15 and 20 MHz that results in 72, 180, 300, 600, 900 and 1200 occupied subcarriers (i.e. subcarriers used for data and reference signals, not counting subcarriers left for, e.g. guard band). Within a time slot, subcarriers are grouped in blocks of 12, forming what is known as the Resource Block (RB). Indeed, RBs are the central unit for resource allocation in LTE (i.e. the resource scheduler in LTE works with a granularity of 1 RB, so that resources are allocated to users as multiples of RBs).
This fine-grained resource resolution in both the time and frequency domains allows LTE to exploit channel-dependent scheduling in both dimensions to benefit, rather than suppress, rapid channel-quality variations due to fading, thereby achieving more efficient utilization of the available radio resources. LTE transmissions also exploit link adaptation techniques that make use of turbo coding schemes with variable coding rates and different modulations such as quadrature phase-shift keying (QPSK), 16-QAM or 64-QAM. Indeed, a radio resource scheduler is a central function in the operation of the LTE radio interface, and largely, it determines the overall system performance, especially in a highly loaded network. Of note is that in LTE both the downlink and uplink transmissions are controlled by the scheduler implemented at the eNB and are supported over shared channels, as opposed to the use of dedicated channels (i.e. unlike previous GSM and UMTS system, LTE does not add support for dedicated channels).
The shorter TTI supported by LTE compared to 3G technologies (HSPA uses a TTI of 2 ms) directly results in reduced user plane latency as well as shorter round-trip time for control signalling in the radio interface that enables the use of fast hybrid Automatic Repeat reQuest (ARQ) processes and the fast delivery of channel-quality feedback from terminals to eNBs.
A summary of the discussed parameters of the LTE radio interface is provided in Table 4.1, together with an estimation of the raw peak data rate achievable under the different bandwidth options.
Table 4.1 LTE radio transmission overview information.
Access scheme | DL | OFDMA |
UL | SC-FDMA (DFT-spread OFDM) | |
Bandwidth | 1.4, 3, 5, 10, 15, 20 MHz | |
Subcarrier spacing | 15 kHz | |
Occupied subcarriers | 72,180,300,600,900,1200 | |
ODFM symbol duration | 71.4 or 83.4 µs | |
Subframe duration (i.e. scheduler TTI) | 1 ms | |
Modulation | QPSK, 16-QAM, 64-QAM | |
(Raw) peak bit rate (for each channel bandwidth and assuming 64-QAM modulation and no spatial multiplexing) | 6, 15, 25, 50, 75, 100 Mb/s |
A central feature to highlight about LTE radio interface is its high degree of spectrum flexibility in terms of:
Another relevant feature of the LTE radio interface is the support of relaying capabilities. E-UTRAN supports relaying by having a relay node (RN) wirelessly connected to an eNB serving the RN, referred to as donor eNB (DeNB), via a modified version of the E-UTRA radio interface, denoted as Un interface [20]. One of the main benefits of relaying is to provide extended LTE coverage in targeted areas at low cost, as discussed in Chapter 3.
Table 4.2 E-UTRA operating bands [18].
E-UTRA operating band | Uplink (UL) operating band BS receive UE transmit | Downlink (DL) operating band BS transmit UE receive | Duplex mode |
FUL_low − FUL_high (MHz) | FDL_low − FDL_high (MHz) | ||
1 | 1920 − 1980 | 2110 − 2170 | FDD |
2 | 1850 − 1910 | 1930 − 1990 | FDD |
3 | 1710 − 1785 | 1805 − 1880 | FDD |
4 | 1710 − 1755 | 2110 − 2155 | FDD |
5 | 824 − 849 | 869 − 894 | FDD |
6 | 830 − 840 | 875 − 885 | FDD |
7 | 2500 − 2570 | 2620 − 2690 | FDD |
8 | 880 − 915 | 925 − 960 | FDD |
9 | 1749.9 − 1784.9 | 1844.9 − 1879.9 | FDD |
10 | 1710 − 1770 | 2110 − 2170 | FDD |
11 | 1427.9 − 1447.9 | 1475.9 − 1495.9 | FDD |
12 | 699 − 716 | 729 − 746 | FDD |
13 | 777 − 787 | 746 − 756 | FDD |
14 | 788 − 798 | 758 − 768 | FDD |
15 | Reserved | Reserved | FDD |
16 | Reserved | Reserved | FDD |
17 | 704 − 716 | 734 − 746 | FDD |
18 | 815 − 830 | 860 − 875 | FDD |
19 | 830 − 845 | 875 − 890 | FDD |
20 | 832 − 862 | 791 − 821 | FDD |
21 | 1447.9 − 1462.9 | 1495.9 − 1510.9 | FDD |
22 | 3410 − 3490 | 3510 − 3590 | FDD |
23 | 2000 − 2020 | 2180 − 2200 | FDD |
24 | 1626.5 − 1660.5 | 1525 − 1559 | FDD |
25 | 1850 − 1915 | 1930 − 1995 | FDD |
26 | 814 − 849 | 859 − 894 | FDD |
27 | 807 − 824 | 852 − 869 | FDD |
28 | 703 − 748 | 758 − 803 | FDD |
29 | N/A | 717 − 728 | FDD |
30 | 2305 − 2315 | 2350 − 2360 | FDD |
31 | 452.5 − 457.5 | 462.5 − 467.5 | FDD |
… | |||
33 | 1900 − 1920 | 1900 − 1920 | TDD |
34 | 2010 − 2025 | 2010 − 2025 | TDD |
35 | 1850 − 1910 | 1850 − 1910 | TDD |
36 | 1930 − 1990 | 1930 − 1990 | TDD |
37 | 1910 − 1930 | 1910 − 1930 | TDD |
38 | 2570 − 2620 | 2570 − 2620 | TDD |
39 | 1880 − 1920 | 1880 − 1920 | TDD |
40 | 2300 − 2400 | 2300 − 2400 | TDD |
41 | 2496 − 2690 | 2496 − 2690 | TDD |
42 | 3400 − 3600 | 3400 − 3600 | TDD |
43 | 3600 − 3800 | 3600 − 3800 | TDD |
44 | 703 − 803 | 703 − 803 | TDD |
On the one hand, the RN supports the eNB functionality – meaning that it terminates the radio protocols of the E-UTRA radio interface as well as the protocols that connect a conventional eNB to the EPC or other eNBs (e.g. S1 and X2 interfaces). On the other hand, the RN also supports a subset of the UE functionality in order to wirelessly connect to the DeNB as a ‘special’ UE (e.g. RRC and NAS protocols). It is worth noting that inter-cell handover of the RN is not supported in the current LTE specifications, so that RNs are mainly intended to be fixed or nomadic but not mobile. A simplified illustration of the architecture supporting RNs is shown in Figure 4.4.
An RN can operate in inband or outband relaying modes. In inband relaying, the relay backhaul link (Un interface) and the relay access link (Uu interface) share the same carrier frequency, whereas different carrier frequencies are employed for the backhaul and access links in outband relaying. In addition, the RN could have its own physical cell identity (cell ID) and so appear as a distinct conventional cell to the terminals. This would be the case of a non-transparent relay, also known as Layer 3 relay. On the contrary, the RN may not have a cell ID and consequently not being ‘seen’ by the served UEs. This case is known as transparent relay or Layer 2 relay. On this basis, RNs are classified into Type 1, Type 1a and Type 1b, all of them being Layer 3 relays, and Type 2, which is a Layer 2 relay. Type 1 is an outband relay, Type 1a is an inband relay able to operate in full duplex (this turns to be the most complex node since isolation is required between access and backhaul transmissions), and Type 1b is an inband relay that uses time-division multiplexing (TDM) to support the access and backhaul link on the same frequency carrier.
The QoS-enabled IP connectivity service provided by an LTE network between a given UE and a given external PDN is denoted as ‘PDN connection’. The LTE network operator may provide access to different types of PDNs, through which different types of services might be reached. One type of PDN could be, for example, the public Internet. Another type of PDN could be, for example, a private IP network belonging to the mobile network operator to offer, for example, multimedia telephony services via IMS service delivery platforms. An LTE UE may access a single PDN at a time, or it may have multiple PDN connections open simultaneously.
Each PDN connection has its own IP address (one IPv4 and/or one IPv6 address) so that all IP packets belonging to the same PDN share a common address (or a pair of addresses, if both IPv4 and IPv6 addresses are used simultaneously over the same PDN connection). A PDN is identified by a parameter named Access Point Name (APN), which is a character string that is used when selecting the PDN for which to set up the IP connectivity. One PDN connection is always established when the terminal attaches to the EPS. During the network attach procedure, the terminal may indicate the APN for the LTE network to select the PDN that the user wants to access (i.e. APN of the PDN). In case the terminal does not provide the APN, a default value from user’s subscription profile would be used. The APN is also used by the network to choose the P-GW providing access to that PDN (there can be several P-GW providing access to a given PDN, as well as a given P-GW that provides access to several PDNs). The concept of a PDN connection and associated parameters (IP address(es), APN) is illustrated in Figure 4.5, showing a particular case where a terminal is configured with three simultaneous PDN connections.
Different QoS treatments can be enforced to different IP packet flows within the same PDN connection: this is implemented through the concept of EPS bearer service. 3GPP specifications define a bearer service as a type of telecommunications service that provides the capability of transmission of signals between two network points. On this basis, an EPS bearer service, or EPS bearer for short, provides a logical transport channel between the UE and the PDN for the transmission of IP packets. Each EPS bearer is associated with a set of QoS parameters that describes the properties of the transport channel, for example, bit rates, delay and packet loss rate. All conformant traffic sent over the same EPS bearer will receive the same packet forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy, radio protocol stack configuration, etc.). In order to provide different QoS treatments to two distinct IP packet flows, they need to be sent over separate EPS bearers. Therefore, the EPS bearer is the level of granularity for bearer level QoS control in the network. A description of the QoS parameters used to specify a given treatment is provided below in this section.
The mapping of IP traffic onto the different bearers is done based on packet filters called Traffic Flow Template (TFT). Therefore, together with a set of QoS parameters, each EPS bearer is associated with packet filter information that allows the UE (in uplink) and the P-GW (in downlink) to identify which packets belong to a certain IP packet flow aggregate. This packet filter information is typically a 5-tuple defining the source and destination IP addresses, source and destination port as well as protocol identifier (e.g. UDP or TCP), while it is also possible to use additional parameters related to an IP flow (e.g. type of service/traffic class).
One EPS bearer service is always established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with the so-called ‘always-on’ IP connectivity to the PDN. That bearer is referred to as the default bearer. Any additional EPS bearer service that is established to the same PDN is referred to as a dedicated bearer. Therefore, each PDN connection has, at least, one default EPS bearer established and a number of additional dedicated EPS bearers if traffic differentiation is needed. The association of the EPS bearer service with some specific parameters (QoS, TFT) is illustrated in Figure 4.5, showing the particular case where PDN connection with APN A is using two EPS bearers, one default and one dedicated, to provide two different QoS treatments between the UE and PDN A, while the other two PDN connections in the example rely only on the default EPS bearer, thus providing the same treatment to all the packet flow aggregate transported over these connections.
As explained earlier, an EPS bearer has an associated QoS profile that determines its expected behaviour. QoS parameters defined in LTE are illustrated in Figure 4.6. EPS bearers can be classified as Guaranteed Bit Rate (GBR) bearers or non-GBR bearers. In the former, GBR resources sufficient to deliver a given GBR value are allocated and reserved (e.g. by an admission control function in the RAN) at bearer establishment/modification. In the latter, such reservation is not enforced. GBR bearers are characterized through four parameters: QoS Class Identifier (QCI), Allocation and Retention Priority (ARP), GBR and Maximum Bit Rate (MBR). In the case of non-GBR bearers, only QCI and APR parameters are associated with a bearer, and two additional parameters, UE Aggregate Maximum Bit Rate (UE-AMBR) and Access Point Name Aggregate Maximum Bit Rate (APN-AMBR), are used to characterize the aggregate behaviour of all non-GBR bearers that a UE may have established. Further details on these parameters are given in the following subsections.
The QCI parameter is a scalar value that is used as a reference to establish eNB-specific parameters that control the bearer level packet forwarding treatment (e.g. scheduling weights, queue management thresholds, configuration of the retransmission modes, etc.). The specific configuration of the packet forwarding process in eNB is managed by the network operator and not signalled on any control interface. Rather, the goal of standardizing a QCI is to ensure that applications/services mapped to a given QCI receive the same treatment in multivendor network deployments and in case of roaming. The current standardized list consists of the nine QCI values specified in 3GPP TS 23.203 [21] and reproduced in Table 4.3, which are defined in terms of the following performance characteristics: (i) resource type (GBR or non-GBR), (ii) priority, (iii) packet delay budget (PDB) and (iv) packet error loss rate (PELR).
Table 4.3 Standardized QCI characteristics [21].
QCI | Resource type | Priority | Packet delay budget (PDB) (ms) | Packet error loss rate (PELR) | Example services |
1 | GBR | 2 | 100 | 10−2 | Conversational voice |
2 | 4 | 150 | 10−3 | Conversational video (live streaming) | |
3 | 3 | 50 | 10−3 | Real-time gaming | |
4 | 5 | 300 | 10−6 | Non-conversational video (buffered streaming) | |
5 | Non-GBR | 1 | 100 | 10−6 | IMS signalling |
6 | 6 | 300 | 10−6 | Video (buffered streaming) TCP based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) | |
7 | 7 | 100 | 10−3 | Voice, video (live streaming) Interactive gaming | |
8 | 8 | 300 | 10−6 | Video (buffered streaming) TCP based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) | |
9 | 9 |
The PDB defines an upper bound for the time that a packet may be delayed between the UE and the P-GW. The fulfilment of a given PDB determines the configuration of the scheduling and link layer functions (e.g. the setting of scheduling priority weights). PDB is primarily associated with the delay introduced by the radio interface, though part of the PDB also accounts for the delay in the network side (delay estimates of roughly 10 ms on the network side for most cases and up to roughly 50 ms for a roaming scenario between Europe and the US West Coast are pointed out in 3GPP TS 23.203 [21]). In any case, the PDB values given in Table 4.3 are quite conservative. Actual packet delays, in particular for GBR traffic, are typically much lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality.
While scheduling between different packet aggregates is to be primarily based on the PDB (e.g. the scheduler serves the traffic so that the corresponding PDB is satisfied), the priority parameter (a value of 1 representing the highest priority) is used to give preference to higher-priority traffic when the target set by the PDB can no longer be met for one or more traffic aggregates.
On the other hand, the PELR parameter defines an upper bound for the rate of non-congestion-related packet losses. A PELR value applies completely to the radio interface between a UE and eNB since other losses are considered negligible. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. configuration of the retransmission modes).
As it can be observed in Table 4.3, there are four QCIs for GBR bearers and five for non-GBR bearers. According to 3GPP TS 23.203 [21], QCI 9 is to be typically used for the default bearer in the case of ‘default’/‘non-privileged subscribers’. Note that the AMBR parameter (that limits the maximum achievable bit rate) can be used in this case as the ‘tool’ to provide subscriber differentiation between subscribers with the same QCI on the default bearer (e.g. different maximum bit rates enforced per user). With similar characteristics as QCI 9 except for the priority value, QCI 8 could then be used for the default bearer of a kind of ‘premium subscribers’. In turn, there is QCI 6 that only differs in the priority value with regard to QCI 8 and 9. If the network supports Multimedia Priority Service (MPS),2 then QCI 6 could be used for the prioritization of non-real-time data (most typically TCP-based services/applications) of the MPS subscribers. Thus, in the case of congestion, MPS subscribers using default EPS bearers with QCI 6 would be favoured in front of ‘premium subscribers’ and ‘default subscribers’. The rest of QCIs (1, 2, 3, 4, 5 and 7) can be used for operator-controlled services, that is, services that require a dedicated EPS bearer with specific traffic forwarding behaviour. For example, to transfer the IP packets containing the voice frames in Voice over LTE (VoLTE) services, dedicated EPS bearers with QCI 1 could be used.
The ARP parameter is used to decide whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations. The ARP parameter is especially relevant for the admission control decision-making of GBR EPS bearer services. It can also be used to decide which existing bearers to pre-empt during resource limitations. The ARP encodes information about:
Once successfully established, the APR value associated with the EPS bearer does not have any impact on the bearer level packet forwarding treatment (e.g. scheduling and rate control). Such packet forwarding treatment is solely determined by the other EPS bearer QoS parameters (QCI and bit rate parameters).
3GPP establishes that the ARP priority levels 1–8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the serving network (SN), regardless of whether this is the home or visited network for some subscribers). The ARP priority levels 9–15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming. This ensures that future releases may use ARP priority levels 1–8 to indicate, for example, emergency and other priority services within an operator domain in a backward compatible manner. This does not prevent the use of ARP priority levels 1–8 in roaming situation in case appropriate roaming agreements exist that ensure a compatible use of these priority levels.
It is worth mentioning that the ARP may be used to free up capacity in exceptional situations, for example, a disaster situation [22]. In such a case, an LTE eNB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption vulnerability information allows this.
For non-GBR bearers, rate limiting can be enforced through the Aggregate Maximum Bit Rate (AMBR) parameters. In particular, the APN-AMBR can be used to enforce a maximum aggregate bit rate across all of the UE bearers for one APN (i.e. all non-GBR bandwidths flowing through the UE and particular external IP network). Another rate limiting control for non-GBR bearers is the per UE-AMBR. This rate liming control is enforced across all of non-GBR bearers that are associated with a UE, independent of the bearer’s termination point (i.e. all non-GBR bandwidths flowing through the UE and any external IP network). The LTE network will allow rates up to the minimum of the APN-AMBR and UE-AMBR values for a UE, and if exceeded, data rates can be throttled. Once the UE’s aggregate bit rate falls below the maximum value, the system will no longer throttle data.
For GBR bearers, the offered bit rate is controlled through two parameters: the GBR and an MBR associated with each bearer. The GBR value is the minimum bandwidth provided by the network should the bearer be admitted. The admission process has to allocate enough bandwidth to assure the delivery of data up to the value of the GBR. This bandwidth is available to the UE independent of the network congestion levels. On the other hand, the MBR is the absolute maximum amount of bandwidth that the GBR bearer can utilize once it has been admitted. The MBR allows for additional bandwidth utilization above the GBR value assuming there are resources available in the network. Once the MBR bandwidth is exceeded, the network can throttle the excessive bandwidth usage. The GBR and MBR limits essentially create a minimum and maximum amount of bandwidth that can be used for a given GBR bearer.
3GPP specifies the functionality for PCC with the following main functions [21]:
The PCC subsystem enables a centralized control to ensure that services and applications running on top of the LTE network are provided with the appropriate transport, that is, service-aware QoS configuration of the EPS bearers, while providing also the means to control charging on a per-service basis. Indeed, the PCC subsystem is an access-agnostic framework that could be applicable to a number of accesses other than LTE (i.e. GPRS, UMTS but also non-3GPP access technologies).
The reference network architecture for the PCC subsystem for LTE access is shown in Figure 4.7. The central element of this architecture is the PCRF. This element encompasses both policy control decision and flow-based charging control functionalities. Decisions made by the PCRF are in the form of PCC rules that are sent to the LTE network over the Gx interface for enforcement in the Policy and Charging Enforcement Function (PCEF) located within the P-GW. Criteria such as the QoS subscription information may be used together with policy rules such as service-based, subscription-based or predefined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow. The Gx interface is also used for the PCEF to provide the PCRF with user- and access-specific information. The usage of the monitoring control capability is also supported to enable dynamic policy decisions based on the total network usage in real time. Another important capability is the application detection and control feature, which comprises the request to detect the specified application traffic, to report to the PCRF on the start or stop of application traffic and to apply the specified enforcement and charging actions.
The PCRF terminates an interface named Rx over which external application servers (e.g. residing on service delivery platforms such as IMS) can send service-related information, including resource requirements for the associated IP flow(s). In this regard, the term application function (AF) is the generic term used to refer to the functional entity that interacts (or intervenes) with applications or services that require dynamic PCC. Typically, the application level signalling for the service passes through or is terminated in the AF (i.e. within the IMS platform, there is a functional entity that takes on the role of the AF for the interaction between IMS services and the PCC subsystem). The AF can also subscribe to certain events that occur at the traffic plane level (e.g. IP session termination, access technology type change, etc.). Decisions made by the PCRF also rely on subscriber-related information, obtained through the interface Sp from a Subscriber Profile Repository (SPR).
On the side of the charging-related functionality, the Online Charging System (OCS) is a credit management system for pre-paid charging, while the Offline Charging System (OFCS) is used for post-paid charging. The PCEF performs measurements of user data plane traffic (e.g. traffic volume and/or time duration) and interacts with the OCS over the Gy interface to check out credit and report credit status. For online charging, there is also the Sy reference point between PCRF and OCS that enables the transfer of policy counter status information related to subscriber spending (e.g. notifications of spending limit reports from OCS to PCRF). For offline charging, the PCEF reports charging events to the OFCS over the Gz reference point. This information is used by the OFCS to generate charging data records (CDRs) to be transferred to the billing system.
The use of the PCC functions for real-time service control is enabling innovative types of service to be offered. Examples are: fair usage, allowing operators to limit (throttle) the bandwidth available to the heaviest users on their unlimited data plans; RAN congestion, facilitating premium customers to receive guaranteed bandwidth during periods of RAN congestion; bill-shock prevention, allowing operators to warn users that they have exceeded their usage allocation or that their charges have exceeded a specified amount; ‘freemium’, through which operators can apply a ‘zero-rated’ tariff to traffic for specific applications/websites, such as Facebook, Twitter and the like; time-based usage, enabling offers of discounted or free data usage (data passes) based on time of day (peak or off-peak plans) that can be monthly, weekly, daily or hourly; and tiered services, allowing operators to provide a range of appropriately priced packages with limits based on access speed, download cap, time of day and so on [23].
In the context of PPDR communications, the PCC subsystem enables the deployment of a powerful framework for dynamic policies that can be adapted to specific incident needs, as discussed further in the Section 4.5.
The increasingly rapid evolution and growth in the complexity of new systems and networks, coupled with the sophistication of changing threats and the presence of intrinsic vulnerabilities, present demanding challenges for maintaining the security of communications systems and networks. This is particularly relevant in the context of mobile networks such as LTE, since the wireless interface that terminals use to access the network makes these systems more exposed to different attacks (e.g. eavesdropping of wireless transmissions, or even manipulation, by third parties; denial-of-service attacks, preventing legitimate users from getting access to the system).
Inherited and evolved from the previous GSM and UMTS systems, LTE specifications adopt a security architecture organized in five functional areas [24], as illustrated in Figure 4.8:
Each of these areas represents a group of security features needed to face certain threats and accomplish certain security objectives. The security features in (I) and (II) are the subject of this overview since they are the ones directly related to the LTE network itself. More details on the other security domains can be found in 3GPP TS 33.401 [24] and TS 33.102 [25].
Access security in E-UTRAN consists of the following components:
Figure 4.9 illustrates these components (except the use of temporary identities).
Mutual authentication covers both user authentication (i.e. the property that the SN corroborates the user identity of the user) and network authentication (i.e. the property that the user corroborates that he/she is connected to an SN that is authorized by the user’s home network to provide services to him/her). Mutual authentication in E-UTRAN is based on the fact that both the USIM card and the network (the authentication centre (AuC) function embedded within the HSS) have access to the same secret key K. This is a permanent key that never leaves the USIM or the HSS/AuC and, as such, is not directly used to protect any traffic. Instead, other keys are generated from the key K in the terminal and in the network during the authentication procedure, which are the ones used for the ciphering and integrity protection services. The mechanism for authentication as well as for key generation in E-UTRAN is named EPS Authentication and Key Agreement (EPS AKA). EPS AKA is performed when the user attaches to the EPS via E-UTRAN access. The procedure takes place between the UE and one MME entity in the SN, which receive an EPS authentication vector (AV) for that particular user (IMSI) from the home network’s HSS/AuC. The AV consists of the parameters (generated with the key K as input, but not explicitly contained within the AV) needed for the mutual authentication and for the derivation of the ciphering and integrity keys to be used within the MME (for the NAS signalling) and within the serving eNB (for user plane and RRC signalling). For those readers familiar with UMTS, the EPS AKA resembles the procedure used in UMTS and referred to as UMTS AKA. However, there a few differences to highlight:
As far as signalling/control plane protection is concerned, NAS signalling between the UE and MME is protected end to end with integrity and confidentiality features. Moreover, integrity and confidentiality protection is also provided for the radio network signalling (RRC signalling, which is also used to encapsulate NAS signalling) over the radio path between the UE and the eNB. Regarding the user plane (i.e. transfer of user IP packets), confidentiality protection is provided between the UE and the eNB, though, unlike the signalling/control plane, integrity protection is not supported.
The LTE standard allows the usage of different cryptographic algorithms for ciphering and integrity protection. Two sets of security algorithms were initially developed for LTE: one set based on Advanced Encryption Standard (AES) and the other on SNOW 3G. The principle being adopted is that the two should be as different from each other as possible to prevent similar attacks being able to compromise them both. The ETSI Security Algorithms Group of Experts (SAGE) is responsible for specifying the algorithms. The key length is 128 bits, with the possibility to introduce 256-bit keys in the future if necessary. In 2011, a third algorithm, ZUC, was approved for its use in LTE. The encryption algorithm 128-EEA3 and the integrity algorithm 128-EIA3, based on ZUC, were finalized in 2012. The UE and the network need to agree on which algorithm to use for a particular connection.
Finally, the identity protection capabilities of LTE also deserve some attention. As in UMTS networks, LTE provides:
To achieve these identity protection objectives, the user is normally identified by a temporary identity (e.g. Globally Unique Temporary Identifier (GUTI)) by which he/she is known by the visited SN. To avoid user traceability, which may lead to the compromise of user identity confidentiality, the user should not be identified for a long period by means of the same temporary identity. In addition, it is required that any signalling or user data that might reveal the user’s identity is ciphered on the radio access link. Only when the user cannot be identified by means of a temporary identity, a user identification mechanism should be invoked by the SN to retrieve the IMSI from the connected terminal/user. This mechanism is initiated by the MME that requests the user to send its permanent identity. The user’s response contains the IMSI in clear text. This represents a breach in the provision of user identity confidentiality.
More details on LTE access security can be found in 3GPP TS 33.401 [24], together with the security provisions for the interworking between E-UTRAN and UTRAN and GERAN. Besides, security features in the case of getting access to EPS from non-3GPP RATs are covered in 3GPP TS 33.402 [26].
In 2G systems (e.g. GSM), no solution was specified on how to protect traffic in the core network. This was not perceived as a problem since the specific protocols and interfaces used for circuit-switched (CS) traffic were typically only accessible to large telecom operators. With the introduction of packet data services (e.g. GPRS, EPS) in mobile communications systems as well as IP transport in general, the signalling of 3G/4G networks runs over networks and protocols that are more open and accessible. Therefore, 3GPP has developed specifications on how IP traffic is to be secured within the core network as well as between a core network and some other (core) networks to be interconnected. These specifications are known as network domain security for IP-based control planes (NDS/IP) [27].
A central concept introduced in the NDS/IP specification is the notion of security domain. A security domain is a network or part of it that is managed by a single administrative authority. Within a security domain, the same level of security and usage of security services can be expected. Typically, a network operated by a single network operator or a single transit operator will constitute one security domain, although an operator may at will organize its network into separate subnetworks from a security standpoint. The border between the security domains is protected by Security Gateways (SEGs). The SEGs are responsible for enforcing the security policy of a security domain towards other SEGs in the destination security domain. The network operator may have more than one SEG in its network in order to avoid a single point of failure or for performance reasons. An SEG may be defined for interaction towards all reachable security domain destinations, or it may be defined for only a subset of the reachable destinations. All NDS/IP traffic shall pass through an SEG before entering or leaving the security domain. The basic idea to the NDS/IP architecture is to provide hop-by-hop security. Therefore, chained-tunnel and hub-and-spoke connection models are used to enforce hop-by-hop-based security protection within and between security domains. The use of hop-by-hop security makes it easy to operate separate security policies internally in a security domain and towards other external security domains.
The traffic between SEGs is protected at network layer, using the IPsec protocols defined by IETF as specified in RFC-4301 [28]. IPsec offers a set of security services, which is determined by the negotiated IPsec security associations (SAs). An SA can be defined as a simplex ‘connection’ that affords security services to the traffic carried by it. In this way, the IPsec SA defines which security protocol to be used, the mode and the endpoints of the SA. Security protocols that form part of the IPsec framework are Authentication Header (AH) and Encapsulating Security Payload (ESP). These protocols can operate in either tunnel and transport modes (the tunnel mode encapsulates the full IP packet to be protected into another IP packet, while the transport mode does not). For NDS/IP networks, the IPsec protocol between SEGs shall always be ESP in tunnel mode. Within a security domain, the use of transport mode is also allowed. For NDS/IP networks, it is further mandated that integrity protection/message authentication together with anti-replay protection shall always be used. Therefore, the security services provided by NDS/IP are:
To set up the IPsec SAs between SEGs, Internet Key Exchange 1 (IKEv1) or Internet Key Exchange 2 (IKEv2) is used for key management and distribution. The main purpose of IKEv1 and IKEv2 is to negotiate, establish and maintain the SAs between parties that are to establish secure connections (from Release 11 onwards, support of IKEv2 is required; thus, it is likely that support of IKEv1 in SEGs will no longer be mandatory in future 3GPP releases). Thus, the concept of an SA is central to IPsec protocols and IKEv1/IKEv2. Security services are afforded to an SA by the use of AH, or ESP protocols, but not both. If both AH and ESP protection are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. To secure typical, bidirectional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement.
The profiling of the protocols ESP, IKEv1 and IKEv2 for the NDS/IP application is specified in 3GPP TS 33.210 [27]. These profiles provide the minimum set of features that must be supported and are required for interworking purposes.
An example scenario employing the NDS/IP architecture is shown in Figure 4.10. In this case, the traffic transfer between security domains A and B is secured by an ESP SA in tunnel mode between SEG A and SEG B. The IKE connection is used to establish the needed IPsec SAs. SEGs will normally maintain at least one IPsec tunnel available at all times to a particular peer SEG. Inside each domain, the NEs may be able to establish and maintain ESP SAs as needed towards an SEG or other NEs. All NDS/IP traffic from an NE in one security domain towards an NE in a different security domain will be routed via the corresponding SEG and will be afforded hop-by-hop security protection towards the final destination. Although NDS/IP was initially intended mainly for the protection of control plane signalling only, it is possible to use similar mechanisms to protect the user plane traffic. As an extension to the NDS/IP framework, 3GPP TS 33.310 [29] defines an inter-operator public key infrastructure (PKI) based on the use of certificates that can be used to support the establishment of the IPsec connections in NDS/IP.
The policy control granularity afforded by NDS/IP is determined by the degree of control with respect to the ESP SA between NEs and SEGs. The normal mode of operation is that only one ESP SA is used between any two NEs and SEGs, and therefore, the security policy will be identical to all secured traffic passing between NEs. This is consistent with the overall NDS/IP concept of security domains, which should have the same security policy in force for all traffic within the security domain. However, operators may decide to establish more than one ESP SA between two communicating security domains should finer-grained security granularity be required. The actual inter-security domain policy is determined by roaming agreements when the security domains belong to different operators and the SEGs are responsible for enforcing security policies for the interworking between networks. In addition to NDS/IP security services, the security may include filtering policies and firewall functionality not specified within 3GPP NDS/IP. Indeed, simple filtering may be needed before the SEG functionality. The filtering policy must allow key protocols such as Domain Name Service (DNS) and Network Time Protocol (NTP) to pass, as well as IKEv1/IKEv2 and IPsec ESP in tunnel mode protocols. Unsolicited traffic shall be rejected. In addition, SEGs shall be physically secured and offer capabilities for secure storage of long-term keys used for IKE authentication.
Roaming is defined as the use of mobile services from another operator, which is not the home operator (i.e. the operator with which the user holds its subscription). Roaming is a key capability supported in current mobile communications networks, especially exploited to provide service to users when abroad.
LTE supports two roaming architectures [22, 30]:
Both architectures are illustrated in Figure 4.11. The three relevant interfaces for roaming support in LTE networks are the following:
The fact that LTE is an all-IP technology makes that the voice service has to be delivered in a different way as it is done in the previous CS-based technologies. Indeed, GSM and UMTS RAN support the establishment of voice services though dedicated connections that are delivered over a separate CS core network (made of so-called mobile switching centres (MSCs)). However, the LTE RAN (E-UTRAN) has been designed not to use any CS core network and instead deliver all services over a packet-switched network (EPC). Therefore, voice services in LTE networks are to be delivered by using a Voice over IP (VoIP) approach, being IMS the platform that has been established by the 3GPP to support this sort of VoIP solutions. In this regard, 3GPP has specified all of the ‘ingredients’ to implement IMS-based voice services but left it up to operators and vendors to decide which of the numerous alternative implementation options to use. On this basis, to avoid fragmentation and incompatibility in the delivery of voice services over LTE, as well as for mobile operators to protect their revenues in front of over-the-top (OTT) voice service offers (e.g. Skype, Google Talk), a standardized scheme to provide the voice and SMS services has been adopted within the wireless commercial industry. This scheme is commonly referred to as Voice over LTE (VoLTE). The implementation of VoLTE offers operators many cost and operational benefits, for example, eliminating the need to have voice on one core network and data on another. VoLTE is also expected to unlock new revenue potential: utilizing IMS as the common service platform, VoLTE can be deployed in parallel with video calls over LTE and Rich Communications Suite (RCS) multimedia services including video share, multimedia messaging, chat and file transfer.
The mandatory set of functionalities that has been agreed for the UE, the LTE access network, the EPC network and the IMS functionalities for VoLTE is specified in the Permanent Reference Document (PRD) IR.92 [31] published and maintained by the Global System for Mobile Association (GSMA). The profile defined in GSMA IR.92 includes the following aspects:
An illustrative view of the UE and network protocol stacks forming the scope of the VoLTE solution is depicted in Figure 4.12. In the upper layers, the VoLTE implementation relies on the use of a set of Internet-based protocols, including Session Initiation Protocol (SIP) and Extensible Markup Language (XML) Configuration Access Protocol (XCAP). SIP is the core protocol for session management (e.g. service registration, activation, etc.). XCAP is used for the configuration of supplementary services (e.g. line identification, forwarding, barring). Support for the Adaptive Multi-Rate (AMR) codec specified by 3GPP is mandated, which is also used in GSM and UMTS. This provides advantages in terms of interoperability with legacy systems (i.e. no transcoders are needed). Additionally, the AMR Wideband (AMR-WB) codec has to be used for high-definition (HD) voice service offers. Voice frames are sent encapsulated in the Real-time Transport Protocol (RTP). UE and the network must support both IPv4 and IPv6 for all protocols that are used for the VoLTE application (e.g. SIP, SDP, RTP, RTCP and XCAP/HTTP). In the network layers, VoLTE leverages the QoS capabilities defined for EPS bearer services, which specify different QoS classes. Optimization features available in LTE to make voice operation more efficient include semi-persistent scheduling (SPS) and TTI bundling. SPS reduces control channel overhead for applications that require a persistent and periodic radio resource allocation. Meanwhile, TTI bundling (transmitting in a set of contiguous TTI) can improve uplink coverage. Optimizations also include support for vocoder rate adaptation, a mechanism with which operators can control the codec rate based on network load, thus dynamically trading off voice quality against capacity. The support of Robust Header Compression (ROHC) is also mandated to reduce the overhead associated with the IP and transport layer headers. The VoLTE solution also mandates the support of Single Radio Voice Call Continuity (SRVCC) capability, which provides seamless handover of voice calls from VoLTE to 2G/3G access. Complementing PRD IR.92, GSMA has also delivered PRD IR.94 [32] that defines a minimum mandatory set of features on top of GSMA PRD IR.92 to implement conversational video services.
A detailed description of the VoLTE solution can be found in Ref. [33], together with some illustrative figures about VoLTE performance in terms of radio coverage, radio capacity and end-to-end latency. With regard to radio coverage, [33] claims that similar voice coverage as in UMTS systems can be achieved by using TTI bundling and retransmission techniques. In terms of capacity, considering the use of header compression techniques and 12.2 kb/s voice codecs, between 40 and 50 simultaneous users can be served in 1 MHz of spectrum well above the efficiencies of 10 users/MHz achieved in systems such as GSM with similar voice codecs. With regard to latency performance, mouth-to-ear delay budgets in the range of 160 ms are achievable, which are lower than those delivered in today’s CS voice calls.
VoLTE services have been already launched along 2014 across the North America and Asia-Pacific regions, with new deployments expected to accelerate in 2015 and beyond. Moreover, consumer-grade HD voice over LTE is already a reality, significantly increasing voice intelligibility, which is anticipated to become a very attractive feature to mission-critical voice, particularly when compared to currently achieved PMR voice quality standards.
Group communications with PTT features are central capabilities in mission-critical voice services, as discussed in Chapter 1. These capabilities are well supported in current PMR technologies but thus far have not received much attention in the commercial domain. While it is considered that the initial primary focus of embracing LTE for PPDR is to deliver broadband data applications, the progressive maturity of the VoLTE technology together with the introduction of these mission-critical voice features in LTE paves the way for a mid- to long-term migration scenario in which both mission-critical voice and data services will eventually be supported over a common communications platform.
Indeed, there is global interest in LTE as a voice solution for the PPDR community. Some relevant PPDR associations have also made public their positions regarding the support of mission-critical voice over LTE networks. In particular, in the policy statement issued by APCO Global Alliance to endorse LTE as the global standard for emergency communications broadband networks, it is stated that ‘Advanced 4G systems’ cellular services will provide a comprehensive and secure IP-based mobile broadband network solution for wireless data, video and voice communications for emergency services worldwide’ [34]. As well, the Critical Communications Broadband Group (CCBG) of the TCCA has acknowledged that group communications and PTT are critical communications applications for future voice services over LTE [3].
This global interest and emphasis on mission-critical voice over LTE has resulted in standardization efforts for a global solution within 3GPP that is expected to be concluded under Release 13. Meanwhile, there are already a number of initiatives and proprietary products on the market that provide group communications and PTT capabilities over commercial IP connectivity networks (LTE, 3G). These ‘PTT over LTE’ solutions already available or under development may well serve some industries and disciplines. However, it is becoming a fragmented market, and current solutions do not provide some of the most basic functionalities required by PPDR responders such as direct mode operation (DMO). Indeed, a document establishing PTT over LTE requirements for PPDR users [35] was delivered by NPSTC in July 2013 for consideration by FirstNet as it embarks on its mission to deploy the nation’s first nationwide public safety broadband network (NPSBN) in the United States as well as by the 3GPP within its specification work.
An overview of the existing initiatives and solutions for PTT over LTE is addressed in the next section. After that, the 3GPP standardization work on group calls and PTT is explained. In particular, the so-called Group Communications System Enablers (GCSE) features being added to the LTE standard as well as the support of a standardized MCPTT application over LTE are covered. The section is concluded with an overview of the current activities at the OMA related to the further enhancement of the OMA’s PoC enabler to meet public safety user needs.
Nowadays, commercial PTT services are already available and the offerings are likely to continue growing. Three main approaches are followed in the current offers [36]:
As to the first approach, PTT services have been available for a number of years mainly in the US market, beginning with Nextel Communications launching its Direct Connect service back in 1993. Nowadays, several of the leading commercial carriers in the United States offer PTT voice services, also referred to as PoC. Indeed, PTT services from AT&T and Verizon Wireless are also delivered over their LTE networks. However, each network is using a different PTT technology, which is not cross network compatible.
On the second approach, there are numerous smartphone applications that emulate PTT on a device using an LTE network. Several companies have developed enterprise-level software solutions with such functionality. Two examples are WAVE and Voxer Walkie-Talkie PTT applications, which offer a PTT subscription service for mobile workforce communications.
Finally, as to the third approach, manufacturers in the PMR industry domain are already developing technology with PTT over LTE together with PTT bridges for the interworking with the legacy PMR networks. Indeed, companies such as Alcatel-Lucent, Cassidian, Harris, Motorola, Thales and others have been demonstrating PTT over LTE and cross-network LTE since 2012 (e.g. BeOn by Harris, Broadband Push to Talk by Motorola, etc.). However, once again, each vendor is using a different technology for its PTT solution. These solutions are not compatible with each other so that, until a common interface is not decided upon, the use of PTT over LTE remains proprietary to each vendor.
The following Work Items (WIs) have been established within 3GPP to develop specifications for group communications and PTT application over LTE:
Table 4.4 lists the main 3GPP technical specifications and reports related to the above WIs.
Table 4.4 3GPP documents covering group communications system enablers and MCPTT over LTE.
Work Item (WI) | Related technical specifications/reports | Comments |
GCSE_LTE and SRM_GCSE_LTE | TS 22.468 – ‘Group Communication System Enablers for LTE’ | Normative requirements document (Stage 1) (see Note 1 below) |
TR 23.768 – ‘Study on Architecture Enhancements to Support Group Communication System Enablers for LTE’ | Informative technical report containing candidate architectural proposals for GCSE_LTE | |
TS 23.468 – ‘Group Communication System Enablers for LTE’ | Normative specification work of the functional architecture (Stage 2) | |
MCPTT | TS 22.179 – ‘Mission Critical PTT over LTE’ | Normative requirements document (Stage 1) |
TS 23.179 – ‘System Architecture Enhancements for Mission Critical PTT over LTE’ | Normative specification work of the functional architecture (Stage 2) | |
TR 23.779 – ‘Study on architectural enhancements to support Mission Critical Push To Talk over LTE (MCPTT) Services’ | Technical report to support the specification of Stage 2 architecture definition |
Note 1: Standards development in 3GPP progresses through three stages:
In addition, 3GPP often performs feasibility studies, the results of which are made available in technical reports (normally 3GPP internal TRs, numbered xx.7xx or xx.8xx).
WI GCSE_LTE has established the requirements and developed the associated extended features within the 3GPP system group communications services (GCS) using E-UTRAN access. These extensions are denoted as GCSE. Of note is that GCSE do not cover the specification of a particular GCS but only the ‘support’ within the LTE network to deploy any GCS. From the perspective of the GCSE, a GCS is basically conceived as a fast and efficient mechanism to distribute the same content to multiple users in a controlled manner. A GCS is expected to be able to deliver different types of media. Examples of media are conversational-type communication (voice, video), streaming (video), data (messaging) or a combination of them. The requirements established for the development of the GCSE features are specified in 3GPP TS 22.468 [40]. Sources of input requirements for GCSE include organizations such as the US NPSTC, TCCA, APCO Global Alliance, the International Union of Railways (UIC) and the ETSI Special Committee EMTEL and Project MESA. The GSCE requirements have been developed ensuring some flexibility to accommodate the likely different operational requirements for various types of critical communications user groups. Based on the requirements established in TS 22.468 [40] and on the analysis of different technical solutions for the GCSE reported in 3GPP TR 23.768, the architecture enhancements for 3GPP systems to support GCS are detailed in TS 23.468 [41]. Of note is that some of the functions requested by Stage 1 in TS 22.468 were not handled in Release 12 and these are addressed under Release 13 [38].
While GCSE are being introduced without any specific application in mind, WI MCPTT is complementing this work with further features that are needed to support an MCPTT service over LTE (i.e. the MCPTT service is a particular realization of a GCS). Therefore, the MCPTT service is intended to leverage the GSCE features to provide PTT voice communications with comparable performance to the PTT functionality currently available in PMR/LMR. The ultimate goal is to come up with a single, widely adopted global standard for a MCPTT application, avoiding as much as possible the current fragmentation.
The GCSE and MCPTT extensions are designed to complement the capabilities and features associated with the support of proximity-based services (ProSe), explained later in Section 4.4. Therefore, applications like MCPTT are intended to work also when terminals are out of network coverage (off-network scenarios), even though not all functions could be available in this case. A further insight into the features within the GCSE and MCPTT application is provided in the following subsections.
The specification of the GCSE in 3GPP has been developed to meet the following main requirements [40]:
A high-level view of the overall architecture of a group communications system on top of the 3GPP EPS is shown in Figure 4.13. The architecture is split into two separate layers [41]:
The support of MBMS requires the addition of new capabilities to existing functional entities of the 3GPP architecture together with the introduction of two new functional entities: the Broadcast Multicast Service Centre (BM-SC) and the MBMS Gateway (MBMS-GW). The BM-SC provides functions for MBMS user service provisioning and delivery. The BM-SC serves as an entry point for the content provider, allowing it to authorize and initiate MBMS bearer services within the network and schedule and deliver MBMS transmissions. Furthermore, the MBMS-GW provides the interface for the entities that are actually using the MBMS bearers (through SGi-mb (user plane) and SGmb (control plane) reference points) and supports IP multicast distribution of MBMS user plane data to eNBs (M1 reference point in Figure 4.13). MBMS on LTE is also denoted as evolved MBMS (eMBMS). A tutorial on MBMS over LTE is provided in Ref. [43].
On this basis, two reference points are central in the proposed architecture:
The architecture assumes that the GCS AS is not associated with any particular network (regardless of the subscription of the UEs that use the GCS). In this regard, 3GPP TS 23.246 [42] covers both roaming and non-roaming scenarios. The group communications system allows for delivering application signalling and data to a group of UEs either (i) over MBMS bearer services or (ii) over EPS bearers or (iii) over both MBMS and EPS bearer services. QoS parameters of both EPS bearers and MBMS bearers can be controlled from the networks. Indeed, QoS attributes related to the GBR EPS bearer service (e.g. QCI, ARP, GBR and MBR) are also applicable to MBMS bearer services. In uplink direction, each UE establishes an EPS bearer service to transfer application signalling and data to the GCS AS. In downlink direction, the GCS AS may transfer application signalling and data via the UE individual EPS bearer services and/or via MBMS bearer service. The MBMS bearer(s) used for MBMS delivery can be pre-established before the group communications session is set up or can be dynamically established after the group communications session is set up. The GCS UEs register with their GCS AS using application signalling for participating in one or multiple GCS groups. When an MBMS bearer service is used, its broadcast service area (i.e. LTE cells involved in the delivery of the information) may be preconfigured for use by the GCS AS. Alternatively, the GCS AS may dynamically decide to use an MBMS bearer service when it determines that the number of UE for a GCS group is sufficiently large within an area (e.g. within a cell or a collection of cells).When MBMS bearer service is used, GCS AS may transfer data from different GCS groups over a single MBMS broadcast bearer. The application signalling and data transferred via MBMS bearer(s) are transparent to BM-SC and the MBMS bearer service. The GCS AS provides the UEs via GCS application signalling with all configuration information that the UE needs to receive application data via MBMS bearer services and to handle that data appropriately. When a GCS UE using MBMS bearer services moves to an area where the MBMS bearers are not available, the UE informs the GCS AS via application signalling that it changes from MBMS broadcast bearer reception to non-reception and the GCS AS activates the downlink application signalling and data transfer via the UE individual EPS bearer(s) as appropriate. To accomplish service continuity in this switching between EPS bearer(s) and MBMS bearer(s), in both ways, a UE may temporarily receive the same GCS application signalling and data in parallel. The GCS UE application discards any received application signalling or data duplicates.
Figure 4.14 shows an example of a scenario where a combination of unicast and MBMS traffic is used by the GCS AS on the DL to different UEs. Here, UE-1 to UE-3 receive DL traffic over unicast, whereas UE-4 to UE-6 receive DL traffic over eMBMS. The decision about whether a particular GCSE group communication (or UE/receiving group member) is using unicast delivery or multicast delivery is determined by the GCS AS. UL traffic, not shown in the illustration, is always done via unicast.
The MCPTT over LTE service is intended to support an enhanced PTT service, suitable for mission-critical scenarios, between several users (a group call), each user having the ability to gain access to the permission to talk in an arbitrated manner [44]. The MCPTT service builds on the existing 3GPP transport communications mechanisms provided by the EPS architectures, extended with the GCSE and ProSe capabilities, to establish, maintain and terminate the actual communications path(s) among the users. To the extent feasible, it is expected that the end user’s experience to be similar regardless if the MCPTT service is used under coverage of an EPC network or based on ProSe without network coverage.
Though the MCPTT service primarily focuses on the use of LTE, there might be users who access the MCPTT service through non-3GPP access technology. Examples are dispatchers and administrators. These special users typically have particular administrative and call management privileges that normal users might not have. In MCPTT, dispatchers can use an MCPTT UE (i.e. LTE access) or a non-3GPP access connection to the MCPTT service based on an interface specifically designed for such a purpose.
The MCPTT service allows users to request the permission to talk (transmit voice/audio) and provides a deterministic mechanism to arbitrate between requests that are in contention (i.e. floor control). When multiple requests occur, the determination of which user’s request is accepted and which users’ requests are rejected or queued is based upon a number of characteristics (including the respective priorities of the users in contention). MCPTT service provides a means for a user with higher priority (e.g. emergency condition) to override (interrupt) the current talker. MCPTT service also supports a mechanism to limit the time a user talks (hold the floor), thus permitting users of the same or lower priority a chance to gain the floor.
The MCPTT service provides the means for a user to monitor the activity on a number of separate calls and enables the user to switch focus to a chosen call. An MCPTT service user may join an already established MCPTT group call (i.e. late call entry feature). In addition, the MCPTT service provides the user identity of the current speaker(s) and user’s location determination features. Moreover, MCPTT users would also be able to communicate with non-MCPTT users using their MCPTT UEs for normal telephony services.
MCPTT is primarily targeting to provide a professional PTT service to, for example, public safety, transport companies, utilities or industrial users with more stringent expectations of performance than the users of a commercial PTT service. In addition, the specification also envisions the use of an MCPTT system for delivering a commercial PTT service to non-professional users. Based on the addressed users, the performance and MCPTT features in use can vary (i.e. more mission-critical specific functionalities such as ambient listening or imminent peril call might not be available to commercial customers).
The service requirements for the operation of the MCPTT service are specified in 3GPP TS 22.179 [44]. Sources of input requirements came from multiple organizations (e.g. FirstNet, the UK Home Office, NPSTC [35], TCCA, APCO Global Alliance, TIA, OMA, ETSI TC TCCE). Some of the key requirements are summarized in the following:
The current work in 3GPP centres on the study and evaluation of possible 3GPP technical system solutions for architectural enhancements needed to support MCPTT services based on the above requirements. A general principle being followed in the architectural design is the possibility for network operators to reuse the MCPTT architecture for non-public safety customers that require similar functionality. This could facilitate that these operators may integrate many components of the MCPTT solution with their existing network architecture. This approach requires the functional decomposition of MCPTT into a small number of distinct logical functions (e.g. ‘group management functions’, ‘PTT functions’). As an illustrative example of this work, Figure 4.15 shows some preliminary schematics of the high-level functional entities and main reference points under consideration in Ref. [45] for the implementation of the MCPTT service in both on-network and off-network scenarios. In the on-network operation scenario, an MCPTT server is placed on the network side, on top of the EPS layer. Indeed, the MCPTT server is a specific instantiation of the generic GCS AS discussed in Section 4.3.3. UEs gain access to the MCPTT service by communicating with the MCPTT server via the GC1 interface. This operation is referred to as MCPTT Network Mode Operation (MCPTT NMO). GC1 is based on the SIP for session control (establishment, release, etc.). Additional protocols may be used for centralized floor control or for UE configuration. The on-network operation also considers the case of UE being out of network coverage, but within the transmission range of another UE supporting ProSe UE-to-Network Relay capabilities (ProSe features are described in Section 4.4). In this case, PC5 is the functional architecture to support ProSe features between the UEs. On top of this, a GCbis interface is needed between the MCPTT client of the terminal out of coverage and an MCPTT proxy functionality inside the relaying UE. This operation is referred to as Network Mode Operation via Relay (MCPTT NMO-R). In the off-network scenario, an MCPTT DMO client is introduced. This client would run on top of the ProSe one-to-many communications service defined for PC5. It would have functionality for fully decentralized floor control. It may also support functionality for location, presence, group management and status reporting, as identified in the Stage 1 requirements. In this case, GC-dmo is the inter-UE application level interface connecting the MCPTT clients for DMO. At the time of writing, no version of the normative work TS 23.179 is still available.
3GPP MCPTT work aims at reusing existing, standardized functionality when possible and justified. Remarkably, the Push-to-Communicate for Public Safety (PCPS) specifications defined by OMA have several components that could provide partial support for the MCPTT standard. As previously noted in Section 4.1, OMA is currently working with 3GPP to find the best method for the effective transfer of this specification to 3GPP so that this can be leveraged and further continued within 3GPP to meet the requirements of the PPDR community and take the specification to its final point in MCPTT.
OMA develops service enablers and Application Programming Interfaces (APIs) in the areas of communications, content delivery, device management (DM) and location, among others. OMA service enablers and APIs are mostly network agnostic, meaning that they are designed to be deployable over any type of network layer. Through the OMA APIs, many fundamental capabilities such as SMS, MMS, location services, presence services, payment and other core network assets in current communications systems can be exposed in a standardized way to the service layer. One of the flagship specifications of OMA is DM, which is widely deployed in commercial handsets. OMA is complementary to and collaborates with standards bodies such as 3GPP.
In recent years, OMA has seen an increasing interest from governmental agencies in participating in the process of building service layer specifications for their communications systems [8]. In 2014, OMA introduced the Government Agency Participant option to allow these parties to be active in OMA (government agencies often cannot participate directly in organizations with foreign legal jurisdictions, strong confidentiality restrictions or IPR requirements). The FirstNet, UK Home Office, UK Met Office, County of Somerset New Jersey and China Academy of Telecommunication Research (CATR) of MIIT are some of the current participants.
Back in 2008, OMA released the first service enabler specifications for a PTT application, named as PoC. OMA PoC specifies a form of communications that allows users to engage in immediate communication with one or more users (‘walkie-talkie’-like) in the way that by pressing a button, a talk session with an individual user or a broadcast to a group of participants is initiated. OMA PoC version 2.1 (published as approved in 2011) allows audio (e.g. speech, music), video (without audio), still image, text (formatted and non-formatted) and file sharing with a single recipient (one to one) or among multiple recipients in a group (one to many). The OMA PoC solution has been commercially deployed by a few commercial operators (e.g. AT&T and Bell Canada, both launched the service in 2012). The PoC solution was mainly conceived as a service for consumers and developed to satisfy the functional and performance requirements arisen from the commercial domain, which are far less strict than those imposed by the public safety community [46]. Some details of this solution follow.
The OMA PoC solution builds upon the 3GPP IMS infrastructure and the IP connectivity service provided by the mobile network for the delivery of half-duplex, one-to-one or one-to-many voice services as well as video and data communications [47]. A simplified view of the OMA PoC solution architecture [48] is outlined in Figure 4.16. The central PoC functional entities are:
The above PoC functional entities that provide the PoC service use and interact with certain external entities such as a Presence Server that may provide availability information about PoC users to other PoC users or an XML Document Management Servers (XDMS) to manage groups and lists (e.g. contact and access lists). Discovery/Registry, Authentication/Authorization and Security are provided in cooperation with SIP/IP Core. OMA PoC solution makes use of the existing IETF protocol suite. The PoC sessions are managed using SIP and session signalling and bearer transport are performed through RTP/RTCP. On top of RTCP, PoC has defined its own extension – known as Talk Burst Control Protocol (TBCP) – for the purpose of speech channel management. From an IMS and PS Core domain perspective, a PoC session is seen as a classical IMS packet session, set up using SIP signalling through the S-CSCF that the subscriber is currently registered to. In order to support session data and signalling (including SIP and PoC signalling) transport, an EPS bearer over the core and access network is established, from the terminal to P-GW in the case of an EPC core network. OMA PoC also defines an interface to extend PoC services beyond the OMA-defined PoC service and PoC network boundaries, accomplished by interworking with other networks and systems, while not PoC compliant, being able to provide a reasonably comparable capability.
As a continuation of the OMA PoC solution, the PCPS project is consolidating OMA PoC v1.0, v2.0 and v2.1 requirements into a single PCPS v1.0 specification. This work has been done with the collaboration of public safety agencies. In essence, PCPS shares the basic PoC technology platform attributes, updated to operate on LTE networks. PCPS supports most of the MCPTT requirements though enhancements are needed. Of note is that PCPS version 1.0 does not consider support to exploit the new features added within the 3GPP layer with regard to GCSE and ProSe communications. An analysis of the major features missing from PCPS to fulfil the 3GPP MCPTT service requirements has reported the following items [49]:
Therefore, further work is necessary to advance the baseline OMA PCPS specifications and turn them into the expected 3GPP R13 MCPTT application. On this basis, as depicted in Figure 4.17, a continued augmentation of the resulting MCPTT core specifications is foreseen to progressively develop other applications that might be required for mission-critical communications (e.g. Mission-Critical Push-To-Multimedia) [8]. In addition to the PCPS specifications, other service enablers produced by OMA for location services, presence services, DM and others can be also considered in future versions of critical communications applications.
The capabilities for the devices to communicate directly among them when they are out of network reach (i.e. off-network communications) are central for PPDR users. Nowadays, device-to-device communications, commonly referred to as DMO, is an important means of communicating voice and narrowband data. DMO is now used in current narrowband systems (e.g. TETRA) in several ways [50]:
On this basis, the expectation is that the adoption of a radio interface based on LTE will continue supporting the abovementioned use cases not only for voice communications but also extended to multimedia services.
In addition to the interest from the PPDR community, the delivery of proximity-based applications and services also represent a recent and enormous trend in the commercial domain. The principle of these applications is to discover instances of the applications running in devices that are within proximity of each other and ultimately exchange application-related data. This enables new and enhanced existing apps/services such as social discovery/matching, push/proximate advertising, venue services, geo-fencing, credentialing, proximity-triggered automation, gaming integrating physical world elements and many others [51, 52]. Additionally, connecting devices directly when information is only of local interest (e.g. traffic safety applications, automation, etc.) instead of through the network can be beneficial to both the network operators and the users. In this case, local communications could turn into reduced latencies, higher throughputs, energy savings and improved resource utilization efficiency.
In this context, the 3GPP is seeking to seize the opportunity to become the platform of choice to exploit device-to-device communications and promote a vast array of future and more advanced proximity-based applications. The addition of built-in features for device-to-device communications to a global standard like LTE can readily turn into economies of scale advantages across both PPDR and non-PPDR services. Indeed, device-to-device communications is one of the main areas of focus in LTE Release 12, known in 3GPP terminology as Proximity-based Services (ProSe). ProSe features are aimed at (i) enabling the discovery of mobile devices in physical proximity to each other (i.e. ProSe Discovery) and (ii) enabling optimized communications between them, including the use of a direct communication path between UEs (i.e. ProSe Communication). The term ‘LTE Direct’ is also often used within the industry to refer to these 3GPP ProSe features.
To some extent, most of the abovementioned benefits intended to be provided by ProSe could also be pursued through the use of other prevalent device-to-device technologies such as Wi-Fi Direct and Bluetooth (Low Energy), complemented by pervasive OTT solutions for tracking the location of the device (e.g. GPS location). Some of the main reasons that justify the development of ProSe in front of these alternative technologies are the following:
The next subsection details how standardization work for ProSe is being addressed in 3GPP. After that, the fundamentals of this technology are summarized including requirements and related features for ProSe Discovery and ProSe Communications and describing the main ProSe features specifically introduced to address the PPDR needs.
The following WIs have been established within 3GPP to develop specifications for ProSe:
Table 4.5 lists the main 3GPP technical specifications and reports related to the above WIs.
Table 4.5 3GPP documents covering ProSe work.
Work Item (WI) | Related technical specifications/reports | Comments |
FS_ProSe | TR 22.803 – ‘Feasibility study for Proximity Services (ProSe)’ | Informative technical report developing use cases for ProSe. Completed under Release 12 |
ProSe (R12), eProSe (R13) and eProSe-Ext (R13) | (Modifications to existing TSs) TS 22.115 – ‘Service aspects; Charging and billing’ | Normative requirements added for ProSe (Stage 1 and Stage 2) |
TS 22.278 – ‘Service requirements for the Evolved Packet System (EPS)’ | ||
TS 23.401 – ‘General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access’ | ||
(New reports and specifications) TR 23.703 – ‘Study on Architecture Enhancements to Support Proximity Services (ProSe)’ | Informative technical reports and normative specifications (Stage 1 and Stage 2/3) for Prose | |
TS 23.303 – ‘Architecture Enhancements to Support Proximity Services (ProSe)’ | ||
TS 33.303 – ‘Security for Proximity-based Services (ProSe)’ | ||
FS_LTE_D2D_Prox | TR 36.843 – ‘Feasibility Study on LTE Device-to-Device Proximity Services – Radio Aspects’ | Feasibility study concerning radio access. Completed under Release 12 |
FS_ProSe_Sec | TR 33.833 – ‘Study on Security Issues to Support Proximity Services’ | Informative technical reports |
The initial feasibility study on Prose reported in TR 22.803 [59] identified requirements and services that could be provided by the 3GPP system based on UEs being in proximity to each other. These requirements are added to the rest of requirements established for EPS (mainly in 3GPP TS 22.115 [60] and 3GPP TS 22.278 [61]). The feasibility study to support the required architecture enhancements is reported in 3GPP TR 23.703 [62], while the normative Stage 2 specifications (functional architecture) of the ProSe features in EPS are provided in 3GPP TS 23.303 [63]. Security aspects of ProSe are covered in 33 series of 3GPP specifications. As well, specific aspects concerning lawful interception (LI) are addressed under the general LI activities in Release 12. A feasibility study was also addressed for ProSe features on radio aspects. In particular, the feasibility study evaluated LTE device-to-device proximity services in different scenarios (e.g. within/outside network coverage, PPDR-only or general requirements); defined an evaluation methodology and channel models for LTE device-to-device proximity services; identified physical layer options and enhancements to incorporate in LTE the ability for devices within network coverage; considered terminal and spectrum specific aspects, for example, battery impact and requirements deriving from direct device-to-device discovery and communication; evaluated, for non-public safety use cases, the gains obtained by LTE device-to-device direct discovery with respect to existing device-to-device mechanisms (e.g. Wi-Fi Direct, Bluetooth) and existing location techniques for proximal device discovery (e.g. in terms of power consumption and signalling overhead); and investigated the possible impacts on existing operator services (e.g. voice calls) and operator resources. In addition, for the purposes of developing public safety requirements, the study also addressed the additional enhancements and control mechanisms required to realize discovery and communication outside network coverage. Single and multi-operator scenarios including the spectrum sharing case where a carrier is shared by multiple operators were considered both for LTE FDD and LTE TDD operations. The feasibility study is reported in 3GPP TR 36.843 [64].
ProSe is organized around two constituent capabilities [61]:
A ProSe-enabled UE refers to an UE that fulfils ProSe requirements for ProSe Discovery and/or ProSe Communication. Similarly, a ProSe-enabled network is a network that supports any or both capabilities. These capabilities and configuration options are shown in Figure 4.18.
Except for the PPDR case, ProSe Discovery and Communication over the LTE radio interface are intended to be used within network coverage and under continuous operator network control. Furthermore, it is required that the operator includes means to apply regulatory requirements, including LI, as per regional regulation. This represents a full ‘operator-centric’ approach that is expected to allow mobile network operators to offer and monetize new services that may exploit ProSe capabilities. Indeed, the operator’s network and the ProSe-enabled UE provide mechanisms to identify, authenticate and authorize (third-party) application to use ProSe capability features. The operator’s network could store information of third-party applications necessary for performing security and charging functions. Indeed, the operator is able to charge for use of ProSe Discovery and/or Communication by an application.
For the PPDR specific usage, ProSe-enabled UEs can establish the communications path directly between two or more UEs, regardless of whether UEs are served by an LTE network (i.e. there is no need for the terminals to be under network coverage). To distinguish between UEs intended to be used in the commercial or the PPDR domain, the latter are explicitly referred to as ‘Public Safety ProSe-enabled UE’ along the 3GPP specifications. Other ProSe capabilities introduced specifically to be supported in Public Safety ProSe-enabled UE are:
The support of the two abovementioned relay functionalities is not included in Release 12 but expected to be completed within Release 13, together with other requirements for service continuity and QoS priority/pre-emption of ProSe Direct Communication sessions. Further details of the Discovery and Communication features are addressed in the following.
ProSe Discovery identifies that ProSe-enabled UEs are in proximity of each other, using E-UTRA (with or without E-UTRAN) or EPC when permission, authorization and proximity criteria are fulfilled. The proximity criteria can be configured by the operator.
The use of ProSe Discovery must be authorized by the operator, and the authorization can be on a ‘per-UE’ basis or a ‘per-UE per-application’ basis. An authorized application can interact with the ProSe Discovery feature to request the use of certain ProSe Discovery preferences.
The network controls the use of E-UTRAN resources used for ProSe Discovery for a ProSe-enabled UE served by E-UTRAN.
A plausible realization of the ProSe Direct Discovery capability is illustrated in Figure 4.19. It is based on the following premises:
ProSe Discovery can be used as a stand-alone process (i.e. it is not necessarily followed by ProSe Communication) or as an enabler for other services. The UE-to-UE interface for ProSe Direct Discovery (and also for ProSe Direct Communication) is denoted as sidelink and specified in 3GPP TS 36.300 [20].
ProSe Communication enables the establishment of new communications paths between two or more ProSe-enabled UEs that are in ProSe communications range. The ProSe Communication path could use E-UTRA or WLAN.
In the case of WLAN, only ProSe-assisted WLAN Direct Communication (i.e. when ProSe assists with connection establishment management and service continuity) is considered part of ProSe Communication. Indeed, direct control of the WLAN link is outside the scope of 3GPP. However, service requirements that enable the 3GPP EPC to provide network support for connection establishment, maintenance and service continuity for WLAN Direct Communication are currently addressed by the 3GPP solution.
In the case of E-UTRA, the network controls the radio resources associated with the E-UTRA ProSe Communication path. The use of ProSe Communication must be authorized by the operator. The operator shall be able to dynamically control the proximity criteria for ProSe Communication. Examples of the criteria include range, channel conditions and achievable QoS. According to the operator’s policy, a UE’s communications path can be switched between an EPC path and a ProSe Communication path, and a UE can also have concurrent EPC and ProSe Communication paths.
Two different modes for ProSe Direct Communication are supported:
Moreover, in the case of Public Safety ProSe-enabled UEs:
A summary of the possible configurations of ProSe Communication for PPDR and non-PPDR users is depicted in Figure 4.20:
It is assumed that ProSe Communication transmission/reception does not use full duplex on a given carrier. Moreover, from the individual UE’s perspective, on a given carrier, ProSe communication signal reception and cellular uplink transmission do not use full duplex either and TDM can be used. This includes a mechanism for handling/avoiding collisions. All data carrying physical channels is being assumed to use SC-FDMA for communication. In scenarios where a number of device-to-device communications links coexist, distributed link scheduling can help to improve resource utilization by enabling maximal spatial reuse depending on the interference environment. Priority mechanisms can also be in place so that a transmitter will not transmit if this action will result in degrading higher-priority scheduled links [52].
The functional architecture to support ProSe features in EPS is illustrated in Figure 4.21. The new functional elements and reference points introduced are:
Figure 4.22 illustrates the protocol stack used in the PC5 reference point between ProSe-enabled UEs, which is used for control and user plane for ProSe Direct Discovery, ProSe Direct Communication and ProSe UE-to-Network Relay. In the user plane, IP packets from upper layer applications are exchanged between the ProSe UE on top of the conventional PDCP/RLC/MAC/PHY layers enhanced with the sidelink features defined in TS 36.300 [20]. On the control plane, a new ‘ProSe Protocol’ has been defined to support the associated procedures for ProSe Service Authorization, ProSe Direct Discovery and ProSe EPC-level Discovery [65]. For further details on the functional architecture and related procedures, the reader is referred to 3GPP TS 23.303 [63].
Prioritization capabilities are essential elements of a mission-critical system at times of emergency and network congestion. Prioritization is the network’s ability to determine which connections have priority over others and to allocate network resources accordingly.
Whenever a user attempts to establish a connection in a cellular network, certain administrative actions take place. In addition to authentication, authorization and some other administrative procedures, the network shall also determine through an admission control function whether it has sufficient resources to accept a new connection or not. These resources include bandwidth, processing power and other operational elements within the system. Prioritization within a cellular network ensures that users of ‘high priority’ can establish connections with higher level of certainty relative to users of ‘low priority’. Hence, when multiple connection requests are being served, a network with prioritization capabilities will allocate resources to connections in an order dictated by the prioritization level. Prioritization capabilities may also include pre-emption of ongoing connections, so that the network could terminate or downgrade low-priority connections to free up resources and allocate a higher-priority connection. In addition to admission control, prioritization levels can also be taken into account by other resource management functions when handling network overload situations (e.g. load/congestion control mechanisms).
In general, priority levels for connections can be defined and assigned based on various criteria including user’s role (or user priority), user application types, incident type in case of emergency-triggered prioritization schemes, etc. As a matter of principle, for a given application type, connections initiated by users with higher user priority take priority over the connections initiated by users with lower user priority. However, such priority may not hold if the application types are different. For example, a priority scheme may choose not to provide a connection priority to a higher-priority user with video application rather than to a lower-priority user with voice application. The determination of connection priority levels and its mapping to user priority, application type and other attributes is a matter that hinges upon both the public safety needs and the technology supporting it. Prioritization schemes used in a network can also be set out to distinguish between home and roaming users. For a prioritization scheme to be effective, any network or system involved in the provision of the ‘end-to-end’ call or session has to be either aware of the prioritization scheme or dimensioned not to be the communications bottleneck.
In LTE networks, prioritization capabilities are closely connected to QoS control capabilities, both of them being essential attributes of a mission-critical system [66, 67]. Indeed, QoS control is the network’s ability to assign classes to different applications based on certain performance attributes and objectives and maintain the network performance for the application (e.g. packet loss, delay and throughput) within the acceptable range. On the other hand, prioritization capabilities are more related to the treatment received when establishing, modifying or releasing a connection. Therefore, during network congestion, a user with high priority shall be able to access his/her applications with no degradation in QoS, whereas a user with lower access priority may not be served or experience degraded QoS of his/her applications. It is worth noting that priority mechanisms should only act during those instances when the demand for bandwidth exceeds the available bandwidth. At all other times, priority mechanisms should not interfere with the transmission of information or access to network resources.
In networks used for PPDR applications, prioritization and QoS control can be exploited to discriminate:
Prioritization and QoS control management in LTE networks can be realized through three constituent features that were already introduced in the first release of the LTE specifications (Release 8) and improved over the subsequent releases (illustrated in Figure 4.23):
The way that LTE priority and QoS control capabilities can best serve PPDR needs shall be eventually determined by PPDR users. In this regard, organizations such as NPSTC have outlined requirements for these capabilities to be deployed in the nationwide PPDR LTE network in the United States [66].
The next subsections cover in more detail each of these constituent features for prioritization and QoS control in LTE. In addition, in a last subsection, the MPS is described. MPS is a service already specified by 3GPP that could be implemented on top of the previously discussed prioritization features.
Access priority is concerned with the initial access to the system. Access priority shall allow the network operator to prevent normal users from making connection attempts or reducing its frequency in specified cells, so that priority users’ connection attempts do not get blocked before being able to initiate the control procedures to set up a priority call/session.
3GPP networks in general and LTE in particular support two mechanisms that allow an operator to impose cell reservations or access restrictions:
Access control allows the network operator to prevent overload of the access channel under critical conditions, though it is not intended that access control be used under normal operating conditions [69]. In 3GPP networks, all UEs are members of 1 out of 10 randomly allocated mobile populations, defined as access classes (ACs) 0–9. In addition, UEs may be members of one or more out of five special categories (ACs 11–15):
AC 10 is also defined, but its use is only intended to control emergency calls (e.g. 911 in the United States, 112 in Europe) attempts. AC information is stored in the SIM/USIM of the UE and in the subscription profile within the network. Over-the-air modification of AC settings is supported.
The information about the permitted ACs is signalled over broadcast channels in the air interface on a cell-by-cell basis. If the UE is a member of at least one of the permitted classes and the AC is applicable in the Serving Network (SN), access attempts are allowed in that cell. Any number of these classes may be barred at any one time. ACs 0–9 are valid for use in both Home and Visited PLMNs, whereas ACs 12, 13 and 14 are only valid for use in networks of the home country4 and ACs 11 and 15 are only valid for use in the HPLMN or any Equivalent HPLMN (EHPLMN).5 For the establishment of the RRC connection, the ‘establishmentCause’ field of the RRC can be used to indicate ‘highPriorityAccess’ when ACs 11–15 are used [70].
Additional features that complement and/or extend the basic access control capabilities in E-UTRAN are the following [69]:
The access control information broadcasted in the air interface and the expected behaviour of UEs are specified in 3GPP TS 36.331 [70] and TS 22.011 [69]. In the case of multiple core networks sharing the same access network, the access network shall be able to apply ACB for the different core networks individually.
Using an administrative terminal or over-the-air configuration mechanisms, a PPDR operator should be able to assign a UE to one or more prioritized AC, which will determine the preferential initial access to the network. As well, the PPDR operator should be able to dynamically control which ACs are able to utilize the network in the event of congestion. It should be emphasized that once a UE has been admitted to the network and the UE remains active (i.e. RRC connected states) on the system, a change in the responder’s AC will not discontinue (pre-empt) the UE’s service. However, should the UE become idle, the UE will be required to once again pass the AC criteria. As well, because AC values (0–15) are stored in the UE’s USIM, the UE’s assigned AC(s) would be the same numerical value(s) regardless of the network that the UE is trying to get access to (e.g. dedicated network or commercial network(s)). Therefore, in the case of scenarios where the roaming of PPDR users to commercial networks is supported, as most ‘average’ commercial users will be assigned ACs 0–9, only having an AC between 0 and 9 should be avoided by critical PPDR UEs.
Admission decision is based on the ARP parameter (15 priority levels + pre-emption and pre-emptability flags). This is enforced by each eNB based on the ARP settings obtained from the core network for the activation of the default and dedicated EPS bearer services.
3GPP specifications [22] point out that the ARP priority levels 1–8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the SN). The ARP priority levels 9–15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming. This ensures that future releases may use ARP priority level 1–8 to indicate, for example, emergency and other priority services within an operator domain in a backward compatible manner. This does not prevent the use of ARP priority level 1–8 in roaming situation in case that appropriate roaming agreements exist that ensure a compatible use of these priority levels.
In the case of using a commercial network for the delivery of PPDR communications, the support of pre-emption is of special interest for PPDR practitioners. Pre-emption could be applied when there is contention for radio resources such that the resources requested by a PPDR user/application are not available. In that case, the network could pre-empt commercial users until sufficient resources become available to permit the PPDR responder to use his/her applications. In any case, the use of the pre-emption capability needs to be properly engineered. For instance, an active ‘911’ or ‘112’ session shall not be pre-empted. Moreover, pre-emption mechanisms should first attempt to free up resources by limiting the choices and QoS of the commercial users’ applications (e.g. throttling down the AMBR or GBR parameters of established EPS bearers) while not depriving these users from minimum connectivity (e.g. voice calls, SMS). A proposal for the mapping of commercial services and PPDR services onto the set of ARP values is provided in the work by R. Hallahan and J.M. Peha [71].
The allocation of ARPs has to be defined by the system administrator as part of the subscription profiles and/or PCC rules. An LTE network may support:
The following parameters are expected to be considered when defining priorities [66, 72]:
The work by R. Hallahan and J.M. Peha [71] provides some considerations on operational policies and arrangements to deploy PPDR priority access over public access cellular networks. Recently, the TIA in the United States, which develops standards for the information and communications technology industry, released the document TIA-4973.211 that describes requirements for a mission-critical priority and QoS control service for a wireless broadband network. It includes requirements to determine a user’s default priority on the broadband network and provides requirements for dynamic prioritization changes to meet situational needs. The requirements allow an operator to define consistent and deterministic policies to moderate usage of a shared wireless broadband network.
The treatment of the user plane (e.g. delay, packet loss, scheduler priority) is based on the QCI parameter, complemented with the GBR/MBR parameters for GBR bearers.
Like admission priority, data plane QoS configuration is typically assigned by an authorized administrator, and it is enforced on a per-eNB basis. As well, all the discussion around default/dynamic settings and the type of parameters considered when defining admission priorities is extensible to the configuration of the user plane.
With regard to QCI, as described in Section 4.2.2, standard QCI values can be suitable for PPDR applications insofar as they already consider some values that may be exploited in PPDR scenarios. Adopting the industry standard QCI definitions may be beneficial in terms of interoperability (e.g. PPDR scenario has the ability to roam for added coverage and capacity to commercial LTE systems). Should the need arise, LTE does allow custom QCIs to be created.
Complementary to QCI, GBR/MBR parameters for GBR bearers and AMBR for non-GBR bearers provide LTE with the rate limiting and bandwidth control capabilities over the amount of radio resources that are made available to a given user. Details on the different rate-related parameters are provided in Section 4.2.2. These parameters would allow, for example, limiting the maximum bit rate for general data services such as using Internet access. This would prevent a user from dominating non-GBR resources at an eNB. Standards/profiles could be created to consistently apply rate limits per UE across the entire network. In the presence of congestion, the network may further provide a guaranteed minimum bandwidth for a UE’s non-GBR traffic in order to prevent starvation.
When configuring a new streaming voice or video application for use, the minimum and maximum bandwidth needs of the application are usually well known (e.g. codec bandwidth needs). Real-time voice and video applications typically require dedicated resources. Therefore, user entities could have the ability to configure application minimum and maximum bandwidth needs when commissioning new applications for use on the network. In any case, real-time adjustment of network bandwidth controls is to be strongly avoided for both UEs and applications because of the high complexity involved [66].
MPS [73] is a service already standardized within 3GPP that is realized through the access control, admission priority and data plane QoS configuration features described in the previous sections.
MPS is intended to be utilized for voice, video and data bearer services in the packet-switched domain and the IMS of 3GPP networks. MPS complements another service called Priority Service [74], specified for establishing voice calls through the 3GPP CS domain.
An MPS user is an individual who has received a priority level assignment from a regional/national authority (i.e. an agency authorized to issue priority assignments) and has a subscription to a mobile network operator that supports the MPS feature (i.e. MPS subscription). Upon MPS invocation, the calling MPS user’s priority level is used to identify the priority to be used for the session being established. Both on-demand MPS invocation (i.e. priority treatment is explicitly requested by MPS user) and always-on MPS subscription (priority treatment is provided by default to all packet-switched sessions) are considered. Pre-emption of active sessions shall be subject to regional/national regulatory requirements. Also, subject to regional/national regulatory policy, a mobile network should have the capability to retain public access as a fundamental function. Therefore, MPS traffic volumes should be limited (e.g. not to exceed a regional/national specified percentage of any concentrated network resource, such as eNB capacity), so as not to compromise this function.
A feasibility study to support MPS over 3GPP networks was first addressed under Release 7 [75], and as a result, MPS Stage 1 requirements were developed within Release 8 in TS 22.153 [73]. Within Release 10, TR 23.854 [76] addressed some enhancements for MPS related to priority aspects of EPS packet bearer services and priority-related interworking between IMS and EPS packet bearer services. These enhancements enable the network to support end-to-end priority treatment for MPS call/session origination/termination, including the NAS and access-stratum (AS) signalling establishment procedures at originating/terminating network side as well as resource allocation in the core and radio networks for bearers. The basic MPS considering priority handling of IMS-based multimedia service, EPS bearer services and CSFB were completed in Release 10. In Release 11, SRVCC from LTE to UTRAN/GERAN/1xCS was also addressed based on Release 10 SRVCC specification [76].
As a result, MPS treatment can be applied to:
A high availability network shall implement features that provide increased robustness and alternate radio path establishment in the case of degraded network due to the failure of one or more infrastructure nodes or network connectivity. In many critical incident scenarios, the benefit of ensuring the ability to communicate between PPDR officers on the ground will be of utmost importance, even though they may be moving in and out of the LTE network coverage or following the loss of backhaul communications.
The support of the ProSe capabilities described in Section 4.4 are already central for ensuring a high availability of PPDR communications services as they can provide off-network operation in the case of complete network failure. However, even in the case of a major disaster, a likely situation is that the backhaul connectivity of a base station could be lost but the base station itself is still operational. In such cases, any features enabling the base station to act alone, isolated from the network, can be still of great support for increased resilience of PPDR communications in the affected area.
Both commercial and PPDR systems need to be able to survive network equipment failures and overload situations, though the requirements for public safety are more rigorous. In June 2013, 3GPP agreed to study how to enhance the resilience of LTE networks for public safety applications. In this context, 3GPP established the WI ‘Feasibility Study on Isolated E-UTRAN Operation for Public Safety (FS_IOPS)’ as part of Release 13 [77]. The WI FS_IOPS is intended to address a feasibility study to define use cases and identify potential requirements for isolated E-UTRAN operation in support of mission-critical network operations to be reported in 3GPP TR 22.897 [78]. Stage 1 specifications have been reported in Ref. [79], and a study on architecture enhancements to support these features has started (to be reported in 3GPP TR 23.797).
Two main scenarios, illustrated in Figure 4.24, can benefit for the addition of isolated E-UTRAN operation features:
In this context, isolated E-UTRAN can be created:
Isolated E-UTRAN can comprise:
The features to be developed for isolated E-UTRAN are closely linked to ProSe and GCSE features. As addressed in previous sections, ProSe and GCSE have defined requirements for public safety discovery and communications (including group communications) in the cases of no network coverage and of full (E-UTRAN and EPC) network coverage. Therefore, the need for discovery and group communications has to be considered in the case of isolated E-UTRAN. Isolated eNB(s) can bring benefits from exploiting locally routed communications for PPDR UEs such as the following:
Table 4.6 illustrates the features expected to be supported by the eNB in scenarios with different backhaul limitations.
Table 4.6 Isolated E-UTRAN scenarios [78].
IOPS scenario | Signalling backhaul status | User data backhaul status | Comment |
No backhaul | Absent | Absent | Fully isolated E-UTRAN operation using local routing of UE-to-UE data traffic and possible support for access to the public Internet via a local gateway |
Signalling-only backhaul | Limited | Absent | User data traffic offload at the E-UTRAN using local routing of UE-to-UE data traffic and possible support for access to the public Internet via a local gateway |
Limited backhaul | Limited | Limited | Selective user data traffic offload at the E-UTRAN using local routing of UE-to-UE data traffic and possible support for access to the public Internet via a local gateway |
Normal backhaul | Normal | Normal | Normal EPC-connected operation |
In coverage-limited deployments, the maximum transmit power of the device (i.e. uplink maximum transmit power) could be a bottleneck to achieve high data rates at long distances from the eNB. At the initial stage, LTE specifications only considered support for one UE power class (Class 3) with a maximum transmit power of 23 dBm for any of the supported operating bands. In Release 11, an additional power class (Class 1) was defined only for Band 14 devices, that is, the band allocated in the United States for PPDR. Therefore, LTE currently specifies the following UE power classes [18]:
The specification of Class 1 devices in a PPDR network would allow for a better coverage and availability/throughput performance than provided by commercial systems, particularly in rural areas. This can be eventually achieved by using higher-power UE(s) for vehicular mobile applications. An illustrative example of the coverage range increase that can be achieved by Class 1 in front of Class 3 devices is given in the following. Assuming the Hata rural path loss model [18], a carrier frequency of 790 MHz within Band 14 and an eNB antenna height of 45 m above the ground, the difference in maximum transmit power of 8 dB between Class 1 and Class 3 will result in the same increase of compensable propagation loss 8 dB, which in turn equates to around 70% increase in the cell radius and over 180% in cell coverage area.
The support of high-power class devices is mainly limited by the coexistence requirements with systems operating in adjacent bands. The approach followed in the specification of Class 1 for Band 14 was to maintain the same coexistence impact in terms of throughput/out-of-band emissions from the Band 14 Class 1 UE to base station receivers in Band 13 through tighter RF requirements for the high-power UE where applicable. These coexistence studies are reported in TR 36.837 [80].
3GPP specifications add support for RAN sharing among several core network operators. In this way, different core network operators are allowed to connect to a shared RAN. The operators do not only share the radio network elements but may also share the radio resources themselves (i.e. radio spectrum).
In the commercial domain, RAN sharing is perceived as a method for QoS improvement in congested areas, reduction of expenditures or coverage improvement. RAN sharing is expected to allow operators for a higher flexibility in pursuing different network deployment strategies [81, 82]:
In the PPDR domain, RAN sharing could be explored as a way to reduce the high upfront costs associated with the deployment of a stand-alone, dedicated PPDR network by partnering with commercial network operators to share the RAN equipment. Indeed, a majority of the upfront costs are related to establishing coverage, with approximately 70% of the capital expenditures (CAPEX) involving site acquisition, access equipment, civil works (i.e. construction of the site, installation of the equipment) and laying cables for electricity and backhaul.
The existing LTE 3GPP-compliant technology makes different RAN sharing options technologically possible today. These options are analysed in Chapter 6, while the description in this section centres on the technical features supported by LTE specifications as to the RAN sharing implementation.
The support for RAN sharing in 3GPP was already introduced under Release 6 for GERAN and UMTS, being later updated for LTE. The details of network sharing for GERAN, UTRAN and E-UTRAN have been defined in 3GPP TS 23.251 [82]. The arrangements for network sharing between the involved entities can vary widely, being influenced by a number of factors including business, technical, network deployment and regulatory conditions. Within all of this variation, there is a set of common roles centred on connecting network facilities between the parties participating in a network sharing agreement:
There are two identified architectures to be supported by network sharing (illustrated in Figure 4.25 for the case of an LTE network):
The UE behaviour in both of these configurations shall be the same. No information concerning the configuration of a shared network shall be indicated to the UE. At the end, network sharing is an agreement between operators and shall be transparent to the user. This implies that a supporting UE needs to be able to discriminate between core network operators available in a shared RAN and that these operators can be handled in the same way as operators in non-shared networks. To that end, each LTE cell in a shared RAN shall include information concerning the available core network operators in the broadcast system information so that LTE UEs can take that information into account in the network and cell (re)selection procedures.
The scenarios allowed from Release 6 specifications are rather limited and do not cover more complex scenarios that arise due to recent needs for more dynamic cooperation among operators. Importantly, current 3GPP RAN sharing specifications do not cover specific mechanisms to distribute radio access capacity between core network operators attending to some specific needs/conditions. In practical situations, such functionality is achieved based on inter-operator cooperation and requires substantial network reconfiguration effort.
Two main WIs have been established within 3GPP to improve the support for RAN sharing:
Table 4.7 lists the main 3GPP technical specifications and reports that are related to both WIs.
Table 4.7 3GPP documents covering RAN sharing enhancements.
Work Item (WI) | Related technical specifications/reports | Comments |
WI FS_RSE(Study on RAN Sharing Enhancements) | TR 22.852 – ‘Study on RAN Sharing Enhancements’ | Feasibility studies on use cases and potential requirements for a more dynamic cooperation among operators on RAN sharing have been analysed |
WI RSE(RAN Sharing Enhancements) | Change request to TS 22.101 – ‘Service aspects; Service Principles on requirements to support enhanced RAN sharing’ | Normative requirements document. TR 22.852 is the basis for normative work on RSE |
Regarding more advanced scenarios for RAN sharing, 3GPP TR 22.852 [85] provides a study on scenarios of multiple operators sharing radio network resources and creates potential requirements that complement the existing system capabilities for sharing common E-UTRAN resources. The scenarios illustrate:
As a result of the analysis of the new scenarios, means that complement the existing system capabilities for sharing common RAN resources are addressed in Release 13:
Though work on enhancements to RAN sharing in Release 13 initially focused on E-UTRAN, the work is going to be extended to GERAN and UMTS. The main motivation for this is that many operators already share RAN resources on GERAN and UTRAN, and it would be beneficial in terms of efficiency and costs to provide similar enhancements for sharing using those RATs also. Also, for GERAN especially, it is likely that some operators will come to a point where there will be a single (2G GSM) network to support legacy traffic from all the operators in a particular country/region. Therefore, it will be important to ensure that GERAN-based networks can be effectively shared with the aim of reducing costs. Virtualization techniques are gaining attraction as potential means to implement some of the abovementioned RAN sharing capabilities [86].