4.2.1 Radio Interface

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.

A central feature to highlight about LTE radio interface is its high degree of spectrum flexibility in terms of:

• Duplex arrangement. LTE can be deployed in both paired and unpaired spectrum. To that end, LTE supports both frequency- and time-division-based duplex (FDD and TDD) arrangements. Unlike previous technologies such as UMTS that also defined support for both duplexing modes, LTE enables both modes within a single RAT with minimum technological deviations, facilitating the manufacturing of equipment capable of supporting both FDD and TDD.
• Operating bands. LTE is able to operate in a wide range of frequency bands, from as low as 450 MHz band up to 3.8 GHz. The E-UTRA operating bands specified up to Release 12 are shown in Table 4.2 [18]. From a radio access functionality perspective, this has limited impact, and LTE physical layer specifications do not assume any specific band. What may differ, in terms of specification, are mainly more specific radio-frequency (RF) requirements such as the allowed maximum transmit power, requirements/limits on out-of-band emission, etc., due to potentially different external constraints coming from spectrum regulations.
• Channel arrangement. Various channel bandwidths are available in the LTE technology allowing for spectrum flexibility (1.4, 3, 5, 10, 15 and 20 MHz). Indeed, the LTE physical layer specifications are bandwidth agnostic and do not make any particular assumption on the supported transmission bandwidths beyond a minimum value. Hence, LTE specifications allow for transmission bandwidth ranging from around 1 MHz up to beyond 20 MHz in steps of 180 kHz (the size of the RB). Therefore, though RF requirements have been only specified so far for the previously mentioned set of transmission bandwidths, additional transmission bandwidths could be easily supported by updating only the RF specifications [13].
• Carrier Aggregation (CA). CA is a feature that was first introduced for LTE-Advanced in Release 10 where multiple Release 8 component carriers were allowed to be aggregated together intra-band and offer a means to increase both the peak data rate and throughput. In subsequent releases, inter-band CA was also specified, where the component carriers can be in different frequency bands. The number of CA schemes is growing from 3 in Release 10 to over 20 in Release 11, a clear indication of the great interest in developing this capability. Within Release 12, 3GPP is working on procedures for allowing UEs to aggregate both TDD and FDD spectrum jointly [19].

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.

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.

4.2.2 Service Model: PDN Connection and EPS Bearer Service

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.

4.2.3 PCC Subsystem

3GPP specifies the functionality for PCC with the following main functions [21]:

• Policy control, which comprises QoS control (i.e. selection of the QoS parameters for the EPS bearers) and gating control (i.e. the process of blocking or allowing packets, belonging to a service data flow/detected application’s traffic, to pass through the network)
• Flow-based charging for network usage, including charging control and online credit control, for service data flows and application traffic

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.

4.2.4 Security

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:

• Network access security (I) provides users with secure access to services and protects against attacks on the radio access interfaces.
• Network domain security (II) enables nodes to securely exchange signalling data and user data and protects against attacks on internal network interfaces.
• User domain security (III) provides secure access to terminals. This is typically implemented by using a PIN code for the user to get access to the network services. Of note is that LTE does not specify a new type of Subscriber Identity Module (SIM) card but leverages the one specified by UMTS and known as UMTS SIM.
• Application domain security (IV) enables applications in the user and service/application provider domains to securely exchange messages. Application level security traverses on top of the user plane transport provided by EPS and as such is transparent to the LTE network.
• Visibility and configurability of security (V) allow the user to learn whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature (e.g. use of a symbol on the terminal display that let the user know whether encryption is being applied or not).

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

4.2.4.1 Network Access Security

Access security in E-UTRAN consists of the following components:

• Mutual authentication between UE and network
• Key derivation to establish the keys for ciphering and integrity protection
• Ciphering, integrity and replay protection of NAS signalling (i.e. session management and mobility management signalling) between UE and MME
• Ciphering, integrity and replay protection of RRC signalling between UE and eNB
• Ciphering of the user plane between the UE and the eNB
• Use of temporary identities in order to avoid sending the permanent user identity (i.e. International Mobile Subscriber Identity (IMSI)) over the radio link

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:

• The keys generated within the home network’s HSS/AuC in EPS AKA are tied to a given SN by including a serving network identity (SN ID). This ensures that a key derived for one SN cannot be (mis)used in a different SN.
• Larger key sizes are possible. E-UTRAN supports not only 128-bit keys, but it is prepared to also use 256-bit keys.
• Additional protection is added against compromised base stations. The keys used in the air interface are updated/refreshed each time the UE changes its point of attachment or when transitioning from idle to active states.

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:

• User identity confidentiality: the property that the permanent user identity (IMSI) of a user to whom services are delivered cannot be eavesdropped on the radio access link
• User location confidentiality: the property that the presence or the arrival of a user in a certain area cannot be determined by eavesdropping on the radio access link
• User untraceability: the property that an intruder cannot deduce whether different services are delivered to the same user by eavesdropping on the radio access link

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

4.2.4.2 Network Domain Security

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:

• Data integrity
• Data origin authentication
• Anti-replay protection
• Confidentiality (optional)
• Limited protection against traffic flow analysis when confidentiality is applied

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.

4.2.5 Roaming Support

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]:

1. Home-routed roaming. In this architecture, the roamer’s traffic is routed back to the home network to enable the use of home resources. Therefore, the IP connectivity service is provided by the gateway functionality (i.e. P-GW) located in the home network.
2. Local breakout roaming. In this architecture, the IP connectivity service is provided by the P-GW located in the visited network. Local breakout architecture allows for AF serving the roaming user to be both on the visited operator network and the home network.

Both architectures are illustrated in Figure 4.11. The three relevant interfaces for roaming support in LTE networks are the following:

1. Interface S6a. This interface is used to exchange the data related to the location of the mobile station and to the management of the subscriber between the MME in the visited network and the HSS in the home network. The main service provided to the mobile subscriber is the capability to transfer packet data within the whole service area. The MME informs the HSS of the location of a mobile station managed by the latter. The HSS sends to the MME all the data needed to support the service to the mobile subscriber. Exchanges of data may occur when the mobile subscriber requires a particular service, when he/she wants to change some data attached to his/her subscription or when some parameters of the subscription are modified by administrative means. This interface is needed for both home-routed and local breakout roaming architectures.
2. Interface S8. This interface provides the user and control plane between the S-GW located in the visited network and the P-GW located in the home network. S8 is the inter-network variant of the S5 interface depicted in Figure 4.2. This interface is only needed for home-routed architecture.
3. Interface S9. This interface is needed to deploy the PCC functionalities described in Section 4.2.3 in roaming scenarios. It provides transfer of QoS PCC information between the Home PCRF (H-PCRF) and the Visited PCRF (V-PCRF) in order to support the local breakout function.

4.2.6 Voice Services over LTE

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:

• IMS basic capabilities and supplementary services for telephony
• Real-time media negotiation, transport and codecs
• LTE radio and EPC capabilities
• Functionality that is relevant across the protocol stack and subsystems

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.

4.3.1 Existing Initiatives and Solutions for PTT over LTE

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]:

1. A commercial carrier offers the service as a core feature on its network.
2. A company offers software or a smartphone application that provides PTT on a legacy network or a network that doesn’t offer it as a core service.
3. Vendor solutions for the dedicated deployment and operation of a specific user base.

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.

4.3.2 3GPP Standardization Work

The following Work Items (WIs) have been established within 3GPP to develop specifications for group communications and PTT application over LTE:

• ‘Group Communication System Enablers for LTE (GCSE_LTE)’ [37], initiated in Release 12
• ‘Service Requirements Maintenance for Group Communication System Enablers for LTE (SRM_GCSE_LTE)’ [38], initiated in Release 13
• ‘Mission Critical Push to Talk over LTE (MCPTT)’ [39], initiated in Release 13

Table 4.4 lists the main 3GPP technical specifications and reports related to the above WIs.

Note 1: Standards development in 3GPP progresses through three stages:

• ‘Stage 1’ refers to the service description from a service user’s point of view.
• ‘Stage 2’ is a logical analysis, devising an abstract architecture of functional elements and the information flows among them across reference points between functional entities.
• ‘Stage 3’ is the concrete implementation of the functionality and of the protocols appearing at physical interfaces between physical elements onto which the functional elements have been mapped.

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.

4.3.3 GCSE

