Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.503  Word version:  18.4.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.2…   6.1.2.4…   6.1.3…   6.1.3.6…   6.1.3.18…   6.1.3.21…   6.1.4…   6.2…   6.2.2…   6.3…   6.4…   6.6…   A…   C   D…

 

6.6  UE policy informationp. 145

6.6.1  Access Network Discovery & Selection Policy Informationp. 145

6.6.1.1  Generalp. 145

The Access Network Discovery & Selection policy is an optional policy that may be provided to UE by the network.
In this release of the specification, the Access Network Discovery & Selection policy shall contain only rules that aid the UE in selecting a WLAN access network. Rules for selecting other types of non-3GPP access networks are not specified.
The WLAN access network selected by the UE with the use of Access Network Discovery & Selection policy may be used for direct traffic offload (i.e. sending traffic to the WLAN outside of a PDU Session) and for registering to 5GC using the non-3GPP access network selection information.
If the UE supports non-3GPP access to 5GC, it shall support ANDSP.
The procedure for WLAN access network selection is defined in clause 6.6.1.3, the procedure for N3IWF selection is defined in clause 6.3.6.1 of TS 23.501.
The Access Network Discovery & Selection policy shall contain one or more WLAN Selection Policy (WLANSP) rules defined in clause 4.8.2.1.6 of TS 23.402.
The Access Network Discovery & Selection policy may contain information to select ePDG or N3IWF by the UE as specified in TS 23.501
Information name Description Category PCF permitted to modify in a UE context Scope
WLANSP rules1 or more WLANSP rules as specified in 4.8.2.1.6 of TS 23.402.MandatoryYesUE context
Extended WLANSP information for network sliceInformation to support TNGF selection based on the S-NSSAI(s) needed by the UE.OptionalYesUE context
ePDG identifier configurationThe UE uses this information to select ePDG as defined in clause 6.3.6.1 of TS 23.501.OptionalYesUE context
N3IWF identifier configurationThe UE uses this information to select N3IWF as defined in clause 6.3.6.1 of TS 23.501.OptionalYesUE context
Extended Home N3IWF identifier configurationThe UE uses this information to select N3IWF based on the slices that the UE intends to access as defined in clause 6.3.6.1 of TS 23.501.OptionalYesUE context
Non-3GPP access node (N3AN) selection informationThe UE uses this information to select ePDG or N3IWF as defined in clause 6.3.6.1 of TS 23.501.OptionalYesUE context
Slice-specific N3IWF prefix configuration The UE uses this information to determine the prefix to be used for the Prefixed N3IWF OI or TA FQDNs as defined in clause 6.3.6.1 and clause 6.3.6.3 of TS 23.501.OptionalYesUE context
The extended WLANSP information for network slice contains the association of the set of slices that the UE is allowed to access to with SSID(s) and TNGF ID(s).
Up

6.6.1.2  UE selecting a WLANSP rulep. 146

The UE, when not operating in SNPN access mode, may be provisioned with multiple valid WLANSP rules (by the HPLMN and by the VPLMN when the UE is roaming). A WLANSP rule is valid if it meets the validity conditions included in the WLANSP rule (if provided).
When the UE is in the home the UE uses the valid WLANSP rules from the home PLMN to select an available WLAN. When the UE is roaming and the UE has valid rules from both HPLMN and VPLMN the UE gives priority to the valid WLANSP rules from the VPLMN.
The SNPN-enabled UE may be provisioned with one or multiple valid WLANSP policy by the subscribed SNPN, by the registered SNPN or by the Credential Holder to be used when operating in SNPN access mode. Based on implementation specific procedure the UE selects the WLANSP corresponding to the Credential Holder or SNPN to which the UE wants to connect to. If the UE is registered to a non-subscribed SNPN and the UE has valid rules from both CH or subscribed SNPN and the registered SNPN, the UE gives priority to the valid WLANSP rules from the registered SNPN. A WLANSP rule is valid if it meets the validity conditions included in the WLANSP rule (if provided).
The N5CW device may be provisioned with multiple valid WLANSP policy (e.g. if they have been received via 3GPP access or via any other implementation specific means).
Up

6.6.1.3  UE procedure for selecting a WLAN access based on WLANSP rulesp. 147

The UE (or N5CW device) shall apply the procedure in this clause when the UE (or N5CW device) is provisioned with WLANSP rules and:
  1. when the UE initiates untrusted non-3GPP access to 5GC and attempts to select a WLAN access network; or
  2. when the UE initiates trusted non-3GPP access to 5GC by executing the Access Network Selection Procedure specified in clause 6.3.12.2 of TS 23.501 and attempts to select a WLAN access network; or
  3. when the N5CW device initiates access to 5GC by executing the Access Network Selection Procedure specified in clause 6.3.12a.2 for access to PLMN or clause 5.30.2.15 of TS 23.501 for access to SNPN and attempts to select a WLAN access network.
