Content for &nbsp; TS 23.502 &nbsp; Word version:&nbsp; 18.1.1

A consumer of event exposure for events detected in AMF or SMF (e.g. NWDAF) sends an Nudm_EventExposure Subscribe/Unsubscribe request to the UDM for a UE or group of UEs, including the subscription details (Event ID, Event filters, etc.).

UDM examines the event type and subscription details to determine whether one or more events are to be detected by the AMF. In this case, for those applicable events that are detected by the AMF, if an AMF is registered in UDM for the UE (or for a UE that is member of the group of UEs), UDM creates an Namf_EventExposure Subscribe/Unsubscribe request and sends it to the AMF of the UE, including the subscription details.

AMF answers with an Namf_EventExposure Subscribe/Unsubscribe response.

UDM examines the event type and subscription details to determine whether one or more events are to be detected by the SMF. In this case, for those applicable events that are detected by the SMF, if one or more SMFs are registered in UDM for the UE (or for a UE that is member of the group of UEs), UDM creates an Nsmf_EventExposure Subscribe/Unsubscribe request and sends it to each applicable SMF of the UE, including the subscription details.

SMF answers with an Nsmf_EventExposure Subscribe/Unsubscribe response.

Table 4.15.4.5.1-1: Input parameters in subscription to UPF event Exposure events

UDM sends an Nudm_EventExposure Subscribe/Unsubscribe response to the consumer of event exposure.

4.15.4.5 Exposure of Events from UPF for UPF Data Collection |R18| p. 376

4.15.4.5.1 General p. 376

This clause contains the detailed description and the procedures for how the UPF event exposure service (see clause 5.2.26.2) is used for UPF data collection.

The list of NF consumer which may receive UPF event notifications is defined in clause 5.8.2 of TS 23.501.

To get exposure data from UPF, NF consumer may subscribe to the UPF directly or indirectly via SMF. This is further defined in clause 5.8.2 of TS 23.501.

The UPF event exposure events are described in clause 5.2.26.2. In this Release of the specification, the following events are used for UPF Data collection:

QoS Monitoring: This event provides QoS Flow performance information.
UserDataUsageMeasures: This event provides information of user data usage of the User PDU Session.
UserDataUsageTrends: This event provides statistics related to user data usage of the User PDU Session.

A consumer of UPF event exposure can subscribe to QoS monitoring event via SMF only and UPF sends the QoS Flow Performance information directly to this consumer. For this event, the interaction between SMF and UPF is over PFCP (TS 29.244).

The subscription request can trigger in SMF end to end UL/DL delay measurements but only for QoS flows that have already been established. Clause 5.33.3 of TS 23.501 describes how end to end UL/DL delay measurements for QoS flows are activated and measured triggered by a PCC rule received in SMF. By default, the Subscription request for QoS monitoring event refers to the QoS Flow associated to the default QoS rule. The subscription can target the QoS flows bound to an application by including an application identifier.

A consumer of UPF event exposure such as NWDAF can subscribe to User Data Usage events directly to UPF or via SMF, and UPF sends the event notifications directly to this consumer. For this event, the interaction between SMF and UPF is over SBI. For User Data Usage events, the subscription request may target specific service data flows (e.g. a specific application traffic) by including a traffic description (e.g. an Application Id). Else, the scope of the subscription is all the traffic in the PDU Session. The subscription request may indicate certain granularity for the information e.g. how many differentiated measurements are requested.

If the event notification can be delayed, i.e. delay tolerant, Reporting suggestion information is included. The Reporting suggestion information includes Report urgency and Reporting time information. Reporting urgency information indicates whether this event report can be delay tolerant, i.e. the event report can be delayed. If the Reporting urgency information indicates "delay tolerant", the Reporting time is also provided, which defines the last valid reporting time, and UPF shall report the detected event before the last valid time.

Information	To SMF	To UPF
UE ID	Y	Y
GroupID	Y	N
AnyUE	Y	Y
DNN	Y	Y
S-NSSAI	Y	Y
AOI	Y	N
BSSID/SSID	Y	N
DNAI (NOTE 3)	Y	N
UPFId (NOTE 3)	Y	N
Type of Measurement	Y	Y
Granularity of Measurement (NOTE 2)	Y	Y
Application ID (NOTE 1)	Y	Y
Traffic Filtering (NOTE 1), (NOTE 2)	Y	Y
Reporting suggestion information	Y	Y
NOTE 1: Application ID and Traffic Filtering are exclusive. NOTE 2: This parameter does not apply to QoS monitoring event. NOTE 3: This parameter is used to indicate a UP Path as defined in Table 6.4.1-1 of TS 23.288.

4.15.4.5.2 Information flow for subscription to UPF event exposure service for certain UE(s) via SMF p. 377

Reproduction of 3GPP TS 23.502, Fig. 4.15.4.5.2-1: Subscription to UPF event exposure service for certain UE(s) via SMF

Figure 4.15.4.5.2-1: Subscription to UPF event exposure service for certain UE(s) via SMF

In the case of a group of UEs, the UPF event consumer (e.g. NWDAF) first issues an Nnrf_NFDiscovery_Request service operation to find the UDM providing the target Group ID and gets the NF profile of the UDM serves this group. Then, NWDAF obtains the list of SUPIs that correspond to the Group ID from UDM using Nudm_SDM_Get

Then, for each SUPI:

The UPF event consumer (e.g. NWDAF) invokes Nudm_UECM_Get service operation to retrieve the appropriate SMF by providing UE ID, DNN, S-NSSAI and NF type = SMF.

The UDM provides a Nudm_UECM_Get response with the corresponding SMF.

The UPF event consumer sends the Nsmf_EventExposure Subscription request to the SMF to subscribe to UPF data, including the following information:

Notification Target Address (UPF event consumer address), Notification Correlation Information.
Indication of UPF Event Exposure Service and Target subscription UPF Event Id.
Event Filter Information: S-NSSAI, DNN, DNAI,UPF Id, Traffic Description for the target traffic (e.g. Application Id), Area of Interest, SSID/BSSID.
Target of Event Reporting: a UE.
Reporting suggestion information.
Target Subscription information: Type of Measurement and granularity of the information requested.

