3 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 (e.g. 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 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) and 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 [1]. NFVaims
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 virtualiza-
tion. 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 (Figure 3.1). As a rule, multiple VNFs are to be
used in sequence in order to provide meaningful services to the customer.

5G Mobile and Wireless Communications Technology, ed. A. Osseiran, J. F. Monserrat, and P. Marsch.
Published by Cambridge University Press. © Cambridge University Press 2016.
 The 5G architecture 51

Legend
Logical Link
Orchestration Framework Physical Link
Virtualization
NFVI
NF VNF NF Virtual
VM
Machines
A Accelerators
Virtualization Layer
End End
Point Point

VM VM VM
A VM A

Figure 3.1 NFV framework.

Example: The air interface is arranged in different layers that build upon each other (cf.
Figure 3.5). In order to provide connectivity, RF processing, physical layer, medium
access control, radio link control and packet data convergence protocol layer are
arranged in sequence.

NFV requires an orchestration framework that enables proper instantiation, monitoring

and operation of VNFs and Network Functions (NFs) (e.g. modulation, coding, multiple
access, ciphering, etc.). In fact, the NFV framework consists of software implementations
of network functions (VNF), hardware (industry standard high volume servers) that is
denoted as NFV Infrastructure (NFVI) and a virtualization management and orchestration
architectural framework. In order to realize real time requirements some NF may need
inclusion of hardware accelerators. The accelerators take over computation intensive and
time critical tasks that still cannot be realized by NFVI. Hence, not only can traffic be off-
loaded from NFVI but also adherence of latency requirements can be ensured.
Opportunities and limitations for NFV are described in more detail in Section 3.4.1.
As depicted in Figure 3.1 in context with virtualization physical and logical paths between
the end points (e.g. devices) in the network are to be distinguished.
The most significant benefits of NFV [1] are reduction of capital and operational
expenditures as well as increased speed of time to market. However, an important
prerequisite for leveraging these benefits is that VNFs are portable between different
vendors and that they can coexist with hardware-based network platforms.
As mentioned previously, in addition to NFV, SDN is another important enabler for
5G future networks. The basic principles of SDN are separation of control and data
planes (also called infrastructure layer or user planes), logical centralization of network
intelligence and abstraction of physical networks from the applications and services by
standardized interfaces [2]. Further, the control of the network is concentrated in
a control layer (control plane), whereas network devices like switches and routers that
52 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

Application Layer
Business Applications

API API API

Network Services
SDN
Control Layer Control
Software

Control-to-infrastructure Layer
interface, e.g. OpenFlow

Network Device Network Device

Infrastructure
Layer
Network Device

Figure 3.2 SDN Architecture.

handle data plane functionalities are distributed within the network topology of the
infrastructure layer (Figure 3.2).
The control layer interacts at one side with the applications and services via standar-
dized Application Programing Interfaces (API) and at the other side with the physical
network via a standardized instruction set called OpenFlow. APIs make it possible to
implement network services like routing, security and bandwidth management.
OpenFlow allows direct access to the plane of network devices like multi-vendor
switches and routers. Since it allows the network to be programmed on a per flow
basis, it provides extremely granular control enabling the network to respond in real time
to demand changes at the application layer and avoid cumbersome manual configuration
of network devices. From a topology point of view, NFs belonging to the control and
infrastructure layers may be arranged centrally, as well as in a distributed manner, based
on the requirements explained in more detail in Section 3.3.
NFV and SDN do not rely on each other. However, as NFV is providing a flexible
infrastructure on which the SDN software can run and vice versa, that is, SDN concept
enables flow based configuration of network functions, both concepts are to be seen as
highly complementary.
 The 5G architecture 53

In 5G networks, both concepts will serve as key enablers to provide the needed
flexibility, scalability and service-oriented management. As for economic reasons net-
works cannot be dimensioned for peak requirements, flexibility means that tailored
functionalities will have to be made available on-demand. Scalability is to be supported
in order to fulfill requirements of contradicting services like massive Machine-Type
Communication (mMTC), ultra MTC (uMTC) and extreme Mobile BroadBand
(xMBB), e.g. by inclusion of adequate access procedures and transmission schemes (see
Chapter 4 for more information on MTC). Service-oriented management will be realized
by flow-oriented control and user planes enabled by joint NFV and SDN frameworks.

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.