The procedure in this clause applies to both UE operating in SNPN access mode and UE not operating in SNPN access mode, except where stated otherwise. The procedure in this clause also applies to N5CW devices when accessing a PLMN or an SNPN.
When the UE or N5WC device has valid 3GPP subscription credentials (i.e. a valid USIM or valid SNPN credentials) and WLANSP rules, the UE or N5CW device shall perform WLAN selection based on these rules, the applicable User Preferences On Non-3GPP Access Selection and the corresponding procedures specified in this document. User Preferences On Non-3GPP Access Selection take precedence over the WLANSP rules.
The UE or N5CW device determines the most preferred WLAN access network using WLANSP rules when a WLAN access network cannot be selected based on User Preferences On Non-3GPP Access Selection (e.g. when there are no User Preferences On Non-3GPP Access Selection or when there is no user-preferred WLAN access network available).
The UE or N5CW device constructs a prioritized list of the available WLANs by discovering the available WLANs and comparing their attributes / capabilities against the groups of selection criteria in the valid WLANSP rule(s). When there are multiple valid WLANSP rules the UE evaluates the valid WLANSP rules in priority order. The UE evaluates first if an available WLAN access meets the criteria of the highest priority valid WLANSP rule. The UE then evaluates if an available WLAN access meets the selection criteria of the next priority valid WLANSP rule.
Within a valid WLANSP rule, the WLAN(s) that match the group of selection criteria with the highest priority are considered as the most preferred WLANs, the WLAN(s) that match the group of selection criteria with the second highest priority are considered as the second most preferred WLANs, etc.
When a group of selection criteria includes the HomeNetwork attribute and is set, then the UE or N5CW device (a) shall create a list of available WLANs that directly interwork with the home operator (as specified in clause 4.8.2.1.6 of TS 23.402) and (b) shall apply the group of selection criteria to all the WLANs in this list. Otherwise, when the HomeNetwork attribute is not set or is not present, the UE or N5CW device shall apply the group of selection criteria to all available WLANs. The UE or N5CW device may need to perform ANQP procedures (as specified in the HS2.0 Rel-2 specification [ref]) or other procedures in order to discover the attributes / capabilities of the available WLANs.
When the UE is roaming (this implies that it is not operating in SNPN access mode and is not an N5CW device) the UE may have valid WLANSP rules from both the VPLMN and the HPLMN. In such a case the UE gives priority to the valid WLANSP rules from the VPLMN. The UE constructs a prioritised list of the available WLANs when the available WLAN accesses meet the selection criteria of the valid rules from the VPLMN and the valid rules from the HPLMN. The prioritised WLAN accesses based on the WLANSP rules from the HPLMN will have lower priority from the prioritised list of WLAN access based on the WLANSP rules of the VPLMN.
Up

6.6.2  UE Route Selection Policy informationp. 147

6.6.2.1  Structure Descriptionp. 147

The UE Route Selection Policy (URSP) includes a prioritized list of URSP rules.
Information name Description Category PCF permitted to modify in a URSP Scope
URSP rules 1 or more URSP rules as specified in Table 6.6.2.1-2MandatoryYesUE context
 
