4.2.2 Npcf_PolicyAuthorization_Create service operation

29.5143GPP5G SystemPolicy Authorization ServiceRelease 18Stage 3TS

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

4.2.2.1 General

The Npcf_PolicyAuthorization_Create service operation authorizes the request from the NF service consumer, and optionally communicates with Npcf_SMPolicyControl service to determine and install the policy according to the information provided by the NF service consumer.

The Npcf_PolicyAuthorization_Create service operation creates an application session context in the PCF.

The following procedures using the Npcf_PolicyAuthorization_Create service operation are supported:

– Initial provisioning of service information.

– Gate control.

– Initial Background Data Transfer policy indication.

– Initial provisioning of sponsored connectivity information.

– Subscription to Service Data Flow QoS notification control.

– Subscription to Service Data Flow Deactivation.

– Initial provisioning of traffic routing information.

– Subscription to resources allocation outcome.

– Invocation of Multimedia Priority Services.

– Support of content versioning.

– Request of access network information.

– Initial provisioning of service information status.

– Provisioning of signalling flow information.

– Support of resource sharing.

– Indication of Emergency traffic.

– Invocation of MCPTT.

– Invocation of MCVideo.

– Priority sharing indication.

– Subscription to out of credit notification.

– Subscription to Service Data Flow QoS Monitoring information.

– Provisioning of TSCAI input information and TSC QoS related data.

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

– P-CSCF restoration enhancements.

– Support of CHEM feature.

– Support of FLUS feature.

– Subscription to EPS Fallback report.

– Subscription to TSC user plane node related events.

– Initial provisioning of required QoS information.

– Support of QoSHint feature.

– Subscription to reallocation of credit notification.

– Subscription to satellite backhaul category changes.

4.2.2.2 Initial provisioning of service information

This procedure is used to set up an AF application session context for the service as defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4].

Figure 4.2.2.2-1 illustrates the initial provisioning of service information.

Figure 4.2.2.2-1: Initial provisioning of service information

When a new AF application session context is being established and media information for this application session context is available at the NF service consumer and the related media requires PCC control, the NF service consumer shall invoke the Npcf_PolicyAuthorization_Create service operation by sending the HTTP POST request to the resource URI representing the "Application Sessions" collection resource of the PCF, as shown in figure 4.2.2.2-1, step 1.

The NF service consumer shall include in the "AppSessionContext" data type in the payload body of the HTTP POST request a partial representation of the "Individual Application Session Context" resource by providing the "AppSessionContextReqData" data type. The "Individual Application Session Context" resource and the "Events Subscription" sub-resource are created as described below.

The NF service consumer shall provide in the body of the HTTP POST request:

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

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

For Ethernet type PDU sessions, if the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported, the "ueMac" attribute containing the MAC address of the DS-TT port as received from the PCF during the reporting of TSC user plane node information as defined in clause 4.2.5.16.

NOTE 1: The determination of the DS-TT port MAC address is specified in clause 5.28.2 of 3GPP TS 23.501 [2]. The DS-TT port MAC address is used as identifier of the PDU session related to the reported TSC user plane node information.

For IP type PDU sessions, if the "TimeSensitiveCommunication" feature is supported, the "ueIpv4" or "ueIpv6" attribute containing the IPv4 or IPv6 address of the UE as received from the PCF during the reporting of user plane node information as defined in clause 4.2.5.16.

NOTE 2: The IP address of the PDU session is used as identifier of the PDU session related to the reported TSC user plane node information.

The NF service consumer shall provide the corresponding service information in the "medComponents" attribute if available. The AF shall indicate to the PCF as part of the "medComponents" attribute whether the service data flow(s) (IP or Ethernet) should be enabled or disabled with the "fStatus" attribute.

If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported, the AF may provide within the MediaComponent data structure required QoS information as specified in clause 4.2.2.32.

The AF may include the AF application identifier in the "afAppId" attribute into the body of the HTTP POST request in order to indicate the particular service that the AF session belongs to.

The AF application identifier may be provided at both "AppSessionContextReqData" data type level, and "MediaComponent" data type level. When provided at both levels, the AF application identifier provided at "MediaComponent" data type level shall have precedence.

The AF application identifier at the "AppSessionContextReqData" data type level may be used 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 "IMS_SBI" feature is supported, the NF service consumer may include the AF charging identifier in the "afChargId" attribute for charging correlation purposes.

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported the NF service consumer may provide TSC information as specified in clauses 4.2.2.24 and 4.2.2.25.

The NF service consumer may also include the "evSubsc" attribute of "EventsSubscReqData" data type to request the notification of certain user plane events. The NF service consumer shall include the events to subscribe to in the "events" attribute, and the notification URI where to address the Npcf_PolicyAuthorization_Notify service operation in the "notifUri" attribute. The events subscription is provisioned in the "Events Subscription" sub-resource.

The AF shall also include the "notifUri" attribute in the "AppSessionContextReqData" data type to indicate the URI where the PCF can request to the AF the deletion of the "Individual Application Session Context" resource.

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

Otherwise, when the PCF receives the HTTP POST request from the NF service consumer, the PCF shall apply session binding as described in 3GPP TS 29.513 [7]. To allow the PCF to identify the PDU session for which the HTTP POST request applies, the NF service consumer shall provide in the body of the HTTP POST request:

– for IP type PDU session, either the "ueIpv4" attribute or "ueIpv6" attribute containing the IPv4 or the IPv6 address applicable to an IP flow or IP flows towards the UE; and

– for Ethernet type PDU session, the "ueMac" attribute containing the UE MAC address applicable to an Ethernet flow or Ethernet flows towards the UE.

The NF service consumer may provide DNN in the "dnn" attribute, SUPI in the "supi" attribute, GPSI in the "gpsi" attribute, the S-NSSAI in the "sliceInfo" attribute if available for session binding. The NF service consumer may also provide the domain identity in the "ipDomain" attribute.

