4.2.3 Npcf_PolicyAuthorization_Update service operation

29.5143GPP5G SystemPolicy Authorization ServiceRelease 18Stage 3TS

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

4.2.3.1 General

The Npcf_PolicyAuthorization_Update service operation provides updated application level information from the NF service consumer and optionally communicates with the Npcf_SMPolicyControl service to determine and install the policy according to the information provided by the NF service consumer.

The Npcf_PolicyAuthorization_Update service operation updates an application session context in the PCF.

The following procedures using the Npcf_PolicyAuthorization_Update service operation are supported:

– Modification of service information.

– Gate control.

– Background Data Transfer policy indication at policy authorization update.

– Modification of sponsored connectivity information.

– Modification of Subscription to Service Data Flow QoS notification control.

– Modification of Subscription to Service Data Flow Deactivation.

– Update of traffic routing information.

– Modification of subscription to resources allocation outcome.

– Modification of Multimedia Priority Services.

– Support of content versioning.

– Request of access network information.

– Modification of service information status.

– Support of SIP forking.

– Provisioning of signalling flow information.

– Support of resource sharing.

– Modification of MCPTT.

– Modification of MCVideo.

– Priority sharing indication.

– Modification of subscription to out of credit notification.

– Modification of Subscription to Service Data Flow QoS Monitoring Information.

– Update of TSCAI Input Information and TSC QoS related data.

– Provisioning of TSC user plane node management information and port management information.

– Support of CHEM feature.

– Support of FLUS feature.

– Subscription to EPS Fallback report.

– Modification of required QoS information.

– Support of QoSHint feature.

– Modification of subscription to reallocation of credit notification.

– Modification of subscription to satellite backhaul category changes.

4.2.3.2 Modification of service information

This procedure is used to modify an existing application session context as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4] when the feature "PatchCorrection" is supported.

Figure 4.2.3.2-1 illustrates the modification of service information using HTTP PATCH method.

Figure 4.2.3.2-1: Modification of service information using HTTP PATCH

The NF service consumer may modify the application session context information at any time (e.g. due to an AF session modification or internal NF service consumer trigger) and invoke the Npcf_PolicyAuthorization_Update service operation by sending the HTTP PATCH request message to the resource URI representing the "Individual Application Session Context" resource, as shown in figure 4.2.3.2-1, step 1, with the modifications to apply.

The JSON body within the PATCH request shall include the "AppSessionContextUpdateDataPatch" data type and shall be encoded according to "JSON Merge Patch", as defined in IETF RFC 7396 [21]. The modifications to apply are encoded within the attributes of the "ascReqData" attribute, as described below and in subsequent clauses.

The NF service consumer may include the updated service information in the "medComponents" attribute of the "ascReqData" attribute.

If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported, the NF service consumer may provide within the MediaComponentRm data structure an update of the required QoS information as specified in clause 4.2.3.30.

The NF service consumer may include in the "ascReqData" attribute an AF application identifier in the "afAppId" attribute to trigger the PCF to indicate to the SMF/UPF to perform the application detection based on the operator’s policy as defined in 3GPP TS 29.512 [8].

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported, the NF service consumer may provide TSC user plane node related information as specified in clauses 4.2.3.24 and 4.2.3.25.

The NF service consumer may also create, modify or remove events subscription information by sending the HTTP PATCH request message to the resource URI representing the "Individual Application Session Context" resource.

The NF service consumer shall create event subscription information by including in the "ascReqData" attribute the "evSubsc" attribute of "EventsSubscReqDataRm" data type with the corresponding list of events to subscribe to; and the "notifUri" attribute with the notification URI where the PCF shall send the notifications.

The NF service consumer shall update existing event subscription information by including in the "ascReqData" attribute an updated value of the "evSubsc" attribute of the "EventsSubscReqDataRm" data type as follows:

– The "events" attribute shall include the new complete list of subscribed events.

– When the NF service consumer requests to update the additional information related to an event (e.g. the NF service consumer needs to provide new thresholds to the PCF in the "usgThres" attribute related to the "USAGE_REPORT" event) the NF service consumer shall include the additional information, which shall completely replace the previously provided one.

NOTE 1: Note that when the NF service consumer requests to remove an event, this event is not included in the "events" attribute.

NOTE 2: When an event is included in the "events" attribute and its related additional information is set to null, the PCF considers the subscription to this event is active, but the related procedures stop applying.

NOTE 3: When an event is removed from the "events" attribute but its related information is not set to null, the PCF considers the subscription to this event is terminated, the related additional information is removed, and the related procedures stop applying.

The NF service consumer shall remove existing event subscription information by setting to null the "evSubsc" attribute included in the "ascReqData" attribute.

Events with "notifMethod" set to "ONE_TIME" shall only apply at the time the NF service consumer requests their subscription. Once the event report is performed, the subscription to this event is automatically terminated in the PCF and the related information is removed. The presence of a one-time event, together with its related additional information when applicable, during an update procedure shall represent the recreation of the subscription to this event in the PCF.

NOTE 4: The "notifUri" attribute within the EventsSubscReqData data structure can be modified to request that subsequent notifications are sent to a new NF service consumer.

If the PCF cannot successfully fulfil the received HTTP PATCH request due to the internal PCF error or due to the error in the HTTP PATCH request, the PCF shall send the HTTP error response as specified in clause 5.7.

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

