6.2.1 3GPP

The 3GPP RAN working groups have completed the study on scenarios and requirements for Next Generation (NG) access technologies [1] and the study on New Radio (NR) access technology [2]. The next stages for the technical specifications of 5G networks in 3GPP, including the Next Generation RAN (NG‐RAN), are underway. The overall descriptions of NR and the NG‐RAN are captured in [3].

Based on considerations of various 5G use cases and deployment scenarios, their associated requirements and key performance indicators (KPIs), a set of requirements for the NG‐RAN architecture and the migration of NG radio access technologies (RATs) has been established in 3GPP [1]. For example, the NG‐RAN architecture shall support tight interworking between NG‐RATs and (e)LTE, connectivity through multiple transmission points, flexible deployment and functional split options, network slicing and network function virtualization (NFV). It shall further support multi‐vendor interoperability with open interfaces between RAN and CN and within the RAN, and between logical nodes and functions of NR and (e)LTE, as detailed in Section 6.3.

In general, the agreement is that the 3GPP NG‐RAN consists of NR Gigabit Node‐Bs (gNBs), providing the user plane (UP) and control plane (CP) protocol terminations for the radio interfaces toward the user equipment (UE), denoted as the NG‐Uu interface. The gNBs may be interconnected with each other via an Xn interface. The gNBs are (ultimately) expected to be connected to the 5G CN, referred to as 5GC, via NG interfaces, more specifically to the Access and Mobility Management Function (AMF) via the NG‐C or N2 interface, and to the User Plane Functions (UPF) via the NG‐U or N3 interface [4]. For details on the AMF and UPF, see Section 5.3.2. Furthermore, the gNB may consist of a centralized unit (CU) and one or more distributed units (DUs) connected to the CU via Fs‐C and Fs‐U interfaces for CP and UP, respectively, with different function split options between CUs and DUs [5], as discussed in detail in Section 6.6. The high‐level architecture of the 3GPP NG‐RAN is depicted in Figure 6‐1. While the NG‐RAN depicts a pure NR deployment, practical deployments will often be based on a co‐existence of e(LTE) enhanced Node‐Bs (eNBs) and gNBs. For details on related (e)LTE/NR interworking scenarios, see Section 5.5.1.

6.2.2 5G PPP

In 5G PPP phases 1 and 2, several projects have been looking into, or are still occupied with the 5G RAN architecture design, for instance

• METIS‐II [6] has developed an overall 5G RAN design, focusing on the efficient integration of evolved legacy and novel AIVs, and the support of network slicing;
• 5G NORMA [7] has developed a novel, adaptive and future‐proof 5G mobile network architecture, with an emphasis on multi‐tenancy and multi‐service support;
• COHERENT [8] has developed a unified programmable control framework for coordination and flexible spectrum management in 5G heterogeneous access networks;
• mmMAGIC [9] has developed new RAN architecture concepts for millimeter‐wave (mmWave) radio access technology, including its integration with lower frequency bands;
• 5G‐MonArch [10] aims to expand existing architecture with key innovations related to inter‐slice control and cross‐domain management, and a cloud‐enabled protocol stack.

Furthermore, the 5G PPP Architecture Working Group facilitates the discussion among 5G PPP projects that are developing architectural concepts and components, and captures the consolidated findings across the projects in annually updated architecture White Papers [11].

6.4.1 Network Functions in a Multi‐Aiv and Multi‐Service Context

One key difference between 5G and earlier cellular technology generations is that a 5G system will consist of multiple highly integrated radio variants, often referred to as air interface variants (AIVs) [15]. An example for an AIV could be an (e)LTE radio, which could be tightly integrated into a 5G system, but there will likely also be multiple novel radio interfaces introduced in the 5G timeframe, for instance tailored towards different carrier frequencies or cell sizes, which could also be considered as individual AIVs. For instance, it is widely understood that propagation at frequencies beyond 40 GHz carrier frequency is so different from that, e.g., below 6 GHz that at least the physical layer (PHY) and Medium Access Control (MAC) design of related radio interfaces will look quite different, as detailed in Chapter 11.

Further, the 5G RAN is expected to support diverse service types, as pointed out in Chapter 2, which naturally suggests radio functionality that is tailored to different service needs. However, from the perspective of the overall 5G RAN design, one should clearly strive to have as much communality in the NFs and overall protocol stack design as possible, despite the notion of different AIVs and different services, for the sake of an efficient standard description and efficient implementation on device and infrastructure side. In this context, it is assumed that the following terms and notions will be relevant in 5G:

• AIV‐specific or service‐specific NFs are functions that are designed for or tailored towards a specific AIV or service, respectively. An example for an AIV‐specific NF would be a particular interference mitigation mechanism on MAC level that is designed to operate on a frame timing used for mmWave communications, and in the context of high beam directivity and link volatility;
• AIV‐agnostic or service‐agnostic NFs are functions that are agnostic to the protocol stack layers underneath, or to the services for which they are used. An example would be a Radio Link Control (RLC) level data segmentation function that could be applied regardless of the AIV or service;
• AIV‐overarching or service‐overarching NFs are functions that are specifically designed to integrate or aggregate multiple AIVs, or handle multiple services. An example could be a multi‐AIV traffic steering function that dynamically maps services to different AIVs depending on instantaneous radio characteristics and QoS targets. An example for such function is provided in Chapter 12.