The specification of the GCSE in 3GPP has been developed to meet the following main requirements [40]:

• Interoperability. Interfaces to the provided enablers shall be open so that group communications between users from different agencies in different territories using application layer clients provided by different manufacturers can interoperate. Furthermore, the network shall provide a third-party interface for group communication and a mechanism for a group member that is not connected via a 3GPP network to communicate in a group communication that it is a member of.
• Performance. The system should provide a mechanism to support a group communications end-to-end set-up time less than or equal to 300 ms. It is assumed that this value is for an uncontended network where there are no presence checking and no acknowledgements requested from receiver group member(s). The end-to-end set-up time is defined as the time elapsed since a group member initiates a group communications request on a UE until this group member can start sending voice or data information. The time elapsed since a UE requests to join an ongoing group communication until it receives the group communication should also be less than or equal to 300 ms. The end-to-end delay for media transport for group communications should be less than or equal to 150 ms.
• Priority and pre-emption. The system shall provide a mechanism to support a number of priority levels for group communication. The network operator shall be able to configure each group communications priority level with the ability to pre-empt lower-priority group communications and non-group communications traffic.
• Flexibility to accommodate the different operational requirements. The service should allow flexible modes of operation as the users and the environment they are operating in evolve. GCS is expected to support, voice, video or, more general, data communication. Also, GCSE should allow users to communicate to several groups at the same time in parallel (e.g. voice to one group, different streams of video or data to several other groups).
• Resource efficiency and scalability. The system shall provide a mechanism to efficiently distribute data for group communication. The number of receiver group members in any area may be very large (as an illustrative scenario, 3GPP TS 22.468 states that, based on real-life scenarios, at least 36 simultaneous voice group communications involving a total of at least 2000 participating users in an area with up to 500 users being able to participate in the same group could be expected). The system shall support multiple distinct group communications in parallel to any one UE. The mechanisms defined shall allow future extension of the number of distinct group communications supported in parallel.
• Interaction with proximity-based services (ProSe). If EPC and E-UTRAN support ProSe, the EPC and E-UTRAN shall be able to make use of ‘ProSe Group Communication’ and the public safety ‘ProSe UE-to-Network Relay’ for group communication, subject to operator policies and UE capabilities or settings. (More details on the ProSe features are given in Section 4.4.)
• High availability of group communication. The system shall be capable of achieving high levels of availability for group communications utilizing GCSE, for example, by seeking to avoid single points of failure in the GCSE architecture and/or by including recovery procedures from network failures.

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]:

1. The application layer, which holds the core functionalities of the group communications service. This functionality might be distributed between a GCS Application Server (GCS AS) on the network side and a GCS Client Application (GCS CA) running on the terminals. The application layer can be seen as the ‘user’ of the GCSE features. Application level interactions between the GCS CA and the GCS AS are out of scope of this GCSE specification.
2. The 3GPP EPS layer, which primarily provides the information delivery service between the application layer entities. This delivery service provided by the 3GPP EPS layer encompasses both unicast and multicast delivery. Therefore, besides the core entities (i.e. MME, S-GW, P-GW, HSS and PCRF) that are central to the provision of (unicast) EPS bearer services, the 3GPP EPS layer also includes the functions specified for Multimedia Broadcast Multicast Service (MBMS) [42]. MBMS is the solution developed within 3GPP to allow the same content to be sent to a large number of subscribers at the same time, resulting in a more efficient use of network resources than each user requesting the same content and having the content unicast to each user. This approach enables the application layer to use a mix of unicast EPS bearer services and MBMS bearer services to support the GCS.

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:

1. GC1. It is the reference point between the GCS CA in the UE and the GCSE AS on the network side. Through GC1, application domain signalling (e.g. for group admission and floor control, group management aspects such as group creation, deletion, modification, group membership control, etc.) is exchanged. This application signalling could be based on IMS-style signalling (e.g. SIP signalling supported in VoLTE services). Specification of this interface is left for Release 13 in the context of the MCPTT service.
2. MB2. It is the reference point between the GCS AS and the MBMS functions within the 3GPP EPS layer. MB2 offers access to the MBMS bearer service from a GCS AS. MB2 carries control plane signalling (MB2-C) and user plane (MB2-U) between GCS AS and BM-SC. The MB2 reference point provides the ability for the application to request the allocation/deallocation of a set of Temporary Mobile Group Identities (TMGIs)³ and to request to activate, deactivate and modify an MBMS bearer. As well, the MB2 reference point provides the ability for the BM-SC to notify the application of the status of an MBMS bearer to the GCS AS. The protocol stack and security requirements for MB2-C/U together with some additional parameters needed by the MBMS procedure as defined in 3GPP TS 23.246 [42] have been specified under Release 12.

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.