NOTE 3: The "ipDomain" attribute is helpful in the following scenario: Within a network slice, there are several separate IP address domains, with SMF/UPF(s) that allocate Ipv4 IP addresses out of the same private address range to UE PDU sessions. The same IP address can thus be allocated to UE PDU sessions served by SMF/UPF(s) in different address domains. If one PCF controls several SMF/UPF(s) in different IP address domains, the UE IP address is thus not sufficient for the session binding. A NF service consumer can serve UEs in different IP address domains, either by having direct IP interfaces to those domains, or by having interconnections via NATs in the user plane between the UPF and the NF service consumer. If a NAT is used, the NF service consumer obtains the IP address allocated to the UE PDU session via application level signalling and supplies it for the session binding to the PCF in the "ueIpv4" attribute. The NF service consumer supplies an "ipDomain" attribute denoting the IP address domain behind the NAT in addition. The NF service consumer can derive the appropriate value from the source address (allocated by the NAT) of incoming user plane packets. The value provided in the "ipDomain" attribute is operator configurable.

NOTE 4: The "sliceInfo" attribute is helpful in the scenario where multiple network slices are deployed in the same DNN, and the same IPv4 address may be allocated to UE PDU sessions in different network slices. If one PCF controls several network slices, the UE IP address is not sufficient for the session binding. The NF service consumer supplies "sliceInfo" attribute denoting the network slice that allocated the IPv4 address of the UE PDU session. How the NF service consumer derives S-NSSAI is out of the scope of this specification.

NOTE 5: When the scenario described in NOTE 3 applies and the NF service consumer is a P-CSCF it is assumed that the P-CSCF has direct IP interfaces to the different IP address domains and that no NAT is located between the UPF and P-CSCF. How a non-IMS NF service consumer obtains the UE private IP address to be provided to the PCF is out of scope of the present release; it is unspecified how to support applications that use a protocol that does not retain the original UE’s private IP address.

If the PCF fails in executing session binding, the PCF shall reject the Npcf_PolicyAuthorization_Create service operation with an HTTP "500 Internal Server Error" response including the "cause" attribute set to "PDU_SESSION_NOT_AVAILABLE".

If the request contains the "medComponents" attribute the PCF shall store the received service information. The PCF shall process the received service information according to the operator policy and may decide whether the request is accepted or not. The PCF may take the priority information within the "resPrio" attribute into account when making this decision.

If the service information provided in the body of the HTTP POST request is rejected (e.g. the subscribed guaranteed bandwidth for a particular user is exceeded or the authorized data rate in that slice for a UE is exceeded), 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".

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_Create 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 POST 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 6: 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 for any of those cases in a slice is exceeded due to the bandwidth demands of the new 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.

To allow the PCF and SMF/UPF to perform PCC rule authorization and QoS flow binding for the described service data flows, the NF service consumer shall supply:

– for IP type PDU session, both source and destination IP addresses and port numbers in the "fDescs" attribute within the "medSubComps" attribute, if such information is available; and

– for Ethernet type PDU session, the Ethernet Packet filters in the "ethfDescs" attribute within the "medSubComps" attribute, if such information is available.

The NF service consumer may specify the ToS traffic class (i.e. ToS (IPv4) or TC (IPv6) value) within the "tosTrCl" attribute for the described service data flows together with the "fDescs" attribute.

NOTE 7: A ToS/TC value can be useful when another packet filter attribute is needed to differentiate between packet flows. For example, packet flows encapsulated and encrypted by a tunnelling protocol can be differentiated by the ToS/TC value of the outer header if appropriately set by the application. To use ToS/TC for service data flow detection, network configuration needs to ensure there is no ToS/TC re-marking applied along the path from the application to the PSA UPF and the specific ToS/TC values are managed properly to avoid potential collision with other usage (e.g., paging policy differentiation).

The NF service consumer may include the "resPrio" attribute at the "AppSessionContextReqData" data type level to assign a priority to the AF Session as well as include the "resPrio" attribute at the "MediaComponent" data type level to assign a priority to the service data flow. The presence of the "resPrio" attribute in both levels does not constitute a conflict as they each represent different types of priority. The reservation priority at the "AppSessionContextReqData" data type level provides the relative priority for an AF session while the reservation priority at the "MediaComponent" data type level provides the relative priority for a service data flow within a session. If the "resPrio" attribute is not specified, the requested priority is PRIO_1.

The PCF shall check whether the received service information requires PCC rules to be created and provisioned 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].

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

If the PCF created an "Individual Application Session Context" resource, the PCF shall send to the NF service consumer a "201 Created" response to the HTTP POST request, as shown in figure 4.2.2.2-1, step 2. The PCF shall include in the "201 Created" response:

– a Location header field; and

– an "AppSessionContext" data type in the payload body.

The Location header field shall contain the URI of the created individual application session context resource i.e. "{apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}".

When "Events Subscription" sub-resource is created in this procedure, the NF service consumer shall build the sub-resource URI by adding the path segment "/events-subscription" at the end of the URI path received in the Location header field.

The "AppSessionContext" data type payload body shall contain the representation of the created "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 event "PLMN_CHG" in the HTTP POST 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 8: The SNPN Identifier consists of the PLMN Identifier and the NID.

NOTE 9: 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" in the HTTP POST 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 10: 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 POST 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_Create 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_Create request is described in clause 4.2.5.

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

NOTE 11: The behaviour when the NF service consumer does not receive the HTTP response message, or when it arrives after the internal timer waiting for it has expired, or when it arrives with an indication different than a success indication, are outside the scope of this specification and based on operator policy.

4.2.2.3 Gate control

This procedure is used by an NF service consumer to instruct the PCF about when the service data flow(s) are to be enabled or disabled for a PDU session.

The AF shall include in the HTTP POST request message described in subclause 4.2.2.2 the "fStatus" attribute for the flows to be enabled or disabled within the "medComponents" or "medSubComps" attributes.

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.2.2.

4.2.2.4 Initial Background Data Transfer policy indication

This procedure is used by a NF service consumer to indicate 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 POST request message described in clause 4.2.2.2 a reference identifier related to a transfer policy negotiated for background data transfer 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.2.2.