Otherwise, the PCF shall process the received service information according the operator policy and may decide whether the HTTP request message is accepted or not.

If the updated service information is not acceptable (e.g. the subscribed guaranteed bandwidth for a particular user is exceeded or the authorized data rate in that slice for the UE is exceeded), the PCF shall include in an HTTP "403 Forbidden" response message the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".

If the PCF detects that a temporary network failure has occurred (e.g. the SGW has failed as defined in clause B.3.3.3 or B.3.4.9 of 3GPP TS 29.512 [8]) and the AF initiates an Npcf_PolicyAuthorization_Update service operation, the PCF shall reject the request with an HTTP "403 Forbidden" response including the "cause" attribute set to "TEMPORARY_NETWORK_FAILURE".

If the service information provided in the HTTP PATCH request is rejected due to a temporary condition in the network (e.g. the NWDAF reported the network slice selected for the PDU session is congested), the PCF may include in the "403 Forbidden" response the "cause" attribute set to "REQUESTED_SERVICE_TEMPORARILY_NOT_AUTHORIZED". The PCF may also provide a retry interval within the "Retry-After" HTTP header field. When the NF service consumer receives the retry interval within the "Retry-After" HTTP header field, the NF service consumer shall not send the same service information to the PCF again (for the same application session context) until the retry interval has elapsed. The "Retry-After" HTTP header is described in 3GPP TS 29.500 [5] clause 5.2.2.2.

NOTE 5: When the PCF supports data rate control per network slice and/or data rate control per network slice for a UE as specified in 3GPP TS 29.512 [8] and the authorized data rate in a slice is exceeded due to the bandwidth demands of the modified service information, it is also possible to accept the request based on operator policies. In this case the derived PCC rule(s) belonging to the authorized GBR service data flows can include a different MBR and/or have a different charging than the one applicable if the data rate is not exceeded as specified in 3GPP TS 29.512 [8].

The PCF may additionally provide the acceptable bandwidth within the attribute "acceptableServInfo" included in the "ExtendedProblemDetails" data structure returned in the rejection response message.

If the request is accepted, the PCF shall update the service information with the new information received. Due to the updated service information, the PCF may need to create, modify or delete the related PCC rules as specified in 3GPP TS 29.513 [7] and provide the updated information towards the SMF following the corresponding procedures specified in 3GPP TS 29.512 [8].

Based on the received subscription information from the NF service consumer, the PCF may create a subscription to event notifications or may modify the existing subscription to event notifications, for a related PDU session from the SMF, as described in 3GPP TS 29.512 [8].

The PCF shall reply with the HTTP response message to the NF service consumer and may include the "AppSessionContext" data type payload body with the representation of the modified "Individual Application Session Context" resource and may include the "Events Subscription" sub-resource.

The PCF shall include in the "evsNotif" attribute:

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

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

NOTE 7: 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" event in the HTTP PATCH request, 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

ii. if the "ATSSS" feature is supported, the "addAccessInfo" attribute with the additional access type information if available, 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; and

NOTE 8: For a MA PDU session, if the "ATSSS" feature is not supported by the NF service consumer, the PCF includes the "accessType" attribute and the "ratType" attribute with a currently active combination of access type and RAT type (if applicable for the notifed access type). When both 3GPP and non-3GPP accesses are available, the PCF includes the information corresponding to the 3GPP access.

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

if the PCF has previously requested to be updated with this information in the SMF; and

– if the "IMS_SBI" feature is supported and if the NF service consumer subscribed to the "CHARGING_CORRELATION" event in the HTTP PATCH request, 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 subscription to other specific events using the Npcf_PolicyAuthorization_Update request is described in the related clauses. Notification of events when the applicable information is not available in the PCF when receiving the Npcf_PolicyAuthorization_Update request is described in clause 4.2.5.

The HTTP response message towards the NF service consumer should take place before or in parallel with any required PCC rule provisioning towards the SMF.

If the PCF does not have an existing application session context for the application session context being modified (such as after a PCF failure), the PCF shall reject the HTTP request message with the HTTP response message with the applicable rejection cause.

4.2.3.3 Gate control

This procedure is used by a NF service consumer to modify in the PCF the service data flow(s) that are to be enabled or disabled to pass through the PDU session.

The NF service consumer shall use the HTTP PATCH method to modify the gate control information.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, in the media component(s) included in the "medComponents" attribute at media and/or media subcomponent level, the "fStatus" attribute for the flows to be enabled or disabled with the appropriate value.

If a "medSubComps" attribute contains a "flowUsage" attribute with the value "RTCP", then the IP Flows described by that media subcomponent shall be enabled in both directions irrespective of the value of the "fStatus" attribute of the corresponding media component.

As result of this action, the PCF shall set the appropriate gate status for the corresponding active PCC rule(s).

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.4 Background Data Transfer policy indication at policy authorization update

This procedure is used by a NF service consumer to indicate at policy authorization update a transfer policy negotiated for background data transfer using the Npcf_BDTPolicyControl service as described in 3GPP TS 29.554 [14].

The NF service consumer may include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, a new reference id in the "bdtRefId" attribute.

NOTE 1: The PCF will retrieve the corresponding transfer policy from the UDR based on the reference identifier within the "bdtRefId" attribute. In case only one PCF is deployed in the network, transfer policies can be locally stored in the PCF and the interaction with the UDR is not required.