The SMF selects the PDU session(s) and the UPFs it has to send the request to. SMF sends the request to the UPF including the UPF event consumer address, Notification Correlation Information, Event Filter Information, Reporting suggestion information, Target of Event Reporting, and Target Subscription Information as required. Target of Event Reporting is certain UE. The interaction mechanism used between SMF and UPF depends on UPF exposure event (see clause 5.2.26.2.1). It could be as in 4a with N4 Session Modification with PFCP (TS 29.244) or as in 4b with Nupf_event exposure subscribe request (as defined in clause 5.2.26.2.3).

Figure 4.15.4.5.3-1: UPF Information Exposure to the UPF event consumer (e.g. NWDAF) of any UE scenario

Per Reporting suggestion information(if available), the UPF sends the locally collected UPF data by invoking Nupf_EventExposure_Notify service operation to the UPF event consumer.

4.15.4.5.3 Information flow for UPF event exposure service for any UE p. 378

Reproduction of 3GPP TS 23.502, Fig. 4.15.4.5.3-1: UPF Information Exposure to the UPF event consumer (e.g. NWDAF) of any UE scenario

(in the case of NWDAF) The analytics consumer sends a request to the NWDAF for analytics on any UE. The consumer provides the any UE in the Target of Analytics Reporting. Analytics Filter Information optionally contains DNN, S-NSSAI, Area of Interest, Application server IP address/FQDN, APP ID, DNAI, etc.

(Optional and only when the UPF event consumer is NWDAF) If in the analytic filter information does not contain DNN/S-NSSAI, but only application server IP address/FQDN, the NWDAF should firstly obtain the DNAI from NEF. The NWDAF invokes Nnef_DNAIMapping_Subscribe service to request the DNAI information. The request includes EAS IP/IP range and/or FQDN.

(if step 2 took place) The NEF determines the suitable DNAI(s) and answers to NWDAF.

The the UPF event consumer triggers the SMFs/UPFs discovery to NRF by Nnrf_NFDiscovery_Request providing the DNN, S-NSSAI, DNAI etc. This procedure is to discover the related SMFs/UPFs associated with any UE and support the indicated DNAI. SMF or UPF(s) are discovered depending on whether the subscription request to UPF events meets the criteria for direct subscription to UPF as as defined in clause 5.8.2 of TS 23.501).

The NRF provides Nnrf_NFDiscovery_Response that may refer to several SMFs/UPFs.

(Option 1) If the subscribed UPF events needs the SMFs to do a third-party subscription onto UPF (as defined in clause 5.8.2 of TS 23.501), the same procedure as Indirect subscription via several SMFs (steps 3 - 5 in Figure 4.15.4.6.2-1 (for single UE)) takes place via each discovered SMF.

Figure 4.15.6.2-1: Nnef_ParameterProvision_Create / Nnef_ParameterProvision_Update / Nnef_ParameterProvision_Delete request/response operations

(Option 2) If the subscribed UPF events allows to directly subscribe to UPF (as defined in clause 5.8.2 of TS 23.501), the UPF event consumer (e.g. NWDAF) triggers the Nupf_EventExposure_Subscribe to all discovered UPFs. The information included in the subscription is the same as step 3 in Figure 4.15.4.5.3-1.

Step 8.

Each UPFs invokes Nupf_EventExposure_Notify service operation directly to the UPF event consumer (e.g. NWDAF).

4.15.5 Void

4.15.6 External Parameter Provisioning p. 379

4.15.6.1 General p. 379

Provisioning capability allows an external party to provision the information, such as expected UE behaviour and service specific parameters or the 5G VN group information to 5G network functions. In the case of provisioning the expected UE behavioural information, the expected UE behavioural information consists of information on expected UE movement and communication characteristics. In the case of provisioning the 5G VN group information the provisioning information consists of information on 5G VN group. The service specific information consists of information to support the specific service in 5G system. Provisioned data can be used by the other NFs.

4.15.6.2 NEF service operations information flow p. 380

Reproduction of 3GPP TS 23.502, Fig. 4.15.6.2-1: Nnef_ParameterProvision_Create / Nnef_ParameterProvision_Update / Nnef_ParameterProvision_Delete request/response operations

Step 0.

NF subscribes to UDM notifications of UE and/or Group Subscription data updates. In the UDM subscription, the NF may request to be notified about expected UE behaviour parameter(s) in Table 4.15.6.3-1 that may have been externally provisioned by an AF.

If an expected UE behaviour parameter subscription is provided by the NF, the subscription may include a threshold indicating that certain confidence and/or accuracy levels must be met for the parameter(s) to be notified by UDM to the NF. Meeting the threshold condition may mean that a parameter is equal to a certain threshold, or less than a certain threshold, or greater than a certain threshold, or less than or equal to a certain threshold, or greater than or equal to a certain threshold. The threshold may be in the form of a range (e.g. minimum value to maximum value, where each may be inclusive or exclusive) or a specific value.

Step 0b.

[Conditional, on using NWDAF-assisted values] The AF may subscribe to NWDAF via NEF in order to learn the UE mobility analytics and/or UE Communication analytics for a UE or group of UEs by applying the procedure specified in clause 6.1.1.2 of TS 23.288. The Analytics ID is set to any of the values specified in clause 6.7.1 of TS 23.288.

Step 0c.

[Conditional, on using NWDAF-assisted values] AF validates the received data and derives any of the Expected UE behaviour parameters defined in clause 4.15.6.3 for a UE or group of UEs.

The AF provides one or more parameter(s) to be created or updated , or deleted in a Nnef_ParameterProvision_Create or Nnef_ParameterProvision_Update or Nnef_ParameterProvision_Delete Request to the NEF. The parameters(s) may include corresponding confidence and/or accuracy levels.

The GPSI identifies the UE and the Transaction Reference ID identifies the transaction request between NEF and AF. For the case of Nnef_ParameterProvision_Create, The NEF assigns a Transaction Reference ID to the Nnef_ParameterProvision_Create request.

NEF checks whether the requestor is allowed to perform the requested service operation by checking requestor's identifier (i.e. AF Identifier).

For a Create request associated with a 5G VN group, the External Group ID identifies the 5G VN Group.

The payload of the Nnef_ParameterProvision_Update Request includes one or more of the following parameters:

Expected UE Behaviour parameters (see clause 4.15.6.3); or
Network Configuration parameters (see clause 4.15.6.3a); or
External Group Id and 5G VN group data (i.e. 5G VN configuration parameters) (see clause 4.15.6.3b), or
5G VN group membership management parameters (see clause 4.15.6.3c); or
Location Privacy Indication parameters of the "LCS privacy" Data Subset of the Subscription Data (see clause 5.2.3.3.1 and clause 7.1 of TS 23.273); or
MTC Provider Information; or
AF provided ECS Address Configuration Information (see clause 4.15.6.3d); or
DNN and S-NSSAI specific Group Parameters (see clause 4.15.6.3e).

The AF may request to delete 5G VN configuration by sending Nnef_ParameterProvision_Delete to the NEF.

If the AF is authorised by the NEF to provision the parameters, the NEF requests to create, update and store, or delete the provisioned parameters as part of the subscriber data via Nudm_ParameterProvision_Create, Nudm_ParameterProvision_Update or Nudm_ParameterProvision_Delete Request message, the message includes the provisioned data and NEF reference ID and optionally MTC Provider Information.

If the AF is not authorised to provision the parameters, then the NEF continues in step 6 indicating the reason to failure in Nnef_ParameterProvision_Create/Update/Delete Response message. Step 7 does not apply in this case.

If the NEF did not receive DNN and/or S-NSSAI from the AF and such information is configured as needed within 5GC, the NEF determines the DNN and/or S-NSSAI from the AF Identifier.

If the AF provides the DNN and S-NSSAI specific Group Parameters, the AF shall indicate the External Group ID, targeted DNN and S-NSSAI in the request.

If the AF provides the service area in the form of geographical information, the NEF maps the geographical information to the list of TAs.

UDM may read from UDR, by means of Nudr_DM_Query, corresponding subscription information in order to validate required data updates and authorize these changes for this subscriber or Group for the corresponding AF.

Based on local configuration, UDM may determine if there is any requirement in terms of threshold conditions that need to be met by the provisioned parameter before storing the parameter in UDR. If satisfied, UDM may proceed seamlessly. If not satisfied, step 5 is triggered as a failed procedure and a related cause value is provided, e.g. "confidence level not sufficient". In that case step 4 is skipped.

If the AF is authorised by the UDM to provision the parameters for this subscriber, the UDM resolves the GPSI to SUPI and requests to create, update or delete the provisioned parameters as part of the subscriber data via Nudr_DM_Create/Update/Delete Request message, the message includes the provisioned data.

If a new 5G VN group is created, the UDM shall assign a unique Internal Group ID for the 5G VN group and include the newly assigned Internal Group ID in the Nudr_DM_Create Request message. If the list of 5G VN group members is changed or if 5G VN group data has changed, the UDM updates the UE and/or Group subscription data according to the AF/NEF request.

When the service area is configured or updated for a group, the UDM authorises the request.

If the Default QoS is configured or updated for a group, the UDM authorises the request and uses such Default QoS to set 5GS Subscribed QoS profile in Session Management Subscription data for each UE within the group. The 5GS Subscribed QoS profile in Session Management Subscription data will be considered by SMF as described in clause 5.7.2.7 of TS 23.501.

UDR stores the provisioned data as part of the UE and/or Group subscription data and responds with Nudr_DM_Create/Update/Delete Response message.

If the Group-MBR is configured or updated for a group, the UDM authorises the request and the Group-MBR is applied as described in clause 5.29a.1.3 of TS 23.501.

When the 5G VN group data (as described in clause 4.15.6.3b) or 5G VN group membership is updated, the UDR notifies to the subscribed PCF by sending Nudr_DM_Notify as defined in clause 4.16.12.2.

If the AF is not authorised to provision the parameters, then the UDM continues in step 5 indicating the reason to failure in Nudm_ParameterProvision_Update Response message and step 7 is not executed.

The UDM classifies the received parameters (i.e. Expected UE Behaviour parameters or Suggested Number of Downlink Packets or the 5G VN configuration parameters or DNN and S-NSSAI specific Group Parameters or Location Privacy Indication parameters or ECS Address Configuration Information), into AMF associated and SMF associated parameters. The UDM may use the AF Identifier received from the NEF in step 2 to relate the received parameter with a particular subscribed DNN and/or S-NSSAI. The UDM stores the SMF-Associated parameters under corresponding Session Management Subscription data type.

Each parameter or parameter set may be associated with a validity time. The validity time is stored at the UDM/UDR and in each of the NFs, to which parameters are provisioned (e.g. in AMF or SMF). Upon expiration of the validity time, each node deletes the parameters autonomously without explicit signalling.

If the ECS Address Configuration Information is provided to any UE in AF request, the UDM shall make use of the shared data mechanism defined in TS 29.503 and notify all NFs (SMFs) that have subscribed to receiving such shared data change notifications.

UDM responds the request with Nudm_ParameterProvision_Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.

NEF responds the request with Nnef_ParameterProvision_Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.

Table 4.15.6.3-1: Description of Expected UE Behaviour parameters

[Conditional this step occurs only after successful step 4] UDM notifies the subscribed Network Function (e.g. AMF) of the updated UE and/or Group subscription data via Nudm_SDM_Notification Notify message.