The structure of the URSP rules is described in Table 6.6.2.1-2 and Table 6.6.2.1-3.
Information name Description Category PCF permitted to modify in a UE context Scope
Rule PrecedenceDetermines the order the URSP rule is enforced in the UE.Mandatory (NOTE 1)YesUE context
Indication for reporting URSP rule enforcementDetermines the need for reporting the URSP rule enforcement in the UE. (NOTE 10)OptionalYesUE context
Traffic descriptorThis part defines the Traffic descriptor components for the URSP rule.Mandatory (NOTE 3)
Application descriptorsIt consists of OSId and OSAppId(s) (NOTE 2, NOTE 8).OptionalYesUE context
IP descriptors (NOTE 6)Destination IP 3 tuple(s) (IP address or IPv6 network prefix, port number, protocol ID of the protocol above IP) (NOTE 8, NOTE 12).OptionalYesUE context
Domain descriptorsFQDN(s) or a regular expression which are used as a domain name matching criteria (NOTE 7, NOTE 8).OptionalYesUE context
Non-IP descriptors (NOTE 6)Descriptor(s) for destination information of non-IP traffic (NOTE 8, NOTE 12)OptionalYesUE context
DNNThis is matched against the DNN information provided by the application (NOTE 8).OptionalYesUE context
Connection CapabilitiesThis is matched against the information provided by a UE application when it requests a network connection with certain capabilities (NOTE 4, NOTE 8) or traffic categories (NOTE 5).OptionalYesUE context
PIN IDMatched against a PIN ID for a specific PIN configured in the PEGC (NOTE 9).OptionalYesUE context
Connectivity Group IDMatched against a Connectivity Group ID for a specific Connectivity Group configured in the 5G-RG (NOTE 11).OptionalYesUE context
List of Route Selection Descriptors A list of Route Selection Descriptors. The components of a Route Selection Descriptor are described in Table 6.6.2.1-3.Mandatory
NOTE 1:
Rules in a URSP shall have different precedence values.
NOTE 2:
The information is used to identify the Application(s) that is(are) running on the UE's OS. The OSId does not include an OS version number. The OSAppId does not include a version number for the application.
NOTE 3:
At least one of the Traffic descriptor components shall be present.
NOTE 4:
The format and some values of Connection Capabilities, e.g. "ims", "mms", "internet", etc. are defined in TS 24.526. More than one Connection Capabilities value can be provided.
NOTE 5:
The format and values of Connection Capabilities Traffic Descriptor to match against standardized traffic categories are defined in TS 24.526 according to the requirements in GSMA PRD NG.135 [39]. The reserved values of Connection Capabilities to match operator-specific traffic categories are specified in TS 24.526. Traffic categories requested by the UE application are independent from the UE's Operating System. Operator-specific traffic categories values are out of scope of 3GPP specifications. Details on how UE applications indicate traffic categories to the UE's Operating System are out of scope of 3GPP specifications.
NOTE 6:
A URSP rule cannot contain the combination of the Traffic descriptor components IP descriptors and Non-IP descriptors.
NOTE 7:
The match of this traffic descriptor does not require successful DNS resolution of the FQDN provided by the UE Application.
NOTE 8:
Not applicable for PINE traffic.
NOTE 9:
The PCF delivers traffic descriptor with PIN ID based on S-NSSAI/DNN as specified in clause 6.2.1.3. PIN ID only applies to traffic to/from PINEs. PIN ID and other traffic descriptor components are mutually exclusive, i.e. if PIN ID is included in a URSP rule, then no other traffic descriptor components are supported in the same URSP rule.
NOTE 10:
A URSP rule can contain this indication only if the URSP rule includes a Connection Capabilities Traffic descriptor.
NOTE 11:
Only applies to traffic to/from NAUN3 devices behind the 5G-RG (as defined in TS 23.316) and may only be combined with IP descriptors and/or non-IP descriptors in the same URSP rule.
NOTE 12:
May also be applied for traffic from NAUN3 devices behind the 5G-RG (as defined in TS 23.316)
 