The aforementioned notions of NFs are illustrated in Figure 6‐2. In this example, there are two AIVs (one using a carrier frequency below 6 GHz, one using mmWave frequency) and two services (eMBB and URLLC) involved. It is here assumed that a URLLC device is only served via the first AIV, while the eMBB device is served via multi‐connectivity between the two AIVs. Please note that for brevity only the UP is shown, and the protocol stack at the device side is skipped. In this example, there are MAC and PHY NFs tailored towards mmWave communications. Further, there are some MAC NFs tailored towards either URLLC or eMBB. However, the RLC implementation is assumed to be the same for all AIVs and services, hence agnostic towards these. Please note, though, that there are still individual instantiations of the RLC NFs for the different AIVs and services, as discussed further in Section 6.4.4. A multi‐service scheduler, as for instance detailed in Section 12.3, and multi‐AIV traffic steering functionality, see Section 12.4, are here given as examples of service‐ and AIV‐overarching NFs, as they are designed specifically to optimize operation across multiple services and AIVs, respectively. Please note that Figure 6‐2 serves for illustration purposes only; in practise, the usage and granularity of service‐ or AIV‐specific NFs may be very different and very implementation‐specific, as we will see in the following sections.

6.4.2 Possible Changes in the 5G Protocol Stack Compared to 4G

In this subsection, we explore the different protocol stack layers, list their current functions as in LTE‐A, summarize which changes 3GPP has already agreed upon for 5G, and elaborate on any further possible changes that may be introduced in 5G. Please note that the 3GPP status described here is to a large extent based on the NR UP related agreements captured in Annex A2 of [16] in March 2017. Further, we focus only on major decisions here for brevity.

6.4.2.3 Radio Link Control (RLC)

In LTE, the RLC layer can operate in acknowledged mode (AM), unacknowledged mode (UM), or transparent mode (TM), and is responsible for

• error correction through Automatic Repeat reQuest (ARQ);
• concatenation, segmentation and reassembly of RLC SDUs in order to generate RLC PDUs of appropriate size from the incoming RLC SDUs;
• re‐segmentation of RLC data PDUs, if these do not fit to the actual transport blocks; and
• reordering of RLC data PDUs, duplicate detection and RLC SDU discard, RLC re‐establishment, and protocol error detection.

For 5G, the main challenge or design goal w.r.t. RLC is to increase the processing efficiency, reduce overhead and duplicate functions, better segregate real‐time and non‐real‐time functions, and enable the support of lower layers with mixed numerologies. 3GPP has already agreed that

• multiple parallel logical channels can be configured with different characteristics and priorities, e.g., involving different numerologies and transmit time interval (TTI) lengths;
• gNBs should have means to control which logical channels the UE may map to which numerology and/or TTIs with variable duration; and
• concatenation of RLC PDUs is performed in the MAC layer instead of the RLC layer. This allows the precomputation of RLC and MAC headers for faster processing and higher data rates, and the parallelization of the PHY encoding and MAC PDU construction. Further, it allows ARQ to be fully decoupled from real‐time processing, and helps to avoid the duplication of concatenation‐like operations in RLC and MAC.

The latter point is illustrated in Figure 6‐3, where the left side shows the UP processing in LTE, i.e. where RLC PDU concatenation is performed in the RLC layer, and the right side shows the agreed 5G approach, including the introduced SDAP layer. It has been discussed to also move segmentation, and not only concatenation, from RLC to MAC layer, since also segmentation requires the knowledge on MAC transport block sizes and is hence tightly tied to MAC processing. If this would be moved to MAC ‐ while keeping individual queues per RLC entity to avoid head‐of‐line blocking ‐ all remaining functions of the RLC would be asynchronous to the radio. In this case, the interface between RLC and MAC would reflect the split between asynchronous and synchronous functions and could constitute a good CU/DU split, as elaborated in Section 6.6.2.

A further proposal for 5G is that the re‐segmentation of RLC PDUs could be extended to new scenarios, e.g. involving unlicensed spectrum, where transmission may be blocked by channel acquisition, and RLC PDUs would need to be re‐segmented to fit the next transmission opportunity.

6.4.3 Possible Service‐specific Protocol Stack Optimization in 5G

As indicated before, a key requirement of the 5G system is to efficiently handle services with very diverse requirements, in particular novel services involving stringent latency requirements. In this respect, the LTE protocol stack is suboptimal, as it constitutes a fixed set of functions applied almost equally to all UP data, except for some limited flexibility in terms of the different RLC modes mentioned in Section 6.4.2.3, and Robust Header Compression (RoHC) profiles. Further, the protocol stack involves some processing inefficiency due to repetitive header processing and reorganization of data, as visible in Figure 6‐3. This inefficiency is quantified in Table 6‐1, which shows the contribution of the different PDCP, RLC and MAC functions to the E2E latency for an example LTE implementation [19], and which for instance emphasizes the major latency contribution of the PDCP layer and repetitive header processing.

One consideration for 5G is hence to introduce a two‐layer approach [20][21], where PDCP, RLC and MAC functionalities are put into two groups for the avoidance of repetitive processing, and where the detailed functionalities are highly tailored towards or possibly even de‐activated or hard‐coded depending on specific service needs. For typical eMBB, URLLC and mMTC services, possible groupings and optimized functionalities are depicted in Figure 6‐4.

The two‐layer approach introduces a) a Lower Layer with traditional MAC and flexibly some RLC functions depending on service requirements, and b) an Upper Layer including the remainder of RLC and PDCP. With this two‐layer proposal, processing and latency gains can be achieved due to less header processing, single duplication detection and re‐ordering, and modular re‐transmission control, where two levels of re‐transmission are utilized instead of three (i.e., on MAC, RLC and PDCP level). Further, this architecture can better support multi‐connectivity and RAN splits into CUs and DUs, as detailed in Section 6.6.2, where the DUs could correspond to different AIVs. Let us shortly elaborate on the key benefits for individual service types that the proposed two‐layer RAN design and service‐specific cross‐layer optimizations could yield:

• eMBB services are expected to benefit strongly from the operation in higher frequencies and with larger bandwidths, which will require the usage of directional antennas to compensate for the high path attenuation, see Section 4.2.1. Directional antennas, however, may lead to challenges like single‐/multi‐channel directional hidden terminals, deafness, etc. Hence, the protocol design in particular for eMBB services could be optimized towards dynamic beam management, allowing for a directional MAC based on resource‐to‐beam allocation, beam sweeping and steering. Further, eMBB services with comparatively relaxed latency requirements can benefit from a high centralization of UP functions as well as coordinated multi‐point (CoMP) transmission, in order to obtain high spectral efficiency;
• For URLLC services, it is expected that multi‐connectivity and carrier aggregation will be important for ultra‐high reliability. With the proposed layering, the upper layer will be able to connect to multiple lower layer entities, thus potentially lowering the processing delays (taking also into account the re‐transmission processes). Further, due to the small and typically fixed size of the packets, functions like segmentation may not be required, fixed size Logical Channel Prioritization (LCP) may be used, and functions like RoHC and ciphering may be skipped, assuming that mission‐critical services will provide application‐level security mechanisms;
• For mMTC services, the high connection density and often low mobility suggests the usage of group‐based functionalities [21], and the deactivation of mobility‐related functions.

Figure 6‐5 shows the possible reduction of layer 2 processing latency through the means discussed before. The benchmark is the LTE eNB UP processing latency of approximately 1 ms [22]. We show results for example eMBB, mMTC and URLLC services, where we split the latter into low mobility (e.g., factory automation) or high mobility cases (e.g., vehicular communications). Clearly, latency depends strongly on factors like TTI size and implementation details, hence the numbers are mainly to be seen as indicative of the trend. For eMBB, we see a marginal benefit from the avoidance of redundant header processing in a two‐layer setup. For mMTC and low‐mobility URLLC, most PDCP and RLC functions are disabled, though an aggregation layer (on top of PDCP) for group‐based functionalities is assumed. URLLC shows higher latency, since it involves also packet re‐ordering and assembly functions that can be skipped in the case of mMTC. For high‐mobility URLLC, due to the expected frequent handovers and multi‐connectivity support, the upper layer includes ciphering. Also, both URLLC cases assume no multiplexing at MAC level.

6.4.4 NF Instantiation for Multi‐Service and Multi‐Tenancy Support

In the past sections, we have discussed how the 5G protocol stack and NFs could be tailored towards specific service needs. We will now go one step further and elaborate on how NFs could be instantiated in a multi‐service and multi‐tenancy environment, in particular when multiple services and tenants are expected to utilize one common multi‐service radio.

It is expected that a key to such multi‐service radio will be a decomposition of NFs into service‐specific and service‐agnostic components [24], as already introduced in Section 6.4.1. Figure 6‐6 shows an example of such decomposition in the case where a RAN supports four services eMBB, URLLC, mMTC and enhanced mobile broadband multimedia services (eMBMS). Note that the URLLC support is here explicitly split into a device‐to‐network (D2N) and device‐to‐device (D2D) part. It is further assumed in this example that all services share a common carrier and the same radio frequency (RF) circuitry, and also the same lower part of the PHY functionality, i.e. the same orthogonal frequency division multiplex (OFDM) numerology in terms of subcarrier spacing and symbol length, the same (inverse) fast Fourier transform (FFT), cyclic prefix insertion, etc. The higher part of the PHY could, however, be implemented in a service‐specific manner, allowing for service‐specific optimization. For example,

• eMBB may be optimized for maximum spectral efficiency, utilizing TTI durations and a demodulation reference symbol (DMRS) spacing adapted to the coherence time and bandwidth of the radio channel as well as multi‐cell and multi‐user capable advanced spatial multiplexing and receive processing concepts such as CoMP;
• URLLC may be optimized for lowest latency at the cost of spectral efficiency, utilizing very short TTIs and accordingly higher DMRS overhead and a radio resource management (RRM) able to pre‐empt other services, as detailed in Section 12.3.3;
• The D2D part of URLLC may convey control information only (e.g., based on semi‐persistent radio resource assignments) in a robust way;
• mMTC may be optimized for processing massive amounts of sporadic small packets, employing contention based access, open loop link adaptation and autonomous synchronization for maximum device energy efficiency in UL and size‐optimized and robust DL control to provide extended coverage;
• eMBMS may be adapted to realize a DL single‐frequency network (SFN), employing inter‐cell coordination, an extended cyclic prefix length and an optimized subcarrier spacing for both CP and UP.

On the other hand, a service‐agnostic RRC cell instance, as depicted on the left side of Figure 6‐6, is envisioned to provide signals for synchronization and channel measurement as well as initial access (i.e., system broadcast, contention‐based UL access and a basic DL channel) to the system, being simple and robust to be accessible by all UEs from low‐cost machine‐type to high performance broadband. In the particular example, it is also envisioned that an eMBMS‐specific RRC cell instance is provided, see the right side of Figure 6‐6, based on the SFN operation and the aforementioned OFDM parameters optimized for eMBMS.

User‐specific RRC functionality (i.e., related to the RRC state handling, handover, etc.) may either be commonly provided for all services, or also optimized for a specific service type. In the given example, user‐specific RRC functionality, denoted as “RRC user” functionality in the eMBB slice of the figure, is for instance assumed to be common to all services (except eMBMS) and to use eMBB for the transport of RRC messages.

The distinct upper PHY implementations per service also imply distinct PHY NF instances per each service. Accordingly, MAC, RLC and PDCP must also employ different NF instances per each service, though the same NF type and implementation may be used for each instance, e.g. with different sets of allowed options and parameter settings per service. When the system evolves over time and especially when new and not yet foreseen use cases emerge, a new NF type and corresponding implementation could be introduced for any service without impacting the others, thereby guaranteeing that the overall system design is future‐proof.