4.2.2.5 Initial provisioning of sponsored connectivity information

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

The NF service consumer shall provide in the "AppSessionContext" data type of the HTTP POST request message described in clause 4.2.2.2 an application service provider identity and a sponsor identity within the "aspId" attribute and "sponId" attribute within the "ascReqData" attribute. Additionally, the NF service consumer may provide an indication to the PCF of sponsored data connectivity not enabled by including the "sponStatus" attribute set to "SPONSOR_DISABLED".

To support the usage monitoring of sponsored data connectivity, the NF service consumer may subscribe with the PCF to the notification of usage threshold reached. The NF service consumer shall include:

– an entry of the "AfEventSubscription" data type in the "events" attribute with the "event" attribute set to "USAGE_REPORT"; and

– the "usgThres" attribute of "UsageThreshold" data type in the "EventsSubscReqData" data type with:

a) the total volume in the "totalVolume" attribute; or

b) the uplink volume only in the "uplinkVolume" attribute; or

c) the downlink volume only in the "downlinkVolume"; and/or

d) the time in the "duration" attribute.

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

When the NF service consumer indicated to enable sponsored data connectivity, and the UE is roaming in a VPLMN, the following procedures apply:

– If the NF service consumer is located in the HPLMN, for home routed roaming case and when the 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 non-roaming 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.2.2.

4.2.2.6 Subscriptions to Service Data Flow QoS notification control

The subscription to Service Data Flow QoS notification control is used by a NF service consumer to subscribe to receive a notification when the GBR QoS targets for one or more service data flows can no longer (or can again) be guaranteed.

NOTE: It may happen that the GBR QoS targets for one or more PCC rules (i.e. Service Data Flows) cannot be guaranteed, either permanently or temporarily in the radio access network.

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

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

4.2.2.7 Subscription to Service Data Flow Deactivation

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

NOTE: It may happen that one or more PCC rules (i.e. Service Data Flows) are deactivated at the SMF at certain time, either permanently or temporarily, due to e.g. release of resources or out of credit condition.

The PCF shall reply to the NF service consumer as described in clause 4.2.2.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.2.8 Initial provisioning of traffic routing information

This procedure is used by a NF service consumer to:

– influence SMF traffic routing decisions to a local access to a Data Network identified by a DNAI; and/or

– request subscriptions to notifications about UP path management events related to the PDU session,

when "InfluenceOnTrafficRouting" feature is supported.

NOTE 1: The NF service consumer uses the Npcf_PolicyAuthorization service for requests targeting specific on-going PDU sessions of individual UE(s). The NF service consumer requests that target existing or future PDU Sessions of multiple UE(s) or any UE are sent via the NEF and may target multiple PCF(s), as described in 3GPP TS 29.513 [7].

The NF service consumer shall include in the HTTP POST request message described in clause 4.2.2.2 the "afRoutReq" attribute of "AfRoutingRequirement" data type with specific routing requirements for the application traffic flows either within "AppSessionContextReqData" data type for the service indicated in the "afAppId" attribute, or within the "medComponents" attribute. When provided at both levels, the "afRoutReq" attribute value in the "medComponents" attribute shall have precedence over the "afRoutReq" attribute included in the "AppSessionContextReqData" data type.

The NF service consumer may include traffic routing requirements together with service information.

The NF service consumer may request to influence SMF traffic routing decisions to a DNAI. The NF service consumer shall include in the "afRoutReq" attribute:

a) A list of routes to locations of applications in the "routeToLocs" attribute. Each element of the list shall contain:

– a DNAI in the "dnai" attribute to indicate the location of the application towards which the traffic routing is applied; and

– a routing profile identifier in the "routeProfId" attribute, and/or the explicit routing information in the "routeInfo" attribute.

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

a) Indication of application relocation possibility in the "appReloc" attribute.

b) Temporal validity during which the NF service consumer request is valid shall be indicated with the "startTime" and "stopTime" attributes.

c) Spatial validity during which the NF service consumer request is valid shall be indicated in terms of validity areas encoded in the "spVal" attribute of "SpatialValidity" data type. The "SpatialValidity" data type consists of a list of presence areas included in the "presenceInfoList" attribute, where each element shall include the presence reporting area identifier in the "praId" attribute and may include the elements composing a presence area encoded in the attributes: "trackingAreaList", "ecgList", "ncgList", "globalRanNodeIdList".

d) Indication of UE IP address preservation in the "addrPreserInd" attribute if the URLLC feature is supported.

e) If the SimultConnectivity feature is supported:

– indication of simultaneous connectivity temporarily maintained in the source and target PSA during the edge re-location procedure in the "simConnInd" attribute; and

– if the "simConnInd" attribute is set to true, the minimum time interval to be considered for inactivity of the traffic routed via the source PSA in the "simConnTerm" attribute.

f) EAS IP replacement information in the "easIpReplaceInfos" attribute if the EASIPreplacement feature is supported.

g) Indication of EAS rediscovery in the "easRedisInd" attribute if the EASDiscovery feature is supported.

h) Maximum allowed user plane latency in the "maxAllowedUpLat" attribute if the AF_latency feature is supported.

NOTE 2: The EAS IP Replacement information and the information indicating the EAS rediscovery are not provided simultaneously.

The NF service consumer may also subscribe to notifications about UP path management events. The NF service consumer shall include in the "upPathChgSub" attribute:

– notifications of early and/or late DNAI change, using the attribute "dnaiChgType" indicating whether the subscription is for "EARLY", "LATE" or "EARLY_LATE";

– the notification URI where the NF service consumer is receiving the Nsmf_EventExposure_Notify service operation in the "notificationUri" attribute; and

– the notification correlation identifier assigned by the NF service consumer in the "notifCorreId" attribute.

If the URLLC feature is supported, the NF service consumer may include an indication of NF service consumer acknowledgement to be expected as an "afAckInd" attribute within the "upPathChgSub" attribute.

When the feature "RoutingReqOutcome" is supported:

– 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 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.

NOTE 3: 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.2.2.

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

