Skip navigation

Enabling intelligent transport in 5G networks

The evolution toward 5G mobile networks is driven by the diverse requirements of a multitude of new use cases in the areas of enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC) and massive machine-type communications. Along with a demand for lower costs, these drivers have led to the development of split architectures for the RAN to support multiple deployment models. Since the transport network’s role is to connect all the pieces of the RAN and the mobile core network, optimal performance in 5G scenarios will require high levels of intelligence, flexibility and automation in the transport network.

Ericsson Technology Review logo

March 21, 2018

Authors: Stefan Dahlfort, Antonio De Gregorio, Giovanni Fiaschi, Shahryar Khan, Jonas Rosen­berg, Tomas Thyni

Download pdf

BBU – baseband unit
BPF – baseband processing functions
BSC – base station controller
CO – central office
CPRI – Common Public Radio Interface
CU – centralized unit
DU – distributed unit
DWDM – dense wavelength division multiplexing
eCPRI  – evolved CPRI
eMBB – enhanced mobile broadband
ERAN – Elastic RAN
GW – gateway
Obs  – observability
O&M – operations and maintenance
ONAP – Open Network Automation Platform
PE – provider edge (router)
QoE – quality of experience
RBS – radio base station
RESTCONF – Representational State Transfer Configuration
RF – radio functions
RNC – radio network controller
RRU – remote radio unit
RRU-BF – remote radio unit beam forming
RU – radio unit
SBH – self backhauling
SDN – software-defined networking
SDNc – SDN controller
SLA – Service Level Agreement
SW – switch
SW/R – switch/router
TCO – total cost of ownership
TIF – transport intelligent function
URLLC – ultra-reliable low-latency communication
µW – microwave
VPN – Virtual Private Network
VRAN – virtualized RAN

At a high level, it is clear that network operators need to continuously look into new revenue streams, faster deployment of required transport connectivity and new consumer services to lower total cost of ownership (TCO). Together with RAN and mobile core networks, transport networks need to evolve to provide the desired level of flexibility in service offerings, simple and agile service configurations, and support for new operations models and cross-domain orchestration that are expected in 5G.

New revenue streams are always difficult to predict, but greater automation can reduce opex, particularly if it enables more intelligent interaction between the RAN, the transport network and the mobile core. Network slices that are supported in a well-coordinated way across RAN, mobile core and transport networks will be able to provide improved life cycle management of services on an end-to-end basis [1]. This is particularly relevant for 5G, but valuable for 3G and 4G networks as well.

The latest demands on the transport network come from areas such as increasing RAN and mobile broadband service capacity, new 5G-enabled services (such as those in the use cases presented below), and the dynamic deployment flexibility of the 5G RAN split architecture, with its tight transport characteristics. These characteristics are especially manifested in the fronthaul portion of RAN transport (in other words, from the DU to other DUs and to the centralized unit (CU) control and packet processing parts in Figure 1), where the latency and synchronization requirements are very challenging. Enhanced automation capabilities in the operations and management domain represent a key requirement to meet these challenges.

Transport network solution for 5G: architectures and protocols

5G RAN’s deployment flexibility and service require­­ments demand much greater control and knowledge of the transport network resources and characteristics compared to previous generations. The increasingly flexible and dynamic behavior in Elastic and virtualized RAN also requires the ability to dynamically add or remove transport connectivity. This is important in the mobile-centric access aggregation part of the network to maintain and improve RAN performance. It is also important for user services, where the positioning of the mobile core becomes critical, or when a new service is launched using mobile core resources at a different site.

The need for flexibility and the above requirements will be a major opex driver in the transport network unless it is fully automated. This is especially true in the mobile-centric part of the network. To overcome this challenge, we have used software-defined networking (SDN) along with an intelligent application, the transport intelligent function (TIF), to design what we consider to be an optimal 5G transport network architecture.

SDN is one of several possible technical solutions to achieve a higher level of automation. However it is achieved, more automation will be required in the near future. Today many network (RAN, transport) operations, such as port and traffic flow configurations, are done manually – that is, by means of a network operations person inserting commands or using graphical user interfaces. While this has been doable (though not always so efficient) in earlier generations, the increased ability to configure and optimize in 5G will make manual operations inviable going forward. The use cases below further illustrate this point.