A key finding in [24], as also emphasized in Figure 6‐6, is that the handling of the CP will most likely be common to all tenants (as described above and based on a limited set of defined key service types), while the UP processing could be based on tenant‐specific NFs. Note that as for the CP, such tenant‐specific UP NFs could be based on the same NF type and implementation, and simply be parametrized to the needs of different tenants.

It is important to stress that multi‐tenancy support requires all RAN NF instances to be slice‐aware. In particular, common NF instances shared by multiple slices need to maintain the one‐to‐one mapping of traffic to individual slices, and there must be mechanisms for slice controllers to influence how traffic of their related slice should be processed in NF instances that are common across multiple slices. Through such mechanisms, both the separation of services and separation of tenants are enabled in both common and service‐ or tenant‐specific NFs, and network slicing effectively becomes end‐to‐end, spanning the whole path from data network (respectively end‐user service) to the UE.

6.5.1 5G/(e)LTE multi‐Connectivity

For multi‐connectivity between an evolved LTE and a novel 5G AIV, there has been an early consensus that this should be realized on RAN level and avoid explicit CN/RAN signaling, which is for instance required in the case of 3G/4G multi‐connectivity. Further, since the 5G PHY and MAC are agreed to be non‐backward compatible to LTE‐A for best possible 5G performance, 5G/(e)LTE multi‐connectivity on MAC layer appears rather challenging, and is hence currently not considered by 3GPP. Instead, 3GPP is envisioning to adopt key principles of the DC concept from LTE Rel. 12 [25] for 5G/(e)LTE multi‐connectivity, where the UP of LTE‐A and 5G are aggregated on PDCP level. The most likely option is to have a bearer split in the master node (MN), which can be either the (e) LTE eNB or 5G gNB, and which corresponds to the option 3c in LTE DC, as depicted in Figure 6‐7 (left) for the example that the (e)LTE eNB acts as the MN. In this particular example, the UP data is exchanged between MN and secondary node (SN) via the Xn or X2 interface. Please note that the figure leaves it open whether the MN is connected to a 4G or 5G CN, see Section 5.5.1, hence both related interface names are displayed.

It is further assumed for first 5G releases, as in LTE‐A, that only the MN has a control plane connection to the CN. This way, a common evolved CN/RAN interface for both LTE and 5G will be used [12][14], and no extra CN/RAN signaling is needed to add or remove a secondary node.

Let us now focus on how RRC signaling is handled in 5G/(e)LTE multi‐connectivity scenarios. For LTE DC, all RRC messages are transmitted via the MeNB. SeNB RRC messages are sent to the MeNB over the X2 interface, and the MeNB makes the final decision of whether to transmit the RRC message to the UE. This has the advantage that there is no need for coordination, since the MeNB always makes the final decision. The disadvantage is that there is no RRC diversity [26], and RRC messages from the SeNB take longer time since they are always routed via the MeNB.

For NR, the following changes have been agreed [26]:

• Master and secondary node have individual RRC instances, allowing for an independent evolution of both protocols, though a UE (still) has only one RRC state, as controlled by the MN;
• The SN can send RRC messages to the UE via the MN, as in LTE DC, but it can also send these directly to the UE, for the benefit of reduced signaling latency, as long as these do not require coordination with the MN;
• Mobility measurements (for instance 5G‐specific measurements) can be sent directly to the SN;
• RRC messages originating from the MN may utilize diversity, i.e., they may be duplicated and sent from both the MN and the SN. For RRC messages originating from the SN, however, diversity is not yet specified.

It is possible that in future NR releases the RRC signaling is further evolved, for instance toward schemes involving explicit coordination of the RRC instances in the MN and SN, as proposed in [17]. By the UE and measurements, which may increase the implementation complexity on the UE side.

6.5.2 5G/5G multi‐Connectivity

Among novel 5G AIVs, more multi‐connectivity options are thinkable than for 5G/(e)LTE integration, as the NFs for different novel 5G AIVs can be kept more similar also on lower layers, hence allowing to also perform bearer split and UP aggregation on lower layers. In addition to the option of aggregating the UP of different AIVs on PDCP level, as in the 5G/(e)LTE multi‐connectivity case described before, the following forms of 5G/5G multi‐connectivity are being discussed, as also depicted in Figure 6‐8:

• Bearer split on PDCP level, with a duplication of data packets towards the secondary gNB. The duplicated data can then be used to enhance diversity and hence reliability whenever required by a specific service type;
• Bearer split on RLC level, such that the secondary gNB only implements the lower parts of the RLC functionality, for instance the NFs that are time‐synchronous to the radio, while the higher parts of the RLC are centralized at the master gNB, allowing for a faster reaction of traffic steering mechanisms towards the radio legs;
• Aggregation on MAC level, like in LTE Rel. 10 carrier aggregation (CA). This provides the possibility of joint scheduling across the radio legs, and hence the fastest possible reaction to changing radio conditions. This level of aggregation, however, typically requires ideal BH between the AIVs, or these should be co‐located, and may be complicated in the context of different numerologies involved.

It appears that the benefit of aggregation on MAC level as compared to PDCP level may in fact be quite limited, at least in terms of throughput, if a low‐latency link between the master and secondary gNB is available and hence PDCP‐level traffic steering can also occur on a decently fast time scale. Hence, a bearer split and UP aggregation on PDCP or RLC level may also be a preferred option for 5G/5G multi‐connectivity, as it poses less requirements on the Xn interface between the gNBs and is easier to handle in the context of different air interface numerologies. Note, however, that this will still have to be investigated through detailed simulation studies.

