A 5G UE has more than one way to carry almost any piece of traffic. It can open a new PDU session or reuse an existing one, ask for a particular slice, or send the traffic over a non-3GPP access instead. Something has to decide, and the decision is not made in the UE.

The network hands the UE a rule set in advance, and the UE applies it locally when an application asks for a connection. Those rules are UE policies. This page covers how they reach the UE and what they are made of, and the worked message dump lives on the Mange UE Policy Command page.

• Policy Management in Detail
• Message Structure
• UE Policy Part Types
• Reference

Policy Management in Detail

The question this answers is narrow. Given a UE that could route an application over several different paths, how does the operator express a preference once, rather than negotiating it every time a connection is opened ? Signalling per flow would be far too expensive, so the preference is pushed to the UE as a rule set and evaluated there.

Three functions are involved and each does one thing. The PCF owns the policies and decides what the UE should hold. The AMF carries them, because a policy is NAS payload and the AMF is the NAS endpoint. The UE stores them, re-assembles them, and applies them when an application asks for a connection.

The policies are not sent as one block. They are split into UE policy sections, and each section is named by a UPSI, which carries a PLMN ID part and a UPSC. That naming is what lets the network add, modify or delete one section without resending the rest. It is also why the UE can report which sections it already holds.

Two details in 24.501 Annex D exist because of that split. Clause D.3 covers UE policy re-assembly at the UE, since one policy can arrive across several messages. Clause D.1.2 sets out the PTI handling rules, because several policy transactions can be outstanding at once and each needs its own identity.

• The delivery service and the policy contents are separate specifications : 24.501 Annex D moves the bytes, and 24.526, 24.588 and others say what the bytes mean.
• The PCF decides and the AMF only carries : the policy travels as NAS payload in a UE policy container, so the AMF does not need to understand it.
• Policies are sectioned, not monolithic : a UPSI names each section, so an update can touch one section and leave the others alone.
• A UPSI has two parts : a PLMN ID part and a UPSC, which is what ties a section to the network that issued it.
• Re-assembly is a defined step : clause D.3 exists because a policy can be larger than one message.
• The UE can start the exchange too : the UE-initiated UE state indication procedure reports which sections the UE already holds.

Message Structure

Four messages make up the whole delivery service, and they split cleanly by direction. One travels from the network to the UE and carries the policy itself. The other three travel from the UE, and each carries one answer : the policy was applied, part of it failed, or these are the sections already held.

In this section the overall message structure and functionalities of important IE (Information Element) will be explained.

MANAGE UE POLICY COMMAND

The outline below follows the message down to the field that decides everything else. Read it as a nesting rather than a list. Each level is one information element, and the figure or table number beside it is where 24.501 draws that level.

MANAGE UE POLICY COMMAND (24.501 - D.5.1.1)

PTI (24.501 - 9.6)

MANAGE UE POLICY COMMAND message identity (24.501 - D.6.1)

UE policy section management list (24.501 -D.6.2)

• UE policy section management list information element (24.501-Figure D.6.2.1)
• UE policy section management list contents (24.501-Figure D.6.2.2)
• UE policy section management sublist (24.501-Figure D.6.2.3)
• UE policy section management sublist contents (24.501-Figure D.6.2.4)
• Instruction (24.501-Figure D.6.2.5)
• UE policy section contents (24.501-Figure D.6.2.6)
• UE policy part (24.501-Figure D.6.2.7)
• UE policy section management list information element (24.501-Table D.6.2.1)
• UE policy part type
• Reserved
• URSP (24.526-5.2, 23.503-Annex A)
• ANDSP (24.526-5.3)
• V2XP (24.588-5.2)

The bottom of that nesting is the UE policy part, and its type field is the branch point. Everything above it is the same for every policy, and everything below it is defined somewhere else entirely. A decoder can stop at the type field and still have read all of 24.501 that applies.

The instruction level is worth noticing as well. One MANAGE UE POLICY COMMAND carries a list of instructions, and each is acknowledged or rejected on its own. That is why the reject message reports a failed instruction order rather than simply failing the message.

• The list nests three deep before any policy appears : management list, then sublist, then instruction, then UE policy section contents.
• Instructions succeed or fail individually : the reject message names the order of the instruction that failed, so a partial failure is reportable.
• The UE policy part type is the branch point : it selects which other specification decodes the bytes that follow.
• PTI ties a response to its command : the procedure transaction identity is what lets more than one policy transaction be outstanding.
• A worked capture is on the neighbouring page : the DL NAS Transport carrying the command and the UL NAS Transport carrying the complete are decoded there.

UE Policy Part Types

The type field at the bottom of that structure is a small number, and each value hands the rest of the octets to a different specification. This is where the delivery service stops and the policy itself begins, so it is also where a reader has to change document.

URSP is the one most readers meet first, and its shape is worth stating. A URSP rule carries a precedence value, one traffic descriptor, and one or more route selection descriptors, each of which carries its own precedence value. The traffic descriptor decides whether a rule applies at all, and the route selection descriptors then decide how the traffic is carried.

The precedence convention is counter-intuitive, so it is worth reading twice. A lower precedence value means higher priority. Only one URSP rule may be the default rule, that rule has to carry a match-all traffic descriptor, and every non-default rule must have a lower precedence value than it. The default rule is therefore evaluated last.

• Six types are defined : URSP, ANDSP, V2XP, ProSeP, RSLPP and A2XP, and 24.501 names the owning specification for each.
• Two of them live in the same document : 24.526 carries URSP in clause 5.2 and ANDSP in clause 5.3.
• A URSP rule has three parts : a precedence value, one traffic descriptor, and one or more route selection descriptors.
• Lower precedence value wins : rules and route selection descriptors are both evaluated in increasing order of that value.
• The default rule matches everything and is checked last : it carries a match-all traffic descriptor, and every other rule outranks it.
• ANDSP covers more than WLAN : clause 5.3 encodes WLANSP and the N3AN node configuration information together.

Reference

[1] 24.501 v20.0.0 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). Annex D is the UE policy delivery service, with the procedures in D.2, the messages in D.5 and the information elements in D.6.

[2] 24.526 v19.4.0 : UE policies for 5GS. Clause 4.2 introduces URSP and clause 4.3 introduces ANDSP, and clauses 5.2 and 5.3 encode them.

[3] 24.588 : Vehicle-to-Everything (V2X) services in 5GS. Clause 5.2 encodes the V2XP UE policy part.

[4] 23.503 : Policy and charging control framework for the 5G System. Annex A holds the URSP rule definition referenced from the outline above.