Our optimal 5G transport network is built as a self-contained infrastructure underlay with an SDN-controlled overlay for a variety of RAN and user services. The distributed control plane in the underlay maintains the basic infrastructure and handles redundancy and quick restoration in case of network failures. The service and characteristics aware overlay is handled by the SDN controller with the TIF application, and this creates a dynamically controlled and orchestrated transport network that requires minimum manual interaction. In other words, the underlay network described here handles the infrastructure connectivity and the network overlay handles the services running on top of the underlay.

The automation focus of the overlay relates to the establishment of initial and dynamic connectivity and is based on requests from the TIF, which is a RAN-aware application [2]. It is also the responsibility of the TIF application to collect and ensure appropriate transport characteristics for different RAN connections as well as user services.

Figure 1: Transport network architecture. The color coding indicates the four different domains: RAN, Transport, Mobile core, Control and observability, and Management and orchestration. TIF represents a cross-domain function between RAN and Transport (the latter via the Transport control and observability).

Figure 1: Transport network architecture. The color coding indicates the four different domains: RAN, Transport, Mobile core, Control and observability, and Management and orchestration. TIF represents a cross-domain function between RAN and Transport (the latter via the Transport control and observability).

Automation application framework

Network automation in the context of transport is a broad area that includes concepts like zero-touch and self-optimizing networks, so there is a need to clarify what exactly we mean when we use the term. Ericsson is keen to define a framework with regard to automation. While our definition is in line with ongoing industrial initiatives, it can also provide unique building blocks from the RAN and transport interaction perspective [3]. Defining a transport automation framework is an important step.

An automation application framework provides the required flexibility of connectivity in the various RAN deployment scenarios. This framework defines the platform for lightweight applications to be developed on top. The following key components are used:

  • cross-domain communication for real-time notifications/events and service request
  • network and service observability function
  • performance-aware topology manager
  • path computation and optimization function
  • network and service logic interfaces to control layer (SDN controller, for example) and to management and orchestration system
  • interface to network observability aggregator function

It should be noted that some of these components are not exclusively used by the TIF. While the architectural details are outside the scope of this article, it is worth mentioning that the automation framework outlined here has been designed with the Open Network Automation Platform (ONAP) in mind.

Transport intelligent function

While the control layer provides an abstract view of the transport network and enables its programmability, the intelligence to decide how to optimize/reconfigure the network is provided by the TIF. The TIF utilizes the network programmability features offered by the control layer and automation application framework, and enables the automation and optimization of the various required inter-5G-network connectivity cases.

A cross-domain communication bus is used to autonomously receive connectivity requests from the RAN. The TIF receives these requests via this bus and processes them together with performance-aware topology data and a pre-configured set of policies (retrieved from manage­ment and orchestration systems). To ensure the optimal actions are taken, the TIF continuously requests insights from the observability function, which, in turn, retrieves its status and performance information from the network via the control layer. This information enables the TIF application to decide, at any time, how best to automate, optimize and configure the transport network.

Once all the data described above is available, the path computation and optimization function processes the data and provides the configuration actions to be taken by the transport control layer.

Figure 1 shows the control architecture, including the control layer interfaces to the network and the TIF interfaces to the RAN functions and control layer for the transport network and services. The geographical area a TIF function operates in would typically be around a portion of a metro area, or even just a few sites. As illustrated in Figure 2, with an area of that size, the signaling load on the TIF would not be technically challenging.

The transport automation framework is applicable to three very distinct stages of the life cycle management process. In auto-integration, the framework supports auto-installation of transport network infrastructure, establishes basic configuration with O&M connectivity to the controller and registers with control and management functions. In auto-configuration, the framework automatically configures the transport connectivity service for the desired RAN interfaces (such as virtualized RAN or VRAN), and interacts with the RAN from a connectivity requirement perspective. Finally, in auto-optimization, it auto­matically optimizes transport resources during the run time phase to achieve overall optimal QoE for consumers and interacts with the RAN domain to achieve overall optimization.

While coordinated RAN transport automation is useful for auto-integration, its benefits are much more significant for auto-configuration and auto-optimization, the focus areas of the two TIF use cases presented below.

Use case 1: auto-configuration in ERAN and VRAN scenarios

