Six talking points for architecting the next wireless generation

The next wireless generation – 6G – is still in the early stages of both discussion and applied research across our industries.

While 6G is still a destination that may be far ahead of us, it is important to already now outline some key principals to explore, including how we should architect the future network and which requirements it should meet.

Beginning this journey today will allow us to set the scene for this decade’s 6G standardization process and ultimately prepare both existing 5G and future 5G Advanced networks for the eventual evolution to commercial 6G networks beyond 2030.

In this blog we have addressed six key points when it comes to designing the future 6G system.

1. A simplified architecture for 6G

One of the overall goals when designing the architecture for 6G networks is to enable the smoothest possible evolution of today’s and tomorrow’s 5G networks into the next eventual generation with all its new features (of course, all yet to be defined).

There are many learnings we can take from the recent and ongoing introduction of 5G networks. For example, one perceived challenge has been the specification of multiple deployment options (that is, user equipment (UE) connectivity options), including both non-standalone and standalone.

There were several drivers for supporting a non-standalone 5G, including enabling existing low-band LTE coverage for new mmWave 5G deployments. However, the specification of multiple deployment options also introduced complexities to the 5G market evolution. In many cases, this has hampered the network transition to the only real deployment option capable of leveraging the full promise of the 5G system: 5G core networks and full 5G standalone.

For future networks, it’s important that the industry learns from this and focuses on standardizing and deploying a single 6G architecture and migration track, avoiding multiple connectivity options and unnecessary complexity.

2. Future-proof 5G core will make a simpler migration possible

The upcoming 6G standardization aims among other things to define a new 6G standalone radio access technology (RAT) that enables the capabilities and features needed to meet advanced use case requirements beyond 2030.

When it comes to future 6G core networks, we believe an evolution of today’s 5G core networks is the most optimal path to take. The reason for this being that 5G core is specified in a very future proof way and allows 5G core capabilities such as exposure, time sensitive- and reliable communication, network slicing, multi-generational inter-working, and roaming to be utilized from day one of 6G rollout.

This would also still allow the possibility to introduce new or modified components in 5G core to support new 6G capabilities. From a migration point of view, this will also make it easier to deploy 6G as a standalone RAT and create a smooth migration from 5G standalone. This applies to CSPs of course, but also industries and enterprises that will be able to leverage 5G standalone deployments.

The 6G RAT should target new spectrum bands available in this time frame, but it should also be optimized for the existing spectrum grid used by 5G networks. This can enable CSPs to utilize 6G features in existing bands, as well as combine existing and new bands using 6G spectrum aggregation to support extreme 6G bitrates, coverage, and capacity.

To utilize existing bands occupied by 5G traffic, it will be critical that 6G offers ample support for 5G/6G spectrum sharing, making it possible for 5G and 6G to efficiently share spectral resources. In this regard, a mechanism similar to today’s LTE/5G Dynamic Spectrum Sharing (DSS) can be utilized. However, with 6G expected to support lean carriers with very low overhead when there is no or little traffic, it can be assumed that 5G/6G spectrum sharing will be significantly more efficient.

3. A simpler architecture provides many benefits and should be the goal

The next-generational architecture should be simpler and more efficient compared to earlier architectures, part of which will be achieved by reducing the number of connectivity options as we discussed earlier.

This will help to speed up the time to market for new 6G features (by enabling faster standardization, implementation and testing), as well as ensuring that 6G network implementation and deployment can benefit from fast-evolving IT tools and frameworks (avoiding lock-in with telco-specific solutions). Other clear benefits include simpler system integration and improved network robustness thanks to fewer moving parts or sources of errors.

To achieve this simplification, it’s important that our industry aligns on key multi-vendor interfaces, UE connectivity options, and well-understood network requirements (e.g., service layer support, security, mobility, deployment, and legacy inter-working) prior to the start of 6G standardization. This alignment will also help to reduce the number of options in the network as well as the risk for market fragmentation. Some of the key identified interfaces so far include roaming interfaces, the core- and radio access network (CN-RAN) interface, RAN internal interface for mobility, lower layer split (LLS)/fronthaul, and interfaces for management, exposure and towards the underlying execution environment.

Above: 6G network architecture overview – some key interfaces

4. Ensuring flexibility will require a three-pillar approach to design, build and operation

