4.2.5 Npcf_PolicyAuthorization_Notify service operation

29.5143GPP5G SystemPolicy Authorization ServiceRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.2.5.1 General

The Npcf_PolicyAuthorization_Notify service operation enables notification to NF service consumers that the previously subscribed event for the existing application session context occurred or that the application session context is no longer valid.

The following procedures using the Npcf_PolicyAuthorization_Notify service operation are supported:

– Notification about application session context event.

– Notification about application session context termination.

– Notification about Service Data Flow QoS notification control.

– Notification about service data flow deactivation.

– Reporting usage for sponsored data connectivity.

– Notification of resources allocation outcome.

– Reporting access network information.

– Notification of signalling path status.

– Notification about out of credit.

– Notification about TSC user plane node management information and/or port management information, Individual Application Session Context exists.

– Notification about Service Data Flow QoS Monitoring control.

– Report of EPS Fallback.

– Notification about TSC user plane node Information, no Individual Application Session Context exists.

– Notification about reallocation of credit.

– Notification of MPS for DTS outcome.

– Notification about application detection information.

– Notification about satellite backhaul category changes.

– Notification about UP path change enforcement failure.

– Notification about PDU session established/terminated events.

4.2.5.2 Notification about application session context event

This procedure is invoked by the PCF to notify the NF service consumer when a certain, previously subscribed, application session context event occurs, as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4].

Figure 4.2.5.2-1 illustrates the notification about application session context event.

Figure 4.2.5.2-1: Notification about application session context event

When the PCF determines that the event for the existing AF application session context, to which the NF service consumer has subscribed to, occurred e.g. upon reception of an event notification for a PDU session from the SMF as described in 3GPP TS 29.512 [8], the PCF shall invoke the Npcf_PolicyAuthorization_Notify service operation by sending the HTTP POST request (as shown in figure 4.2.5.2-1, step 1) to the NF service consumer using the notification URI received in the subscription creation (or modification), as specified in clause 4.2.6, and appending the "notify" segment path at the end of the URI. The PCF shall provide in the body of the HTTP POST request the "EventsNotification" data type including:

– the Events Subscription resource identifier related with the notification in the "evSubsUri" attribute; and

– the list of the reported events in the "evNotifs" attribute. For each reported event, the "AfEventNotification" data type shall include the event identifier and may include additional event information.

The PCF shall include:

– if the NF service consumer subscribed to the "PLMN_CHG" event, the "event" attribute set to "PLMN_CHG" and the "plmnId" attribute including the PLMN Identifier or the SNPN Identifier if the PCF has requested to be updated with this information in the SMF;

NOTE 1: The SNPN Identifier consists of the PLMN Identifier and the NID.

NOTE 2: Handover between non-equivalent SNPNs, and between SNPN and PLMN is not supported. When the UE is operating in SNPN access mode, the trigger reports changes of equivalent SNPNs.

– if the NF service consumer subscribed to the event "ACCESS_TYPE_CHANGE", the "event" attribute set to "ACCESS_TYPE_CHANGE" and:

i. the "accessType" attribute including the access type, and the "ratType" attribute including the RAT type when applicable for the notified access type; and/or

ii. if the "ATSSS" feature is supported and the PDU session is a MA PDU session:

a. if it is the first access type report, and both, 3GPP and non-3GPP access information is available, the "addAccessInfo" attribute. The "addAccessInfo" attribute contains the additional access type information, where the access type is encoded in the "accessType" attribute, and the RAT type is encoded in the "ratType" attribute when applicable for the notified access type;

b. if it is a subsequent access type change report:

– if a new access type is added to the MA PDU session, the"addAccessInfo" attribute with the added access type encoded in the "accessType" attribute, and the RAT type encoded in the "ratType" attribute when applicable for the notified access type;

– if an access type is released to the MA PDU session, the "relAccessInfo" attribute with the released access type encoded in the "accessType" attribute, and the RAT type encoded in the "ratType" attribute when applicable for the notified access type; and

NOTE 3: For a MA PDU session, if the "ATSSS" feature is not supported by the NF service consumer the PCF shall include the "accessType" attribute and the "ratType" attribute with a currently active combination of access type and RAT type. When both 3GPP and non-3GPP accesses are available, the PCF includes the information corresponding to the 3GPP access and only changes on activation and deactivation of 3GPP access are reported.

iii. the "anGwAddr" attribute including access network gateway address when available; and

– if the "IMS_SBI" feature is supported and if the NF service consumer subscribed to the "CHARGING_CORRELATION" event, the "event" attribute set to "CHARGING_CORRELATION" and may include the "anChargIds" attribute containing the access network charging identifier(s) and the "anChargAddr" attribute containing the access network charging address.

The NF service consumer notification of other specific events using the Npcf_PolicyAuthorization_Notify request is described in the related clauses.

Upon the reception of the HTTP POST request from the PCF indicating that the PDU session and/or service related event occurred, the NF service consumer shall acknowledge that request by sending an HTTP response message with the corresponding status code.

