The mobile network evolution towards 5G consists of providing users with new services and better quality of services (QoS). the main aim of the mobile network architecture design is to define all the network elements and their interaction among each other so that the system will operate consistently. The capabilities of user equipments also limit the new services provided by the evolved networks because these devices have limited computational power and short battery life. To extend their battery life, demanding applications will be offloaded to a cloud with the help of mobile cloud computing concept. But, for real-time or delay-sensitive applications, this approach is not suitable as additional communication delay has been added by MCC. Hence, the solution is to incorporate mobile the cloud capabilities at the edge of the mobile network which is a part of network consists of small cell base stations (SCeNBs).
A small cell cloud (SCC) concept is used to represent the idea of computation distributed over the edge of a mobile network. To provide the needed flexibility of future networks, especially for the core network, enablers such as Network Function Virtualization (NFV) and Software Defined Networking (SDN) are to be applied. To accelerate computation and save the energy of the UE, the offloading of computation has been enabled by SCC and MEC from the UE to the (SC)eNBs in the proximity of users. A new general purpose processor and additional memory is included to enhance the (SC)eNBs toward the SCC or MEC.
The design and deployment of a new control entity, known as a small cell cloud manager (SCM), is the major challenge of SCC that on depending on the radio channel, backhaul conditions, required computing power, and status of the SCeNBces, coordinate the computation.
Evolution towards an architecture of future mobile networks
To enable the management of computational resources over the SCeNBces and to get benefit from network status knowledge, there is a requirement of integration of SCM in the existing infrastructure so that the mobile networks will be incorporated with the SCC concept.
Architecture of 4G mobile networks
The access part of LTE-A mobile networks architecture consists of evolved universal terrestrial radio access network (E-UTRAN) and an evolved packet core (EPC) as shown in fig. 2.1. The components of E-UTRAN are eNBs, the SCeNBs, and the UE. The responsibilities of E-UTRAN are:
- scheduling and allocating radio resources
- mobility control
- the encryption of radio data transmission
- enabling connectivity to the EPC
Fig. 2.1. Architecture of LTE-A mobile networks
The EPC consists of a mobility management entity (MME), a serving gateway (S-GW), and a packet gateway (P-GW). All signaling between the UE and the EPC is controlled and managed by the MME. All IP packets among the pieces of user equipment and other IP-based networks are routed and forwarded by the S-GW. The actions related to the QoS and flow management toward other networks are taken by P-GW.
Architecture of mobile networks based on C-RAN
The improvement in the efficiency of control functionality, cost, capacity, and energy consumption has been resulted from the evolution of mobile networks and the users requirements. Hence, there rises the need for cloud RAN (C-RAN) i.e. centralized control is provided to the radio access network. In C-RAN, the control and communication part of eNBs are splitted into a centralized BBU and distributed radio remote heads (RRH), as shown in fig. 2.2.
Fig. 2.2. Architecture of C-RAN
Depending on the centralization level, there is an implementation of the RRH either as a simple transmitter/receiver with no baseband processing so that there is a transmission of a full baseband I/Q signal between the BBU, called full centralization, and the baseband processing is handled by the RRH so that the load of the link between the BBU and RRH can be lowered, called partial centralization. In both cases, the BBU handle the functionalities of upper layer.
C-RAN can improve the performance of the technologies, increase the coverage and capacity of the network with coordinated multipoint (CoMP), multiple-input multiple-output (MIMO), or non-orthogonal multiple access technologies along with the cost and energy efficiency.
Architecture Enclosing SCC with Centralized Management
Integration of virtualized computing resources into the SCeNBces and a new entity has been incorporated by the architecture of mobile networks with SCC so that cloud interoperability can be controlled and maintained and there is an interaction with the E-UTRAN and EPC. the available computing resources are coordinated with respect to the radio channel and backhaul conditions by using this entity, named as SCM. Computing resources are also allocated by the SCM in order to process the users applications over the SCeNBces.
The VMs are used to virtualize these computing resources. The deployment of SCM efficiently will minimise overhead of supplementary protocol data, complexity of implementation, impact on LTE-A, deployment cost, and operation and maintenance. The placement and interconnection of centralized SCM with LTE-A architecture has been shown in fig. 2.3.
Fig. 2.3. Integration of the centralized SCM into a mobile network
Option 1 is to place SCM directly in the EPC. The main advantage of this approach is that the computing power of all SCeNBces connected to the network has been exploited. In this approach, all signalling will be exchanged through the EPC as the majority of the signaling required for offloading management is originating from the SCeNBs. Option 2 is, SCM will be deployed close to the user i.e. within the radio access network close to the SCeNBce. A constrained computing power of subordinated SCeNBces is the disadvantage of this approach. Moreover, the signalling overhead between the network edge (E-UTRAN) and the EPC can be reduced significantly when SCM is located closer to the user. Hence, the SCC exploitability and deployment can be limited as both of the options mentioned above introduce some drawbacks.
Computation in SCC with distributed management
The drawbacks of centralized SCM can be minimized by proposing two new architectural options:
In H-SCM, the SCM is physically splitted into two parts: a local SCM (L-SCM) and a remote SCM (R-SCM) as shown in fig. 3.1.
Fig. 3.1. Deployment of the L-SCM and R-SCM for hierarchical SCM
The L-SCM is placed near the SCeNBces. Several SCeNBces can be coordinated by the L-SCM in its vicinity due to a need for proximity between the L-SCM and the SCeNBces.
Computing requests of relatively low complexity can be handled by L-SCM. The CPUs for SCeNBces will also evolve with the evolution of CPUs in smartphones due to which the computing power of several SCeNBces will be much higher than that of smartphones. If nearby SCeNBces offer the requested computational power, low signalling delay will be allowed by L-SCM to handle the tasks in proximity to UE.
A principle of centralized SCM is followed by R-SCM which is placed in EPC.The computing power of all SCeNBces connected to the EPC can be exploited by R-SCM.
An application running on the UE generate the request for computational offloading as follows. In first step, a decision has been taken that whether to offload an application to the cloud or not by using conventional offloading decision algorithms. If result is positive, the evaluation is done by L-SCM if the given task can be handled by its subordinate SCeNBces. Then, a cluster of computing resources can be created by the subordinate SCeNBces.
One or more SCeNBces can be selected and assigned by the L-SCM to participate in the offloading job, if there is sufficient computation power of the subordinate SCeNBces within the cluster. Otherwise, according to the availability of resources, the R-SCM distributes the computation among L-SCMs and their subordinated SCeNBces. There is a continuous collection of information on the network status either in proactive or reactive manner to evaluate the computing capabilities of the subordinated SCeNBces.
Virtual Hierarchical SCM
A relatively high cost of deployment of L-SCM is the limitation of H-SCM. Hence, VH-SCM can be introduced in order to reduce the high cost of H-SCM. In VH-SCM, the role of the L-SCM is directly virtualized into the SCeNBces. Hence, the entire L-SCM’s functionality is distributed among the VMs of the participating SCeNBces as shown in fig. 3.2.
Fig. 3.2. Allocation of resources for SCM
VL-SCM is the virtualized L-SCM which is a piece of code running on the virtualized resources of the particular SCeNBce. The advantage of this approach is that new hardware is not needed to be installed. The VL-SCM’s functionality resources are allocated within resources normally dedicated to the computation of the offloaded applications by users as shown in the fig. 3.3
Fig. 3.3. Virtualization of the L-SCM in SCeNBce for VH-SCM
Processing power for the users computation remains low so this will be the major drawback of this solution. Proper SCeNBce within a cluster with enough computational resources will be selected to minimize this impact. There is unexpected turnoff risk or the malfunction of the SCeNBce hosting the VL-SCM risk if the VL-SCM is allocated to a SCeNB owned by a user. In order to avoid this risk, elect one SCeNBce as the VL-SCM and other cell as secondary VL-SCM.
A specific multicast address is used for communication from the SCeNBce to the VL-SCM as its destination address. In case of failure, the primary function is performed by the backup VL-SCM and selection of new backup VL-SCM is done. The functionalities of the R-SCM should be placed in the BBU and the functionalities of the VL-SCM should be placed in the RRH so that the proposed VH-SCM has been integrated into the mobile network architecture based on the C-RAN concept. In this case, the control functionalities will be shifted near the user that is to RRH from the BBU.
NFV and SDN
An initiative on NFV has been started at the end of 2012 by the network operators. There are one or more virtual machines which are running different software and processes so that custom hardware appliances should be replaced as shown in fig. 4.1.
Fig. 4.1. NFV Framework
To provide meaningful services to the customer, multiple VNFs are to be used in sequence. An orchestration framework is required by NFV so that proper instantiation, monitoring and operation of VNFs and Network Functions should be enabled. Software implementations of network functions (VNF), hardware that is denoted as NFV Infrastructure (NFVI) and a virtualization management and orchestration architectural framework are included in the NFV framework. Hardware accelerators are included in some NF to realise real-time requirements. The computation intensive and time critical tasks are performed by the accelerators. This will offload the traffic from NFVI as well as ensure adherence of latency requirements. Reduction of capital and operational expenditures and increase in speed of time to market are the most significant benefits of NFV. Because of portability of VNFs between different vendors these benefits can be leveraged.
Another important enabler for 5G future networks in addition to NFV is SDN. Control and data planes separation, logical centralization of network intelligence and physical networks abstraction from the applications and services by standardized interfaces are the basic principles of SDN. A control layer is the layer on which the network control is concentrated and there is a distribution of network devices, that handle data plane functionalities, within infrastructure layer network topology as shown in fig. 4.2.
Fig. 4.2. SDN Architecture
To provide the needed flexibility, scalability and service-oriented management, both concepts will serve as key enablers in 5G.
Integration of LTE and new air interface to fulfill 5G requirements
Inter-connected core networks or a common core network
Each RAT consists of RAN protocol stack and core networks where inter-node interfaces are used to link the core networks. There is an integration of UTRAN and E-UTRAN in the current solution. For integration between 4G and 5G, there is a need provide seamless mobility and transparent connectivity which is quite challenging. Therefore, both LTE and the new air interface use new 5G core NFs in order to reduce handover latency and to provide seamless mobility.
Common Physical layer
The physical layer of LTE is based on OFDM that provides services to MAC layer and the mapping of transport channels to physical channels can also be handled. Transmission based on OFDM will be a good baseline for new air interface. Hence, it is very challenging to introduce a common physical layer.
Common Medium Access Control
The MAC layer is responsible for providing services to the RLC layer. There are differences in the time and frequency domain structures for LTE and the new air interface due to which realization of common MAC layer is a big challenge.
Common RLC, PDCP and RRC
The PDCP layer gets services from the RLC layer in case of LTE. Synchronicity between PHY, MAC and RLC will be required to a appropriate level due to which common RLC layer realization is becoming a challenge in case of the deployment of new air interface.
Both control and user planes use the PDCP layer. As there is no need of synchronicity with the lower layers, this does not impose any problems for a common PDCP layer.
The control plane functions are basically performed by the RRC layer. Realization of this layer is not creating any problem as RRC functions do not require synchronization with functions in lower layer
Download full document 5g Architecture in PDF
Check our course on 5G Architecture