5GIC details 5G architecture for context-centric networks

Architecture proposes new protocols to enable “always sufficient” user experience.

5G may require a “disruptive”, revolutionary cellular network architecture, according to a report released by the UK’s premier 5G research institute, 5GIC.

5GIC has outlined the capabilities of a new network architecture – termed the Flat Distributed Cloud (FDC) architecture – in a white paper released yesterday. The paper states that the new architecture is intended to provide the foundation for context-aware networks that provide a user experience that is perceived as always sufficient.

As the name suggests, the architecture flattens the current network hierarchy, invoking a “horizontally distributed cloud model that relies on new user and control plane protocols allied to the implementation of NFV and SDN, with all network nodes equipped with service compute power and storage as well as communications processing”. Although this may sound like other proposals for 5G architecture, the paper says that FDC avoids the “blind adoption of SDN, NFV and Cloud principles… without placing them in the context of some of the very specific challenges of mobile architectures.”

The paper said this combination would allow networks to gain access to, and act upon, new context information as well as to apply new QoS controls.


Context aware networking means that user profiles provide full “5W” (what, when, where, who, why) to the network, with user profiles being selectively enabled for application/network usage using secure certificates issued by the user. Subscriber Data Management (SDM) systems have remained HLR centric to date, but that is envisaged to be extended to support user profiles so that the user may share information selectively with the network in order to improve their user experience. It is proposed that each user will have a User Profile (Upr) that will be extensible in a negotiable manner to provide information keys into new applications and network SON algorithms to improve the network and user experience.


FDC also proposes extending the current RRC (Radio Resource Protocol) into an Common Resource Connection Protocol, CRCP, allowing multiple bearer types from multiple technologies to be combined to support one common, dynamic, virtual connection from a device towards the FDC network. In this manner the FDC network enables the potential to dynamically operate simultaneous multiradio and multi-fixed access technology pooling, on a per user basis (multi-RAT/ FAT).


The FDC also proposes a context-aware user plane protocol (UPc) that allows bearer class negotiation by service description and user context rather than by QoS class request. It will also map the service/context request to available QoS controls that are provided by FDC network elements. To do this whilst also also maintaining control of functions such as charging, policy and lawful intercept, the FDC would include a new protocol called the Met-Data Protocol (MDP).

The paper said that to date, “QoS controls have been seen as either too complex or insufficiently supported on an end to end basis to be workable”. The IETF has “been slightly more successful” in its Differentiated Services Code Point (DSCP) approach although once again a small subset of controls is actually operated in most cases. “3GPP has four generations of experience in setting QoS for mobile networks, but provision and exposure of QoS controls to the device/application has proved poor. So it is proposed here that for 5G, each communications ‘request’ is made more descriptive of the request type, content and performance requires and the network selects the best available QoS controls in the network accordingly.”


The paper said that FDC is similar to the CUPS  (Control and User Plane Separation) architecture evolved from LTE – in which the control and user plane parts of the Serving Gateway and packet Gateway are being separated out into control and user plane node parts. The paper proposes separation of the control and user plane on an end to end basis, with predictive signalling to reduce signalling load.

Although Inside5G recommends a full reading of the paper to get the detail of the FDC proposal, here is an extract that describes the architecture.

proposed FDC architecture

In the FDC architecture all nodes are both 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 that are located at key Datacentres of various sizes according to location type and available transmission support.

The architecture is very close to that of the CUPS architecture evolved from LTE, but the Control Plane nodes are mapped directly to MACRO/Umbrella cells as a single function per cluster of cells called the Cluster Controller (CC) and the user plane nodes are mapped to Small Cells as User plane functions called Cluster Member functions whilst the user operates dual connectivity to both the Control-Plane associated Macro-Cell system per Cluster and the most appropriate User Plane Cell within the cell-cluster. So the FDC approach combines Dual connectivity from 3GPP Rel-12, CUPS from Rel-14 and adds Context awareness and clustering to the architecture approach.

The FDC operates as follows: a user device connects to a Cluster, umbrella Cell, which supports a Cluster Controller (CC) and directly connects to it to setup the network’s communications connection signalling using a contended group connection system. Once the device has a Control Plane communications connection to the cluster at the Cluster Controller it establishes a group NAS (Network Access Stratum) connection to the Cluster at the Cluster Controller virtual node.

The user is then setup a default UP bearer according to their Device/ user profile and mobility (e.g. connect to umbrella id operating with high mobility) by connecting to the most appropriate CM, user plane node functionality. Significant use of a user profile is made to optimise default bearer setup as a dialogue between the User and Network.

The Cluster Member (CM) node provides 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-theair usage.

The architecture assumes an underlying NFV based implementation architecture with a 2-level Orchestration Controller approach. One controller is located at the CC level and one at the inter-CC level. This approach allows algorithms for topology optimisation to operate at the inter-CC level and then direct the periodic re-organisation 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 re-organisation of the clusters and their number and sizes at the inter-cluster topology level to realise Automatic Network Optimisation.