If the HTTP POST request from the PCF is accepted, the NF service consumer shall acknowledge the receipt of the event notification with a "204 No Content" response to HTTP POST request, as shown in figure 4.2.5.2-1, step 2.

If the HTTP POST request from the PCF is not accepted, the NF service consumer shall indicate in the response to HTTP POST request the cause for the rejection as specified in clause 5.7.

If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].

4.2.5.3 Notification about application session context termination

This procedure is invoked by the PCF to notify the NF service consumer that the application session context is no longer valid, as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4].

Figure 4.2.5.3-1 illustrates the notification about application session context termination.

Figure 4.2.5.3-1: Notification about application session context termination

When the PCF determines that the AF application session context is no longer valid, the PCF shall invoke the Npcf_PolicyAuthorization_Notify service operation by sending the HTTP POST request (as shown in figure 4.2.5.3-1, step 1) using the notification URI received in the "Individual Application Session Context" context creation, as specified in clause 4.2.2 and clause 4.2.6.3, and appending the "terminate" segment path at the end of the URI, to trigger the NF service consumer to request the application session context termination (see clause 4.2.4.2). The PCF shall provide in the body of the HTTP POST request the "TerminationInfo" data type including:

– the Individual Application Session Context resource identifier related to the termination notification in the "resUri" attribute; and

– the application session context termination cause in the "termCause" attribute of the "TerminationCause" data type, indicating:

i) "PDU_SESSION_TERMINATION" when the PCF received from the SMF the indication of SM Policy Context termination without a specific PDU session release cause value;

ii) "ALL_SDF_DEACTIVATION" when the PCF received from the SMF the indication that all the SDFs of the Individual Application Session Context resource are deactivated or all resource allocation of an Individual Application Session Context fails because other reasons than "PS_TO_CS_HAN";

iii) "PS_TO_CS_HO" if the "IMS_SBI" feature is supported and the PCF received from the SMF:

a) the PDU session release cause value "PS_TO_CS_HO"; or

b) the failure code value "PS_TO_CS_HAN" for all the SDFs of the Individual Application Session Context resource;

iv) "INSUFICIENT_SERVER_RESOURCES" when the PCF is overloaded;

v) "INSUFFICIENT_QOS_FLOW_RESOURCES" when the PCF received that the maximum number of QoS flows for the PDU session is reached or there was a QoS flow resource limitation error; or

vi) "SPONSORED_DATA_CONNECTIVITY_DISALLOWED" when the PCF detects that due to operator policy the UE accessing the sponsored data connectivity is disallowed.

Upon the reception of the HTTP POST request from the PCF requesting the application session context termination, the NF service consumer shall acknowledge that request by sending an HTTP response message with the corresponding status code.

If the HTTP POST request from the PCF is accepted, the NF service consumer shall acknowledge the receipt of the application session context termination request with a "204 No Content" response to HTTP POST request (as shown in figure 4.2.5.3-1, step 2) and shall invoke the Npcf_PolicyAuthorization_Delete service operation to the PCF as described in clause 4.2.4.

If the HTTP POST request from the PCF is not accepted, the NF service consumer shall indicate in the response to HTTP POST request the cause for the rejection as specified in clause 5.7.

4.2.5.4 Notification about Service Data Flow QoS notification control

When the PCF gets the knowledge that one or more SDFs:

– cannot guarantee the GBR QoS targets; or

– can guarantee again the GBR QoS targets;

the PCF shall inform the NF service consumer accordingly if the AF has previously subscribed as described in clauses 4.2.2.6 and 4.2.3.6.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include:

– within the "evNotifs" attribute an event entry of the "AfEventNotification" data type with the matched event "QOS_NOTIF" in the "event" attribute; and

– the "qncReports" array with:

a) the "notifType" attribute to indicate whether the GBR targets for the indicated SDFs are "NOT_GUARANTEED" or "GUARANTEED" again;

b) the identification of the affected service flows (if not all the flows are affected) encoded in the "flows" attribute if applicable; and

c) if the "AuthorizationWithRequiredQoS" feature or the "AltSerReqsWithIndQoS" feature as defined in clause 5.8 is supported, the reference to the Alternative Service Requirement corresponding alternative QoS parameter set if received from the SMF within the "altSerReq" attribute. When the "altSerReq" attribute is omitted and the "notifType" attribute is NOT_GUARANTEED, it indicates that the lowest priority alternative service requirement could not be fulfilled.

When the "AuthorizationWithRequiredQoS" and "AltQoSProfilesSupportReport" features as defined in clause 5.8 are supported, and the AF included during the media component provisioning the "altSerReqs" attribute for the concerned media components(s), or the "AltSerReqsWithIndQoS" and "AltQoSProfilesSupportReport" features are supported and the AF included during media component provisioning the "altSerReqsData" attribute for the concerned media component(s), if the PCF receives from the SMF the indication that the GBR QoS targets cannot be guaranteed and the indication that alternative QoS profiles are not supported in the NG-RAN where the UE is currently located as specified in in 3GPP TS 29.512 [8], the PCF may include within the QosNotificationControlInfo data structure the "altSerReqNotSuppInd" attribute set to true. When the Alternative QoS profiles are supported by the NG-RAN where the UE is currently located, the PCF may omit or set the "altSerReqNotSuppInd" attribute to false, as indicated by the SMF.

