ETSI TS 124 526 V15.3.0 (2019-07)

TECHNICAL SPECIFICATION
5G;
User Equipment (UE) policies for 5G System (5GS);
Stage 3
(3GPP TS 24.526 version 15.3.0 Release 15)

3GPP TS 24.526 version 15.3.0 Release 15 1 ETSI TS 124 526 V15.3.0 (2019-07)

Reference
RTS/TSGC-0124526vf30
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 2 ETSI TS 124 526 V15.3.0 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 3 ETSI TS 124 526 V15.3.0 (2019-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 4
1 Scope . 5
2 References . 5
3 Definitions, symbols and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Descriptions of UE policies for 5GS . 6
4.1 Overview . 6
4.2 UE route selection policy (URSP) . 7
4.2.1 General . 7
4.2.2 Association between an application and either a PDU session or non-seamless non-3GPP offload . 8
4.2.3 Unknown or unexpected URSP rules. 10
4.3 Access network discovery and selection policy (ANDSP) . 10
4.3.1 Overview . 10
4.3.2 WLAN selection policy (WLANSP) . 10
4.3.2.1 General . 10
4.3.2.2 WLAN access selection . 12
4.3.3 N3AN node configuration information . 12
4.3.3.1 General . 12
4.3.3.2 N3AN node selection . 12
4.4 Interworking with EPC . 12
5 Encoding of UE policies. 13
5.1 Overview . 13
5.2 Encoding of UE policy part type URSP . 13
5.3 Encoding of UE policy part type ANDSP . 19
5.3.1 General . 19
5.3.2 Encoding of WLANSP . 20
5.3.3 Encoding of N3AN node configuration information . 35
5.3.3.1 General . 35
5.3.3.2 N3AN node selection information . 36
5.3.3.3 Home N3IWF identifier configuration . 37
5.3.3.4 Home ePDG identifier configuration . 38
Annex A (informative): Change history . 41
History . 42

ETSI
3GPP TS 24.526 version 15.3.0 Release 15 4 ETSI TS 124 526 V15.3.0 (2019-07)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 5 ETSI TS 124 526 V15.3.0 (2019-07)
1 Scope
The present document defines UE policies for 5G System (5GS) as specified in 3GPP TS 23.503 [2] including:
- UE route selection policy; and
- Access network discovery and selection policy.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 23.503: " Policy and Charging Control Framework for the 5G System; Stage 2".
[3] 3GPP TS 24.502: "Access to the 3GPP 5G Core Network (5GCN) via Non-3GPP Access
Networks (N3AN); Stage 3".
[4] 3GPP TS 23.003: "Numbering, addressing and identification".
[5] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification".
[6] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource
Control (RRC); Protocol specification".
[7] 3GPP TS 23.032: "Universal Geographical Area Description (GAD)".
[8] IEEE Std 802.11™-2012: "Information Technology- Telecommunications and information
exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications".
[9] Wi-Fi Alliance: "Hotspot 2.0 (Release 2) Technical Specification, version 1.0.0", 2014-08-08.
[10] ITU-T Recommendation E.212: "The international identification plan for public networks and
subscriptions", 2016-09-23.
[11] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
[12] IETF RFC 1035: "Domain names - implementation and specification".
[13] ISO 8601:2004: "Data elements and interchange formats -- Information interchange --
Representation of dates and times".
[14] 3GPP TS 38.413: "NG-RAN; NG Application Protocol (NGAP)".
[15] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[16] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 6 ETSI TS 124 526 V15.3.0 (2019-07)
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1]apply. A term defined
in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 [1].
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.501 [15] apply:
non-seamless non-3GPP offload
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.503 [2] apply:
UE local configuration
For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.501 [11] apply:
5GMM-IDLE mode
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
5GCN 5G Core Network
5GS 5G System
ANDSP Access Network Discovery and Selection Policy
DNN Data Network Name
ePDG evolved Packet Data Gateway
FQDN Fully Qualified Domain Name
H-PCF A PCF in the HPLMN
IMS IP Multimedia Subsystem
LADN Local Area Data Network
MCC Mobile Country Code
ME Mobile Equipment
MMS Multimedia Messaging Service
MNC Mobile Network Code
N3AN Non-3GPP Access Network
N3IWF Non-3GPP InterWorking Function
OS Operating System
PCF Policy Control Function
S-NSSAI Single Network Slice Selection Assistance Information
SSC Session and Service Continuity
SUPI Subscriber Permanent Identifier
SUPL Secure User Plane Location
URSP UE Route Selection Policy
USIM User Services Identity Module
V-PCF A PCF in the VPLMN
WLANSP WLAN Selection Policy
4 Descriptions of UE policies for 5GS
4.1 Overview
The UE policies for 5GS include:
- UE route selection policy(URSP)(see subclause 4.2); and
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 7 ETSI TS 124 526 V15.3.0 (2019-07)
- Access network discovery and selection policy(ANDSP)(see subclause 4.3).
The UE policies can be delivered from the PCF to the UE. The UE policy delivery procedure is specified in
3GPP TS 24.501 [11].
The UE policies can also be pre-configured in the UE. The pre-configured policy shall be applied by the UE only when
the UE has not received the same type of policy from the PCF. The implementation of pre-configured UE policies is out
of scope of this specification.
4.2 UE route selection policy (URSP)
4.2.1 General
The URSP is defined in 3GPP TS 23.503 [2] and is a set of one or more URSP rules, where a URSP rule is composed
of:
a) a precedence value of the URSP rule identifying the precedence of the URSP rule among all the existing URSP
rules;
b) a traffic descriptor, including either:
1) match-all traffic descriptor; or
2) at least one of the following components:
A) one or more application identifiers;
B) one or more IP 3 tuples as defined in 3GPP TS 23.503 [2] i.e. the destination IP address, the destination
port number, and the protocol in use above the IP;
C) one or more non-IP descriptors, i.e. destination information of non-IP traffic;
D) one or more DNNs;
E) one or more connection capabilities; and
F) one or more domain descriptors, i.e. destination FQDN(s); and
c) one or more route selection descriptors each consisting of a precedence value of the route selection descriptor
and either
1) at least one of the followings:
A) SSC mode;
B) one or more S-NSSAIs;
C) one or more DNNs;
D) PDU session type; and
E) preferred access type; or
2) non-seamless non-3GPP offload indication.
Only one URSP rule in the URSP can be a default URSP rule and the default URSP rule shall contain a match all traffic
descriptor. If a default URSP rule and one or more non-default URSP rules are included in the URSP, any non-default
URSP rule shall have lower precedence value than (i.e. shall be prioritised over) the default URSP rule.
If a traffic descriptor lists one or more application identifiers together with one or more connection capabilities, the UE
shall consider that the application identifiers identify the applications requesting access to the connection capabilities.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 8 ETSI TS 124 526 V15.3.0 (2019-07)
NOTE 1: The connection capabilities requested by the applications are OS dependent. The connection capability
identifiers defined in table 5.2.1 are OS independent. It is based on the UE implementation how the UE
matches the connection capabilities requested by the applications to the connection capability identifiers
in table 5.2.1.
NOTE 2: If the UE has multiple concurrently active OS, the traffic descriptor can list as many multiple OS Ids.
If one or more DNNs are included in the traffic descriptor of a URSP rule, the route selection descriptor of the URSP
rule shall not include any DNN.
NOTE 3: It is recommended to avoid the combination of more than two components in the traffic descriptor.
4.2.2 Association between an application and either a PDU session or
non-seamless non-3GPP offload
When the upper layers request information of the PDU session via which to send a PDU of an application, information
on the non-3GPP access outside of a PDU session shall be provided to the upper layers, without evaluating the URSP
rules, if due to UE local configuration non-seamless non-3GPP offload is requested. Otherwise, the UE shall proceed in
the following order:
a) the UE shall evaluate the URSP rules, except the default URSP rule, with a traffic descriptor matching the
application information in increasing order of their precedence values, if any. If the traffic descriptor contains
more than one component, all of them shall be matched.
If the UE finds the traffic descriptor in a non-default URSP rule matching the application information, and:
I) if there is one or more PDU sessions:
1) matching at least one of the route selection descriptors of the URSP rule; and
2) established without requesting any parameter not included in the matching route selection descriptor of
the URSP rule,
the UE shall provide information on the PDU session that matches the route selection descriptor of the lowest
precedence value to the upper layers;
NOTE 1: It is up to the UE implementation which PDU session to select if there exist multiple PDU sessions
matching the same route selection descriptor of the lowest precedence value.
II) otherwise:
1) the UE shall select a route selection descriptor with the next smallest precedence value which has not yet
been evaluated;
2) if:
i) the selected route selection descriptor contains a non-seamless non-3GPP offload indication:
A) if the information on the non-3GPP access outside of a PDU session is available, it shall be
provided to the upper layers and the UE shall stop selecting a route selection descriptor matching
the application information.
B) if the information about the non-3GPP access outside of a PDU session is not available, or non-
3GPP access is not available the UE shall proceed to step 4); or
ii) the selected route selection descriptor does not contain a non-seamless non-3GPP offload indication,
the URSP handling layer requests the UE NAS layer to establish a PDU session providing at least one
of the following PDU session attributes:
A) SSC mode if there is a SSC mode in the route selection descriptor;
NOTE 2: The SSC mode 3 is only used when the PDU session type is IPv4, IPv6 or IPv4v6.
B) one S-NSSAI if the S-NSSAI is in the route selection descriptor; and the S-NSSAI is in the
allowed NSSAI
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 9 ETSI TS 124 526 V15.3.0 (2019-07)
Otherwise, the S-NSSAI shall not be used as a PDU session attribute for establishing a PDU
session;
NOTE 3: If there are multiple S-NSSAIs in the route selection descriptor, an S-NSSAI is chosen among the S-
NSSAIs based on UE implementation.
C) one DNN, if the DNN in the route selection descriptor; and if the DNN is an LADN DNN and the
UE is in the service area of that LADN;
NOTE 4: If one or more DNNs are included in the traffic descriptor of a URSP rule, the existing DNNs in the route
selection descriptor for the application are ignored.
NOTE 5: If there is no DNN in the traffic descriptor and there are multiple DNNs in the route selection descriptor,
a DNN is chosen based on UE implementation.
D) PDU session type if the PDU session type is in the route selection descriptor; and
E) preferred access type if the preferred access type is in the route selection descriptor.
The UE NAS layer indicates the result of the PDU session establishment. Upon successful completion
of the PDU session establishment, the UE NAS layer shall additionally indicate the attributes of the
established PDU session (e.g. PDU session identity, SSC mode, S-NSSAI, DNN, PDU session type,
access type, PDU address) to the URSP handling layer, and shall provide information (e.g. PDU
address) of the successfully established PDU session to the upper layers. The UE shall stop selecting a
route selection descriptor matching the application information. If the PDU session establishment is
unsuccessful, the UE shall proceed to step 3);
3) Based on the rejection cause and if there is another value which can be used for the rejected component in
the same route selection descriptor, the UE shall select another combination of values in the currently
selected route selection descriptor by using this value of the rejected component and proceed to step 2),
otherwise the UE shall proceed to step 4); and
4) if there is any route selection descriptor which has not yet been evaluated, the UE shall proceed to step 1).
If all route selection descriptors for the matching non-default URSP rule have been evaluated and there is
one or more non-default matching URSP rule which has not yet been evaluated, the UE shall proceed to
step a). If all non-default matching URSP rules have been evaluated, the UE shall inform the upper layers
of the failure.
b) if no non-default matching URSP rule can be found and if UE local configuration for the application is available,
the UE shall perform the association of the application to a PDU session accordingly. If no matching PDU
session exists, the UE NAS layer shall attempt to establish a PDU session using UE local configuration.
NOTE 6: Any missing information in the UE local configuration needed to build the PDU session establishment
request can be the appropriate corresponding component from the default URSP rule with the "match-all"
traffic descriptor.
If the PDU session establishment is successful, the UE NAS layer shall provide information (e.g. PDU address)
of the successfully established PDU session to the upper layers. Otherwise, the UE shall go to step c);
c) if no non-default matching URSP rule can be found and if either UE local configuration for the application is not
available or the PDU session establishment based on UE local configuration for the application was
unsuccessful, the UE shall perform the association of the application to a PDU session or to non-seamless non-
3GPP offload according to the default URSP rule with the "match-all" traffic descriptor, if any. If the association
is unsuccessful, the UE shall inform the upper layers of the failure.
The HPLMN may pre-configure the UE with URSP or may provide URSP to the UE by signallingas described in
annex D of 3GPP TS 24.501 [11]. The pre-configured URSP and the signalled URSP shall be stored in a non-volatile
memory in the ME together with the SUPI from the USIM. If the UE has both pre-configured URSP and signalled
URSP, the UE shall only use the signalled URSP. The pre-configured URSP shall be stored until a new URSP is
configured by HPLMN or the USIM is removed. The signalled URSP may be modified by the procedures defined in
annex D of 3GPP TS 24.501 [11] and shall be stored until USIM is removed. The URSP can only be used if the SUPI
from the USIM matches the SUPI stored in the non-volatile memory of the ME. If the SUPI from the USIM does not
match the SUPI stored in the non-volatile memory of the ME, the UE shall delete the URSP.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 10 ETSI TS 124 526 V15.3.0 (2019-07)
The UE may re-evaluate the URSP rules, to check if the change of the association of an application to a PDU session is
needed, when:
NOTE 7: The time when the UE performs the re-evaluation is up to UE implementation. It is recommended that the
UE performs the re-evaluation in a timely manner.
a) the UE performs periodic URSP rules re-evaluation based on UE implementation;
b) the UE NAS layer indicates that an existing PDU session used for routing traffic of an application based on a
URSP rule is released;
c) the URSP is updated by the PCF;
d) the UE NAS layer indicates that the UE performs inter-system change from S1 mode to N1 mode;
e) the UE NAS layer indicates that the UE is successfully registered in N1 mode over 3GPP access or non-3GPP
access;
f) the UE establishes or releases a connection to a WLAN access and transmission of a PDU of the application via
non-3GPP access outside of a PDU session becomes available/unavailable;
g) the allowed NSSAI is changed; or
h) the LADN information is changed.
If the re-evaluation leads to a change of the association of an application to a PDU session, the UE may enforce such
change immediately or when UE returns to 5GMM-IDLE mode.
NOTE 8: The time when the UE enforces the change of the association of an application to a PDU Session is up to
UE implementation. It is recommended that the UE performs the enforcement in a timely manner.
The URSP handling layer may request the UE NAS layer to release an existing PDU session after the re-evaluation.
4.2.3 Unknown or unexpected URSP rules
If the network provides URSP rules including any new component in the traffic descriptor or in the route selection
descriptor which is not recognized by the UE, such URSP rules are unknown or unexpected to the UE. In this case, the
UE shall ignore the unknown or unexpected URSP rules when evaluating the URSP rules to associate an application
either with a PDU session or with non-seamless non-3GPP offload.
4.3 Access network discovery and selection policy (ANDSP)
4.3.1 Overview
The ANDSP is used to control UE behaviour related to access network discovery and selection over non-3GPP access
network.
ANDSP consists of:
- WLAN Selection Policy (WLANSP) which is described in subclause 4.3.2.; and
- non-3GPP access network (N3AN) node configuration information which is described in subclause 4.3.3.
4.3.2 WLAN selection policy (WLANSP)
4.3.2.1 General
The WLANSP is used to control UE behaviour related to selection and reselection of a WLAN.
The WLANSP consists of zero or more WLANSP rules.
Each WLANSP rule consists of:
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 11 ETSI TS 124 526 V15.3.0 (2019-07)
- rule identifier;
- one or more groups of WLAN selection criteria;
- validity area;
- zero or more time of day;
- rule priority;
- roaming.
Each group of WLAN selection criteria contains:
- criteria priority;
- home network indication;
- preferred roaming partner list;
- min backhaul threshold;
- maximum BSS load value;
- required proto port tuple;
- SP exclusion list; and
- preferred SSID list.
The priority of a selection criteria is encoded in the criteria priority field. The WLAN priority defined in the preferred
SSID list (see figure 5.3.2.4c) represents the priority of the WLAN matching the selection criteria.
The validity of the WLANSP rule can be restricted by validity conditions. The validity of the WLANSP rule takes into
account validity area, roaming, and time of day where each condition shall match in order to make the WLANSP rule
valid.
Each validity area consists of:
- 3GPP location;
- WLAN location; and
- Geo location.
Each time of day consists of:
- time start;
- time stop;
- date start;
- date stop; and
- day of week.
The WLANSP rule is considered valid if none of the validity conditions exist or all validity conditions match.
There can be multiple valid WLANSP rules at the same time. In addition to validity conditions and selection criteria,
there is a rule priority that shall be set for each WLANSP rule. The rule priority is encoded in the rule priority field, and
it enables the UE to determine which WLANSP rule, out of potentially several valid WLANSP rules, it should consider
as active. A WLANSP rule is active if it is valid and has highest rule priority out of the valid WLANSP rules. At any
point in time, there shall be at most one active WLANSP rule. A WLAN that matches a selection criteria of the active
WLANSP rule is considered as matching the selection criteria.
If the UE is roaming and WLANSP rules from both HPLMN and VPLMN are available, visited WLANSP rules shall
take precedence.
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 12 ETSI TS 124 526 V15.3.0 (2019-07)
4.3.2.2 WLAN access selection
The procedure of UE selecting WLAN access network based on WLAN selection policy is specified in
3GPP TS 24.502 [3].
4.3.3 N3AN node configuration information
4.3.3.1 General
Non-3GPP access network (N3AN) node configuration information is used to control UE behaviour related to selection
of either N3IWF or ePDG for accessing 5GCN via non-3GPP access.
The non-3GPP access network (N3AN) node configuration information consists of:
- Non-3GPP access network (N3AN) node selection information;
- optionally, home ePDG identifier configuration; and
- optionally, home N3IWF identifier configuration.
4.3.3.2 N3AN node selection
The procedure of UE selecting an N3AN node based on N3AN node configuration information is specified in
3GPP TS 24.502 [3].
4.4 Interworking with EPC
If the UE supports both S1 mode and N1 mode:
- the UE shall always use the ANDSP information and applicable user preferences, if available at the UE, for non-
3GPP access node selection;
NOTE: This includes the case when the UE is registered to the 5GCN via 3GPP access, the case when the UE is
registered to the EPC via 3GPP access, and the case when the UE is not registered to any CN via 3GPP
access.
- if the UE is:
a) registered to the 5GCN via 3GPP access and not registered to any CN via non-3GPP access; or
b) registered to the 5GCN via 3GPP access and registered to the 5GCN via non-3GPP access,
the UE shall apply URSP rules and applicable user preferences, if available at the UE, to all uplink user data;
- if the UE is registered to the 5GCN via 3GPP access and registered to the EPC via non-3GPP access, the UE
shall:
a) use the ANDSF rules and RAN rules, if available at the UE, for uplink user data sent via the ePDG; and
b) apply URSP rules and applicable user preferences, if available at the UE, to all other uplink user data;
- if the UE is:
a) registered to the EPC via 3GPP access and not registered to any CN via non-3GPP access; or
b) registered to the EPC via 3GPP access and registered to the EPC via non-3GPP access,
the UE shall use the ANDSF rules and RAN rules, if available at the UE, for all uplink user data, except for the
rules and parameters related to non-3GPP access node selection; and
- if the UE is registered to the EPC via 3GPP access and registered to the 5GCN via non-3GPP access, the UE
shall:
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 13 ETSI TS 124 526 V15.3.0 (2019-07)
a) apply URSP rules and applicable user preferences, if available at the UE, to uplink user data sent via the
N3IWF; and
b) use the ANDSF rules and RAN rules, if available at the UE, for all other uplink user data, except for the rules
and parameters related to non-3GPP access node selection.
5 Encoding of UE policies
5.1 Overview
The content of UE policies is included in the UE policy part contents defined in annex D.6.2 of 3GPP TS 24.501 [11].
The UE policy part contents include URSP or ANDSP.
For URSP definition, the encoding is defined in subclause 5.2.
For ANDSP definition, it includes encoding of WLANSP and encoding of N3AN node configuration information. The
encoding of WLANSP is defined in subclause 5.3.2. The encoding of N3AN node configuration information is defined
in subclause 5.3.3.
5.2 Encoding of UE policy part type URSP
The UE policy part type URSP contains one or more URSP rules which may be included in the UE policy part contents
as defined in annex D.6.2 of 3GPP TS 24.501 [11].
If the UE policy part contents includes one or more URSP rules (i.e. the UE policy part type field is set to "URSP"), the
UE policy part contents including URSP rules is encoded as shown in figures 5.2.1 to 5.2.4 and table 5.2.1.
8 7 6 5 4 3 2 1
octet q+3
URSP rule 1
octet s
octet s+1*
URSP rule 2
octet t*
octet t+1*
…
octet u*
octet u+1*
URSP rule n
octet r*
Figure 5.2.1: UE policy part contents including one or more URSP rules
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 14 ETSI TS 124 526 V15.3.0 (2019-07)
8 7 6 5 4 3 2 1
octet v
Length of URSP rule
octet v+1
Precedence value of URSP rule octet v+2
octet v+3
Length of traffic descriptor
octet v+4
octet v+5
Traffic descriptor
octet w
octet w+1
Length of route selection descriptor list
octet w+2
octet w+3
Route selection descriptor list