Example: The E-UTRAN architecture defined in 3GPP for the 4th Generation radio access
(Figure 3.3) consists of the NEs radio node (eNodeB (eNB)) and devices (User Equipment
(UE)) [3]. eNBs are linked with themselves via an inter-node interface X2 and UEs are
linked to eNBs via the air interface Uu. 4G systems consist of a flat architecture hence eNBs
are linked directly to the core network (evolved packet core, EPC) via an S1 interface.

Each NE accommodates a set of NFs that execute operations based on a set of input
data. NFs generate a set of output data that is to be communicated to other NEs. Each of
these NFs must then be mapped to NEs. The functional decomposition of technical
components and the assignment of NFs to NEs are described by a functional architecture
(Figure 3.4). An implementation of technical components may require the placement of
their NFs at different places within the logical architecture.

Example: Channel measurements can only be done directly at the air interface of devices
or radio nodes whereas resource assignment based on these measurements might be
done in the radio nodes.

NFs impose different interface requirements with respect to latency and bandwidth.
This implies the need for a view on how the boxes are arranged in a concrete
54 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

EPC EPC

UE S1
S1
Uu

X2

eNB eNB
S1 X2
X2 S1

eNB

Figure 3.3 E-UTRAN architecture.

Technical Logical and Orchestration Physical

Component functional Architecture architecture
architecture

Logical network
elements (NE)
Core
Network
Functional
Interface
Decomposition
SDN & Physical nodes
NF1 NFV
Radio node
Enabler

NF2 NF3 Interface

Logical
NF = Network Function Device
Physical devices

Figure 3.4 Relation between functional, logical, orchestration and physical architectures.

deployment. The physical architecture describes the assignment of NEs or NFs to

physical nodes that are located at certain locations within the network topology.
Physical architecture design has a big impact on network performance and network
economics. Some NF may preferably be placed at central sites for, e.g. economic reasons
in the case that statistical multiplexing of computing resources can be exploited.
However, due to functional or interface requirements in terms of latency or bandwidth
 The 5G architecture 55

demand some functions may need to be operated close to the air interface or close
together, which rather requires a distributed placement. In this case, both performance
and cost may be affected. Technical and operational aspects in the context of function
placement are elaborated in more detail in Section 3.3.
Traditionally the assignment of NFs to NEs as well as of NEs to physical nodes has
been customized for each specific deployment. As it was seen from Chapter 2, diverse
end-user requirements, services and use cases suggest the need for much more
flexibility in 5G networks. Novel architectural enablers such as NFV and SDN aim
to facilitate this increased flexibility [1][2]. An orchestration and control architecture
as described in more detail in Section 3.4.1 will allow for significantly more flexible
placement of NFs in future physical networks. To be more precise, the usage of SDN/
NFV is already happening in 4G networks, mainly for core network functions. The 5G
architecture will explore these technologies from the beginning. At this point, it is to
be highlighted that in future networks the focus will be much more on NFs rather than
on NEs.
Specification by standardization groups plays an important role to guarantee
worldwide interoperability of equipment originating from different manufacturers.
Even though traditional NEs, protocols and interfaces are specified, both network and
device manufacturers still have considerable degrees of freedom. The first degree of
freedom consists of how NEs are mapped to the physical network.

Example: Even though E-UTRAN is essentially a distributed logical architecture,

a network manufacturer can still design a centralized solution where physical controller
equipment, e.g. placed at a central access site, executes some eNB functions while other
functions are executed at the distributed physical nodes closer to the radio heads. In that
sense, a network manufacturer would be splitting a standardized NE into multiple physical
nodes in order to enable a centralized deployment architecture. In another direction, the
same vendor has the freedom to merge NEs in the same physical node, as it is the case in
some core network nodes that are used in the market where manufacturers offer solutions
of integrated Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW) [3].