If "MediaComponentVersioning" feature is supported, and if the content version was included when the corresponding media component was provisioned, the "flows" attribute shall also contain the "contVers" attribute including the content version(s) of the media components. The PCF shall include more than one entry in the "contVers" attribute for the same media component if the PCF has received multiple content versions as described in clause 4.2.6.2.14 in 3GPP TS 29.512 [8].

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF. The NF service consumer may also update the AF application session context information by sending an HTTP PATCH request to the PCF.

Signalling flows for Service Data Flow QoS notification control are presented in 3GPP TS 29.513 [7].

4.2.5.5 Notification about Service Data Flow Deactivation

When the PCF gets the knowledge that one or more SDFs have been deactivated, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed as described in clauses 4.2.2.7 and 4.2.3.7.

When not all the service data flows within the AF application session context are affected, the PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include within the "evNotifs" attribute an event of "AfEventNotification" data type indicating the matched event ("FAILED_RESOURCES_ALLOCATION" if the resources could not be allocated or "UE_TEMPORARILY_UNAVAILABLE" if the UE was temporarily unavailable) in the "event" attribute and the deactivated service data flows (if not all the flows are affected) encoded in the "flows" attribute.

NOTE 1: If the PCF detects that the PCC rules related to an AF application session context cannot be installed or modified because there is a temporary network failure (e.g. SGW failed according to clause B.3.3.3 or B.3.4.9 of 3GPP TS 29.512 [8]) and if requested by the AF, the PCF can notify the AF of the event "FAILED_RESOURCES_ALLOCATION".

If the "MediaComponentVersioning" feature is supported, and if the content version was included when the corresponding media component was provisioned as described in clause 4.2.5.8, the PCF shall also include in the "flows" attribute the "contVers" attribute with the content version(s) of the media components.

If the "RAN-NAS-Cause" feature is supported and the PCF received the RAN-NAS release cause and access network information from the SMF, the PCF shall provide in the "EventsNotification" data type of the HTTP POST request:

– in case of 3GPP access, the user location information in the "eutraLocation" or in the "nrLocation" attribute in the "ueLoc" attribute, if available;

– in case of untrusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if available, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute;

b) the UDP source port or the TCP source port in the "portNumber" and "protocol" attributes, if available; and

c) if the "WLAN_Location" feature is supported, the WLAN location information encoded in the "twapId" attribute, if available, that shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

NOTE 2: When the UE reaches the ePDG via a NAT, the combination of UE local IP address and the UE source port is needed for lawful interception purposes. The UE source port may be either a UDP or a TCP port, and it is indicated in the "protocol" attribute.

– in case of trusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if available, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute, if available; and

b) the UDP source port in the "portNumber" attribute if available; and

NOTE 3: The UDP protocol can be used between the UE and the TNGF to enable NAT traversal.

c) either the TNAP identifier encoded in the "tnapId" attribute or the TWAP identifier encoded in the "twapId" attribute. The TNAP identifier and the TWAP identifier shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

– the serving network identity i.e. the PLMN Identifier (the PLMN network code and the country code) or the SNPN Identifier (the PLMN Identifier and the NID) in the "plmnId" attribute, if user location information is not available in any access;

– the UE timezone in the "ueTimeZone" attribute if available; and

– the RAN and/or NAS release cause in the "ranNasRelCauses" attribute, if available.

NOTE 4: The PCF forwards both 3GPP and non-3GPP access UE locations in the "ueLoc" attribute when both UE locations are provided by the SMF as defined in 3GPP TS 29.512 [8].

The PCF shall include in the "evNotifs" attribute, together with the event "FAILED_RESOURCES_ALLOCATION", an event of the "AfEventNotification" data type with the "event" attribute set to the value "RAN_NAS_CAUSE".

The PCF shall include more than one entry in the "contVers" attribute for the same media component if the PCF has received multiple content versions as described in clause 4.2.6.2.14 in 3GPP TS 29.512 [8].

When all the service data flows within the AF session are affected, the PCF shall inform the NF service consumer by sending a notification about application session context termination as defined in clause 4.2.5.3.

Signalling flows for Service Data Flow Deactivation cases are presented in 3GPP TS 29.513 [7].

4.2.5.6 Reporting usage for sponsored data connectivity

When "SponsoredConnectivity" is supported, the NF service consumer enabled sponsored data connectivity and the NF service consumer provided usage thresholds for such sponsor to the PCF, the PCF shall report accumulated usage to the NF service consumer using the Npcf_PolicyAuthorization_Notify service operation when:

– the PCF detects that the usage threshold provided by the NF service consumer has been reached; or

– the NF service consumer disables the sponsored data connectivity.

The PCF shall notify the NF service consumer of the accumulated usage by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include:

– an event of the "AfEventNotification" data type in the "evNotifs" attribute with the matched event "USAGE_REPORT" in the "event" attribute; and