The PCF shall check whether the received routing requirements requires PCC rules to be created or provisioned to include or modify traffic steering policies and 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 in 3GPP TS 29.512 [8].

NOTE 4: The NF service consumer receives the notification about UP path management events by the Nsmf_EventExposure_Notify service operation as defined in clause 4.2.2.2 of 3GPP TS 29.508 [13].

4.2.2.9 Void

4.2.2.10 Subscription to resources allocation outcome

This procedure is used by a NF service consumer to subscribe to notifications when the resources associated to the corresponding service information have been allocated and/or cannot be allocated.

The NF service consumer shall use the "EventsSubscReqData" data type as described in clause 4.2.2.2 and shall include in the HTTP POST request message:

– if the NF service consumer requests the PCF to provide a notification when the resources associated to the service information have been allocated, an event entry within the "events" attribute with the "event" attribute set to "SUCCESSFUL_RESOURCES_ALLOCATION";

– if the NF service consumer requests the PCF to provide a notification when the resources associated to the service information cannot be allocated, an event entry within the "events" attribute with the "event" attribute set to "FAILED_RESOURCES_ALLOCATION"; and/or

– if the feature "UEUnreachable" is supported and the NF service consumer request the PCF to provide a notification when the resources associated to the service information are not allocated because the UE is unreachable, an event entry within the "events" attribute with the "event" attribute set to "UE_TEMPORARILY_UNAVAILABLE".

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

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

4.2.2.11 Void

4.2.2.12 Invocation of Multimedia Priority Services

4.2.2.12.1 General

This procedure allows a NF service consumer, as per 3GPP TS 22.153 [23], to request prioritized access to system resources in situations such as during congestion.

The NF service consumer may include the "mpsId" attribute to indicate that the new AF session relates to an MPS session.

The "mpsId" attribute shall contain the national variant for the MPS service name indicating an MPS session. The "resPrio" attribute shall include the priority value of the related priority service.

If the NF service consumer supports the SBI Message Priority mechanism for an MPS session, it shall include the "3gpp-Sbi-Message-Priority" custom HTTP header towards the PCF as described in clause 6.8.2 of 3GPP TS 29.500 [5].

NOTE 1: If the NF service consumer supports the SBI Message Priority mechanism for an MPS session, the NF service consumer will include the "3gpp-Sbi-Message-Priority" custom HTTP header with a priority value equivalent to the value of the "resPrio" attribute. Highest user priority value is mapped in the corresponding lowest value of the "3gpp-Sbi-Message-Priority" custom HTTP header.

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

NOTE 2: 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.

4.2.2.12.2 MPS for DTS

MPS for DTS is the means for an NF service consumer to invoke/revoke the Priority PDU connectivity service for the default QoS flow only, i.e. without designating a particular service data flow for priority service. MPS for DTS applies only to non-IMS DNNs.

When the "MPSforDTS" feature is supported, to invoke MPS for DTS, the NF service consumer includes the "mpsAction" attribute, set to "ENABLE_MPS_FOR_DTS" or "AUTHORIZE_AND_ENABLE_MPS_FOR_DTS". These "mpsAction" attribute values signal a QoS change to the default QoS flow and service data flows mapped to the default QoS flow without the creation of a new QoS flow.

When the "ENABLE_MPS_FOR_DTS" value is received, and allowed by local policy, the PCF does not check the user’s MPS subscription details. When the "AUTHORIZE_AND_ENABLE_MPS_FOR_DTS" value is received, 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".

NOTE: How the NF service consumer checks the MPS for DTS authorization is out of scope of the present document.

When creating an Individual Application Session Context resource, due to the invocation or revocation of MPS for DTS, the NF service consumer may subscribe to the outcome of the default QoS updates by setting within the "evSubsc" attribute an event in 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 to be successful.

The NF service consumer may use the procedure specified in clause 4.2.2.12.3 to open a new priority PDU session related to the AF signalling IP flow between the UE and NF service consumer.

4.2.2.12.3 Provisioning of MPS for DTS signalling flow information

This clause is applicable to provisioning of signalling flow information for MPS for DTS if the MPSforDTS feature is supported as described in clause 5.8.

This procedure allows NF service consumer to provision information about the AF signalling IP flows between the UE and the NF service consumer.

The NF service consumer shall provide:

– the IP address (IPv4 or IPv6) of the UE in the "ueIpv4" or "ueIpv6" attribute;

– the "mpsId" attribute; and

– a media component within the "medComponents" attribute including:

– the "medCompN" attribute set to "0"; and

– the media subcomponent within the "medSubComps" attribute representing the AF signalling IP flow, where the media subcomponent shall contain:

– the "flowUsage" attribute set to the value "AF_SIGNALLING";

– the "fDesc" attribute containing the IP flows of the AF signalling flow; and

– the "fStatus" set to the value "ENABLED".

The PCF shall determine whether the request is accepted or not. If accepted, the PCF shall perform session binding and shall reply to the NF service consumer as described in clause 4.2.2.2. If rejected, 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".

The PCF shall set appropriate QoS values for the AF signalling IP flow and shall install the corresponding dynamic PCC rule for the AF signalling IP flows.

The NF service consumer may de-provision the information about the AF signalling IP flows at any time. To do that, if the "Individual Application Session Context" resource is only used to provide information about the AF Signalling IP flows, the NF service consumer shall remove the resource by sending an Npcf_PolicyAuthorization_Delete service operation towards the PCF as defined in clause 4.2.4.2. Otherwise, the NF service consumer shall remove the IP flow within the media component invoking the Npcf_PolicyAuthorization_Update service operation as defined in clause 4.2.3.17.

NOTE: Combining the request for the AF signalling flow with an MPS for DTS invocation/revocation request is not supported in this release.

4.2.2.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.

If required by operator policies, the NF service consumer shall assign a content version to the media component related to certain service and shall provide assigned content version to the PCF in the "contVer" attribute included in the corresponding media component entry of the "medComponents" attribute.

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.2.14 Request of access network information

This procedure is used by a NF service consumer to request the PCF to report the access network information (i.e. user location and/or user timezone information) at the creation of the "Individual Application Session Context" resource, when the "NetLoc" feature is supported.