If the NF is AMF, the UDM performs Nudm_SDM_Notification (SUPI or Internal Group Identifier, AMF-Associated Expected UE Behaviour parameters, Subscribed Periodic Registration Timer, subscribed Active Time, 5G VN group data or DNN and S-NSSAI specific Group Parameters, etc.) service operation. If the AMF receives confidence and/or accuracy levels along the Expected UE behaviour parameter(s), the AMF may use the associated confidence level and/or accuracy level when handling the expected UE behaviour parameter(s). The AMF uses the received parameters to derive the appropriate UE configuration of the NAS parameters and to derive Core Network assisted RAN parameters. The AMF may determine a Registration area based on parameters Stationary indication or Expected UE Moving Trajectory.
If the AMF obtains service area for a group the AMF configures the DNN for the group as LADN DNN and applies the LADN per DNN and S-NSSAI taking into account the service area for the group as described in clause 5.20b.2 of TS 23.501.
If the NF is SMF, the UDM performs Nudm_SDM_Notification (SUPI or Internal Group Identifier, SMF-Associated Expected UE Behaviour parameter set, DNN/S-NSSAI, Suggested Number of Downlink Packets, 5G VN group data or DNN and S-NSSAI specific Group Parameters, etc.) service operation.
The SMF stores the received parameters and associates them with a PDU Session based on the DNN and S-NSSAI included in the message from UDM.
If the SMF obtains service area for a group the SMF configures the DNN for the group as LADN DNN.
If the SMF receives confidence and/or accuracy levels along the Expected UE behaviour parameter(s), the SMF may use the associated confidence level and/or accuracy level when handling the expected UE behaviour parameter(s). The SMF may use the parameters as follows:
- SMF configures the UPF accordingly. The SMF can use the Scheduled Communication Type parameter or Suggested Number of Downlink Packets parameter to configure the UPF with how many downlink packets to buffer. The SMF may use Communication duration time parameter and/or Expected Inactivity Time parameter and/or Battery Indication parameter combined with their confidence/accuracy levels to set the inactivity timer for a PDU Session. The SMF then waits for a UP inactivity report to be received from UPF. Based on the received UP inactivity report, the SMF may determine to deactivate a UP connection for a single UE or determine a collective pattern of deactivating UP connections for multiple UEs (e.g. for a group of UEs receiving application AI/ML traffic during FL operation) and perform CN-initiated selective deactivation of UP connection of an existing PDU Session.
- The SMF may derive SMF derived CN assisted RAN information for the PDU Session. The SMF provides the SMF derived CN assisted RAN information to the AMF as described in PDU Session establishment procedure or PDU Session modification procedure.

4.15.6.3 Expected UE Behaviour parameters p. 383

These Expected UE Behaviour parameters characterise the foreseen behaviour of a UE or a group of UEs. Sets of these parameters may be provided via the NEF to be stored as part of the subscriber data. Each parameter within the Expected UE Behaviour shall have an associated validity time. The validity time indicates when the Expected UE Behaviour parameter expires and shall be deleted by the related NFs. The validity time may be set to indicate that the particular Expected UE Behaviour parameter has no expiration time. When the validity time expires, the related NFs delete their local copy of the associated Expected UE Behaviour parameter(s). In addition, each parameter within the Expected UE Behaviour may have a confidence and/or accuracy level associated with it. The confidence level indicates a probability assertion for the associated Expected UE Behaviour parameter and the accuracy level indicates the performance of the estimator (e.g. AI/ML model) used for the prediction. The provision procedure of the Expected UE Behaviour is realized by external parameter provision procedure defined in clause 4.15.6.2.

The Expected UE Behaviour parameters stored as AMF-Associated Expected UE Behaviour parameters which is per UE level and SMF-Associated Expected UE Behaviour parameters which is per PDU session level in UDM. AMF retrieves the AMF-Associated Expected UE Behaviour parameters from UDM which may related to both PDU session(s) and SMS transmission. SMF retrieves the SMF-Associated Expected UE Behaviour parameters from UDM for the specific PDU session. AMF and SMF uses the Expected UE Behaviour parameters as described in clause 5.4.6.2 in TS 23.501.

Expected UE Behaviour parameter	Description
Expected UE Moving Trajectory	Identifies the UE's expected geographical movement Example: A planned path of movement
Stationary Indication	Identifies whether the UE is stationary or mobile [optional]
Communication Duration Time	Indicates for how long the UE will normally stay in CM-CONNECTED for data transmission. Example: 5 minutes. [optional]
Periodic Time	Interval Time of periodic communication Example: every hour. [optional]
Scheduled Communication Time	Time and day of the week when the UE is available for communication. Example: Time: 13:00-20:00, Day: Monday. [optional]
Battery Indication	Identifies power consumption criticality for the UE: if the UE is battery powered with not rechargeable/not replaceable battery, battery powered with rechargeable/replaceable battery, or not battery powered. [optional]
Traffic Profile	Identifies the type of data transmission: single packet transmission (UL or DL), dual packet transmission (UL with subsequent DL or DL with subsequent UL), multiple packets transmission [optional]
Scheduled Communication Type	Indicates that the Scheduled Communication Type is Downlink only or Uplink only or Bi-directional [To be used together with Scheduled Communication Time] Example: <Scheduled Communication Time>, DL only. [optional]
Expected Time and Day of Week in Trajectory	Identifies the time and day of week when the UE is expected to be at each location included in the Expected UE Moving Trajectory. [optional]
Expected Inactivity Time	Identifies the expected PDU Session Inactivity time during which the UE will not be providing application AI/ML related data. [optional] Editor's note: Whether and how Expected Inactivity Time parameter can be made independent of the type of application is FFS.

The Expected UE Moving Trajectory and the Expected Time and Day of Week in Trajectory may be used by the AMF. All other parameters may be used by the AMF and by the SMF.The Scheduled Communication Type and the Traffic Profile should not be used by the AMF to release the UE when NAS Release Assistance Information from the UE is available.

In the case of NB-IoT UEs, the parameters may be forwarded to the RAN to allow optimisation of Uu resource allocation for NB-IoT UE differentiation.

4.15.6.3a Network Configuration parameters |R16| p. 384

The Network Configuration parameters are the parameters sent from an AF by invoking the Nnef_ParameterProvision Service as described in clause 4.15.6.2.

The Network Configuration parameters are described in Table 4.15.6.3a-1.

Table 4.15.6.3a-1: Description of Network Configuration parameters

Network Configuration parameter	Description
Maximum Response Time	Identifies the time for which the UE stays reachable to allow the AF to reliably deliver the required downlink data. [optional]
Maximum Latency	Identifies maximum delay acceptable for downlink data transfers. Example: in order of 1 minute to multiple hours. [optional]
Suggested Number of Downlink Packets	Identifies the number of packets that the core network is suggested to buffer if the UE is not reachable. Example: 5 packets. [optional]

The parameters Maximum Response Time and Maximum Latency are stored in the UDM and the Maximum Response Time is sent to the AMF for event monitoring as specified in clause 4.15.3.2.3b.

The AMF may use the Maximum Response Time parameter as guide to configure:

Extended Connected time for MICO mode;
when to send reachability notifications to AF relative to expected reachability events (e.g. paging occasions).