octet x
Figure 5.2.2: URSP rule
8 7 6 5 4 3 2 1
octet w+3
Route selection descriptor 1
octet y
octet y+1*
Route selection descriptor 2
octet z*
octet z+1*
…
octet a*
octet a+1*
Route selection descriptor m
octet x*
Figure 5.2.3: Route selection descriptor list
8 7 6 5 4 3 2 1
octet b
Length of route selection descriptor
octet b+1
Precedence value of route selection descriptor octet b+2
octet b+3
Length of route selection descriptor contents
octet b+4
octet b+5
Route selection descriptor contents
octet c
Figure 5.2.4: Route selection descriptor
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 15 ETSI TS 124 526 V15.3.0 (2019-07)
Table 5.2.1: UE policy part contents including a URSP rule
ETSI
3GPP TS 24.526 version 15.3.0 Release 15 16 ETSI TS 124 526 V15.3.0 (2019-07)
Precedence value of URSP rule (octet v+2)
The precedence value of URSP rule field is used to specify the precedence of the
URSP rule among all URSP rules in the URSP. This field includes the binary encoded
value of the precedence value in the range from 0 to 255 (decimal). The higher the
value of the precedence value field, the lower the precedence of the URP rule is.
Multiple URSP rules in the URSP shall not have the same precedence value.