An effective mobile network is the product of three different kinds of architectures: a standardized functional architecture, an implementation architecture, and a deployment architecture. Together, these architectures contribute to how the network is defined first on an abstract level, how it’s built, and how it’s eventually designed, configured, and operated.

Here is a summary of each architecture:

• The standardized functional architecture defines the abstract entities, the functions they perform, their services offered to other entities, and the procedures i.e. how the system works.
• The implementation architecture guides the development process with the choice of development tools, internal structures, and software lifecycle management i.e. how the system is built.
• Lastly, deployment architects of network operators have to make concrete plans on network design, configuration, and operation within the capabilities of the available implementations i.e. how a network is created and operated.

Above: Three architectures that comprise a mobile network

The three architectures are inter-related, but there exists a good split of responsibility between them. Most technical decisions related to a mobile network have a best place in one of these.

The standardized functional architecture sets what the implementation needs to do, while allowing a range of implementation choices. Consequently, the implementation architecture sets the boundaries in which deployments can operate. In this process, it is smart to delay decisions as much as possible, for example, to leave a lot of flexibility for the deployment architects. The functional architecture should not be dependent on a specific implementation or specify a specific deployment architecture, to allow decisions in those domains at the design and deployment phase.

The implementation should be flexible to allow as many kinds of deployment as possible. It is largely influenced by the rapid development of cloud and related technologies. Of course, for interoperability, the standardized functional architecture must be specific enough, but it is important to intentionally limit its scope.

Finally, it is important to note that relations are not unilateral between the three architectures. Naturally, there is a lot of operational and implementation experience fed back to the functional architecture, for example.

The 5G standard denotes detailed and explicit support for many implementation and deployment options. For example, a rich set of binding options are available for network functions (NFs), NF sets and NF instances. Another example is communication between NFs, which can be direct or indirect. Any or all of discovery, initial selection and re-selection can be delegated to the Service Communication Proxy (SCP) or not. Each of these decisions having deployment, configuration, and performance consequences. This situation is less than ideal as it makes the resulting system unnecessarily complex.

When thinking about the 6G functional architecture, it is important to keep the other two architectures in mind, as well. Specifically, the following points are recommended.

• Abstract: In general, the functional architecture, being the slowest to change, should focus on the application logic and dictate as little implementation and deployment as possible. This would speed up potential innovation.
• Cloud friendly: We should promote solutions that work well with cloud platforms. For example, given that the deployment architecture determines where functions are deployed, the functional architecture should be location agnostic. This includes the notion – or lack thereof – of single or multiple-site services. Another example is instance bindings which expose the implementation of a service, typically hidden in modern cloud applications.
• Platform agnostic: Since there is no standard cloud platform, the functional architecture shall allow support for as many kinds of cloud infrastructure arrangements.
• Management separation: The management standards should completely break away from the notion of a node and focus on logical NFs. These should be de-coupled from the hardware and software implementing them. This allows the in-service upgrade of the software without seeming impact on the NF, but also allows changing the behavior of the NF.

5. How to architect a generation that delivers close to zero-touch autonomy

The configuration of the network at large, its services and individual network functions should also be decoupled from the detailed deployment, for example where to instantiate a given function and how many replicas would be needed at each location.

When it comes to future 6G systems, we also expect a greater diversity of services, both public and private. To handle this efficiently, the 6G system should be autonomous to a large extent, where humans define operational requirements and the network has the intelligence to identify and take needed actions, such as making detailed configurations. Based on observed data, the system would also adapt to changes and learn over time to optimize performance.

There are three main aspects that the network should support to achieve this.

Firstly, we introduce intents to configure the network and its services. These are formal specifications as to what should be achieved in the networks and provide means to prioritize in situations where resource constraints would impact performance. The network should operate autonomously to fulfil all intents in the best way, based on the current situation and learned behavior. The intents originate from different sources such as service level agreements (SLAs) for customer services or CSP policies for optimizing energy consumption. They are also used between systems, forming a hierarchy of intent management functions (IMFs) with specific scopes in terms of e.g. network domain (RAN, transport, etc.) or geographical/administrative domains as shown in the figure below.

Intents decouple the requirements as to what needs to be achieved from the procedures, actions and internal parameters that are needed to fulfil those requirements. As an example, let’s say that you have a RAN scheduler with four different parameters to be set, impacting throughput and latency for a specific service. With intents, you would set the required throughput and latency and not the four implementation-specific parameters. Then, it can be replaced with a better algorithm using seven parameters, but still controlled via the throughput and latency as before the change.