The second degree of freedom regards the hardware and software platforms archi-
tectures that are applied by the different manufacturers. So far, this has not been in the
scope of 3GPP, which does not define any specific software or hardware architectures or
platforms for the NEs.
The third degree of freedom relates to how manufacturers can implement the decision
logic behind the different NFs.

Example: 3GPP has specified protocols for information exchange at the air interface.
This defines the way how radio nodes (eNB) communicate, among others, scheduling
information and the way devices (UE) interpret this information and how the UE should
56 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

react. However, there exists some degree of freedom on how an eNB uses information in
order to assign resources.

3.2 High-level requirements for the 5G architecture

Before the RAN logical architecture is specified, high-level principles should be defined.
These principles take into account the 5G end-user requirements and envisaged services.
In the following, the most important high-level design principles for the 5G architecture
are listed.
principle i: The 5G architecture should benefit from co-deployments with the evolution
of LTE, but inter-system dependencies should be avoided. At the same time, all funda-
mental RAN functionalities should be designed having in mind the frequencies that the new
air interface should operate at, e.g. system access, mobility, QoS handling and coverage.
This principle has been derived from i) the acknowledgement of the proven success of
LTE when it comes to Mobile Broadband (MBB) services and possibly other services
such as mMTC [4] and ii) the fact that it is likely that at the time of the initial 5G
deployments LTE will likely have wide coverage [5]. This principle is endorsed in [5],
where enhanced multi-Radio Access Technology (RAT) coordination is stated as
a design principle to be followed for the 5G architecture [4].
Inter-RAT coordination should also include non-3GPP technologies, e.g. IEEE 802.11
family, but the level of coordination may differ.
There may be no need to support handover or service continuity between 5G and 3G
or 2G networks [5].
principle ii: The 5G architecture should enable multi-connectivity, including multi-
layer and multi-RAT.
It is expected that a device may be connected to several links of the same RAT (e.g. to
macro and small cells), as well as to different RATs, including new RATs and LTE. This
may leverage or extend existing technologies such as carrier aggregation and dual
connectivity. This combination of RATs may involve also non-3GPP RATs, e.g. IEEE
802.11ax (High Efficiency Wi-Fi).
principle iii: The 5G architecture should support coordination features usable for
nodes connected via different categories of backhaul.
This means that the new air interface should be designed in a way that avoids
unnecessary constraints such that deployments with different functional splits are
possible. This is a very important principle since coordination for interference cancella-
tion, for example, is part of the “design principles for 5G” [5], where massive MIMO and
Coordinated Multipoint (CoMP) transmission and reception are given as examples of
expected technologies [4]. This principle is also valid for non-collocated deployments of
 The 5G architecture 57

LTE evolution and the new air interfaces. It would guarantee that operators with their
existing backhaul should be able to deploy the 5G technology.
principle iv: The 5G architecture should have embedded flexibility to optimize net-
work usage, while accommodating a wide range of use cases, and business models.
This principle implies that the same RAN logical architecture, specified by 3GPP,
should be sufficiently flexible to address MBB and non-MBB use cases, e.g. uMTC, and
a diversity of business models, e.g. network sharing. When it comes to the RAN and CN
architecture, it implies that the protocol design is flexible enough to support the different
requirements.
principle v: The 5G architecture should have a programmability framework to
enable innovation.
In order to support the envisaged wide range of requirements, address many use cases
(not clear in the time frame 5G is implemented) and allow for fast business innovation,
5G devices should have a high degree of programmability and configurability, multi-
band multi-mode support and aggregation of flows from different technologies, device
power efficiency and service aware signaling efficiency.

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 [3][6], 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.
• NFs 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
58 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

Table 3.1 Assessment of centralized versus distributed architectural approaches. Capacity is compared to required
rates in the case of fully distributed operation.

Approach Expected benefit Requirements Physical Constraints

