Device testing for 5G network slicing

Author : Jonathan Borrill | Head of Global Market Technology | Anritsu

01 March 2022

Anritsu Network-Slicing-Article-Graphic-1
Anritsu Network-Slicing-Article-Graphic-1

5G networks have a focus on providing new capabilities to ‘industry verticals’ such as smart factories, medtech & automotive, where high quality wireless connectivity can bring significant enhancements. But these industries all have very specific performance needs that must be maintained – beyond a ‘best effort’ basis and with guaranteed quality.

This article was originally featured in the March 2022 issue of EPDT magazine [read the digital issue]. And sign up to receive your own copy each month.

To support this, network slicing in 5G will enable operators to offer dedicated virtual networks to users, where the performance of one network slice is isolated from the performance of other slices. As Jonathan Borrill, Head of Global Market Technology at communications T&M provider, Anritsu explains here, this means that users operating on a dedicated network slice will not suffer any degradation of service quality due to users on other slices of the network.

Network slicing is sometimes compared with Quality of Service (QoS) when analysing how a communication network could provide differing service quality to different users, and QoS uses the 5QI (5G QoS Identifier) definition in 3GPP (TS23.501 Section 5.7). The 3GPP (3rd Generation Partnership Project is an umbrella term for a number of standards bodies that develop protocols for mobile telecoms) specifications contain service examples, but no definition is provided to map services to QoS/5QI value. Network slicing considers both the 5QI (a pointer to a set of QoS characteristics, such as priority level, packet delay or packet error rate) and the actual services themselves.

For example, for a non-conversational video traffic stream, and then a 2K or 8K video stream, are two differentiated service experiences. Although both streams use same 5QI value, the two “services” are significantly different, and the network capabilities and resources required to achieve the desired quality are likewise very different. Network quality based on 5QI, and based on network slicing, both provide user experience differentiation – but network slicing focuses more on service level differentiation.

Key parameters for 5G network slicing

5G terminals are intended to support multiple network applications, and these network applications (or NetApps – defined, in a 5G context, as a set of services that provide certain functionalities to the verticals and their associated use cases) are using 5G network slices. From the NetApp perspective, 5G terminals are responsible for managing slice configuration information, selecting network slices for the NetApp, initiating the setup of 5G network slices, and maintaining PDU (Protocol Data Unit) sessions during mobility and roaming. From the 5G network’s perspective, 5G terminals assist the network in selecting network resources, providing end-to-end services over the 5G network.

An S-NSSAI (Single – Network Slice Selection Assistance Information) is an identifier for a specific 5G network slice and represents the network resources used for that specific slice, with several S-NSSAIs forming a collection known as the NSSAI. The network’s subscriber database also contains a list of S-NSSAIs which the user is subscribed to, and such S-NSSAIs are called subscribed S-NSS-AIs. URSP (UE or user equipment route selection policy) is defined in 3GPP standards to describe the relationship between traffic flows and the corresponding routing. URSP contains multiple rules for traffic flows and routing; each rule consists of a traffic descriptor and a route selection descriptor. They are used to describe the S-NSSAI and related route characteristics that match the traffic flow description.

The main traffic descriptors are listed below, and are used to identify which traffic flow to associate with which slice, radio access type (or RAT) and related routing parameters:

•  DNN (Data Network Name)

•  IP triples (IP address or IP Prefix, Port Number, Protocol ID)

•  Destination FQDN (fully qualified domain name)

•  OSId (Operating System Identifier) and OSAppID (OS specific Application Identifier)

Terminals are responsible for managing and maintaining information needed for network slices, and may have a generic default Configured NSSAI or a Configured NSSAI for each mobile network (PLMN or public land mobile network). The Configured NSSAI for each PLMN can also be provided by the network, and terminals can use ‘UE configuration update’ procedure to update URSP and NSSAI. To match an application/service with a network slice, terminals can use either UE/USIM (universal subscriber identity module) configured or network configured URSP. When an application starts, the terminal will initiate a data (PDU) session set-up procedure. The terminal can indicate its desired S-NSSAI during the PDU session set-up procedure (based on URSP), or the network can assign a network slice to be used for the PDU session. Generally, if a network application service flow needs to use a specific network slice, then the operator should configure this network slice for this service flow in URSP.

Anritsu Network-Slicing-Article-Graphic_2
Anritsu Network-Slicing-Article-Graphic_2

Test requirements for 5G network slicing in terminals

A key principle of device testing is to verify ‘interoperability’ between devices and networks. This is to ensure that a user has the expected level of functionality and user experience as they move between different networks – and they do not have to take care of which network they use and how that network is configured. This is also to ensure that a network does not suffer any degradation when devices operate on the network, and that the network provides stable operation regardless of which devices are connected to the network.