Secondly, the network should support intelligence everywhere where it is needed. This includes transforming the set of global, high-level intents into lower-level intents and in the end detailed configurations. But we also expect AI algorithms to complement or replace existing procedures and optimization algorithms due to their ability to learn from actual network performance and adapt to local conditions and observed patterns. It should also be possible to execute AI workloads wherever it makes sense based on a cost-benefit analysis. Therefore, AI execution and training environments need to be available throughout the network. When the number of AI models in the network grows, their lifecycle management needs to be fully automated, deciding e.g. which model version to use for execution and where and when to train model. Models may require data originating from several layers and network domains, which may imply that layer and domain borders blur.

Thirdly, a distributed data infrastructure is needed to support the aspect of interconnected intelligence everywhere. Executing and training AI models wherever it is most beneficial requires access to timely and relevant data at any location. Sometimes data would be transferred centrally for processing, in other cases it is better to keep the data in place and process locally. Several factors impact this choice. Data may be bound to a location due to legal constraints, or the volume of data could make it too costly to transfer. Network functions also need to support more flexible observability, only collecting data when needed for e.g. training and analysis.

Above: Future 6G networks will support three main aspects to realize mostly autonomous operation: a hierarchy of intent management functions (IMF), intelligence wherever it’s needed (red dots in the illustration), and a common distributed data infrastructure.

6. Exposure and aggregation will be key to securing innovation and business scale

6G networks will expand on the innovation platform that is being established by 5G. This allows application developers to get easy access to application programming interfaces (APIs) exposed by the network. These APIs enable the inherent network capabilities to be leveraged beyond communication services, such as device location and management, security, sync, sensing, and quality of service (QoS).

Based on the richer set of network capabilities, more complex services with value add can be offered in the network ecosystem that are more tailored to the needs of applications. But beside the content of services, new levels of quality of service should also be offered that allow networks and applications to inform each other about predicted changes and service needs. Connected to this, more complex service layer agreements (SLAs) should be available and possible to update dynamically.

From the CSP’s (or application’s) viewpoint, network services are needed irrespective of where a user is located at any given moment. The role of the network platform should therefore also be to aggregate services across multiple available access types e.g., Wi-Fi, satellite, and cellular, as well as across multiple 6G networks – all to ensure smooth and efficient service delivery. This functionality can be taken by the network or by a separate aggregator, which in turn can be a federation of networks or a separate service provider.

The 6G architecture thus needs to support deeper interactions between the network and stakeholders, creating more business opportunities in a larger ecosystem. Networks should be able to deliver in several different scenarios, such as full provider towards enterprises and industries, directly towards CSPs, as a component to be aggregated towards global scale applications, and still as a direct CSP to the end user.

Above: The business and technical relationships across the network ecosystem

7. Take away

6G is still a destination that is ahead of us, but it is important to already now outline some key principals to explore. In this blog we have addressed six key points when it comes to designing the future 6G system.

In summary

• It is important to have a single 6G architecture and migration track to avoid multiple connectivity options and unnecessary complexity for a smooth 6G introduction.
• The future 6G core networks should be an evolution of today’s 5G core networks with the possibility to support new 6G capabilities. This will also make it easier to deploy 6G as a standalone RAT.
• To enable openness and minimize time to market it is important that the industry align on key multi-vendor interfaces.
• The standardized functional architecture should be cloud friendly, platform agnostic and allow for management separation to enable freedom of both implementation and deployment.
• The 6G system should be autonomous to a large extent where the use of intents, data and AI will enable efficient management of many different services.
• 6G networks will expose services on multiple levels where application developers can get easy access to exposed network APIs and hence, be an innovation platform for the future.

Continue the journey to 6G with us

Learn more about our research journey to 6G

Visit Ericsson’s future network architecture page

Read Ericsson’s 6G white paper: Connecting a cyber-physical world

Read Ericsson’s white paper: Defining AI native: A key enabler for advanced intelligent telecom networks

Blog: Find out the nine important takeaways from early 6G research

Blog: Learn more about the role of cognitive technologies in the end-to-end 6G architecture

Blog: Learn more about Hexa-X and the foundation it has laid for 6G’s end-to-end architecture