If the UDM received multiple Network Configuration requests, the UDM shall accept the request as long as the Maximum Latency (if received) and/or the Maximum Response Time (if received) are within the range defined by operator policies. The UDM shall use the minimum value of Maximum Latency(s) to derive the subscribed periodic registration timer and use the maximum value of Maximum Response Time(s) to derive the subscribed Active Time as specified in step 2 of clause 4.15.3.2.3b. If the newly derived value is changed comparing to the one last time sent to the AMF, the UDM notify the AMF of the updated value via Nudm_SDM_Notification message. If there is a deletion of Network Configuration request, the UDM re-calculates the values (see step 2 in clause 4.15.3.2.3b) and notify the AMF if needed.

The Suggested Number of Downlink Packets is classified as SMF associated subscription data. If the NEF is providing DNN and S-NSSAI as specified in clause 4.15.3.2.3, then the UDM is able to associate the parameters with subscribed DNN and S-NSSAI and provides the Suggested Number of Downlink Packets consolidated as specified in 4.15.3.2.3b to the SMF for the PDU Session associated with the specific DNN and S-NSSAI as specified in clause 4.15.6.2. The SMF may use the Suggested Number of Downlink Packets parameter to configure the number of packets to buffer in the SMF/UPF (in the case of UPF anchored PDU sessions) or in the NEF (in the case of NEF anchored PDU session) when the UE is not reachable and extended buffering of downlink data is activated.

A Validity Time may be associated with any of the Network Configuration parameters. When the validity time expires, the related NFs delete their local copy of the associated Network Configuration parameter(s). If the deletion results in subscribed value change, the UDM shall notify the AMF or SMF of the changed value.

4.15.6.3b 5G VN group data |R16| p. 385

The 5G VN group data is described in Table 4.15.6.3b-1.

Table 4.15.6.3b-1: Description of 5G VN group data

Parameters	Description
DNN	DNN for the 5G VN group
S-NSSAI	S-NSSAI for the 5G VN group
PDU Session Type	PDU Session Types allowed for 5G VN group
Application descriptor	There may be multiple instances of this information; this information may be used to build URSP sent to 5G VN group members (NOTE 1)
Information related with secondary authentication / authorization	This may indicate: the need for secondary authentication/authorization (as defined in clause 5.6 of TS 23.501); the need for SMF to request the UE IP address from the DN-AAA Server. If at least one of secondary authentication/authorization or DN-AAA UE IP address allocation is needed, the AF may provide DN-AAA Server addressing information.
5G VN group communication indication	Indicates that the 5G VN group is associated with 5G VN group communication.
NOTE 1: As described in TS 23.503, the PCF may be configured with a mapping from Application Descriptor to other information required to construct the URSP rules, e.g. IP filters and SSC mode.

The information described in Table 4.15.6.3b-1 corresponds to 5G VN group data that an AF may provide together with External Group ID.

4.15.6.3c 5G VN Group membership management parameters |R16| p. 386

5G VN group membership management parameters that an AF may provide are described in Table 4.15.6.3c-1.

Table 4.15.6.3c-1: Description of 5G VN Group membership management parameters

Parameters	Description
List of GPSI	List of 5G VN Group members, each member is identified by GPSI
External Group ID	A identifier for 5G VN group

4.15.6.3d ECS Address Configuration Information Parameters |R17| p. 386

AF provided ECS Address Configuration Information that an AF may provide to the 5GC is described in Table 4.15.6.3d-1. The AF may associate ECS Address Configuration Information with a group of UE or with any UE.

Multiple AF may configure 5GC with AF provided ECS Address Configuration Information.

The Subscription provided ECS Address Configuration Information that a SMF may receive is described in Table 4.15.6.3d-2

For non-roaming and LBO cases, the ECS Address Configuration Information is provided to SMF as Session Management Subscription data. The ECS Address Configuration Information is associated with a DNN and S-NSSAI included in the message from UDM.

For HR cases, when the HPLMN has the knowledge of EACI in the VPLMN, the ECS Address Configuration Information is provided to H-SMF as Session Management Subscription data. The ECS Address Configuration Information is associated with a DNN, S-NSSAI and PLMN ID included in the message from UDM.

The SMF is not expected to understand the internal structure of ECS Address Configuration Information.

Table 4.15.6.3d-1: Description of ECS Address Configuration Information provided by the AF

Parameters	Description
ECS Address Configuration Information	One or more ECS Configuration Information as defined in clause 8.3.2.1 of TS 23.558.
Target	This may correspond to one of: a group of UE identified by an external group Id; any UE.
PLMN ID	The ECS Address Configuration Information is applied to the UE roaming in target PLMN.

Table 4.15.6.3d-2: Description of Subscription provided ECS Address Configuration Information (as sent to the SMF)

Parameters	Description
ECS Address Configuration Information	As defined in Table 4.15.6.3d-1. The SMF is not expected to understand the internal structure of ECS Address Configuration Information.

4.15.6.3e DNN and S-NSSAI specific Group Parameters |R18| p. 387

The DNN and S-NSSAI specific Group Parameters are the parameters sent from an AF by invoking the Nnef_ParameterProvision Service as described in clause 4.15.6.2.

The DNN and S-NSSAI specific Group Parameters are described in Table 4.15.6.3e-1.

Table 4.15.6.3e-1: Description of DNN and S-NSSAI specific Group Parameters

Parameters	Description
Default QoS (NOTE 1)	Identifies the requested default QoS parameters (as defined in clause 5.7.2.7 in TS 23.501) applicable to each UE within a group. [optional]
Service Area (NOTE 1)	Identifies the AF-requested Service Area applicable to each UE within a group. [optional]
Group-MBR (NOTE 1)	This limits the total bit rate that is expected to be provided across all sessions of a group. [optional]
NOTE 1: These parameters are applicable per DNN and S-NSSAI.

4.15.6.4 Set a chargeable party at AF session setup p. 388

Reproduction of 3GPP TS 23.502, Fig. 4.15.6.4-1: Set the chargeable party at AF session set-up

Figure 4.15.6.4-1: Set the chargeable party at AF session set-up

