4 NEF Northbound Interface

29.5223GPP5G SystemNetwork Exposure Function Northbound APIsRelease 18Stage 3TS

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

4.1 Overview

The NEF Northbound interface is between the NEF and the AF. It specifies RESTful/RPC APIs that allow the AF to access the services and capabilities provided by 3GPP network entities and securely exposed by the NEF.

This document also specifies the procedures triggered at the NEF by API requests from the AF and by event notifications received from 3GPP network entities.

The stage 2 level requirements and signalling flows for the NEF Northbound interface are defined in 3GPP TS 23.502 [2], 3GPP TS 23.247 [53] for MBS specific aspects and 3GPP TS 26.531 [59] for data reporting provisioning and Media Streaming Event Exposure specific aspects.

The NEF Northbound interface supports the following procedures:

1) Procedures for Monitoring

2) Procedures for Device Triggering

3) Procedures for resource management of Background Data Transfer

4) Procedures for CP Parameters, Network Configuration Parameters Provisioning, 5G LAN Parameters Provisioning, ACS Configuration Parameter Provisioning, Location Privacy Indication Parameters Provisioning and ECS address provisioning

5) Procedures for PFD Management

6) Procedures for Traffic Influence

7) Procedures for changing the chargeable party at session set up or during the session

8) Procedures for setting up an AF session with required QoS

9) Procedures for MSISDN-less Mobile Originated SMS

10) Procedures for non-IP data delivery

11) Procedures for analytics information exposure

12) Procedure for applying BDT policy

13) Procedures for Enhanced Coverage Restriction Control

14) Procedures for IPTV Configuration

15) Procedures for Service Parameter Provisioning

16) Procedures for RACS Parameter Provisioning

17) Procedures for Mobile Originated Location Request

18) Procedures for AKMA

19) Procedures for AF triggered Access and Mobility Influence

20) Procedures for AF triggered Access and Mobility Policy Authorization

21) Procedures for Time Synchronization Exposure

22) Procedures for EAS Deployment information provisioning

23) Procedures for TMGI allocation, deallocation, expiry timer refresh and timer expiry notification

24) Procedures for MBS session management and parameters provisioning.

25) Procedures for Data Reporting.

26) Procedures for Data Reporting Provisioning.

27) Procedures for AF specific UE ID retrieval.

28) Procedures for Media Streaming Event Exposure.

29) Procedures for MBS User Service management.

30) Procedures for MBS User Data Ingest Session management.

Which correspond to the following services respectively, supported by the NEF as defined in 3GPP TS 23.502 [2] or 3GPP TS 26.531 [59]:

1) Nnef_EventExposure service and Nnef_APISupportCapability service

2) Nnef_Trigger service

3) Nnef_BDTPNegotiation service

4) Nnef_ParameterProvision service

5) Nnef_PFDManagement service

6) Nnef_TrafficInfluence service

7) Nnef_ChargeableParty service

8) Nnef_AFsessionWithQoS service

9) Nnef_MSISDN-less_MO_SMS service

10) Nnef_NIDDConfiguration and Nnef_NIDD services

11) Nnef_AnalyticsExposure service

12) Nnef_ApplyPolicy service

13) Nnef_ECRestriction service

14) Nnef_IPTVConfiguration service

15) Nnef_ServiceParameter service

16) Nnef_UCMFProvisioning service

17) Nnef_Location service

18) Nnef_AKMA service

19) Nnef_AMInfluence

20) Nnef_AMPolicyAuthorization service

21) Nnef_TimeSynchronization and Nnef_ASTI services

22) Nnef_EASDeployment service

23) Nnef_MBSTMGI service

24) Nnef_MBSSession service

25) Nnef_DataReporting

26) Nnef_DataReportingProvisioning

27) Nnef_UEId service

28) Nnef_MSEventExposure service

29) Nnef_MBSUserService

30) Nnef_MBSUserDataIngestSession

NOTE 1: For Nnef_PFDManagement service, only the Nnef_PFDManagement_Create/Update/Delete service operations are applicable for the NEF Northbound interface.

NOTE 2: For Nnef_NIDD service, NF consumer other than the AF does not use the NEF Northbound interface.

NOTE 3: For Nnef_NIDDConfiguration service, the Nnef_NIDDConfiguration_Trigger service operation is only applicable for the NEF Northbound interface.

NOTE 4: The Nnef_APISupportCapability service is only applicable in the MonitoringEvent API when the monitoring type sets to "API_SUPPORT_CAPABILITY".

NOTE 5: The Nnef_MSEventExposure service maps to the Nnef_EventExposure service and is applicable for the case where the event consumer AF in the Application Service Provider is deployed outside the trusted domain, as described in 3GPP TS 26.531 [59], and the subscribed event is set to "MS_QOE_METRICS", "MS_CONSUMPTION", "MS_NET_ASSIST_INVOCATION", "MS_DYN_POLICY_INVOCATION", or "MS_ACCESS_ACTIVITY".

4.2 Reference model

The NEF Northbound interface resides between the NEF and the AF as depicted in figure 4.2.1. The overall NEF architecture is depicted in 3GPP TS 23.502 [2]. An AF can get services from multiple NEFs, and an NEF can provide services to multiple AFs.

NOTE: The AF can be provided by a third party.

Figure 4.2-1: Reference Architecture for the Nnef Service; SBI representation

Figure 4.2-2: Reference Architecture for the Nnef Service; reference point representation

4.3 Functional elements

4.3.1 NEF

The Network Exposure Function (NEF) is a functional element that supports the following functionalities:

– The NEF shall securely expose network capabilities and events provided by 3GPP NFs to AF.

– The NEF shall provide means for the AF to securely provide information to 3GPP network and may authenticate, authorize and assist in throttling the AF.

– The NEF shall be able to translate the information received from the AF to the one sent to internal 3GPP NFs, and vice versa.

– The NEF shall support to expose information (collected from other 3GPP NFs) to the AF.

– The NEF may support a PFD Function which allows the AF to provision PFD(s) and may store and retrieve PFD(s) in the UDR. The NEF further provisions PFD(s) to the SMF.

– The NEF may support the time synchronization exposure function to the AF.

– The NEF may provide means for the AF to influence access and mobility management related policies.

– The NEF may provide means for the AF to provide inputs that can be used by the PCF for deciding access and mobility management related policies.

– The NEF may provide means for the AF to provide the EAS Deployment information.

– The NEF may provide means for the AF to retrieve AF specific UE ID.

– The NEF may provide means for an untrusted event consumer AF to perform Media Streaming Event Exposure monitoring.

A specific NEF instance may support one or more of the functionalities described above and consequently an individual NEF may support a subset of the APIs specified for capability exposure.

NOTE: The NEF can access the UDR located in the same PLMN as the NEF.

4.3.2 AF

The Application Function (AF) may interact with the 3GPP Core Network via the NEF in order to access network capabilities.

4.4 Procedures over NEF Northbound Interface

4.4.1 Introduction

All procedures that operate across the NEF Northbound interface, as specified in 3GPP TS 23.502 [2], and in 3GPP TS 23.247 [53] for MBS specific aspects, are specified in the following clauses.

4.4.2 Procedures for Monitoring

The procedures for monitoring as described in clause 4.4.2 of 3GPP TS 29.122 [4] shall be applicable in 5GS with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the HSS applies to the UDM, and the NEF shall interact with the UDM by using Nudm_EventExposure service as defined in 3GPP TS 29.503 [17];

– description of the MME/SGSN applies to the AMF, and the NEF shall interact with the AMF by using Namf_EventExposure service as defined in 3GPP TS 29.518 [18];

– description about the PCRF is not applicable;

– description about the change of IMSI-IMEI(SV) association monitoring event applies to the change of SUPI-PEI association monitoring event;

– when "monitoringType" sets to "LOCATION_REPORTING" within the MonitoringEventSubscription data type as defined in clause 5.3.2.1.2 of 3GPP TS 29.122 [4] during the monitoring event subscription, only "CGI_ECGI", "TA_RA", "GEO_AREA" and "CIVIC_ADDR" within the Accuracy data type as defined in clause 5.3.2.4.7 of 3GPP TS 29.122 [4], are applicable for 5G MonitoringEvent API;

– after validation of the AF request, the NEF may determine a monitoring expiry time, based on operator policy and take into account the monitoring expire time if included in the request; and the NEF may provide a expiry time (determined by the NEF, UDM or AMF) to the AF even the AF does not provided before;

– if the "Loss_of_connectivity_notification" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, values 0-5 are not applicable for the lossOfConnectReason attribute within MonitoringEventReport data type, the lossOfConnectReason attribute shall be set to 6 if the UE is deregistered, 7 if the maximum detection timer expires or 8 if the UE is purged;

– the AF may include a periodic reporting time indicated by the "repPeriod" attribute within MonitoringEventSubscription data type, which is only applicable for Location_notification, Number_of_UEs_in_an_area_notification_5G and NSAC features in the NEF;

– if the "locationType" attribute sets to "LAST_KNOWN_LOCATION", the "maximumNumberOfReports" attribute shall set to 1 as a One-time Monitoring Request;

– description about the PDN connectivity status event applies to the PDU session status event, the description of the MME/SGSN applies to the SMF during the reporting of monitoring event procedure, the NEF receives the event notification via Nsmf_EventExposure service as defined in 3GPP TS 29.508 [26];

– if the "Session_Management_Enhancement" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, the "dnn"and/or "snssai" may be provided in MonitoringEventSubscription data type for monitoring type provided "PDN_CONNECTIVITY_STATUS" or " DOWNLINK_DATA_DELIVERY_STATUS";

– when sending the UDM/AMF/SMF event report to the AF, the NEF may store the event data in the report in the UDR as part of the data for exposure as specified in 3GPP TS 29.519 [23] by using Nudr_DataRepository service as specified in 3GPP TS 29.504 [20];

– if the "Downlink_data_delivery_status_5G" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, in order to support the downlink data delivery status notification;

1) the AF shall send an HTTP POST message to the NEF to the resource "Monitoring Event Subscriptions" as defined in clause 5.3.3.2 of 3GPP TS 29.122 [4] for creating an subscription or send an HTTP PUT message to the NEF to the resource "Individual Monitoring Event Subscription" as defined in clause 5.3.3.3 of 3GPP TS 29.122 [4] for updating the subscription with the following difference:

A)within the MonitoringEventSubscription data structure the AF may additionally include packet filter descriptor(s) within the "dddTraDescriptors" attribute and the list of monitoring downlink data delivery status event(s) within the "dddStati" attribute; and

B)the NEF shall subscribe the events to the appropriate UDM(s) within the network by invoking the Nudm_EventExposure_Subscribe service operation as defined in clause 5.5.2.2 of 3GPP TS 29.503 [17];

2)if the "Partial_group_modification" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, in order to support partial cancellation or addition of certain UE(s) within the active group event subscription, the NEF shall map the "excludedExternalIds" and/or "excludedMsisdns" attributes to the "excludeGpsiList" attribute for the partial group cancellation, or shall map the "addedExternalIds" and/or "addedMsisdns" attributes to the "includeGpsiList" attribute within the Nudm_EventExposure service; and

3)when the NEF receives the event notification as defined in clause 4.4.2 of 3GPP TS 29.508 [26], the NEF shall send an HTTP POST message to the AF as defined in clause 4.4.2.3 of 3GPP TS 29.122 [4] with the difference that within each MonitoringEventReport data structure, the NEF shall include:

A)the downlink data delivery status within the "dddStatus" attribute;

B)the downlink data descriptor impacted by the downlink data delivery status change within the "dddTraDescriptor" attribute;

C)the estimated buffering time within the "maxWaitTime" attribute if the downlink data delivery status is set to "BUFFERED"; and

D)if the "Availability_after_DDN_failure_notification_enhancement" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, the AF shall send an HTTP POST message to the NEF to the resource "Monitoring Event Subscriptions" as defined in clause 5.3.3.2 of 3GPP TS 29.122 [4] for creating an subscription or send an HTTP PUT message to the NEF to the resource "Individual Monitoring Event Subscription" as defined in clause 5.3.3.3 of 3GPP TS 29.122 [4] for updating the subscription with the difference that within the MonitoringEventSubscription data structure, the AF shall include packet filter descriptions within the "dddTraDescriptors" attribute;

– if the "eLCS" feature as defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, the AF may send an HTTP POST message to the NEF to the resource "Monitoring Event Subscriptions" as defined in clause 5.3.3.2 of 3GPP TS 29.122 [4] for creating an subscription or send an HTTP PUT message to the NEF to the resource "Individual Monitoring Event Subscription" as defined in clause 5.3.3.3 of 3GPP TS 29.122 [4] for updating the subscription with the following difference:

1)within the MonitoringEventSubscription data structure, the AF may additionally include location QoS requirement within the "locQoS" attribute, the service identifier within the "svcId" attribute, Location deferred requested event type within the "ldrType" attribute, the validity start time and the validity end time within the "locTimeWindow" attribute, the maximum age of location estimate within the "maxAgeOfLocEst" attribute, the requesting target UE velocity within the "velocityRequested" attribute, the linear distance within the "linearDistance" attribute, the reporting target UE location estimate indication within the "reportingLocEstInd" attribute, the sampling interval within the "samplingInterval" attribute, the maximum reporting expire interval within the "maxRptExpireIntvl" attribute, the supported GAD shapes within the "supportedGADShapes" attribute, the Code word within the "codeword" attribute, and other attributes as defined in clause 5.3.2.3.2 of 3GPP TS 29.122 [4] for location information subscription; The MonitoringEventSubscription data structure may also include the "locationArea5G" attribute containing only the "geographicAreas" attribute and the "accuracy" attribute set to the value "GEO_AREA". The "accuracy" attribute and "locQoS" attribute are mutually exclusive. If the "MULTIQOS" feature is also supported, Multiple QoS Class is supported in the "lcsQosClass" attribute within the "locQoS" attribute for deferred MT-LR;

2)if the NEF identifies the location request precision higher than cell level location accuracy is required based on the "locQoS" attribute received, the NEF shall interact with the appropriate GMLC within the network by invoking the Ngmlc_Location_ProvideLocation service operation as defined in clause 6.1 of 3GPP TS 29.515 [35];

3)if the location request precision is lower than or equal to cell level, based on implementation, the NEF may interact with the GMLC by invoking the Ngmlc_Location_ProvideLocation service operation as defined in clause 6.1 of 3GPP TS 29.515 [35]; or retrieve the UE location privacy information from the UDM by using Nudm_SDM service as described in clause 5.2 of 3GPP TS 29.503 [17] and if the privacy setting is verified, the NEF shall interact with the UDM for the serving AMF address by invoking the Nudm_UECM service as described in clause 5.3 of 3GPP TS 29.503 [17]. After receiving the serving AMF address from the UDM, the NEF shall interact with the AMF by invoking the Namf_EventExposure_Subscribe service operation as defined in clause 5.3 of 3GPP TS 29.518 [18]; or may interact with UDM by using Nudm_EventExposure service as defined in clause 5.5 of 3GPP TS 29.503 [17] and the NEF receives the location event notification from the AMF via Namf_EventExposure service as defined in in clause 5.5 of 3GPP TS 29.518 [18]; and

4)based on the received AF information and local authorization policy, the NEF shall derive the LCS client type with a suitable enumeration value for the AF location request, to be provided as the "externalClientType" attribute when invoking the Ngmlc_Location_ProvideLocation service operation as defined in clause 6.1 of 3GPP TS 29.515 [35];

Upon receipt of successful location response from the GMLC or the AMF or the UDM, the NEF shall create or update the "Individual Monitoring Event Subscription" resource and then send an HTTP POST or PUT response to the AF as defined in clause 4.4.2.2 of 3GPP TS 29.122 [4]. Upon receipt of the location Report from the GMLC or the AMF, the NEF shall determine the monitoring event subscription associated with the corresponding Monitoring Event Report as defined in clause 4.4.2.3 of 3GPP TS 29.122 [4].

In order to delete a previous active configured monitoring event subscription at the NEF, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual Monitoring Event Subscription" which is received in the response to the request that has created the monitoring events subscription resource. The NEF shall interact with the GMLC or the AMF or the UDM to remove the request, upon receipt of the successful response from the GMLC or the AMF or the UDM, the NEF shall delete the active resource "Individual Monitoring Event Subscription" addressed by the URI and send an HTTP response to the AF with a "204 No Content" status code, or a "200 OK" status code including the monitoring event report if received;

– Based on local regulations’ requirements and operator policies, user consent management specified in Annex V of 3GPP TS 33.501 [6] may be required for EDGE applications to access the Nnef_EventExposure API for UE’s location retrieval. When it is the case and the NEF is used by the Edge Enabler Layer entities to access 3GPP 5GC services, the NEF acts as the consent enforcement entity, as specified in clause 5.1.3 of 3GPP TS 33.558 [56];

When user consent management shall be carried out for EDGE applications, then:

1)if the AF (e.g. Edge Enabler Server) does not support the "UserConsentRevocation" feature or does not indicate its support for this feature in the HTTP POST request to create a new "Individual Monitoring Event Subscription" resource with the "monitoringType" attribute set to "LOCATION_REPORTING", the NEF shall reject the request and respond to the AF with an HTTP "403 Forbidden" status code with the response body including a ProblemDetails data structure containing the "CONSENT_REVOCATION_NOT_SUPPORTED" application error within the "cause" attribute;

2)if the AF indicates its support for the "UserConsentRevocation" feature in the HTTP POST request to create a new "Individual Monitoring Event Subscription" resource with the "monitoringType" attribute set to "LOCATION_REPORTING", the NEF shall check user consent for the targeted UE(s) by retrieving the user consent subscription data via the Nudm_SDM service API of the UDM as specified in clause 5.2.2.2.24 of 3GPP TS 29.503 [17], subscribe to user consent revocation notifications only for those UE(s) for which user consent is granted also using the Nudm_SDM service API of the UDM and accept the request for the creation of the event monitoring subscription only for the UE(s) for which user consent is granted;

3)if user consent is not granted for all the targeted UE(s), the NEF shall reject the request and respond to the AF with an HTTP "403 Forbidden" status code with the response body including a ProblemDetails data structure including the "USER_CONSENT_NOT_GRANTED" application error within the "cause" attribute;

4)the AF shall provide within the HTTP POST request to create a new event monitoring subscription the URI via which it desires to receive user consent revocation notifications within the "revocationNotifUri" attribute. The AF may update this URI in subsequent HTTP PUT/PATCH requests to update/modify the corresponding "Individual Monitoring Event Subscription" resource;

5)when becoming aware of user consent revocation for one or several UE(s), the NEF shall:

A)stop processing the data related to the concerned UE(s);

B)send a user consent revocation notification to the AF by sending an HTTP POST request with the request body including the ConsentRevocNotif data structure that shall contain the user consent revocation information (e.g. UE(s) for which user consent was revoked, etc.); and

C)remove the concerned UE(s) from the corresponding "Individual Monitoring Event Subscription" resource and from the related subscriptions at the GMLC, if any; and

D)unsubscribe from user consent revocation notifications for the concerned UE(s) at the UDM;

and

6)at the reception of the user consent revocation notification from the NEF, the AF shall take the necessary actions to stop processing the data related to the UE(s) for which user consent was revoked;

– if user consent is revoked for all the UE(s), the AF shall delete the corresponding "Individual Monitoring Event Subscription" resource as specified above in this clause.

– if the "NSAC" feature defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, in order to support network slice status reporting:

1)the AF shall send an HTTP POST request to the NEF to the "Monitoring Event Subscriptions" resource as defined in clause 5.3.3.2.3.4 of 3GPP TS 29.122 [4] to create a subscription, or send an HTTP PUT message to the NEF to the "Individual Monitoring Event Subscription" resource as defined in clause 5.3.3.3.3.2 of 3GPP TS 29.122 [4] to update an existing subscription with the following differences:

A)within the MonitoringEventSubscription data structure:

a) either the concerned network slice identified by the "snssai" attribute, in the case of a trusted AF, or the AF service identifier within the "afServiceId" attribute, in the case of an untrusted AF, shall be provided;

b) the value of the "monitoringType" attribute shall be set to "NUM_OF_REGD_UES" to indicate that the AF requests to be notified of the current number of registered UEs for the network slice or "NUM_OF_ESTD_PDU_SESSIONS" to indicate that the AF requests to be notified of the current number of established PDU Sessions for the network slice;