Traffic descriptor (octets v+5 to w)
The traffic descriptor field is of variable size and contains a variable number (at least
one) of traffic descriptor components. Each traffic descriptor component shall be
encoded as a sequence of one octet traffic descriptor component type identifier and a
traffic descriptor component value field. The traffic descriptor component type identifier
shall be transmitted first.
Traffic descriptor component type identifier
Bits
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 1 Match-all type
0 0 0 0 1 0 0 0 OS Id + OS App Id type (NOTE)
0 0 0 1 0 0 0 0 IPv4 remote address type
0 0 1 0 0 0 0 1 IPv6 remote address/prefix length type
0 0 1 1 0 0 0 0 Protocol identifier/next header type
0 1 0 1 0 0 0 0 Single remote port type
0 1 0 1 0 0 0 1 Remote port range type
0 1 1 0 0 0 0 0 Security parameter index type
0 1 1 1 0 0 0 0 Type of service/traffic class type
1 0 0 0 0 0 0 0 Flow label type
1 0 0 0 0 0 0 1 Destination MAC address type
1 0 0 0 0 0 1 1 802.1Q C-TAG VID type
1 0 0 0 0 1 0 0 802.1Q S-TAG VID type
1 0 0 0 0 1 0 1 802.1Q C-TAG PCP/DEI type
1 0 0 0 0 1 1 0 802.1Q S-TAG PCP/DEI type
1 0 0 0 0 1 1 1 Ethertype type
1 0 0 0 1 0 0 0 DNN type
1 0 0 1 0 0 0 0 Connection capabilities type
1 0 0 1 0 0 0 1 Destination FQDN
1 0 1 0 0 0 0 0 OS App Id type
All other values are spare.
For "match-all type", the traffic descriptor component shall not include the traffic
descriptor component value field. The "match-all type" traffic descriptor component
shall not appear more than once among all traffic descriptors of the whole URSP rules
in the URSP. If the "match-all type" traffic descriptor component is included in a traffic
descriptor, there shall be no traffic descriptor component with a type other than "match-
all type" in the traffic descriptor.