When setting up the connection between an ASP sponsoring a session and the UE, the ASP may communicate with the AF to request to become the chargeable party for the session to be set up by sending a Nnef_ChargeableParty_Create request message (AF Identifier, UE address, Flow description information or External Application Identifier, Sponsor Information, Sponsoring Status, Background Data Transfer Reference ID, DNN, S-NSSAI) to the NEF. The Sponsoring Status indicates whether sponsoring is started or stopped, i.e. whether the 3rd party service provider is the chargeable party or not. The Background Data Transfer Reference ID parameter identifies a previously negotiated transfer policy for background data transfer as defined in clause 4.16.7. The NEF assigns a Transaction Reference ID to the Nnef_ChargeableParty_Create request.

The NEF authorizes the AF request to sponsor the application traffic and stores the sponsor information together with the AF Identifier and the Transaction Reference ID. If the authorisation is not granted, step 2 is skipped and the NEF replies to the AF with a Result value indicating that the authorisation failed.

The NEF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Create request message and provides IP filter information or Ethernet filter information, sponsored data connectivity information (as defined in TS 23.503), Background Data Transfer Reference ID (if received from the AF) and Sponsoring Status (if received from the AF) to the PCF.

The PCF determines whether the request is allowed and notifies the NEF if the request is not authorized. If the request is not authorized, NEF responds to the AF in step 5 with a Result value indicating that the authorization failed.

Figure 4.15.6.5-1: Change the chargeable party during the session

The NEF sends a Nnef_ChargeableParty_Create response message (Transaction Reference ID, Result) to the AF. Result indicates whether the request is granted or not.

4.15.6.5 Change the chargeable party during the session p. 389

Reproduction of 3GPP TS 23.502, Fig. 4.15.6.5-1: Change the chargeable party during the session

For the ongoing AF session, the AF may send a Nnef_ChargeableParty_Update request message (AF Identifier, Transaction Reference ID, Sponsoring Status, Background Data Transfer Reference ID) to the NEF. The Sponsoring Status indicates whether sponsoring is enabled or disabled, i.e. whether the 3rd party service provider is the chargeable party or not. The Background Data Transfer Reference ID parameter identifies a previously negotiated transfer policy for background data transfer as defined in clause 4.16.7. The Transaction Reference ID provided in the Change chargeable party request message is set to the Transaction Reference ID that was assigned, by the NEF, to the a Nnef_ChargeableParty_Create request.

The NEF authorizes the AF request of changing the chargeable party. If the authorisation is not granted, step 3 is skipped and the NEF replies to the AF with a Result value indicating that the authorisation failed.

The NEF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request and provides IP filter information or Ethernet filter information, sponsored data connectivity information (as defined in TS 23.503), Background Data Transfer Reference ID (if received from the AF) and Sponsoring Status (if received from the AF) to the PCF.

Figure 4.15.6.6-1: Setting up an AF session with required QoS procedure

The NEF sends a Nnef_ChargeableParty_Update response message (Transaction Reference ID, Result) to the AF. Result indicates whether the request is granted or not.

4.15.6.6 Setting up an AF session with required QoS procedure p. 390

Reproduction of 3GPP TS 23.502, Fig. 4.15.6.6-1: Setting up an AF session with required QoS procedure

The AF sends a request to reserve resources for an AF session using Nnef_AFsessionWithQoS_Create request message (UE address, AF Identifier, Flow description information or External Application Identifier, QoS Reference or individual QoS parameters, PDU Set QoS parameters, Protocol Description, Alternative Service Requirements (as described in clause 6.1.3.22 of TS 23.503), DNN, S-NSSAI) to the NEF. Optionally, QoS monitoring requirements and Multi-modal Service ID can be included in the AF request. Optionally, a period of time or a traffic volume for the requested QoS can be included in the AF request. The AF may, instead of a QoS Reference, provide one or more of the following individual QoS parameters: Requested 5GS Delay (optional), Requested Priority (optional), Requested Guaranteed Bitrate, Requested Maximum Bitrate, Maximum Burst Size and Requested Packet Error Rate. Regardless of whether the AF request is formulated using a QoS Reference or individual QoS parameters, the AF may also provide one or more of the following parameters that describe the traffic characteristics: flow direction, Burst Arrival Time at UE (uplink) or UPF (downlink), Periodicity, Time domain, Survival Time, Capability for BAT adaptation or BAT Window, Periodicity Range. The AF may also provide an RT Latency Indication. The optional Alternative Service Requirements provided by the AF shall either contain QoS References or Requested Alternative QoS Parameter Set(s) in a prioritized order as described in clause 6.1.3.22 of TS 23.503.

The NEF assigns a Transaction Reference ID to the Nnef_AFsessionWithQoS_Create request. The NEF authorizes the AF request and may apply policies to control the overall amount of QoS authorized for the AF. If the authorisation is not granted, all steps (except step 5) are skipped and the NEF replies to the AF with a Result value indicating that the authorisation failed.

The NEF determines whether to invoke the TSCTSF or to directly contact the PCF. This determination may use the presence of a QoS Reference or individual QoS parameters in the AF request. The determination may also use the AF identifier or the presence of AF provided parameters that describe the traffic characteristics. The determination may also be based on operator configuration, e.g. SLA between operator and application provider.

If the NEF determines not to invoke the TSCTSF, then steps 3, 4, 5, 6, 7, 8 are executed, otherwise, steps 3a, 3b, 4a, 4b, 5, 6a, 7a, 7b, 8 are executed.

If the NEF determines to contact the PCF directly without invoking the TSCTSF, the NEF uses the UE address to discover the PCF from the BSF. The NEF forwards received parameters to the PCF in the Npcf_PolicyAuthorization_Create request. Any optionally received QoS monitoring requirements and Multi-modal Service ID are forwarded to the PCF to support the delivery of multi-modal services (as defined in TS 23.503). Any optionally received period of time or traffic volume mapped and forwarded as sponsored data connectivity information (as defined in TS 23.503).

If the AF is considered to be trusted by the operator, the AF uses the Npcf_PolicyAuthorization_Create request message to interact directly with PCF to request reserving resources for an AF session.

Step 3a.

If the NEF determines to invoke the TSCTSF, the NEF forwards received parameters in the Ntsctsf_QoSandTSCAssistance_Create request message to the TSCTSF. Any optionally received period of time or traffic volume is mapped and forwarded as sponsored data connectivity information (as defined in TS 23.503).

