What does transport need to handle 5G network slicing efficiently?
Since network slicing is an end-to-end concept, support of network slicing in the transport domain is needed to ensure that the correct service assurance for the network slices can be upheld. At the same time, it’s important to remember that network slices are not “created” nor “terminated” in the transport network. Instead, the transport network’s main target is maintaining the properties of the network slices it transports. To achieve this, all three domains, RAN, Core, and Transport, including management, must be considered.
The figure below shows the end-to-end nature of network slicing and how transport is an integral part of the overall solution.
To fulfill the target for the transport domain, we have chosen to divide the technology needed into six main principles:
- Transport resource sharing
- Packet identification
- Packet identifier
- Transport resource partition
- Transport resource partition instantiation
- Transport management
Transport resource sharing
The first item to consider is the way to share resources in the transport network. We recommend using what we have called dynamic partitioning, which is using standard packet technologies like, for example, SVLANs, VPNs, QoS, and other technologies. They will likely be used to a larger extent than many transport networks today to achieve the targets set. We believe that the absolute majority of network slicing use cases can be properly served by these technologies with very good transport network resource utilization and avoiding a costly forklift of the network.
Some networks could benefit from other solutions, e.g., private 5G networks for industrial control processes, but in those cases, the transport network and its dimensioning are significantly different than for wide area networks.
Packet identification and Packet identifiers
At the edges of the transport network, it must be possible for the edge nodes to identify a packet flow belonging to a network slice or a group of network slices (in case Core/RAN have decided to pre-group them before reaching the transport domain).
For the identification to be possible, Core/RAN must apply an identifier to the packets. This identifier can be implicit, which is when the identifier already has a use in the network for some other purpose. The IP address of the RAN node or Core node is one example of an implicit identifier.
It can also be explicit, which is when it’s only used as an identifier for the transport network, e.g., using VLAN or the IPv6 flow label specifically as a transport identifier. The identifier can be in the ethernet or IP headers, independent of whether the transport is an ethernet or IP network. The identifier must be visible to the transport edge nodes, so it must be accessible outside any security or other tunnels.
In case the network slices have multiple traffic classes with different priorities, the identifier must be combined with a traffic class/priority indicator. There is currently work ongoing in standardization bodies to agree on suitable identifiers.
Transport resource partition and instantiation
The packet flows, containing one or more network slices, can now be identified and separated into entities we have chosen to call “transport resource partitions”. A transport resource partition shall be seen as an intermediate abstraction between the packet flows of the network slices and the specific technology for transporting them, e.g., a VPN or an SVLAN. It in a way represents as set of resources in the transport network serving a set of packet flows.
The transport resource partition also becomes the entity to which we can connect a certain Service Level Agreement (SLA) in the transport domain. It contains one or more network slices that need the same type of SLA treatment in the transport network. In case a single network slice would have several different traffic types with different priorities, the transport resource partition also needs to have a traffic priority concept to be able to carry over this information to the transport technology used in the network.
We have now identified packets from network slices, collected them into transport resource partitions, and kept any internal traffic classes. The next step is to apply transport technology to get the packets through the actual network. The properties we are looking for are well-standardized technologies, support of QoS, a certain level of separation, a way to control the path through the network, and the possibility to apply monitoring and service assurance.
The transport technologies’ capability to support multiple priorities is important. We recommend keeping a “diff-serv”-implementation where only the transport network edge nodes have a full separation of transport resource partitions and traffic classes.
Inside the transport network, transport resource partitions are handled on a level of aggregates using the transport technologies’ natively supported QoS principles. Also note that we can instantiate more than one transport resource partition in the same transport technology when they have very similar SLAs. This is recommended when there is a very high number of transport resource partitions to avoid issues with scaling.
In ethernet and IP networks, SVLANs and VPNs are good choices as they offer the properties we are looking for. One or more transport resource partitions are mapped to an SVLAN/VPN and any traffic classes to PCP/EXP.
In IP networks, the VPN can be instantiated on top of several different underlying technologies, e.g., IP-MPLS, SR-MPLS, or SRv6 depending on what is supported and preferred by the service provider.
For an ethernet network, the separation of transport resource partitions, and even traffic class, can be upheld through the entire network and not only in the edge node since the SVLAN and any related PCP values are accessible to all nodes. A simpler model re-mapping to the eight available PCP values is, of course, also possible.
For an MPLS or SRv6-based network, the principles are different as the P-nodes inside of the network only use the outermost label or SID for their forwarding decision without knowledge of any VPNs. It means that in case of congestion, a P-node will just process the QoS value in the outermost label or SID making a re-mapping to the available priority levels needed. This principle is not specific to the use of network slicing but applies to all MPLS/SRv6-based transport networks. MPLS has eight priority levels (EXP) while SRv6 has 64 (DSCP), giving an SRv6 network better possibilities for QoS separation in case of a large number of resource partitions with different SLA needs.
Currently, discussions are ongoing if the identifier and QoS indicator for a network slice, or group of network slices, or more correctly, a transport resource partition, as we want to keep the possibility of bundling in the transport domain, should be made visible to the P-nodes inside of an MPLS or SRv6 transport network. It would allow for per transport resource partition and traffic class separation through the entire network, as is possible in an ethernet network. While this will offer an improved resource separation in the network, it also adds complexity both for management and QoS configuration.
In principle, a per-node QoS configuration will be needed, possibly even dynamically updated, in case a transport resource partition moves to or from a specific node in the network. Extended identification is not yet standardized, and further work is needed to understand how already deployed transport networks will be able to offer support for it.
One more way to ensure the transport resource partitions are correctly treated in the transport network is to apply traffic steering. This will typically only be used when there are transport resource partitions with tough SLA requirements and/or when the transport network is large, complex, and offers many paths with different characteristics for the traffic. The traffic steering method would be what is already standardized within MPLS and SRv6.
Managing a transport network supporting network slicing can mean new challenges as the network will be more dynamic than what is typical today. Network slices and hence transport resource partitions can be added and removed, and more advanced QoS configurations will be used in many cases.
The general recommendation is to strive for a management architecture, as in the figure below, which is in line with the recommendations for 3GPP and IETF. The use of hierarchical architecture for the transport network and its different domains will simplify automation and consistent end-to-end transport service and QoS configuration.
The RAN and Core domains are responsible for applying implicit or explicit identifiers and QoS indicators on the network slice packet flows for the transport network to use, making it necessary for the transport management domain to interact with those two domains. Using manual configuration within and between the domains can be challenging as it increases the risk of errors and will not support faster dynamic reconfigurations.
Many tools already exist for transport to handle network slicing, but some standardization is left to ensure performance in a multi-technology and multi-vendor environment. We recommend that a thorough analysis of the transport network, management system, network slices, and the required service assurance levels is done to understand what resource partitioning, QoS, and transport steering technologies are needed to correctly support all defined use cases without creating an overly complex or hard-to-operate system.
Like what you’re reading? Please sign up for email updates on your favorite topics.Subscribe now
At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.