6.5.3 5G/Wi‐Fi multi‐Connectivity

The integration of 5G and Wi‐Fi systems can be useful for increasing the user throughput and to offload traffic from the cellular network. This section considers the integration of Wi‐Fi and 5G on spectrum below 6 GHz and compares solutions involving a tighter or looser integration on RAN level. Note that there are also other options for integrating 3GPP and Wi‐Fi systems in general, such as Multi‐Path Transmission Control Protocol (MP‐TCP), but these are not considered in this section. Please also note that general options of integrating 5G with non‐3GPP access are covered in detail in Section 5.5.2.

Figure 6‐9 shows the different considered variants of 5G/Wi‐Fi integration, namely:

• Tight 5G/Wi‐Fi integration on either RLC or PDCP level. In these cases, the 3GPP eNB is the anchor for CP and UP and responsible for traffic steering between the two radios, implying that it has knowledge of the state of the two systems (e.g., the numbers of users and their radio conditions). For this tight level of integration, the Wi‐Fi access point (AP) should be connected with the 3GPP eNB via ideal BH or be co‐located with it. Note that both cases could work with or without bearer split. Though the bearer split option may be more complicated because of the need to schedule packets from a single stream to multiple RATs, it can provide higher user throughput, and since the two radios are anyway tightly coupled in this scenario, it is recommended to apply the bearer split (as illustrated in the figure). Note that both variants a) or b) require some adaptation of the RLC protocol on the Wi‐Fi side. A MAC layer split, i.e. some form of carrier aggregation, would not be feasible, because the Institute for Electrical and Electronics Engineers (IEEE) 802.11 MAC is substantially different from the 3GPP MAC;
• Loose 5G/Wi‐Fi integration above PDCP: In this case, higher layers decide whether to switch or split the radio bearer to transmit over 3GPP radio and/or Wi‐Fi, based on longer‐term averaged knowledge of the state of each system. There is no need for tight integration between 5G and Wi‐Fi nodes, and they do not need to be co‐located. This solution is similar to the current LTE Rel‐13 LTE/Wi‐Fi radio level integration using an IPsec tunnel (LWIP). In this scenario, there is an Internet Protocol Security (IPsec) tunnel between a Wi‐Fi termination node and a UE connected to Wi‐Fi, so the Wi‐Fi network does not even need to be aware of the ongoing aggregation with a 3GPP access. Because of the lack of tight coordination between technologies, the bearer split scenario is almost impossible to implement, and hence not recommended here.

In detailed simulation studies comparing the mentioned 5G/Wi‐Fi integration options [21], it is clearly visible that a tight integration benefits from an instantaneous resource allocation across the technologies, as opposed to routing data based on long‐term average information on the technologies. However, the price is of course higher implementation complexity, the need for ideal BH or co‐location of the radios, and an adaptation of the Wi‐Fi RLC, and ultimately the difficulty of developing a solution that is subject to decisions by individual standards bodies.

6.6.1 Control Plane/User Plane Split (Vertical Split)

A separation of CP and UP functions (aka vertical split) is for instance investigated in detail in [28] and motivated by the fact that [27]

• it enables the introduction of SDN principles also in the RAN [29][30];
• it allows for a separate optimization of the placement of CP and UP functionality, as detailed further in Section 6.6.3, and an independent scaling of CP and UP;
• in multi‐vendor networks, a standardized interface to the CP enables a consistent control over network entities and NFs from different vendors, e.g. in terms of interference management for ultra‐dense networks [20];
• due to the tight coupling of CP and UP functions in today’s networks, the replacement or upgrade of a CP function often requires also the replacement of UP functions. Designing the CP and UP functions such that they are inherently less coupled and better separable might offer significant cost savings.

However, there are also major disadvantages of a CP/UP split that have to be considered:

• Standardization is required in case the interfaces between CP and UP have to be extended to introduce new features, which might slow down their introduction. Integrating additional interfaces in a proprietary manner in combination with standardized ones is not a suitable solution, as it would compromise the main benefit of a CP/UP split;
• Additional effort in terms of testing is required to guaranty the interoperability of CP and UP functions from different sources, shifting the effort from single vendors to system integrators supporting mobile network operators;
• As mentioned before, CP and UP functions are often tightly coupled, especially in the lower protocol stack layers. In particular, MAC schedulers need tight interaction with the UP since they determine the UL/DL resource usage, coding schemes, antenna mappings, precoding schemes, rank and modulation schemes to be applied by the UP. In the case of analog beamforming, e.g. for massive multiple‐input multiple‐output (MIMO), it is also typically assumed that the MAC scheduler selects the phase shifts or beams to be applied. All the listed interactions would require ideal BH connectivity between UP and CP.

Especially for the latter reason, a complete CP/UP split across all protocol stack layers is rather questionable. However, the following two options are possible:

• Separated RRC: In this case, the RRC for possibly multiple cells is handled separately, while for the complete remaining protocol stack the CP and UP are kept together. This case is very straightforward, as the related signaling between CP and UP would essentially resemble that on the X2 interface in the case of LTE Rel. 12 DC [25];
• Separated asynchronous CP functionality: In this case, all asynchronous CP functionality would be separated from asynchronous UP functionality, but all synchronous CP functionality requiring tight coordination with the UP would be kept together with the UP. In fact, this approach, as earlier considered in, e.g.,[21], has now been agreed in 3GPP, and the involved CP‐UP interface is now specified as E1 interface [31].

6.6.2 Split into Centralized and Decentralized Units (Horizontal Split)

An architecture that allows a flexible split of RAN functions into CUs and DUs (aka horizontal split) is motivated by the possibility