When Elastic RAN (ERAN) is deployed, inter-site baseband connectivity is needed to give the RAN enough freedom to arrange radio coordination patterns. However, manually setting up the connec­tivity can be complex. On one hand, multiple paths are desirable to exploit all the resources of the transport network, distribute the traffic load and reduce the probability of packet collisions and consequent delays, which would dramatically reduce the advantages of the ERAN feature itself. On the other hand, unless very specific latency constraints are respected, the connectivity will be unusable for the application. Finally, to minimize the collision probability on the whole network, the traffic distribution should be globally optimized.

In VRAN deployments (also known as split architecture [4]), the connectivity accuracy is not as critical as in ERAN. The complexity in these cases is due to the larger scale and possibly heterogeneous nature of the network. Portions of the underlay network may be self-built by the operator and may consist of third-party equipment and technology. The data center architectural elements must also be orchestrated in the VRAN, which adds further complexity. The required connectivity between the baseband functions in hub sites and the virtualized functions in central offices (COs) and aggregation sites is many-to-many, and adaptive transport is needed to ensure resilience, continuous traffic optimization and reconfiguration after the addition and removal of the packet processing function.

In both ERAN and VRAN, constant monitoring of the transport network status (to detect temporary partial outage, for example) is also required to be forwarded to the RAN domain to allow for consequent actions.

Figure 2 illustrates the operation sequence, and one aspect worth highlighting is the communi­cation between the RAN and transport that takes place through the TIF. This communication includes the specification of RAN flow setup requirements to the transport network in a dynamic fashion. The TIF is responsible for taking these specific requirements and translating them into computation of requisite transport paths and optimal distribution of RAN flows across these paths to ensure the desired Service Level Agreement (SLA) requirements.

Figure 2: ERAN/VRAN auto-configuration

Figure 2: ERAN/VRAN auto-configuration

Figure 2 shows the six main TIF operations in relation to the other components of the network: (1) underlay topology discovery, (2) RAN topology discovery, (3) RAN connection setup request, (4) overlay service readiness, (5) overlay aware path setup and (6) real-time topology-aware SLA monitoring. The auto-configuration process for ERAN and VRAN scenarios requires complete automation of the whole sequence.

During underlay topology discovery (1), the TIF acquires the transport network underlay topology from the SDN controller via a standard RESTCONF interface. In RAN topology discovery (2), the TIF acquires the RAN topology directly from the RAN. It then integrates it with the transport topology to build the entire network topology view. During RAN connection setup request (3), RAN sends connectivity requests to the TIF when needed, including endpoint information along with constraints such as maximum allowed latency and expected bandwidth usage.

During overlay service readiness (4), the TIF triggers the process of the overlay service setup based on the connectivity setup request. This includes the VPN service configuration parameters and the policies required to be configured to match RAN flows to the desired transport paths, which are configured as part of the next step.

During overlay aware path setup (5), the TIF computes all possible paths according to the overlay service requirements and then requests the SDN controller to provide the desired paths on the transport edge nodes. One important consideration in the case of ERAN is the need for optimal load-balancing on RAN flows on all feasible transport paths. The idea is to ensure the optimal usage of all available transport resources to accommodate the inherently bursty traffic. This requires the implementation of a customized load-balancing algorithm in the TIF, as it is responsible for handling the overlay service part.

During real-time topology-aware SLA monitoring (6), the monitoring systems continuously supervise both the overlay RAN flows and the underlying transport network and update the TIF in case of any changes. This is necessary because enhanced observation levels are key to providing a desired SLA for the RAN flows.

This auto-configuration process for ERAN and VRAN scenarios is designed to enable complex and large-scale deployments in an agile manner, simplifying operations significantly and reducing TCO for the operator.

As previously mentioned, the TIF provides the mapping and correlation between the VRAN or ERAN traffic flows and the underlay transport. Such an enhanced level of observability into the usage of various transport resources and overlay services can be used to provide much more advanced service level guarantees. For example, congestion in a certain part of the transport network would result in detection of all impacted overlay services. This could then trigger optimization of various transport resources to protect SLAs for the impacted overlay services. The process of detecting SLA violation and doing a correlation and an impact analysis makes an excellent case for a type of automation called auto-optimization. This is a natural next step to the auto-integration and auto-configuration processes.

Use case 2: auto-optimization

Figure 3 illustrates an example of end-to-end auto-optimization. In this scenario, if congestion is detected in the transport path to the CO that serves the URLLC services, the transport path and the RAN and core functions can be moved to another CO that provides the same level of reliability and latency constraints. This is only possible because the TIF can detect the congestion in the transport network, identify the impacted URLLC flows and take the necessary corrective action in conjunction with other domains such as the RAN and core. This kind of flexibility, agility and cross-domain orchestration in an automated fashion is the key to offering highly demanding new 5G services such as URLLC.