Information name Description Category PCF permitted to modify in URSP Scope
Route Selection Descriptor PrecedenceDetermines the order in which the Route Selection Descriptors are to be applied.Mandatory (NOTE 1)YesUE context
Route selection componentsThis part defines the route selection componentsMandatory (NOTE 2)
SSC Mode SelectionOne single value of SSC mode. (NOTE 5)OptionalYesUE context
Network Slice SelectionEither a single value or a list of values of S-NSSAI(s).Optional (NOTE 3)YesUE context
DNN SelectionEither a single value or a list of values of DNN(s).OptionalYesUE context
PDU Session Type SelectionOne single value of PDU Session TypeConditional (NOTE 8)YesUE context
Non-Seamless Offload indicationIndicates if the traffic of the matching application is to be offloaded to non-3GPP access outside of a PDU Session.Optional (NOTE 4) (NOTE 10)YesUE context
ProSe Layer-3 UE-to-Network Relay Offload indicationIndicates if the traffic of the matching application is to be sent via a ProSe Layer-3 UE-to-Network Relay outside of a PDU session.Optional (NOTE 4) (NOTE 10)YesUE context
ProSe Multi-path PreferenceIndicates if the traffic of the matching application is preferred to be sent via a PDU Session over the Uu reference point and a ProSe Layer-3 UE-to-Network Relay outside of a PDU session.Optional (NOTE 9) (NOTE 10)YesUE context
Access Type preferenceIndicates the preferred Access Type (3GPP or non-3GPP or Multi-Access) when the UE establishes a PDU Session for the matching application.OptionalYesUE context
PDU Session Pair IDAn indication shared by redundant PDU Sessions as described in clause 5.33.2.1 of TS 23.501.Optional (NOTE 10)YesUE context
RSNThe RSN as described in clause 5.33.2.1 of TS 23.501.Optional (NOTE 10)YesUE context
Route Selection Validation Criteria (NOTE 6, NOTE 7)This part defines the Route Validation Criteria componentsOptional
Time WindowThe time window when the matching traffic is allowed. The RSD is not considered to be valid if the current time is not in the time window.OptionalYesUE context
Location CriteriaThe UE location where the matching traffic is allowed. The RSD rule is not considered to be valid if the UE location does not match the location criteria.OptionalYesUE context
NOTE 1:
Every Route Selection Descriptor in the list shall have a different precedence value.
NOTE 2:
At least one of the route selection components shall be present.
NOTE 3:
When the Subscription Information contains only one S-NSSAI in UDR, the PCF needs not provision the UE with S-NSSAI in the Network Slice Selection information. The "match all" URSP rule has one S-NSSAI at most.
NOTE 4:
If this indication is present in a Route Selection Descriptor, no other components shall be included in the Route Selection Descriptor.
NOTE 5:
The SSC Mode 3 shall only be used when the PDU Session Type is IP.
NOTE 6:
The Route Selection Descriptor is not considered valid unless all the provided Validation Criteria are met.
NOTE 7:
To support VPLMN specific URSP rules, Location Criteria in the Route Selection Descriptor may contain VPLMN-specific values.
NOTE 8:
This component shall be present when the Route Selection Component does neither include the "Non-Seamless Offload indication" nor "ProSe Layer-3 UE-to-Network Relay Offload indication".
NOTE 9:
If this indication is present in a Route Selection Descriptor, ProSe Layer-3 UE-to-Network Relay Offload indication shall not be included in the Route Selection Descriptor.
NOTE 10:
This indication is not applicable for PIN.
Each URSP rule contains a Traffic descriptor (containing one or more components described in Table 6.6.2.1-2) that determines when the rule is applicable. A URSP rule is determined to be applicable when every component in the Traffic descriptor (for traffic descriptor components other than the PIN ID) matches the corresponding information from the application, matches the information configured for a PIN (if the URSP rule contains a PIN ID traffic descriptor component) or matches the information configured for a Connectivity Group (if the URSP rule contains a Connectivity Group ID traffic descriptor). A URSP rule is determined not to be applicable when for any given component in the Traffic descriptor:
  • No corresponding information from the application/for a PIN/for a Connectivity Group is available; or
  • The corresponding information from the application/for a PIN/for a Connectivity Group does not match any of the values in the Traffic descriptor component.
If a URSP rule is provided that contains a Traffic descriptor with two or more components, it is recommended to also provide URSP rule(s) with lower precedence and a Traffic descriptor with less components, in order to increase the likelihood of URSP rule matching for a particular application.
Each URSP rule contains a list of Route Selection Descriptors containing one or multiple Route Selection Descriptors each having a different Route Selection Descriptor Precedence value. A Route Selection Descriptor contains one or more of the following components:
  • Session and Service Continuity (SSC) Mode: Indicates that the traffic of the matching application/PIN shall be routed via a PDU Session supporting the included SSC Mode.
  • Network Slice Selection: Indicates that the traffic of the matching application/PIN shall be routed via a PDU Session supporting any of the included S-NSSAIs, see clause 5.15.4 in TS 23.501. It includes one or more S-NSSAI(s).
  • DNN Selection: Indicates that the traffic of the matching application/PIN shall be routed via a PDU Session supporting any of the included DNNs. It includes one or more DNN(s). If a DNN Selection component is provided in the Route Selection Descriptor then the UE shall use any of the DNNs of the DNN Selection component, instead of the DNN requested by the application for the PDU Session that is used to route the traffic of the matching application. If there is no DNN Selection component in the Route Selection Descriptor, then the UE shall use the DNN requested by the application for the PDU Session that is used to route the traffic of the matching application.
  • PDU Session Type Selection: Indicates that the traffic of matching application/PIN shall be routed via a PDU Session supporting the included PDU Session Type. The possible PDU Session Types are defined in clause 5.6.10 in TS 23.501.
  • Non-Seamless Offload indication: Indicates that traffic of the matching application is to be offloaded to non-3GPP access outside of a PDU Session when the rule is applied. If this component is present in a Route Selection Descriptor, no other components shall be included in the Route Selection Descriptor.
  • ProSe Layer-3 UE-to-Network Relay Offload indication: Indicates that the traffic of the matching application is to be sent via a ProSe Layer-3 UE-to-Network Relay outside of a PDU Session when the rule is applied. If this indication is absent and the ProSe Multipath Preference indication is absent then the traffic matching the URSP rule shall not be sent via a ProSe Layer-3 UE-to-Network Relay outside of a PDU Session. If this component is present in a Route Selection Descriptor, no other components shall be included in the Route Selection Descriptor.
  • ProSe Multipath Preference indication: Indicates that the traffic of the matching application is preferred to be sent via a PDU Session over the Uu reference point and a ProSe Layer-3 UE-to-Network Relay without N3IWF outside of a PDU Session. The traffic of the matching application may be sent via a PDU session over Uu reference point or via ProSe Layer-3 UE-to-Network Relay outside of a PDU Session when e.g. one of the paths is not available. If this indication is absent and the ProSe Layer-3 UE-to-Network Relay Offload indication is absent then the traffic matching of the URSP rule shall not be sent via a ProSe Layer-3 UE-to-Network Relay outside of a PDU Session. If this component is present in a Route Selection Descriptor, other components can be included in the Route Selection Descriptor to determine the PDU Session over the Uu reference point.
  • Access Type Preference: If the UE needs to establish a PDU Session when the rule is applied, this indicates the Access Type (3GPP or non-3GPP or multi-access) on which the PDU Session should be established. The type "Multi-Access" indicates that the PDU Session should be established as a MA PDU Session, using both 3GPP access and non-3GPP access.
  • PDU Session Pair ID: An indication shared by redundant PDU Sessions as described in clause 5.33.2.1 of TS 23.501.
  • RSN: The RSN for redundant PDU Sessions as described in clause 5.33.2.1 of TS 23.501.
  • Time Window: The Route Selection Descriptor is not be considered valid unless the UE is in the time window.
  • Location Criteria: The Route Selection Descriptor is not be considered valid unless the UE's location matches the Location Criteria.