For "OS Id + OS App Id type", the traffic descriptor component value field shall be
encoded as a sequence of a sixteen octet OS Id field, a one octet OS App Id length
field, and an OS App Id field. The OS Id field shall be transmitted first. The OS Id field
contains a Universally Unique IDentifier (UUID) as specified in IETF RFC 4122 [16].

For "IPv4 remote address type", the traffic descriptor component value field shall be
encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address
mask field. The IPv4 address field shall be transmitted first.

For "IPv6 remote address/prefix length type", the traffic descriptor component value
field shall be encoded as a sequence of a sixteen octet IPv6 address field and one
octet prefix length field. The IPv6 address field shall be transmitted first.

For "protocol identifier/next header type", the traffic descriptor component value field
shall be encoded as one octet which specifies the IPv4 protocol identifier or Ipv6 next
header.
For "single remote port type", the traffic descriptor component value field shall be
encoded as two octets which specify a port number.

ETSI
3GPP TS 24.526 version 15.3.0 Release 15 17 ETSI TS 124 526 V15.3.0 (2019-07)
For "remote port range type", the traffic descriptor component value field shall be
encoded as a sequence of a two octet port range low limit field and a two octet port
range high limit field. The port range low limit field shall be transmitted first.

For "security parameter index type", the traffic descriptor component value field shall
be encoded as four octets which specify the IPSec security parameter index.