4.3.4 MCPTT over LTE

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:

• Support for one-to-many communication groups
• Dynamic group creation
• Monitoring of multiple PTT groups
• Authentication, authorization and security controls for PTT groups
• One-to-one private calls
• Announcement group calls
• Support of ruthless pre-emption
• Support of imminent peril and responder emergency calls including prioritization above normal PTT calls
• Identity and personality management
• Location information for PTT group members
• Support of off-network PTT communications and its operation together with on-network PTT at the same time

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.

4.3.5 OMA PCPS

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:

• PoC Server. A network element, which implements the IMS application level network functionality for the PoC service. It operates as an SIP Application Server from the IMS perspective that manages the PoC session set-up and tearing down procedures, talk burst control (i.e. floor control), and enforces policy defined for PoC group sessions.
• PoC Client. A functional entity that resides on the UE that supports the PoC service.
• PoC Box. A PoC functional entity where PoC session data and PoC session control data can be stored. It can be a network PoC Box or a UE PoC Box.
• PoC Crisis Event Handling Entity. A functional entity in the PoC network authorizing PoC users to initiate or join crisis PoC sessions. The PoC Crisis Event Handling Entity enforces the local policy for national security, public safety and private safety applications within a country or a subdivision of a country. The PoC Crisis Event Handling Entity complements the emergency service.

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]:

• Authorization to both UE and application (user); difference in actors
• Group hierarchy and group affiliation
• Personality management
• Location (could be supported by OMA LOC enabler)
• Off-network support
• Late call entry performance
• Ability to forward support of new security evolution
• Interworking with non-LTE MCPTT systems (P25, TIA-603, etc.)

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.

4.4.1 3GPP Standardization Work

The following WIs have been established within 3GPP to develop specifications for ProSe:

• ‘Study on Proximity-based Services (FS_ProSe)’ [53], initiated in Release 12
• ‘Proximity-based Services (ProSe)’ [54], initiated in Release 12
• ‘Feasibility Study on LTE Device-to-Device Proximity Services – Radio Aspects (FS_LTE_D2D_Prox)’ [55], initiated in Release 12
• ‘Enhancements to Proximity-based Services (eProSe)’ [56] and ‘Enhancements Enhancements to Proximity-based Services – Extensions (eProSe-Ext)’ [57], both initiated in Release 13
• ‘Study on Security for Proximity-based Services (FS_ProSe_Sec)’ [58], initiated in Release 12 and moved to Release 13

Table 4.5 lists the main 3GPP technical specifications and reports related to the above WIs.

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

4.4.2 ProSe Capabilities

ProSe is organized around two constituent capabilities [61]:

1. ProSe Discovery: a process that identifies that a ProSe-enabled UE is in the proximity of another using the LTE radio interface (with or without the infrastructure network) or using the EPC. The former is denoted as ProSe Direct Discovery. The latter is denoted as ProSe EPC-level Discovery.
2. ProSe Communication: a communication between two or more ProSe-enabled UEs in the proximity by means of a ProSe Communication path. This path could be established through the LTE radio interface either directly between the ProSe-enabled UEs or routed via local eNB(s) (i.e. ProSe E-UTRA Communication). The path could also be established over Wi-Fi Direct (i.e. ProSe-assisted WLAN Direct Communication). The case that the path is established directly between the devices is referred to as ProSe Direct Communication.

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:

• Support for ProSe Group Communication and ProSe Broadcast Communication among a number of Public Safety ProSe-enabled UEs (these features rely on the use of a common ProSe E-UTRA Communication path).
• Ability for a UE to function as ProSe UE-to-Network Relay between E-UTRAN and UEs not served by E-UTRAN. This capability allows an out-of-coverage area Public Safety ProSe-enabled UE to have access to network services and applications through another Public Safety ProSe-enabled UE that supports the ProSe UE-to-Network Relay function.
• Ability for a UE to function as ProSe UE-to-UE Relay between two other UEs that are out of direct communication with each other. This relay function allows communications between these Public Safety ProSe-enabled UEs without the communications media (e.g. voice, data) being transported via the infrastructure of the PPDR network.

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.