The NF service consumer shall include in the HTTP POST request message described in clause 4.2.2.2:

– 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.2.2.

4.2.2.15 Initial provisioning of service information status

When the "IMS_SBI" feature is supported, the NF service consumer may provide 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 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.2.16 Provisioning of signalling flow information

This clause is applicable when IMS restoration is supported according to the supported feature "ProvAFsignalFlow" as described in clause 5.8.

This procedure allows NF service consumer to provision information about the AF signalling IP flows between the UE and the NF service consumer.

The NF service consumer shall provide:

– the IP address (IPv4 or IPv6) of the UE in the "ueIPv4" or "ueIPv6" attribute; and

– a media component within the "medComponents" attribute including:

– the "medCompN" attribute set to "0"; and

– one or more media subcomponents within the "medSubComps" attribute representing the AF signalling IP flows, where each media subcomponent shall contain:

– the "flowUsage" attribute set to the value "AF_SIGNALLING";

– the "fNum" attribute set according to the rules described in Annex C;

– the "fDesc" attribute containing the IP flows of the AF signalling flow;

– the "fStatus" set to the value "ENABLED"; and

– the "afSigProtocol" set to the value corresponding to the signalling protocol used between the UE and the NF service consumer.

The PCF shall perform session binding and shall reply to the NF service consumer as described in clause 4.2.2.2.

PCC rules related to the AF signalling IP flows could have been provisioned to SMF using the corresponding procedures specified in 3GPP TS 29.512 [8] at an earlier stage (e.g. typically at the establishment of the QoS flow for AF Signalling IP Flows). The PCF shall install the corresponding dynamic PCC rule for the AF signalling IP flows.

The NF service consumer may de-provision the information about the AF signalling IP flows at any time. To do that, if the "Individual Application Session Context" resource is only used to provide information about the AF Signalling IP flows, the NF service consumer shall remove the resource by sending an Npcf_PolicyAuthorization_Delete service operation as service operation towards the PCF as defined in clause 4.2.4.2. Otherwise, the NF service consumer shall remove the IP flows within the media component invoking the Npcf_PolicyAuthorization_Update service operation as defined in clause 4.2.3.17.

4.2.2.17 Support of resource sharing

This procedure is used by a NF service consumer to indicate that a media component of an Individual Application Session Context resource may share resources with other media components in the related direction in other Individual Application Session Context resources when the "ResourceSharing" feature is supported.

The NF service consumer may include the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute within a media component of the "medComponents" attribute to indicate that the related media of the created new Individual Application Session Context resource may share resources with other media components in the related direction that include the same value for the "sharingKeyUl" attribute and/or "sharingKeyDl" attribute.

The PCF shall reply to the NF service consumer with an HTTP response message as described in clause 4.2.2.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.2.18 Indication of Emergency traffic

When the "IMS_SBI" feature is supported, this procedure allows a NF service consumer to indicate that the new AF session context relates to emergency traffic.

The NF service consumer may include the "servUrn" attribute to indicate that the new AF session context relates to emergency traffic. Additionally, the NF service consumer may include the "afReqData" attribute to indicate the additional information requested for the AF session context.

When the PCF receives the "servUrn" attribute indicating an emergency session, the PCF may apply special policies, for instance prioritising service flows relating to the new AF session context, allowing these service flows free of charge or exempting the service flows from the limitation of data rate per network slice 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]).

If the "servUrn" attribute indicates that the new NF service consumer session context relates to emergency traffic and the "afReqData" attribute is received, the PCF shall reply to the NF service consumer as described in clause 4.2.2.2 and shall provide the requested available user information in the "ueIds" attribute included within the "ascRespData" attribute in the HTTP "201 Created" response.

NOTE 1: The "supi" attribute within the "ueIds" attribute contains an IMSI, if available, when the UE accesses a PLMN and contains either an IMSI or a network-specific identifier that takes the form of an NAI, if available, when the UE accesses a SNPN. For both, PLMN access and SNPN access, the "gpsi" attribute within the "ueIds" attribute contains an MSISDN, if available, and the "pei" attribute contains an IMEI(SV).

If the NF service consumer supports the SBI Message Priority mechanism for an emergency session, it shall include the "3gpp‑Sbi‑Message‑Priority" custom HTTP header towards the PCF as described in clause 6.8.2 of 3GPP TS 29.500 [5].

NOTE 2: If the NF service consumer supports the SBI Message Priority mechanism for an emergency session, the NF service consumer includes the "3gpp-Sbi-Message-Priority" custom HTTP header based on NF service consumer policies in relation to valid values of the "servUrn" attribute. The highest user priority value is mapped to the corresponding lowest value of the "3gpp-Sbi-Message-Priority" custom HTTP header.

When the new AF session context does not indicate emergency traffic and the session binding function detects that the binding is to a PDU session established to the Emergency DNN, the PCF shall reject the HTTP POST request and shall indicate in an HTTP "403 Forbidden" response message the cause for the rejection including the "cause" attribute set to "UNAUTHORIZED_NON_EMERGENCY_SESSION".

4.2.2.19 Invocation of MCPTT

When the feature "MCPTT" is supported by the NF service consumer and the PCF, this procedure allows a NF service consumer to request prioritized access to system resources in situations such as an MCPTT session with priority call.

The NF service consumer may include the "mcpttId" attribute to indicate that the new "Individual Application Session Context" resource relates to an MCPTT session with priority call.

When the PCF receives the "mcpttId" attribute indicating an MCPTT session and the "resPrio" attribute, the PCF shall take specific actions on the corresponding PDU session to ensure that the MCPTT session is prioritized as specified 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.

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.2.21.

For the handling of MCPTT session with priority call, see Annex B.13

4.2.2.20 Invocation of MCVideo

When the feature "MCVideo" is supported by the NF service consumer and the PCF, this procedure allows a NF service consumer to request prioritized access to system resources in situations such as an MCVideo session with priority call.

