Patrick Marsch1, Navid Nikaein2, Mark Doll3, Tao Chen4 and Emmanouil Pateromichelakis5
1 Nokia, Poland (now Deutsche Bahn, Germany)
2 EURECOM, France
3 Nokia Bell Labs, Germany
4 VTT, Finland
5 Huawei German Research Center, Germany
With contributions from Nico Bayer, Jakob Belschner, Salah Eddine Elayoubi, Jens Gebert, Caner Kilinc, Tomasz Mach, Vinh Van Phan, Mikko Saily, Amit Sharma and Gerd Zimmermann.
After having ventured into the 5th generation (5G) end‐to‐end (E2E) system architecture in Chapter 5, we will now focus on the radio access network (RAN) architecture, i.e. covering all aspects of a 5G system in the so‐called access stratum (AS). Key points we will explore here are:
Clearly, all the points above are currently also being addressed in the 3rd Generation Partnership Project (3GPP), and by the time this book appears, many design decisions will have been taken. In this chapter, in addition to providing a brief overview of the latest 5G RAN architecture progress and related decisions in 3GPP, we hence focus on explaining 5G RAN architecture considerations from a broader perspective. For instance, we explain in detail the rationale for possible changes in the 5G RAN architecture as opposed to legacy systems, compare the pros and cons related to different architecture options, and also discuss concepts that have been proposed but not (or not yet) endorsed by 3GPP.
Please note that most parts of this chapter assume a split between core network (CN) and RAN as agreed in 3GPP and described in Section 5.3.2, though the majority of the presented concepts are independent of the exact split. For further information on possible alternative split options or a tighter coupling of CN and RAN, please also see Section 5.3.2.
The chapter is structured as follows. Section 6.2 shortly summarizes the related work on the 5G RAN architecture in 3GPP and the 5G Public Private Partnership (5G PPP). Section 6.3 then lists the 5G RAN architecture requirements, as identified in 3GPP and 5G PPP. Section 6.4 dives into details of the 5G RAN protocol stack architecture and related NFs, elaborating on the notion of NFs in the context of different air interface variants (AIVs), possible service‐specific protocol stack optimizations, and NF instantiations in the context of multi‐service and multi‐tenancy. Section 6.5 then ventures into the 5G RAN support of multi‐connectivity, either among multiple 5G radio legs, 5G and Long Term Evolution (LTE) or enhanced LTE (eLTE), or 5G and Wi‐Fi. Section 6.6 goes in detail into vertical and horizontal split options in the 5G RAN, which are seen as essential to support diverse deployment scenarios, as covered in Section 6.7. Section 6.8 finally delves into aspects of RAN programmability, before the chapter is summarized in Section 6.9.
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.
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
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].
Chapter 2 has provided an insight into the likely use cases that should be covered by 5G in the longer term, and in particular stressed the very diverse requirements associated to enhanced mobile broadband (eMBB), ultra‐reliable low‐latency communications (URLLC) and massive machine‐type communications (mMTC) use cases. From these requirements as such, and from the need to enable the joint support of diverse use cases in an economically feasible way, the following RAN architecture requirements have been captured on high‐level in [1] and formulated in more detail in [12]. Note that for brevity we here focus only on novel requirements specific to 5G:
Also, the following requirements have been identified, which are related explicitly to connectivity options and deployment:
We now investigate which implications the beforementioned RAN architecture requirements may have on the 5G protocol stack architecture and the NFs described by this.
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:
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.
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.
3GPP has agreed to introduce the Service Data Adaptation Protocol (SDAP) [3] as a new protocol layer in NR that has the role to provide the mapping between a QoS flow and a data radio bearer, and mark the QoS flow ID in uplink (UL) and downlink (DL) packets, as described in Section 5.3.3. Typically, a single protocol entity of SDAP is configured for each individual protocol data unit (PDU) session, except for dual connectivity (DC), where two entities can be configured.
In LTE, the Packet Data Convergence Protocol (PDCP) layer is responsible for
For 5G, the main challenge or design goal w.r.t. PDCP lies in the reduction of duplicate functions across layers, the reduction of overhead, the decoupling of the processing related to multiple layers, and the support of enhanced reliability. Recently, 3GPP has already agreed that
In general, it is considered that PDCP processing in 5G may be service‐tailored, as discussed also in Section 6.4.3. For instance, header compression may be omitted if the payload is large and/or latency is crucial (e.g., for eMBB or URLLC applications), while being more pronounced for mMTC. Also, it is expected that further refinements of the PDCP and RLC handling may be beneficial in the context of multi‐connectivity. For example, if retransmissions are handled in both PDCP (related to handover) and RLC (related to ARQ), and one PDCP entity is related to multiple RLC entities reflecting different radio legs, there should be means for the coordination of the re‐transmissions in the different protocol entities.
In LTE, the RLC layer can operate in acknowledged mode (AM), unacknowledged mode (UM), or transparent mode (TM), and is responsible for
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
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.
In LTE, the MAC is responsible for
In 5G, key challenges are to enable MAC operation based on PHY instances with different numerology, the explicit support of beam‐based communication, e.g. for mmWave bands, and the capability to meet and handle diverse QoS requirements, which will likely require a larger extent of coordination of multiple MAC entities, for instance in different cells. 3GPP has already agreed that
The following further considerations have been discussed: To support better service differentiation, the MAC should be able to map an UL grant to one or more logical channels with a different MAC configuration (e.g., different HARQ settings for eMBB and URLLC), instead of treating different services in the same way. Further, to enable service prioritization already during initial access, it has been proposed to introduce priority‐level‐specific physical RACH (PRACH) preambles that enable to increase the success probability of the initial access of high‐priority services, without sacrificing the initial access of other services [17]. Note that there are also various considerations to further improve HARQ in 5G, for instance based on dynamic soft buffers, enabling to adapt HARQ behaviour to packet lengths and the extent of soft buffer available at the device side, or novel HARQ feedback concepts [18].
It is also considered for 5G to have a better and service‐ or AIV‐specific cross‐optimization of protocol stack layers. One example would be optimized ARQ and HARQ constellations, where for URLLC use cases more emphasis may be put on obtaining reliability through (improved) HARQ, while ARQ is skipped as it introduces too much latency, whereas for eMBB use cases the HARQ could be simplified, as reliability could be more efficiently gained through ARQ. Such cross‐layer optimizations are also the subject of the following section.
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.
Table 6‐1. Latency contributions of protocol stack layers in LTE [19].
Sub‐layer | Function | Overall latencycontribution |
PDCP | RoHC | 20.0% |
De‐ciphering | 59.2% | |
Header processing | 7.8% | |
RLC | Reassembly | 8.6% |
Re‐ordering | 0.4% | |
Header processing | 1.0% | |
MAC | De‐mux | 0.8% |
Header processing | 2.2% |
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:
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.
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,
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.
As stressed in Section 6.3, an essential feature of the 5G system shall be the native support of multi‐connectivity between different radio legs, either related to different AIVs (i.e., different frequency bands, different RATs, etc., see Section 6.4.1) or different cells serving the same AIV. The benefits are increased throughput and/or improved reliability, for instance for 5G mmWave deployments that are subject to volatile propagation conditions, or for mission‐critical use cases. We now hence elaborate on the architectural means to enable multi‐connectivity, in particular on the protocol stack layers that are most suitable for the UP aggregation of different AIVs, and the way of integrating the CP functions of the involved AIVs.
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]:
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.
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:
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.
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:
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.
A likely key difference in the 5G RAN architecture to that of legacy systems will be the native support of various function splits along two dimensions: A split of CP and UP related NFs, and a split between functions which are closer to the radio, and hence tightly related to radio timing, and those that are rather asynchronous to the radio, into DUs and CUs, respectively. This is illustrated in a simplified form in Figure 6‐10.
This is a paradigm shift from having few, clearly defined logical network entities as in 4G (which are in practice typically reflected in the same set of physical entities), to an architecture that allows for a more flexible mapping of NFs to physical network entities depending on deployment constraints, use case needs, etc. Taking this to the extreme, 5G has been stated to resemble a “network of functions” rather than a “network of entities” [24].
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]
However, there are also major disadvantages of a CP/UP split that have to be considered:
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:
An architecture that allows a flexible split of RAN functions into CUs and DUs (aka horizontal split) is motivated by the possibility
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,
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:
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.
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:
UP Functions:
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]:
5G RRM architectures and particular RRM concepts are elaborated further in Chapter 12.
Different deployment scenarios have been considered by different bodies, namely 3GPP, the Small Cell Forum (SCF), the Next Generation Fronthaul Interface (NGFI) forum, and NGMN, among others. 3GPP defines four main deployment scenarios as follows [5]:
SCF adopts sharing approaches beyond multi‐operator core networks (MOCNs) and mobile operator radio access networks (MORANs) by opening the internal RAN interface that allows for NFs to be shared and hence vendor specific RAN intellectual property (IPr) to be hosted in a common or separate network function virtualization infrastructure (NFVI). This new form of sharing targets multi‐operator and multi‐vendor deployments in an indoor small cell infrastructure enabled by the Network Functional Application Programming Interface (nFAPI) [38], see also Figure 6‐15. In particular, the nFAPI interface allows to map operator‐specific and (possibly) operator‐shared functionality effectively to CUs and DUs, respectively. The specified nFAPI functional split corresponds to 3GPP split option 6, i.e. a MAC/PHY split as explained in Section 6.6.2, and aims to lower barriers w.r.t. shared access, in particular the multi‐operator sharing of physical network functions (PNFs) and virtual network functions (VNFs) [39].
NGFI adopts a three‐tier RAN architecture with a radio cloud centre (RCC) as CU entity, a radio aggregation unit (RAU) as DU entity, and remote radio units (RRUs) as further distributed entities. Three splits are considered, namely 3GPP split option 7 (intra‐PHY split) with two flavours (iFFT and cyclic prefix insertion and removal with and without mapper and dedicated PRACH handling), and 3GPP split option 2 (PDCP/RLC split), see Section 6.6.2. The considered deployment scenarios are dense indoor coverage, massive MIMO, and outdoor distributed antenna systems (DAS).
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.
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):
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.
While the RAN is the most complex part of the mobile network infrastructure, it offers many opportunities to benefit from SDN principles. One reason is that strategies and technologies being adopted to improve spectral efficiency, and to scale system capacity, such as cell densification, multi‐RAT, or the usage of advanced PHY techniques like CoMP, require a high level of coordination among BSs, which SDN can naturally enable since control decisions can be made and coordinated at a centralized SDN controller. As another reason, softwarization of the RAN CP not only allows for an easier evolution through programmability, but also enables a multi‐service architecture supporting a wide range of use cases and novel services. One of the main design challenges of a software‐defined RAN (SD‐RAN) are RRM functionalities and the stringent timing constraints associated with some key RAN control operations, such as flexible functional splits, beamforming, and MAC scheduling.
A possible high‐level SD‐RAN architecture is shown in Figure 6‐17 and realized through FlexRAN [42], a flexible and programmable platform for SD‐RAN. The CP follows a hierarchical design and is composed of three entities as described below:
The CP/UP separation is provided by a RAN agent application programming interface (API) which acts as the southbound API following SDN principles (e.g., based on OpenFlow), with the CP protocol on one side and RAN UP on the other side. The agent abstracts the RAN‐specific drivers through these APIs, and is composed of a set of control modules that interact with each layer of the protocol stack. The relationship between agent and RAN depends on the physical BS deployment and the applied functional split. For instance, in case of a legacy 3GPP Rel. 10 standalone BS, only one agent is required, whereas in case of a three‐tier 3GPP RAN architecture, as discussed in Section 6.7.1, three agents are required. Depending on the deployment scenario, the agent‐controller topology could vary from tree to mesh, and the edge entity could become part of the centralized entity. The control application can operate either on the edge entity, centralized entity, or both.
On top of the edge and centralized controller, a northbound API (labelled NB‐IF) is provided, which allows RAN control applications to change the state of RAN infrastructure (BSs and UEs) based on the statistics and events gathered from the CP with the desired level of granularity. Such applications could vary from simple monitoring applications to more advanced applications that program the state and composition of the RAN (e.g., functional split and MAC scheduler).
All the access stratum protocols of LTE (RRC, PDCP, RLC, MAC) can be decomposed into two parts; the control logic that makes the decisions for the radio link and the control action that is responsible for applying those decisions. For example, the control logic of the MAC makes scheduling decisions (resource block allocation and modulation and coding scheme), while the action logic applies them to user logical channels. Similarly, part of the logic of the RRC protocol decides on UE handovers, while the actual handover operation requires RRC to perform the corresponding action. Based on this taxonomy, the separation of the RAN CP from the UP, as discussed in Section 6.6.1, can be taken a step further by also detaching the control logic from the action and consolidating all the control operations in a logically centralized controller, which in the proposed architecture is comprised of centralized and edge controllers and agents interacting via the control protocol. This allows BSs to focus on performing all the UP related action functions, such as applying scheduling decisions, performing handovers, applying DRX commands, (de)activating component carriers in carrier aggregation, etc.
To control and manage the BS UP actions, the RAN Agent API is introduced to provide a set of functions that constitute the southbound APIs. These functions allow the CP to interact with the UP in five ways, namely
These API calls can be invoked either by the centralized or edge controller through the control protocol or directly from the agent if control for some operation has been delegated to it. Table 6‐2. provides a list of some exemplary RAN‐specific API calls. Note that the Agent is in charge of retrieving the cell‐ and user‐related information from the underlying eNB such as cell bandwidth, user reference signal receive power (RSRP) and reference signal receive quality (RSRQ) through the API calls, and can trigger events when a state changes, e.g. involving user attachment and TTI information (frame and subframe)1. In addition, such API calls may be related to the NFs, resources, UEs, etc., belonging to a particular slice [43]. It can be seen that different types of network applications can be developed ranging from monitoring for a better decision making (e.g., adaptive video optimization) to control and programmability for a better adaptability and flexibility to services (e.g., by controling resource allocation, adjusting the handover logic, changing functional splits, updating precoding matrices, or even disabling/enabling ciphering/deciphering, etc.).
Table 6‐2. RAN‐specific API calls [42].
API | Target | Direction | Example | Applications |
Configuration (synchronous) | eNB, UE, Slice | Centralized/Edge → Agent | UL/DL cell bandwidth, reconfigure Data Radio Bearer (DRB), Measurements, | Monitoring, Reconfiguration, Self Organizing Networks (SON) |
Statistic, Measurement, Metering (asynchronous) | List of eNB, UE, Slice | Agent → Centralized/Edge | Channel Quality Indicator (CQI) measurements, SINR measurements, Reference Signal Receive Power (RSRP)/Reference Signal Receive Quality (RSRQ)/ UL/DL performance | Monitoring, Optimization, SON |
Commands (synchronous) | Agent | Centralized/Edge → Agent | Scheduling decisions, Admission control Handover (HO) initiation | Realtime Control, SON |
Event trigger | Master | Agent → Centralized/Edge | TTI, UE attach/detach, Scheduling request, Slice created/destroyed | Monitoring, Control actions |
Control delegation | Agent | Centralized/Edge → Agent | Update DL/UL scheduling, Update HO algorithm | Programmability, Multi‐service |
In this chapter, we have ventured in detail into the RAN architecture design for 5G, for instance covering the key changes to the RAN protocol stack that have been already agreed or discussed in 3GPP, or key considerations that have to be made in the context of the handling of novel AIVs, or for network slicing, multi‐service and multi‐tenancy support. We have also discussed how multi‐connectivity among different 5G AIVs, or among (e)LTE and NR, will likely be realized, and have covered in detail the novel 5G design paradigm of offering various CP/UP split options and also horizontal function splits in the RAN, in order to flexibly adapt the RAN to various physical deployment scenarios. Finally, we have ventured into RAN programmability and control, which is seen as essential to meet the diverse service requirements foreseen for 5G, and to facilitate network evolution.
It appears that 3GPP has already moved fast and obtained various important agreements that pave the road towards the 5G RAN. The key challenge will likely lie in the exact implementation of the 5G system, in particular given the many (more) degrees of freedom that 3GPP foresees for 5G in comparison to legacy technology, for instance related to the usage and parametrization of network functions or a plethora of multi‐connectivity and also vertical and horizontal split options in the RAN. It is expected that many details will be left to proprietary implementation and optimization, in particular how exactly network slicing, multi‐service and multi‐tenancy are realized in the RAN. Similarly, we will likely see proprietary RAN interfaces (e.g., related to intra‐PHY split options) that are highly optimized to, e.g., specific mMIMO product offerings from network vendors, and proprietary concepts for cross‐layer optimization, such as overall resource management and QoS management concepts across the layers from SDAP to PHY.