c) the "maximumNumberOfReports" attribute set to a value of 1 shall be provided, if one-time reporting of the current network slice status information is requested;

d) if one-time reporting is not requested, either a targeted reporting threshold within the "tgtNsThreshold" attribute (if threshold based reporting is requested) or a reporting periodicity within the "repPeriod" attribute (if periodic reporting is requested) shall be provided;

e) if periodic reporting is requested, the "nsRepFormat" attribute shall be provided to indicate the requested reporting format (i.e. numerical or percentage); and

f) the "immediateRep" attribute set to "true", if immediate reporting of the current network slice status information is requested or one-time reporting of the current network slice status information is requested;

2)the NEF shall then further interact with the concerned NSACF(s) to create or update the associated subscription(s) to notifications by invoking the Nnsacf_SliceEventExposure_Subscribe service operation as specified in 3GPP TS 29.536 [47];

If an AF service identifier was provided by the AF (case of an untrusted AF), the NEF shall translate it into the corresponding S-NSSAI prior to sending the request(s) to the NSACF(s).

After receiving a successful response from the NSACF(s), the NEF shall:

NOTE 1: If multiple NSACFs are selected for the requested S-NSSAI, the NEF can set the event reporting type to periodic in its request to these NSACFs, irrespective of the requested reporting type by the AF (i.e. threshold based reporting or periodic reporting).

A)for the HTTP POST request, respond to the AF as defined in clause 5.3.3.2.3.4 of 3GPP TS 29.122 [4] with either;

a)a "201 Created" status code and the response body containing the created "Individual Monitoring Event Subscription" resource within the MonitoringEventSubscription data structure. The NEF shall include the current network slice status information received from the NSACF within the "monitoringEventReport" attribute, if available and the "immediateRep" attribute was provided and set to "true" in the request; or

b)a "200 OK" status code and the response body containing the current network slice status information received from the NSACF within the "MonitoringEventReport" data structure, if it is a one-time reporting request with the "immediateRep" attribute set to "true"; and

B)for the HTTP PUT request, respond to the AF with a "200 OK" status code as defined in clause 5.3.3.3.3.2 of 3GPP TS 29.122 [4] and the response body including the MonitoringEventSubscription data structure containing a representation of the updated "Individual Monitoring Event Subscription" resource. The NEF shall include the current network slice status information received from the NSACF within the "monitoringEventReport" attribute, if available and the "immediateRep" attribute was provided and set to "true" in the request;

NOTE 2: When the "maximumNumberOfReports" attribute is provided and set to a value of 1 and the "immediateRep" attribute is provided and set to "true", the Individual Monitoring Event Subscription is immediately terminated after returning the current network slice status information in the HTTP POST response body.

NOTE 3: After sending a subscription creation request for network slice status reporting with a particular reporting format (e.g. percentage) for periodic reporting, an AF cannot send a subsequent subscription creation request for the same network slice with a different reporting format (e.g. numerical) for periodic reporting.

3)when the NEF receives event report(s) from the NSACF(s) as defined in 3GPP TS 29.536 [47], the NEF shall notify the AF via an HTTP POST message as defined in clause 5.3.3A.2.3 of 3GPP TS 29.122 [4] with the following differences:

A)within the MonitoringEventReport data type of the MonitoringNotification data type;

a)the value of the "monitoringType" attribute shall be set to "NUM_OF_REGD_UES" or "NUM_OF_ESTD_PDU_SESSIONS" (i.e. the same value received during the HTTP POST or PUT request that created or modified the subscription);

b)the AF service identifier to which the notification is related, within the "afServiceId" attribute, if it was provided by the AF in the related subscription request; and

c)the current network slice status information as the "nSStatusInfo" attribute shall be provided, wherein:

I)if the event reporting is threshold based (i.e. the "tgtNsThreshold" was provided within the MonitoringEventSubscription data type), the "nSStatusInfo" attribute shall contain a confirmation for reaching the targeted threshold value, i.e. by sending the current number of registered UEs or the current number of established PDU Sessions, for the network slice identified by the "snssai" attribute provided during the subscription creation/update; and

II)if the event reporting is periodical (i.e. the "repPeriod" was provided within the MonitoringEventSubscription data type), the "nSStatusInfo" attribute shall provide the current network slice status information, i.e. the current number of registered UEs or the current number of established PDU Sessions for the network slice identified by the "snssai" attribute provided during the subscription creation/update; and

NOTE 4: The handling of threshold based notifications is described in clause 4.15.3.2.10 of 3GPP TS 23.502 [2].

NOTE 5: If the NEF interacts with multiple NSACFs for the requested S-NSSAI, the NEF performs the aggregation of the received network slice status reports from all these NSACFs and determines based on that whether a notification towards the subscribing AF needs to be sent or not (i.e. the reporting conditions to trigger a notification towards the AF are fulfilled or not).

4)in order to unsubscribe from network slice status reporting, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual Monitoring Event Subscription" as defined in clause 5.3.3.3.3.5 of 3GPP TS 29.122 [4] to delete an existing network slice reporting subscription. Then the NEF shall interact with the NSACF to delete the associated subscription to notifications by invoking the Nnsacf_SliceEventExposure_Unsubscribe service operation as specified in 3GPP TS 29.536 [47]; and

– if the "UEId_retrieval" feature defined in clause 5.3.4 of 3GPP TS 29.122 [4] is supported, in order to support AF specific UE ID retrieval:

1)the AF may request AF specific UE ID retrieval for an individual UE, by providing the UE’s IP address in the "ueIpAddr" attribute or the UE’s MAC address in the "ueMacAddr" attribute within the MonitoringEventSubscription data type;

2)the AF may also provide the DNN in "dnn" attribute and/or the S-NSSAI in the "snssai" attribute in the MonitoringEventSubscription data type;

3)upon reception of the corresponding request message from the AF, the NEF shall check whether the AF is authorized to perform this operation or not:

– if the AF’s request for AF specific UE ID retrieval is not authorized, the NEF shall respond to the AF with a "403 Forbidden" status code with the response body including the ProblemDetails data structure containing the "cause" attribute set to the "REQUEST_NOT_AUTHORIZED" application error indicating AF authorisation failure; and

– if the AF request is for AF specific UE ID retrieval authorized by the NEF, then if the DNN and/or S-NSSAI information is not available in the request, the NEF shall determine the corresponding DNN and/or S-NSSAI information based on the requesting AF Identifier, and if provided, the MTC Provider Information.

4)the NEF shall then interact with the BSF using the UE address and IP domain (if the UE IPv4 address is provided), DNN and/or S-NSSAI to retrieve the session binding information of the UE by invoking the Nbsf_Management_Discovery service operation as described in 3GPP TS 29.521 [9].;

5)if the NEF receives an error response from the BSF, the NEF shall respond to the AF with a proper error status code. If the NEF received from the BSF an error response including a "ProblemDetails" data structure with the "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error. If no SUPI matching the provided UE information is returned by the BSF, the NEF shall respond to the AF with a "404 Not Found" status code with the response body including a ProblemDetails data structure containing the "cause" attribute set to the "UE_NOT_FOUND" application error to indicate that the requested UE address is not found;

6)upon success and a SUPI is returned by the BSF, the NEF shall then interact with the UDM to retrieve the AF specific UE Identifier using the received SUPI and at least one of the Application Port ID, MTC Provider Information or AF Identifier information by invoking Nudm_SDM_Get service as described in clause 5.2.2.2 of 3GPP TS 29.503 [17].;

7)upon success, the UDM responds to the NEF with an AF specific UE Identifier represented as an External Identifier for the UE which is uniquely associated with the MTC provider Information and/or AF Identifier. The NEF shall then respond to the AF with the received information, i.e. the AF specific UE Identifier represented as an External Identifier that was received from the UDM;

8)if the NEF receives an error response from the UDM, the NEF shall respond to the AF with a proper error status code. If the NEF received from the UDM an error response including a "ProblemDetails" data structure with the "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error. If the UDM indicates that the requested UE Identifier is not available in the subscription data, the NEF shall respond to the AF with a "404 Not Found" error status code with the response body including a ProblemDetails data structure containing the "cause" attribute set to the "UE_ID_NOT_AVAILABLE" application error to indicate that the AF specific UE ID is not available.

NOTE 6: The case where the UE’s IP address provided by the AF to the NEF corresponds to an IP address that has been NATed (Network and Port Address Translation) is not supported in this release of the specification.

Editor’s note: Whether and how user’s consent is needed is FFS and pending SA6 and SA3 feedback.

4.4.3 Procedures for Device Triggering

The procedures for device triggering as described in clause 4.4.6 of 3GPP TS 29.122 [4] shall be applicable in 5G with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the HSS applies to the UDM;

– the NEF shall interact with the UDM by using the Nudm_SubscriberDataManagement service and the Nudm_UEContextManagement service as defined in 3GPP TS 29.503 [17]; and

– the NEF acts as MTC-IWF.

4.4.4 Procedures for resource management of Background Data Transfer

The procedures for resource management of Background Data Transfer (BDT) in 5GS are described in clause 4.4.3 of 3GPP TS 29.122 [4] with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– If the feature Group_Id is supported, an external group identifier may be included in the HTTP POST or PUT request message by the NEF. If the external group Id is sent from the AF to the NEF, the NEF shall interact with the UDM by using Nudm_SubscriberDataManagement service as defined in 3GPP TS 29.503 [17] to translate the external group identifier into the corresponding internal group identifier;

– description of the PCRF applies to the PCF;

– the NEF shall interact with the PCF by using Npcf_BDTPolicyControl service as defined in 3GPP TS 29.554 [19];

– if the "BdtNotification_5G" feature is supported, the AF may include a notification URI within the "notificationDestination" attribute in the Bdt data type during the background data transfer policy negotiation. In addition, the AF may request to enable the BDT warning notification by setting the "warnNotifEnabled" attribute to true. When the NEF receives the BDT warning notification from the PCF as defined in clause 4.2.4.2 of 3GPP TS 29.554 [19] and the "warnNotifEnabled" attribute was set to true, the NEF shall send an HTTP POST message including the ExNotification data structure to the AF identified by the notification destination URI received during the background data transfer policy negotiation. The AF shall respond with an HTTP response to confirm the received notification. The AF may select one policy from the candidate of BDT policies if provided in the notification by using the HTTP PATCH message as described in clause 5.4.3.3.3.3 of 3GPP TS 29.122 [4]. If the selected policy is set to value "0" within the "selectedPolicy" attribute in the HTTP PATCH message, it implies no transfer policy is selected by the AF. The AF may also request to disable/enable the BDT warning notification by including the "warnNotifEnabled" attribute in the HTTP PATCH message; and

– The AF may include a traffic descriptor of background data within the "trafficDes" attribute in the Bdt data type during the background data transfer policy negotiation.

4.4.5 Procedures for CP Parameters Provisioning

The procedures for CP parameters provisioning as described in clause 4.4.9 of 3GPP TS 29.122 [4] shall be applicable in 5G with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the HSS applies to the UDM;

– the NEF shall interact with the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17];

– if the ExpectedUMT_5G feature as defined in clause 5.10.4 of 3GPP TS 29.122 [4] is supported, the expected UE moving trajectory within the "expectedUmts" attribute shall also be included in the HTTP POST/PUT request. In addition, if the ExpectedUmtTime_5G feature as defined in clause 5.10.4 of 3GPP TS 29.122 [4] is supported, the start time and duration may be provided in the "expectedUmts" attribute to indicate when the UE arrives at a location and how long the UE stays in the location and the periodicity in the "expectedUmtDays" attribute may be provided to indicate the effective days within a week; and

– if the "UEId_retrieval" feature defined in clause 5.10.4 of 3GPP TS 29.122 [4] is supported, in order to support the AF specific UE ID retrieval:

2)the AF may also provide the DNN in the "dnn" attribute and/or the S-NSSAI in the "snssai" attribute within the CpInfo data type;

3)upon reception of the corresponding request message from the AF:

– if the AF’s request for AF specific UE ID retrieval is authorized by the NEF, then if the DNN and/or S-NSSAI information is not available in the request, the NEF shall determine the corresponding DNN and/or S-NSSAI information based on the requesting AF Identifier, and if provided, the MTC Provider Information;

4)the NEF shall interact using the the BSF with UE address and IP domain (if the UE IPv4 address is provided), DNN and/or S-NSSAI to retrieve the session binding information of the UE by invoking the Nbsf_Management_Discovery service operation as described in 3GPP TS 29.521 [9].;

6)upon success and a SUPI is returned by the BSF, the NEF shall interact with the UDM to retrieve the AF specific UE Identifier using the received SUPI and at least one of the Application Port ID, MTC Provider Information or AF Identifier information by invoking Nudm_SDM_Get service as described in clause 5.2.2.2 of 3GPP TS 29.503 [17].

7)upon success, the UDM responds to the NEF with the AF specific UE Identifier represented as an External Identifier for the UE which is uniquely associated with the MTC provider Information and/or AF Identifier. The NEF shall then respond to the AF with the received information, i.e. the AF specific UE Identifier represented as an External Identifier that was received from the UDM;

NOTE: The case where UE’s IP address provided by the AF to the NEF corresponds to an IP address that has been NATed (Network and Port Address Translation) is not supported in this release of the specification.

Editor’s note: Whether and how user’s consent is needed is FFS and pending SA6 and SA3 feedback.

4.4.6 Procedures for PFD Management

The procedures for PFD management as described in clause 4.4.10 of 3GPP TS 29.122 [4] shall be applicable for 5GS with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF; and

– the NEF (PFDF) shall interact with the UDR for PFD management by using Nudr_DataRepository service as defined in 3GPP TS 29.504 [20]. The PFDF is functionality within the NEF.

– If the PFDs are provisioned to at least one of the subscribed SMFs (but not all) within the allowed delay, the NEF (PFDF) may notify the AF about the failed PFD provisioning with the HTTP POST message by including the PfdReport data structure in the body of the message. In addition, the NEF may include the location area(s) of the user plane(s) which are unable to enforce the provisioned PFD(s) within the "locationArea" attribute of the PFD report(s). If the PFDs are provisioned to none of the subscribed SMFs within the allowed delay, the NEF (PFDF) shall notify the AF about the failed PFD provisioning with the HTTP POST message using appropriate failure code as defined in Table 5.11.2.2.3-1 of 3GPP TS 29.122 [4].

NOTE 1: Unsuccessful PFDs provisioning to the subscribed SMFs within the allowed delay means that the PFDs are not provisioned successfully to the UPFs served by the failed SMFs.

NOTE 2: The NEF maps the 3GPP network area(s) to the geographic area(s), civic address(es) or DNAI(s) if the 3GPP network area(s) is not allowed to be exposed to the 3rd party according to the operator policy.

4.4.7 Procedures for Traffic Influence

4.4.7.1 General

In order to create a resource for the Traffic Influence, the AF shall send an HTTP POST message to the NEF to the resource "Traffic Influence Subscription", the body of the HTTP POST message may include the AF Service Identifier, external Group Identifier, any UE Indication, the UE address, GPSI, DNN, S-NSSAI, Application Identifier or traffic filtering information, Subscribed Event, Notification destination address, a list of geographicareas(s), AF Transaction Identifier, a list of DNAI(s), routing profile ID(s) or N6 traffic routing information, Indication of application relocation possibility, type of notifications, Temporal validity conditions, and if the URLLC feature is supported, Indication of AF acknowledgement to be expected and/or Indication of UE IP address preservation. If the AF_latency feature is supported, user plane latency requirements may also be included and may support the indication of simultaneous connectivity in the "simConnInd" attribute and the minimum time interval for inactivity of traffic via source PSA in the "simConnTerm" attribute. If the EASDiscovery feature is supported, the indication of the EAS rediscovery may also be included. If the EASIPreplacement feature is supported, EAS IP replacement information may also be included. If the EDGEAPP feature is supported and the "subscribedEvents" attribute is provided, the event reporting requirements may also be included within the "eventReq" attribute. The Notification destination address shall be included if the Subscribed Event is included in the HTTP request message.

In order to update an existing traffic influence subscription, the AF shall send an HTTP PUT or PATCH message to the resource "Individual Traffic Influence Subscription" requesting to change the traffic influence parameters.

In order to delete an existing traffic influence subscription, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual Traffic Influence Subscription".

Upon receipt of the HTTP request from the AF, if the AF is authorized, the NEF shall perform the mapping as described in 3GPP TS 23.501 [3], and then perform as described in clause 4.4.7.2 if the request is identified by UE address or perform as described in clause 4.4.7.3 if the request is not identified by UE address.

If the EDGEAPP feature is supported and the "subscribedEvents" attribute is provided in the received HTTP POSTrequest, and immediate reporting was requested by the AF, then user plane path management report(s) shall be included in the HTTP POST response within the "eventReports" attribute, if available. They may also be included in the HTTP PUT/PATCH response, if available.

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

4.4.7.2 AF request identified by UE address

Upon receipt of the above AF request which is for an individual UE identified by IP or Ethernet address, the NEF may interact with the BSF to retrieve the related PCF information by invoking the Nbsf_Management_Discovery service operation as described in 3GPP TS 29.521 [9] If the NEF receives an error responsefrom the BSF, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the BSF, the NEF shall interact with the PCF by invoking the Npcf_PolicyAuthorization service as described in 3GPP TS 29.514 [7]. After receiving a successful response from the PCF, the NEF shall:

– for the HTTP POST request, create a resource "Individual Traffic Influence Subscription" which represents the traffic influence subscription, addressed by a URI that contains the AF Identifier and an NEF-created subscription identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this traffic influence subscription:

– for the HTTP PUT or PATCH request, update a resource "Individual Traffic Influence Subscription" which represents the traffic influence subscription, and shall responds to the AF with a 200 OK status code with the "TrafficInfluSub" data structure as response body containing the representation of the modified "Individual Traffic Influence Subscription", or an HTTP "204 No Content" response; and

– for the HTTP DELETE request, remove all properties of the resource and delete the corresponding active resource "Individual Traffic Influence Subscription" which represents the traffic influence subscription, then shall responds to the AF with a 204 No Content status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

If the NEF receives a response with an error code from the PCF, the NEF shall not create, update or delete the resource and shall respond to the AF with a proper error status code.

4.4.7.3 AF request not identified by UE address

For AF request not identified by UE address, it may target an individual UE, a group of UEs or any UE. For an individual UE identified by GPSI, or a group of UEs identified by External Group Identifier, the NEF shall interact with the UDM by invoking the Nudm_SubscriberDataManagement service as described in 3GPP TS 29.503 [17] to retrieve the SUPI or Internal Group Identifier.

The NEF shall interact with the UDR to store the received traffic influence parameters from the AF by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] and 3GPP TS 29.519 [23]. If the NEF receives an error responsefrom the UDR, the NEF shall not create, update or delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall:

– for the HTTP DELETE request, delete the corresponding active resource "Individual Traffic Influence Subscription" which represents the traffic influence subscription, and shall responds to the AF with a 204 No Content status code.

4.4.7.4 Handling of UP path management event notification

If the NEF receives a UP path management event notification from the SMF indicating that the subscribed event has been detected, then the NEF shall provide a notification by sending an HTTP POST message that shall include the EventNotification data type at least with the subscribed event (e.g. UP Path has changed) to the AF identified by the notification destination received during creation or modification of the Individual Traffic Influence Subscription resource and, optionally, by the AF Transaction Identifier received during the creation of the Individual Traffic Influence Subscription resource. If a URI for AF acknowledgement within the "ackUri" attribute is provided by the SMF in the event notification as defined in 3GPP TS 29.508 [26], the NEF shall also provide a URI for AF acknowledgement within the "afAckUri" attribute in the EventNotification data.

Upon receipt of the event notification, the AF shall respond with a "204 No Content" status code to confirm the received event notification.