In the case of network rejection of the PDU Session Establishment Request, the UE may trigger a new PDU Session establishment based on the rejection cause and the URSP policy.
When the PCF provisions URSP rules to the UE, one URSP rule with a "match all" Traffic descriptor may be included.
The URSP rule with the "match all" Traffic descriptor is used to route the traffic of applications which do not match any other URSP rules and shall therefore be evaluated as the last URSP rule, i.e. with lowest priority. There shall be only one Route Selection Descriptor in this URSP rule. The Route Selection Descriptor in this URSP rule includes at most one value for each Route Selection Component.
If a URSP rule is provided with an Indication for reporting URSP rule enforcement, the UE follows the procedures specified in clause 6.6.2.4.
Up

6.6.2.2  Configuration and Provision of URSPp. 153

6.6.2.2.1  General |R17|p. 153
The UE may be provisioned (signalled) with URSP rules by PCF of the HPLMN. When the UE is roaming, the PCF in the HPLMN may update both the non-VPLMN specific and VPLMN specific URSP rules in the UE. For URSP rules, the UE shall support the provisioning (signalling) from the PCF in the HPLMN, as specified in TS 24.501. In addition, the UE may be also pre-configured with URSP rules (e.g. by the operator).
Only the URSP rules provisioned (signalled) by the PCF are used by the UE, if both URSP rules provisioned (signalled) by the PCF and pre-configured URSP rules are present. If no URSP rule is provisioned (signalled) by the PCF, and the UE has pre-configured rules configured in both the USIM and ME, then only the pre-configured URSP rules configured in the USIM is used.
If the PCF receives application guidance for URSP determination that may apply to a given UE from UDR or from V-PCF as specified in clause 4.15.6.7 of TS 23.502, the PCF may verify the requested parameters (which are described in clauses 4.15.6.7 and 4.15.6.10 of TS 23.502) with regards to the existing URSP rules and (re-)compose the URSP rules for the UE as described in clause 6.6 of TS 23.548.
Up
6.6.2.2.2  URSP rules for an SNPN-enabled UE |R17|p. 153
An SNPN-enabled UE, while registered in an SNPN, may be provisioned (signalled) with URSP rules by the PCF of the SNPN. For URSP rules, the UE shall support the provisioning (signalling) from the PCF in the SNPN as specified in TS 24.501. In addition, the UE may be also pre-configured with URSP rules for the SNPN (e.g. by the operator of the SNPN).
When an SNPN-enabled UE accesses an SNPN using credentials from a Credentials Holder (CH), the UE may also be provisioned (signalled) with URSP rules for the SNPN by the PCF of the SNPN. However, the UE may be required to not accept URSP rules signalled by any SNPN that the UE accesses using CH credentials from a CH as specified in TS 24.501, as follows:
  • by (pre-)configuration by the PLMN or SNPN of which the CH is part of (when applicable); or
  • by provisioning (signalling) by the PLMN or SNPN of which the CH is part of, when the UE is registered in that PLMN or SNPN.