If the AF is considered to be trusted by the operator, the AF uses the Ntsctsf_QoSandTSCAssistance_Create request message to interact directly with TSCTSF to request reserving resources for an AF session.

A TSCTSF address may be locally configured (a single TSCTSF per DNN/S-NSSAI) in the NEF, PCF and trusted AF. Alternatively, the NEF uses the AF Identifier to determine the DNN/S-NSSAI and uses the DNN/S-NSSAI to discover the TSCTSF from the NRF.

Step 3b.

The TSCTSF determines whether it has an AF session with a PCF for the given UE address. In this case the TSCTSF sends a Npcf_PolicyAuthorization_Update request message to the PCF and forwards the received parameters after executing the adjustment and mapping actions described below.

If the TSCTSF does not have an AF-session for a given UE address, the TSCTSF discovers the PCF and a Npcf_PolicyAuthorization_Create request message to the PCF.

If the TSCTSF receives a Requested 5GS Delay, the TSCTSF calculates a Requested PDB by subtracting the UE-DS-TT Residence Time (either provided by the PCF or pre-configured at TSCTSF) from the Requested 5GS Delay and sends the Requested PDB to the PCF instead of the Requested 5GS Delay. If the TSCTSF receives any of the following parameters: flow direction, Burst Arrival Time, Periodicity, Time domain, Survival Time, Capability for BAT adaptation or BAT Window, Periodicity Range from the NEF, the TSCTSF determines the TSC Assistance Container and sends it to the PCF instead of these parameters.

For requests received from the NEF in step 3, the PCF determines whether the request is authorized and notifies the NEF if the request is not authorized.

If the request is authorized, the PCF derives the required QoS parameters of the PCC rule based on the information provided by the NEF and determines whether this QoS is allowed (according to the PCF configuration) and notifies the result to the NEF. If the events subscribed for the QoS monitoring by the NEF, the PCF generates the QoS monitoring policy for the service data flow based on the information provided by the NEF. If the AF is considered to be trusted by the operator, the PCF sends the Npcf_PolicyAuthorization_Create response message directly to AF.

If the PCF receives the individual QoS parameters instead of QoS Reference, the PCF determines a 5QI that matches the individual QoS parameters as described in clause 6.1.3.22 of TS 23.503. It also sets the GBR and MBR for the PCC rule according to the requested values. The PCF may use the Requested Priority from the AF to determine Priority Level as defined in clause 5.7.3.3 of TS 23.501. Requested individual QoS parameter values supersede default values for the 5QI.

If the PCF receives the RT Latency Indication described in clause 6.1.3.22 of TS 23.503, the PCF executes Uplink-Downlink Transmission Coordination as described in clause 5.37.7 of TS 23.501.

If the PCF receives PDU Set QoS parameters described in clause 5.7.7 of TS 23.501, the PDU Set QoS parameters are applied as described in clause 6.1.3.22 of TS 23.503.

In addition, if the Alternative Service Requirements are provided, the PCF derives the Alternative QoS parameter set(s) in the same way from the one or more QoS Reference parameters or the Requested Alternative QoS Parameter Set(s) contained in the Alternative Service Requirements keeping the same prioritized order (as defined in clause 6.1.3.22 of TS 23.503).

If received, the PCF takes into account the Multi-modal Service ID to derive the required QoS parameters in the PCC rules and QoS monitoring requirements for each media flow that comprise a multi-modal service.

If the PCF determines that the SMF needs updated policy information, the PCF issues a Npcf_SMPolicyControl_UpdateNotify request with updated policy information about the PDU Session as described in the PCF initiated SM Policy Association Modification procedure in clause 4.16.5.2.

Step 4a.

For requests received from the TSCTSF in step 3b, the PCF determines whether the request is authorized and notifies the TSCTSF if the request is not authorized.

If the request is authorized, the PCF derives the required QoS parameters of the PCC rule in the same way it is described in step 4 based on the information provided by the TSCTSF and determines whether this QoS is allowed (according to the PCF configuration) and notifies the result to the TSCTSF.

If the PCF receives a subscription for the 5GS Bridge/Router information from the TSCTSF, if the PCF does not have the 5GS Bridge/Router information for the PDU Session, the PCF uses the PCF initiated SM Policy Association Modification procedure as described in clause 4.16.5.2 to subscribe for 5GS Bridge/Router information event from the SMF. Once the PCF has the 5GS Bridge/Router information, the PCF notifies the TSCTSF for the 5GS Bridge/Router information (including the UE-DS-TT Residence Time).

Step 4b.

The TSCTSF sends a Ntsctsf_QoSandTSCAssistance_Create response message (Transaction Reference ID, Result) to the NEF. Result indicates whether the request is granted or not.

If the AF is considered to be trusted by the operator, the TSCTSF sends the Ntsctsf_QoSandTSCAssistance_Create response message directly to AF.

The NEF sends a Nnef_AFsessionWithQoS_Create response message (Transaction Reference ID, Result) to the AF. Result indicates whether the request is granted or not.

The NEF shall send a Npcf_PolicyAuthorization_Subscribe message to the PCF to subscribe to notifications of Resource allocation status and may subscribe to other events described in clause 6.1.3.18 of TS 23.503.

Step 6a.

The TSCTSF shall send a Npcf_PolicyAuthorization_Subscribe message to the PCF to subscribe to notifications of Resource allocation status and may subscribe to other events described in clause 6.1.3.18 of TS 23.503.

The TSCTSF that receives Capability for BAT adaptation or BAT Window in step 3a shall subscribe to notification on BAT offset via sending a Npcf_PolicyAuthorization_Subscribe request message to the PCF.

Figure 4.15.6.6a-1: AF session with required QoS update procedure

When the event condition is met, e.g. that the establishment of the transmission resources corresponding to the QoS update succeeded or failed, the PCF sends Npcf_PolicyAuthorization_Notify message to the NEF notifying about the event.

If the AF is considered to be trusted by the operator, the PCF sends the Npcf_PolicyAuthorization_Notify message directly to AF.

Step 7a.

Step 7b.

The TSCTSF sends Ntsctsf_QoSandTSCAssistance_Notify message with the event reported by the PCF to the NEF.