– the accumulated usage, corresponding to the usage since the last report to the AF, encoded in the "usgRep" attribute.

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF. The NF service consumer may terminate the AF session sending an HTTP POST as described in clause 4.2.4.2 or update the AF application session context information by providing a new usage threshold sending an HTTP PATCH request to the PCF as described in clause 4.2.3.5 or an HTTP PUT request to the PCF as described in clause 4.2.6.4.

NOTE: Once the accumulated usage is reported by the PCF to the AF, the monitoring will not start until the PCF receives the new threshold from the NF service consumer and provides it to the SMF.

4.2.5.7 Void

4.2.5.8 Notification about resources allocation outcome

When the PCF becomes aware that the resources associated to service information for one or more SDFs have been allocated, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "SUCCESSFUL_RESOURCES_ALLOCATION" event as described in clauses 4.2.2.10 and 4.2.3.10. The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2. The PCF shall include in the "evNotifs" attribute an entry with the "event" attribute set to "SUCCESSFUL_RESOURCES_ALLOCATION" and (if not all the flows are affected) the identification of the related media components in the "flows" attribute. If the "MediaComponentVersioning" feature is supported, the PCF shall also include in the "flows" attribute the "contVers" attribute with the content version(s) of the media components if the content version was included when the corresponding media component was provisioned.

If the "AuthorizationWithRequiredQoS" feature or the "AltSerReqsWithIndQoS" feature as defined in clause 5.8 is supported, when the PCF becomes aware that the resources associated to service information for one or more SDFs have been allocated and additionally receives the alternative QoS parameter set(s), the PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2. The PCF shall include:

– an entry in the "evNotifs" attribute with the "event" attribute set to "SUCCESSFUL_RESOURCES_ALLOCATION"; and

– the "succResourcAllocReports" attribute with the reference to the Alternative Service Requirement corresponding alternative QoS parameter set within the "altSerReq" attribute and the identification of the related media components in the "flows" attribute. If the "AltQoSProfilesSupportReport" feature is supported, and the PCF received the "altQosNotSuppInd" attribute set to false and the PCF did not receive alternative service QoS parameter set within the "altSerReq" attribute as specified in 3GPP TS 29.512 [8] clause 4.2.4.14, the PCF shall include the "altSerReq" attribute to false to indicate that alternative QoS parameters are supported by the access network and the lowest priority alternative QoS profile cannot be fulfilled. If the "MediaComponentVersioning" feature is supported, the PCF shall also include in the "flows" attribute the "contVers" attribute with the content version(s) of the media components if the content version was included when the corresponding media component was provisioned.

When the PCF becomes aware that the resources associated to service information for one or more SDFs cannot be allocated, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "FAILED_RESOURCES_ALLOCATION" event as described in clauses 4.2.2.10 and 4.2.3.10. The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2. The PCF shall include:

– an entry in the "evNotifs" attribute with the "event" attribute set to "FAILED_RESOURCES_ALLOCATION"; and

– the "failedResourcAllocReports" attribute with the active/inactive status of the PCC rules related to certain media components encoded in the "mcResourcStatus" attribute, and (if not all the flows are affected) the identification of the related media components in the "flows" attribute. If the "MediaComponentVersioning" feature is supported, the PCF shall also include in the "flows" attribute the "contVers" attribute with the content version(s) of the media components if the content version was included when the corresponding media component was provisioned.

When the feature "UEUnreachable" is supported and if the PCF becomes aware that the UE is temporarily unavailable and thus the resources associated to service information for one or more SDFs are not allocated, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "UE_TEMPORARILY_UNAVAILABLE" event as described in clauses 4.2.2.10 and 4.2.3.10. The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2. The PCF shall include:

– an entry in the "evNotifs" attribute with the "event" attribute set to "UE_TEMPORARILY_UNAVAILABLE",

– the "retryAfter" attribute if this information was received from the SMF.

NOTE: The NF service consumer will use the content version to identify the media component version that failed or succeeded when multiple provisions of the same media component occur in a short period of time. How the NF service consumer handles such situations is out of scope of this specification.

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF.

Signalling flows for resource allocation outcome are presented in 3GPP TS 29.513 [7].

4.2.5.9 Void

4.2.5.10 Notification of signalling path status

When the PCF is notified of the loss or release of resources associated to the PCC rules corresponding with AF signalling IP flows, the PCF shall inform the NF service consumer about the loss of the signalling transmission path if the NF service consumer has previously subscribed as described in clause 4.2.6.7.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include within the "evNotifs" attribute an event of "AfEventNotification" data type indicating the matched event "FAILED_RESOURCES_ALLOCATION" in the "event" attribute and the deactivated IP flow encoded in the "flows" attribute.

If the "RAN-NAS-Cause" feature is supported and the PCF received the RAN-NAS release cause and/or access network information from the SMF, the PCF shall provide in the "EventsNotification" data type in the "200 OK" response to the HTTP POST request:

– in case of 3GPP access, the user location information in the "eutraLocation" or in the "nrLocation" attribute in the "ueLoc" attribute, if available;

– in case of untrusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if available, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute; and

b) the UDP source port or the TCP source port in the "portNumber" and "protocol" attributes, if available; and

c) if the "WLAN_Location" feature is supported, the WLAN location information encoded in the "twapId" attribute, if available, that shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

NOTE 1: When the UE reaches the ePDG via a NAT, the combination of UE local IP address and the UE source port is needed for lawful interception purposes. The UE source port may be either a UDP or a TCP port, and it is indicated in the "protocol" attribute.

– in case of trusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if available, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute, if available; and

b) the UDP source port in the "portNumber" attribute if available; and

NOTE 2: The UDP protocol can be used between the UE and the TNGF to enable NAT traversal.

c) either the TNAP identifier encoded in the "tnapId" attribute or the TWAP identifier encoded in the "twapId" attribute. The TNAP identifier and the TWAP identifier shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

– the UE timezone in the "ueTimeZone" attribute if available; and

– the RAN and/or NAS release cause in the "ranNasRelCauses" attribute, if available.

NOTE 3: The PCF forwards both 3GPP and non-3GPP access UE locations in the "ueLoc" attribute when both UE locations are provided by the SMF as defined in 3GPP TS 29.512 [8].

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF.

4.2.5.11 Reporting access network information

This procedure is used by the PCF to report the access network information (i.e. user location and/or user timezone information) to the NF service consumer when the "NetLoc" feature is supported.

When the PCF receives the access network information from the SMF, the PCF shall include the "EventsNotification" data type in the body of the HTTP POST request message sent to the NF service consumer as described in clause 4.2.5.2. The PCF shall include in the "EventsNotification" data type:

– in case of 3GPP access, the user location information in the "eutraLocation" or in the "nrLocation" attribute in the "ueLoc" attribute, if available and required;

– in case of untrusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if required, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute, if available;

b) the UDP source port or the TCP source port in the "portNumber" and "protocol" attributes, if available; and

c) if the "WLAN_Location" feature is supported, the WLAN location information encoded in the "twapId" attribute, if available, that shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

– in case of trusted non-3GPP access, the user location information in the "n3gaLocation" attribute in the "ueLoc" attribute, if required, as follows:

a) the user local IP address in the "ueIpv4Addr" or "ueIpv6Addr" attribute, if available; and

b) the UDP source port in the "portNumber" attribute if available; and

NOTE 2: The UDP protocol can be used between the UE and the TNGF to enable NAT traversal.

c) either the TNAP identifier encoded in the "tnapId" attribute or the TWAP identifier encoded in the "twapId" attribute. The TNAP identifier and the TWAP identifier shall consist of:

i. the SSID in the "ssId" attribute;

ii. the BSSID the "bssId" attribute if available; and

iii. the civic address in the "civicAddress" attribute if available;

– if user location was required, the time when it was last known in the "ueLocTime" attribute if available;

NOTE 3: The PCF derives the value of the "ueLocTime" attribute from the "userLocationInfoTime" attribute received from the SMF as specified in 3GPP TS 29.512 [8].

– the UE timezone in the "ueTimeZone" attribute if required and available.

NOTE 4: The PCF forwards both 3GPP and non-3GPP access UE locations in the "ueLoc" attribute when both UE locations are provided by the SMF as defined in 3GPP TS 29.512 [8].

When the PCF receives from the SMF that the access network does not support access network information report, the PCF shall include the "noNetLocSupp" attribute set to "ANR_NOT_SUPPORTED", "TZR_NOT_SUPPORTED" or "LOC_NOT_SUPPORTED" value received from the SMF in the "EventsNotification" data type in the "200 OK" response to the HTTP POST request.

The PCF shall also include an event of the "AfEventNotification" data type in the "evNotifs" attribute with the "event" attribute set to the value "ANI_REPORT".

NOTE 5: The PCF receives the access network information from the SMF if it is previously requested by the NF service consumer or at PDU session termination or at the termination of all the service data flows of the AF session.

The PCF shall not invoke the Npcf_PolicyAuthorization_Notify service operation with the "event" attribute set to the value "ANI_REPORT" to report to the NF service consumer any subsequently received access network information, unless the NF service consumer sends a new request for access network information.

4.2.5.12 Notification about Out of Credit

If the "IMS_SBI" feature is supported and if the PCF becomes aware that there is no credit available in the CHF for one or more SDFs, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "OUT_OF_CREDIT" event as described in clauses 4.2.2.22 and 4.2.3.22.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include:

– in the "evNotifs" attribute an entry with the "event" attribute set to the value "OUT_OF_CREDIT"; and

– the "outOfCredReports" attribute containing in each entry of the "OutOfCreditInformation" data type the credit information for one or more service data flows. The "OutOfCreditInformation" data type shall contain the termination action in the "finUnitAct" attribute, and the identification of the affected service data flows (if not all the flows are affected) encoded in the "flows" attribute.

Upon the reception of the HTTP POST request from the PCF, the NF service consumer shall acknowledge that request by sending an HTTP response message as described in clause 4.2.5.2.