1
Full centralization Cloud and virtualization Latency : <100 µs, Limited set of suitable
enabler Capacity: ≈20x [7] BH technologies
Coordination schemes
simplified
Routing optimization
Partial centralization Both centralized and Latency: <1 ms (HARQ Many interfaces need to
distributed approaches constrained); <10 ms (frame be standardized
available constrained)
Capacity: ≈1-5x
Fully distributed Distributed processing Synchronization among nodes Inter node connections
operation simplified necessary

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
constrains 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 limita-
tions on the interfaces.
In particular, when it comes to functional split, the following aspects should be
carefully taken into account [8]:

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

1
Latency refers to the RTT latency between radio access point and central processor.
 The 5G architecture 59

• Physical constraints on the link: With particular reference to the latency and band-
width 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 NFs are deployed in a virtualized manner. For legacy physical architectures
where mainly D-RAN is operated, C-RAN as well as Cloud-RAN architectures repre-
sent 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 [9] or ORI [10]. 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).
60 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

EPC

RRC/C-Plane

PDCP Layer
Split D

RLC layer (incl. Buffers, LA, ARQ)

MAC layer (incl. MUX)

Scheduling

Split C

Upper PHY layer (incl. FEC, HARQ)

Split B

Lower PHY layer (incl. DET)

Split A

A/D conversion / pre-processing

RF processing

Radio Access Point

Figure 3.5 Overview of four exemplary functional splits [7].

• 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.
 The 5G architecture 61

In addition, the functional split could be arranged in different options regarding

control and user plane. Three models are envisioned [8]:

• 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 High buildings, streets or pedestrian
limitations area
User characteristics Multi-connectivity need, D2D availability, Mobility, user density
handover probability
Deployment type Local breakout, cooperative gains, dynamic Stadium, hot spot, airport, mall,
RAN moving/nomadic nodes
Service pattern Local breakout, latency and reliability mMTC, MBB
requirements, carrier modulation
RAN technology Backhaul connectivity, coordination Massive MIMO, CoMP, Inter-Cell
requirements Interference Coordination (ICIC)
Backhaul network Centralization options, coordination Optical fiber, mmWave, In-band
opportunities
62 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

On MAC layer, among others Hybrid ARQ may be differently optimized depend-
ing 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 proces-

sing 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 telecommu-
nication services should be provided locally. Similarly, at hot spots local services may be
offered, which requires again local core-network functionality.
 The 5G architecture 63

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 introduc-
tion 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) [11].
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 [12].
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 [4][5][6][12].
This kind of tight integration of multiple accesses has been previously investigated
[13], where a common RRM-based architecture for GSM, UTRAN and WLAN has
been introduced for service-based access selection. In the Ambient Networks project
[14], 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 [12]. Further, according to [12], 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):
64 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

Common Core Network Common PDCP/RRC Common MAC

(better, but not fully explored) (Recommended) (possible, but challenging)
5G CN 5G CN 5G CN

RRC RRC RRC RRC

PDCP PDCP PDCP PDCP
RLC RLC RLC RLC RLC
MAC MAC MAC MAC MAC
PHY PHY PHY PHY PHY PHY
LTE New AI LTE New AI LTE New AI
5G RAN 5G RAN 5G RAN

• Reduced delays on hard • Coordination gains • Very tight coordination

handovers compared to from a common gains e.g. cross-carrier
current 4G and 3G control plane: scheduling
interworking mobility, multi- • Limited to co-located
• Limits the possibility for connectivity, traffic scenarios or ideal
coordination features steering. backhaul
(basically enables air • Suitable for any type • High level of
interface selection) of backhaul in non- synchronicity required
collocated scenarios. between MAC/RLC/
• Strict synchronicity PHY layers in LTE and
not required between new AI
the new AI and LTE
Figure 3.6 Different protocol architectures for the tight integration of LTE and new air interface.

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
 The 5G architecture 65

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,
66 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

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

Control plane diversity Fast control plane User plane

switching aggregation

LTE New AI LTE New AI

LTE New AI

Fast user plane

