Content for TS 23.503 Word version: 18.0.0
A URSP rules example
B Deployment option to support of BSF and DRA coexistence due to network migration
C Support for Application Functions supporting Rx interface
D PCC usage for sponsored data connectivity
D.1 General
D.2 Reporting for sponsored data connectivity
$ Change history
A URSP rules example p. 137
As an example, the URSP rules provisioned in the UE may include the following rules:
| Example URSP rules | Comments | |
|---|---|---|
| Rule Precedence =1 Traffic Descriptor: Application descriptor=App1 | Route Selection Descriptor Precedence=1 Network Slice Selection: S-NSSAI-a SSC Mode Selection: SSC Mode 3 DNN Selection: internet Access Type preference: 3GPP access | This URSP rule associates the traffic of application "App1" with S-NSSAI-a, SSC Mode 3, 3GPP access and the "internet" DNN. It enforces the following routing policy: The traffic of App1 should be transferred on a PDU Session supporting S-NSSAI-a, SSC Mode 3 and DNN=internet over 3GPP access. If this PDU Session is not established, the UE shall attempt to establish a PDU Session with S-NSSAI-a, SSC Mode 3 and the "internet" DNN over 3GPP access. |
| Rule Precedence =2 Traffic Descriptor: Application descriptor=App2 | Route Selection Descriptor Precedence =1 Network Slice Selection: S-NSSAI-a Access Type preference: Non-3GPP access | This URSP rule associates the traffic of application "App2" with S-NSSAI-a and Non-3GPP access. It enforces the following routing policy: The traffic of application App2 should be transferred on. a PDU Session supporting S-NSSAI-a using a Non-3GPP access. If this PDU Session is not established, the UE shall attempt to establish a PDU Session with S-NSSAI-a over Access Type=non-3GPP access. If the PDU Session cannot be established, the traffic of App2 shall be directly offloaded to WLAN, if the UE is connected to a WLAN with SSID-a (based on the 2nd RSD) |
| Route Selection Descriptor Precedence =2 Non-seamless Offload indication: Permitted (WLAN SSID-a) | ||
| Rule Precedence =3 Traffic Descriptor: DNN=DNN_1 | Route Selection Descriptor Precedence =1 Network Slice Selection: S-NSSAI-a Access Type preference: Non-3GPP access | This URSP rule associates the traffic of applications that are configured to use DNN_1 with DNN_1, S-NSSAI-a over Non-3GPP access. It enforces the following routing policy: The traffic of application(s) that are configured to use DNN_1 should be transferred on a PDU Session supporting S-NSSAI-a over Non-3GPP access. If this PDU Session is not established, the UE shall attempt to establish the PDU Session with S-NSSAI-a over Non-3GPP access. |
| Rule Precedence =4 Traffic Descriptor: Application descriptor=App1 Connection Capabilities="internet", "supl" | Route Selection Descriptor Precedence =1 Network Slice Selection: S-NSSAI-a DNN Selection: DNN_1 Access Type preference: Non-3GPP access | This URSP rule associates the application "App1" and the Connection Capabilities "internet" and "supl" with DNN_1, S-NSSAI-a over Non-3GPP access. It enforces the following routing policy: When the "App1" requests a network connection with Connection Capability "internet" or "supl", the UE establishes (if not already established) a PDU Session with DNN_1 and S-NSSAI-a over Non-3GPP access. After that, the UE routes the traffic of "App1" over this PDU Session. |
| Rule Precedence =5 Traffic Descriptor: Application descriptor=App3 Connection Capabilities="ims" | Route Selection Descriptor Precedence =1 Network Slice Selection: S-NSSAI-c DNN Selection: DNN_1 Access Type preference: Multi-Access | This URSP rule associates the application "App3" and the Connection Capability "ims" with DNN_1, S-NSSAI-c and multi-access connectivity. It enforces the following routing policy: When the "App3" requests a network connection with Connection Capability "ims", the UE establishes (if not already established) a MA PDU Session with DNN_1 and S-NSSAI-c. After that, the UE routes the traffic of "App3" over this MA PDU Session by using the received ATSSS rules |
| Rule Precedence =6 Traffic Descriptor: Application descriptor=App1 | Route Selection Descriptor Precedence =1 DNN Selection: DNN_1 Network Slice Selection: S-NSSAI-a Access Type preference: Multi Access | This URSP rule associates App 1 with DNN_1, S-NSSAI-a with Multi Access connectivity. It enforces the following routing policy: The traffic of Application 1 should be transferred on a PDU Session supporting S-NSSAI-a and DNN_1 according to the received ATSSS rules. After that the UE routes the traffic of any other application according to the ATSSS rule with match all packet filters if available. |
| Rule Precedence = lowest priority Traffic Descriptor: * | Route Selection Descriptor Precedence =1 Network Slice Selection: S-NSSAI-b SSC Mode Selection: SSC Mode 3 DNN Selection: internet | This URSP rule associates all traffic not matching any prior rule a PDU Session with S-NSSAI-b, SSC Mode 3 and the "internet" DNN. It enforces the following routing policy: All traffic not matching any prior rule should be transferred on a PDU Session supporting S-NSSAI-b, SSC Mode 3 and DNN=internet with no access network preference. |
B Deployment option to support of BSF and DRA coexistence due to network migration p. 141
During the network migration, DRA and BSF may coexist in operator's network. The DRA can be a consumer of Nbsf services and the BSF can provide binding functionality for different subscribers. When the AF using Rx, such as P-CSCF, sends Rx request to the DRA, if the DRA has no binding information for the subscriber, based on configuration or via NRF, it selects the BSF. Then the DRA can query the BSF by invoking Nbsf_Management discovery service operation, to get the relevant PCF address, based on which the DRA routes the Rx request to the selected PCF.
C (Normative) Support for Application Functions supporting Rx interface |R16| p. 142
To allow the 5G system to interwork with AFs related to existing services, e.g. IMS based services as described in TS 23.228, Mission Critical Push To Talk services as described in TS 23.179, the PCF shall support the corresponding IMS procedures defined in the main body of this TS via Rx interface. This facilitates the migration from EPC to 5GC without requiring these AFs to upgrade to support the Npcf_PolicyAuthorization services in Rel-16.
Session Binding applies for PDU Sessions of IP type only.
The functionality described for Multimedia Priority Services (clause 6.1.3.11) and Mission Critical service (clause 6.1.3.19) applies via Rx interface.
In order to support IMS Emergency services over Rx interface, in addition to the functional description in clause 6.1.3.10, the following applies: The PCF shall provide the IMEI and the subscriber identifiers (IMSI, MSISDN) (if available), received from the SMF at PDU Session establishment, if so requested by the P-CSCF. The PCF derives the IMEI from the PEI, the IMSI from the SUPI and the MSISDN from the GPSI.
Any AF using Rx, such as P-CSCF, the BSF determines the selected PCF address according to the information included in the incoming Rx requests and the information stored at the BSF. The BSF is able to proxy or redirect Rx requests targeting an IP address of a UE to the selected PCF.
The following event reporting is supported over Rx interface:
| Event | Description | Availability for Rx Session |
|---|---|---|
| PLMN Identifier Notification | The PLMN identifier where the UE is currently located. | Yes |
| Change of Access Type | The Access Type and, if applicable, the RAT Type of the PDU Session has changed. | Yes |
| EPS fallback | EPS fallback is initiated | Yes |
| Signalling path status | The status of the resources related to the signalling traffic of the AF session. | Yes |
| Access Network Charging Correlation Information | The Access Network Charging Correlation Information of the resources allocated for the AF session. | Yes |
| Access Network Information Notification | The user location and/or timezone when the PDU Session has changed in relation to the AF session. | Yes |
| Reporting Usage for Sponsored Data Connectivity | The usage threshold provided by the AF has been reached; or the AF session is terminated. | Yes |
| Resource allocation status | The status of the resources related to the AF session (established/released). | Yes |
| QoS targets can no longer (or can again) be fulfilled | The QoS targets can no longer (or can again) be fulfilled by the network for (a part of) the AF session. | No |
| Out of credit | Credit is no longer available. | Yes |
D PCC usage for sponsored data connectivity |R16| p. 144
D.1 General p. 144
With sponsored data connectivity, the Sponsor has a business relationship with the operator and the Sponsor reimburses the operator for the user's data connectivity in order to allow the user access to an associated Application Service Provider's (ASP) services. Alternatively, the user pays for the connectivity with a transaction which is separate from the subscriber's charging. It is assumed the user already has a subscription with the operator.
A possible deployment configuration for sponsored data connectivity in the non-roaming case is illustrated in Figure D.1-1.
The relationship between the AF and Sponsor and between the Sponsor and ASP is out of scope of this specification. A single AF can serve multiple ASPs and multiple sponsors.
The sponsor may choose to supply the PCF (via the AF) with the usage thresholds that it expects the SMF to enforce. Alternatively, the Sponsor can allow the ASP to enforce such control over the sponsored data connectivity.
The information required for the detection of sponsored HTTP traffic (i.e. server host name) can be verified with the corresponding server IP address/prefix of the IP packets by the SMF. The SMF uses implementation specific logic to perform this verification.
D.2 Reporting for sponsored data connectivity p. 145
There are two deployment scenarios for usage reporting for sponsored data connectivity. The Sponsor Identifier and Application Service Provider Identifier are provided for sponsored services to the PCF from the AF over the Rx/N5 interface.
In the first scenario the PCF assigns a service specific Charging Key for a sponsored IP flow. The Charging key is used by the SMF to generate separate accounting records for offline charging and and/or usage data records for online charging for the sponsored flows. Correlation of accounting records and usage data records from multiple users per sponsor and/or application service provider is then performed using the charging key.
In a second scenario the Sponsor Identifier and Application Service Provider Identity is included in PCC rules from the PCF to the SMF as defined in clause 6.3.1. For this scenario the same Charging Key may be used both for IP flows that are sponsored and for flows that are not sponsored. Accounting records generated by the SMF for offline charging include the Sponsor Identity and the Application Service Provider Identity. Correlation of accounting records from multiple users per sponsor and/or application service provider can then be based on Sponsor Identity and Application Service Provider Identity instead of the Charging Key. Usage reporting for online charging including Sponsor Identity and Application Service Provider Identity has not been specified in this release of the specification. PCC rules that include a Sponsor Identity and an Application Service Provider Identity should include a Charging Method that indicates offline charging.
$ Change history p. 146
