An FDC is a dynamic and distributed cloud based architecture that separates the user and control planes, is flatter than the Long Term Evolution (LTE) network and which could simplify the traditional mobile network.
The FDC employs user and network context information – such as where, when, why, who and what is being requested – as well as the user’s location and type to service requests, using learned intelligence.
The approach looks to employ evolving Network Function Virtualisation (NFV) and Software Defined Networking (SDN) implementations, to address shortcomings in today’s 3GPP based architectures and to connect with and support different Radio Access Network deployment configurations.
The main requirement is that the 5G infrastructure should be far more demand/user/device centric and be capable of delivering ‘always sufficient’ data rates, giving the end user the perception of infinite capacity.
5GIC says a 5G Network architecture should provide such elements as: distributed cloud based services; context aware networking; low latency services; and universal network capability over as large a coverage area as possible.
However, the ultra dense deployment of small cells and massive connectivity requirements of devices/things expected for 5G will place undue loads on the core network nodes in the current long-term evolution architecture.
Virtualised network functions
Virtualisation, applicable to any data plane packet processing and control plane function, can be deployed anywhere in the network and the trend towards virtualisation of core network nodes and subsystems is accelerating.
SDN, meanwhile, makes data networks simpler to manage. Complex control plane functions are abstracted from forwarding elements, simplifying user plane operations by relocating control logic to physical or virtual servers in a data centre. SDN also enables Agile Innovation – operators can program their network in real time and, when deployed with NFV, introduce new services in a matter of hours – and intelligent path management, based on service needs rather than routing configuration. This is important where end users are mobile and bandwidth demands vary.
Mobile systems require IP addressing in a mobile context and the mapping of the network across a flexible cellular system whilst handling soft radio scope and resolution onto a group of Cells or Radio units, whilst maintaining administrative functions.
A recent initiative being addressed in 3GPP starts to blend practical evolution with mobile awareness. In CUPS – Control and User Plane Separation CUPS archi– LTE entities are separated into their constituent User Plane Node and Control Plane Node parts in order to provide more flexibility and scalability, whilst retaining the mobility control enabled by the GPRS Tunnelling Protocol.
In the FDC architecture, all nodes are service and communications enabled with suitable processing and storage. The network is arranged in dynamic virtual cell clusters that are, in turn, overlaid onto hardware clusters located at key datacentres.
While similar to the CUPS architecture evolved from LTE, Control Plane nodes are mapped directly to macro/umbrella cells as a single function per cluster of cells. This is called the Cluster Controller (CC). User plane nodes are mapped to small cells as Cluster Member (CM) functions. Users have connectivity to the Control Plane associated cluster and to the most appropriate User Plane Cell within the cell cluster. So the FDC approach adds context awareness and clustering.
The CC can also provide local CM functionality; for example, where it supports a mobile device travelling at high speed and a user plane function at the macro-umbrella level is more applicable.
The term ‘function’ is used intentionally; these functions are intended to be implemented as soft entities over an SDN/NFV implemented set of equipment across variously sized data centres, allowing the cluster to be reorganised over time according to service evolution requirements, network slicing configuration and demand load. Reconfiguration of this network architecture is envisaged with the suitably named Automatic Cluster Organisation algorithm.
The architecture is envisaged as being implemented across a cloud but, unlike the huge centralised clouds operated by companies like Google, Amazon and Microsoft that are distributed physically according to storage demands, the FDC architecture is distributed according to mobile demands.
The FDC also embraces ETSI’s mobile edge computing initiative, which adds hardware and software resources to enable caching either at the edge of the network or at a point of aggregation across a number of cells in order to provide computing and storage enhancement to the mobile functions. In an NFV/SDN FDC, this means that, when providing user plane service, the CC and CM functions offer local caching and application processing.
FDC operation
The FDC operates as follows: a user device connects to a cluster umbrella Cell, which supports a CC and connects directly to it to setup the network’s communications connection signalling using a contended group connection system.
Once the device has a CP communications connection to the cluster, it establishes a group Network Access Stratum connection to the cluster at the CC virtual node. The user is then set up as a default UP bearer according to their device/user profile and mobility by connecting to the most appropriate CM, user plane node functionality.
Significant use of a user profile is made to optimise default bearer set up as a dialogue between the user and network. The CM node provides user plane (UP) control separately to the Cluster Controller functionality. As this network is context-aware, for fast moving mobiles, connection to the Cluster Controller itself is possible in the UP for this type of user context. Intra-cluster communications connections may be connected or ‘parked’ to minimise connection overhead and then reloaded for UP service. However the signalling connection and bearer connection are managed independently with local network signalling between each instance to minimise over-the-air usage.
The architecture assumes an underlying NFV based implementation architecture with a two level Orchestration Controller approach; one controller is located at the CC level, the other at the inter CC level. This allows algorithms for topology optimisation to operate at the inter-CC level and to then direct the periodic reorganisation of the clusters at the CC orchestration level according to information such as load vs time and user dominant usage type(s) collected at the cluster level. This allows periodic reorganisation of the clusters and their number and sizes at the inter-cluster topology level to realise Automatic Network Optimisation.
The 5GIC aims to demonstrate several context awareness aspects of the FDC in the forthcoming months, as evolutions of the Centre’s 5GIC test-bed.
Author profile:
Gerry Foster is 5G Systems Architect at the University of Surrey’s 5G Innovation Centre