UE Policies are sets of rules and configuration parameters defined by the network operator and delivered to the UE. These policies guide the UE's behavior regarding network selection, routing preferences, access control, and more. The "Manage UE Policy Command" is part of the UE Policy Control framework in 5G. It allows the network to dynamically configure the UE with policies defined by the Policy Control Function (PCF) in the 5G Core (5GC).

The message typically includes policy sections or instructions, such as

• URSP (UE Route Selection Policy): Rules that help the UE decide how to route traffic for different applications (e.g., send low-latency gaming traffic over a specific network slice, send background updates over the default connection).
• ANDSP (Access Network Discovery & Selection Policy): Rules guiding the UE on how to discover and select non-3GPP access networks (like Wi-Fi).

URSP(UE Route Selection Policy)

URSP is essentially a set of rules configured on the User Equipment (UE) by the 5G network. Its primary purpose is to guide the UE on how to handle outgoing traffic from different applications. Think of it as a smart routing table within your phone, specifically for deciding which network connection path (PDU Session) or network characteristics (like a Network Slice) should be used for a specific application or type of data.

NOTE : The details of URSP is spcified in 3GPP 24.526-4.2 UE route selection policy (URSP) and 23.503-6.6.2 UE Route Selection Policy information

Functionally, when an application on the UE wants to send data, the UE consults its URSP rules. It tries to match the characteristics of the application's traffic (like the app ID, destination address, or requested data network) against criteria defined in the rules. If a match is found, the rule tells the UE the preferred way to route that traffic – for example, directing it towards a specific Network Slice designed for low latency, using a particular Data Network Name (DNN), sending it over Wi-Fi instead of cellular, or even blocking it. This allows the network operator to influence how the UE utilizes network resources, enabling optimized performance for different services and efficient network management.

NOTE : URSP operation is tightly associated with Network Slice. So the understandings on Network Slice would be necessary for URSP understanding. Check out this note for Network Slicing

Provision of URSP

When an app on your phone needs to send data, the phone must decide how to connect it. The mobile network provides a 'rulebook' (called URSP rules) that tells the phone how to choose the right data path for different applications and network conditions.

In other words, when an app needs internet, your phone checks a prioritized list of network rules. It finds the first rule that matches the app's traffic, picks the best "connection recipe" from that rule, and tries to use an existing connection that fits the recipe. If none exists, it tries to make a new one based on the recipe. This process repeats if rules or conditions change.

Now let's breakdown this process and look into details (this procedure is based on 23.503-6.6.2.3

• App Starts Needing Internet: When a new app on your phone wants to connect to the internet, your phone notices.
• Check the Rulebook (URSP): Your phone looks at the list of rules the network gave it. These rules are ranked by importance (priority). It goes through them one by one, starting with the most important.
• Find a Matching Rule: The phone checks if the type of traffic the app wants to send (e.g., video streaming, web Browse) matches the description in a rule.
• Pick a Connection Recipe (RSD): Once it finds a rule that matches the app's traffic, that rule might have several "recipes" (called Route Selection Descriptors or RSDs) for how to connect. These recipes are also ranked by priority. The phone picks the highest priority recipe that is currently valid.
• Check if a Suitable Connection Already Exists: The phone looks at its current internet connections (PDU Sessions) to see if any of them perfectly match all the requirements in the chosen recipe (RSD).
• A match means:
• Specific settings (like connection type) must be identical.
• Settings with multiple options (like allowed network slices) must match at least one option.
• If the recipe doesn't mention a specific setting, the existing connection must also have been set up without that setting.
• If the recipe has time or location limits, the existing connection must have the same limits.
• Use Existing Connection (If Found): If there's an existing connection that's a perfect match, the phone directs the app's traffic over that connection. If more than one existing connection matches, the phone just picks one.
• Try Making a New Connection (If No Match): If none of the current connections match the recipe, the phone tries to create a new internet connection using the exact details from the chosen recipe (RSD).
• Handle Connection Success/Failure:
• Success: If the network allows the new connection, the phone uses it for the app.
• Failure: If the network rejects the new connection request:
• The phone might try slightly different settings within the same recipe, if possible based on the rejection reason.
• If not, it moves to the next highest priority recipe (RSD) within the same rule and tries again.
• If all recipes in that rule fail, it goes back to Step 3 and looks for the next highest priority rule that matches the app's traffic (but it won't use a generic "match-all" rule at this stage).
• If all relevant rules and their recipes fail, the phone can't set up a connection for the app based on these specific network rules.
• Special Case: Wi-Fi Offload: If the chosen recipe says to use "Non-Seamless Offload" and your phone is connected to Wi-Fi, it will just send the app's traffic directly over Wi-Fi, not using a cellular data connection (PDU Session) for it.
• Keep Checking (Re-evaluation): This isn't a one-time thing. Your phone re-checks these rules and connections periodically, or when things change, such as:
• The network updates the rules.
• You move between 4G and 5G.
• Your network permissions change.
• You enter or leave an area with a special local network (LADN).
• You connect to Wi-Fi or switch between cellular/Wi-Fi registration.
• A connection currently used by an app gets dropped.
• Time or location conditions for a rule expire.
• Validity Check: For a recipe (RSD) to even be considered (back in Step 4), it must be valid right now. This means:
• Any required network slice must be currently allowed for your phone.
• If it needs a special local network (LADN), you must be in that area.
• If it requires features your phone doesn't have (like specific multi-access tech), it's invalid.
• If it has a time window, the current time must be within it.
• If it has a location requirement, you must be in that location.