If the PCF cannot retrieve the transfer policy, the PCF shall set to TP_NOT_KNOWN the "servAuthInfo" attribute in the HTTP response message to the NF service consumer to indicate that the transfer policy is unknown.

If the time window of the received transfer policy has expired, the PCF shall set to TP_EXPIRED the "servAuthInfo" attribute in the HTTP response message to indicate to the NF service consumer that the transfer policy has expired. Otherwise, if the time window of the received transfer policy has not yet occurred, the PCF shall set to TP_NOT_YET_OCCURRED the "servAuthInfo" attribute in the HTTP response message to the NF service consumer to indicate that the time window of the transfer policy has not yet occurred.

NOTE 2: In the case that the PCF cannot retrieve the transfer policy, the transfer policy time window has not yet occurred or the transfer policy expired, the PCF makes the decision without considering the transfer policy.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.5 Modification of sponsored connectivity information

This procedure is used by a NF service consumer to modify sponsored data connectivity when "SponsoredConnectivity" feature is supported.

The NF service consumer shall use the HTTP PATCH method to modify the sponsored connectivity information.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, an application service provider identity and a sponsor identity within the "aspId" attribute and "sponId" attribute, and optionally an indication of whether to enable or disable sponsored data connectivity within the "sponStatus" attribute set to the applicable value to provide sponsored connectivity information or to update existing sponsored connectivity information.

If the NF service consumer requests to enable sponsored data connectivity the NF service consumer shall change the "sponStatus" attribute value to "SPONSOR_ENABLED".

If the NF service consumer requests to disable sponsored data connectivity the NF service consumer shall provide an indication to disable sponsored data connectivity to the PCF by setting the "sponStatus" attribute to "SPONSOR_DISABLED".

To support the usage monitoring of sponsored data connectivity, the NF service consumer may also include in the HTTP PATCH a new or modified "evSubsc" attribute of "EventsSubscReqDataRm" data type with:

– the usage thresholds to apply in the "usgThres" attribute; and

– the subscription to usage monitoring for sponsored data connectivity in an entry of the "events" attribute of the "AfEventSubscription" data type with the "event" attribute set to "USAGE_REPORT".

NOTE 1: If the NF service consumer is in the user plane, the NF service consumer can handle the usage monitoring and therefore it is not required to provide a usage threshold to the PCF as part of the sponsored data connectivity information.

When the NF service consumer indicated to enable sponsored data connectivity, and the UE is roaming with the visited access case, the following procedures apply:

– If the NF service consumer is located in the HPLMN, for home routed roaming case and when operator policies do not allow accessing the sponsored data connectivity with this roaming case, the H-PCF shall reject the service request and shall include in the HTTP "403 Forbidden" response message the "cause" attribute set to "UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY".

– If the NF service consumer is located in the VPLMN, the V-PCF shall reject the service request and shall include in the HTTP "403 Forbidden" response message the "cause" attribute set to "UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY".

When the NF service consumer indicated to enable sponsored data connectivity, and the UE is in the non-roaming case or roaming with the home routed case and the operator policies allow accessing the sponsored data connectivity with this roaming case, the following procedures apply:

– If the SMF does not support sponsored connectivity and the required reporting level for that service indicates a sponsored connectivity level according to 3GPP TS 29.512 [8], then the PCF shall reject the request and shall include in the HTTP "403 Forbidden" response message the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".

– If the SMF supports sponsored data connectivity feature or the required reporting level is different from sponsored connectivity level as described in 3GPP TS 29.512 [8], then the PCF, based on operator policies, shall check whether it is required to validate the sponsored connectivity data. If it is required, it shall perform the authorizations based on sponsored data connectivity profiles. If the authorization fails, the PCF shall include in the HTTP "403 Forbidden" response message the "cause" attribute set to "UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY".

NOTE 2: The PCF is not required to verify that a trust relationship exists between the operator and the sponsors.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.6 Modification of Subscription to Service Data Flow QoS notification control

This procedure is used in the NF service consumer to modify in the PCF the subscription to notification about whether the GBR QoS targets can no longer (or can again) be guaranteed.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, the updated values of the "EventsSubscReqDataRm" data type, which either shall include in the "events" attribute a new element with the "event" attribute set to "QOS_NOTIF" to indicate the subscription to QoS notification control, or shall not include in the "events" attribute an existing element with the "event" attribute set to "QOS_NOTIF" to indicate the termination of the subscription to QoS notification control.

As result of this action, the PCF shall set the appropriate subscription to QoS notification control for the corresponding active PCC rule(s) as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.7 Modification of Subscription to Service Data Flow Deactivation

This procedure is used by a NF service consumer to modify in the PCF the subscription to the notification of deactivation of one or more Service Data Flows within the AF application session context.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

As result of this action, the PCF shall set the appropriate subscription to service data flow deactivation for the corresponding PCC rule(s) as described in in 3GPP TS 29.512 [8].

4.2.3.8 Update of traffic routing information

This procedure is used by NF service consumer to modify in the PCF the traffic routing information to a local access to a DNN, and/or to modify the subscription to notifications about UP path management when "InfluenceOnTrafficRouting" feature is supported.

When the "SimultConnectivity" feature is supported, this procedure may be used to modify (create, delete, update) the indication of simultaneous connectivity temporarily maintained for the source and target PSA and/or the indication of the minimum time interval to be considered for inactivity for the traffic routed via the source PSA.

