Components of a 5G architecture

The devil is in the detail, they say, and when it comes to 5G there is a lot of detail still to be thrashed out.

Quite how much detail is evident in the latest whitepaper – 5G RAN Architecture and Functional Design – delivered by 5G-PPP’s METIS-II.

The paper raises a lot of questions, but can come to very few definitive answers as yet, although it does propose a number of likely answers to each question. These include new AI design, new network and RAN interworking interfaces, and a new connectivity state.


Just as a scene-setter and a reminder, here are some of the things the 5G RAN will have to do – and therefore all of these things will have to be enabled within 5G’s architecture. A 5G RAN should:

    • Be able to scale to extremes
    • Support Network Slicing
    • Be Software configurable
    • Support multi-connectivity (inter-node, inter-air interface, and network-controlled device to device)
    • Maximally leverage centralised processing, but also operate well in case of distributed base stations with imperfect backhaul/fronthaul infrastructure
    • Some 5G devices should be able to flexibly act as a network node as well, one example being self-backhauled, possibly nomadic access nodes
    • The 5G RAN design must be future proof, i.e. it should enable an efficient introduction of new features and services (e.g. by minimising the spreading of signals over radio resources and facilitating the introduction of new physical channels) and guarantee backward-compatibility of devices in future releases
    • Be energy efficient with a wide spectrum range


A first key question the white paper asks is how far different air interface variants, which may well be tailored for specific bands, can be harmonised towards a single Air Interface protocol stack. If you can’t do this, then equipment is much more expensive to build and more complex.

METIS-II is currently investigating three ways to come up with an answer to this.

  1. PHY layer harmonisation
  2. MAC layer harmonisation supporting usage of different waveform families on the PHY layer.
    MAC layer aggregation has the potential to enable tighter integration features like cross-carrier scheduling, but may be challenging: for example in the context of PHY layers with very different frame structures. Also, User Plane aggregation on the MAC or RLC layer would typically only be possible in co-located deployments and/or deployments with good backhaul quality.
  1. Scaling of a single waveform across all the different 5G use cases.
    There could be support for a single overall waveform with different numerologies, or there might be coexistence of different waveforms, such as OFDM and FBMC. The obvious issue here is compromise: if air interfaces are designed to meet certain use cases or performance objectives matched to certain spectrum bands, then a single waveform will have to be traded off against extremes at either end.

An added issue is to aggregate LTE-A evolution radio and new 5G air interfaces. With one common radio resource control for the control plane, user plane aggregation of LTE-A evolution and new 5G air interfaces on the PDCP level so far appears to be the most viable option.

The paper says, “Ultimately, it is clear that the final choice of a particular 5G AIV (Air Interface Variant) landscape has to be based on a careful trade-off between the potential benefits of a large extent of harmonisation (e.g. from standards and implementation complexity point of view) vs. the potential performance benefits of AIVs that are comparatively more highly specialised for certain services, bands and cell types.”

So – on the issue of how to include different air interfaces in a single design – still tricky.


The 5G RAN will need to be able to support network slicing – where multiple logical networks are deployed on a common physical infrastructure. That will mean a 5G RAN will be tasked with acting with considerably more “intelligence” than its 4G counterpart. That, in turn means that any 5G architecture will need to provide a means of enabling:

  1. More QoS for traffic differentiation
  2. Extensive resource reuse, including radio resources
  3. A RAN that is slice-aware
  4. The provision of slice protection, so events on one slice do not affect another, with setup and management being slice-specific
  5. Performance monitoring solutions (e.g. counters, traces and KPIs) need to be aggregated per slice to verify the fulfilment of SLAs and/or properly operate the different businesses associated to different slices.

All this is work to be decided – but it’s notable that the need for monitoring and assurance is being considered at the design phase of 5G, rather than as an adjunct.


Another architectural consideration is the relationship between the core network and the radio network. METIS-II is considering that 5G will mirror the current structure, with a couple of amendments. So the paper envisions a logical split between core network and RAN, with 5G and LTE-A sharing a common interface between RAN and core, as they also have a common control plane. However, alternative core network/RAN splits and/or cross layer optimisations are currently being studied. To give one example, the project is investigating the design of RAN-based paging solutions to address densified deployments and a new connected state optimized for inactivity periods.