4.2.5.13 Notification about TSC user plane node management information and/or port management information detection, Individual Application Session Context exists

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication"feature is supported and if the PCF becomes aware that, for an existing Individual Application Session Context resource, updated TSC user plane node information is available, e.g., a UMIC and/or a DS-TT PMIC and/or one or more NW-TT PMIC(s) are available, the PCF shall inform the NF service consumer (i.e., the TSN AF or the TSCTSF) accordingly, if the NF service consumer has previously subscribed as described in clause 4.2.2.31.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include in the "evNotifs" attribute an entry with the "event" attribute set to the value "TSN_BRIDGE_INFO", and the "tsnBridgeManCont" attribute and/or the "tsnPortManContDstt" attribute and/or the "tsnPortManContNwtts" attribute as received from the SMF if the PCF is aware that a UMIC and/or a DS-TT PMIC and/or one or more NW-TT PMIC(s) are available or updated.

Upon the reception of the HTTP POST request from the PCF, the NF service consumer shall acknowledge that request as specified in clause 4.2.5.2.

The NF service consumer may use the received UMIC and/or the received DS-TT PMIC and/or NW-TT PMIC(s) and the local configuration to construct the DS-TT port and or NW-TT port management information required to interwork with the external network (e.g. TSN).

If port management information shall be sent as a response of the received notification, the NF service consumer triggers the Npcf_PolicyAuthorization_Update service operation to send the port management information to the PCF as specified in clause 4.2.3. The NF service consumer delivers to the PCF the derived port management information containers as described in clause 4.2.3.25.

And/or if TSC user plane node management information shall be sent as a response of the received notification, the NF service consumer includes the UMIC in the Npcf_PolicyAuthorization_Update service operation as described in clause 4.2.3.25.

4.2.5.14 Notification about Service Data Flow QoS Monitoring control

When the PCF gets the information about any one of the following items for one or more SDFs from the SMF:

– uplink packet delay(s);

– downlink packet delay(s); and/or

– round trip delay(s);

the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed as described in clauses 4.2.2.23 and 4.2.3.23 and 4.2.6.8.

The PCF shall notify the NF service consumer of the QoS monitoring events by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include:

– within the "evNotifs" attribute an event entry of the "AfEventNotification" data type with the matched event "QOS_MONITORING" in the "event" attribute; and

– the "qosMonReports" array with:

a) the identification of the affected service flows (if not all the flows are affected) encoded in the "flows" attribute if applicable; and

b) one or two uplink packet delays within the "ulDelays" attribute;

c) one or two downlink packet delays within the "dlDelays" attribute; and/or

d) one or two round trip packet delays within the "rtDelays" attribute.

4.2.5.15 Report of EPS Fallback

When "EPSFallbackReport" feature is supported and the PCF becomes aware of the EPS Fallback for the resources requested for a particular service information (voice media type), the PCF shall inform the NF service consumer if the NF service consumer has previously subscribed as described in clauses 4.2.2.30 and 4.2.3.29.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include within the "evNotifs" attribute an event entry of the "AfEventNotification" data type with the matched event "EPS_FALLBACK" in the "event" attribute.

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF.

4.2.5.16 Notification about TSC user plane node Information, no Individual Application Session Context exists

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported and if the PCF becomes aware that TSC user plane node information for an external network (e.g. TSN) is available, but there is no "Individual Application Session Context" resource bound to the SM Policy Association updated with TSC user plane node related information, the PCF shall inform the NF service consumer (i.e. TSN AF or TSCTSF) about the detection of a TSC user plane node information in the context of a PDU session by sending a notification request:

– to the request URI locally configured in the PCF for the NF service consumer; or

– if the request URI for the TSCTSF is not locally configured in the PCF, to the notification URI registered by the TSCTSF in the NRF as default notification subscription for time sensitive communication and time synchronization notifications, and retrieved from NRF by the PCF using the discovery service, as specified in 3GPP TS 29.510[27] for the PDU session DNN/S-NSSAI.

NOTE 1: PCF configuration of TSN AF needs to ensure that the notification is addressed to a TSN AF that connects to the same external network the UPF/NW-TT connects to. How it is achieved is implementation specific. It can be based e.g. on dedicated DNN/S-NSSAI combinations or on the received TSC user plane node information.

NOTE 2: It is assumed that there is only one TSCTSF for a given DNN/S-NSSAI in this release of the specification.

Figure 4.2.5.16-1 illustrates the notification about TSC user plane node information when there is no Individual Application Session Context bound to the SM Policy Association.

Figure 4.2.5.16-1: Notification about TSC user plane node Information, no AF session context exists