Afterwards, if a URI for AF acknowledgement within the "afAckUri" attribute is received during the UP path management event notification, the AF may determine that an application layer relocation is needed, and may then send an HTTP POST request as acknowledgement for the UP path management event notification to inform the NEF about the result of application layer relocation. If the application layer is ready and/or the application relocation is completed, within the payload of the HTTP POST request, the AF shall include the AfAckInfo data type with the "afStatus" attribute set to "SUCCESS" and may provide within the AfResultInfo data the N6 traffic routing information associated to the target DNAI as "trafficRoute" attribute and, if the "ULBuffering" feature is supported, an indication that buffering of uplink traffic to the target DNAI is needed as "upBuffInd" attribute and, if the "EASIPreplacement" feature is supported, EAS IP replacement information as "easIpReplaceInfos" attribute; otherwise, the AF shall indicate the failure by including the AfAckInfo data type in the payload with the "afStatus" attribute sets to the corresponding failure cause. The NEF Northbound interface transaction identifier generated by the AF shall also be provided as the "afTransId" attribute within the AfAckInfo data if the AF has previously provided it.

Upon receipt of the AF acknowledgement, the NEF shall respond with a "204 No Content" status code to confirm the received acknowledgement, and forward the AF acknowledgement to the SMF as described in 3GPP TS 29.508 [26].

4.4.8 Procedures for changing the chargeable party at session set up or during the session

The procedures for changing the chargeable party at session set up or during the session in 5GS are described in clause 4.4.4 of 3GPP TS 29.122 [4] with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the PCRF applies to the PCF;

– in the HTTP POST request, the AF may include the AF session subscribed "dnn" attribute and/or "snssai" attribute;

– if the EthChgParty_5G feature as defined in clause 5.5.4 of 3GPP TS 29.122 [4] is supported and the request is for Ethernet UE:

– in the HTTP POST request, the AF shall include the UE MAC address within the "macAddr" attribute instead of the UE IP address, If the AppId feature is not supported,the AF shall include the Ethernet Flow description within the "ethFlowInfo" attribute instead of the IP Flow description; otherwise, the AF shall include either the External Application Identifier within the "exterAppId" attribute or the Ethernet Flow description within the "ethFlowInfo" attribute;

– in the HTTP PATCH request, the AF may update the Ethernet Flow description within the "ethFlowInfo" attribute or the External Application Identifier within the "exterAppId" attribute;

– the NEF may interact with BSF by using Nbsf_Management_Discovery service (as defined in 3GPP TS 29.521 [9]) to retrieve the PCF address; and

– the NEF shall interact with the PCF by using Npcf_PolicyAuthorization service as defined in 3GPP TS 29.514 [7].

4.4.9 Procedures for setting up an AF session with required QoS

The procedures for setting up an AF session with required QoS in 5GS are described in clause 4.4.13 of 3GPP TS 29.122 [4] with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the PCRF applies to the PCF;

– the NEF may interact with BSF by using Nbsf_Management_Discovery service as defined in 3GPP TS 29.521 [9] to retrieve the PCF address;

– the NEF shall interact with the PCF by using Npcf_PolicyAuthorization service as defined in 3GPP TS 29.514 [7];

– in the HTTP POST request, the AF may include a "dnn" attribute and/or a "snssai" attribute; and in the HTTP PUT request, the AF shall keep the same value(s) of the "dnn" attribute and/or the "snssai" attribute as set in the HTTP POST request if provided;

– description about the INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION event and INDICATION_OF_FAILED_RESOURCES_ALLOCATION event apply to the SUCCESSFUL_RESOURCES_ALLOCATION event and FAILED_RESOURCES_ALLOCATION event respectively; In addition, description about the INDICATION_OF_RELEASE_OF_BEARER, INDICATION_OF_LOSS_OF_BEARER and INDICATION_OF_RECOVERY_OF_BEARER events are not applicable in this specification.

– if the EthAsSessionQoS_5G feature as defined in clause 5.14.4 of 3GPP TS 29.122 [4] is supported and the request is for Ethernet UE:

– in the HTTP POST/PUT request, the AF shall include the UE MAC address within the "macAddr" attribute instead of the UE IP address. If the AppId feature is not supported, the AF shall include the Ethernet Flow description within the "ethFlowInfo" attribute instead of the IP Flow description; otherwise, the AF shall include either the External Application Identifier within the "exterAppId" attribute or the Ethernet Flow description within the "ethFlowInfo" attribute;

– in the HTTP PATCH request, the AF may update the Ethernet Flow description within the "ethFlowInfo" attribute or the External Application Identifier within the "exterAppId" attribute;

– if the "QoSMonitoring_5G" feature as defined in clause 5.14.4 of 3GPP TS 29.122 [4] is supported, in order to support the QoS Monitoring, the AF shall include "qosMonInfo" attribute. The AF shall also include the "directNotifInd" attribute set to true if the "ExposureToEAS" feature is supported and the direct notification is required. Within the QosMonitoringInformation data structure, the AF shall include:

– one or more requested QoS Monitoring Parameter(s) within the "reqQosMonParams"; and

– one or more report frequency within the "repFreqs" attribute; and

– when the "repFreqs" attribute includes the value "PERIODIC", the reporting period within the "repPeriod" attribute; and

– when the "repFreqs" attribute includes the value "EVENT_TRIGGERED", the AF shall include:

– the delay threshold for downlink with the "repThreshDl" attribute;

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

– the delay threshold for round trip with the "repThreshRp" attribute; and

– the minimum waiting time between subsequent reports within the "waitTime" attribute.

If the NEF authorizes the AF request, the NEF may create a QoS monitoring notification correlation identifier for the AF transaction during the creation of the AF resource and may provision it together with the received QoS monitoring parameters to the PCF by invoking the Npcf_PolicyAuthorization service as defined in 3GPP TS 29.514 [7];

– when the NEF receives the event notification for the AF transaction as defined in clause 4.2.2 of 3GPP TS 29.508 [26] or clauses 4.2.4.12 and 4.2.5.14 of 3GPP TS 29.514 [7], or when the AF requested direct notification, as defined in clause 5.2.2.3 of 3GPP TS 29.564 [61], the NEF shall include one or more QoS monitoring reports within the "qosMonReports" attribute. Within the QosMonitoringReport data structure, the NEF shall include:

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

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

– one or two round trip packet delays within the "rtDelays" attribute; and

– if the "AlternativeQoS_5G" feature is supported, the AF may include an ordered list of QoS references within the "altQosReferences" attribute and, if the "DisableUENotification_5G" feature is also supported, an indication that the UE does not need to be informed about changes related to Alternative QoS Profiles within the "disUeNotif" attribute. The NEF shall transfer them to the PCF in the Npcf_PolicyAuthorization service and subscribe to PCF event "QOS_NOTIF" in the Npcf_PolicyAuthorization service. When the NEF receives the notification of PCF event "QOS_NOTIF", it shall notify the AF with "QOS_GUARANTEED" event; or "QOS_NOT_GUARANTEED" event with the currently applied QoS reference if received. When the NEF receives the notification of PCF event "SUCCESSFUL_RESOURCES_ALLOCATION", it shall notify the AF the event together with the currently applied QoS reference if received.

NOTE 1: Based on the operator configuration, the QoS reference identifiers received from the AF can be the same or different as the QoS reference identifiers known at the PCF. The NEF can perform a mapping for the QoS reference identifier.

– if the "TSC_5G" feature is supported, the AF may include:

– the TSC QoS requirement within the "tscQosReq" attribute. Within the TscQosRequirement data structure, the AF may include:

– the input information to construct the TSC Assistance Container within the "tscaiInputUl" attribute and/or "tscaiInputDl"attribute;

And, if individual QoS parameters instead of QoS reference is provided, may include:

– requested GBR within the "reqGbrDl" attribute and/or "reqGbrUl" attribute;

– requested MBR within the "reqMbrDl" attribute and/or "reqMbrUl" attribute; and

– the maximum burst size within the "maxTscBurstSize" attribute;

– the priority within the "priority" attribute;

– the requested 5GS delay within the "req5Gsdelay" attribute.

If the NEF authorizes the AF request, the NEF may provision the received QoS requirements to the TSCTSF by invoking the Ntsctsf_QoSandTSCAssistance_Create/Update request as defined in 3GPP TS 29.565 [50]. The NEF determines whether to invoke the TSCTSF or to directly contact the PCF based on operator configuration. This determination may consider the AF identifier, whether the "tscaiInputUl" and/or "tscaiInputDl" attributes within the "tscQosReq" attribute were received in the subscription request, and whether the "qosReference" attribute or individual QoS parameters within the "tscQosReq" attribute were received in the subscription request. A TSCTSF address may be locally configured in the NEF or the NEF uses the DNN/S-NSSAI (which may be provided in the request or determined based on the AF identifier) to discover the TSCTSF from the NRF.

– if the "AltQosWithIndParams_5G" feature is supported, the AF may include:

– alternative service requirements that include individual QoS parameter sets within the "altQosReqs" attribute. Within the AlternativeServiceRequirementsData data structure, the AF shall include:

– a reference to the alternative individual QoS related parameter(s) included in this set within the "altQosParamSetRef" attribute; and

– at least one of the following:

– The guaranteed bandwidth in uplink within the "gbrUl" attribute and the guaranteed bandwidth in downlink within the "gbrDl" attribute;

– The Requested 5GS Delay within the "packetDelayBudget" attribute;

If the NEF authorizes the AF request, the NEF may provision the received QoS requirements and subscribe to event "QOS_NOTIF" to the TSCTSF by invoking the Ntsctsf_QoSandTSCAssistance_Create request as defined in 3GPP TS 29.565 [50]. The NEF determines whether to invoke the TSCTSF or to directly contact the PCF based on operator configuration. This determination may consider the AF identifier, whether the "tscaiInputUl" and/or "tscaiInputDl" attributes within the "tscQosReq" attribute were received in the subscription request, and whether the "qosReference" attribute or individual QoS parameters within the "altQosReqs" attribute were received in the subscription request. A TSCTSF address may be locally configured in the NEF or the NEF uses the DNN/S-NSSAI (which may be provided in the request or determined based on the AF identifier) to discover the TSCTSF from the NRF. When the NEF receives the notification of TSCTSF event "QOS_NOTIF", it shall notify the AF with "QOS_GUARANTEED" event or "QOS_NOT_GUARANTEED" event with the currently applied individual QoS parameter set within the "appliedQosRef" attribute if received. When the NEF receives the notification of the TSCTSF event "SUCCESSFUL_RESOURCES_ALLOCATION", it shall notify the AF the event together with the currently applied individual QoS parameter set within the "appliedQosRef" attribute if received.

– If the "eNB_5G" feature is supported, the AF may additionally subscribe the event(s) "ACCESS_TYPE_CHANGE" and/or "PLMN_CHG". If the NEF authorizes the AF request, the NEF shall subscribe the event(s) at the PCF by invoking the Npcf_PolicyAuthorization service operation.

4.4.10 Procedures for MSISDN-less Mobile Originated SMS

The procedures are used by the NEF to send the MSISDN-less MO-SMS to the AF in 5GS are described in clause 4.4.14 of 3GPP TS 29.122 [4] with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– the NEF shall interact with UDM by using Nudm_SubscriberDataManagement service (as defined in 3GPP TS 29.503 [17]) to retrieve the external identifier; and

– the NEF may receive an MSISDN-less MO-SMS via SM11 including a destination SME address (long/short code of the AF) upon the SMS-SC invoking Nnef_SMService.

4.4.11 Procedures for Network Configuration Parameters Provisioning

The procedures for network configuration parameters provisioning as described in clause 4.4.12 of 3GPP TS 29.122 [4] shall be applicable in 5GS with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the HSS applies to the UDM;

– the NEF shall interact with the UDM by using Nudm_ParameterProvision service as specified in 3GPP TS 29.503 [17]; and

– if the "UEId_retrieval" feature defined in clause 5.13.4 of 3GPP TS 29.122 [4] is supported, in order to support the AF specific UE ID retrieval:

2)the AF may also provide the DNN in the "dnn" attribute and/or the S-NSSAI as "snssai" attribute within the NpConfiguration data type;

3)upon reception of the corresponding request message from the AF:

4)the NEF shall then interact with the BSF with the UE address and IP domain (if the UE IPv4 address is provided), DNN and/or S-NSSAI to retrieve the session binding information of the UE by invoking the Nbsf_Management_Discovery service operation as described in 3GPP TS 29.521 [9].

NOTE: The case where UE IP address provided by the AF to the NEF corresponds to an IP address that has been NATed (Network and Port Address Translation) is not supported in this release.

Editor’s note: Whether and how user’s consent is needed is FFS and pending SA6 and SA3 feedback.

4.4.12 Procedures for Non-IP data delivery

4.4.12.1 General

The procedures are used by the NEF to send/receive the non-IP data to/from the AF. It comprises NIDD configuration and NIDD delivery.

The NIDD configuration may be triggered by the NEF or the AF. If it is triggered by the NEF, the NiddConfigurationTrigger API described in clause 5.5 is used and the procedure is described in clause 4.4.12.2.

4.4.12.2 NIDD configuration Triggered by the NEF

If the NEF receives a NIDD connection establishment request from the SMF and if there is no NIDD configuration for the UE, the NEF may send a NIDD configuration trigger to the AF. The NEF determines the destination URI by local configuration. The NEF shall send to the determined destination URL an HTTP POST request that shall include a NiddConfiguarationTrigger data type with:

– the NEF identifier,

– the AF identifier, and

– GPSI as UE identity.

The AF shall acknowledge the HTTP POST request with an HTTP 200 OK response. Then the AF may start NIDD configuration procedure as described in clause 4.4.12.3.

4.4.12.3 NIDD configuration triggered by the AF and NIDD delivery

The procedures for NIDD configuration triggered by the AF and NIDD delivery are described in clause 4.4.5 of 3GPP TS 29.122 [4] with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the MME/SGSN applies to the SMF;

– for the connection establishment, the interaction between the NEF and the SMF shall use Nnef_SMContext service as specified in 3GPP TS 29.541 [24];

– for MO NIDD, the interaction between the SMF and the NEF shall use Nnef_SMContext service as specified in 3GPP TS 29.541 [24]; and

– for MT NIDD, the interaction between the SMF and the NEF shall use Nsmf_NIDD service as specified in 3GPP TS 29.542 [25].

4.4.13 Procedures for RACS Parameter Provisioning

The procedures for RACS parameter provisioning as described in clause 4.4.15 of 3GPP TS 29.122 [4] shall be applicable in 5G with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF.

4.4.14 Procedures for analytics information exposure

4.4.14.1 Subscription/unsubscription to notification of analytics information

The procedures are used by the AF to subscribe/unsubscribe to retrieve analytics information via NEF, and are used by the NEF to notify the AF about the requested analytics information as described in 3GPP TS 23.288 [29].

In order to subscribe to retrieve analytics information, the AF shall send an HTTP POST message to the NEF to the resource "Analytics Exposure Subscriptions", the HTTP POST request message body shall include the AnalyticsExposureSubsc data structure that shall include:

– the URI where to receive the requested notifications as "notifUri" attribute;

– the Notification Correlation Identifier assigned by the NF service consumer for the requested notifications as "notifId" attribute; and

– a description of the subscribed events as "analyEventsSubs" attribute that shall include for each event:

1) an event identifier as "analyEvent" attribute.

The AnalyticsExposureSubsc data structure may include:

– event reporting requirement information as "analyRepInfo" attribute, which applies for all events in a subscription and may contain the following attributes:

1) event notification method (periodic, one time, on event detection) as "notifMethod" attribute;

2) maximum Number of Reports as "maxReportNbr" attribute;

3) monitoring Duration as "monDur" attribute;

4) repetition period for periodic reporting as "repPeriod" attribute;

5) immediate reporting indication as "immRep" attribute;

6) sampling ratio as "sampRatio" attribute;

7) group reporting guard time as "grpRepTime" attribute;

8) partitioning criteria for partitioning the impacted UEs before performing sampling as "partitionCriteria" attribute if the "EneNA" feature is supported; and

9) a notification flag (used for muting and retrieving notifications) as "notifFlag" attribute if the "EneNA" feature is supported.

Each AnalyticsEventSubsc data structure may include:

– event specific filters via the "analyEventFilter" attribute; and

– the indication of the UEs to which the subscription applies via "tgtUe" attribute, which if provided shall include one of the following attributes:

1) identification of an individual UE via a "gpsi" attribute;

2) identification of a group of UE(s) via a "exterGroupId" attribute; or

3) identification of any UE via the "anyUeInd" attribute.

Upon receipt of the HTTP POST request from the AF, if the AF is authorized, the NEF shall interact with the UDM by using Nudm_SubscriberDataManagement service as defined in 3GPP TS 29.503 [17] to translate the GPSI or external group identifier into the corresponding SUPI or internal group identifier. After receiving a successful response from the UDM, the NEF may perform further mappings and translations (e.g. map application identifiers to DNN and S-NSSAI information, or translate attributes of data type NetworkAreaInfo to attributes of data type LocationArea5G) and it shall interact with the NWDAF to subscribe to the subscription to the analytics information by using the Nnwdaf_EventsSubscription service as defined in 3GPP TS 29.520 [27]. If the NEF receives an error responsefrom the NWDAF, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

In order to update an existing analytics exposure subscription, the AF shall send an HTTP PUT message to the NEF to the resource "Individual Analytics Exposure Subscription" requesting to change the subscription.

In order to delete an existing analytics exposure subscription, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual Analytics Exposure Subscription".

Upon receipt of the HTTP PUT or DELETE request from the AF, if the AF is authorized, the NEF may perform further mappings and translations (e.g. map application identifiers to DNN and S-NSSAI information, or translate attributes of data type LocationArea5G to attributes of data type NetworkAreaInfo as required by the data model) and it shall interact with the NWDAF to modify or cancel the subscription to the analytics information by using the Nnwdaf_EventsSubscription service as defined in 3GPP TS 29.520 [27]. If the NEF receives an error responsefrom the NWDAF, the NEF shall not update or delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the NWDAF, the NEF shall:

– for the HTTP POST request, create a resource "Individual Analytics Exposure Subscription" which represents the analytics exposure subscription, addressed by a URI that contains the AF Identifier and an NEF-created subscription identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this analytics exposure subscription. If not all the requested analytics events in the subscription are accepted, then the NEF may include the "failEventReports" attribute indicating the event(s) for which the subscription failed and the associated reason(s):

– for the HTTP PUT request, update a resource "Individual Analytics Exposure Subscription" which represents the analytics exposure subscription, and shall responds to the AF with a 200 OK or 204 No Content status code. When responding with a 200 OK status code, if not all the requested analytics events in the subscription are modified successfully, then the NEF may include the "failEventReports" attribute indicating the event(s) for which the modification failed and the associated reason(s); and

– for the HTTP DELETE request, remove all properties of the resource and delete the corresponding active resource "Individual Analytics Exposure Subscription" which represents the analytics exposure subscription, then shall responds to the AF with a 204 No Content status code.

If the immediate reporting indication in the "immRep" attribute within the "analyRepInfo" attribute sets to true during the HTTP POST or PUT request, the NEF shall also include the reports of the events subscribed, if available, in the HTTP POST or PUT response to the AF.

If the NEF receives an analytics information notification from the NWDAF indicating that the subscribed analytics event has been detected, the NEF may perform further mappings and translations (e.g. translate attributes of data type NetworkAreaInfo to attributes of data type LocationArea5G as required by the data model), it may determine based on local configuration to hide from the Untrusted AF network internal information (e.g. DNN, S-NSSAI) which was included in the NWDAF notification, and it shall provide a notification by sending HTTP POST message that include the AnalyticsEventNotification data structure at least with the detected analytics event to the AF identified by the notification URI together with the notification correlation identifier received during creation/modification of the Individual Analytics Exposure Subscription. Upon receipt of the analytics event notification, the AF shall respond with a "204 No Content" status code to confirm the received notification.

When the "notifFlag" attribute is included during the creation of a subscription (HTTP POST request) and set to "DEACTIVATE", the NEF shall mute the event notification and store the available events.

When the "notifFlag" attribute is included during the update of a subscription (HTTP PUT request) and set to "DEACTIVATE", the NEF shall mute the event notification and store the available events; if it is set to the value "RETRIEVAL", the NEF shall send the stored events to the NF service consumer, mute the event notification again and store available events; if it is set to the value "ACTIVATE" and the event notifications are muted (due to a previously received "DECATIVATE" value), the NWDAF shall unmute the event notification, i.e. start sending again notifications for available events.