If a UE accesses an SNPN using credentials from a CH, the UE applies URSP rules as follows:
  • The UE first evaluates (in precedence order) the URSP rules, if any, provisioned (signalled) by the PCF of this SNPN, except the URSP rule with the "match all" Traffic descriptor, following the procedure described in clause 6.6.2.3.
  • If none of the above URSP rules received from this SNPN match, or if there is no URSP rules except the URSP rule with the "match all" Traffic descriptor received from this SNPN (or if the UE is required to not accept any URSP rules from any SNPN), then the UE evaluates (in precedence order) the URSP rules, if any, provisioned (signalled) by the PCF of the network (HPLMN or SNPN) holding the credentials when previously registered in the network holding the credentials, except the URSP rule with the "match all" Traffic descriptor, following the procedure described in clause 6.6.2.3.
  • If there is no matching URSP rules according to the above, the UE uses UE Local Configuration if any.
  • If no UE Local Configuration matches or there is no UE Local Configuration, the UE applies the URSP rule with the "match all" Traffic descriptor as follows:
    • The UE first uses the URSP rule with the "match all" Traffic descriptor, if any, provisioned (signalled) by the PCF of this SNPN, following the procedure described in clause 6.6.2.3.
    • If there is no URSP rule with the "match all" Traffic descriptor from provisioned (signalled) by the PCF of this SNPN, then the UE uses the URSP rule with the "match all" Traffic descriptor, if any, provisioned (signalled) by the PCF of the network (HPLMN or SNPN) holding the credentials when previously registered in the network holding the credentials, following the procedure described in clause 6.6.2.3.
The UE keeps the received UE policies stored even when registering in another SNPN. The number of UE policies to be kept stored in the UE for SNPNs other than the subscribed SNPN is up to UE implementation. If necessary, the UE may remove earlier stored UE policy in UE.
If the UE is in an SNPN, at Initial Registration:
  • The UE provides the list of stored PSIs which identify the Policy Sections associated to the serving SNPN that are currently stored in the UE. If USIM is changed or the selected entry of "list of subscriber data" is updated, the UE does not provide any PSI. If no policies are stored in the UE for the serving SNPN, the UE does not provide any PSI associated to the serving SNPN.
The PCF of the serving SNPN retrieves the list of PSIs and its content stored in the UDR of the serving SNPN for the UEs subscribed to the SNPN; for other UEs, the PCF of the serving SNPN has this information locally configured.
Up
6.6.2.2.3Void

6.6.2.3  UE procedure for associating applications to PDU Sessions based on URSPp. 154

For every newly detected application/PIN the UE evaluates the URSP rules in the order of Rule Precedence and determines if the application/PIN is matching the Traffic descriptor of any URSP rule. When a URSP rule is determined to be applicable for a given application/PIN (see clause 6.6.2.1), the UE shall select a Route Selection Descriptor within this URSP rule in the order of the Route Selection Descriptor Precedence.
When a valid Route Selection Descriptor is found, the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor. The UE compares the components of the selected Route Selection Descriptor with the existing PDU Session(s) as follows:
  • For a component which only contains one value (e.g. SSC mode), the value of the PDU Session has to be identical to the value specified in the Route Selection Descriptor.
  • For a component which contains a list of values (e.g. Network Slice Selection), the value of the PDU Session has to be identical to one of the values specified in the Route Selection Descriptor.
  • When some component(s) is not present in the Route Selection Descriptor, a PDU Session is considered matching only if it was established without including the missing component(s) in the PDU Session Establishment Request.
  • When the Route Selection Descriptor includes a Time Window or a Location Criteria, the PDU Session is considered matching only if the PDU Session is associated with an RSD that has the same Time Window or a Location Criteria Validity Conditions.