For "type of service/traffic class type", the traffic descriptor component value field shall
be encoded as a sequence of a one octet type-of-service/traffic class field and a one
octet type-of-service/traffic class mask field. The type-of-service/traffic class field shall
be transmitted first.
For "flow label type", the traffic descriptor component value field shall be encoded as
three octets which specify the IPv6 flow label. The bits 8 through 5 of the first octet
shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label.

For "destination MAC address type", the traffic descriptor component value field shall
be encoded as 6 octets which specify a MAC address.

For "802.1Q C-TAG VID type", the traffic descriptor component value field shall be
encoded as two octets which specify the VID of the customer-VLAN tag (C-TAG). The
bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall
contain the VID.
For "802.1Q S-TAG VID type", the traffic descriptor component value field shall be
encoded as two octets which specify the VID of the service-VLAN tag (S-TAG). The
bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall
contain the VID.
For "802.1Q C-TAG PCP/DEI type", the traffic descriptor component value field shall
be encoded as one octet which specifies the 802.1Q C-TAG PCP and DEI. The bits 8
through 5 of the octet shall be spare, and the bits 4 through 2 contain the PCP and bit
1 contains the DEI.
For "802.1Q S-TAG PCP/DEI type", the traffic descriptor component value field shall be
encoded as one octet which specifies the 802.1Q S-TAG PCP. The bits 8 through 5 of
the octet shall be spare, and the bits 4 through 2 contain the PCP and bit 1 contains
the DEI.
For "ethertype type", the traffic descriptor component value field shall be encoded as
two octets which specify an ethertype.