When the PCF determines that the AF application session context does not exist for the SM Policy Association that detected new port information and a notification URI for the NF service consumer can be determined, the PCF shall invoke the Npcf_PolicyAuthorization_Notify service operation by sending the HTTP POST request (as shown in figure 4.2.5.16-1, step 1) using the notification URI locally configured in the PCF or, retrieved from NRF, and appending the "new-bridge" segment path at the end of the URI, to trigger the NF service consumer (i.e. TSN AF or TSCTSF) to request the creation of an Invidual Application Session Context resource to handle the TSC user plane node detected in the context of a PDU session, configuring ports and TSC user plane node management information, and providing the corresponding TSCAI input containers and TSC traffic QoS related data (see clauses 4.2.2.2, 4.2.2.24, 4.2.2.25 and 4.2.2.31).

The PCF shall provide in the body of the HTTP POST request the "PduSessionTsnBridge" data type including TSC user plane node information as follows:

– the "tsnBridgeInfo" attribute as received from the SMF;

– the "tsnBridgeManCont" attribute as received from the SMF, if available;

– the "tsnPortManContDstt" attribute and/or "tsnPortManContNwtts" attribute as received from the SMF, if available; and

– when the "TimeSensitiveCommunication" feature is supported and for a PDU session of IP type, the UE IPv4 address within the "ueIpv4Addr" attribute or the UE IPv6 prefix within the "ueIpv6AddrPrefix", the DNN within the "dnn" attribute, the S-NSSAI within the "snssai" attribute and, if available, the domain identity within the "ipDomain" attribute if UE IPv4 address is provided.

NOTE 3: In the case of IP overlapping, the DNN, S-NSSAI and domain identity, if available, are required for session binding in the PCF. Domain identity applies as defined in clause 4.2.2.2.

Upon the reception of the HTTP POST request from the PCF, the NF service consumer shall acknowledge that request.

With the received information, the NF service consumer (i.e. TSN AF or TSCTSF) shall immediately trigger the creation of an Individual Application Session Context resource to handle in this association the configuration of the new TSC user plane node in the context of this PDU session, as described in clauses 4.2.2.2, 4.2.2.24, 4.2.2.25 and 4.2.2.31.

NOTE 4: For the time synchronization service, the subscription to UE availability for time-synchronization service can occur after the PDU Session establishment has been completed in 5GS. Similarly, for the AF session with required QoS, the indication of the required QoS and TSC Assistance Container information can occur after the completion of the PDU session establishment. In such cases, the PCF sends the notification to the TSCTSF about the detection of a TSC user plane node information during PDU session establishment, and the TSCTSF could defer the creation of the related "Individual Application Session Context" till the reception of the subscription to UE availability for time synchronization or the AF session with required QoS occurs, as specified in 3GPP TS 29.513[7].

The NF service consumer (i.e. TSN AF or TSCTSF) may use the received TSC user plane node information and/or the received DS-TT port management information container and/or NW-TT port management information containers and the local configuration to construct the DS-TT port and or NW-TT port management information required to interwork with the external network.

4.2.5.17 Notification about Reallocation of Credit

If the "IMS_SBI" and the "ReallocationOfCredit" features are supported and if the PCF becomes aware that there is credit reallocated for one or more SDFs after a former out of credit indication, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "REALLOCATION_OF_CREDIT" event as described in clauses 4.2.2.34 and 4.2.3.32.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include in the "evNotifs" attribute an entry with:

– the "event" attribute set to the value "REALLOCATION_OF_CREDIT"; and

– the SDFs that are impacted as consequence of the reallocation of credit condition encoded in the "flows" attribute.

Upon the reception of the HTTP POST request from the PCF, the NF service consumer shall acknowledge that request by sending an HTTP response message as described in clause 4.2.5.2.

4.2.5.18 Notification of MPS for DTS Outcome

When the MPSforDTS feature is supported and the PCF is informed about the successful default QoS update, the PCF shall notify the NF service consumer as described in clause 4.2.5.2, if the NF service consumer has previously subscribed to the "SUCCESSFUL_QOS_UPDATE" event as described in clauses 4.2.2.12.2 and 4.2.3.12. The PCF shall notify the NF service consumer by including within the "evNotifs" attribute, an entry with the "event" attribute set to "SUCCESSFUL_QOS_UPDATE".

When the MPSforDTS feature is supported and the PCF is informed about the failure of a default QoS update, the PCF shall notify the NF service consumer as described in clause 4.2.5.2, if the NF service consumer has previously subscribed to the "FAILED_QOS_UPDATE" event as described in clauses 4.2.2.12.2 and 4.2.3.12. The PCF shall notify the NF service consumer by including within the "evNotifs" attribute, an entry with the "event" attribute set to "FAILED_QOS_UPDATE".

4.2.5.19 Notification about Application Detection Information

When the "ApplicationDetectionEvents" feature is supported, when the PCF gets the knowledge that the traffic of the indicated application started or stopped, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed as described in clauses 4.2.6.9.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include, for the detected application(s)’s traffic:

– within the "evNotifs" attribute an event entry of the "AfEventNotification" data type with the matched event "APP_DETECTION" in the "event" attribute; and

– the "adReports" array, which for each detected application’s traffic shall include:

a) the "adNotifType" attribute to indicate whether the detection is about the start of the application’s traffic encoded as the "APP_START" value, or about the stop of the application’s traffic encoded as the "APP_STOP" value; and