Following is general flow involved in URSP rule configuration as an example flow. After the initial steps(Step 1~4) where the User Equipment connects to the network and establishes a data pathway, the focus shifts to refining how the device handles its traffic. In Step 5, the network proactively sends instructions down to the UE using the Manage UE Policy Command message. This crucial message delivers the specific UE Route Selection Policy, known as URSP Rules, which dictate how the UE should direct traffic from different applications, perhaps over specific network slices or data connections. Subsequently, in Step 6, the UE responds back to the network with the Manage UE Policy Complete message. This serves as confirmation that the device has successfully received, processed, and applied the URSP rules provided by the network, concluding this particular policy management exchange.

Following is overall description of the flow listed in the table.

• Step 1: Asking to Join (Registration Request)
  • UE -> NW: Your phone (UE) contacts the network (NW).
  • Registration Request: It says, "Hi, I'm here and I'd like to connect."
  • Requested NSSAI: It might also mention the specific types of network services (Network Slices, like high-speed internet, low-latency gaming, etc.) it prefers to use.
• Step 2: Network Says OK (Registration Accept)
  • UE <- NW: The network replies to your phone.
  • Registration Accept: It says, "Okay, you're allowed on the network."
  • Allowed NSSAI: Crucially, it tells your phone which network slices it's actually permitted to use based on your subscription and network capabilities.
• Step 3: Setting up a Basic Connection (PDU Session Request)
  • UE -> NW: Your phone asks to set up an initial data pathway (PDU Session).
  • PDU Session Establishment Request: "I need a basic data connection now."
  • Selected NSSAI: It likely picks one of the allowed network slices for this first connection.
• Step 4: Basic Connection Confirmed (PDU Session Accept)
  • UE <- NW: The network confirms the initial data connection is ready.
  • PDU Session Establishment Accept: "Your basic data connection is set up using this slice."
• Step 5: Getting the Rules! (Manage UE Policy Command)
  • UE <- NW: The network sends an important command to your phone.
  • DL NAS Transport / Manage UE Policy Command: This message contains the URSP Rules – the "rulebook" we discussed. It tells your phone how to handle data traffic for different applications or types of data.
• Step 6: Got the Rules! (Manage UE Policy Complete)
  • UE -> NW: Your phone confirms back to the network.
  • UL NAS Transport / Manage UE Policy Complete: "Okay, I have received and understood the URSP rules."
• Step 7: App Needs Data! (Internal Trigger)
  • UE: An application starts on your phone (e.g., you open a video app) and needs to send/receive data.
  • Triggers a packet matching a URSP Rule: Your phone checks the data the app wants to send against the URSP rules it received in Step 5. It finds a rule that matches this specific type of traffic.
• Step 8: Asking for a Specific Connection (PDU Session Request based on URSP)
  • UE -> NW: Based on the matching URSP rule (the "recipe"), the phone realizes it needs a specific type of data connection (PDU Session), maybe different from the basic one established in step 3 and 4. (NOTE : If there is any existing PDU session that matches URSP rule, UE would not trigger this PDU Session Request)
  • UL NAS Transport / PDU Session Establishment Request: It asks the network, "I need to set up a new PDU session specifically for this type of traffic, according to my rules."
  • NSSAI defined in URSP Rules: The request specifies the network slice (NSSAI) that the URSP rule dictated for this app's traffic.