4.4.14.2 Fetch analytics information

The procedures are used by the AF to fetch analytics information via NEF.

In order to fetch analytics information, the AF shall send an HTTP POST request message to the NEF targetingthe custom operation URI "{apiRoot}/3gpp-analyticsexposure/v1/{afId}/fetch", the HTTP POST request message body shall include the AnalyticsRequest data structure that shall include:

– the identification of the analytics events, encoded within the "analyEvent" attribute;

and may include:

– the description of the analytics reporting information, encoded within the "analyRep" attribute;

– an event filter, encoded within the "analyEventFilter" attribute.

– the indication of the UEs to which the analytics request applies via either:

a) the identification of an individual UE via the "gpsi" attribute;

b) the identification of a group of UE(s) via the "exterGroupId" attribute; or

c) the identification of any UE via the "anyUeInd" attribute.

Upon the reception of an HTTP POST request, if the AF is authorized, the NEF shall interact with the UDM by using Nudm_SubscriberDataManagement service as defined in 3GPP TS 29.503 [17] to translate the GPSI or external group identifier into the corresponding SUPI or internal group identifier. After receiving a successful response from the UDM, the NEF may perform further mappings and translations (e.g. map application identifiers to DNN and S-NSSAI information, or translate attributes of data type NetworkAreaInfo to attributes of data type LocationArea5G) and it shall interact with the NWDAF by using Nnwdaf_AnalyticsInfo service as defined in 3GPP TS 29.520 [27]. If the NEF receives an error responsefrom the NWDAF, the NEF shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable. If a successful response including analytics information is received from the NWDAF, the NEF shall translate the network internal information to external information (e.g. SUPI to GPSI, Internal Group ID to External Group ID, attributes of data type NetworkAreaInfo to attributes of data type LocationArea5G), it may determine based on local configuration to hide from the Untrusted AF network internal information (e.g. DNN, S-NSSAI) which was included in the NWDAF response, and it shall send an HTTP POST response to the AF by including analytics information within the AnalyticsData data structure.

4.4.15 Procedures for 5G LAN Parameter Provisioning

4.4.15.1 General

The procedures are used by the AF to provision 5G LAN type service related parameters to the NEF. The following procedures support:

– Management of 5G Virtual Network group membership; and/or

– Management of 5G Virtual Network group data

4.4.15.2 Creation of a new subscription for 5G LAN parameter provisioning

In order to create a new subscription to provision 5G LAN related parameters, the AF shall initiate an HTTP POST request to the NEF for the "5GLAN Parameters Provision Subscriptions" resource. The body of the HTTP POST message shall include the 5G LAN service related parameters within the "5gLanParams" attribute.

Upon receipt of the corresponding HTTP POST message, if the AF is authorized by the NEF to provision the parameters, the NEF shall interact with the UDM to create a subscription at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall create a new subscription and assign a subscription identifier for the "Individual 5GLAN Parameters Provision Subscription" resource. Then the NEF shall send a HTTP "201 Created" response with 5GLanParametersProvision data structure as response body and a Location header field containing the URI of the created individual subscription resource.

4.4.15.3 Modification of an existing subscription for 5G LAN parameter provisioning

To modify an existing subscription to provision 5G LAN parameters, the AF shall initiate an HTTP PUT/PATCH request to the NEF for the "Individual 5GLAN Parameters Provision Subscription" resource. The body of the HTTP PUT message shall include the 5GLanParametersProvision data type as defined in clause 5.7.2.3.2. The External Group Identifier, DNN, S-NSSAI and PDU session type(s) shall remain unchanged from previous values. The body of the HTTP PATCH message shall include the 5GLanParametersProvisionPatch data as defined in clause 5.7.2.3.5.

Upon receipt of the corresponding HTTP PUT/PATCH message, if the AF is authorized by the NEF to provision the parameters, the NEF shall interact with the UDM to modify an existing subscription at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the modification request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall update the existing subscription for the "Individual 5GLAN Parameters Provision Subscription" resource. Then the NEF shall send a HTTP response including "200 OK" status code with 5GLanParametersProvision data structure or "204 No Content" status code.

4.4.15.4 Deletion of an existing subscription for 5G LAN parameter provisioning

To delete an existing subscription to 5GLAN provision parameters, the AF shall initiate an HTTP DELETE request to the NEF for the "Individual 5GLAN Parameters Provision Subscription" resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized, the NEF shall interact with the UDM to delete an existing parameters provision subscription at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM and informs the NEF with a successful response, the NEF shall delete the existing subscription for the "Individual 5GLAN Parameters Provision Subscription" resource. Then the NEF shall send a HTTP "204 No Content" response.

4.4.16 Procedures for applying BDT policy

In order to create a resource for the applying a previously negotiated Background Data Transfer Policy to a UE or a Group of UEs, the AF shall send an HTTP POST message to the NEF to the resource "Applied BDT Policy Subscriptions". The body of the HTTP POST message shall contain the external Group Identifier or external Identifier, and the Background Data Transfer Reference ID for a previously negotiated policy of a background data transfer.

Upon receipt of the HTTP POST request from the AF, if the AF is authorized, the NEF shall interact with the UDM by invoking the Nudm_SubscriberDataManagement service as described in 3GPP TS 29.503 [17] to retrieve the SUPI or Internal Group Identifier.

In order to update an existing applied BDT policy subscription, the AF shall send an HTTP PATCH message to the resource "Individual Applied BDT Policy Subscription" requesting to change the applied BDT policy. The AF shall include in the body of the HTTP PATCH request the new Background Data Transfer Reference ID.

In order to delete an existing applied BDT policy subscription, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual Applied BDT Policy Subscription".

The NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20], if the NEF receives an error responsefrom the UDR, the NEF shall not create, update or delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall:

– for the HTTP POST request, create a resource "Individual Applied BDT Policy Subscription" addressed by a URI that contains the AF Identifier and an NEF-created subscription identifier, and shall respond to the AF with a "201 Created" status code, including a Location header field containing the URI of the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this resource;

– for the HTTP PATCH request, update a resource "Individual Applied BDT Policy Subscription" which represents the applied BDT policy subscription, and shall respond to the AF with a "200 OK" or "204 No Content" status code; and

– for the HTTP DELETE request, delete the corresponding active resource "Individual Applied BDT Policy Subscription", and shall respond to the AF with a "204 No Content" status code.

4.4.17 Procedures for Enhanced Coverage Restriction Control

The procedures for network configuration parameters provisioning as described in clause 4.4.11 of 3GPP TS 29.122 [4] shall be applicable in 5GS with the following differences:

– description of the SCS/AS applies to the AF;

– description of the SCEF applies to the NEF;

– description of the HSS applies to the UDM; and

– upon receipt of HTTP POST request from the AF to query the current status of enhanced coverage restriction, the NEF shall interact with the UDM by using the Nudm_SubscriberDataManagement service as specified in 3GPP TS 29.503 [17].

– upon receipt of HTTP POST request from the AF to configure the enhanced converage restriction, the NEF shall interact with the UDM by using the Nudm_ParameterProvision service as specified in 3GPP TS 29.503 [17].

– if the ECR_WB_5G feature is supported, in order to configure the enhanced coverage restriction for WB UE, the HTTP POST request message shall include the WB mode related enhanced coverage restriction information via the "ecrDataWbs" attribute for the WB UE.

4.4.18 Procedures for IPTV Configuration

The procedures are used by the AF to authorize the request and forward the request for IPTV configuration information via NEF.

In order to configure IPTV information, the AF shall send an HTTP POST message to the NEF to the resource "IPTV Configurations", the HTTP POST request message body shall include the IptvConfigData data structure that shall include:

– indication of the UEs to which the subscription applies via:

a) identification of an individual UE via a "gpsi" attribute; or

b) identification of a group of UE(s) via a "exterGroupId" attribute;

– an application identifier as "appId" attribute; and

– a list of Multicast Access Control as "multiAccCtrls" attribute;

and may include:

– an DNN as "dnn" attribute;

– an S-NSSAI as "snssai" attribute; and

– MTC Provider Information as "mtcProviderId" attribute.

NOTE: The NEF can check the received MTC Provider Id information and reject the IPTV configuration request upon failure checking result.

In order to update an existing individual IPTV configuration, the AF shall send an HTTP PUT or HTTP PATCH message to the NEF to the resource "Individual IPTV Configuration" requesting to change the subscription. The External Group Identifier, GPSI, DNN, S-NSSAI and Application Identifier shall remain unchanged from previous values in the HTTP PUT message.

In order to delete an existing individual IPTV configuration, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual IPTV Configuration".

Upon receipt of the HTTP request from the AF, if the AF is authorized, the NEF shall interact with the UDM by invoking the Nudm_SubscriberDataManagement service as described in 3GPP TS 29.503 [17] to retrieve the SUPI or Internal Group Identifier. Then the NEF shall interact with the UDR to create, update or delete the IPTV configuration by using the Nudr_DataRepository service as defined in 3GPP TS 29.519 [23]. If the NEF receives an error responsefrom the UDR, the NEF shall not create, update or delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall:

– for the HTTP POST request, create a resource "Individual IPTV Configuration" which represents the IPTV configuration request, addressed by a URI that contains the AF Identifier and an NEF-created configuration identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this IPTV configuration.

– for the HTTP PUT or HTTP PATCH request, update a resource "Individual IPTV Configuration" which represents the IPTV configuration, and shall responds to the AF with a 200 OK or 204 No Content status code; and

– for the HTTP DELETE request, remove all properties of the resource and delete the corresponding active resource "Individual IPTV Configuration", then shall responds to the AF with a 204 No Content status code.

4.4.19 Procedures for Location Privacy Indication Parameters Provisioning

The procedures are used by the AF to provision Location Privacy Indication parameters to the NEF. The procedures are applicable for an individual UE or a group of UEs.

In order to provision Location Privacy Indication parameters, the AF shall initiate an HTTP POST request to the NEF for the "LPI Parameters Provisionings" resource. The body of the HTTP POST message shall include the Location Privacy Indication related parameters within the LpiParametersProvision data structure.

Upon receipt of the corresponding HTTP POST message, if the AF is authorized by the NEF to provision the parameters, the NEF shall interact with the UDM to create a resource at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall create a new resource and assign an identifier for the "Individual LPI Parameters Provisioning" resource. Then the NEF shall send a HTTP "201 Created" response with LpiParametersProvision data structure as response body and a Location header field containing the URI of the created individual resource.

In order to update an existing individual LPI Parameters Provisioning, the AF may send an HTTP PUT message to the resource " Individual LPI Parameters Provisioning" requesting the NEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include LpiParametersProvision data type as defined in clause 5.10.2.3.2. The External Group Identifier or GPSI shall remain unchanged from previous values.

If the "PatchUpdate" feature defined in clause 5.10.3 is supported, in order to partially modify an existing LPI Parameters Provisioning resource, the AF may send an HTTP PATCH request message to the NEF on the "Individual LPI Parameters Provisioning" resource, with the request body containing the LpiParametersProvisionPatch data structure including only the attributes that shall be updated.

Upon receipt of the corresponding HTTP PUT/PATCH request message, if the AF is authorized by the NEF to provision the parameters, the NEF shall interact with the UDM to modify an existing resource at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the modification request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall update the existing resource for the "Individual LPI Parameters Provisioning" resource. Then the NEF shall send a HTTP response including "200 OK" status code with LpiParametersProvision data structure or "204 No Content" status code.

To delete an existing individual LPI Parameters Provisioning, the AF shall initiate an HTTP DELETE request to the NEF for the "Individual LPI Parameters Provisioning" resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized, the NEF shall interact with the UDM to delete an existing LPI Parameters Provisioning at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM, the NEF shall delete the existing resource for the "Individual LPI Parameters Provisioning" resource. Then the NEF shall send a HTTP "204 No Content" response.

4.4.20 Procedures for service specific parameter provisioning

These procedures are used by an AF to provide service specific parameters to the 5G system via the NEF.

In order to provision service specific parameters to the 5G system, the AF shall send an HTTP POST message to the NEF targetting the resource "Service Parameter Subscriptions", the HTTP POST request message body shall include the ServiceParameterData data structure that shall include:

– service description via:

a) a combination of DNN and S-NSSAI within the "dnn" attribute and the "snssai" attribute respectively;

b) an AF Service Identifier within the "afServiceId" attribute; or

c) an application identifier within the "appId" attribute;

NOTE: When the feature "AfGuideURSP" is supported, the DNN, S-NSSAI and/or Application Identifier information can be provided in the "urspGuidance" attribute, hence only the "afServiceId" attribute needs to be included for providing guidance for URSP determination.

– indication of the UEs to which the subscription applies via:

a) identification of an individual UE within the "gpsi" attribute;

b) an IPv4 address of the UE within the "ueIpv4" attribute;

c) an IPv6 address of the UE within the "ueIpv6" attribute;

d) a MAC address of the UE within the "ueMac" attribute;

e) an identification of a group of UE(s) within the "exterGroupId" attribute; or

f) an identification of any UE within the "anyUeInd" attribute; and

– service parameters for at least one of the following:

1)V2X service parameters via:

a) configuration parameters for V2X communications over PC5 within the "paramOverPc5" attribute; and

b) configuration parameters for V2X communications over Uu within the "paramOverUu" attribute;

2)if the "ProSe" feature is supported, 5G ProSe service parameters via:

a) configuration parameters for 5G ProSe direct discovery within the "paramForProSeDd" attribute;

b) configuration parameters for 5G ProSe direct communication within the "paramForProSeDc" attribute; and

c) configuration parameters for 5G ProSe UE-to-network relay, including configuration parameters for 5G ProSe UE-to-network relay UE within the "paramForProSeU2NRelUe" attribute and configuration parameters for 5G ProSe remote UE within the "ParamForProSeRemUe" attribute; and

3)if the "AfGuideURSP" feature is supported, URSP service parameters via:

a) contents for the AF guidance on URSP within the "urspGuidance" attribute, which shall include one or more URSP rule requests. Each URSP rule request may include a traffic descriptor within the "trafficDesc" attribute, a relative precedence within the "relatPrecedence" attribute and/or one or more route selection parameter sets within the "routeSelParamSets" attribute. Each route selection parameter set may include a precedence value within the "precedence" attribute, a DNN within the "dnn" attribute, an S-NSSAI within the "snssai" attribute, and a spatial validity condition within the "spatialValidity" attribute. If the request contains only one route selection parameter set, each of the optional attributes "dnn", "snssai", "precedence", and "spatialValidity" that is missing from the request may be complemented by the NEF based on local configuration for the provided AF service identifier. It is up to the NEF to transform the information of the "spatialValidity" attribute into a list of TAIs;

and may include:

– if the "AfNotifications" feature is supported:

a) subscription to event notification of the outcome related to invocation of service parameter provisioning within the "subNotifEvents" attribute; and

b) notification URI within the "notificationDestination" attribute.

In order to update an existing service parameter subscription, the AF shall send an HTTP PUT or HTTP PATCH message to the NEF targetting the resource "Individual Service Parameter Subscription" and requesting to change the subscription.

In order to delete an existing service parameter subscription, the AF shall send an HTTP DELETE message to the NEF targetting the resource "Individual Service Parameter Subscription".

Upon receipt of the HTTP request from the AF, and if the AF is authorized, the NEF shall interact with the UDM by invoking the Nudm_SubscriberDataManagement service as described in 3GPP TS 29.503 [17] to retrieve the SUPI or Internal Group Identifier. NEF may, based on local configuration, complement missing service parameters. Additionally, based on operator’s local policy, NEF may support service specific authorization as described in clause 4.15.6.10 in 3GPP TS 23.502 [2]. Then the NEF shall interact with the UDR to create, update or delete the associated service parameters by using the Nudr_DataRepository service as defined in 3GPP TS 29.519 [23]. If information related to AfNotifications feature are received from the AF, the NEF shall also include the required information (e.g. "policDelivNotifUri" and "policDelivNotifCorreId" attributes in 3GPP TS 29.519 [23]) in UDR data creation if the NEF supports the DeliveryOutcome feature (as described in 3GPP TS 29.504 [4]). If the NEF receives an error responsefrom the UDR, the NEF shall not create, update or delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall:

– for an HTTP POST request, create an "Individual Service Parameter Subscription" resource which represents the Service Parameter provisioning request, addressed by a URI that contains the AF Identifier and a NEF-created configuration identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this Service Parameter Subscription;

– for an HTTP PUT or HTTP PATCH request, update the "Individual Service Parameter Subscription" resource which represents the service parameter provisioning request, and respond to the AF with a 200 OK or 204 No Content status code; and

– for an HTTP DELETE request, remove all properties of the resource and delete the corresponding active "Individual Service Parameter Subscription" resource, then respond to the AF with a 204 No Content status code.

When the NEF receives the Service Specific Authorization Update information from the UDM by Nudm_ServiceSpecificAuthorization_UpdateNotify service operation defined in 3GPP TS 29.503 [17], if the authorization is revoked, the NEF shall provide a notification to AF by sending HTTP POST message that include the one or more AfNotification data structure(s). Upon receipt of the notification, the AF shall respond with a "204 No Content" status code to confirm the received notification.

When the NEF receives the notification of the outcome of invocation related to AF provisioned service parameters from the PCF by Npcf_EventExposure_Notify service operation defined in 3GPP TS 29.523 [22], the NEF shall determine the corresponding service parameter subscription and provide a notification to AF by sending HTTP POST message that include the AfNotification data structure. Upon receipt of the notification, the AF shall respond with a "204 No Content" status code to confirm the received notification.

4.4.21 Procedures for ACS configuration parameter provisioning

The procedures are used by the AF to provide ACS configuration information to 5G system via NEF.

In order to provision the ACS configuration information, the AF shall send an HTTP POST message to the NEF to the resource "ACS Configuration Subscriptions", the HTTP POST message shall include AcsConfigurationData data structure as request body. The AcsConfigurationData data structure shall include:

– the URL of the ACS or the address of the ACS within the "acsInfo" attribute; and

– indication of the UEs to which the subscription applies via:

a) identification of an individual UE via a "gpsi" attribute; or

b) identification of a group of UE(s) via a "exterGroupId" attribute.

In order to update an existing ACS configuration subscription, the AF shall send an HTTP PUT message to the NEF to the resource "Individual ACS Configuration Subscription" requesting to change the subscription. The body of the HTTP PUT request message shall include AcsConfigurationData data type. The External Group Identifier or GPSI shall remain unchanged from previous values.

If the "PatchUpdate" feature defined in clause 5.12.3 is supported, in order to partially modify an existing ACS Configuration subscription, the AF shall send an HTTP PATCH request message to the NEF on the "Individual ACS Configuration Subscription" resource, with the request body containing the AcsConfigurationDataPatch data structure including only the attributes that shall be modified.

In order to delete an existing ACS configuration subscription, the AF shall send an HTTP DELETE message to the NEF to the resource "Individual ACS configuration Subscription".

Upon receipt of the corresponding HTTP message, if the AF is authorized by the NEF to provision the parameters, the NEF shall interact with the UDM to create a subscription at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17].

After receiving a successful response from the UDM, the NEF shall,

– for the HTTP POST request, create a resource "Individual ACS Configuration Subscription" which represents the ACS configuration parameter provisioning request, addressed by a URI that contains the AF Identifier and an NEF-created configuration identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this ACS Configuration Subscription.

– for the HTTP PUT/PATCH request, update/modify the concerned "Individual ACS Configuration Subscription" resource which represents the ACS configuration, and shall responds to the AF with an HTTP "200 OK" or an HTTP "204 No Content" status code.

– for the HTTP DELETE request, remove all properties of the resource and delete the corresponding active resource "Individual ACS Configuration Subscription", then shall responds to the AF with a 204 No Content status code.

4.4.22 Procedures for Mobile Originated Location Request

4.4.22.1 General

The procedure is used by NEF to transfer the updated UE location information to AF. The following procedure support:

– Notify the AF of the updated UE location information as described in clause 6.2 of 3GPP TS 23.273 [36];

4.4.22.2 Location Update Notification triggered by UE

In order to notify the AF of the updated UE location information received from GMLC, the NEF shall initiate an HTTP POST request to the AF. The body of the HTTP POST message shall include the location information related to UE MO-LR within the LocUpdateData data structure.

