Controlling Devices with UE Policy

Back in November 2021, one of the first network slicing proof of concepts was carried out in which Android end devices supported a new(ish) 5G feature known as URSP (UE Route Selection Policy). Since then, we’ve seen a relatively limited amount of deployment of Standalone 5G, which has naturally limited the volume of network slicing that’s actually taking place. However, the move towards Standalone 5G continues (albeit more slowly than anticipated), which invariably means network slicing will start to become more prevalent. Crucially, a key enabler for network slicing, particularly from the device and application perspective, is URSP. So, for this month’s blog, I thought I’d provide a little more context around UE Policy as a whole in 5G, with additional focus on URSP – all with the hope that we will be seeing it in action in the not too distant future…

Background

For years now, 4G networks have had the option of supporting ANDSP (Access Network Discovery and Selection Policy), which is a means by which the service provider can control how devices access and utilize Wi-Fi networks which are in their local vicinity, in addition to traffic steering rules between 3GPP and non-3GPP access (see Figure 1).

Speaking as a consumer, I’m not sure I’ve ever had a device that has actively used ANDSP; instead, a much simpler technique is often used, whereby the device’s Connection Manager makes the decision as to which network it should use (3GPP or non-3GPP), with no real influence from the mobile network; although simpler, there’s no policy control in operation. Part of the limitation for ANDSP deployment is general support – the devices need to support it in some way, as well as the RAN (Radio Access Network) and elements of the core (which can often mean a single vendor solution is mandated).

Despite potentially limited levels of deployment, ANDSP is still supported in 5G networks but it now becomes part of a larger UE Policy solution that is managed entirely by the 5G PCF (Policy and Charging Function). This means that the 4G ANDSF (Access Network Discovery and Selection Function) that would be required for ANDSP in 4G is no longer required, particularly if the core network is a converged 4G and 5G solution (end of life product announcements for this function started to appear around the same time 5G started to be deployed).

5G UE Policy

In 5G, UE Policy now encompasses four main areas:

• ANDSP – this is more limited than the ANDSP that is provided by the ANDSF in 4G. ANDSP provided by the PCF is centred around provisioning the device with information relating to selecting non-3GPP access networks (namely Wi-Fi), including locating a suitable ePDG (evolved Packet Data Gateway) or N3IWF (Non 3GPP Interworking Function) which can be used as an ingress/egress point for the core network (there could be times when both ePDG access to the 4G core or N3IWF access to the 5G core is available and there are rules for determining which should be used).

• URSP (UE Route Selection Policy) – this is a new feature introduced in 5G which provides information to the device on mapping different traffic to different PDU Sessions and network slices.

• V2X (Vehicle to Everything) Policy – this provides configuration information to the device on the utilization of the Uu and PC5 reference points within a V2X deployment.

• ProSe (Proximity Services) Policy – this relates to ProSe features and capabilities such as Direct Discover, Direct Communication and UE to Network Relay.

UE Policy Distribution

As mentioned, it is the PCF that is responsible for furnishing the device with UE Policy information. One obvious problem here is the fact that the PCF does not have direct access to the device and as such, the AMF must be used as an interim network function. Therefore, as Figure 3 shows, UE Policy distribution relies on a combination of SBI (Service Based Interface) interaction, coupled with the exchange of NAS signalling. It’s worth pointing out that this is all bidirectional; although the PCF will push policy to the device, there will be times when the device must supply or even request information in the opposite direction. Note also that for the AMF to be able to push UE policy information that’s come from the device to the PCF, the PCF must have already put in place a subscription under the Namf Communication service. As such, the AMF will know the Notification URI it must use in relation to the subscriber.

Focus on URSP

URSP policy information is comprised of one or more URSP rules and is used by the device to determine how to handle traffic associated with an application running on the device. As such, when application data is sent to the lower layers of the device, the URSP will determine one of three options for route selection:

• The application data can be sent on an existing identified PDU Session.
• The application data can be offloaded to non-3GPP access.
• The application data can trigger the establishment of a new PDU Session (potentially across a specific network slice). This can also encompass the establishment of a Multi Access PDU Session as part of ATSSS (Access Traffic Steering, Switching and Splitting).

Figure 4 shows the format of a URSP Rule, which fundamentally must identify the traffic (termed the Traffic Descriptor) and the action that must be taken with it (termed the Route Selection Descriptor List). Within the former, a range of different application or traffic features can be used to identify the traffic, whereas in the latter route selection components can inform the device as to what to do with the traffic.

Just one more point on the subject of ATSSS, for those readers who are aware of it. Notice that in the Route Selection Components of a URSP rule, one of them is “PDU Session Type”. If ATSSS is in operation for a particular application, the device will be instructed to establish a Multi Access PDU Session in the PDU Session Type. As such, the device will conduct a PDU Session Establishment and when the SMF (Session Management Function) responds with the PDU Session Establishment Accept, it will provide an ATSSS container. This container will instruct the device on exactly how traffic should be steered, switched or split across the access networks that are available (in 4G, this would all be provided in the ANDSP provided by the ANDSF).

Conclusion

In reality we may be some way off in terms of routinely seeing URSP in operational networks and even when we do, it’s quite possible that other verticals will see URSP used before it hits the consumer market (for example a vehicle using URSP to determine which slices it should be using). We know that network slicing is integral to the success of 5G, and it’s areas such as URSP that are a key consideration that must be factored in to the overall network slicing picture. Hopefully, you’re now a little more prepared for when it does arrive! Finally, look out for our update to our 5G Policy and Charging Control course that should be arriving in Q3!