Home Articles Device tests for fragmentation or "slicing" of the 5G network

Device tests for fragmentation or "slicing" of the 5G network

By Jonathan Borrill, Head Of Global Market Technology, Anritsu

5G networks are focused on providing new capabilities to “industrial verticals” such as Smart Factory, Medicare, or Automotive, where high-quality wireless connectivity can bring a significant improvement. But all these sectors have very specific performance needs that must be maintained, beyond the "best effort" with a guaranteed quality. To do this, with 5G network division (Network Slicing) is introduced, which allows operators to offer virtual networks dedicated to specific users, in which the performance of one portion of the network is isolated from the performance of another portion. This means that users operating in a dedicated network portion do not experience any quality of service degradation due to users in other network portions.

Network partitioning or fragmentation is sometimes compared to Quality of Service (QoS) when discussing how a communications network might provide a different quality of service to users, and QoS uses the 5QI definition in 3GPP (TS23.501 .5.7 Section 3). The 5GPP specifications contain examples of services, but no definition is provided to assign the services to the QoS/5QI value. The network division considers both the 2QI and the actual services. For example, for a non-conversational video traffic stream, a 8K video stream or an 5K video stream are two distinct service experiences. Although both flows use the same value of 5QI, the two "services" are significantly different, and the network capabilities and resources required to achieve the desired quality are significantly different. Both XNUMXQI-based and split-based network quality provide user experience differentiation, but split-network focuses more on service level differentiation.

Key parameters for 5G network fragmentation

5G terminals are intended to support multiple network applications, these network applications (NetApp) are using the 5G network divisions. From NetApp's perspective, 5G endpoints are responsible for managing 5G network portion configuration information, selecting network portions for NetApp, initiating configuration of 5G network portions, and maintaining sessions. PDU during mobility and roaming. From the perspective of the 5G network, 5G terminals help the network to select the network resources that provide end-to-end services in the XNUMXG network.

S-NSSAI (Specific – Network Slice Selection Assistance Information) information is used to identify a specific 5G network slice and represents the network resources used for that specific slice. Several S-NSSAIs form a group called the NSSAI. The network subscriber database also contains a list of S-NSSAIs to which the user is subscribed, and such S-NSSAIs are called subscribed S-NSSAIs. URSP (UE Route Selection Policy) is defined in 3GPP standards to describe the relationship between traffic flows and the corresponding routing. The URSP contains multiple rules for traffic flows and routing, each rule consisting 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 found below, and are used to identify which traffic flow to associate with which portion, Radio Access Type, and related routing parameters:

–DNN

– Triple IP(IP address or IP prefix, port number, protocol ID)

– Destination FQDN

– OSId and OSAppID

The terminals are in charge of managing and maintaining the necessary information for the network portions and can have a generic NSSAI configured by default or an NSSAI configured for each mobile network (PLMN). The NSSAI configured for each PLMN may also be provided by the network, and the terminals may use the “UE Configuration Update” procedure to update the URSP and NSSAI. To match an application/service with a network portion, the terminals may use a URSP configured by the UE/USIM or by the network. When an application is started, the terminal will initiate a data session setup procedure (PDU). The terminal may indicate its desired S-NSSAI during the PDU session setup procedure (based on the URSP), or the network may assign a network portion to be used for the PDU session. In general, if a network application service flow needs to use a specific network portion, the operator must configure this network portion for this service flow in the URSP.

Test requirements for 5G network fragmentation at terminals

A key principle of device testing is to verify "interoperability" between devices and networks. It's about ensuring that a user has the expected level of functionality and user experience when moving between different networks, and that they don't have to worry about which network they use and how that network is configured. It is also about ensuring that a network does not experience any degradation when devices operate on it, and that the network provides stable operation regardless of what devices are connected to the network.

The main testing requirements fall into two categories: “regulatory compliance” for the exchange of messages (ie, NSSAI and URSP configuration information) between a network and the device; and "UE implementation" for device behavior in using the URSP to select and request certain slice configurations. “Regulatory compliance” is often listed in the 5GPP RAN3 testing requirements and methodology and is supported by testing systems such as the Global Certification Forum (GCF). “User equipment implementation” is typically an operator or device vendor specific test plan. This "UE implementation" test should test how the application/device uses the configuration information, and the triggers that cause the device to request/change the network portion and routing being used. These aspects are called “user equipment implementation specific” and do not have a standard behavior or test procedure.