When a matching PDU Session exists the UE associates the application/PIN to the existing PDU Session, i.e. route the traffic of the detected application/PIN on this PDU Session.
If the UE determines that there is more than one existing PDU Session which matches (e.g. the selected Route Selection Descriptor only specifies the Network Slice Selection, while there are multiple existing PDU Sessions matching the Network Slice Selection with different DNNs), it is up to UE implementation to select one of them to use.
If none of the existing PDU Sessions matches, the UE tries to establish a new PDU Session using the values specified by the selected Route Selection Descriptor. If the PDU Session Establishment Request is accepted, the UE associates the application/PIN to this new PDU Session. If the PDU Session Establishment Request is rejected, based on the rejection cause, the UE selects another combination of values in the currently selected Route Selection Descriptor if any other value for the rejected component in the same Route Selection Description can be used. Otherwise, the UE selects the next Route Selection Descriptor, which contains a combination of component value which is not rejected by network, in the order of the Route Selection Descriptor Precedence, if any. If the UE fails to establish a PDU Session with any of the Route Selection Descriptors, it tries other URSP rules in the order of Rule Precedence with matching Traffic descriptors, except the URSP rule with the "match-all" Traffic descriptor, if any. The UE shall not use the UE Local Configuration in this case.
If a UE receives tuple(s) (PLMN ID, list of PSIs associated with the PLMN ID), the UE uses the URSP rules associated with the PSIs indicated in the tuple(s) as VPLMN specific URSP rules and the UE uses the URSP rules associated with the PSI not indicated in the tuple(s) as non-VPLMN specific URSP rules.
If a UE receives VPLMN specific URSP rules and non-VPLMN specific URSP rules (i.e. the URSP rules which are applicable to both HPLMN and VPLMN), the VPLMN specific URSP rules take precedence over the non-VPLMN specific URSP rules and Local UE Configuration and any other URSP rules provided to the UE. The UE determines VPLMN specific URSP rules to be used taking serving PLMN ID into consideration. If the UE does not find a match to the VPLMN specific URSP rules associated to serving PLMN ID, then the UE uses the VPLMN specific URSP rules associated to the equivalent serving PLMN ID, if any. Otherwise, the UE uses the non-VPLMN specific URSP rules.
The UE receives the updated URSP rules and (re-)evaluates their validities in a timely manner when certain conditions are met, for example:
  • the URSP is updated by the PCF;
  • the UE moves from EPC to 5GC;
  • change of Allowed NSSAI or Configured NSSAI;
  • change of LADN DNN availability;
  • change of PLMN;
  • UE registers over 3GPP or non-3GPP access;
  • UE establishes a connection with a ProSe Layer-3 UE-to-Network Relay;
  • UE establishes connection to a WLAN access.
Details of the conditions are defined by TS 24.526.
The Route Selection Descriptor of a URSP rule shall be only considered valid if all of the following conditions are fulfilled:
  1. If any S-NSSAI(s) is present, the S-NSSAI(s) is in the Allowed NSSAI or in the Partially Allowed NSSAI for the non-roaming case and in the mapping of the Allowed NSSAI (or of the Partially Allowed NSSAI) to HPLMN S-NSSAI(s) for the roaming case.
  2. If any DNN is present and the DNN is an LADN DNN, the UE is in the area of availability of this LADN.
  3. If Access Type preference is present and set to Multi-Access, the UE supports ATSSS.
  4. If a Time Window is present and the time matches what is indicated in the Time Window.
  5. If a Location Criteria is present and the UE location matches what is indicated in the Location Criteria.
  6. If ProSe Layer-3 UE-to-Network Relay Offload indication is present and the UE supports the ProSe capability of 5G ProSe Layer-3 Remote UE.
  7. If ProSe Multipath Preference indication is present and the UE supports the ProSe capability of 5G ProSe Layer-3 Remote UE.
If none of the conditions in bullet 1) are met for all the S-NSSAI(s) in the RSD during the validation of the route selection descriptor, the UE shall attempt to meet the condition by requesting any of the S-NSSAI(s) in the RSD through a Mobility Registration Update procedure to attempt to add the S-NSSAI(s) to the Allowed NSSAI (or to the Partially Allowed NSSAI), as specified in clause 5.15.5.2.2 of TS 23.501. The UE attempts the Mobility Registration Update for a S-NSSAI only if the S-NSSAI is in the Configured NSSAI or, in the roaming case, in the mapping of the S-NSSAIs of the Configured NSSAI for the VPLMN to the corresponding S-NSSAI values of the HPLMN, and any other restrictions to prevent triggering Mobility Registration Update as defined in TS 24.501.
If a matching URSP rule has no valid RSD, the UE tries other URSP rules in the order of Rule Precedence with matching Traffic descriptors, except the URSP rule with "match-all" Traffic descriptor. The UE shall not use the UE Local Configuration in this case.
When URSP rules are updated or their validity according to the conditions above change, the association of existing applications/PINs to PDU Sessions may need to be re-evaluated. The UE may also re-evaluate the application/PIN to PDU Session association due to the following reasons:
  • periodic re-evaluation based on UE implementation;
  • an existing PDU Session that is used for routing traffic of an application/PIN based on a URSP rule is released;
  • The expiration of Time Window in Route Selection Validation Criteria, i.e. the expiration of Time Window, or UE's location no longer matches the Location Criteria.
  • change of PLMN.