b) the application identifier within the "afAppId" attribute.

When the NF service consumer receives the HTTP POST request, it shall acknowledge the request by sending a "204 No Content" response to the PCF.

Signalling flows for the notification of application detection information are presented in 3GPP TS 29.513 [7].

NOTE: When the NF service consumer receives the notifications for multiple applications, the NF service consumer (e.g. the PCF for the UE) can determine which logic to apply (e.g. which AM policy to apply) based on local configuration and operator policy.

In this release of the specification application detection applies only to the application(s) with IP traffic.

4.2.5.20 Notification about satellite backhaul category changes

When the PCF gets the knowledge that there is a change of the backhaul used for the PDU session between satellite backhaul categories (i.e., GEO, MEO, LEO, or other satellite) or between a satellite and a non-satellite backhaul category, the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed as described in clauses 4.2.2.35 and 4.2.3.33 and 4.2.6.10.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include within the "evNotifs" attribute an event entry of the "AfEventNotification" data type with the matched event "SAT_CATEGORY_CHG" in the "event" attribute, and within the "satBackhaulCategory" attribute the received satellite backhaul category (i.e., GEO, MEO, LEO, or other satellite) or the indication of non-satellite backhaul.

4.2.5.21 Notification about UP change enforcement failure

If the "RoutingReqOutcome" feature is supported and if the PCF becomes aware that the enforcement of the UP path change fails (as specified in clause 4.2.6.2.6.2 of 3GPP TS 29.512 [8]), the PCF shall inform the NF service consumer accordingly if the NF service consumer has previously subscribed to the "UP_PATH_CHG_FAILURE" event as described in clauses 4.2.2.8 and 4.2.3.8.

The PCF shall notify the NF service consumer by including the "EventsNotification" data type in the body of the HTTP POST request as described in clause 4.2.5.2.

The PCF shall include in the "evNotifs" attribute an entry with the "event" attribute set to the value "UP_PATH_CHG_FAILURE".

Upon the reception of the HTTP POST request from the PCF, the NF service consumer shall acknowledge that request by sending an HTTP response message as described in clause 4.2.5.2.

4.2.5.22 Notification about PDU session established/terminated events

If the PCF becomes aware that the SM Policy Association contains the callback URI of the PCF for a UE then, the PCF shall inform the NF service consumer (i.e. the PCF for a UE) about:

– the PDU session establishment, when the PCF receives the callback URI of the PCF for a UE from the SMF; and

– the PDU session termination, when the PCF receives the SM Policy Association termination from the SMF;

by sending a notification request to the received callback URI of the PCF for a UE.

Figure 4.2.5.22-1 illustrates the notification about PDU session established/terminated events.

Figure 4.2.5.22-1: Notification about PDU session established/terminated events

When the PCF becomes aware that a SM Policy Association is receiving the callback URI of the PCF for a UE, or becomes aware that the SM Policy Association that is terminating contains the callback URI of the PCF for a UE, the PCF shall invoke the Npcf_PolicyAuthorization_Notify service operation by sending an HTTP POST request (as shown in figure 4.2.5.22-1, step 1) using the callback URI contained in the SM Policy Association and appending the "pdu-session" path segment at the end of the URI.

NOTE: The PCF includes in the notification request a Routing Binding Indication as specified in 3GPP TS 29.500 [5], clause 6.12 if an SBA binding indication relative to the PCF for a UE is available in the SM Policy Association together with the callback URI of the PCF for a UE.

The PCF shall provide in the body of the HTTP POST request the PduSessionEventNotification data type, which shall include an indication of PDU session establishment/termination as follows:

– the "evNotif" attribute, of "AfEventNotification" data type, which shall include the "PDU_SESSION_STATUS" event within the "event" attribute;

– the SUPI of the PDU session within the "supi" attribute;

– the served UE address as the identification of the reported PDU session:

i. for IP type PDU sessions, the IP address (IPv4 or IPv6) of the UE in the "ueIpv4" or "ueIpv6" attribute; and

ii. for Ethernet type PDU sessions, the MAC address of the UE in the "ueMac" attribute;

– whether the PDU session is established or terminated within the "status" attribute; and

– when the "status" attribute indicates "ESTABLISHED":

i. the PCF addressing information where the NF service consumer (i.e. PCF for a UE) may send the subscription request to notification about the detected application traffic in the "pcfInfo" attribute; and

ii. the context information of the related PDU session, i.e., the DNN withing the "dnn" attribute, the S-NSSAI within the "snssai" attribute and the GPSI within the "gpsi" attribute, if available.

Upon the reception of the HTTP POST request from the PCF, and if the request is accepted, the NF service consumer (i.e. PCF for a UE) shall acknowledge that request by sending an HTTP response message with a "204 No Content" status code as described in figure 4.2.5.22-1, step 2.

The NF service consumer (i.e. PCF for a UE) may use the notified PCF address(es) and SBA binding indication, if available, to subscribe with the PCF for a PDU session to the detection of application(s) traffic, as described in clause 4.2.6.9.