Lean by help of
switching
LTE

Common 5G RRC and PDCP

LTE New AI
LTE New AI
RLC/MAC/PHY of the new AI
zzz
RLC/MAC/PHY of LTE

Figure 3.7 Different multi-RAT coordination features.

 The 5G architecture 67

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, sub-
stantial 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
68 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

3rd Party
Services/Applications
API

Flexible Network Configuration & Control

Functional Architecture /
Network Function Pool Service Flow Management
Reliable Central Management
Service Entities
Compo- 5G Orchestrator
sition Radio Node (Function Coordinator)
Data
Management
Flow

Air Interface 5G SDN Controller(s)

RNE SE CNE RNE SE CNE RNE SE CNE

Internet
Cloud-RAN Data Centers
D-RAN

Device Networks Access Network Transport Network

Figure 3.8 Relation of logical, functional, physical and orchestration architecture.

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 architec-
ture 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.
 The 5G architecture 69

• Reliable service composition represents a central C-plane integrated into service flow
2

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 deploy-
ments 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.

2
Reliable service composition has been highlighted since it is expected to be one the new 5G services. In fact,
service composition can be as well about any new expected service.
70 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

Central Management Infrastructure Node Device

Entity Measurements
D2D Device Discovery
& Mode Selection
D2D Device D2D Device Discovery
Detection and & Mode Selection
Grouping
Spectrum D2D Discovery
Management Resource Selection
Discovery
Resource Allocation
D2D Mode Selection

Long-Term RRM AI
Spectrum
& Interference D2D Discovery
Controller
Management Signal Generation

Figure 3.9 Assignment of network functions to logical nodes for device-to-device communication (D2D).

With some limitations, 5G architectures will permit device networks where devices
act as part of the network infrastructure enabling other devices to get access to the
network e.g. by D2D communication. Even at this device networks, RNEs will coexist
with SEs and CNEs.

An example for assignment of network functions to logical nodes is given in Figure 3.9.
Enabling D2D Type 2B (see Chapter 5) network functions are interworking at three
different logical nodes denoted as device, infrastructure node and central management
entity. Functions enabling device discovery are located at devices and infrastructure
nodes. Device discovery is based on measurements that are executed by devices at certain
radio resources where D2D discovery signals are transmitted over the Air Interface (AI).
Responsible infrastructure nodes execute device grouping and resource allocation based
on information about network capabilities, service requirements and measurement
reports of the devices. Network capabilities include options for sharing D2D frequency
resources with the cellular infrastructure (underlay D2D) or partitioning spectrum
dedicated to cellular and D2D (overlay D2D). Discovery resource allocation is prepared
by the infrastructure based on load situation and density of devices. Devices have to
initiate selection between infrastructure or D2D mode (mode selection). The long-term
radio resource and interference management considers allocation of D2D resources
during resource assignment. Multi-operator D2D can be enabled by out-band D2D at
dedicated spectrum resources. In this case, functionalities of a centrally operated spec-
trum controller are needed. In a physical network the central management entity will be
located at central data centers in the transport network whereas logical infrastructure
nodes are to be located in the access network e.g. at Cloud-RAN or D-RAN locations.
As all described network functions operate asynchronous to the radio frames the infra-
structure node functions provide potential for centralization meaning that not all RNEs
located at BS sites need to host D2D detection and mode selection functionalities.
 The 5G architecture 71

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 inter-
action 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 con-
straints 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

103
Number of supported BSs

102

101

Split A, no MUX gain

Split B, no MUX gain
Split B, w/ MUX gain
Split C, no MUX gain
Split C, w/ MUX gain
100
101 102 103 104 105 106 107
BH rates [Mbps]
Figure 3.10 Functional split options and their required BH rates [16].
72 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

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 gain3 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 coopera-
tive algorithms. In this case, functional splits at lower RAN protocol layers are prefer-
able. 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