• to obtain centralization gains, here referring to both performance gains from common multi‐cell and/or multi‐AIV processing, such as centralized resource management or even multi‐cell joint signal processing, and gains in terms of economy of scale;
• to shift functions to different locations based on use case requirements. For instance, for latency‐critical communications, it may be required to place the full protocol stack and the application closer to the edge, while for delay‐tolerant applications, certain functionalities could by centralized in the cloud; and
• to adapt RAN processing to different deployments with possibly different infrastructure characteristics, such as available local processing power, different degrees of BH and FH infrastructure etc.

Various horizontal split options have been discussed, and are partially still under discussion in 3GPP and other bodies such as CPRI [32] and xRAN (see www.xRAN.org). The main options, using 3GPP terminology, are depicted in Figure 6‐11. An overview on options 1‐8 can be found under [5], while the variants of split option 7 have been detailed in the work item “Study on CU‐DU lower layer split for New Radio” [33]. Note that there is still controversy on whether such lower layer split options should be fully standardized (i.e., “stage 3 specification”), or whether a functional level description (i.e., “stage 2 specification”) is sufficient.

As indicated at the bottom of Figure 6‐11, the main characteristics of the split options are the requirements posed on the related interfaces in terms of data rate and latency. Function splits that are far away from the radio, i.e. shown on the left side of the figure, have the most relaxed latency and data rate requirements, but offer the least centralization gains. For brevity, we here only shortly elaborate on the most prominent options. Regarding possible higher‐layer splits,

• Option 1 (RRC/PDCP split) equals the split used in LTE Rel. 12 DC option 1a [25];
• Option 2 (PDCP/RLC split) corresponds to the split used for the UP in LTE Rel. 12 DC option 3c [25]. It has been chosen by 3GPP for NR Rel. 15 and is denoted as F1 interface [34]. While it may be inferior to option 3, it has the practical benefit of already being utilized in legacy systems;
• Option 3 (intra‐RLC split) is based on a split of the RLC functionality such that the entire RLC is located in the CU, in particular all ARQ‐related functionality, except for the aggregation functionality which is located in the DU. This way, the CU/DU split corresponds to the split between asynchronous (or non‐real‐time) and synchronous (real‐time) functionality, see also Section 6.4.2.3. This option is superior to option 2 in that it offers a larger extent of centralization and pooling gains and possibly enables better flow control, though the ARQ process is more prone to interface latency;
• Option 5 (intra‐MAC split) is in fact not pursued intensively in 3GPP, but is considered by the Small Cell Forum (SCF), as detailed in Section 6.7. In this case, high‐level scheduling decisions, for instance related to inter‐cell interference coordination (ICIC) or CoMP, would be performed in the CU, while time‐critical MAC processing, for instance related to HARQ, would reside in the DU;
• Option 6 (MAC/PHY split), also not in the main focus of 3GPP but considered by the SCF, foresees the complete MAC to be handled in the CU, with distributed PHY implementations in the DUs. Obviously, this would require sub‐frame‐level timing interactions between CU and DU, and FH delay would affect HARQ timing and scheduling.

A large debate has taken place in 3GPP w.r.t. split options within the PHY, where the classical Common Public Radio Interface (CPRI), based on an exchange of time‐domain in‐phase and quadrature phase (IQ) samples, is particularly problematic in the context of massive MIMO and mmWave communications, as interface bandwidth requirements scale with the number of antenna ports and system bandwidth. The main considered options are:

• Option 7‐1, where the i(FFT) and cyclic prefix insertion/removal are performed at the DU, and IQ samples in frequency domain are exchanged over the interface. Compared to option 8 (CPRI) this offers the benefit that only the samples related to occupied sub‐carriers need to be exchanged, instead of time domain samples reflecting the whole system bandwidth. Also, less quantization bits per symbol may be needed when quantizing in frequency domain. In the UL, some PRACH processing may also be performed at the DU;
• Options 7‐2 and 7‐2a have the additional benefit that pre‐coding and digital beamforming, or parts thereof, are performed at the DU, such that the FH interface requirements scale with the number of MIMO layers, and not with the number of antenna ports as in the case of options 7‐1 and 8. Options 7‐2 and 7‐2a differ in the extent of precoding happening at the CU or DU, or the location where channel estimation is performed in the uplink etc.;
• Option 7‐3, considered only for the DL, further reduces bandwidth requirements on the interface, as coded user data is exchanged before modulation. As a downside, such split would likely strongly increase the complexity of the DU.

Note that RAN splits need not be the same for UL and DL, e.g., there are also considerations to use options 7‐2 or 7‐2a for the UL, and option 7‐3 in the DL. Further note that beside the activities in 3GPP, a group of network vendors have also specified an enhanced CPRI (eCPRI) standard [32], which essentially includes all the 3GPP split options 7‐x described above.

To obtain a rough feeling for the requirements associated with different UP split options, Figure 6‐12 shows the interface data rate requirements for an example scenario with a system bandwidth of 400 MHz, 64 transmit antennas, 4 spatial layers, and 64 quadrature amplitude modulation (QAM) with code rate 3. For the methodology to compute the data rate needs, and all used parameters, the reader is referred to [15] and [18], respectively. For this large number of antenna ports and large system bandwidth, 3GPP split option 8 (CPRI) would require more than 1 Tbps of FH data rate. With option 7‐1, this can already be reduced to about 600 Gbps, due to the possible lower bit resolution when quantizing IQ samples in frequency domain, and the fact that only occupied subcarriers have to be considered. With options 7‐2 or 7‐2a, the interface data rate can be further reduced to about 38 Gbps, since the quantization now happens before digital beamforming and the mapping of streams to transmit antennas. Option 7‐3 again reduces the interface data rate by about a factor of 4, as now coded data bits are relayed instead of quantized IQ samples, though at the price of higher DU complexity. The higher split options, such as options 2 and 3, further reduce the data rate needs due to the forwarding of uncoded user data, and the avoidance of sending HARQ retransmissions over the FH, but the effect is rather minor.