To enable testing at an "end-to-end" level, the incorporation of application layer functions on the device side is required, since the portion selection and traffic routing procedures use selection criteria related to the application and mappings that are configured within the device. This specific application layer and device implementation functionality requires additional test interfaces and test/verification procedures to support implementation and network sharding interoperability/consistency for smartphones.

Network Split Test Areas

The exchange of NSSAI information between the network and the UE (reading, authorizing and updating the available segments) is covered by the 3GPP conformance tests in TS38.523-1. This verifies the transfer of the required information through the signaling of the air interface.

Section 5.15.4 of 3GPP TS23.501 gives priority rules for preferences and options of segments reported by the network and configured by the user equipment (including defaults). These must be validated to ensure that any configuration provided by a third party is treated correctly against configurations provided by the network. This is a specific area of ​​UE implementation, outside of the current coverage of 3GPP conformance testing. The text of section 5.15.5 of 3GPP TS23.501 provides detailed information on the handling of NSSAIs. This includes the implementation of the NSSAI rules, the procedures for registering and modifying the NSSAI lists in the UE, and the process for establishing a PDU session using these lists.

URSP test areas.

USIM-based updating 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 the 3GPP in TS31.124. This verifies the transfer of the required information via air interface signaling to the USIM, for any URSP rules stored/configured by the USIM.

Section 6.6.2.3 of 3GPP TS23.503 provides the procedure for the UE to associate applications to PDU sessions based on the URSP information. The behavior of the UE to implement these procedures is the sandbox which is "UE implementation specific". The assignment of applications to URSP rules and the selection process of the different URSP rules are specific to the UE implementation and are outside the coverage of current 3GPP conformance testing. If the operators provide specific URSP rules with the required parameters/configurations, the consistency of the mapping in the UE should be checked in terms of the selection and prioritization of the rules and the mapping to the PDU session types. The UE may also have “local settings” that are used to select a specific PDU session type for a particular application (stored in the UE or in the USIM). Equivalently, if the same rules are provided to different UEs, the interpretation of and response to these rules by each UE should be tested for consistency and expected correct behaviour. In the case of roaming, there may be differences in the rules provided by the home PLMN and the visited PLMN, and the correct priority management of these rules should be verified.

3GPP TS24.562 describes the UE policies for URSP. Section 4.2 covers the URSP handling process, and section 5 covers the details of URSP rule encoding. URSP rules can be pre-configured in the USIM and/or in the UE and can also be provided by the network operator (from the PCF, policy control function) using the NAS messaging "UE Policy Delivery Service". Delivery of EU Policies). It may be necessary to verify correct provisioning and interoperability (equivalency) of rules to ensure consistent/predictable selection behavior by UEs when operating on different networks (eg in roaming scenarios).

There is no standardized way to trigger URSP rule selection, rather it is application layer dependent and UE implementation specific. In order to be able to perform the tests, the user equipment must have a suitable test method (eg a remote command) or a suitable test application that can trigger the necessary selection procedures. The process of pairing the user equipment application (session PDU) with the URSP and requesting the appropriate network portions is described earlier in this document, and different options are referenced. Each of the different methods requires a combination of NSSAI and URSP provisioning, followed by a selection of application-specific rules/profiles that are an OS (operating system) specific implementation. Verifying correct operation requires a combination of NSSAI tests, URSP tests, and then OS selection procedures. To enable the required selections of specific profiles, a "test application" or specific test interfaces in the OS will be needed to allow a specific selection in the UE.

Benchmark for Network Slicing.

You can build a test environment for network splitting and el URSP using Anritsu's MT8000A Radio Communications Tester. This platform enables controlled and precise configuration of network signaling, including S-NSSAI and URSP, so that specific test cases and configurations can be validated. The MT8000A can also directly connect to external MEC (Multi-access Edge Compute) 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.

In conclusion

Network slicing brings new capabilities to 5G devices, with the potential to provide differentiated quality of service 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 the 3GPP modem/protocol layers and the operating system/application layers. This requires new test methods and procedures to verify both device and application performance, and also to verify interoperability and roaming/mobility scenarios. As network sharding is designed to offer the user a differentiated service, user experience verification becomes a critical aspect of network sharding deployment.