The NF service consumer may include the "mcVideoId" attribute to indicate that the new "Individual Application Session Context" resource relates to an MCVideo session with priority call.

When the PCF receives the "mcVideoId" attribute indicating an MCVideo session and the "resPrio" attribute, the PCF shall take specific actions on the corresponding PDU session to ensure that the MCVideo session is prioritized as specified in 3GPP TS 29.512 [8].

For the handling of MCVideo session with priority call, see Annex B.15.

4.2.2.21 Priority sharing indication

When the "PrioritySharing" feature is supported, the NF service consumer may 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.

The NF service consumer may include the "prioSharingInd" attribute set to "ENABLED" within a media component of the "medComponents" attribute to indicate to the PCF that the related media flow is allowed to use the same Allocation and Retention Priority as media flows which:

– are assigned the same 5QI in the PCF; and

– belong to other "Individual Application Session Context" resources bound to the same PDU session that also contain the "prioSharingInd" attribute set to "ENABLED".

If the "MCPTT-Preemption" feature is supported, the NF service consumer may also include:

– within a media component of the "medComponents" attribute, the "preemptCap" attribute containing the suggested pre-emption capability value and the "preemptVuln" attribute containing the suggested pre-emption vulnerability value, for the PCF to determine ARP values;

– within the "ascReqData" attribute in the request body, the "preemptControlInfo" attribute containing the pre-emption control information for the PCF to perform pre-emption control as described in 3GPP TS 29.512 [8], clause 4.2.6.2.9; and

– within the "evSubsc" attribute, the "event" attribute set to "FAILED_RESOURCES_ALLOCATION" to request the notification for resource allocation failure.

Upon reception of this information, the PCF shall behave as described in 3GPP TS 29.512 [8], clause 4.2.6.2.9. For the handling of MCPTT sessions, see Annex B.10.

NOTE 1: Service data flow deactivation procedures will apply according to clauses 4.2.2.7, 4.2.3.7, 4.2.5.5.

NOTE 2: This enhancement avoids the risk that a QoS flow establishment request is rejected if the maximum number of active QoS flows is exceeded.

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

4.2.2.22 Subscription to Out of Credit notification

This procedure is used by the NF service consumer if the "IMS_SBI" feature is supported to subscribe to notifications of credit not available for the Service Data Flows within the AF application session context.

NOTE: It can happen that there are one or more PCC rules (i.e. Service Data Flows) with credit not available, each one with their corresponding termination action (terminate, redirect, access restricted).

The NF service consumer shall use the "EventsSubscReqData" data type as described in clause 4.2.2.2 and shall include in the HTTP POST request message an event within the "evSubsc" attribute with the "event" attribute set to the value "OUT_OF_CREDIT".

As 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.2.2.

4.2.2.23 Subscriptions to Service Data Flow QoS Monitoring Information

The subscription to Service Data Flow QoS monitoring information is used by a NF service consumer to receive a notification about the packet delay between UPF and RAN.

The NF service consumer shall use the "EventsSubscReqData" data type as described in clause 4.2.2.2 and shall include:

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

– an entry of the "AfEventSubscription" data type per requested notification method in the "events" attribute with:

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

b) the "notifMethod" attribute set to the value "EVENT_DETECTION", "PERIODIC" or "PDU_SESSION_RELEASE"; and

c) when the "notifMethod" attribute is set to the value "PERIODIC", the reporting period within the "repPeriod" attribute; and

d) when the "notifMethod" attribute is set to the value "EVENT_DETECTION", the minimum waiting time between subsequent reports within the "waitTime" attribute.

– when the "notifMethod" attribute set to the value "EVENT_DETECTION", the "qosMon" attribute, with the required Qos Monitoring information, i.e.:

a) the delay threshold for downlink with the "repThreshDl" attribute;

b) the delay threshold for uplink with the "repThreshUl" attribute; and/or

c) the delay threshold for round trip with the "repThreshRp" attribute.

The NF service consumer may include in "EventsSubscReqData" data type the notification correlation identifier assigned by the AF within the "notifCorreId" attribute and, if the feature "ExposureToEAS" is supported, the "directNotifInd" attribute set to true to indicate direct event notification of QoS Monitoring data from the UPF.

The NF service consumer shall include more than one "AfEventSubscription" data type within the "EventsSubscReqData" data type if more than one notification method is required.

The PCF shall reply to the AF as described in clause 4.2.2.2.

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

4.2.2.24 Provisioning of TSCAI input Information and QoS related data

If the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported the NF service consumer (i.e. TSN AF or TSCTSF) may provide TSCAI input information within the TSC assistance container and QoS related data to the PCF by the Npcf_PolicyAuthorization_Create service operation to describe the TSC traffic pattern and QoS characteristics for use in the 5G System.

The NF service consumer (i.e. TSN AF or TSCTSF) shall derive the TSCAI input information and the QoS related data for a given TSC stream or flow of aggregated TSC streams. The TSCTSF may determine the TSCAI input information and the related QoS data based on information provided by an AF/NEF, and may provide it for IP type and Ethernet type of PDU sessions as specified in clauses 4.15.6.6 and 4.15.6.6a of TS 23.502 [3]. In case of integration with IEEE TSN network, the TSN AF determines the TSCAI input information as defined in clause 5.27.2.2 of 3GPP TS 23.501 [2] and the QoS related data as defined in clause 5.28.4 of 3GPP TS 23.501 [2].

To indicate the TSCAI input information of a TSC stream or aggregated set of TSC streams, the NF service consumer (i.e. TSN AF or TSCTSF) may include for the uplink flow direction (ingress interface of the DS-TT/UE) in the "tscaiInputUl" attribute and/or for the downlink flow direction (ingress interface of the NW-TT) the "tscaiInputDl" attribute included in a media component entry of the "medComponents" attribute:

– the time period between the start of two bursts of a TSC stream or aggregated TSC streams in reference to the external GM encoded in the "periodicity" attribute;

– the arrival time of the first data burst of a TSC stream or aggregated TSC streams in reference to the external GM encoded in the "burstArrivalTime" attribute; and