When the "URLLC" feature is supported, this procedure may be used to modify (create, delete, update) the indication of UE IP address preservation.

When the "EASIPreplacement" feature is supported, this procedure may be used to modify (initially provide, delete, update) the EAS IP replacement information to the PCF.

The NF service consumer shall use the HTTP PATCH method.

To modify traffic routing information, the NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, an updated "afRoutReq" attribute(s) with the modified traffic routing information. To modify the indication of simultaneous connectivity and/or the termination of the simultaneous connectivity, the NF service consumer shall include an updated "simConnInd" attribute and/or an updated "simConnTem" attribute, if applicable. To modify the indication of UE IP address preservation, the NF service consumer shall include the updated indication of UE IP address preservation in the "addrPreserInd" attribute, if applicable. To modify the EAS IP replacement information, the NF service consumer shall include the updated/new "easIpReplaceInfos" attribute, if applicable. To modify the maximum allowed user plane latency, the NF service consumer shall include the updated/new "maxAllowedUpLat" attribute, if applicable.

To modify the subscription to notifications about UP path management events (create, delete or modify), the NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, the updated values of the "upPathChgSub" attribute with the modified subscription to UP path management events.

When the feature "RoutingReqOutcome" is supported:

– and the NF service consumer is creating or modifying AF routing information, the PCF may set the "servAuthInfo" attribute in the HTTP response message to "ROUT_REQ_NOT_AUTHORIZED" when the PCF determines, e.g. based on subscription, the AF influence on traffic routing is not allowed for the PDU session;

– when the NF service consumer requests the update of the steering of traffic to a DNAI and/or the subscription to notifications about UP path management events, the NF service consumer may subscribe to notifications of failures in the enforcement of UP path changes including within the "evSubsc" attribute the "event" attribute value "UP_PATH_CHG_FAILURE" in an entry of the "events" array, or may remove the subscription to notification of failures in the enforcement of UP path changes by not including the the "event" attribute value "UP_PATH_CHG_FAILURE" in an entry of the "events" array of the "evSubsc" attribute.

NOTE: In the case that the PCF determines that the requested AF routing requirements cannot be applied and returns the "servAuthInfo" attribute in the HTTP response, the PCF makes the decision without considering the requested AF routing requirements.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

The PCF shall store the application routing requirements included in the "afRoutReq" attribute.

The PCF shall check whether the updated application routing requirements require PCC rules to be created or modified to include updated traffic steering policies, or to update the application relocation possibility as specified in 3GPP TS 29.513 [7]. Provisioning of PCC rules to the SMF shall be carried out as specified at 3GPP TS 29.512 [8].

4.2.3.9 Void

4.2.3.10 Modification of subscription to resources allocation outcome

This procedure is used in the NF service consumer to modify in the PCF the subscription to notification about resources allocation outcome.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, the updated values of the "EventsSubscReqDataRm" data type, which either include in the "events" attribute a new element with the "event" attribute set to "SUCCESSFUL_RESOURCES_ALLOCATION","FAILED_RESOURCES_ALLOCATION" and/or "UE_TEMPORARILY_UNAVAILABLE" or remove in the "events" attribute an existing element with the "event" attribute set to "SUCCESSFUL_RESOURCES_ALLOCATION", "FAILED_RESOURCES_ALLOCATION" and/or "UE_TEMPORARILY_UNAVAILABLE".As a result of this action, the PCF shall set the appropriate subscription to notification of resources allocation outcome in the corresponding PCC Rule(s) as described in 3GPP TS 29.512 [8].

4.2.3.11 Void

4.2.3.12 Modification of Multimedia Priority Services

The NF service consumer may include, in the "ascReqData" attribute, the "mpsId" attribute if it was not previously provided in order to indicate that the modified AF session relates to an MPS session.

If the NF service consumer supports the SBI Message Priority mechanism for an MPS session, the NF service consumer shall include the "3gpp-Sbi-Message-Priority" custom HTTP header towards the PCF as described in clause 4.2.2.12.1.

If the PCF receives the "mpsId" attribute, the PCF shall take specific actions on the corresponding PDU session to ensure that the MPS session is prioritized as defined in 3GPP TS 29.512 [8].

NOTE: When the PCF supports data rate control per network slice and/or data rate control per network slice for a UE as specified in 3GPP TS 29.512 [8], it is possible that, subject to operator policy and national/regional regulations, prioritised services are exempted from the limitation of data rate per network slice. In that case the PCF will handle the request from the NF service consumer even if the authorized data rate per network slice is exceeded.

When the feature "MPSforDTS" is supported, the NF service consumer includes the "mpsAction" attribute to invoke or revoke MPS for DTS, as specified in clause 4.2.2.12.2. When invoking MPS for DTS, the NF service consumer shall include the "mpsAction" attribute set to "ENABLE_MPS_FOR_DTS" or "AUTHORIZE_AND_ENABLE_MPS_FOR_DTS". When the "ENABLE_MPS_FOR_DTS" value is received in the "mpsAction" attribute, and allowed by local policy, the PCF does not check the authorization of the request. When the "AUTHORIZE_AND_ENABLE_MPS_FOR_DTS" value is received in the "mpsAction" attribute, and allowed by local policy, the PCF shall check the user’s MPS subscription to authorize the request. When the request is to authorize and enable, and the request is not authorized (e.g. not allowed by MPS subscription), the PCF shall indicate in an HTTP "403 Forbidden" response message the cause for the rejection including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".