Upon receipt of the corresponding HTTP POST message, if the AF cannot handle the location estimate of the UE, e.g. the UE does not register to the AF, the AF shall respond to the NEF with an error code. Otherwise, the AF shall handle the location estimate according to the Service Identity if provided, and send a HTTP response including "200 OK" status code with LocUpdateDataReply data structure.

4.4.23 Procedures for AKMA

4.4.23.1 General

The procedures support:

– request AKMA application key by the AF to the AAnF via the NEF as described in clause 6.3 of 3GPP TS 33.535 [37];

4.4.23.2 AKMA Application Key Request

In order to retrieve the AKMA application key, the AF shall send an HTTP POST request message to the resource URI "{apiRoot}/3gpp-akma/v1/retrieve". The HTTP POST request includes the identification of AF and an A-KID.

Upon receipt of the corresponding HTTP POST message from the AF, if the AF’s request is authorized by the NEF, then the NEF shall interact with the AAnF to retrieve the AKMA application key by using Naanf_AKMA service as defined in 3GPP TS 29.535 [38]. After receiving a successful response from the AAnF, the NEF shall respond to the AF with a 200 OK status code, including a K_AF and the expiration time of the K_AF, and if "anonInd" attribute contained in AkmaAfKeyRequest data type is not set to "true" in the incoming request, optionally the GPSI (external ID) which may be translated from the SUPI received from the AAnF. The SUPI shall not be included in the response to the external AF. If the NEF receives an error responsefrom the AAnF, the NEF shall respond to the AF with a proper error status code.

If the NEF receives a response from the AAnF with an HTTP "403 Forbidden" status code and the response message body including a ProblemDetails data structure with the "cause" attribute set to the "K_AKMA_NOT_PRESENT" application error, then the NEF shall relay this response to the AF.

4.4.24 Procedures for Time Synchronization Exposure

4.4.24.0 General

Time synchronization exposure allows an AF to configure time synchronization in 5GS. For (g)PTP operation, the Time synchronization service allows an AF to subscribe to the UE and 5GC capabilities and availability for time synchronization service (as described in clause 4.4.24.1) and to configure the (g)PTP instance in 5GS as described in clause 4.4.24.2. For 5G access stratum based time distribution, the AF can influence the 5G access stratum time distribution as described in clause 4.4.24.3. The time synchronization exposure is provided by NEF that uses the service provided by TSCTSF. The AF that is part of operator’s trust domain may invoke the services directly with TSCTSF.

NOTE: The AF can use either the procedure for configuring the (g)PTP instance in 5GS as described in clause 4.4.24.2 or the procedure for controlling the 5G access stratum time distribution as described in clause 4.4.24.3 for a particular UE. The procedures are not intended to be used in conjunction with each other by the AF. However, the (g)PTP instance activation, modification, and deactivation can influence the 5G access stratum time distribution for the UEs that are part of the impacted PTP instance.

4.4.24.1 Subscription and unsubscription to notification of Time Synchronization Capabilites

The procedures are used by the AF to subscribe to notifications and to explicitly cancel a previous subscription to notification of capabilities of the time synchronization service for a list of UE(s), a group of UEs or any UE using a DNN/S-NSSAI combination via the NEF.

In order to subscribe to the notification of capabilities of UE and 5GC, and availability for the time synchronization service, the AF shall send an HTTP POST rmessage to the NEF to the customized operation URI "{apiRoot}/3gpp-time-sync/v1/{afId}/subscriptions". The HTTP POST request message body shall include the TimeSyncExposureSubsc data structure that shall include:

– one of the indication of the UEs to which the time synchronization capabilities is requested via:

1)identification of a list of individual UEs within a "gpsis" attribute;

2)indication of any UE within the "anyUeInd" attribute if DNN and S-NSSAI are provisioned; or

3)identification of a group of UE(s) via a "exterGroupId" attribute.

– subscription to event(s) notification as "subscribedEvents" attribute when the NF service consumer needs to subscribe to notifications;

– notification URI within the "subsNotifUri" attribute; and

– notification correlation Id within the "subsNotifId" attribute;

and may include:

– either the DNN within the "dnn" attribute and the "snssai" attribute or the AF Service Identifier within the "afServiceId" attribute;

– the requested event filter(s) within the "eventFilters" attribute;

– notification methods within the "notifMethod" attribute;

– maximum number of reports within the "maxReportNbr" attribute;

– expiry time within the "expiry" attribute; and

– report period within the "repPeriod" attribute.

Upon the reception of an HTTP POST request, if the AF is authorized, the NEF shall select a TSCTSF based on the local configuration or discover the TSCTSF via Nnrf_NFDiscovery service as defined in 3GPP TS 29.510 [57] for a DNN/S-NSSAI combination, if not configured. If the DNN and the S-NSSAI is omitted in the AF request, prior the TSCTSF discovery the NEF shall determine the corresponding DNN and S-NSSAI based on the received AF Service Identifier. After the NEF obtains the TSCTSF, the NEF shall invoke the Ntsctsf_TimeSynchronization_CapsSubscribe request service operation as defined in clause 5.2.2.2.2 of 3GPP TS 29.565 [50] to the selected TSCTSF. If the NEF receives an error responsefrom the TSCTSF, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

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

After receiving a successful response from the TSCTSF, the NEF shall create an "Individual Time Synchronization Exposure Subscription" resource which represents the time synchronization exposure subscription request, addressed by a URI that contains the AF Identifier and a NEF-created configuration identifier, and shall respond to the AF with a 201 Created status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header in subsequent requests to the NEF to refer to this "Individual Time Synchronization Exposure Subscription".

In order to update an existing subscription, the AF shall send an HTTP PUT message to the NEF targeting the resource "Individual Time Synchronization Exposure Subscription". The body of the HTTP PUT request message shall include the TimeSyncExposureSubsc data type. Upon receipt of the corresponding HTTP PUT message, if the AF is authorized by the NEF, the NEF shall interact with the TSCTSF by invoking Ntsctsf_TimeSynchronization_CapsSubscribe request service operation as defined in clause 5.2.2.2.3 of 3GPP TS 29.565 [50]. After receiving a successful response from the TSCTSF, the NEF shall update a resource "Individual Time Synchronization Exposure Subscription" which represents the exposure subscription, and responds to the AF with a 200 OK with TimeSyncExposureSubsc data structure or 204 No Content status code.

When the NEF receives the notification of the capabilities of the time synchronization service from the TSCTSF as defined in clause 5.2.2.4.2 of 3GPP TS 29.565 [50], the NEF shall provide a notification to AF by sending HTTP POST message that includes the TimeSyncExposureSubsNotif data structure in the request body. Upon receipt of the notification, the AF shall respond with a "204 No Content" status code to confirm the received notification.

In order to delete an existing subscription, the AF shall send an HTTP DELETE message to the NEF targeting the resource "Individual Time Synchronization Exposure Subscription". The NEF shall interact with the TSCTSF by invoking the Ntsctsf_TimeSynchronization_CapsUnsubscribe service operation as defined in clause 5.2.2.3.2 of 3GPP TS 29.565 [50] and delete the corresponding active "Individual Time Synchronization Exposure Subscription" resource, then respond to the AF with a 204 No Content status code.

4.4.24.2 Time Synchronization Exposure Configuration

The procedures are used by the AF to activate, modify or deactivate the (g)PTP instances by performing the time synchronization configuration at the NEF.

In order to configure the time synchronization parameters, the AF shall initiate an HTTP POST request to the NEF for the "Time Synchronization Exposure Configurations" resource. The body of the HTTP POST message shall include the Time Synchronization related parameters within the TimeSyncExposureConfig data structure.

Upon receipt of the corresponding HTTP POST message and the request is authorized by the NEF, the NEF invokes the Ntsctsf_TimeSynchronization_ConfigCreate service operation with the corresponding TSCTSF as defined in 3GPP TS 29.565 [50]. After receiving a successful response from the TSCTSF, the NEF shall create a new resource and assign an identifier for the "Individual Time Synchronization Exposure Configuration" resource. Then the NEF shall send a HTTP "201 Created" response with TimeSyncExposureConfig data structure as response body and a Location header field containing the URI of the created individual resource.

In order to update an existing Individual Time Synchronization Exposure Configuration, the AF may send an HTTP PUT message to the resource "Individual Time Synchronization Exposure Configuration" requesting the NEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include TimeSyncExposureConfig data type as defined in clause 5.15.4.3.6. The user plane node Id shall remain unchanged from previous values.

When the NEF receives the notification of the current state of time synchronization service configuration from the TSCSF by Ntsctsf_TimeSynchronization_ConfigUpdateNotify service operation defined in 3GPP TS 29.565 [50], the NEF shall provide a notification to AF by sending HTTP POST message that include the TimeSyncExposureConfigNotif data structure in the request body. Upon receipt of the notification, the AF shall respond with a "204 No Content" status code to confirm the received notification.

To delete an existing "Individual Time Synchronization Exposure Configuration", the AF shall initiate an HTTP DELETE request to the NEF for the "Individual Time Synchronization Exposure Subscription" resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized, the NEF shall interact with the TSCTSF to delete an existing Individual Time Synchronization Exposure Configuration at the TSCTSF by using Ntsctsf_TimeSynchronization_ConfigDelete service operation as defined in 3GPP TS 29.565 [50]. If the request is accepted by the TSCTSF, the NEF shall delete the existing resource for the "Individual Time Synchronization Exposure Configuration" resource. Then the NEF shall send a HTTP "204 No Content" response.

4.4.24.3 Management of 5G access stratum time distribution

The procedures are used by the AF to activate, update or delete the 5G access stratum time distribution for one UE or group of UEs.

In order to configure the 5G access stratum time distribution parameters, the AF shall initiate an HTTP POST request to the NEF for the "ASTI Configurations" resource. The body of the HTTP POST message shall include the 5G access stratum time distribution parameters within the AccessTimeDistributionData data structure as defined in clause 5.22.4.3.2.

Upon receipt of the corresponding HTTP POST message and the request is authorized by the NEF, the NEF shall select a TSCTSF based on the local configuration or discover the TSCTSF via Nnrf_NFDiscovery service as defined in 3GPP TS 29.510 [57] for the GPSI or external group identifier, if not configured. After the NEF obtains the TSCTSF, the NEF invokes the Ntsctsf_ASTI_Create service operation with the corresponding TSCTSF, if available, as defined in 3GPP TS 29.565 [50]. After receiving a successful response from the TSCTSF, the NEF shall create a new resource and assign an identifier for the "Individual ASTI Configuration" resource. Then the NEF shall send a HTTP "201 Created" response with AccessTimeDistributionData data structure as response body and a Location header field containing the URI of the created individual resource. If the NEF receives an error responsefrom the TSCTSF, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

In order to update an existing Individual ASTI Configuration, the AF may send an HTTP PUT message to the resource "Individual ASTI Configuration" requesting the NEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include the AccessTimeDistributionData data type.

Upon receipt of the corresponding HTTP PUT message and the request is authorized by the NEF, the NEF shall interact with the TSCTSF to modify an existing resource at the TSCTSF by using Ntsctsf__ASTI_Update service operation as defined in 3GPP TS 29.565 [50]. If the modification request is accepted by the TSCTSF and the TSCTSF informs the NEF with a successful response, the NEF shall update the existing resource for the "Individual ASTI Configuration" resource. Then the NEF shall send a HTTP response including "200 OK" status responsewith AccessTimeDistributionData data structure or "204 No Content" status code. If the NEF receives an error code from the TSCTSF, the NEF shall not update the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

To delete an existing Individual ASTI Configuration, the AF shall initiate an HTTP DELETE request to the NEF for the "Individual ASTI Configuration" resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized, the NEF shall interact with the TSCTSF to delete an existing Individual ASTI Configuration at the TSCTSF by using Ntsctsf_ASTI_Delete service operation as defined in 3GPP TS 29.565 [50]. If the request is accepted by the TSCTSF, the NEF shall delete the existing resource for the "Individual ASTI Configuration" resource. Then the NEF shall send a HTTP "204 No Content" response. If the NEF receives an error responsefrom the TSCTSF, the NEF shall not delete the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

AF may request and query the status of the access stratum time distribution sending the HTTP POST request, "retrieve" custom operation, to the resource"ASTI Configurations". The body of the HTTP POST request message shall include the StatusRequestData data type as defined in clause 5.22.4.3.3.

Upon receipt of the corresponding HTTP POST message, if the AF is authorized, the NEF shall interact with the TSCTSF by using Ntsctsf_ASTI_Get service operation as defined in 3GPP TS 29.565 [50]. Upon receipt of response from the TSCTSF, the NEF shall shall send a HTTP "200 OK" response with the StatusResponseData data structure as defined in clause 5.22.4.3.4 in the payload. If the NEF receives an error responsefrom the TSCTSF, the NEF shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.25 Procedures for ECS address Provisioning

The procedures are used by the AF to provision ECS address(es) to the NEF. The procedures are applicable for an individual UE or a group of UEs.

In order to create an Individual ECS Address Provision Configuration resource, the AF shall initiate an HTTP POST request to the NEF for the "ECS Address Provision Configurations" resource. The body of the HTTP POST message shall include within the EcsAddressProvision data structure the ECS address(es) via the "ecsServerAddr" attribute, may include the spatial validity condition via the "spatialValidityCond" attribute and target of UE information via the "tgtUe" attirbute. Upon receipt of the corresponding HTTP POST message, if the AF is authorized by the NEF to provision the ECS address(es), the NEF shall interact with the UDM to create a resource at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall create a new resource and assign an identifier for the "Individual ECS Address Provision Configuration" resource. Then the NEF shall send a HTTP "201 Created" response with EcsAddressProvision data structure as response body and a Location header field containing the URI of the created individual resource.

In order to update an existing Individual ECS Address Provision Configuration, the AF shall send an HTTP PUT message to the resource "Individual ECS Address Provision Configuration" requesting the NEF to change all properties in the existing resource. The body of the HTTP PUT request message shall include the EcsAddressProvision data type. Upon receipt of the corresponding HTTP PUT message, if the AF is authorized by the NEF to provision the ECS address(es), the NEF shall interact with the UDM to modify an existing resource at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the modification request is accepted by the UDM and the UDM informs the NEF with a successful response, the NEF shall update the existing resource for the "Individual ECS Address Provision Configuration" resource. Then the NEF shall send a HTTP response including "200 OK" status code with EcsAddressProvision data structure or "204 No Content" status code.

To delete an existing Individual ECS Address Provision Configuration, the AF shall initiate an HTTP DELETE request to the NEF for the "Individual ECS Address Provision Configuration" resource. Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized, the NEF shall interact with the UDM to delete the existing resource at the UDM by using Nudm_ParameterProvision service as defined in 3GPP TS 29.503 [17]. If the request is accepted by the UDM, the NEF shall delete the existing resource for the "Individual ECS Address Provision Configuration" resource. Then the NEF shall send a HTTP "204 No Content" response.

4.4.26 Procedures for AM Policy Authorization

4.4.26.1 General

The procedures are used by AF to send request to NEF for AM Policy Authorization, and for NEF to authorize an AF triggered AM Policy Authorization request and trigger a respective Npcf_AMPolicyAuthorization request. This service also allows the AF to subscribe/unsubscribe the notification of event(s) for the existing AF application AM context.

The following procedures support:

– Create/Modify/Delete of AF triggered application AM context; and

– Subscribe/Unsubscribe/Notify event(s) for the existing AF application AM context.

4.4.26.2 Creation of a new Individual Application AM Context

In order to create a new Individual application AM context resource for a given AF, the AF shall initiate an HTTP POST request to the NEF for the "Application AM Contexts" resource. The HTTP POST request message body shall include the AppAmContextExpData data structure that shall include:

– identification of an individual UE via a "gpsi" attribute;

and may include:

– subscription to AM policy event(s) notification as "evSubscs" attribute. For each subscribed event, the AF may include the description of the event reporting mode, as e.g. whether immediate reporting is required;

– a high throughput requirement Indication as "highThruInd" attribute;

– service coverage requirements as "covReqs" attribute; and

– policy duration requirement as "policyDuration" attribute.

Upon receipt of the corresponding HTTP POST message, if the AF is authorized by the NEF to request the AM policy authorization, the NEF shall trigger a respective Npcf_AMPolicyAuthorization_Create request as defined in 3GPP TS 29.534 [43]. If the request is accepted by the PCF and the PCF informs the NEF with a successful response, the NEF shall create a new "Individual application AM Context" and assign an application AM context identifier for the "Individual application AM Context" resource.

Then the NEF shall send a HTTP "201 Created" response with:

– AppAmContextExpRespData data structure as response body, including the created "Individual application AM Context" resource and, if immediate reporting was requested for the subscribed event(s), the currently available value(s), if received from the PCF; and

– a Location header field containing the URI of the created "Individual application AM Context" resource to the AF.

If the NEF receives an error responsefrom the PCF, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.26.3 Modification of an existing individual Application AM Context

In order to modify an existing individual Application AM Context resource, the AF shall initiate an HTTP PATCH request to the NEF for the "Individual application AM Context" resource. The body of the HTTP PATCH message shall include the AppAmContextExpUpdateData data type as defined in clause 5.17.1.3.3.3.

Upon receipt of the corresponding HTTP PATCH message, if the AF is authorized by the NEF to modify the AM policy authorization request, the NEF shall interact with the PCF to modify an existing application AM context by using Npcf_AMPolicyAuthorization_Update request as defined in 3GPP TS 29.534 [43]. If the modification request is accepted by the PCF and the PCF informs the NEF with a successful response, the NEF shall update the existing application AM context for the "Individual application AM Context" resource. Then the NEF shall send a HTTP response including "200 OK" status code with AppAmContextExpRespData data structure (including the updated resource representation and, if immediate reporting was requested for the new subscribed event(s), the currently available value(s), if received from the PCF) or "204 No Content" status code to the AF.

If the NEF receives an error responsefrom the PCF, the NEF shall not modify the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.26.4 Deletion of an existing individual Application AM Context

To delete an existing application AM context, the AF shall initiate an HTTP DELETE request to the NEF for the "Individual application AM Context" resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized to delete the application AM context, the NEF shall interact with the PCF to delete an existing application AM context at the PCF by using Npcf_AMPolicyAuthorization_Delete request as defined in 3GPP TS 29.534 [43]. If the request is accepted by the PCF and informs the NEF with a successful response, the NEF shall delete the existing application AM context for the "Individual application AM Context" resource. Then the NEF shall send a HTTP "204 No Content" response to the AF.

If the NEF receives an error responsefrom the PCF, the NEF shall take proper error handling action and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.26.5 Create or modify subscription to notification of AM policy event

In order to create or modify the subscription to notification of AM policy event(s) for the application AM context, the AF shall send an HTTP PUT message to the NEF to the sub-resource "AM Policy Events Subscription", the HTTP PUT message shall include the AmEventsSubscData data structure as request body.

Upon receipt of the HTTP request from the AF, if the AF is authorized, the NEF shall interact with the PCF to subscribe to, or modify the subscription to the AM policy event notification by using Npcf_AMPolicyAuthorization_Subscribe request as defined in 3GPP TS 29.534 [43]. If the request is accepted by the PCF and the PCF informs the NEF with a successful response, the NEF shall create a new AM policy event subscription sub-resource in an existing application AM context or modify an existing AM policy event subscription to the "AM Policy Events Subscription" sub-resource. Then the NEF shall send:

– for a subscription creation request, an HTTP "201 Created" response with:

a. AmEventsSubscRespData data structure as response body, including the created "AM Policy Events Subscription" resource and, if immediate reporting was requested for the subscribed event(s), the currently available value(s), if received from the PCF; and

b. a Location header field containing the URI of the created individual subscription resource to the AF; or

– for a subscription update request, an HTTP "200 OK" response code with AmEventsSubscRespData data structure with the updated "AM Policy Events Subscription" resource or HTTP "204 No Content" response code and, if immediate reporting was requested for the subscribed event(s), the currently available value(s), if received from the PCF;

as response body to the AF.

If the NEF receives an error responsefrom the PCF, the NEF shall not create or modify the sub-resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.26.6 Unsubscription to notification of AM policy event