– if the "TimeSensitiveCommunication" feature is supported, the time period an application can survive without any burst, i.e., the survival time, in terms of maximum number of messages encoded in the "surTimeInNumMsg" attribute or in time units encoded in the "surTimeInTime" attribute.

NOTE: A single burst (message is equivalent to burst) is expected within a single periodicity. The survival time in terms of maximum number of messages represents the time period result of multiplying the periodicy by the indicated number of messages.

The uplink and/or downlink flow of the TSC stream or aggregated set of TSC streams shall be encoded within the corresponding "MediaSubComponent" entries of the "medSubComps" attribute, for PDU sessions of Ethernet type in the "ethfDescs" attribute and for PDU sessions of IP type in the "fDescs" attribute.

When the feature "TimeSensitiveCommunication" is supported, to indicate the time domain the NF service consumer is located in (i.e. the (g)PTP domain), the NF service consumer may include the "tscaiTimeDom" attribute in the corresponding media component entry of the "medComponents" attribute.

To indicate the TSC QoS related data of a TSC stream or aggregated set of TSC streams, the NF service consumer (i.e. TSN AF or TSCTSF) may include in the "tsnQos" attribute included in a media component entry of the "medComponents" attribute;

– the maximum burst size encoded in the "maxTscBurstSize" attribute;

– the maximum time a packet may be delayed encoded in the "tscPackDelay" attribute;

– the TSC traffic priority in scheduling resources among other TSC streams encoded in the "tscPrioLevel" attribute.

The NF service consumer (i.e. TSN AF or TSCTSF) may also include the max bitrates in uplink and downlink within the "marBwUl" attribute and the "marBwDl" attribute of the "medComponents" attribute respectively. In case of integration with IEEE TSN network, the TSN AF determines the maximum flow bit rate as defined in Annex I of 3GPP TS 23.501 [2]. In case of integration with a TSC network other than IEEE TSN network, the TSCTSF may additionally include the "mirBwUl" attribute and the "mirBwDl" attribute of the "medComponents" attribute to indicate the requested guaranteed bit rates in uplink and downlink respectively.

When the feature "TimeSensitiveCommunication" is supported, and the feature "AuthorizationWithRequiredQoS" is supported as specified in clause 4.2.2.32, the NF service consumer (i.e. TSCTSF or TSN AF) may provide within an entry of the "medComponents" attribute a reference to pre-defined QoS information within the "qosReference" attribute instead of providing the attributes "tsnQos", "marBwUl", "marBwDl", "mirBwUl", and/or "mirBwDl". Additionally, if the NF service consumer supports adjustments to different QoS parameter combinations, the NF service consumer may provide a prioritized list of one or more QoS references within the "altSerReqs" attribute as specified in clause 4.2.2.32.