If the AF is considered to be trusted by the operator, the TSCTSF sends the Ntsctsf_QoSandTSCAssistance_Notify message directly to AF.

Step 8.

The NEF sends Nnef_AFsessionWithQoS_Notify message with the event reported by the PCF to the AF.

The AF may send Nnef_AFsessionWithQoS_Revoke request to NEF in order to revoke the AF request. The NEF authorizes the revoke request and triggers the Ntsctsf_QoSandTSCAssistance_Delete/Unsubscribe and/or Npcf_PolicyAuthorization_Delete and the Npcf_PolicyAuthorization_Unsubscribe operations for the AF request.

4.15.6.6a AF session with required QoS update procedure |R16| p. 393

Reproduction of 3GPP TS 23.502, Fig. 4.15.6.6a-1: AF session with required QoS update procedure

For an established AF session with required QoS, the AF may send a Nnef_AFsessionWithQoS_Update request message (AF Identifier, Transaction Reference ID, [Flow description information], [QoS Reference or individual QoS parameters], [PDU Set QoS parameters, Protocol Description], [Alternative Service Requirements (as described in clause 6.1.3.22 of TS 23.503)]) to NEF for updating the reserved resources. Optionally, updated QoS monitoring requirements can be included in the AF request. Optionally, a period of time or a traffic volume for the requested QoS can be included in the AF request. The Transaction Reference ID provided in the AF session with required QoS update request message is set to the Transaction Reference ID that was assigned, by the NEF, to the Nnef_AFsessionWithQoS_Create request message. The AF may, instead of a QoS Reference, provide one or more of the following individual QoS parameters: Requested 5GS Delay (optional), Requested Priority (optional), Requested Guaranteed Bitrate, Requested Maximum Bitrate, Maximum Burst Size and Requested Packet Error Rate. Regardless whether the AF request is formulated using a QoS Reference or individual QoS parameters, the AF may also provide one or more of the following parameters that describe the traffic characteristics: flow direction, Burst Arrival Time at UE (uplink) or UPF (downlink), Periodicity, Time domain, Survival Time, Capability for BAT adaptation or BAT Window, Periodicity Range. The optional Alternative Service Requirements provided by the AF shall either contain QoS References or Requested Alternative QoS Parameter Set(s) in a prioritized order as specified in clause 6.1.3.22 of TS 23.503.

The NEF authorizes the AF request of updating AF session with required QoS and may apply policies to control the overall amount of QoS authorized for the AF. If the authorisation is not granted, all steps (except step 5) are skipped and the NEF replies to the AF with a Result value indicating that the authorisation failed.

The NEF shall contact the same NF type (i.e. TSCTSF or PCF) as with the initial Nnef_AFsessionWithQoS_Create request during the establishment procedure in clause 4.15.6.6. If the NEF determined not to invoke the TSCTSF, then steps 3, 4, 5, 6, 7 are executed, otherwise, steps 3a, 3b, 4a, 4b, 5, 6a, 6b, 7 are executed. If the Nnef_AfsessionWithQoS_Update request updates an existing Flow description by adding any parameters that would require the NEF to invoke TSCTSF while the NEF determined not to invoke the TSCTSF for the initial Nnef_AFsessionWithQoS_Create request, the NEF shall reject the Nnef_AFsessionWithQoS_Update request with a cause value which may indicate the reason of failure.

If the NEF does not invoke the TSCTSF, the NEF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request and forwards received parameters to the PCF. Any optionally received period of time or traffic volume is mapped and forwarded as sponsored data connectivity information (as defined in TS 23.503).

If the AF is considered to be trusted by the operator, the AF uses the Npcf_PolicyAuthorization_Update request message to interact directly with PCF to update the reserving resources for an AF session.

Step 3a.

If the NEF decided to contact the TSCTSF when the session was established, the NEF forwards received parameters in the Ntsctsf_QoSandTSCAssistance_Update request message to the TSCTSF. Any optionally received period of time or traffic volume is mapped and forwarded as sponsored data connectivity information (as defined in TS 23.503).

If the AF is considered to be trusted by the operator, the AF uses the Ntsctsf_QoSandTSCAssistance_Update request message to interact directly with TSCTSF to update the reserving resources for an AF session.

Step 3b.

The TSCTSF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request and forwards the received parameters after executing the adjustment and mapping actions described in step 3b of clause 4.15.6.6.

The PCF processes the Npcf_PolicyAuthorization_Update request according to the actions described in step 4 of clause 4.15.6.6. If the QoS monitoring requirements are updated, the PCF updates the PCC rules considering the updated QoS information provided by the AF.

Step 4a.

The PCF processes the Npcf_PolicyAuthorization_Update request according to the actions described in step 4a of clause 4.15.6.6. If the PCF has received a request to unsubscribe for 5GS Bridge/Router information Notification, the PCF uses the PCF initiated SM Policy Association Modification procedure as described in clause 4.16.5.2 to unsubscribe for 5GS Bridge/Router information event from the SMF.

Step 4b.

The TSCTSF sends a Ntsctsf_QoSandTSCAssistance_Update response message (Transaction Reference ID, Result) to the NEF. Result indicates whether the request is granted or not.

If the AF is considered to be trusted by the operator, the TSCTSF sends the Ntsctsf_QoSandTSCAssistance_Update response message directly to AF.

The NEF sends a Nnef_AFsessionWithQoS_Update response message (Transaction Reference ID, Result) to the AF. Result indicates whether the request is granted or not.

The PCF sends Npcf_PolicyAuthorization_Notify message to the NEF when the modification of the transmission resources corresponding to the QoS update succeeded or failed, or when an Alternative Service Requirement is being applied.

If the AF is considered to be trusted by the operator, the PCF sends the Npcf_PolicyAuthorization_Notify message directly to AF.

Step 6a.

The PCF sends Npcf_PolicyAuthorization_Notify message to the TSCTSF when the modification of the transmission resources corresponding to the QoS update succeeded or failed, or when an Alternative Service Requirement is being applied.

Step 6b.

The TSCTSF sends Ntsctsf_QoSandTSCAssistance_Notify message with the event reported by the PCF to the NEF.

If the AF is considered to be trusted by the operator, the TSCTSF sends the Ntsctsf_QoSandTSCAssistance_Notify message directly to the AF.