In order to delete existing subscribed AM policy event(s) within the existing Individual application AM context, the AF shall initiate the HTTP DELETE request message to the NEF to the "AM Policy Events Subscription" sub-resource.

Upon receipt of the corresponding HTTP DELETE message, if the AF is authorized to delete the notification of AM policy event(s), the NEF shall interact with the PCF to delete an existing subscription of notification to AM policy event(s) within the existing application AM context at the PCF by using Npcf_AMPolicyAuthorization_Unsubscribe request as defined in 3GPP TS 29.534 [43]. If the request is accepted by the PCF and informs the NEF with a successful response, the NEF shall delete the existing subscription to notification of AM policy event(s) within the existing application AM context for the "AM Policy Events Subscription" resource. Then the NEF shall send a HTTP "204 No Content" response to the AF.

4.4.26.7 Notification of AM policy event

If the NEF receives an AM policy event notification from the PCF indicating that the subscribed AM policy event has been detected, the NEF shall provide a notification to AF by sending HTTP POST message that include the AmEventsNotification data structure in the request body. Upon receipt of the AM policy event notification, the AF shall respond with a "204 No Content" status code to confirm the received notification to the NEF.

4.4.27 Procedures for AF triggered Access and Mobility Influence

4.4.27.1 General

The procedures are used by the AF to provision the Access and Mobility(AM) policy related request via NEF to one or multiple UEs that may have already registered or not. This service also allows the NEF to send the notification of service area coverage outcome events to the AF.

4.4.27.2 Create the AM Influence Subscription

In order to create a resource for the AM Influence, the AF shall send an HTTP POST request message to the NEF for the "AM Influence Subscription" resource. The request message may include the AF Transaction Identifier, GPSI, DNN, S-NSSAI, External Group Identifier, list of application identifier(s), AF Service Identifier, throughput requirements, service area coverage requirements represented by list of geographical areas, policy duration, subscribed event(s) and the notification destination address.

The request may target one or multiple UEs that may have already registered or not. For an individual UE identified by GPSI, or a group of UEs identified by External Group Identifier, the NEF shall interact with the UDM by invoking the Nudm_SubscriberDataManagement service as described in 3GPP TS 29.503 [17] to retrieve the SUPI or Internal Group Identifier. For all UEs, the NEF will not interact with the UDM.

The NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] to store the policy data in the UDR.

If the NEF receives an error responsefrom the UDR, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall create a resource "Individual AM Influence Subscription", which represents the AM influence subscription, addressed by a URI that contains the AF Identifier and an NEF-created subscription identifier. The NEF shall respond to the AF with a "201 Created" status code, including a Location header field containing the URI for the created resource. The AF shall use the URI received in the Location header when it subsequently sends requests to the NEF to reference this AM influence subscription.

4.4.27.3 Modifiy the AM Influence Subscription

In order to update an existing AM influence subscription, the AF shall send an HTTP PUT or HTTP PATCH request message to the NEF for the "Individual AM Influence Subscription" resource. The NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] to update the policy data in the UDR.

If the NEF receives an error responsefrom the UDR, the NEF shall not update the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall update the "Individual AM Influence Subscription" resource which represents the AM influence subscription, and shall respond to the AF with an HTTP "200 OK" or "204 No Content" response message.

4.4.27.4 Delete the AM Influence Subscription

In order to delete an existing AM influence subscription, the AF shall send an HTTP DELETE request message to the NEF for the "Individual AM Influence Subscription" resource. The NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] to delete the policy data in the UDR. If the NEF receives an error responsefrom the UDR, the NEF shall take proper error handling actions and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

After receiving a successful response from the UDR, the NEF shall delete the "Individual AM Influence Subscription" resource which represents the AM influence subscription, and shall respond to the AF with an HTTP "204 No Content" response message.

4.4.27.5 Notification of service area coverage outcome events

When the NEF receives the notification of service area coverage outcome events from the PCF as defined in 3GPP TS 29.534 [43], the NEF shall provide a notification by sending an HTTP POST message to the AF. The HTTP POST message shall include the subscribed event (service area coverage outcome event) to the AF identified by the notification destination received during the creation/modification of the AM Influence resource.

Upon receipt of the event notification, the AF shall respond with a "204 No Content" status code to confirm the received event notification.

4.4.28 Procedures for Northbound EAS Deployment Information management

4.4.28.1 General

The procedures are used by AF to provide, update or delete EAS Deployment Information to NEF, and for NEF to authorize the AF provisioned EAS Deployment Information to be stored in the UDR.

The following procedures support:

– Create/Update/Delete the AF provisioned EAS Deployment information;

4.4.28.2 Creation of a new Individual EAS Deployment information resource

In order to create a new Individual EAS Deployment information resource for a given AF, the AF shall initiate an HTTP POST request to the NEF for the "EAS Deployment Information" resource. The HTTP POST request message body shall include the EasDeployInfo data structure that shall include:

– FQDN(s) of an application deployed in the Local part of the DN via an "fqdns" attribute;

and may include:

– an AF service identifier as the "afServiceId" attribute;

– an DNN as "dnn" attribute;

– an S-NSSAI as "snssai" attribute;

– an external Group Identifier as "exterGroupId" attribute;

– identification of an application as "appId" attribute; and

– list of DNS server identifier and/or IP address(s) of the EAS in the local DN for each DNAI as "dnaiInfos" attribute.

Upon receipt of the corresponding HTTP POST message, if the AF is authorized by the NEF to provide the EAS Deployment Information, the NEF shall interact with the UDM by using Nudm_SubscriberDataManagement service as defined in 3GPP TS 29.503 [17] to translate the external group identifier into the corresponding internal group identifier and the NEF may derive DNN and S-NSSAI from the AF Service Identifier if not received explicitly. Then the NEF shall interact with the UDR to create the associated EAS Deployment information by using the Nudr_DataRepository service as defined in 3GPP TS 29.504 [20]. If the request is accepted by the UDR and the UDR informs the NEF with a successful response, the NEF shall create a new "Individual EAS Deployment Information" resource. Then the NEF shall send a HTTP "201 Created" response with the EasDeployInfo data structure including the contents of the created EAS Deployment Information resource in theresponse body and a Location header field containing the URI of the created individual EAS Deployment Information resource. If the NEF receives an error responsefrom the UDR, the NEF shall not create the resource and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.28.3 Modification of an existing individual EAS Deployment Information resource

In order to modify an existing individual EAS Deployment Information resource, the AF shall initiate an HTTP PUT request to the "Individual EAS Deployment Information" resource. The request body shall include the EasDeployInfo data structure. The "afServiceId" value shall remain unchanged from the previous value, if available in the HTTP PUT message.

Upon receipt of the corresponding HTTP PUT request message, if the AF is authorized by the NEF to modify the existing individual EAS Deployment Information resource, the NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] to modify the EAS Deployment Information in the UDR.

If the modification request is accepted by the UDR and the UDR informs the NEF with a successful response, the NEF shall update the existing individual EAS Deployment Information resource. Then the NEF shall send a HTTP response including "200 OK" status code with EasDeployInfo data structure or "204 No Content" status code.

If the NEF receives an error responsefrom the UDR, the NEF shall not update the "Individual EAS Deployment Information" resource and shall respond a proper error status code to the AF. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.28.4 Deletion of an existing individual EAS Deployment Information resource

In order to delete an existing EAS Deployment Information, the AF shall send an HTTP DELETE request message to the NEF for the "Individual EAS Deployment Information" resource. The NEF shall interact with the UDR by invoking the Nudr_DataRepository service as described in 3GPP TS 29.504 [20] to delete the EAS Deployment Information in the application data in the UDR.

After receiving a successful response from the UDR, the NEF shall delete the "Individual EAS Deployment Information" resource and shall respond to the AF with an HTTP "204 No Content" response message.

If the NEF receives an error responsefrom the UDR, the NEF shall take proper error handling actions and shall respond to the AF with a proper error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.28.5 Deletion of EAS Deplyoment Information based on given criteria

In order to delete existing EAS Deployment Information resource(s) which match given attributes, the NF service consumer shall send an HTTP POST request with "{apiRoot}/3gpp-eas-deployment/<apiVersion>/remove-edis" as URI. The POST request body shall contain an EdiDeleteCriteria data structure. The EdiDeleteCriteria data structure provided in the request body shall include at least one of the following:

– an AF identifier within the "afId" attribute;

– DNN and slice information within the "dnnSnssai" attribute;

Upon the reception of this HTTP POST request, if the NF service consumer is authorized by the NEF to delete the EAS Deployment Information, the NEF shall determine the EAS Deployment Information resources that match the provided criteria and interact with the UDR to delete the associated EAS Deployment Information by using the Nudr_DataRepository service as defined in 3GPP TS 29.504 [20]. If the request is accepted by the UDR and the UDR informs the NEF with a successful response, the NEF shall send a HTTP "204 No Content" response. If the NEF receives an error code from the UDR, the NEF shall respond to the AF with a proper error status code.

4.4.29 Procedures for MBS Management

4.4.29.1 General

The procedures described in the clauses below are used by an AF to interact with the 5GC for MBS management as defined in 3GPP TS 23.247 [53] and 3GPP TS 26.502 [65], in order to carry out the following procedures:

– MBS TMGI management procedures.

– MBS Session management procedures.

– MBS User Service management procedures.

– MBS User Data Ingest Session management procedures.

4.4.29.2 Procedures for MBS TMGI management

4.4.29.2.1 General

The procedures described in the clauses below are used by an AF to request and manage TMGI(s) for MBS session(s) as defined in clause 7.1 of 3GPP TS 23.247 [53].

4.4.29.2.2 Procedure for MBS TMGI(s) allocation or MBS TMGI(s) expiry time refresh

This procedure is used by an AF to request the allocation of TMGI(s) for new MBS session(s) or the refresh of the expiry time of already allocated MBS TMGI(s).

In order to request the allocation of TMGI(s) for new MBS session(s) or the refresh of the expiry time of already allocated MBS TMGI(s), an AF shall send a Nnef_MBSTMGI_Allocation request message to the NEF using the HTTP POST method with the request body including the TmgiAllocRequest data structure that shall contain:

NOTE: The Nnef_MBSTMGI_Allocation service operation corresponds to the stage 2 Nnef_MBSTMGI_Allocate service operation defined in 3GPP TS 23.247 [53].

– within the "afId" attribute, the identifier of the AF that is sending the request;

– within the "tmgiParams" attribute, the parameters (e.g. number of TMGI(s) to be allocated, etc.) to request the allocation of TMGI(s) for new MBS session(s) or the refresh of the expiry time of already allocated TMGI(s);

– within the "suppFeat" attribute, the features supported by the AF, if feature negotiation needs to take place;

and may contain:

– within the "notificationUri" attribute, the notification URI via which the AF desires to receive notifications on timer expiry for TMGI(s);

– within the "requestTestNotification" attribute, an indication on whether the NEF should send a test notification, if the "Notification_test_event" feature is supported; and/or

– within the "websockNotifConfig" attribute, the configuration parameters to set up notification delivery over Websocket protocol, if the "Notification_websocket" feature is supported.

The NEF shall then check whether the AF is authorized to perform this operation or not as defined in clause 6.1.1 of 3GPP TS 23.247 [53]. If the AF is authorized, the NEF may query the NRF to discover and select an MB-SMF (service) instance that can handle this request. Otherwise, the target MB-SMF is determined based on local configuration. Then, the NEF shall convey this MBS TMGI(s) allocation request or expiry time refresh request to the selected MB-SMF using the Nmbsmf_TMGI service API as defined in 3GPP TS 29.532 [52].

Upon reception of a successful response from the MB-SMF as defined in 3GPP TS 29.532 [52], the NEF shall forward the received information (e.g. allocated MBS TMGI(s), expiry time or updated expiry time of existing MBS TMGI(s), etc.) to the AF in a Nnef_MBSTMGI_Allocation response message with an HTTP "200 OK" status code and the response body including the TmgiAllocResponse data structure that shall contain:

– within the "tmgiInfo" attribute, the MBS TMGI(s) allocation information or the refreshed expiry time for already allocated MBS TMGI(s); and

– within the "suppFeat" attribute, the features supported by both the AF and the NEF, if feature negotiation needs to take place and the AF provided the list of its supported features in the corresponding request body.

On failure or if the NEF receives an error responsefrom the MB-SMF, the NEF shall take proper error handling actions, as specified in clause 5.19.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.2.3 Procedure for MBS TMGI(s) deallocation

This procedure is used by an AF to request the deallocation of previously allocated MBS TMGI(s).

In order to request the deallocation of previously allocated MBS TMGI(s), an AF shall send a Nnef_MBSTMGI_Deallocation request message to the NEF using the HTTP POST method with the request body including the TmgiDeallocRequest data structure that shall contain :

NOTE: The Nnef_MBSTMGI_Deallocation service operation corresponds to the stage 2 Nnef_MBSTMGI_Deallocate service operation defined in 3GPP TS 23.247 [53].

– within the "afId" attribute, the identifier of the AF that is sending the request; and

– within the "tmgis" attribute, the list of MBS TMGI(s) for which deallocation is requested.

The NEF shall then check whether the AF is authorized to perform this operation or not as defined in clause 6.1.1 of 3GPP TS 23.247 [53]. If the AF is authorized, the NEF shall convey this MBS TMGI(s) deallocation request to the MB-SMF using the Nmbsmf_TMGI service API as defined in 3GPP TS 29.532 [52].

Upon reception of a successful response from the MB-SMF confirming the deallocation of the TMGI(s), the NEF shall forward this confirmation to the AF in a Nnef_MBSTMGI_Deallocation response message with an HTTP "204 No Content" status code.

4.4.29.2.4 Procedure for MBS TMGI(s) timer expiry notification

This procedure is used by the NEF to notify an already subscribed AF of timer expiry for previously allocated MBS TMGI(s).

In order to notify an AF of timer expiry for previously allocated MBS TMGI(s), the NEF shall send a Nnef_MBSTMGI_ExpiryNotify request message to the AF using the HTTP POST method with the request body including the ExpiryNotif data structure that shall contain:

– within the "tmgis" attribute, the list of MBS TMGI(s) for which the timer has expired.

Upon reception of this notification request, the AF shall acknowledge its successful reception by sending a Nnef_MBSTMGI_ExpiryNotify response message with an HTTP "204 No Content" status code.

On failure, the AF shall take proper error handling actions, as specified in clause 5.19.7, and respond to the NEF with an appropriate error status code.

4.4.29.3 Procedures for MBS session management

4.4.29.3.1 General

The procedures described in the clauses below are used by an AF to create, update or delete MBS session(s) and to subscribe to / unsubscribe from MBS Session Status event(s) reporting at the NEF.

This service is applicable for both broadcast and multicast sessions or, for a location dependent MBS session, the part of an MBS Session within an MBS service area, as defined in 3GPP TS 23.247 [53].

4.4.29.3.2 Procedure for MBS session creation

This procedure is used by an AF to request the creation of a multicast or a broadcast MBS session or, for a location dependent MBS session, the part of an MBS Session within an MBS service area.

In order to request the creation of an MBS Session, an AF shall send a Nnef_MBSSession_Create request to the NEF using the HTTP POST method and targeting the "MBS Sessions" collection resource with the request message body including the MbsSessionCreateReq data structure that shall contain:

– within the "afId" attribute, the identifier of the AF that is sending the request; and

– within the "mbsSession" attribute, the characteristics of the MBS session that is to be created.

The "mbsSession" attribute shall be encoded using the MbsSession data structure that shall contain:

– within the "mbsSessionId" attribute, the identifier of the MBS Session (e.g. SSM, TMGI), if available;

– within the "tmgiAllocReq" attribute, the TMGI allocation request indication, if the "mbsSessionId" attribute is either absent or does not contain a TMGI; and

– within the "serviceType" attribute, the MBS service type (i.e. multicast or broadcast);

– within the "locationDependent" attribute, the location dependent MBS session indication, if the request is related to a location dependent MBS;

and may further contain:

– for a multicast or a broadcast MBS session:

– within the "ingressAddrReq" attribute, the ingress transport address request indication to indicate whether the allocation of an ingress transport address is requested or not;

– within the "extMbsServiceArea" attribute, the MBS service area, for a location dependent MBS session or a local MBS session;

– within the "activationTime" attribute, the MBS session activation time;

– within the "terminationTime" attribute, the MBS session termination time;

– within the "mbsServInfo" attribute, the MBS Service Information for the MBS session; and

– within the "mbsSessionSubsc" attribute, the parameters to request the creation of a subscription to MBS session status event(s) reporting;

– for a multicast MBS session:

– within the "activityStatus" attribute, the MBS session activity status (i.e. active or inactive); and

– within the "anyUeInd" attribute, the indication of whether any UE may join the MBS session;

– for a broadcast MBS session:

– within the " mbsFsaIdList" attribute, the list of MBS frequency selection area Identifiers (i.e. FSA IDs).

At the reception of this HTTP POST request for MBS session creation:

– the NEF may decide to interact with the PCF for MBS policy authorization of the received MBS Service Information;

– if the NEF decides to interact with the PCF, then:

– if the NEF did not receive an MBS Session Identifier or received a TMGI allocation request within the "tmgiAllocReq" attribute, the NEF shall request TMGI allocation to the MB-SMF using the Nmbsmf_TMGI service API, as specified in 3GPP TS 29.532 [52];

– if the received MBS Session Creation request is for the creation of an MBS Session that is part of a location dependent MBS, i.e. the "locationDependent" attribute is present and set to "true", and there is a need to select the same PCF for all the MBS Sessions composing the location dependent MBS, the NEF shall interact with the BSF using the Nbsf_Management service API to check whether there is already a PCF serving the MBS Sessions of the location dependent MBS based on the MBS Session Identifier, as specified in 3GPP TS 29.532 [52]. Then:

NOTE 1: Interacting with the BSF to discover whether there is already a PCF serving the MBS Session is not necessary in a deployment with a single PCF.

– if there is a PCF already serving the MBS Sessions of the location dependent MBS, the NEF shall use this PCF for MBS policy authorization of the received MBS Service Information;

– if there is no PCF already serving the MBS Sessions of the location dependent MBS or the NEF did not interact with the BSF, the NEF shall interact with the NRF using the Nnrf_NFDiscovery service API to discover a PCF (service) instance to serve the MBS Session possibly based on the MBS Session Identifier, as specified in 3GPP TS 29.510 [57];

– the NEF shall then interact with the selected PCF (service) instance using the Npcf_MBSPolicyAuthorization service API for MBS policy authorization of the received MBS Service Information and the creation of a corresponding MBS Application Session Context at the PCF, as specified in 3GPP TS 29.537 [63]; and

– if MBS session authorization is successful or when the NEF decides to not interact with the PCF for MBS policy authorization, the NEF shall interact with the MB-SMF using the Nmbsmf_MBSSession service API to request the creation of a corresponding MBS session at the MB-SMF as specified in 3GPP TS 29.532 [52]; and

– if the MBS Service Area information is provided within the "extMbsServiceArea" attribute, the NEF shall translate the received geographical area(s) or civic address(es) to a list of cell ID(s) and/or list of TAI(s) before relaying it to the MB-SMF.

Upon reception of a successful response from the MB-SMF and successful MBS session creation at the NEF, the NEF shall return a Nnef_MBSSession_Create response with an HTTP "201 Created" status code to theAF including a "Location" header that shall contain the URI of the created "Individual MBS Session" resource, and the response body including the MbsSessionCreateRsp data structure that shall contain:

– within the "mbsSession" attribute, a representation of the created Individual MBS Session resource encoded using the MbsSession data structure, including:

– the area session ID assigned by the MB-SMF in the case of a location dependent MBS within the "areaSessionId" attribute of the MbsSession data structure;

– the allocated TMGI for the MBS session, if the MBS session creation request included a "tmgiAllocReq" attribute requesting TMGI allocation for the MBS session, within the "tmgi" attribute;

– if unicast transport is used over N6mb/Nmb9, the ingress MB-UPF tunnel information, within the "ingressTunAddr" attribute;

– if the "serviceType" value is "BROADCAST" and any MBS FSA ID(s) received from the MB-SMF, the list of MBS FSA ID(s) within the "mbsFsaIdList" attribute.