Figure 3: Example of end-to-end auto-optimization

Figure 3: Example of end-to-end auto-optimization

Meanwhile, concurrently existing services such as eMBB must not be adversely impacted by this flexibility. In other words, a single transport network must be able to support an extremely diverse set of services. The TIF plays an important role in providing the capability to track the SLAs of all the overlay services. Furthermore, with the TIF in place, run time impact analysis of changes in the underlay network characteristics like bandwidth, latency or packet loss is carried out in conjunction with the overlay SLA requirements, and the necessary corrective action is taken. One such example of corrective action might be dynamically moving the flows of an overlay service to an alternate path computed with minimal or no impact on the other overlay services.

Global orchestration and optimization of all network level resources is another important consideration in the auto-optimization process. We are currently studying this aspect, as we believe it will take network automation to a whole new level. Domain-specific intelligent functions such as TIF for transport are set to play a critical role in the global and/or cross-domain optimization owing to the level of visibility and inherent inter-domain communication capabilities.


The transport network tends to get less attention than RAN and mobile core networks in discussions about 5G, but as the vital link between all the pieces, it too requires significant enhancement to support the diverse set of services and deployment models expected in 5G. Intelligent, automated coordination between RAN, transport and mobile core networks will undoubtedly be a key part of a robust 5G solution, because without automation it will not be possible to achieve the required levels of flexibility and observability. The TIF solution provides the requisite intelligence and acts as a catalyst for automation, enabling operators to meet the 5G requirements of multiple use cases while simultaneously reducing opex.

The authors

Stefan Dahlfort

Stefan Dahlfort

has worked in the tele­com industry for 22 years. He founded a start-up before joining Ericsson in 2007 as a manager for fiber to the x research. Having held different management positions in Research and Systems & Technology in the transport area, he is now based in Santa Clara in Silicon Valley as a product development leader. He holds an electrical engineering and a Ph.D. in optical networking from KTH Royal Institute of Technology in Stockholm, Sweden.

Antonio De Gregorio

Antonio De Gregorio

has 23 years of experience in the telecom industry. He joined Ericsson in 1997, initially working in the Operations and Maintenance area. Since then he has been responsible for the strategy and technology units of different product development organizations in Europe and in Silicon Valley in the US. He currently heads the Technical Management organization in Genoa, Italy within Development Unit Network Management. He holds an M.Sc. in electronic engineering from the University of Salerno, Italy.

Giovanni Fiaschi

Giovanni Fiaschi

joined the company in 2005 when Marconi, his employer since 1990, was acquired by Ericsson. He has been working in telecommunications for more than 25 years, specializing mostly in control functions for transport networks. Fiaschi currently works at Development Unit Networks, Systems and Technology, focusing on mobile transport network simulations and control solutions. He is also active in the IPR and security areas. He holds an M.Sc. in computer science from the University of Pisa, Italy.

Shahryar Khan

Shahryar Khan

has nearly two decades of experience in architecture design and integration for multiservice IP and transport networks for telecom operators and large enterprises. Khan held several roles within Ericsson during the period 2005-2017, most recently serving as an expert and chief architect in multiservice IP and transport networks in Development Unit Networks in Kista, Sweden. He holds a B.Sc. in electrical engine­ering from the University of Engineering and Technology in Lahore, Pakistan.

Jonas Rosenberg

Jonas Rosenberg

is a senior specialist in network architecture and solutions whose main area of expertise is within technologies and software for cross-domain automation and assurance solutions in mobile networks. He works as a leader for the mobile transport technology area and is responsible for Transport O&M within Development Unit Networks. Rosenberg joined Ericsson in 2000 and holds an M.Sc. in electrical engineering from KTH Royal Institute of Technology in Stockholm, Sweden.

Tomas Thyni

Tomas Thyni

is an expert in the area of IP and transport networks. A telecommunication and network engineer, he joined Ericsson in 2000 and has worked within the IP, broadband and optical networks areas. Today, Thyni works as a chief architect on new concepts for transport in RAN at Development Unit Networks; one such concept area is RAN and transport interaction. Prior to joining Ericsson, he accumulated 15 years of experience as an IP and transport network designer with various network operators.