• Step 9: Specific Connection Approved (PDU Session Accept)
  • UE <- NW: The network approves the request for this specific PDU session.
  • DL NAS Transport / PDU Session Establishment Accept: "Okay, the specific connection you asked for (based on the URSP rule) is established."
  • NSSAI Requested by UE: Confirms the network slice being used is the one the phone asked for in step 8.
• Step 10: Using the Right Path! (Data Transfer)
  • UE -> NW: Your phone now sends the application's data packet.
  • Packet goes through the assigned NSSAI: The data travels over the specific PDU session (and associated network slice) that was just established in steps 8 & 9 because the URSP rules determined it was the correct path for that application's traffic.

Example 01 >

Following is an example of Manage UE Policy Command with URSP. This is from Amarisoft Tech Academy Tutorial.

This is an example of DL NAS Transport message, which acts as a container to carry the actual Manage UE Policy Command. This command, in turn, contains a UE Route Selection Policy (URSP) rule designed to instruct the UE on how to route certain types of traffic.

In summary, this Manage UE Policy Command instructs the UE to apply a low-priority URSP rule (precedence 255). This rule targets traffic going to the specific IP address 192.168.3.2 and associated with the "internet" DNN. The preferred routing action is to use the "internet" DNN over cellular (3GPP) access, ideally utilizing the network slice defined by SST=1, SD=1.

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0xaedd094a

Sequence number = 0x09

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x68 (DL NAS transport)

Payload container type = 5 (UE policy container)

Payload container:

  Procedure transaction identity = 128

  Message type = 0x01 (Manage UE policy command)

    UE policy section management list:

    Length: 64

      UE policy section management sublist (PLMN 1):

        MCC = 001

        MNC = 01

          Instruction 1:

            UPSC: 0

            UE policy part 1

              UE policy part contents length: 53

              UE policy part type: 1 (URSP)

              UE policy part contents:

              URSP rule 1

                Length of URSP rule: 50

                Precedence value of URSP rule: 255

                Length of traffic descriptor: 21

                Traffic descriptor:

                  IPv4 remote address = 192.168.3.2 mask 255.255.255.255

                  Match-all

                  DNN = "internet"

                Length of route selection descriptor list: 24

                Route selection descriptor list:

                  Route selection descriptor 1

                    Length of route selection descriptor: 22

                    Precedence value of route selection descriptor: 255

                    Length of route selection descriptor contents: 19

                    Route selection descriptor components:

                      S-NSSAI

                        Length of S-NSSAI contents = 4 (SST and SD)

                        SST = 0x01

                        SD = 0x000001

                      DNN = "internet"

                      Preferred access type = 1 (3GPP access)

Followings are breakdown and description of this message

• UE policy section management list: A container holding the specific policy instructions.
  • Length: 64: Indicates the size of this management list section.
  • UE policy section management sublist (PLMN 1): Specifies that the following instructions apply to a particular network operator.
    • MCC = 001, MNC = 01: The Mobile Country Code and Mobile Network Code, identifying the specific operator (often 001/01 is used for testing purposes).
    • Instruction 1: Details the action to be taken regarding a policy section.
      • UPSC: 0: The UE Policy Section Code, uniquely identifying the policy section being managed by this instruction. This is an ID of the instruction. You can use any unique 2 byte integer for this.
      • UE policy part 1: Refers to the first (or only) part within the policy section UPSC 0.
        • UE policy part contents length: 53: The size of the actual policy data within this part.
        • UE policy part type: 1 (URSP): Clearly identifies the policy data as UE Route Selection Policy rules.
        • UE policy part contents: This is where the actual URSP rule data begins.
          • URSP rule 1: Identifies the specific URSP rule being defined or updated.
            • Length of URSP rule: 50: The total size of this individual URSP rule.
            • Precedence value of URSP rule: 255: Sets this rule's evaluation priority among all URSP rules on the UE. 255 is typically the lowest priority, meaning it's evaluated after higher-priority rules.
            • Length of traffic descriptor: 21: The size of the section defining which traffic this rule matches.
            • Traffic descriptor: The criteria for matching outgoing traffic.
              • IPv4 remote address = 192.168.3.2 mask 255.255.255.255: Matches traffic specifically destined for the IP address 192.168.3.2.
              • Match-all: Likely indicates that other potential traffic descriptors (like protocol or port number) are not specified, so the rule applies regardless of them, as long as the IP and DNN match.
              • DNN = "internet": Also requires the traffic to be associated with the Data Network Name "internet".
            • Length of route selection descriptor list: 24: The size of the section defining what to do with matched traffic.
            • Route selection descriptor list: Contains one or more ways the UE should try to route the matched traffic.
              • Route selection descriptor 1: The first (and only, in this snippet) routing preference defined for this rule.
                • Length of route selection descriptor: 22: The size of this routing preference block.
                • Precedence value of route selection descriptor: 255: Priority within this rule. If multiple descriptors existed, the UE would try them in order; 255 is likely the lowest priority here too.
                • Length of route selection descriptor contents: 19: The size of the actual preference parameters.
                • Route selection descriptor components: The specific preferences for routing.
                  • S-NSSAI (SST = 0x01, SD = 0x000001): Indicates a preference to route this traffic via a specific Network Slice identified by Slice/Service Type 1 (likely eMBB) and Slice Differentiator 1.
                  • DNN = "internet": Indicates a preference to use the "internet" Data Network Name when establishing or using a PDU session for this traffic.
                  • Preferred access type = 1 (3GPP access): Indicates the UE should prefer using the cellular network (3GPP) for this traffic over other options like Wi-Fi (Non-3GPP).

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0x25d2415e