– within the "eventList" attribute, a list of MBS Session Status Event(s) report(s), if available.

If the MBS session creation request contained a request to also create a subscription to MBS session status event(s) within the "mbsSessionSubsc" attribute, the the NEF shall also create a corresponding "Individual MBS Session Subscription" resource and return a representation of it in the HTTP POST response body within the "mbsSessionSubsc" attribute of the MbsSession data structure. The "mbsSessionSubsc" attribute shall contains the identifier of the created "Individual MBS Session Subscription" resource within the "subscriptionId" attribute. The AF shall construct the URI of the created "Individual MBS Session Subscription" resource by appending the path segments "/subscriptions/{subscriptionId}", where the "subscriptionId" takes the value of the received "subscriptionId" attribute, to the URI of the created "Individual MBS Session" resource received within the HTTP Location header.

On failure or if the NEF receives an error code from the PCF, the NRF or the MB-SMF, the NEF shall take proper error handling actions, as specified in clause 5.20.7, and respond to the AF with an appropriate error status code,. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.3.3 Procedure for MBS session update

This procedure is used by an AF to request the modification of an existing multicast or a broadcast MBS session or, for a location dependent MBS session, the part of an MBS Session within an MBS service area.

In order to request the modification of an existing MBS Session, an AF shall send a Nnef_MBSSession_Update request using the HTTP PATCH method and targeting the URI of the corresponding "Individual MBS Session" resource and the request message body including an array of PatchItem data structure(s) containing the requested modifications. For a multicast or a broadcast MBS session, only the "mbsServiceArea" attribute, and/or the "mbsServInfo" attribute may be modified. For a multicast MBS session, the "activityStatus" attribute may also be modified. For a broadcast MBS session, the "mbsFsaIdList" attribute may also be modified.

At the reception of this HTTP PATCH request for MBS session modification:

– if updated MBS Service Information is provided and the NEF decided to interact with the PCF during MBS Session Creation as specified in clause 4.4.29.3.2, the NEF shall also interact with the PCF for MBS policy authorization of the received updated MBS Service Information and the update of the corresponding MBS Application Session Context, as specified in 3GPP TS 29.537 [63];

– if MBS session authorization is successful or when the NEF does not interact with the PCF, the NEF shall interact with the MB-SMF to request the modification of the corresponding MBS session at the MB-SMF as specified in 3GPP TS 29.532 [52];

– if the NEF receives an "indication that the PCF shall be contacted" within the "contactPcfInd" attribute from the PCF as specified in 3GPP TS 29.537 [63], the NEF shall relay this indication to the MB-SMF;

and

– if updated MBS Service Area information is provided within the "extMbsServiceArea" attribute, the NEF shall translate the received geographical area(s) or civic address(es) to a list of cell ID(s) and/or list of TAI(s) before relaying it to the MB-SMF.

Upon reception of a successful response from the MB-SMF and successful MBS session modification, the NEF shall return a Nnef_MBSSession_Update response with an HTTP "204 No Content" status code.

On failure or if the NEF receives an error responsefrom the PCF or the MB-SMF, the NEF shall take proper error handling actions, as specified in clause 5.20.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.3.4 Procedure for MBS session deletion

This procedure is used by an AF to request the deletion of an existing multicast or a broadcast MBS session or, for a location dependent MBS session, the part of an MBS Session within an MBS service area.

In order to request the deletion of an existing MBS Session, an AF shall send a Nnef_MBSSession_Delete request using the HTTP DELETE method and targeting the URI of the corresponding "Individual MBS Session" resource.

At the reception of this HTTP DELETE request for MBS session deletion:

– if the NEF decided to interact with the PCF during MBS Session Creation as specified in clause 4.4.29.3.2, the NEF shall also interact with the PCF to request the deletion of the corresponding MBS Application Session Context, as specified in 3GPP TS 29.537 [63]; and

– the NEF shall interact with the MB-SMF to request the deletion of the corresponding MBS Session.

Upon success, the NEF shall return a Nnef_MBSSession_Delete response with an HTTP "204 No Content" status code.On failure or if the NEF receives an error responsefrom the PCF or the MB-SMF, the NEF shall take proper error handling actions, as specified in clause 5.20.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.3.5 Procedure for MBS session status subscription

This procedure is used by an AF to request to create a subscription to MBS session status event(s) reportingfor a multicast or a broadcast MBS session or, for a location dependent MBS session, the part of an MBS Session within an MBS service area.

In order to request the creation of a new subscription to MBS Session status event(s) reporting, an AF shall send a Nnef_MBSSession_StatusSubscribe request to the NEF using the HTTP POST method and targeting the "MBS Session Subscriptions" collection resource, with the request body including the MbsSessionSubsc data structure.

On successful MBS session subscription creation, the NEF shall return a Nnef_MBSSession_StatusSubscribe response with an HTTP "201 Created" status code to the AF, including a "Location" header containing the URI of the created "Individual MBS Session Subscription" resource and the response body containing a representation of the created resource within the MbsSessionSubsc data structure.

On failure or if the NEF receives an error responsefrom the MB-SMF, the NEF shall take proper error handling actions, as specified in clause 5.20.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.3.6 Procedure for MBS session status unsubscription

This procedure is used by an AF to request the deletion of an existing subscription to MBS session status event(s) reportingfor a multicast or a broadcast MBS session or, for a location dependent MBS session, the part of an MBS Session within an MBS service area.

In order to request the deletion of an existing subscription to MBS Session status event(s) reporting, an AF shall send a Nnef_MBSSession_StatusUnsubscribe request to the NEF using the HTTP DELETE method and targeting the corresponding "Individual MBS Session Subscription" resource.

On successful deletion of the subscription, the NEF shall return a Nnef_MBSSession_StatusUnsubcribe response with an HTTP "204 No Content" status code.

4.4.29.3.7 Procedure for MBS session status notification

This procedure is used by the NEF to send MBS session status event(s) notifications to a previously subscribed AF.

In order to send an MBS Session status event(s) notification, the NEF shall send a Nnef_MBSSession_StatusNotify request to the AF using the HTTP POST method and targeting the notification URI provided by the AF during the corresponding MBS session subscription creation/modification, with the request body including the MbsSessionStatusNotif data structure that shall contain:

– within the "eventList" attribute, the reported MBS session event(s) ) and the related information, encoded via the MbsSessionEventReportList data structure that shall contain:

– within the "eventReportList" attribute, one or several MBS session event report(s), with each one of them encoded using the MbsSessionEventReport data structure that shall contain:

– within the "eventType" attribute, the reported MBS session status event;

– within the "timeStamp" attribute, the time at which the event is generated, if available;

– within the "ingressTunAddrInfo" attribute, the ingress tunnel address to use to send MBS session data over N6mb/Nmb9 interface, if the "eventType" attribute is set to "INGRESS_TUNNEL_ADD_CHANGE";

and

– within the "eventList" attribute, the list of MBS session events to be reported, encoded via the MbsSessionEventReportList data structure that shall contain;

– within the "eventReportList" attribute, one or several individual MBS session event report(s), with each one of them encoded within the MbsSessionEventReport data structure that shall contain:

– within the "broadcastDelStatus" attribute, the broadcast delivery status (e.g. whether the MBS session is ACTIVATED or TERMINATED), if the "eventType" attribute is set to "BROADCAST_DELIVERY_STATUS".

Upon reception of this notification request, the AF shall acknowledge its successful reception by sending a Nnef_MBSSession_StatusNotify response with an HTTP "204 No Content" status code.

On failure, the AF shall take proper error handling actions, as specified in subclause 5.20.7, and respond to the NEF with an appropriate error status code.

4.4.29.4 Procedures for MBS Parameters Provisioning

4.4.29.4.1 General

The procedures described in the clauses below are used by an AF to perform MBS parameters provisioning, e.g. multicast MBS Session Authorization information provisioning as defined in clause 7.2.9 of 3GPP TS 23.247 [53].

4.4.29.4.2 Procedure for multicast MBS Session Authorization information provisioning

This procedure is used by an AF to request the creation/update/deletion of an MBS Session Authorization information provisioning for a multicast MBS group.

In order to request the creation of an MBS Parameters Provisioning for the purpose of MBS Session Authorization information provisioning for a multicast MBS group, an AF shall trigger the Nnef_MBSSession API by sending an HTTP POST request to the NEF targeting the "MBS Parameters Provisionings" collection resource, with the request body including the MbsPpData data structure that shall contain:

– within the "afId" attribute, the identifier of the AF that is sending the request;

– within the "mbsSessAuthData" attribute, the MBS Session Authorization information data to be provisioned, encoded via the MbsSessAuthData data structure that shall contain:

– within the "extGroupId" attribute, the external group identifier of the targeted multicast MBS Group; and

– within the "gpsisList" attribute, the list of the GPSI(s) of the member UE(s) constituting the multicast MBS group, if the multicast MBS group has not yet been created or the list of its member(s) needs to be updated; and

– within the "mbsSessionIdList" attribute, the identifier(s) of the multicast MBS Session(s) that the multicast MBS group is authorized to join;

and

– within the "suppFeat" attribute, the features supported by the AF, if applicable (i.e. feature negociation needs to take place).

The NEF shall then check whether the AF is authorized to perform this operation or not as defined in clause 7.2.9 of 3GPP TS 23.247 [53]. If the AF is authorized, the NEF shall trigger the Nudm_ParameterProvision service API of the UDM to request the provisioning of the received MBS Session Authorization information.

Upon reception of a successful response from the UDM as defined in 3GPP TS 29.503 [17], the NEF shall respond to the AF with an HTTP "200 OK" status code including a Location header field containing the URI of the created resource, and the response body containing the MbsPpData data structure containing a representation of the created "Individual MBS Parameters Provisioning" resource.

In order to request the update of an existing "Individual MBS Parameters Provisioning" resource for the purpose of MBS Session Authorization information provisioning for a multicast MBS group, an AF shall trigger the Nnef_MBSSession API by sending to the NEF either:

– an HTTP PUT request targeting the concerned "Individual MBS Parameters Provisioning" resource with the request body including the MbsPpData data structure; or

– an HTTP PATCH request targeting the concerned "Individual MBS Parameters Provisioning" resource with the request body including the MbsPpDataPatch data structure.

After authorizing the request, the NEF shall interact with the UDM via the the Nudm_ParameterProvision service API to request the provisioning of the received updated MBS Session Authorization information.

Upon reception of a successful response from the UDM as defined in 3GPP TS 29.503 [17], the NEF shall respond to the AF with an HTTP "200 OK" status code with the response body containing a representation of the updated Individual MBS Parameters Provisioning resource within the MbsPpData data structure, or an HTTP "204 No Content" status code.

In order to request the deletion of an existing "Individual MBS Parameters Provisioning" resource for the purpose of MBS Session Authorization information provisioning for a multicast MBS group, an AF shall trigger the Nnef_MBSSession API by sending an HTTP DELETE request targeting the concerned "Individual MBS Parameters Provisioning" resource to the NEF. After authorizing the request, the NEF shall interact with the UDM via the the Nudm_ParameterProvision service API to request to update accordingly the MBS Session Authorization information.

Upon reception of a successful response from the UDM as defined in 3GPP TS 29.503 [17], the NEF shall respond to the AF with an HTTP "204 No Content" status code.

On failure or if the NEF receives an error code from the UDM, the NEF shall take proper error handling actions, as specified in clause 5.20.7, and respond to the AF with an appropriate error status code.

NOTE: The stage 2 Nnef_ParameterProvisioning API for MBS Parameters Provisioning is implemented in stage 3 via the Nnef_MBSSession API.

4.4.29.5 Procedures for MBS User Service management

4.4.29.5.1 General

The procedures described in the clauses below are used by an external/untrusted AF (e.g. MBS Application Provider that lies outside the trusted DN) to manage MBS User Services via the NEF, i.e. create, retrieve, update and delete an MBS User Service, as defined in 3GPP TS 26.502 [65].

4.4.29.5.2 Procedure for MBS User Service creation

This procedure is used by an AF to request the creation of a new MBS User Service at the NEF.

In order to request the creation of an MBS User Service, an AF shall send a Nnef_MBSUserService_Create request to the NEF using the HTTP POST method and targeting the "MBS User Services" collection resource, with the request message body including the MBSUserService data structure, as specified in clause 5.26.2.2.3.2.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserService service API of the MBSF to request the creation of the corresponding MBS User Service at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserService_Create response with an HTTP "201 Created" status code including a "Location" header field that shall contain the URI of the created resource, and the response body containing a representation of the created "Individual MBS User Service" resource within the MBSUserService data structure, as specified in clause 5.26.2.2.3.2.

On failure or if the NEF receives an error response from the MBSF, the NEF shall take proper error handling actions, as specified in clause 5.26.7, and respond to the AF with an appropriate error status code.

4.4.29.5.3 Procedure for MBS User Service retrieval

This procedure is used by an AF to request the retrieval of an existing MBS User Service at the NEF.

In order to request the retrieval of an existing MBS User Service, an AF shall send a Nnef_MBSUserService_Retrieve request using the HTTP GET method and targeting the URI of the concerned "Individual MBS User Service" resource, as specified in clause 5.26.2.3.3.1.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserService service API of the MBSF to request the retrieval of the corresponding MBS User Service at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserService_Retrieve response with an HTTP "200 OK" status code and the response body containing a representation of the requested Individual MBS User Service resource within the MBSUserService data structure, as specified in clauses 5.26.2.3.3.1.

On failure or if the NEF receives an error code from the MBSF, the NEF shall take proper error handling actions, as specified in clause 5.26.7, and respond to the AF with an appropriate error status code.

4.4.29.5.4 Procedure for MBS User Service update/modification

This procedure is used by an AF to request the update/modification of an existing MBS User Service at the NEF.

In order to request the update of an existing MBS User Service, an AF shall send a Nnef_MBSUserService_Update request using the HTTP PUT method and targeting the URI of the corresponding "Individual MBS User Service" resource, with the request body including the MBSUserService data structure, as specified in clause 5.26.2.3.3.2.

In order to request the modification of an existing MBS User Service, an AF shall send a Nnef_MBSUserService_Update request using the HTTP PATCH method and targeting the URI of the corresponding "Individual MBS User Service" resource, with the request body including the MBSUserServicePatch data structure, as specified in clause 5.26.2.3.3.3.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserService service API of the MBSF to request the update/modification of the corresponding MBS User Service at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserService_Update response with an HTTP "200 OK" status code with the response body containing a representation of the updated Individual MBS User Service resource within the MBSUserService data structure, or an HTTP "204 No Content" status code, as specified in clause 5.26.2.3.3.2 or clause 5.26.2.3.3.3.

4.4.29.5.5 Procedure for MBS User Service deletion

This procedure is used by an AF to request the deletion of an existing MBS User Service at the NEF.

In order to request the deletion of an existing MBS User Service, an AF shall send a Nnef_MBSUserService_Delete request using the HTTP DELETE method and targeting the URI of the concerned "Individual MBS User Service" resource, as specified in clause 5.26.2.3.3.4.

NOTE: The Nnef_MBSUserService_Delete service operation corresponds to the stage 2 Nnef_MBSUserService_Destroy service operation defined in 3GPP TS 26.502 [65].

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserService service API of the MBSF to request the deletion of the corresponding MBS User Service at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserService_Delete response with an HTTP "204 No Content" status code, as specified in clause 5.26.2.3.3.4.

4.4.29.6 Procedures for MBS User Data Ingest Session management

4.4.29.6.1 General

The procedures described in the clauses below are used by an external/untrusted AF (e.g. MBS Application Provider that lies outside the trusted DN) to manage an MBS User Data Ingest Session along with its subordinate MBS Distribution Session(s) via the NEF, i.e. create, retrieve, update/modify and delete an MBS User Data Ingest Session, create, retrieve, update/modify and delete an MBS User Data Ingest Session Status subscription, and manage the related MBS User Data Ingest Session Status notifications, as defined in 3GPP TS 26.502 [65].

4.4.29.6.2 Procedure for MBS User Data Ingest Session creation

This procedure is used by an AF to request the creation of a new MBS User Data Ingest Session at the NEF.

In order to request the creation of an MBS User Data Ingest Session, including a set of subordinate MBS Distribution Session(s), an AF shall send a Nnef_MBSUserDataIngestSession_Create request message to the NEF using the HTTP POST method and targeting the "MBS User Data Ingest Sessions" collection resource, with the request message body including the MBSUserDataIngSession data structure, as specified in clause 5.27.2.2.3.2.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession API of the MBSF to request the creation of the corresponding MBS User Data Ingest Session at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_Create response message with an HTTP "201 Created" status code including a "Location" header field that shall contain the URI of the created resource, and the response body containing a representation of the created "Individual MBS User Data Ingest Session" resource within the MBSUserDataIngSession data structure, as specified in clause 5.27.2.2.3.2.

On failure or if the NEF receives an error response from the MBSF, the NEF shall take proper error handling actions, as specified in clause 5.27.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a ProblemDetails data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.6.3 Procedure for MBS User Data Ingest Session retrieval

This procedure is used by an AF to request the retrieval of an existing MBS User Data Ingest Session at the NEF.

In order to request the retrieval of an existing MBS User Data Ingest Session, an AF shall send a Nnef_MBSUserDataIngestSession_Retrieve request message using the HTTP GET method and targeting the URI of the concerned "Individual MBS User Data Ingest Session" resource, as specified in clause 5.27.2.3.3.1.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession service API of the MBSF to request the retrieval of the corresponding MBS User Data Ingest Session at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_Retrieve response message with an HTTP "200 OK" status code and the response body containing a representation of the requested Individual MBS User Data Ingest Session resource within the MBSUserDataIngSession data structure, as specified in clauses 5.27.2.3.3.1.

On failure or if the NEF receives an error code from the MBSF, the NEF shall take proper error handling actions, as specified in clause 5.27.7, and respond to the AF with an appropriate error status code. If the NEF received within an error response a ProblemDetails data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.29.6.4 Procedure for MBS User Data Ingest Session update/modification

This procedure is used by an AF to request the update/modification of an existing MBS User Data Ingest Session at the NEF.

In order to request the update of an existing MBS User Data Ingest Session, an AF shall send a Nnef_MBSUserDataIngestSession_Update request message using the HTTP PUT method and targeting the URI of the corresponding "Individual MBS User Data Ingest Session" resource, with the request body including the MBSUserDataIngSession data structure, as specified in clause 5.27.2.3.3.2.

In order to request the modification of an existing MBS User Data Ingest Session, an AF shall send a Nnef_MBSUserDataIngestSession_Update request message using the HTTP PATCH method and targeting the URI of the corresponding "Individual MBS User Data Ingest Session" resource, with the request body including the MBSUserDataIngSessionPatch data structure, as specified in clause 5.27.2.3.3.3.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession service API of the MBSF to request the update/modification of the corresponding MBS User Data Ingest Session at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_Update response message with an HTTP "200 OK" status code with the response body containing a representation of the updated Individual MBS User Data Ingest Session resource within the MBSUserDataIngSession data structure, or an HTTP "204 No Content" status code, as specified in clause 5.27.2.3.3.2 or clause 5.27.2.3.3.3.

4.4.29.6.5 Procedure for MBS User Data Ingest Session deletion

This procedure is used by an AF to request the deletion of an existing MBS User Data Ingest Session at the NEF.

In order to request the deletion of an existing MBS User Data Ingest Session, an AF shall send a Nnef_MBSUserDataIngestSession_Delete request message using the HTTP DELETE method and targeting the URI of the concerned "Individual MBS User Data Ingest Session" resource, as specified in clause 5.27.2.3.3.4.

NOTE: The Nnef_MBSUserDataIngestSession_Delete service operation corresponds to the stage 2 Nnef_MBSUserDataIngestSession_Destroy service operation defined in 3GPP TS 26.502 [65].

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession service API of the MBSF to request the deletion of the corresponding MBS User Data Ingest Session at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_Delete response message with an HTTP "204 No Content" status code, as specified in clause 5.27.2.3.3.4.

4.4.29.6.6 Procedure for MBS User Data Ingest Session Status Subscription

This procedure is used by an AF to subscribe to MBS User Data Ingest Session status event(s) reporting at the NEF.