When the feature "TimeSensitiveCommunication" is supported, the feature "AltSerReqsWithIndQoS" is supported as specified in clause 4.2.2.32, and the NF service consumer (i.e. TSCTSF or TSN AF) provides within an entry of the "medComponents" attribute individual QoS information (e.g. within the "tsnQos", "marBwUl" and/or "marBwDl" attributes as described in this clause, then the NF service consumer may provide adjustments to different QoS parameter combinations within a prioritized list of one or more Requested Alternative QoS Parameter set(s) within the "altSerReqsData"attribute as specified in clause 4.2.2.32.

The PCF shall reply to the NF service consumer (i.e. TSN AF or TSCTSF) as described in clause 4.2.2.2.

The PCF shall check whether the received TSCAI input container and TSC QoS related data require to create PCC rules to provide the SMF with derived QoS characteristics and the received TSCAI input container. Provisioning of PCC rule(s) to the SMF shall be carried out as specified in 3GPP TS 29.512 [8].

4.2.2.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 UPF/NW-TT and PMIC(s) for the DS-TT port and/or the NW-TT ports to configure the 5G system as a TSC user plane node bridge by invoking the Npcf_PolicyAuthorization_Create service operation to the PCF.

The NF service consumer may include in the "AppSessionContextReqData" data type:

– the DS-TT PMIC encoded in the attribute "tsnPortManContDstt" and/or the one or more NW-TT PMIC(s) encoded in the "tsnPortManContNwtts" attribute, if available, for the DS-TT port and NW-TT ports allocated for a PDU session. The PMIC(s) are encoded in the "PortManagementContainer" data type, which includes the port management information in the "portManCont" attribute and the related port number in the "portNum" attribute; and/or

– the UMIC encoded in the "tsnBridgeManCont", if available, for the TSC user plane node functionality of the UPF/NW-TT allocated for a PDU session. The UMIC is encoded in the "BridgeManagementContainer" data type.

As result of this action, the PCF shall provide the received DS-TT and/or NW-TT PMIC(s) and/or UMIC for the corresponding PDU session as described in 3GPP TS 29.512 [8].

4.2.2.26 Invocation of Mission Critical Services

This procedure allows a NF service consumer, as per 3GPP TS 22.179 [45], to request prioritized access to system resources in situations such as during congestion.

The NF service consumer may include the "mcsId" attribute to indicate that the new AF session relates to an MCS session.

The "mcsId" attribute shall contain the national variant for the MCS service name indicating an MCS session. The "resPrio" attribute shall include the priority value of the related priority service.

If the NF service consumer supports the SBI Message Priority mechanism for an MCS session, it shall include the "3gpp-Sbi-Message-Priority" custom HTTP header towards the PCF as described in clause 6.8.2 of 3GPP TS 29.500 [5].

NOTE: If the NF service consumer supports the SBI Message Priority mechanism for an MCS session, the NF service consumer will include the "3gpp-Sbi-Message-Priority" custom HTTP header with a priority value equivalent to the value of the "resPrio" attribute. Highest user priority value is mapped in the corresponding lowest value of the "3gpp-Sbi-Message-Priority" custom HTTP header.

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

4.2.2.27 P-CSCF restoration enhancements

The P-CSCF restoration custom operation is applicable when the PCF based Restoration Enhancement, as defined in 3GPP TS 23.380 [39], represented by the supported feature "PCSCF-Restoration-Enhancement" is supported by both P-CSCF and PCF.

Figure 4.2.2.27-1 illustrates the P-CSCF restoration enhancements.

Figure 4.2.2.27-1: P-CSCF restoration enhancements

The P-CSCF acting as a NF service consumer shall invoke the "P-CSCF restoration" custom operation sending an HTTP POST request to the resource URI representing the custom operation (POST …/pcscf-restoration) as shown in figure 4.2.2.27-1, step 1, in case P-CSCF restoration needs to be performed.

The P-CSCF shall include in the "PcscfRestorationRequestData" data type in the payload body of the HTTP POST request:

– the IP address (IPv4 or IPv6) of the UE in the "ueIpv4" or "ueIpv6" attribute, and if the IP address is not unique (e.g. private IPv4 case), the "ipDomain" attribute or the "sliceInfo" attribute if available; or

– if the IP address is not available or if the IP address is not unique and the "ipDomain" attribute and the "sliceInfo" attribute are not available, the SUPI in the "supi" attribute and the DNN in the "dnn" attribute.

The PCF shall identify the PDU session for which the HTTP POST request applies. If the PCF fails in identifying the PDU session, the PCF shall reject the "P-CSCF restoration" custom operation with an HTTP "500 Internal Server Error" response including the "cause" attribute set to "PDU_SESSION_NOT_AVAILABLE".

Otherwise, the PCF shall acknowledge the request and shall send to the NF service consumer a "204 No content" response to the HTTP POST request, as shown in figure 4.2.2.27-1, step 2.

The PCF shall send a request for P-CSCF restoration to the SMF for the corresponding PDU session as described in 3GPP TS 29.512 [8], clause 4.2.3.18.

4.2.2.28 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.2.29 Support of FLUS feature

When "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 created new 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.2.30 Subscription to EPS Fallback report

When the "EPSFallbackReport" feature is supported, the NF service consumer subscribes to EPS Fallback report to be notified of the rejection in 5GS of the requested resources associated to service information for voice media type and the subsequent fallback to EPS of the resources associated to the voice media and other medias requested by this NF service consumer.

The NF service consumer shall use the "EventsSubscReqData" data type as described in clause 4.2.2.2 and shall include in the HTTP POST request message an event within the "events" attribute with the "event" attribute set to "EPS_FALLBACK". The NF service consumer shall request to the PCF to report EPS Fallback in conjuction with providing the PCF with NF service consumer service information for voice media type as described in clause 4.2.2.2.

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

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

4.2.2.31 Subscription to TSC user plane node related events

This procedure is used by the NF service consumer (i.e. TSN AF or TSCTSF) if the "TimeSensitiveNetworking" or "TimeSensitiveCommunication" feature is supported to subscribe to notifications of updated TSC user plane node information, e.g., DS-TT PMIC and/or NW-TT PMIC(s) and/or UMIC availability within the Individual Application Session Context resource created to handle the TSC user plane node in the context of a PDU session.

The NF service consumer shall use the "EventsSubscReqData" data type as described in clause 4.2.2.2 and shall include in the HTTP POST request message within the "evSubsc" attribute an event within "events" attribute with the "event" attribute set to the value "TSN_BRIDGE_INFO" to subscribe to the reception of TSC user plane node information.

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

As result of this action, the PCF shall set the corresponding subscription to TSC user plane node related events for the corresponding PDU session as described in as described in 3GPP TS 29.512 [8].

4.2.2.32 Initial provisioning of required QoS information

This procedure is used by a NF service consumer to request that a data session to a UE is set up with a specific QoS (e.g. low latency or jitter) and priority handling when the "AuthorizationWithRequiredQoS" feature is supported.

The NF service consumer may provide within one or more entries of the "medComponents" attribute included in the "ascReqData" attribute of the HTTP POST request message described in clause 4.2.2.2 a reference to pre-defined QoS information within the "qosReference" attribute.

Additionally, if the NF service consumer supports adjustment to different QoS parameter combinations, the NF service consumer may provide a prioritized list of one or more QoS references within the "altSerReqs" attribute, where the lower the index of the array for a given entry, the higher the priority.

If the "AltSerReqsWithIndQoS" feature is supported, and the NF service consumer requests that the data session to a UE is set up with individual QoS parameters (i.e., with QoS information within "medComponents" attribute, e.g. the "tsnQos", "marBwUl" and/or "marBwDl" attributes, instead of a QoS reference within the "qosReference" attribute), the NF service consumer may instead of the "altSerReqs" attribute provide a prioritized list of alternative service requirements that include Requested Alternative QoS Parameter set(s) within the "altSerReqsData" attribute, where the lower the index of the array for a given entry, the higher the priority.

If the "DisableUENotification" feature is supported, the AF may also indicate to the PCF that the UE does not need to be informed about changes related to Alternative QoS Profiles by including the "disUeNotif" attribute set to true.

When the NF service consumer provides the "altSerReqs" attribute or the "altSerReqsData" attribute, the NF service consumer shall also 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.2.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.2.6.

Due to the received QoS information, the PCF may need to provision or modify the related PCC rules as specified in 3GPP TS 29.513 [7] and provide the related 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.2.2.

4.2.2.33 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 created Individual Application Session Context resource has specific latency and/or loss demands.

4.2.2.34 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 subscribe to notifications of reallocation of credit for the Service Data Flows within the AF application session context.

As 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.2.2.

4.2.2.35 Subscription to satellite backhaul category changes

When the feature "SatelliteBackhaul" is supported, the subscription to satellite backhaul category changes is used by a NF service consumer to subscribe to receive a notification when the satellite backhaul category changes and when the backhaul category changes between satellite backhaul and non-satellite backhaul.

The NF service consumer shall use the "evSubsc" attribute as described in clause 4.2.2.2 and shall include in the HTTP POST request message an event within the "events" attribute with the "event" attribute set to "SAT_CATEGORY_CHG".

The PCF shall reply to the NF service consumer as described in clause 4.2.2.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 requested to the SMF to be updated with this information.

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