The principal testing requirements are broken down into two categories: ‘standards compliance’, for the exchange of messages (for instance, NSSAI and URSP configuration information) between a network and the device; and ‘UE implementation’, for the behaviour of the device in using the URSP for selecting and requesting certain slice configurations. The ‘standards compliance’ is normally contained in the 3GPP RAN5 testing requirements and methodology, and supported by testing schemes such as Global Certification Forum (GCF). Within the 3GPP Technical Specification Group Radio Access Network (TSG RAN), the 3GPP TSG RAN WG5 (RAN5) is the Conformance Testing Working Group for User Equipment (UE). The ‘UE implementation’ is normally an operator or device vendor specific test plan. This ‘UE implementation’ testing should test how the application/device uses the configuration information, and the triggers which cause the device to request/change the network slice and routing that is being used. These aspects are designated as ‘UE implementation specific’ and do not have a standardised behaviour or test procedure.

To enable testing at an ‘end-to-end’ level requires the inclusion of application layer functions at the device side, as the slice selection and traffic routing procedures use application related selection criteria and mappings that are configured within the device. This application layer and device implementation specific functionality requires additional test interfaces and test/verification procedures to support the implementation and interoperability/consistency of network slicing for smartphones.

Network slicing test areas

Exchange of NSSAI information between network and UE (reading, authorising and updating available slices) is covered by 3GPP Conformance Tests in TS38.523-1. This verifies the transfer of required information across the air interface signalling.

Priority rules for network informed and UE configured (including any default) slice preferences and options are given in 3GPP TS23.501 section 5.15.4. These must be validated to ensure any configurations provisioned by a third party are correctly handled versus network provided configurations. This is a UE implementation specific area, outside of current 3GPP conformance test coverage. The text in 3GPP TS23.501 section 5.15.5 provides the detailed information for handling NSSAI. This includes the implementation of NSSAI rules, procedures to register and modify the NSSAI lists in the UE, and the process to establish a PDU session using these lists.

URSP test areas

USIM based refresh of Routing Indicator data via NAS (Non Access Stratum) messages and opening a new radio bearer after receiving URSP policy update from the network are covered by 3GPP in TS31.124. This verifies the transfer of required information across the air interface signalling to the USIM, for any USIM stored/configured URSP rules.

3GPP TS23.503 section 6.6.2.3 provides the UE procedure for associating applications to PDU sessions based on URSP information. The behaviour of the UE to implement these procedures is the area of testing that is ‘UE implementation specific’. Mapping of applications to URSP rules, and the selection process for different URSP rules, is UE implementation specific and outside of current 3GPP conformance test coverage. If operators are providing specific URSP rules with required parameters/settings, then the mapping in the UE should be checked for consistency in selection and prioritisation of rules and mapping to PDU session types. The UE may also have ‘Local Configurations’ which are used for selection of a specific PDU session type for a specific application (stored in the UE or in the USIM). Equivalently, if the same rules are provisioned to different UEs, then the interpretation and response to these rules by each UE should be tested for consistency and correct expected behaviour. In the case of roaming, there may be differences in rules provided by the Home-PLMN and the Visited-PLMN, and the correct priority handling of these rules should be verified.

3GPP TS24.562 describes the UE Policies for URSP. Section 4.2 covers the process of handling URSP, and section 5 covers the details of encoding the URSP rules. URSP rules can be pre-configured in the USIM and/or UE and can also be provided by the network operator (from the PCF or Policy Control Function) using the NAS messaging ‘UE Policy Delivery Service’. Correct provisioning and interoperability (equivalence) of rules may need to be verified to ensure consistent/predictable selection behaviour by UEs when operating in different networks (in other words, roaming scenarios).

Anritsu Network-Slicing-Article-Graphic-3
Anritsu Network-Slicing-Article-Graphic-3

There is no standardised way to trigger URSP rule selection, this is driven by the application layer and is UE implementation specific. To enable testing, the UE must be provided with a suitable test method (such as remote command) or a suitable test application that can trigger the required selection procedures. The process of matching UE application (PDU session) to URSP and requesting suitable network slices is described earlier in this article, and different options are referred to. Each of the different methods requires a combination of NSSAI and URSP provisioning, followed by application specific selection of rules/profiles which are an OS (Operating System) specific implementation. To verify the correct operation requires a combination of the NSSAI tests, URSP tests, and then the OS selection procedures. To trigger the required selections of specific profiles will require either a ‘test application’ or specific test interfaces in the OS, to enable a specific selection in the UE.

Network slicing test bed

A test environment for network slicing and URSP can be built using the Anritsu MT8000A Radio Communication Tester. This platform allows precise controlled configuration of the network signalling, including S-NSSAI and URSP, so that specific test cases and configurations can be validated. The MT8000A can also be connected directly to external Multi-access Edge Compute (MEC) servers, to provide user data with different routing. The same MT8000A platform is also used in the ME7834NR Protocol Conformance Test system, to enable validation of 3GPP Conformance Test specifications.

Conclusion

Network slicing brings new capabilities to 5G devices, with the ability to provide differentiated service quality to different applications. This requires a new approach to testing the application and service layer aspects of 5G devices. In particular, there is a new type of interaction between 3GPP protocol/modem layers and the operating system/application layers. This requires new test methods and procedures to verify both the performance of the device and application, and also to verify the interoperability and roaming/mobility scenarios. As network slicing is designed to offer the user a differentiated service, then the verification of user experience becomes a critical aspect of network slicing deployment.


More information...

Contact Details and Archive...

Print this page | E-mail this page