Sequence number = 0x15

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x0 (Plain 5GS NAS message, not security protected)

Message type = 0x67 (UL NAS transport)

Payload container type = 5 (UE policy container)

Payload container:

  Procedure transaction identity = 128

  Message type = 0x02 (Manage UE policy complete)

Parameters

URSP parameters are the building blocks that define how the UE should route different types of application traffic. These parameters are organized into rules, primarily consisting of criteria to identify specific traffic (Traffic Descriptors) and the corresponding actions or preferences for routing that traffic (Route Selection Descriptors). These rules, along with other related policy information, are managed and delivered by the network to the UE. The parameters range from high-level identifiers for the subscription and device, to management structures for the policies, down to the very specific details within each rule, like IP addresses, application IDs, or network slice preferences, collectively enabling sophisticated traffic steering in 5G networks.

The parameter structure is defined in 23.503 as follows.

< 23.503-Table 6.6.2.1-1: UE Route Selection Policy >

< 23.503-Table 6.6.2.1-2: UE Route Selection Policy Rule>

< 23.503-Table 6.6.2.1-3: Route Selection Descriptor>

Consolidating all the tables listed above, the message structure and contents are described as below. (NOTE : These parameter list is based on Amarisoft Core NetworkUser Manual)

ue policy section management list: This represents metadata provided by the network (PCF) to the UE. It contains identifiers for the policy sections (which could include URSP rules, ANDSP rules, etc.) currently active on the UE. When the network sends updates (`Manage UE Policy Command`), it uses these identifiers to tell the UE which specific policy sections to add, modify, or delete.