To revoke MPS for DTS, the NF service consumer shall include the "mpsAction" attribute set to "DISABLE_MPS_FOR_DTS". When the "DISABLE_MPS_FOR_DTS" value is received in the "mpsAction" attribute, and allowed by local policy, the PCF does not check the authorization of the request.

When modifying an Individual Application Session Context resource due to the invocation or revocation of the MPS for DTS service, the NF service consumer may subscribe to the outcome of the QoS updates by setting within the "evSubsc" attribute an event within the "events" array with:

– the "event" attribute set to the value "SUCCESSFUL_QOS_UPDATE" to report that the invocation/revocation requested by the NF service consumer was successful; and/or

– the "event" attribute set to the value "FAILED_QOS_UPDATE" to report that the invocation/revocation requested by the NF service consumer has failed.

4.2.3.13 Support of content versioning

The support of the media component versioning is optional. When the "MediaComponentVersioning" feature is supported, the NF service consumer and the PCF shall comply with the procedures specified in this clause.

Upon each media component modification encoded in the "medComponents" attribute included in the "ascReqData" attribute, if the content version was previously assigned to a media component, the NF service consumer shall assign a new content version. All the content related to that media component shall be included and the content version shall be unique for the lifetime of the media component.

NOTE: The NF service consumer will include all the content of the media component in each media component modification in order to ensure that the media component is installed with the proper information regardless of the outcome of the QoS flow procedure related to previous interactions that are not reported to the PCF yet.

If the PCF receives the "contVer" attribute for a certain media component, the PCF shall follow the procedures described in 3GPP TS 29.512 [8], clause 4.2.6.2.14.

4.2.3.14 Request of access network information

This procedure is used by a NF service consumer to request access network information for an existing "Individual Application Session Context" resource at service information modification when the "NetLoc" feature is supported.

NOTE 1: Clause 4.2.6.6 describes the NF service consumer request of access network information without providing service information.

The NF service consumer shall create event subscription information by including in the "AppSessionContextUpdateData" data type the "evSubsc" attribute of "EventsSubscReqData" data type with the corresponding list of events to subscribe to.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute:

– an entry of the "AfEventSubscription" data type in the "events" attribute with:

a) the "event" attribute set to the value "ANI_REPORT"; and

b) the "notifMethod" attribute set to the value "ONE_TIME"; and

– the "reqAnis" attribute, with the required access network information, i.e. user location and/or user time zone information).

When the PCF determines that the access network does not support the access network information reporting because the SMF does not support the NetLoc feature, the PCF shall respond to the NF service consumer including in the "EventsNotification" data type the "noNetLocSupp" attribute set to "ANR_NOT_SUPPORTED" value. Otherwise, the PCF shall immediately configure the SMF to provide such access information, as specified in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer with an HTTP response message as described in clause 4.2.3.2.

NOTE 2: The NF service consumer does not invoke the Npcf_PolicyAuthorization_Update service operation to remove subscription to access network information report since the "Access Network Information Notification" is the one-time reported event. Once the access network information is reported to the NF service consumer the subscription to the access network information report is automatically terminated in the PCF and the related information is removed.

4.2.3.15 Modification of service information status

When the "IMS_SBI" feature is supported, the NF service consumer may update the status of the service information. If the NF service consumer provides service information that has been fully negotiated (e.g. based on the SDP answer), the NF service consumer may include in the "ascReqData" attribute the "servInfStatus" attribute set to "FINAL". In this case the PCF shall authorize the session and provision the corresponding PCC rules to the SMF.

The NF service consumer may additionally provide preliminary service information not fully negotiated yet (e.g. based on the SDP offer) at an earlier stage. To do so, the NF service consumer shall include the "servInfStatus" attribute set to "PRELIMINARY". Upon receipt of such preliminary service information, the PCF shall perform an early authorization check of the service information. If the NF service consumer requests the PCF to report the access network information together with preliminary service information, the PCF shall immediately configure the SMF to provide the access network information.

4.2.3.16 Support of SIP forking

When the "IMS_SBI" feature is supported, this procedure is used by a NF service consumer to indicate that an existing "Individual Application Session Context" resource comprises service information about several SIP dialogues.

The NF service consumer shall use the HTTP PATCH method to modify the service information.

The NF service consumer may include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, the "sipForkInd" attribute and include the updated service information.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

When the "sipForkInd" attribute gets the value:

– "SEVERAL_DIALOGUES", the PCF shall send additional PCC rules or individual data flow filters to already provided PCC rules as described in Annex B.3.1.

– "SINGLE_DIALOGUE", the PCF shall update installed PCC rules and Authorized-QoS information as described in Annex B.3.2.

4.2.3.17 Provisioning of signalling flow information

This procedure is used by a NF service consumer to provision or de-provision information about the AF signalling IP flows between the UE and the NF service consumer.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute:

– when the procedure is used to provision information about the AF signalling IP flows, a media component within the "medComponents" attribute including the attributes described in clause 4.2.2.16 in the case of IMS restoration or clause 4.2.2.12.3 otherwise;

– when the procedure is used to de-provision information about the AF signalling IP flows, for the media subcomponents containing the AF signalling IP flows, the "fStatus" attribute set to the value "REMOVED".

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.18 Support of resource sharing