The white paper points out that current interworking (for instance between 3G and 4G) relies on core network signaling managing things like handovers, with semi-independent resource management for the different access technologies. In 5G, a RAN level integration (along the lines proposed above) would go far beyond the existing interworking between access technologies. That  would means that different accesses would, instead of being allied to specific core networks as now (PSC, EPC etc) could benefit from common 5G core network functions and therefore from a common core network/RAN interface. METIS-II labels this new interface S1*. It will have to support:

  • end-to-end (E2E) Network Slicing where each slice may have its own set of core network functions
  • new 5G services with diverging requirements where core functions can be optimised for a specific service,
  • enhanced multi-RAT integration with common core network functions where some could be designed to be independent of the access
  • Potentially new User/Control Plane splits in the 5G core network (designed to follow an SDN/NFV-native architecture)
  • A new “Connected Inactive” state, optimised for battery savings but enabling a fast transition to connected state (see below).

Aside from integration within the 5G air interface, another evolved interface may emerge to facilitate the integration of new 5G air interfaces with evolved LTE-A. Within the RAN, METIS-II initially envisions a new inter-node RAN interface, called  X2*. This interface would provide features such as:

  • Inter-node multi-connectivity and mobility among the multiple carriers (such as mmWave and lower frequency variants
  • Inter-node multi-connectivity and mobility among the new 5G air inerface and LTE-A evolution.

Another novel aspect of the X2* interface is that beside supporting distributed deployments it should also leverage from centralised ones, e.g. by enabling the control of multiple synchronous functions (RLC/MAC/PHY) by centralised asynchronous functions (PDPC and/or RRC) that could possibly be implemented in a centralized cloud.


Given this integrated RAN, with a common core, all supporting network slicing – a key challenge in 5G is how to dynamically assign services to the most suitable bands, air interface variants, communication modes and the radio resources. Further, each network slice can have specific requirements for the radio part (e.g. guaranteed service levels in terms of delay) and restrictions (e.g., wireless transmission only in a dedicated frequency band).

Not only that, but resource management in a “sliced” network goes beyond just the radio. In this respect, METIS-II extends the notion of a resource beyond conventional radio resources towards capabilities such as processing power, memory capacity and energy budget.

The conventional use of resources can also span new dimensions, for example unlicensed bands, which can enable additional degrees of freedom provided that proper interference coordination is achieved.

So METIS-II asks the following:

  • Which changes to the X2* interface will be required?
  • Which particular PHY/MAC features may be needed to support resource management in 5G?
  • Which mechanisms will be required to support QoS management in 5G with relation to bearer, flow management and related granularity?
  • How will the Network Slicing concept impact the overall resource management of the system comprising inter-slice and intra-slice resource management schemes?
  • What will be the role of different protocol stack layers for resource management in 5G?


One potential change in 5G is the protocol stack layer on which traffic steering is performed. In existing systems, the assignment of services to radio access layers and cells takes at the RRC-level. Additionally, a device may be served in multi-connectivity within a radio technology (e.g., LTE Release 12 dual connectivity), where traffic is then further steered on PDCP level to the different radio legs.

In 5G, considering more stringent service requirements, more degrees of freedom and larger radio dynamics, METIS_II proposes: “It may be beneficial to perform traffic steering further down in the protocol stack, e.g. on RLC or MAC layer, and hence on a faster time scale and thus overcoming the semi-static and time-consuming bearer modification in legacy systems.”

The architectural impact is to use the Policy and Charging Enforcement Function (PCEF) to define QoS Class Identifier (QCI) characteristics for different services. The traffic steering framework resides in the RAN and “translates these Air Interface-agnostic QoS metrics to Air Interface-specific ones, based on the real-time feedback received from the Air Interfaces”. This feedback could for instance contain information such as radio conditions and radio resource utilisation values – specific to the Air Interface.

In other words, the RAN itself is providing the information upon which steering takes place, based on overall quality identifiers provided from the 5G core network.


METIS-II is proposing a new state called “Connected Inactive” – to go alongside the Connected and Idle states.

As its name suggests, this is a state that is designed to keep a device in a more near-ready state – thereby reducing signalling and chat on the network. It does this by not discarding previously exchanged information from an inactive device, so that UEs in “Connected Inactive” state keep parts of the RAN context. In addition to storing the RAN context, signalling is reduced by allowing the UE to move around within a pre-configured area without notifying the network.

Moving from Idle to Connected will mainly happen during an initial first access to a network, and is not expected to occur as often as in LTE-A. However, transitions from “Connected Inactive” to “Connected” are expected to occur often and, accordingly, should be optimised as a lightweight and fast transition. This is achieved by keeping the Core Network to RAN connection alive during inactivity periods and reducing the amount of RRC signaling needed to resume an existing inactive connection. It may also reduce control plane latency since the transition doesn’t require the setup of the Core to RAN interface nor the whole RRC connection setup procedure.