• plmn (Public Land Mobile Network): Identifies a specific mobile network operator (using MCC - Mobile Country Code and MNC - Mobile Network Code). UE policies, including URSP, can be specific to a PLMN (either the Home PLMN or a Visited PLMN). The PLMN ID provides the context for which operator's rules are currently applicable.
• instruction list: This seems to refer to a list of instructions within the UE policy delivery mechanism. It likely contains commands or data units related to managing policy sections on the UE.
  • upsc (UE Policy Section Code): A unique identifier assigned by the PCF for a specific UE Policy Section. This code is used in the `ue policy section management list` and in policy management commands to refer to a particular set of policy information (e.g., the set containing URSP rules).
  • ue policy part list: A UE Policy Section can be composed of one or more "parts". This list likely enumerates these parts within a given section, possibly allowing for granular management or updates. URSP rules might constitute one such part.
  • ursp rules (within instruction list): Here, this refers more specifically to the actual set of URSP rules being delivered or managed as part of a UE policy section or part. This is the core data containing the traffic steering logic.
    • precedence (of URSP rule): A numerical value assigned to each URSP rule. The UE evaluates rules in order of precedence (typically, lower value means higher priority). The first rule (highest priority) whose Traffic Descriptor matches the outgoing traffic is selected, and its Route Selection Descriptor is applied.
    • traffic description components: These are the specific criteria within a URSP rule used to match outgoing application traffic. A rule can contain one or more components. Traffic matches if it meets the criteria defined by these components.
      • match all: A component that acts as a wildcard. If present in a rule's Traffic Descriptor, it matches *any* outgoing traffic. This is typically used for default rules with the lowest precedence.
      • os-id-os-app-id: A combination used to identify a specific application running on a specific operating system.
        • os-id: A unique identifier for the Operating System (e.g., Android, iOS).
        • os-app-id: The identifier of the application within that OS (e.g., `com.example.myapp` on Android, Bundle ID on iOS). This allows rules to target traffic from specific apps.
      • ipv4-remote-address: Matches traffic based on the destination IPv4 address or prefix.
      • ipv6-remote-address: Matches traffic based on the destination IPv6 address or prefix.
      • protocol-id: Matches traffic based on the transport layer protocol number (e.g., 6 for TCP, 17 for UDP).
      • remote-port: Matches traffic based on the destination port number.
      • remote-port-range: Matches traffic based on a range of destination port numbers.
      • security-parameter-index (SPI): Used in IPsec contexts. Matches traffic based on the SPI value in the IPsec header.
      • type of service / traffic class: Matches traffic based on the DSCP (Differentiated Services Code Point) value in the IP header (IPv4 Type of Service or IPv6 Traffic Class field).
      • flow label: Matches traffic based on the Flow Label value in the IPv6 header.
      • destination mac address: Matches traffic based on the destination MAC address (relevant for Ethernet PDU sessions).
      • 802.1q-ctag-vid: Matches Ethernet traffic based on the Customer VLAN ID (C-VID) in the 802.1Q tag.
      • 802.1q-stag-vid: Matches Ethernet traffic based on the Service VLAN ID (S-VID) in the 802.1Q tag.
      • 802.1q-ctag-pcp-dei: Matches Ethernet traffic based on the Priority Code Point (PCP) and Drop Eligible Indicator (DEI) in the Customer VLAN tag.
      • 802.1q-stag-pcp-dei: Matches Ethernet traffic based on the Priority Code Point (PCP) and Drop Eligible Indicator (DEI) in the Service VLAN tag.
      • ethertype: Matches Ethernet traffic based on the EtherType field (e.g., 0x0800 for IPv4, 0x86DD for IPv6).
      • dnn (Data Network Name): Matches based on the DNN requested by the application or associated with the traffic.
      • connection capabilities: Allows matching based on certain required network capabilities (e.g., low latency). The application might indicate these needs to the OS/UE.
      • destination-fqdn: Matches traffic based on the destination Fully Qualified Domain Name (FQDN) being requested (e.g., `www.google.com`).
      • os-app-id (standalone): Matches based on the application ID, potentially without specifying the OS-ID if it's unambiguous or applicable across OS types supported by the UE.
      • destination-mac-address-range: Matches traffic based on a range of destination MAC addresses (relevant for Ethernet PDU sessions).
    • route list (Route Selection Descriptor list): This contains one or more Route Selection Descriptors (RSDs), each defining a potential way to route the traffic that matched the Traffic Descriptor part of the rule. The UE evaluates these RSDs in order of precedence.
      • precedence (of RSD): Each RSD within the list has a precedence value. The UE tries to satisfy the RSDs in order (highest priority first). For example, it might first try to route via a specific slice; if that fails or isn't possible, it moves to the next RSD in the list, which might specify using a particular DNN.
      • components (of RSD): The specific parameters within a Route Selection Descriptor that define the preferred routing action.
        • ssc-mode (Session and Service Continuity Mode): Specifies the preferred SSC mode (1, 2, or 3) for the PDU Session used for this traffic.
        • snssai (Single Network Slice Selection Assistance Information): Specifies the preferred Network Slice (combination of SST and optional SD) to route the traffic over.
          • sst (Slice/Service Type): Defines the main type of service the slice provides (e.g., eMBB, URLLC, MIoT).
          • sd (Slice Differentiator): An optional identifier to differentiate between slices of the same SST.
        • dnn (Data Network Name): Specifies the preferred DNN to use for the PDU Session handling this traffic.
        • pdu session type: Specifies the preferred PDU session type (IPv4, IPv6, IPv4v6, Ethernet, Unstructured).
        • multi access preference (ATSSS preference): Indicates preferences related to Access Traffic Steering, Switching, and Splitting (ATSSS), defining how 3GPP and non-3GPP access should be used (e.g., prefer non-3GPP, prefer multi-access, disallowed, etc.).

Reference :

• 3GPP 23-503 : 5G; Policy and charging control framework for the 5G System (5GS)
• 3GPP 24-526 : 5G; User Equipment (UE) policies for 5G System (5GS);
• NG.141 Guidelines for URSP - GSMA
• Enhance differentiated service experience with slicing using URSP - Nokia