4.4.2.1 ProSe Discovery

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 operates in uplink spectrum (in the case of FDD) or uplink subframes of the cell providing coverage (in the case of TDD).
• ProSe Discovery resources are configured by the RAN. Resources are semi-statically allocated and their amount does not practically impact on the LTE capacity (e.g. capacity reduction can be <1%). The eNBs assign part of discovery resources via broadcast control signalling (i.e. System Information Blocks (SIBs)) to authorized ProSe Discovery devices.
• All UEs can use the allocated resources either to broadcast their needs/services or listen to others. To that end, UEs broadcast 64- or 128-bit service identifiers named Expressions for each service they offer. An expression is used by peers in the discovery of proximate services, apps and context. Expressions can also be used by proximate peers to establish direct communications. The operator or some other entity has to manage a database of expressions and services they represent; UEs transmit and receive expressions within the discovery resources.
• UEs in the proximity read ‘expressions’ to determine relevance. UEs wake up periodically and synchronously to discover all UEs within range.

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

4.4.2.2 ProSe Communication

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:

1. Network-independent direct communication. This mode of operation for ProSe Direct Communication does not require any network assistance to authorize the connection, and the communication is performed by using only functionality and information local to the UE. This mode is applicable only to pre-authorized Public Safety ProSe-enabled UEs, regardless of whether the UEs are served by E-UTRAN or not.
2. Network-authorized direct communication. This mode of operation for ProSe Direct Communication always requires network assistance and may also be applicable when only one UE is ‘served by E-UTRAN’ for PPDR UEs. For non-PPDR UEs, both UEs must be ‘served by E-UTRAN’. The direct connection set-up via network allows an operator to authorize and control the direct connection set-up between UEs and determine the user traffic routing between direct and network-based paths.

Moreover, in the case of Public Safety ProSe-enabled UEs:

• ProSe Communication can start without the use of ProSe Discovery if the Public Safety ProSe-enabled UEs are in ProSe communications range.
• Public Safety ProSe-enabled UEs must be able to establish the communications path directly between Public Safety ProSe-enabled UEs, regardless of whether the Public Safety ProSe-enabled UE is served by E-UTRAN, as well as being able to participate in ProSe Group Communication or ProSe Broadcast Communication between two or more Public Safety ProSe-enabled UEs which are in proximity. Any of the involved Public Safety ProSe-enabled UEs need to have authorization from the operator.
• ProSe Communication is also facilitated by the use of a ProSe UE-to-Network Relay, which acts as a relay between E-UTRAN and UEs not served by E-UTRAN. The use of this relay function is controlled by the operator.
• In addition, ProSe Communication can also take place over a ProSe UE-to-UE Relay, a form of relay in which a Public Safety ProSe-enabled UE acts as a ProSe E-UTRA Communication relay between two other 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:

• Direct configuration, under network coverage and control. Applicable to both PPDR and non-PPDR use cases. ProSe data plane is established directly between the communicating devices, while part of the control signalling is still performed through the involvement of the network.
• Locally routed configuration. Applicable to both PPDR and non-PPDR use cases. Neither data nor control plane is supported directly between devices, but data traffic is routed locally at the eNB, in contrast to the common case where data plane for each terminal is terminated at the P-GW of the LTE network.
• Off-network operation. Only applicable to PPDR. Public Safety ProSE-enabled UEs may communicate in case of absence of E-UTRAN coverage, subject to regional regulation and operator policy, and limited to specific public safety designated frequency bands and terminals.
• ProSe UE-to-Network Relay. Only applicable to PPDR. Under network control or off-network.
• ProSe UE-to-UE Relay. Only applicable to PPDR. Under network control or off-network.
• ProSe Group Communication (one to many) and ProSe Broadcast Communication (one to all). Only applicable to PPDR. Under network control or off-network. Communication is realized by means of a common ProSe E-UTRA Communication path established between the Public Safety ProSe-enabled UEs.

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