If the re-evaluation leads to a change of the application/PIN to PDU Session association, e.g. the application/PIN is to be associated with another PDU Session or a new PDU Session needs to be established, the UE may enforce such changes in a timely manner based on implementation, e.g. immediately or when UE enters CM-IDLE state.
If the selected Route Selection Descriptor contains a Non-Seamless Offload indication and the UE has established a connection to a WLAN access, the UE routes the traffic matching the Traffic descriptor of the URSP rule via the WLAN access outside of a PDU Session.
If the selected Route Selection Descriptor contains a ProSe Layer-3 UE-to-Network Relay Offload indication and the UE has established a connection with a ProSe Layer-3 UE-to-Network Relay, the UE routes the traffic matching the Traffic descriptor of the URSP rule (including the URSP rule with the "match-all" Traffic descriptor) via the ProSe Layer-3 UE-to-Network Relay outside of a PDU session.
Up

6.6.2.4  Support of URSP rule enforcement reporting |R18|p. 157

This clause defines how and under what conditions the UE reports URSP rule enforcement to PCF so that PCF can be made aware when a given UE enforces specific URSP rule(s) and what actions the PCF may trigger upon the reception of such reporting.
In order to determine the URSP rule enforcement, for a UE indicating the capability of reporting URSP rule enforcement to network (see clause 4.2.2.2.2 of TS 23.502), the PCF may indicate in a URSP rule sent to the UE to send reporting of URSP rule enforcement (see clause 6.6.2.1).
A UE supporting URSP rule enforcement reporting shall report URSP rule enforcement to the SMF if a URSP rule includes an indication for reporting URSP rule enforcement and if Connection Capabilities is in the TD (see clause 6.6.2.1), when:
  • the UE associates a newly detected application to a new PDU Session based on URSP evaluation result (see clause 6.6.2.3) for such a URSP rule, the UE shall include in the PDU Session Establishment Request (see clause 4.3.2.2.1 of TS 23.502) the Connection Capabilities contained in the Traffic descriptor of the associated URSP rule, or
  • the UE associates a newly detected application to an existing PDU Session based on URSP evaluation result (see clause 6.6.2.3) for such a URSP rule, the UE shall send a PDU Session Modification Request (see clause 4.3.3.2 of TS 23.502) including the Connection Capabilities contained in the Traffic descriptor of the associated URSP rule.
If the UE enforces several URSP rules for multiple applications, and these multiple applications' traffic are all associated to the same PDU session, in order to reduce the number of uplink NAS messages, the UE may include more than one URSP rule enforcement report in one PDU Session Modification Request to 5GC (see clause 4.3.3.2 of TS 23.502).
The PCF receives reporting from URSP rule enforcement for a given UE via Policy Control Request Triggers (see clause 6.1.3.5).
When the PCF serving the PDU session is not the same as the PCF serving the UE, the PCF serving the UE subscribes to the PCF serving the PDU session to receive the reporting of URSP rule enforcement for a given UE via PCF event reporting (see clause 6.1.3.18 and the related procedure in clause 4.16.16 of TS 23.502).
For LBO roaming session case, the H-PCF for the UE sends the PCRT for the UE reporting of URSP rule enforcement to the V-PCF for the UE during the UE Policy Association Establishment or Modification.
The PCF for the UE may check whether the value of URSP rule enforcement and its PDU Session parameters (e.g. DNN/S-NSSAI) are compliant to the URSP rule of the UE. If the PCF for the UE found an inconsistency, the PCF for the UE may perform appropriate actions (e.g. initiating slice replacement procedure).
Policy control decisions based on awareness of URSP rule enforcement are described in clause 6.1.6.
Up

6.6.3  V2X Policy information |R16|p. 158

The V2X Policy information (V2XP) is defined in TS 23.287.

6.6.4  ProSe Policy information |R17|p. 158

The ProSe Policy information (ProSeP) is defined in TS 23.304.

6.6.5  Ranging/Sidelink Positioning Policy information |R18|p. 158

The Ranging/Sidelink Positioning Policy information (RSLPP) is defined in TS 23.586.

6.6.6  A2X Policy information |R18|p. 158

The A2X Policy information (A2XP) is defined in TS 23.256.

Up   Top   ToC