full Table of Contents for TS 23.503 Word version: 16.3.0
A URSP rules example
B Deployment option to support of BSF and DRA coexistence due to network migration
C [N] Support for Application Functions supporting Rx interface
D PCC usage for sponsored data connectivity
D.1 General
D.2 Reporting for sponsored data connectivity
E Change history
A URSP rules example Word-p. 97
B Deployment option to support of BSF and DRA coexistence due to network migration Word-p. 100
D PCC usage for sponsored data connectivity [R16] Word-p. 103
As an example, the URSP rules provisioned in the UE may include the following rules:
Table A-1: Example of URSP rules
Example URSP rules
Comments
Rule Precedence =1
Traffic Descriptor: Application Identifiers=App1
Traffic Descriptor: Application Identifiers=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
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 Identifiers=App2
Traffic Descriptor: Application Identifiers=App2
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-a
Access Type preference: Non-3GPP access
Route Selection Descriptor Precedence =2
Non-seamless Offload indication: Permitted (WLAN SSID-a)
Network Slice Selection: S-NSSAI-a
Access Type preference: Non-3GPP access
Route Selection Descriptor Precedence =2
Non-seamless Offload indication: Permitted (WLAN SSID-a)
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)
Rule Precedence =3
Traffic Descriptor: DNN=DNN_1
Traffic Descriptor: DNN=DNN_1
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-a
Access Type preference: Non-3GPP access
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 Identifiers=App1
Connection Capabilities="internet", "supl"
Traffic Descriptor: Application Identifiers=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
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 Identifiers=App3
Connection Capabilities="ims"
Traffic Descriptor: Application Identifiers=App3
Connection Capabilities="ims"
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-c
DNN Selection: DNN_1
Access Type preference: Multi-Access
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 Identifiers=App1
Traffic Descriptor: Application Identifiers=App1
Route Selection Descriptor Precedence =1
DNN Selection: DNN_1
Network Slice Selection: S-NSSAI-a
Access Type preference: Multi Access
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: *
Traffic Descriptor: *
Route Selection Descriptor Precedence =1
Network Slice Selection: S-NSSAI-b
SSC Mode Selection: SSC Mode 3
DNN Selection: internet
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.
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.
NOTE: The DRA decides to select a BSF based on user IP address range.
C (Normative) Support for Application Functions supporting Rx interface [R16] Word-p. 101
To allow the 5G system to interwork with AFs related to existing services, e.g. IMS based services as described in TS 23.228 [5], Mission Critical Push To Talk services as described in TS 23.179 [6], 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.
Figure C-1: Interworking between 5G Policy framework and AFs supporting Rx interface
Session Binding applies for PDU Sessions of IP type only
The functionality described for Multimedia Priority Services (clause 6.11) and Mission Critical service (clause 6.19) applies via Rx interface.
In order to support IMS Emergency services over Rx interface, in addition to the functional description in clause 6.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.
NOTE 1: TS 23.501 defines both 5G identifiers, SUPI, PEI and GPSI and then how they are allocated to allow interworking with functional entities not supporting 5G identifies such as P-CSCF.
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:
Table C-1: Events relevant for reporting from the PCF
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
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.1 General
E Change history Word-p. 105
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.
NOTE 1: Sponsored data connectivity is not supported in the roaming with visited access scenario in this Release.
Figure D.1-1: Deployment for sponsored data connectivity
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.
NOTE 2: An ASP can also be a sponsor.
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 Word-p. 104
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.
