5G Architecture PDF

# The 5G architecture Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi ## 3.1 Introduction The design of a mobile network architecture aims at defining network elements, such as: * Base Stations (BSs) * switches * routers * user devices and their interaction in order to ensure...

# The 5G architecture Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi ## 3.1 Introduction The design of a mobile network architecture aims at defining network elements, such as: * Base Stations (BSs) * switches * routers * user devices and their interaction in order to ensure a consistent system operation. This chapter discusses basic considerations and provides an overview of current research activities. Network architecture can be considered from different angles that are needed in order to fulfill objectives like integration of technical components into an overall system, proper interworking of multi-vendor equipment and efficient design of physical networks from a cost and performance point of view. As 5G systems have to integrate a plethora of partly contradicting requirements, enablers such as: * Network Function Virtualization (NFV) * Software Defined Networking (SDN) are to be applied in order to provide the needed flexibility of future networks, especially for the core network. Applying these tools may require a rethinking of some traditional aspects of network architecture design. This chapter will give the reader an impression of the most important topics influencing architecture design of future networks. ## 3.1.1 NFV and SDN Today's operator networks include a large and increasing variety of hardware appliances. Launching new services often requires integration of complex hardware dedicated to the service including costly procedure design and is associated with lengthy time to market. On the other hand, hardware life cycles become shorter as technology and service innovation accelerates. At the end of 2012, network operators have started an initiative on NFV. NFV aims at consolidating the variety of network equipment onto industry-standard high-volume servers. These servers can be located at the different network nodes as well as end-user premises. In this context, NFV relies upon but differs from traditional server virtualization. Unlike server virtualization, Virtualized Network Functions (VNF) may consist of one or more virtual machines running different software and processes in order to replace custom hardware appliances. As a rule, multiple VNFs are to be used in sequence in order to provide meaningful services to the customer. ## 3.1.2 Basics about RAN architecture The design of network architectures aims firstly at integrating technical components into an overall system and making them properly interoperable. In this context, it is very important to define a common understanding on how components designed by different manufacturers are capable of communicating so that they can execute the needed functionalities. So far in standardization, this common understanding is achieved by the specification of a logical architecture consisting of logical Network Elements (NEs), interfaces and related protocols. Standardized interfaces allow for communication between NEs with aid of protocols including procedures, message formats, triggers and behavior of the logical network elements. ## 3.3 Functional architecture and 5G flexibility In traditional networks, the assignment of NFs and NEs to physical nodes is designed for a specific deployment. SDN and NFV are novel architectural enablers that allow for a new way of deploying a mobile network. Hence, recent 5G research projects have addressed the logical architecture design by defining NFs and inter-function interfaces, instead of NEs and inter-node interfaces, except for the air interface, for obvious reasons. This implies a number of potential benefits such as * NFs can be placed at optimal locations in a flexible way considering opportunities and limitations of the transport network. * Only necessary NFs are applied to avoid overhead. * NF can be optimized through dedicated implementations. However, this approach would require a plethora of interface definitions to enable multi-vendor interoperability. Hence, operators must be enabled to define and configure flexibly their own interfaces based on the functions that are used. A potential challenge that will concern mobile network operators is the increased complexity of such a system where many interfaces would need to be managed. As it is elaborated further in Section 3.4.1, software interfaces instead of inter-node protocols may be a solution but the 5G architecture design must carefully take into account the trade-off between complexity and flexibility. This section provides an introduction on criteria for splitting functionality between NEs, an overview of exemplary functional splits, and examples for optimizing the operation of a mobile network. It is worth mentioning that the analysis not only supports the shift from inter-node to inter-function interfaces but also might be used to understand potential RAN functional splits with inter-node interfaces. ## 3.3.1 Functional split criteria During the logical architecture design, the so-called "functional split" allows mapping of NFs to protocol layers and defining the placement of these layers within different NEs. There are different possibilities for implementing the functional split in 5G and they will mainly be driven by the following two factors: * a distinction between NFs that operate synchronous or asynchronous with respect to the radio frames. Depending on this distinction there exist stronger or looser timing constraints on the interfaces. * backhaul (BH) and fronthaul technologies which may be used to operate the 5G system. Depending on the technology, there might be latency or bandwidths limitations on the interfaces. In particular, when it comes to functional split, the following aspects should be carefully taken into account: * Centralization benefits: Defining whether the architectural approach would imply benefits in case it is centralized with respect to the case of distributed implementation (see Table 3.1). * Computational needs and diversity: Some functions may require high computation capabilities that should be provided centrally, at the same time at these locations applications with very different types of traffic demands may be implemented. * Physical constraints on the link: With particular reference to the latency and bandwidth requirements on the connections between central unit pool and remote units. * Dependencies between different NFs in terms of synchronicity and latency toward the air interface: NFs running at higher network layers in the OSI model are considered to be asynchronous. Two NFs should not be split if one of them depends on time-critical information of the other. Table 3.1 summarizes benefits, requirements and constraints related to the functional decomposition from a fully centralized approach to a completely distributed positioning of NFs. ## 3.3.2 Functional split alternatives As previously mentioned, 5G is characterized by the flexibility of placing NFs at any location within the network topology. This flexibility potentially introduces the two options of a Centralized RAN (C-RAN) and a Distributed RAN (D-RAN). Traditionally, C-RAN primarily aims at centralizing (pooling) base band processing resources. With the aid of NFV and using industry standard high volume server hardware for the base-band signal processing, the C-RAN approach can be extended to the so-called Cloud-RAN where mainly D-RAN is operated, C-RAN as well as Cloud-RAN architectures represent a kind of paradigm change. So far, only fully centralized RAN architectures have been implemented, which require that the digitized receive signal (I/Q samples, one stream per antenna) is communicated via a fronthaul link between radio access point and central baseband pool, e.g. using an interface such as CPRI or ORI. The flexibility in 5G networks refers to the extension of this concept to a generic split of the NFs. A classical representation of this functional split is reported in [8]. Figure 3.5 shows four different options to split the functionality between the local radio access point and the central processor, the split line identifying what is in the central location (above the line) and what is locally placed (below): * Split A: Lower Physical layer split. Similar to the currently deployed CPRI/ORI based functional split, where highest centralization gains are achieved at the expense of strong fronthaul requirements. * Split B: Upper Physical layer split. Similar to the previous option, but only user-based NFs are centralized while cell-specific functions are remotely managed. For instance, Forward Error Correction (FEC) coding/decoding may be centralized. Its processing and fronthaul requirements scale with the number of users, their occupied resources and data rates. Hence, multiplexing (MUX) gains are possible on the fronthaul link and centralization gains are slightly reduced. * Split C: MAC centralization. Time-critical centralized processing is not needed but also less centralization gains are exploitable. This implies that scheduling and Link-Adaptation (LA) must be divided into a time-critical (locally performed) and less time-critical part (centrally performed). * Split D: Packet Data Convergence Protocol (PDCP) centralization. Similar to existing dual connectivity mechanisms in 3GPP LTE. Functions that operate asynchronously to the air interface frames are the ones with the least restrictive requirements on centralization and virtualization. These are the ones typically assigned to PDCP and RRC protocols. It has also been pointed out that the functions running in the lower layer must be performed synchronously to the air interface frames, i.e. part of the functionality which is centralized in splits A and B. This imposes strong requirements on their interfaces, which makes centralization and virtualization very challenging. On the other hand, core network functions, not explicitly addressed here are the ones benefiting the most from both centralization and virtualization. As it is discussed in detail in Section 3.4, the actual choice of functional split highly depends on the physical deployment and specific applications. In addition, the functional split could be arranged in different options regarding control and user plane. Three models are envisioned: * Straight flow: Packets from the core go to the central entity that afterwards sends them to the remote units. This option is viable with centralized higher layers and distributed lower layers. * Forward-backward flow: Packets from the core are sent directly to the remote units that decide what must be processed by the central unit. Afterward, the central unit NFs perform required processing and send the packets back one more time to the remote units. This option is viable when some higher-layer NFs are managed in a distributed way. * Control/user plane separation: The previous two models can be further split in the case that central units perform only control plane processing and remote units only user plane processing. ## 3.3.3 Functional optimization for specific applications 5G networks will provide more degrees of freedom to optimize the mobile network operation, e.g. based on a specific purpose, dedicated software may be deployed and only a subset of the whole RAN protocol stack is implemented. Some factors that should be considered for optimizing mobile network functionality are listed in Table 3.2. Functionality that may be optimized based on the scenario can be identified on all RAN protocol layers. On physical layer, coding plays an important role, e.g. block codes for mMTC and turbo-codes for XMBB, hard-decision decoding for resource limited nodes, carrier modulation, e.g. single-carrier for latency-critical applications and multi-carrier for high-throughput services, or channel estimation, which may be performed differently depending on the scenario. Table 3.2 Influence factors on functional composition. | Factor | Impact | Example | |---|---|---| | Structural properties | Interference pattern, shadowing, deployment limitations | High buildings, streets or pedestrian area | | User characteristics | Multi-connectivity need, D2D availability, handover probability | Mobility, user density | | Deployment type | Local breakout, cooperative gains, dynamic RAN | Stadium, hot spot, airport, mall, moving/nomadic nodes | | Service pattern | Local breakout, latency and reliability requirements, carrier modulation | mMTC, MBB | | RAN technology | Backhaul connectivity, coordination opportunities | Massive MIMO, COMP, Inter-Cell Interference Coordination (ICIC) | | Backhaul network | Centralization options, coordination opportunities | Optical fiber, mmWave, In-band | On MAC layer, among others Hybrid ARQ may be differently optimized depending on latency requirements, mobility functions highly depend on the actual user mobility, scheduling implementations must take into account user density, mobility, and QoS requirements and random access coordination may be optimized for MTC if necessary. Furthermore, also functionality on network level can be optimized based on the actual deployment type and service pattern. Local break-out functionality depends on whether local services are to be provided, i.e. in the case that localized services are offered, internet traffic may be handled locally at the radio access point. Multi-cell cooperation and coordination depend on network density, structural properties and user characteristics like interference pattern and user density, respectively. Dual connectivity features depend on which multi-RAT coordination feature is applied (see Section 3.3.5). Example: Consider a wide-area deployment where massive MIMO and ultra-dense networks (UDNs) (of small cells) are deployed. As UDN (see Chapter 11) and massive MIMO could operate at higher frequencies due to small cell areas and narrow beams robust mobility may not be guaranteed. Hence, multi-RAT connectivity for C-plane diversity is needed. The possible degree of centralization will depend heavily on the envisioned backhaul network. Example: Macro-cells with optical fiber connectivity can be deployed more centrally while, for economic reasons, UDN nodes are equipped with wireless backhaul and due to bandwidth limitations less NFs can be centralized. Finally, the applicability of NFs depends on scenario and the deployed RAN technology. Example: For densely UDNs, inter-cell interference coordination or multi-cell processing algorithms are essential, while massive MIMO will require pilot coordination algorithms. Furthermore, UDNs deployed in a pedestrian area with low mobility requirements allow for application of different interference mitigation schemes than wide area nodes at railway lines. Finally, the use of massive MIMO for backhauling will not require mobility management. In the case of a stadium, content will be provided locally and therefore core-network functionality as well as information and telecoтти-nication services should be provided locally. Similarly, at hot spots local services may be offered, which requires again local core-network functionality. For each of the above examples, dedicated software may be deployed which is optimized for the particular use case. ## 3.3.4 Integration of LTE and new air interface to fulfill 5G requirements The integration of new air interfaces with legacy one(s) has always been an important task during the introduction of a new generation of mobile systems. Up to the introduction of 4G, the main goal of such integration was the provision of seamless mobility over the whole network, the smother introduction of new services in particular areas provided by the new generation and the maintenance of the services supported by the previous generation such as voice, supported by UTRAN during initial LTE deployments via circuit-switched fall-back. Among the different 3GPP systems this integration has been typically achieved via inter-node interfaces between the different core network nodes such as S11 (between MME and Serving Gateway) and S4 (between Serving Gateway and SGSN). For the transition to 5G a tight integration of the new air interface with LTE (compared to the integration between current legacy systems) will be from day one an essential part of the 5G RAN architecture. A tight integration in this context basically means a common protocol layer for multiple accesses residing above access-specific protocol layer(s). The demand for this tight integration comes from data rate requirement in 5G (up to 10 Gbps), which together with lower latency, drives the design of a new air interface(s) to be optimized to operate in higher frequencies above 6 GHz. Under these frequency bands, propagation is more challenging and coverage can be spotty [2]. In parallel with the 5G research activities, 3GPP is continuously adding new features to LTE and it is likely that at the time 5G reaches market LTE should be capable of addressing many of the 5G requirements, such as the ones related to MTC and MBB. At that time, LTE is also expected to be heavily deployed and, the fact that it operates in frequency bands with better propagation properties, makes the integration of LTE and the new interface operating in higher frequency bands very appealing. This kind of tight integration of multiple accesses has been previously investigated [3], where a common RRM-based architecture for GSM, UTRAN and WLAN has been introduced for service-based access selection. In the Ambient Networks project, different tight integration architectures have been discussed and an architecture, relying on a multi-radio resource manager and a generic link layer, has been proposed. More recently alternatives for a tightly integrated architecture have been evaluated taking into account the LTE protocol architecture and aspects that are an important part of the new air interface [2]. Further, according to [2], at least PDCP and RRC layers should be common for LTE and the new air interface supporting the 5G requirements. This preferred option leads to a protocol architecture somehow similar to the one standardized in LTE Release 12 to support dual connectivity. The various options are the following (and shown in Figure 3.6): Figure 3.6 Different protocol architectures for the tight integration of LTE and new air interface. * Reduced delays on hard handovers compared to current 4G and 3G interworking. * Limits the possibility for coordination features (basically enables air interface selection) * Coordination gains from a common control plane: mobility, multi-connectivity traffic steering. * Suitable for any type of backhaul in non-collocated scenarios. * Strict synchronicity not required between the new Al and LTE. * Very tight coordination gains e.g. cross-carrier scheduling. * Limited to co-located scenarios or ideal backhaul. * High level of synchronicity required between MAC/RLC/PHY layers in LTE and new Al. ## Inter-connected core networks or a common core network In this case, each RAT has its own RAN protocol stack and its own core networks where both core networks are linked via inter-node interfaces. The current solution integrates UTRAN (3G) and E-UTRAN (4G), where an inter-node interface exists between Mobility Management Entity (MME) and S-GW for the control plane. When it comes to the integration between 5G and LTE, this is unlikely to be the way forward since it would be challenging to fulfill the requirements of seamless mobility and transparent connectivity. In the case that each RAT has its own RAN protocol stack but the core network is common, new 5G core NFs can be used by both LTE and the new air interface. This has the potential to reduce hard handover delays and enable more seamless mobility. On the other hand, potential multi-RAT coordination features might not be possible. ## Common physical layer (PHY) The LTE PHY layer is based on OFDM. It provides services to the MAC layer in the form of transport channels and handles the mapping of transport channels to physical channels. OFDM-based transmission will most likely remain as a good baseline also for the new air interface, that will likely have quite different characteristics compared to LTE, e.g. in terms of OFDM numerology, which means numbers for carrier spacing, symbol length, guard intervals and cyclic prefix length (cf. Chapter 7). Hence, the introduction of a common PHY may be very challenging. In addition, this architecture would impose limitations in terms of deployments since non-collocated operation of multi-RAT radios would likely not be possible due to the high level of synchronicity needed between the physical layers of LTE and the new air interface. ## Common medium access control (MAC) The LTE MAC layer provides services to the RLC layer in the form of logical channels, and it performs mapping between these logical channels and transport channels. The main functions are: uplink and downlink scheduling, scheduling information reporting, Hybrid-ARQ feedback and retransmissions, (de)multiplexing data across multiple component carriers for carrier aggregation. In principle, the integration of the new air interface and LTE on the MAC level can lead to coordination gains, enabling features such as cross-carrier scheduling across multiple air interfaces. The challenge to realize a common MAC comes from the assumed differences in the time- and frequency-domain structures for LTE and the new air interface. A high level of synchronicity would be needed between the common MAC layer and underlying PHY layers, including LTE and novel air interfaces. In addition, harmonized numerology for the different OFDM-based transmission schemes is needed. This challenge would likely limit this level of integration of the MAC layer level of integration to co-located deployments in which this high level of synchronicity could be achieved. ## Common RLC In LTE, the RLC layer provides services for the PDCP layer. The main functions for both user and control plane are segmentation and concatenation, retransmission handling, duplicate detection and in-sequence delivery to higher layers. RLC integration is likely to be challenging due to the required level of synchronicity between PHY, MAC and RLC. For example, in order to perform fragmentation/reassembly, the RLC needs to know the scheduling decisions in terms of resource blocks for the next TTI, information that has to be provided in time by the PHY layer. A joint fragmentation and reassembly for multiple air interfaces would likely not work unless a common scheduler is deployed. Similarly to the previous alternative (common MAC), a common RLC would only properly operate in co-located deployments of LTE and the new air interface. ## Common PDCP/radio resource control (RRC) In LTE, PDCP is used for both control and user planes. The main control plane functions are (de)ciphering and integrity protection. For the user plane, the main functions are (de)ciphering, header (de)compression, in-sequence delivery, duplicate detection and retransmission. In contrast to PHY, MAC and RLC functions, the PDCP functions do not have strict constraints in terms of synchronicity with the lower layers. Hence, a specific design for PHY, RLC and MAC functionalities for both air interfaces would likely not impose any problems for a common PDCP layer. In addition to this, such integration would work in both co-located and non-collocated network deployment scenarios, making it more general and future proof. The RRC layer is responsible for the control plane functions in LTE. Among these, the broadcast of system information for non-access stratum and access stratum, paging, connection handling, allocation of temporary identifiers, configuration of lower layer protocols, quality of service management functions, security handling at the access network, mobility management, and measurement reporting and configuration. The RRC functions do not require synchronization with functions in lower layer protocols, which makes it quite likely that they can be common to multiple air interfaces in order to exploit potential coordination gains from a common control plane. As in the case of common PDCP layer, both co-located and non-collocated network deployment scenarios would be allowed. ## 3.3.5 Enhanced Multi-RAT coordination features Different multi-RAT coordination features can be envisioned thanks to the recommended protocol architecture alternative relying on a tight integration with common PDPC/RRC, as shown in the previous section. Some of these options are shown in Figure 3.7. ## Control plane diversity A common control plane for LTE and the new air interface would allow a dual-radio device to have a single control point for dedicated signaling connected via the two air interfaces. An equivalent concept has been developed as part of the dual connectivity concept for LTE Release 12 in order to improve mobility robustness [5]. With such a feature, no explicit signaling would be needed to switch the link and the receiver should be capable of receiving any message on any link including the same message simultaneously on both air interfaces. This might be the main benefit of the feature, which might be important to fulfill the ultra-reliability requirements for certain applications in challenging propagation conditions. In addition, a common control plane is also an enabler for user-plane integration features, as discussed in the following. Figure 3.7 Different multi-RAT coordination features. * Fast control plane switching: With such a feature relying on a common control plane, the device would be capable of connecting to a single control point via any of the air interfaces and switch very fast (without the need of core network signaling, context transfers, etc.) from one link to another without requiring extensive connection setup signaling. The reliability might not be as high as with applying control plane diversity and additional signaling would be needed. * User plane aggregation : One variant of the user plane aggregation is called flow aggregation, which allows a single flow to be aggregated over multiple air interfaces. In another variant, defined as flow routing, a given user data flow is mapped on a single air interface, such that each flow of the same UE may be mapped on different air interfaces. The benefits of this feature is increased throughput, pooling of resources and support for seamless mobility. The flow aggregation variant may have limited benefits when the air interfaces provide different latency and throughput. * Fast user plane switching: Here, instead of aggregating the user plane, the user plane of devices uses only a single air interface at a time, but a fast switching mechanism for multiple air interfaces is provided. In this case, a robust control plane is required. Fast user plane switching provides resource pooling, seamless mobility and improved reliability. * Lean by help of LTE: This feature relies on a common control plane. The basic idea is to make 5G "lean" by transmitting all control information over LTE that will anyway be transmitted for backwards compatibility purpose (cf. Chapter 2). Information to idle mode devices, e.g. system information, is transmitted over LTE. The main benefit is that it likely reduces overall network energy consumption and “idle" interference in 5G. Even though the transmitted energy is just moved from one transmitter to another, substantial energy can be saved when the electronic circuitry associated with a transmitter can be turned off. ## 3.4 Physical architecture and 5G deployment ## 3.4.1 Deployment enablers The logical architecture enables specification of interfaces and protocols whereas a functional architecture describes the integration of NFs into an overall system. The arrangement of functions in a physical architecture is important for practical deployment. NFs are mapped to physical nodes trying to optimize cost and performance of the whole network. In that sense, 5G will follow the same design principles as previous generations. However, in 5G networks the introduction of NFV and SDN concepts will cause also a rethinking of imaginations in the context of traditional protocol stack methodologies. There could be interfaces directly between NFs rather than between NEs. Interfaces between functions not necessarily have to be protocols but may be software interfaces. The idea around SDN and NFV are mainly driven by flexibility requirements at the core network. However, an extension of both enablers to RAN architectures has been developed [6]. A relation of the logical, functional, physical and orchestration architecture is shown in Figure 3.8. NFs are compiled in a Network Function Pool. The function pool collects data processing and control functions, and allows them to be available centrally. It includes information on the interfaces, function classification (synchronous vs. asynchronous) and placement options as well as input and output relations. At high level, RAN related functions can be assigned to the following building blocks: * Central management entities include overarching network functions that mainly are to be deployed at some central physical nodes (data centers). Typical examples are context and spectrum management. * Radio Node Management provides functions that usually affect more than one radio node to be operated at selected physical radio node sites (D-RAN or Cloud-RAN). * Air Interface functions provide functionalities directly related to the air interface in radio nodes and devices. * Reliable service composition² represents a central C-plane integrated into service flow management that interfaces to the other building blocks. This function evaluates the availability or enable provisioning of ultra-reliable links applied for novel services requiring extremely high reliability or extremely low latency. The task of the flexible network configuration and control block is to realize an efficient integration of functions according to service and operator requirements by mapping elements of the logical topologies of data and control plane to physical elements and nodes as well as configuration of the NFs and data flows as shown in Figure 3.8. Thereby, in a first step, the Service Flow Management is analyzing customer-demanded services and outlines requirements for data flows through the network. Requirements from 3rd party service providers, e.g. minimum delay and bandwidth, can be included through a dedicated API. These requirements are communicated to the 5G orchestrator and 5G SDN controller. The 5G orchestrator is responsible for setting up or instantiating VNFs, NFs or logical elements within the physical network. Radio Network Elements (RNEs) and Core Network Elements (CNEs) are logical nodes that can host virtualized functions (VNF) or hardware (non-virtualized) platforms (NF). Logical Switching Elements (SEs) are assigned to hardware switches. In order to guaranty sufficient performance required by some synchronous NFs, the RNEs will include a mixture of software and hardware platforms in the physical network - especially at small cells and devices. Hence, the flexibility with respect to deployment of VNF in radio access is limited. As most of the respective NFs act asynchronously to the radio frames and hence are less time critical to the air interface, CNEs allow more degrees of freedom to apply function virtualization. The 5G SDN Controller flexibly configures the elements set up by the 5G Orchestrator according to service and operator needs. Thereby, it sets up the data flow through the physical nodes (U-plane) and executes the C-plane functionalities including scheduling and handover functions. At high level, the physical network consists of transport networks, access networks and device networks. The transport network realizes interconnection between data centers by high-performance link technology. Transport network sites (data centers) host physical elements dealing with big data streams including the fixed network traffic and core network functionalities. RNEs may be collocated realizing centralized base band processing (Cloud-RAN). In radio access, 4G base station sites (sometimes referred as D-RAN) as well as sites hosting Cloud-RAN connected via fronthaul to pure antenna sites will coexist. In other words, the flexible functional placement will lead to deployments where traditional core network functions could be instantiated closer to the air interface. The need for local break out, for instance, will cause a coexistence of RNE, SE and CNE even at radio access sites. SDN concepts will allow for creation of customized virtual networks using shared resource pools (network slices). Virtual networks may be used to realize optimized resource assignment to diverse services such as mMTC and MBB. It also allows for resource sharing between operators. ## 3.4.2 Flexible function placement in 5G deployments A physical architecture determines a set of characteristics of the radio access such as network density, radio access point properties (size, number of antennas, transmit power), propagation characteristics, expected number of user terminals, their mobility profile and traffic profile. It also determines the backhaul technology between radio access nodes and transport network, which may be a heterogeneous technology mix composed of fixed line and wireless technologies. Furthermore, the physical deployment defines the technology toward the core network and its logical elements. All these characteristics imply the physical properties and limitations, which apply to the interaction of functional and logical mobile network components. The impact of these limitations and the way how to cope with them may differ significantly depending on the data rate requirements, network status and service portfolio. The choice of functional split options and the physical deployment conditions are tightly coupled, i.e. a decision of a certain functional split option determines the logical interfaces that must be carried over the physical infrastructure, which imposes constraints on this interface. Consider first the network density. The more radio access points are deployed per unit area, the more backhaul (BH) traffic must be supported. Figure 3.10 shows the number of supported base stations depending on the BH data rates and functional split [7]. The higher the functional split is located within the RAN protocol layers, the more access points can be supported. Split A (cf. Figure 3.5) implies a static data rate per radio access point while in the case of split B and `C`, data rates vary with the actual data rates toward users. Hence, these two splits are able to exploit a statistical multiplexing gain³ in the transport network, which may be up to a factor of 3. By contrast, split A will always induce the same data rate per access point independent of the actual load and therefore no multiplexing gain can be exploited. Backhaul technologies not only determine possible data rates but also influence end-to-end latencies that can be realized. Split A requires optical fiber or mmWave backhauling technologies with either wavelength-switching or daisy-chaining of mmWave links. Low latency is very critical for split A as the physical transmission is implemented by CPRI, which obtains its time and frequency synchronization from the CPRI data stream. Split B and C could also tolerate higher latencies in the order of a few milliseconds, which allows for using higher layer switching technologies such as MPLS or Ethernet. This increases the degrees of freedom to design the backhaul network significantly. The main difference between splits B and C is that split B performs central encoding and decoding. In current 3GPP LTE, this may imply stringent timing requirements because the Hybrid ARQ process requires that code words are processed within 3 ms after reception. If the backhaul latency is in the order of a few milliseconds, this constraint would not be met. Hence, either workarounds are required which relax this requirement [17] or 5G mobile network must be sufficiently flexible to scale its latency requirements. However, also split C (and inherently split B) has to cope with latency requirements for instance for scheduling and link-adaptation. The latter is very critical as a sub-optimal link-adaptation due to imperfect channel knowledge may severely deteriorate the performance [18]. The impact of this latency is mainly determined by the user mobility and changing interference patterns. Both network density and user density have an inherent impact on the choice of the functional split as well as its gains. In the case that each cell has to serve a large number of users, one can expect scenarios where almost all resources are occupied. Hence, significant inter-cell interference is caused, which must be mitigated through cooperative algorithms. In this case, functional splits at lower RAN protocol layers are preferable. Such a scenario would occur, for instance, in hot spots, stadium or indoor deployments such as malls and airports. By contrast, if the number of users per cell is rather low or significantly varying due to the user's traffic profile, the number of occupied resources per cell may be lower. This increases the degrees of freedom for inter-cell coordination, which could be performed with higher layer functional splits and may be similarly efficient as cooperative algorithms. Finally, the service profile has a strong impact on the choice of functional split as well as the deployment. Splits A and B offer more optimization opportunities compared to split C because more functionality can be implemented in software and optimized for the actual purpose as discussed in Section 3.3.3. For instance, split B allows for using coding technologies specific for the actual service, e.g. block-codes for MTC and LDPC codes for MBB services. Furthermore, split B allows for joint decoding algorithms in order to mitigate interference efficiently. Hence, if high service diversity can be foreseen, it may be worth to increase the degree of centralization. However, there also may be services that must be processed locally, e.g. vehicular traffic steering. Hence, the network may need to selectively apply the degree of centralization. The next three examples describe how the placement of functionality may be determined by the type of deployment. ## 3.4.2.1 Wide-area coverage with optical fiber deployment In this case, all radio access NFs are centralized. This imposes the strongest requirements on the network in terms of transport network capacity and latency. However, since all radio NFs are executed in a data center, preferably co-located with core NFs, also the maximum cooperative diversity gains as well as software virtualization gains can be exploited. Furthermore, other RAT standards could easily be integrated by providing for each a specific implementation running at the data center. However, relying on optical fiber backhaul also limits the flexibility and increase deployment costs, e.g. for small-cell networks where all nodes need to be connected either via optical fiber or line-of-sight (LOS) mmWave backhaul technologies. ## 3.4.2.2 Wide-area coverage with heterogeneous backhaul This scenario is illustrated in Figure 3.11 [19] and would allow for different backhaul technologies, which are chosen based on available backhaul links as well as structural limitations, e.g. the usage of multi-hop mmWave technologies as well as Non-Line-of-Sight (NLoS) backhauling. This mix of backhaul technologies enables different degrees of centralization. Hence, the ability to cooperate among radio access points and the flexibility to adapt to changing network parameters may vary. If, for instance, two radio access points would apply functional split B and C, respectively, then both could coordinate their resources through ICIC and split B could apply advanced and tailored coding algorithms. This deployment scenario is optimal in terms of capital expenditures [20] as it exploits a large portion of cooperative gains and reduces deployment costs compared to conventional deployments. However, it is also very challenging from many perspectives such as cooperation among radio access points, placement and dimension-ing of data processing elements, deployment of software, and management of network elements, e.g. by means of SDN. ## 3.4.2.3 Local-area stadium A stadium deployment is illustrated in Figure 3.12 and a very good example for deployments where the infrastructure is owned by the operator of the venue. Similar deployments are airports or malls. In this case, the operator of the venue provides the connectivity while mobile network operators must share the facilities. Furthermore, those deployments are very well planned and dimensioned in order to fit with the expected traffic demands. Finally, the deployed hardware will be very similar to wide-area or other hot-spot deployments but the applied software may vary significantly, not only in the radio access but also core-network functionality. For instance, core-network functionality may be placed right at the stadium in order to allow for local services such video streaming. ## 3.5 Conclusions As next generation radio access has to fulfill a broad range of requirements, the design of future networks architectures will be driven by demand for flexibility, scalability and service-oriented management. Even though not directly associated with 5G, NFV and SDN will complement each other and enable the implementation of these basic requirements. 5G networks respond to changing market conditions will be much faster compared to legacy networks e.g. 3G or 4G. By fulfilling high-level requirements like co-deployments of 5G with LTE evolution and provisioning of multi-RAT connectivity, high capacity islands as well as ultra-reliable radio links can be enabled without additional economic effort. Flexible placement of network functions paves the way for better matching of functional split to service requirements, user density, propagation conditions as well as mobility and traffic profiles. To enable all these benefits, it will be fundamental to provide