3
Statistical multiplexing gain in this context refers to the gain achieved by mixing independent, statistical
bandwidth demand sources. Due to their random nature, the sum-rate of the multiplexed demand streams
(effective bandwidth) is lower than the sum of the individual rates of each stream.
 The 5G architecture 73

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 require-
ments 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

Access Aggregation Metro Core

Cloud-RAN

eNB

Small cell

BH node
S-GW or Internet
P-GW

P2P
wireless
p2mp
wireless
Wired
link

Figure 3.11 Illustration of a heterogeneous wide-area deployment [19] including point-to-point (p2p) and
point-to-multi-point (p2mp) transmissions.
74 Heinz Droste, Icaro Leonardo Da Silva, Peter Rost, and Mauro Boldi

Stadium Ring #1 placed on the roof top

Stadium Ring #2 placed on the roof top Macro cell MME S-GW P-GW
Stadium Ring #3 placed on the roof top
Core (local)

SDN

Cloud-RAN

Figure 3.12 Deployment within a stadium [7].

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 deploy-
ments 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 deploy-
ments 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 require-
ments 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
 The 5G architecture 75

benefits, it will be fundamental to provide a compromise between the needed flex-

ibility of communication among the arranged network functions and the number of
standardized interfaces that allow for interworking of multi-vendor equipment.

References

[1] AT&T et al., “Network Function Virtualization: An Introduction, Benefits,

Enablers, Challenges & Call for Action,” White Paper, October 2012, http://portal
.etsi.org/NFV/NFV_White_Paper.pdf
[2] Open Networking Foundation, “Software-Defined Networking: The New Form
for Networks,” ONF White Paper, April 13, 2012, www.opennetworking.org/ima
ges/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf
[3] 3GPP TS 36.300, “Overall description; Stage 2 (Release 12),” Technical
Specification TS 36.300 V11.7.0, Technical Specification Group Radio Access
Network, September 2013.
[4] ICT-317669 METIS project, “Final report on the METIS 5G system concept and
technology roadmap,” Deliverable 6.6, Version 1, May 2015.
[5] NGMN, “5G Whitepaper,” February 2015, www.ngmn.org/uploads/media/NGM
N_5G_White_Paper_V1_0.pdf
[6] ICT-317669 METIS project, “Final report on architecture,” Deliverable 6.4,
Version 1, January 2015.
[7] ICT-317941 iJOIN project, “Final definition of iJOIN architecture,” Deliverable
5.3, Version 1, April 2015.
[8] ICT-317941 iJOIN project, “Revised definition of requirements and preliminary
definition of the iJOIN architecture,” Deliverable 5.1, Version 1, October 2013.
[9] Common Public Radio Interface (CPRI), “Interface Specification,” CPRI
Specification V6.0, August 2013.
[10] Open Radio equipment Interface (ORI), “ORI Interface Specification,” ETSI GS
ORI V4.1.1, June 2014.
[11] M. Olsson, S. Sultana, S. Rommer, L. Frid, and C. Mulligan, SAE and the Evolved
Packet Core, Driving the Mobile Broadband Revolution, 1st ed. Academic Press,
2009.
[12] I. Da Silva et al., “Tight integration of new 5G air interface and LTE to fulfill 5G
requirements,” in 1st 5G architecture Workshop, IEEE Vehicular Technology
Conference, Glasgow, May 2015.
[13] IST-2002–001858 Everest Project. [Online] www.everest-ist.upc.es
[14] M. Johnsson, J. Sachs, T. Rinta-aho, and T. Jokikyyny, “Ambient networks:
A framework for multi-access control in heterogeneous networks,” in IEEE
Vehicular Technology Conference, Montreal, September 25–28, 2006.
[15] 3GPP TR 36.842, “Study on Small Cell Enhancements for E-UTRA and
E-UTRAN – Higher layer aspects,” Technical Report TR 36.842 V12.0.0,
Technical Specification Group Radio Access Network, January 2014.
[16] ICT-317941 iJOIN project, “Final definition and evaluation of PHY layer
approaches for RANaaS and joint backhaul-access layer,” Deliverable 2.3,
Version 1, April 2015.