When the "ResourceSharing" is supported by the NF service consumer and the PCF, the NF service consumer may include, in the "ascReqData" attribute, the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute within a media component of the "medComponents" attribute to indicate to the PCF that the related media of the modified Individual Application Session Context resource may share resources with other media components in the related direction that include the same value in the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute.

The NF service consumer may modify the conditions for resource sharing by including the media component within the "medComponents" attribute with a new value for the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute. The NF service consumer may indicate that the related media of the modified Individual Application Session resource is not sharing resources with other media components in the related direction setting the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute to "null".

The NF service consumer shall use the HTTP PATCH method to update the "Individual Application Session Context resource" as described in clause 4.2.3.2.

If the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute are provided within a media component of the "medComponents" attribute, the PCF may apply the mechanisms for resource sharing as described in 3GPP TS 29.512 [8], clause 4.2.6.2.8.

4.2.3.19 Modification of MCPTT

The NF service consumer may include, in the "ascReqData" attribute, the "mcpttId" attribute in order to indicate that the modified "Individual Application Session Context" resource relates to the priority adjustment of an MCPTT session. When the PCF receives the "mcpttId" attribute related to that MCPTT session, the PCF may take specific actions on the corresponding PDU session to ensure that the MCPTT session is prioritized. For the handling of MCPTT session with priority call, see Annex B.13.

Additionally, when the "PrioritySharing" feature is supported, the PCF may receive the "prioSharingInd" attribute within the media component received in the "medComponents" attribute as described in clause 4.2.2.21. In this case, and if "MCPTT-Preemption" feature is supported, the PCF may receive pre-emption information as also described in clause 4.2.3.21.

4.2.3.20 Modification of MCVideo

The NF service consumer may include, in the "ascReqData" attribute, the "mcVideoId" attribute in order to indicate that the modified "Individual Application Session Context" resource relates to the priority adjustment of an MCVideo session. When the PCF receives the "mcVideoId" attribute related to that MCVideo session, the PCF may take specific actions on the corresponding PDU session to ensure that the MCVideo session is prioritized. For the handling of MCVideo session with priority call, see Annex B.15.

4.2.3.21 Priority sharing indication

When the "PrioritySharing" feature is supported, the NF service consumer may include the "prioSharingInd" attribute set to "ENABLED" within a media component of the "medComponents" attribute included in the "ascReqData" attribute to indicate to the PCF that the related media flow is allowed to use the same Allocation and Retention Priority (ARP) as media flows belonging to other "Individual Application Session Context" resources as described in clause 4.2.2.21. In this case, if the "MCPTT-Preemption" feature is supported, the NF service consumer may also include the "preemptCap", "preemptVuln" and "preemptControlInfo" attributes as described in clause 4.2.2.21.

When the "preemptControlInfo" attribute is modified, the latest provided value shall be applied to all potential media flow candidates.

If the NF service consumer earlier has indicated a media flow priority sharing to the PCF by setting the "prioSharingInd" attribute to "ENABLED", the NF service consumer may include the Priority-Sharing-Indicator AVP set to "DISABLED" within a media component of the "medComponents" attribute to indicate to the PCF that the related media flow shall not be part of the mechanism for sharing the Allocation and Retention Priority with other media flows any longer.

If this media flow was in priority sharing with other media flows the PCF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in 3GPP TS 29.512 [8], clause 4.2.6.2.9 and handle the media flow excluded from priority sharing according to normal PCC/QoS rule provisioning procedures described in 3GPP TS 29.512 [8], clause 4.2.6.2.

If the NF service consumer earlier has indicated a media flow priority sharing to the PCF by setting the "prioSharingInd" attribute to "ENABLED" for media flows and the NF service consumer indicates to remove one or more of the media flows in priority sharing with other media flows, the PCF should readjust the Allocation and Retention Priority for the remaining services sharing priority as described in 3GPP TS 29.512 [8], clause 4.2.6.2.9 and handle the media flow removed according to normal PCC/QoS rule provisioning procedures described in 3GPP TS 29.212 [8], clause 4.2.6.2.

4.2.3.22 Modification of Subscription to Out of Credit notification

This procedure is used by the NF service consumer if the "IMS_SBI" feature is supported to modify in the PCF the subscription to notification about credit unavailability for the Service Data Flows within the AF application session context.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

As a result of this action, the PCF shall set the appropriate subscription to out of credit notification for the corresponding PCC Rule(s) as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer with an HTTP response message as described in clause 4.2.3.2.

4.2.3.23 Modification of Subscription to Service Data Flow QoS Monitoring Information

This procedure is used by NF service consumer to modify the PCF subscription for notification about packet delay between UPF and RAN.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

– to create a subscription to notifications of QoS monitoring report:

a) shall include the "events" array with an array that contains a new entry per requested notification method with the "event" attribute set to "QOS_MONITORING", and notification related information as described in clause 4.2.2.23;

b) when the "notifMethod" of the new entry is "EVENT_DETECTION", shall include a "qosMon" attribute with the QoS monitoring information as described in clause 4.2.2.23.

c) shall include the new requested QoS monitoring parameter(s) to be measured (i.e. DL, UL and/or round trip packet delay) within the "reqQosMonParams" attribute;

d) if the feature " ExposureToEAS" is supported, may include the "directNotifInd" attribute set to true to indicate the direct event notification of QoS Monitoring data from the UPF; and

– to remove a subscription to QoS monitoring information:

a) shall include the "events" array containing an array that shall omit the corresponding entry with the "event" attribute value "QOS_MONITORING";

b) when the "notifMethod" attribute of the removed entry is "EVENT_DETECTION", it shall contain the "qosMon" attribute set to null;

c) if the "directNotifInd" attribute was previously provided, it shall contain the "directNotifInd" attribute set to null.

As result of this action, the PCF shall set the appropriate subscription to QoS monitoring information for the corresponding active PCC rule(s) as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.24 Update of TSCAI Input Information and TSC QoS related data

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported, the NF service consumer may update the TSCAI Input container and the TSC QoS related data held in an "Individual Application Session Context" resource using the Npcf_PolicyAuthorization_Update service operation to modify the TSCAI input information and QoS characteristics delivered to the SMF for use in the 5G System.

The NF service consumer shall use the HTTP PATCH method as described in clause 4.2.3.2 to modify TSCAI input container and the TSC QoS related information.

The NF service consumer may indicate TSCAI input information and/or TSC QoS related information for new TSC streams by adding, in the "ascReqData" attribute, one or more media component entries within the "medComponents" attribute including the "tsnQos" attribute and including the "tscaiInputUl" attribute and/or the "tscaiInputDl" attribute and, when the feature "TimeSensitiveCommunication" is supported, the "tscaiTimeDom" attribute, if available as described in clause 4.2.2.24.

The NF service consumer may update the TSCAI input information and/or the TSC QoS related information for existing TSC traffic by including the updated values in the "tscaiInputUl" attribute and/or "tscaiInputDl"attribute and/orupdated values in the "tsnQos" attribute included in a media component entry of the "medComponents" attribute included in the "ascReqData" attribute.

The NF service consumer may delete the TSCAI input information and TSC QoS related information of removed TSC traffic by removing the corresponding media component entries within the "medComponents" attribute included in the "ascReqData" attribute.

Alternatively, when the "TimeSensitiveCommunication" and "AuthorizationWithRequiredQoS" features are supported, the NF service consumer (i.e., the TSCTSF or TSN AF) may update TSC QoS related information updating the "qosReference" attribute, and/or may indicate the update of the alternative service requirements updating the "altSerReqs" attribute as specified in clause 4.2.3.30.

When the "TimeSensitiveCommunication" and "AltSerReqsWithIndQoS" features are supported, the NF service consumer (i.e., the TSCTSF or TSN AF) may update TSC QoS related information updating the individual QoS requirement within the "tsnQos" attribute, and/or may indicate the update of the alternative service requirements updating the "altSerReqsData" attribute as specified in clause 4.2.3.30.

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

The PCF shall check whether the received TSCAI input information and TSC QoS related information require to modify or to remove PCC rules in the SMF. Provisioning of PCC rule(s) to the SMF shall be carried out as specified in 3GPP TS 29.512 [8].

4.2.3.25 Provisioning of TSC user plane node management information and port management information

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported the NF service consumer (i.e., the TSN AF or the TSCTSF) may provide a UMIC for the TSC user plane node functionality of the UPF/NW-TT and/or a PMIC for the DS-TT port and/or PMIC(s) for the NW-TT ports to update the configuration of the 5G system as a TSC user plane node by invoking the Npcf_PolicyAuthorization_Update service operation to the PCF.

The NF service consumer shall use the HTTP PATCH method as described in clause 4.2.3.2 to modify the "Individual Application Session Context" resource holding the UMIC and/or the DS-TT PMIC and/or NW-TT PMIC(s).

The NF service consumer may include in the "ascReqData" attribute:

– the DS-TT PMIC encoded in the "tsnPortManContDstt" and/or the one or more NW-TT PMIC(s)encoded in the "tsnPortManContNwtts", if available; and/or

– the UMIC encoded in the "tsnBridgeManCont", if available.

4.2.3.26 Modification of Mission Critical Services

The NF service consumer may include, in the "ascReqData" attribute, the "mcsId" attribute if it was not previously provided in order to indicate that the modified AF session relates to an MCS session.

If the NF service consumer supports the SBI message priority mechanism for an MCS session, the NF service consumer shall include the "3gpp-Sbi-Message-Priority" custom HTTP header towards the PCF as described in clause 4.2.2.12.

If the PCF receives the "mcsId" attribute, the PCF shall take specific actions on the corresponding PDU session to ensure that the MCS session is prioritised as defined in 3GPP TS 29.512 [8].

4.2.3.27 Support of CHEM feature

When CHEM feature is supported, the NF service consumer may include the value of Maximum Packet Loss Rate for UL within the "maxPacketLossRateUl" attribute and/or the value of Maximum Packet Loss Rate for DL within the "maxPacketLossRateDl" attribute in "medComponents" attribute. For CHEM feature, see Annex B.14.

4.2.3.28 Support of FLUS feature

If the "FLUS" feature is supported by the NF service consumer, the NF service consumer may include the "flusId" attribute within a media component of the "medComponents" attribute to indicate that the related media of the modified Individual Application Session Context resource corresponds to a FLUS media stream. Additional QoS information for the treatment of FLUS media may be provided within "desMaxLatency" attribute and/or "desMaxLoss" attribute.

4.2.3.29 Subscription to EPS Fallback report

When the "EPSFallbackReport" feature is supported, this procedure is used in the NF service consumer to subscribe to the notification of EPS Fallback events, if this event was not previously provisioned.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