4.4.3 ProSe Functional Architecture

The functional architecture to support ProSe features in EPS is illustrated in Figure 4.21. The new functional elements and reference points introduced are:

• ProSe Application is the application in the UE side that uses the features provided by ProSe. A ProSe Application is given a globally unique identifier (application ID). The UE hosting the ProSe Application is required to support procedures for ProSe Direct Discovery of other ProSe-enabled UEs (over PC5 reference point) as well as procedures for the exchange of ProSe control information between ProSe-enabled UE and the ProSe Function over the user plane (over PC3 reference point). In the case of Public Safety ProSe-enabled UE, additional functions may be included to support procedures associated with one-to-many ProSe Direct Communication and UE-to-Network Relay. The configuration of parameters (e.g. including IP addresses, group security material, radio resource parameters) can be preconfigured in the UE or, if in coverage, provisioned by signalling (over the PC3 reference point).
• ProSe Application Server supports capabilities for storage and mapping of application and user identifiers. Specific application level signalling between the ProSe Application Server and the ProSe Application is done over PC1. The ProSe Application Server also interacts with the ProSe Function over the PC2 reference point.
• ProSe Function is the logical function that is used for network-related actions required for ProSe. It consists of three main sub-functions that perform different roles depending on the ProSe feature:
  1. Direct Provisioning Function is used to provision the UE with necessary parameters in order use ProSe Direct Discovery and Prose Direct Communication.
  2. Direct Discovery Name Management Function is used for open Prose Direct Discovery to allocate and process the mapping of ProSe Application IDs and other identifiers used in ProSe Direct Discovery. It uses ProSe-related subscriber data stored in HSS for authorization for each discovery request (retrieved over PC4 reference point). It also provides the UE with the necessary security material in order to protect discovery messages transmitted over the air.
  3. EPC-level Discovery ProSe Function that includes storage of ProSe-related subscriber data and/or retrieval of ProSe-related subscriber data from the HSS, storage of a list of applications that are authorized to use ProSe EPC-level Discovery and EPC-assisted WLAN direct discovery and communication, etc.

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

4.5.1 Access Priority

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:

1. The first mechanism uses an indication of cell status and special reservations for control of UE cell selection and reselection procedures. This mechanism allows the barring of a cell, so that users are not pexrmitted to camp on that cell. Cell reservation also considers a situation in which camping on the cell is only allowed for operator UEs [68].
2. The second mechanism, referred to as Access Class Barring (ACB), does not influence in selecting the cell to camp on, but the related cell access restrictions shall be checked by the UE when initiating any access attempt (i.e. RRC connection establishment procedure).

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):

• Class 15: Public land mobile network (PLMN) staff
• Class 14: Emergency services
• Class 13: Public utilities (e.g. water/gas suppliers)
• Class 12: Security services
• Class 11: For PLMN use

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 country⁴ and ACs 11 and 15 are only valid for use in the HPLMN or any Equivalent HPLMN (EHPLMN).⁵ 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]:

• Enhanced Access Control. Barring status is not limited to ‘barred/unbarred’. The SN broadcasts ‘barring rates’ (e.g. percentage value) and ‘mean durations of access control’ information parameters. These parameters are provided for different types of access attempts (i.e. mobile originating data or mobile originating signalling). With this information, the UE determines the barring status by drawing a uniform random number between 0 and 1. Access is allowed when the uniform random number is less than the current barring rate. Otherwise, the access attempt is not allowed, and further access attempts of the same type are then barred for a time period that is calculated based on the ‘mean duration of access control’.
• Service Specific Access Control (SSAC). SSAC allows E-UTRAN to apply independent access control for multimedia telephony services for mobile originating session requests (e.g. a ‘barring rate’ and ‘mean duration of access control’ are broadcasted for voice and video services).
• Access Control for Circuit-Switched Fallback (CSFB). Similar to SSAC, access control support for CSFB provides a mechanism to regulate the access to E-UTRAN to perform CSFB calls. It minimizes service availability degradation (i.e. radio resource shortage, congestion of fallback network) caused by mass simultaneous mobile originating requests for CSFB and increases the availability of the E-UTRAN resources for UEs accessing other services.
• Extended Access Barring (EAB). It is a mechanism to restrict network access for low-priority devices. Low-priority access configuration was introduced in Release 10 to aid with congestion and overload control in scenarios where a high number of devices can be connected to the eNB for delay-tolerant low-bit-rate data services (e.g. machine-to-machine (M2M) scenarios). A network operator can restrict network access for UE(s) configured for EAB in addition to the common access control and domain-specific access control when network is congested while permitting access from other UEs. The UE can be configured for EAB in the USIM or in the mobile equipment. EAB can be initiated when MMEs connected to eNB(s) request to restrict the load for UEs configured for low access priority or if requested by the network management system. When EAB is activated and UE is configured for EAB, it is not allowed to access the network. When the UE is accessing the network with a special AC (ACs 11–15) and that special AC is not barred, the UE can ignore EAB. Also, if it is initiating an emergency call and an emergency call is allowed in the cell, it can ignore EAB. During the work of 3GPP on System Improvements to Machine-Type Communication (SIMTC) Release 11, dual priority access was also introduced to allow for devices to hold dual-priority applications that will need ‘normal’ (default) priority access (e.g. in order to send infrequent service alerts/alarms) in addition to the ‘low-priority/delay-tolerant’ access (e.g. that will be used for the vast majority of their connection establishments). In addition to access restrictions, a ‘low access priority’ indicator is included in the signalling from the device to the RAN and to the core network. In the LTE and UMTS RAN specifications, the indicator is named ‘delay tolerant’.

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.

4.5.2 Admission Priority

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:

• Default admission priority settings. Default priority should be thought of as the day-to-day prioritization settings that the network will automatically use most of the time but special incidents or needs. Because congestion can occur at any moment, the default priority framework must be carefully designed to accommodate the widest range of responder activities. Default priority levels may be set in the user profiles.
• Dynamic admission priority settings. Dynamic priority refers to the ability of an authorized responder or administrator to override the default priority assigned automatically by the network and to be able to dynamically set or modify the priorities assigned to users. Typically, human intervention is required to trigger a dynamic priority change, such as pressing the UE’s emergency button. As well, users’ priorities may be assignable by the incident commander in real time (e.g. an incident commander should have the capabilities with support to influence network priority rather than having this responsibility fall to an overwhelmed public safety dispatcher or to the individual radio users). The user may be made aware of the default and incident-specific settings of his/her access priority via the UE human interface.

The following parameters are expected to be considered when defining priorities [66, 72]:

• Role of the user involved in the response to an incident in accordance with incident management systems or incident command systems
• User operational state (e.g. immediate peril, responder emergency, etc.)
• Location of the user (users that are too far from the incident or unable to intervene effectively should be assigned a lower priority)
• Application category (e.g. mission-critical/non-mission-critical categories)
• Application type (e.g. latency-sensitive real-time, video streaming, latency-tolerant M2M, client–server database queries, web browsing, etc.)

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.

4.5.3 Data Plane QoS Configuration

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

4.5.4 MPS

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:

• IMS-based multimedia services. An MPS session (e.g. a voice/video call with priority treatment) can be activated through the IP Multimedia Subsystem (IMS) platform. A session request shall include an MPS code/identifier followed by the destination address (e.g. SIP URI, Tel URI). Consistency of the priority indication and treatment between the IMS service layer and signalling and data bearers established through the mobile network is achieved through Policy Control and Charging functionality [21]. Thus, PCC functionality determines the QoS profile (i.e. ARP and QCI parameters) to be assigned to the corresponding bearer services. Besides user prioritization, service prioritization is also possible with this model.
• Priority EPS bearer services. The activation of MPS does not require the use of IMS. Hence, when IMS is not used, on-demand MPS can also be activated/deactivated via, for example, HTTPS server that would interact with the operator PCC infrastructure (the HTTPS server will act as an AF within the PCC model).
• Circuit-switched fallback (CSFB). This functionality is needed to allow the initiation or termination of CS services (e.g. voice service) from/to an UE while the UE is attached to an E-UTRAN that does not provide direct access to CS services. CSFB instructs the terminal to move to GERAN/UTRAN to handle the service. In this context, priority treatment for calls initiated/terminated using the CSFB functionality will also be permitted.