In order to request the creation of an MBS User Data Ingest Session Status Subscription, an AF shall send a Nnef_MBSUserDataIngestSession_StatusSubscribe request message to the NEF using the HTTP POST method and targeting the "MBS User Data Ingest Session Status Subscriptions" collection resource, with the request message body including the MBSUserDataIngStatSubsc data structure, as specified in clause 5.27.2.4.3.2.

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_StatusSubscribe response message with an HTTP "201 Created" status code including a "Location" header field that shall contain the URI of the created resource, and the response body containing a representation of the created "Individual MBS User Data Ingest Session Status Subscription" resource within the MBSUserDataIngStatSubsc data structure, as specified in clause 5.27.2.4.3.2.

4.4.29.6.7 Procedure for MBS User Data Ingest Session Status update/modification

This procedure is used by an AF to request the update/modification of an existing MBS User Data Ingest Session Status Subscription at the NEF.

In order to request the update of an existing MBS User Data Ingest Session Status Subscription, an AF shall send a Nnef_MBSUserDataIngestSession_StatusSubscribeMod request message using the HTTP PUT method and targeting the URI of the corresponding "Individual MBS User Data Ingest Session Status Subscription" resource, with the request body including the MBSUserDataIngStatSubsc data structure, as specified in clause 5.27.2.5.3.2.

In order to request the modification of an existing MBS User Data Ingest Session Status Subscription, an AF shall send a Nnef_MBSUserDataIngestSession_StatusSubscribeMod request message using the HTTP PATCH method and targeting the URI of the corresponding "Individual MBS User Data Ingest Session Status Subscription" resource, with the request body including the MBSUserDataIngStatSubscPatch data structure, as specified in clause 5.27.2.5.3.3.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession service API of the MBSF to request the update/modification of the corresponding MBS User Data Ingest Session Status Subscription at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_StatusSubscribeMod response message with an HTTP "200 OK" status code with the response body containing a representation of the updated Individual MBS User Data Ingest Session resource within the MBSUserDataIngStatSubsc data structure, or an HTTP "204 No Content" status code, as specified in clause 5.27.2.5.3.2 or clause 5.27.2.5.3.3.

4.4.29.6.8 Procedure for MBS User Data Ingest Session Status Unsubscription

This procedure is used by an AF to request the deletion of an existing MBS User Data Ingest Session Status Subscription at the NEF.

In order to request the deletion of an existing MBS User Data Ingest Session Status Subscription, an AF shall send a Nnef_MBSUserDataIngestSession_StatusUnsubscribe request message using the HTTP DELETE method and targeting the URI of the concerned Individual MBS User Data Ingest Session Stats Subscription resource, as specified in clause 5.27.2.5.3.4.

The NEF shall then check whether the AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Nmbsf_MBSUserDataIngestSession service API of the MBSF to request the deletion of the corresponding MBS User Data Ingest Session Status Subscription at the MBSF, as specified in 3GPP TS 29.580 [66].

Upon reception of a successful response from the MBSF, as defined in 3GPP TS 29.580 [66], the NEF shall return a Nnef_MBSUserDataIngestSession_StatusUnsubscribe response message with an HTTP "204 No Content" status code, as specified in clause 5.27.2.5.3.4.

4.4.29.6.9 Procedure for MBS User Data Ingest Session Status Notification

This procedure is used by the NEF to send MBS User Data Ingest Session status change notifications to a previously subscribed AF.

Upon reception of an MBS User Data Ingest Session Status Notification from the MBSF, as specified in 3GPP TS 29.580 [66], the NEF shall relay this notification to the AF by sending a Nnef_MBSUserDataIngestSession_StatusNotify request message to the AF using the HTTP POST method and targeting the notification URI provided by the AF during the creation of the corresponding MBS User Data Ingest Session Status Subscription, with the request body including the MBSUserDataIngStatNotif data structure, as specified in clause 5.27.4.2.3.1.

Upon successful reception of this notification request, the AF shall acknowledge its successful reception by sending a Nnef_MBSUserDataIngestSession_StatusNotify response message with an HTTP "204 No Content" status code, as specified in clause 5.27.4.2.3.1.

On failure, the AF shall take proper error handling actions, as specified in subclause 5.27.7, and respond to the NEF with an appropriate error status code.

4.4.30 Procedures for Data Reporting

4.4.30.1 General

The procedures in this clause are used by an AF to obtain data collection and reporting information and provide Data Reports, as defined in clause 4.2 of 3GPP TS 26.531 [59] and 3GPP TS 26.532 [60].

4.4.30.2 Procedure for Data Reporting Session Management

This procedure is used by an AF to request the creation/update/delection of a Data Reporting Session in order to obtain data collection and reporting information.

In order to request the creation of a Data Reporting Session, an AF shall send a Nnef_DataReporting_Create request to the NEF using the HTTP POST method, targeting the "Data Reporting Sessions" collection resource with the request message body including the DataReportingSession data structure as defined in clause 5.23.2.2.3.1.

In order to read an existing Individual Data Reporting Session, an AF shall send a Nnef_DataReporting_Retrieve request to the NEF using the HTTP GET method, targeting the concerned "Individual Data Reporting Session" resource. If successful, the response message body contains the requested DataReportingSession data structure as defined in clause 5.23.2.3.3.1.

In order to request the update of an existing Data Reporting Session, an AF shall send a Nnef_DataReporting_Update request to the NEF using the HTTP PUT method, targeting the concerned "Individual Data Reporting Session" resource with the request message body including the updated resource representation within the DataReportingSession data structure as defined in clause 5.23.2.3.3.2.

In order to request the deletion of an existing Data Reporting Session, an AF shall send a Nnef_DataReporting_Delete request to the NEF using the HTTP DELETE method, targeting the concerned "Individual Data Reporting Session" resource as defined in clause 5.23.2.3.3.3.

At the reception of the HTTP POST GET/PUT/DELETE requests from the AF, the NEF shall trigger the necessary interaction with the DCAF as specified in 3GPP TS 26.532 [60] and:

– for an HTTP GET request, retrieve the requested "Individual Data Reporting Session" resource and respond to the AF with an HTTP "200 OK" status code;

– for an HTTP POST request, create a new "Individual Data Reporting Session" resource and respond to the AF with an HTTP "200 OK" status code including an HTTP Location header field containing the URI of the created resource and the response body including a representation of the created "Individual Data Reporting Session" resource within the DataReportingSession data structure;

– for an HTTP PUT request, update the concerned "Individual Data Reporting Session" resource and respond to the AF with an HTTP "200 OK" status code with the response body including a representation of the updated "Individual Data Reporting Session" resource within the DataReportingSession data structure; and

– for an HTTP DELETE request, delete the corresponding "Individual Data Reporting Session" resource, and respond to the AF with an HTTP "204 No Content" status code.

4.4.30.3 Procedure for Data Report

This procedure is used by an AF to send collected UE Data Reports to the NEF.

In order to send a collected UE Data Report, an AF shall use the "Report" custom operation. The AF shall send for this purpose an HTTP POST request targeting the URI "{apiRoot}/3gpp-data-reporting/v1/sessions/{sessionId}/report", with the request message body including the DataReport data structure specified in 3GPP TS 26.532 [60]. Upon successful reception of the report, the NEF shall respond to the AF with an HTTP "200 OK" status code.

4.4.31 Procedures for Data Reporting Provisioning

4.4.31.1 General

The procedures in this clause are used by an AF to supply data collection and reporting provisioning information in the form of Data Reporting Provisioning resources, as defined in clause 4.2 of 3GPP TS 26.531 [59] and 3GPP TS 26.532 [60].

4.4.31.2 Procedure for Data Reporting Provisioning Session Management

This procedure is used by an AF to request the creation/deletion of a Data Reporting Provisioning Session in order to supply data collection and reporting provisioning information.

In order to request the creation of a Data Reporting Provisioning Session, an AF shall send a Nnef_DataReportingProvisioning_Create request to the NEF using the HTTP POST method and targeting the "Data Reporting Provisioning Sessions" collection resource, with the request message body including the DataReportingProvisioningSession data structure as defined in clause 5.24.2.2.3.1.

In order to read an existing "Individual Data Reporting Provisioning Session" resource, an AF shall send a Nnef_DataReportingProvisioning_Retrieve request to the NEF using the HTTP GET method and targeting the concerned "Individual Data Reporting Provisioning Session" resource, as defined in clause 5.24.2.3.3.1.

In order to request the deletion of an existing Data Reporting Provisioning Session, an AF shall send a Nnef_DataReportingProvisioning_Delete request to the NEF using the HTTP DELETE method and targeting the concerned "Individual Data Reporting Provisioning Session" resource as defined in clause 5.24.2.3.3.3.

At the reception of the HTTP POST/GET/DELETE request from the AF, the NEF shall trigger the necessary interactions with the DCAF as specified in 3GPP TS 26.532 [60] and:

– for an HTTP POST request, create a new "Individual Data Reporting Provisioning Session" resource and respond to the AF with an HTTP "200 OK" status code including an HTTP Location header field containing the URI of the created resource and the response body including a representation of the created "Individual Data Reporting Provisioning Session" resource within the DataReportingProvisioningSession data structure;

– for an HTTP GET request, respond to the AF with an HTTP "200 OK" status code with the response body including the representation of the requested "Individual Data Reporting Provisioning Session" resource within the DataReportingProvisioningSession data structure; and

– for an HTTP DELETE request, delete the corresponding "Individual Data Reporting Provisioning Session" resource and respond to the AF with an HTTP "204 No Content" status code.

4.4.31.3 Procedure for Data Reporting Configuration management

This procedure is used by an AF to manage Data Reporting Configuration.

In order to request the creation of a Data Reporting Configuration, an AF shall send a Nnef_DataReportingProvisioning_CreateConfiguration request to the NEF using the HTTP POST method and targeting the "Data Reporting Configurations" collection resource, with the request message body including the DataReportingConfiguration data structure as defined in clause 5.24.2.5.3.1.

In order to read an existing Data Reporting Configuration, an AF shall send a Nnef_DataReportingProvisioning_RetrieveConfiguration request to the NEF using the HTTP GET method and targeting the concerned "Individual Data Reporting Configuration" resource. , as defined in clause 5.24.2.4.3.1.

In order to request the update of an existing Data Reporting Configuration, an AF shall send a Nnef_DataReportingProvisioning_UpdateConfiguration request to the NEF using the HTTP PUT method, targeting the concerned "Individual Data Reporting Configuration" resource with the request message body including the updated resource representation within the DataReportingConfiguration data structure as defined in clause 5.24.2.5.3.3.

In order to request the modification of an existing Data Reporting Configuration, an AF shall send a Nnef_DataReportingProvisioning_UpdateConfiguration request to the NEF using the HTTP PATCH method and targeting the concerned "Individual Data Reporting Configuration" resource with the request message body containing the DataReportingConfigurationPatch data structure, as defined in clause 5.24.2.5.3.3A.

In order to request the deletion of an existing Data Reporting Configuration, an AF shall send a Nnef_DataReportingProvisioning_DeleteConfiguration request to the NEF using the HTTP DELETE method and targeting the concerned "Individual Data Reporting Configuration" resource as defined in clause 5.24.2.5.3.4.

At the reception of the HTTP POST/GET/PUT/PATCH/DELETE requests from the AF, the NEF shall trigger the necessary interactions with the DCAF as specified in 3GPP TS 26.532 [60] and:

– for an HTTP POST request, create a new "Individual Data Reporting Configuration" resource and respond to the AF with an HTTP "200 OK" status code including an HTTP Location header field containing the URI of the created resource and the response body including a representation of the created "Data Reporting Configuration" resource within the DataReportingConfiguration data structure;

– for an HTTP GET request, respond to the AF with an HTTP "200 OK" status code with the response body including the representation of the requested "Individual Data Reporting Configuration " resource within the DataReportingConfiguration data structure;

– for an HTTP PUT/PATCH request, update/modify the concerned "Individual Data Reporting Configuration" resource and respond to the AF with an HTTP "200 OK" status code with the response body including a representation of the updated/modified "Individual Data Reporting Configuration" resource within the DataReportingConfiguration data structure, or with an HTTP "204 No Content" status code; and

– for an HTTP DELETE request, delete the corresponding "Individual Data Reporting Configuration" resource and respond to the AF with an HTTP "204 No Content" status code.

4.4.32 Procedures for AF specific UE ID retrieval

4.4.32.1 General

The procedures described in the clauses below are used by an AF to request the NEF to provide an AF specific UE ID, as described in clause 4.15.10 of 3GPP TS 23.502 [2].

4.4.32.2 Retrieve AF specific UE ID service operation

In order to retrieve AF specific UE ID information, the AF shall send an HTTP POST request message to the NEF targeting the resource URI "{apiRoot}/3gpp-ueid/v1/retrieve", with the request body including the UeIdReq data structure.

Upon reception of the HTTP POST request message from the AF, the NEF shall check whether the AF is authorized to perform this operation or not:

– if AF request for for AF specific UE ID retrieval is not authorized, the NEF shall respond to the AF with a "403 Forbidden" status code with the response body including the ProblemDetails data structure containing the "cause" attribute set to the "REQUEST_NOT_AUTHORIZED" application error indicating the AF authorisation failure; and

– if the AF’s request for AF specific UE ID retrieval is authorized, then if the DNN and/or S-NSSAI information is not available in the request, the NEF shall determine the corresponding DNN and/or S-NSSAI information based on the requesting AF Identifier, and if provided, the MTC Provider Information.

The NEF shall then interact with the BSF using the UE address and IP domain (if the UE IPv4 address is provided), DNN and/or S-NSSAI to retrieve the session binding information of the UE by invoking the Nbsf_Management_Discovery service operation, as described in 3GPP TS 29.521 [9].

If the NEF receives an error response from the BSF, the NEF shall respond to the AF with a proper error status code. If the NEF received from the BSF an error response including a "ProblemDetails" data structure with the "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error. If no SUPI matching the provided UE information is returned by the BSF, the NEF shall respond to the AF with a "404 Not Found" status code with the response body including a ProblemDetails data structure containing the "cause" attribute set to the "UE_NOT_FOUND" application error to indicate that the requested UE address is not found.

Upon success and a SUPI is returned by the BSF, the NEF shall then interact with UDM to retrieve the AF specific UE Identifier using the received SUPI and at least one of the Application Port ID, MTC Provider Information or AF Identifier information by invoking Nudm_SDM_Get service, as described in clause 5.2.2.2 of 3GPP TS 29.503 [17]. Upon success, the UDM responds to the NEF with the AF specific UE Identifier represented as an External Identifier for the UE which is uniquely associated with the Application Port ID, MTC provider Information and/or AF Identifier. The NEF shall then respond to the AF with the received information, i.e. the AF specific UE Identifier represented as an External Identifier that was received from the UDM.

If the NEF receives an error response from the UDM, the NEF shall respond to the AF with a proper error status code. If the NEF received from the UDM an error response including a "ProblemDetails" data structure with the "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error. If the UDM indicates that the requested UE Identifier is not available in the subscription data, the NEF shall respond to the AF with a "404 Not Found" error status code with the response body including a ProblemDetails data structure containing the "cause" attribute set to the "UE_ID_NOT_AVAILABLE" application error to indicate that the AF specific UE ID is not available.

Editor’s note: Whether and how user’s consent is needed is FFS and pending SA6 and SA3 feedback.

4.4.33 Procedures for Media Streaming Event Exposure

4.4.33.1 General

The procedures described in the clauses below are used by an external/untrusted event consumer AF to subscribe, update and delete a subscription to Media Streaming Exposure event(s) reporting via the NEF, also for a data collection AF to notify the observed Media Streaming event(s) which has been subscribed, as defined in 3GPP TS 26.512 [67].

4.4.33.2 Procedure for Media Streaming Event Exposure Subscription Creation

This procedure is used by an event consumer AF to subscribe to at least one Media Streaming Exposure event at the NEF.

In order to subscribe to at least one Media Streaming Exposure event, an event consumer AF shall send a Nnef_MSEventExposure_Subscribe request message to the NEF using the HTTP POST method and targeting the "Media Streaming Event Exposure Subscriptions" collection resource, with the request message body including the AfEventExposureSubsc data structure, as specified in clause 5.28.2.2.3.2.

The NEF shall then check whether the event consumer AF is authorized to perform this operation or not. If the event consumer AF is authorized, the NEF shall then trigger the Naf_EventExposure API of the data collection AF to request the creation of the corresponding Application Event Subscriptions at the AF, as specified in 3GPP TS 29.517 [58].

Upon reception of a successful response from the data collection AF, as defined in 3GPP TS 29.517 [58], the NEF shall return a Nnef_MSEventExposure_Subscribe response message with an HTTP "201 Created" status code including a "Location" header field that shall contain the URI of the created resource, i.e. "{apiRoot}/3gpp-ms-event-exposure/v1/subscriptions/{subscriptionId}", and the response body containing a representation of the created "Individual Media Streaming Event Exposure Subscription" resource within the AfEventExposureSubsc data structure, as specified in clause 5.28.2.2.3.2.

On failure or if the NEF receives an error response from the data collection AF, the NEF shall take proper error handling actions, as specified in clause 5.28.7, and respond to the event consumer AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.33.3 Procedure for Media Streaming Event Exposure Subscription Update

This procedure is used by an event consumer AF to update an existing Media Streaming Event Exposure Subscription at the NEF.

In order to update an existing Media Streaming Event Exposure Subscription, the event consumer AF shall send a Nnef_MSEventExposure_Subscribe request message to the NEF using the HTTP PUT method and targeting the "Individual Media Streaming Event Exposure Subscription" resource, with the request message body including the AfEventExposureSubsc data structure, as specified in clause 5.28.2.3.3.2.

The NEF shall then check whether the event consumer AF is authorized to perform this operation or not. If the event consumer AF is authorized, the NEF shall then trigger the Naf_EventExposure API of the data collection AF to request the update of the corresponding Individual Application Event Subscription at the AF, as specified in 3GPP TS 29.517 [58].

Upon reception of a successful response from the data collection AF, as defined in 3GPP TS 29.517 [58], the NEF shall return a Nnef_MSEventExposure_Subscribe response message with an HTTP "200 OK" status code with the AfEventExposureSubsc data structure or “204 No Content” status code, as specified in clause 5.28.2.3.3.2.

4.4.33.4 Procedure for Media Streaming Event Exposure Unsubscription

This procedure is used by an event consumer AF to request the deletion of an existing Media Streaming Event Exposure Subscription at the NEF.

In order to request the deletion of an existing Media Streaming Event Exposure Subscription, an event consumer AF shall send a Nnef_MSEventExposure_Unsubscribe request message using the HTTP DELETE method and targeting the URI of the concerned "Individual Media Streaming Event Exposure Subscription" resource.

The NEF shall then check whether the event consumer AF is authorized to perform this operation or not. If the AF is authorized, the NEF shall then trigger the Naf_EventExposure service API of the data collection AF to request the deletion of the corresponding Application Event Subscription at the AF, as specified in 3GPP TS 29.517 [58].

Upon reception of a successful response from the data collection AF, as defined in 3GPP TS 29.517 [58], the NEF shall return a Nnef_MSEventExposure_Unsubscribe response message with an HTTP "204 No Content" status code.

On failure or if the NEF receives an error code from the data collection AF, the NEF shall take proper error handling actions, as specified in clause 5.28.7, and respond to the event consumer AF with an appropriate error status code. If the NEF received within an error response a "ProblemDetails" data structure with a "cause" attribute indicating an application error, the NEF shall relay this error response to the AF with a corresponding application error, when applicable.

4.4.33.5 Procedure for Media Streaming Event Exposure Notification

This procedure is used by the NEF to send a Media Streaming Event Exposure notification to a previously subscribed event consumer AF.

In order to send a Media Streaming Event Exposure notification, the NEF shall send a Nnef_MSEventExposure_Notify request message to the AF using the HTTP POST method and targeting the notification URI provided during the creation/update of the corresponding subscription, with the request body including the MSEventExposureNotif data structure as specified in clause 5.28.4.2.3.1.

Upon success, the event consumer AF shall send a Nnef_MSEventExposure_Notify response message with an HTTP "204 No Content" status code.

On failure, the event consumer AF shall take proper error handling actions, as specified in subclause 5.28.7, and respond to the NEF with an appropriate error status code.