The NF service consumer shall include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, the updated values of the "evSubsc" attribute of the "EventsSubscReqDataRm" data type, which shall include in the "events" attribute a new element with the "event" attribute set to "EPS_FALLBACK". The NF service consumer shall request to the PCF to report EPS Fallback in conjunction with providing the PCF with NF service consumer service information for voice media type as described in clause 4.2.3.2, if the event was not previously provisioned as described in clause 4.2.2.30.

As result of this action, the PCF shall set the appropriate subscription to EPS Fallback for the corresponding active PCC rule(s) as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.30 Modification of required QoS information

When the "AuthorizationWithRequiredQoS" feature is supported, this procedure is used by a NF service consumer to modify the required QoS by providing a different QoS reference(s) parameter while the AF session is ongoing. When the "AltSerReqsWithIndQoS" feature is supported, this procedure is used by a NF service consumer to modify the Requested Alternative QoS Parameter set(s).

The NF service consumer shall use the HTTP PATCH method to modify the required QoS information.

When the "AuthorizationWithRequiredQoS" feature is supported, the NF service consumer may include in the HTTP PATCH request message described in clause 4.2.3.2, in the "ascReqData" attribute, within one or more entries of the "medComponents" attribute included in the AppSessionContextUpdateData data type:

– a "qosReference" attribute, which may contain:

i. a QoS reference, that replaces an existing QoS reference value if the "qosReference" attribute was previously provisioned, or creates a new one if no "qosReference" attribute was previously provisioned;

ii. a "null" value, which removes a previously provisioned "qosReference" attribute value.

– an "altSerReqs" attribute, which may contain:

i. a prioritized list of alternative QoS references, which replaces an existing alternative QoS references list if the "altSerReqs" attribute was previously provisioned, or creates a new one if no "altSerReqs" attribute was previously provisioned;

ii. a "null" value, which removes a previously provisioned alternative QoS references list.

When the "AltSerReqsWithIndQoS" feature is supported, and the service QoS is provided, or was previously provided using individual QoS parameters (e.g. "marBwUl" and/or "marBwDl", attributes) instead of a QoS reference, the NF service consumer may include within one or more entries of the "medComponents" attribute:

– an "altSerReqsData" attribute, which may contain:

i. a prioritized list of alternative service requirements that include Requested Alternative QoS Parameter set(s), which replaces an existing list of alternative service requirements that include Requested Alternative QoS Parameter set(s) if the "altSerReqsData" attribute was previously provisioned, or creates a new one if no "altSerReqsData" attribute was previously provisioned;

ii. a "null" value, which removes a previously provisioned list of alternative service requirements that include individual QoS parameter sets.

NOTE: The modification of the individual QoS parameters is performed by provisioning within the "medComponents" attribute an update of the existing values or deleting the previously provided values, as described in clause 4.2.3.2.

When the "DisableUENotification" feature is supported, the NF service consumer may include a "disUeNotif" attribute, which may contain:

i. a "true" value if it was not provided or it was provided and set to "false";

ii. a "false" value if it was provided and set to "true".

When the NF service consumer provides the "altSerReqs" attribute containing a prioritized list of alternative QoS references or "altSerReqsData" attribute containing a prioritized list of alternative service requirements that include individual QoS parameter sets, the NF service consumer shall subscribe to receive notifications from the PCF when the resources associated to the corresponding service information have been allocated as described in clause 4.2.3.10 and when the GBR QoS targets for one or more service data flows can no longer (or can again) be guaranteed, as described in clause 4.2.3.6, if not previously subscribed.

Due to the updated required QoS information, the PCF may need to modify the related PCC rules as specified in 3GPP TS 29.513 [7] and provide the updated information towards the SMF following the corresponding procedures specified in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2.

4.2.3.31 Support of QoSHint feature

If the QoSHint feature is supported by the NF service consumer, the NF service consumer may include the "desMaxLatency" attribute and/or "desMaxLoss" attribute within a media component of the "medComponents" attribute to indicate that the related media of the modified Individual Application Session Context resource has specific latency and/or loss demands.

4.2.3.32 Modification of Subscription to Reallocation of Credit notification

This procedure is used by the NF service consumer if the "IMS_SBI" and the "ReallocationOfCredit" features are supported to modify in the PCF the subscription to notification about reallocation of credit for the Service Data Flows within the AF application session context.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

As a result of this action, the PCF shall set the appropriate subscription to reallocation of credit notification for the corresponding PCC Rule(s) as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer with an HTTP response message as described in clause 4.2.3.2.

4.2.3.33 Modification of Subscription to satellite backhaul category changes

When the feature "SatelliteBackhaul" is supported, this procedure is used in the NF service consumer to modify in the PCF the subscription to notification about satellite backhaul category changes.

The NF service consumer shall use the HTTP PATCH method to update the "Events Subscription" sub-resource together with the modifications to the "Individual Application Session Context" resource.

As result of this action, the PCF shall set the appropriate subscription to satellite backhaul changes for the PDU session as described in 3GPP TS 29.512 [8].

The PCF shall reply to the NF service consumer as described in clause 4.2.3.2. The PCF shall include the "evsNotif" attribute with an entry in the "evNotifs" array with the "event" attribute set to "SAT_CATEGORY_CHG" and the "satBackhaulCategory" attribute including the satellite backhaul category or the indication of non-satellite backhaul if the PCF has previously subscribed with the SMF to changes in this information.