For "DNN type", the traffic descriptor component value field shall be encoded as a
sequence of a one octet DNN length field and a DNN value field of a variable size. The
DNN value contains an APN as defined in 3GPP TS 23.003 [4].

For "connection capabilities” type, the traffic descriptor component value field shall be
encoded as a sequence of one octet for number of network capabilities followed by one
or more octets, each containing a connection capability identifier encoded as follows:
Bits
8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 1 IMS
0 0 0 0 0 0 1 0 MMS
0 0 0 0 0 1 0 0 SUPL
0 0 0 0 1 0 0 0 Internet
All other values are spare.
For "destination FQDN" type, the traffic descriptor component value field shall be
encoded as a sequence of one octet destination FQDN length field and a destination
FQDN value of variable size. The destination FQDN value field shall be encoded as
defined in IETF RFC 1035 [12].

For "OS App Id type", the traffic descriptor component value field shall be encoded as
a one octet OS App Id length field and an OS App Id field.

ETSI
3GPP TS 24.526 version 15.3.0 Release 15 18 ETSI TS 124 526 V15.3.0 (2019-07)
Precedence value of route selection descriptor (octet b+2)
The precedence value of route selection descriptor field is used to specify the
precedence of the route selection descriptor among all route selection descriptors in
the URSP rule. This field includes the binary encoded value of the precedence value in
the range from 0 to 255 (decimal). The higher the value of the precedence value field,
the lower the precedence of the route selection descriptor is.

Route selection descriptor contents (octets b+5 to c)
The route selection descriptor contents field is of variable size a
...