The latency requirements on the interface in general become tighter the further down in the protocol stack the split is, though one can roughly classify two levels of latency requirements: For 3GPP split options 1‐3, where all RAN functionality that has to operate synchronously to the radio (i.e., in real‐time) is located below the split, the interface latency requirements are rather relaxed, while they are much more stringent for the other options where the RAN split cuts in between synchronous functionalities.

In consequence, even though 3GPP refers to the intra‐RAN interfaces resulting from all mentioned split options as fronthaul (FH), the higher‐layer split options 1‐3 are in fact much more similar in terms of interface data rate and latency requirements to classical backhaul (BH) than classical FH (which in legacy systems is typically associated to lower‐layer splits such as CPRI). This topic is further elaborated in the context of transport network architecture in Chapter 7.

6.6.3 Most Relevant Overall Split Constellations

In principle, many combinations of vertical and horizontal splits are thinkable, and capable to fulfil 5G requirements, but only a subset appear practically relevant. To crystallize key options, network functions in both CP and UP can be grouped into the following blocks of which logical network entities in 5G would most likely be composed:

CP Functions:

• CP‐H: Asynchronous functionalities such as ICIC, RRC functionality, etc;
• CP‐L: Synchronous functionality such as cell configuration, MAC scheduling and PHY layer control.

UP Functions:

• UP‐H: QoS/slice enforcement, PDCP (possibly also the asynchronous parts of RLC);
• UP‐M: Remainder of RLC and MAC and higher PHY layer, at least covering (de‐)coding, (de‐)scrambling, etc. (depending on the exact horizontal split, see Section 6.6.2);
• UP‐L: Remainder of the PHY, at least covering (i)FFT, cyclic prefix insertion, etc.

Figure 6‐13 depicts the likely most relevant overall split constellations. Constellation a) corresponds to a classical standalone BS where the complete RAN functionality is located in distributed points, also referred to as distributed RAN (D‐RAN).

Constellation b) represents a large extent of centralization, in particular of all CP functions. The difference to a classical centralized RAN (C‐RAN) is that the lower part of the UP PHY is located at the DU, corresponding to any of the split options 7 introduced in Section 6.6.2, and strongly reducing the data rate requirements on the FH interface. Finally, constellation c) shows a higher layer split, where only the asynchronous (i.e., non‐real‐time) part of the UP and the less time‐critical parts of the CP functions are centralized. This constellation could be based on horizontal split options 2 (split between PDCP and RLC) or 3 (split within RLC). All time‐critical functionalities, including for instance the MAC scheduler, are here located at the DU, which allows to relax the timing requirements on the interfaces to the CU, such that these can also be based on non‐ideal BH or possible wireless self‐xhauling links (see Chapter 7). Since in this constellation the CU contains only asynchronous (i.e., non‐real‐time) functionalities, the CP and UP therein can be nicely split, allowing to exploit the benefits listed in Section 6.6.1.

3GPP has agreed to a particular embodiment of constellation c) for NR Rel. 15, where the RRC and PDCP functionalities are centralized, and RLC, MAC and PHY are decentralized, with the F1 interface in between [34], and possibly with a further split of the higher‐layer functionality into CP (F1‐C) and UP (F1‐U), involving the mentioned E1 interface [31].

Clearly, further split constellations are thinkable, such as combinations of b) and c) with three levels of CUs or DUs, as further discussed in Section 6.7.1. Further, if a higher‐layer CP and UP split is involved in case c), it is of course also possible to move either the higher‐layer CP functionality to the DU (e.g., to optimize CP latency, while exploiting maximum pooling gains for the UP functionality), or move the higher‐layer UP functionality to the DU (e.g., for centralized and hence better CP coordination of multiple DUs, while having latency‐optimized decentralized UP processing) [31].

Regardless of whether option b) or c) is chosen, it is possible to integrate mobile or multi‐access edge computing (MEC) infrastructure [29] into the CU to serve latency‐critical applications. The CU approach also has a big advantage with respect to mobility handling. If a UE is moving within the range of antenna sites belonging to a single CU, mobility is handled CU‐internally only, for instance through fast UP switching [20] resulting in low handover interruption time because of low latency between involved components and the avoidance of RAN/CN signaling. This is especially beneficial for ultra‐dense deployments (using, e.g., mmWave bands), where the number of mobility events is typically high.

Note that independent of the split options and resulting logical entities depicted in Figure 6‐13, the physical location of RAN functions may be dynamically optimized based on service requirements. For instance, the CP in the CU may be placed close to the DU or even co‐located with this for the support of URLLC services. On the other hand, the UP in the CU may be centralized in a regional data centre for efficient cloud implementation and the support of multi‐connectivity and other interworking scenarios, see also Section 6.7.1.

In general, it does not make sense to cover huge areas via a single CU, but one will rather implement several CUs each controlling the radio processing for a certain number of antenna sites [18][28]. Typically, the NFs running in the CU are implemented as virtual network functions (VNFs) on server platforms based on NFV principles [35]. Suitable locations for CUs are, e.g., the central offices of fixed or integrated network operators [11].

The split of CU and DU leads to a hierarchical architecture for 5G systems [36], also allowing for hierarchical RRM concepts. The central RRM located at the CU is then able to coordinate the lower layer functions across multiple DUs, for mobility, interference and load coordination among DUs. The local RRM located at the DUs will handle the fast changing and detailed parameters at low layers, for instance, for scheduling and power control at the resource block (RB) level. In other words, the central RRM will handle the high‐level, less time‐sensitive information and more coordination‐oriented network functions for the interaction of multiple DUs. The general central RRM functions for high‐level coordination include, as summarized in [37]:

• Call admission, to allow necessary resources coordinated and reserved in DUs;
• Cell selection, to select the best serving DU according to UE and service requirements;
• Load balancing between cells, for a trade‐off between cell utilization and performance;
• Mobility, to improve mobility performance by centralized coordination;
• Multi‐connectivity, to select serving cells and transmission mode of cells.

5G RRM architectures and particular RRM concepts are elaborated further in Chapter 12.

6.7.1 Possible Physical Architectures Supporting the Deployment Scenarios

Figure 6‐16 illustrates an evolved 3‐tier RAN architecture that could support the different deployment scenarios and functional splits as considered by 3GPP, NGFI, and SCF and introduced before. Note that this architecture (with RRU, DU and CU) is an evolution of the original two‐tier C‐RAN (with RRU and baseband unit, BBU), which provides the required flexibility for future multi‐RAT deployments. Typically, a CU would cover a large area corresponding to a radius of 100‐200 kilometres, whereas a DU would cover a radius of only 10 to 20 kilometres.

The exact functional splits in the 3‐tier architecture are of course highly dependent on the transport network capabilities, as elaborated in Chapter 7. When using an ideal FH network (i.e., with low latency and high capacity), only the lower part of the PHY functions (L1‐Low) should be placed at the RRU to maximally exploit the benefit of coordinated signal processing at the DU. DAS and Massive MIMO are two typical deployment scenarios enabled with 3GPP split options 7 and 8 and (e)CPRI/NGFI radio‐over‐Ethernet (RoE) transport protocols or proprietary interfaces as implemented in OpenAirInterface [40]. Both require a common transmission precoding and reception combining operation (cell‐specific and UE‐specific) that must be placed either at the DU to enable the coordinated beamforming across several geographically distributed RRUs, or at a single RRU driving a massive antenna array. For a non‐ideal FH network (i.e., with medium latency and capacity as in a public network), the entire PHY functions are moved to the RRU to relax the FH network and yet exploit the benefit of joint scheduling and interference coordination at DU. Indoor‐outdoor RAN sharing and virtual cell mobility are two representative deployment scenarios that can be enabled with the SCF nFAPI interface or a proprietary interface corresponding to 3GPP split option 5, see Section 6.6.2. In addition, the separation of CP and UP among macro and small cell can be easily realized to seamlessly serve UP traffic via the centralized PDCP entity located either at DU or CU.

6.7.2 5G/(e)LTE and 5G Multi‐AIV Co‐Deployment

During the introduction of 5G, mobile network operators (MNOs) will of course aim to maximally leverage the existing (e)LTE deployments, and also need to serve legacy UEs that may be in the field for years. Hence, it is important to consider optimized co‐deployments of (e)LTE and 5G. The main envisioned non‐standalone deployments are (see also Chapter 5):

• Lean on LTE (corresponding to 3GPP options 3/3a/3x or 7/7a/7x[5]): A deployment where (e)LTE provides the basic communication layer, typically on a lower carrier frequency, acts as MeNB and provides the Primary Cell (PCell) in multi‐connectivity constellations (see Section 6.5.1). In addition, one or more NR Secondary Cells (SCells) can be configured, typically on higher carrier frequencies;
• Lean on NR (corresponding to 3GPP options 4/4a[5]): A deployment where the NR RAT is acting as the MeNB and is providing at least the PCell (e.g., on a carrier frequency F1), and in addition an eLTE SCell is configured (e.g., on a carrier frequency F2) where both F1 and F2 are from a lower frequency band.

More details on 5G/(e)LTE tight interworking with regard to different AIVs are provided in Section 2.3 of [21]. Note that the different options listed above can work with most of the function split and physical architecture considerations described in Sections 6.6.2 and 6.7.1.

Regarding the co‐deployment of multiple 5G AIVs, one strongly investigated constellation is the tight integration of mmWave AIVs with lower‐frequency 5G AIVs, in order to combat the challenging propagation conditions and volatile radio links associated with higher carrier frequencies [41], as described in Chapter 4. Here, the lower‐ and higher‐frequency AIVs would ideally share the same DUs according to Figure 6‐16, such that, e.g., joint or strongly coordinated MAC scheduling across the AIVs could be performed, see also Section 6.5.2. In this case, any sudden drop of link quality on the mmWave carrier(s) could be compensated by scheduling resources to the same UE on the lower frequency AIV, to still provide a decent quality of experience (QoE). It has to be noted, though, that for most eMBB use cases with higher throughput but often comparatively relaxed latency requirements, it may also be sufficient to use DC‐type multi‐connectivity between a lower and higher‐frequency 5G AIV (see also Section 6.5.2) and react to outages in the mmWave carrier(s) through PDCP‐level flow control.

In general, a joint design and tight integration of lower‐ and higher‐frequency 5G AIVs [41] may provide benefits going strongly beyond those of mere multi‐connectivity, such as the option to utilize lower‐frequency channel measurements, interference fingerprints, etc., for the decision on the fast activation and deactivation of higher‐frequency AIVs. Similarly, information available on the lower frequency layer could be used to setup and dynamically update the most suitable RAN function split and CU/DU hierarchy for a given area and instantaneous UE presence (i.e., determining the best possible set of DUs that should be covered by one CU to enable fast and efficient mobility among mmWave cells for the present UEs). Finally, such lower‐frequency information could be used for improved beam management and mobility among high‐frequency access nodes (e.g., to determine good initial mmWave beams already before a UE is actually served by mmWave, or to determine suitable mmWave cells and related beams for handover). One has to note, though, that many of the mentioned techniques may be implemented via proprietary means, and need not necessarily be standardized.