Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.4…   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2…   4.11.3…   4.12…   4.12.6…   4.12a…   4.12b…   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25…   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…
4.15.4 Core Network Internal Event Exposure4.15.4.1 General4.15.4.2 Exposure of Mobility Events from AMF4.15.4.3 Exposure of Communication trends from SMF4.15.4.4 Internal Event Exposure Subscription/Unsubscription via UDM4.15.6 External Parameter Provisioning4.15.6.1 General4.15.6.2 NEF service operations information flow4.15.6.3 Expected UE Behaviour parameters4.15.6.3a Network Configuration parameters4.15.6.3b 5G VN group data4.15.6.3c 5G VN Group membership management parameters4.15.6.3d ECS Address Configuration Information Parameters4.15.6.4 Set a chargeable party at AF session setup4.15.6.5 Change the chargeable party during the session4.15.6.6 Setting up an AF session with required QoS procedure4.15.6.6a AF session with required QoS update procedure4.15.6.7 Service specific parameter provisioning4.15.6.8 Set a policy for a future AF session4.15.6.9 Procedures for AF-triggered dynamically changing AM policies4.15.6.10 Application guidance for URSP determination4.15.7 Network status reporting4.15.8 Event exposure controlled by a DCCF4.15.9 Time Synchronization exposure4.15.9.1 General4.15.9.2 Exposure of UE availability for Time Synchronization service4.15.9.3 Time Synchronization activation, modification, and deactivation4.15.9.4 Time Synchronization using 5G Reference time distribution: activation, modification, and deactivation
...

 

4.15.4  Core Network Internal Event Exposure

4.15.4.1  General

The exposure of events internally within the 5GC NFs is explained in the following clauses. Only the event notifications that are independent of the ongoing system procedure are specified in this clause. For the event notifications that are part of the system procedure, see the system procedure descriptions under clause 4.2 to clause 4.14.

4.15.4.2  Exposure of Mobility Events from AMFWord‑p. 345

The AMF invokes the Namf_EventExposure_Notify to provide mobility related events to NF consumers that have subscribed for the events by invoking Namf_EventExposure_Subscribe, in the following scenarios listed below and after Namf_EventExposure_Subscribe service operation.
  • During Registration procedure, Inter NG-RAN node N2 based handover procedure, when there is a change of AMF (within the same AMF Set or across the AMF Set), the new AMF receives all event subscriptions from old AMF or UDSF. For each event subscription:
    if the event subscription only applies to the UE, the new AMF allocates a new Subscription Correlation ID and notify the NF consumer of the new Subscription Correlation ID associated with the change of Subscription Correlation ID event.
    if the event subscription applies to a group of UE(s) and there is no corresponding subscription for this group (identified by the internal group Id and notification endpoint) at the new AMF, the new AMF shall create corresponding event subscription, allocate a new Subscription Correlation Id and send it to the received notification endpoint, i.e. Notification Target Address (+Notification Correlation Id), associated with the addition of Subscription Correlation ID event. The initial Maximum number of reports and the remaining number of reports within the Maximum number of reports quota for the UE is transferred from the old AMF.
  • During Registration procedure, when there is a change of AMF, the new AMF notifies each NF that has subscribed for UE reachability event about the UE reachability status.
  • During Registration, Handover, UE Triggered Service Request procedure in CM-IDLE state, Location Reporting, N2 Notification and AN Release procedures, the AMF determines the UE presence in Area Of Interest (i.e. IN, OUT or UNKNOWN status ) as described in Annex D.1 and notifies the NF Consumers of the UE presence in an Area Of Interest if the NF consumers (e.g. SMF) had subscribed for this Area Of Interest, and if the UE presence in Area Of Interest is different from the one reported earlier.
  • During Registration and Handover procedure or during Service Area Restriction update by UDM or PCF, if the UE is moving from an Allowed Area to a Non-Allowed Area, then the AMF informs all the NF consumers (e.g. SMF), that have subscribed for UE reachability event, that the UE is reachable only for regulatory prioritized service. The SMF shall explicitly subscribe UE reachability unless the established PDU Session is related to regulatory prioritized service.
  • If the AMF had notified an SMF of the UE being reachable only for regulatory prioritized service earlier, the AMF informs the NF consumers (e.g. SMF), that have subscribed for UE reachability event, that the UE is reachable if the UE enters into Allowed Area.
  • During Registration procedure and Service Request procedure, if the AMF had notified an SMF earlier of the UE being unreachable and that SMF need not invoke Namf_Communication_N1N2MessageTransfer to the AMF due to DL data notifications, the AMF informs the SMF when the UE becomes reachable.
  • During Registration procedure and Service Request procedure, if the AMF had notified an SMF earlier that the UE is unreachable together with an Estimated Maximum Wait time, then the AMF informs the SMF when the UE becomes reachable. When the SMF learns that the UE is reachable and:
    • if the SMF performs Extended Buffering for a PDU session, the SMF sends the buffered data to the UPF and invokes the Namf_Communication_N1N2MessageTransfer service operation to the AMF to establish the User Plane(s) for the PDU Sessions, or the buffered data is delivered to the UE as per the procedure in clause 4.24.2 starting from step 2g for a PDU session using Control Plane CIoT 5GS Optimisation;
    • if the UPF performs Extended Buffering for a PDU session, the SMF invokes the Namf_Communication_N1N2MessageTransfer service operation to the AMF to establish the User Plane(s) for the PDU Sessions, or the buffered data is delivered to the UE as per the procedure in clause 4.24.2 starting from step 8a for a PDU session using Control Plane CIoT 5GS Optimisation.
  • If NEF had subscribed for UE reachability event notification for Extend Buffering, then the AMF informs the NEF when the UE becomes reachable. When the NEF learns that the UE is reachable, it invokes the Nsmf_NIDD_Delivery service operation of the corresponding SMF to deliver the buffered data to the UE as per the procedure in the clause 4.25.5 starting from step 2 for a PDU session using Control Plane CIoT 5GS Optimisation.
  • During Registration procedure, Handover without Registration procedure, and Service Request procedure, if the NF consumers had subscribed for UE reachability status, the AMF notifies the UE reachability status changes.
  • If the Mobile Reachable Timer expires the AMF notifies the NF consumers that have subscribed for the corresponding events that the UE is not reachable.
  • If the UDM had subscribed for UE reachability event notification either to be reported to the UDM or to an NF consumer directly, then the AMF notifies the UE reachability event to the UDM or to the NF consumer as specified in clause 4.2.5.2.
  • If UE's TAC is already known by the AMF, then, the AMF notifies UE TAC to the NF consumers (e.g. to NWDAF). If UE TAC is unknown, then the AMF notifies the UE TAC when it obtained the UE TAC from the UE.
During Connection, Registration and Mobility Management procedures, the AMF may store and update the UE access behaviour trends specified in Table 4.15.4.2-1 and the UE location trends specified in Table 4.15.4.2-2. Each metrics is updated incrementally, e.g. using exponential moving average. This information is exposed to consumer NFs (e.g. NWDAF) that subscribe for the event ID "UE access behaviour trends" and/or "UE location trends", respectively, by invoking Namf_EventExposure_Subscribe.
Information Description
UE IdentitySUPI
List of state transitions
> State transition typeState transition identifier:
  • "Access Type change to 3GPP access",
  • "Access Type change to non-3GPP access",
  • "RM state change to RM-DEREGISTERED",
  • "RM state change to RM-REGISTERED ",
  • "CM state change to CM-IDLE",
  • "CM state change to CM-CONNECTED",
  • "Handover", or
  • "Mobility Registration Update".
> SpacingAverage and variance of the time interval separating two consecutive occurrences of the state transition.
> DurationAverage and variance of duration in the resulting state.
 
Information Description
UE IdentitySUPI
List of location information (1..N)
> UE LocationTAI, Cell-ID (if available), non-3GPP access identity.
> SpacingAverage and variance of the time interval separating two consecutive arrivals at this location.
> DurationAverage and variance of duration of stay in the location.
> TimestampTimestamp of last arrival in the location.
NOTE:
The maximum size of the list (N) is defined per configuration and only the N entries with the highest average value of "Duration" are kept in the list. The list is ordered by descending order of "Duration".
Up

4.15.4.3  Exposure of Communication trends from SMF |R17|Word‑p. 346

During Session Management procedures, the SMF may store and update the UE access behaviour trends specified in Table 4.15.4.3-1 and the UE communication trends specified in Table 4.15.4.3-2. Each metrics is updated incrementally, e.g. using exponential moving average. This information is exposed to consumer NFs (e.g. NWDAF) that subscribe for the event ID "UE session behaviour trends" and/or "UE communication trends", respectively, by invoking Nsmf_EventExposure_Subscribe.
Information Description
UE IdentitySUPI
List of state transitions
> State transition typeState transition identifier:
  • "PDU Session Establishment",
  • "PDU Session Release",
  • "Communication failure", or
  • "PLMN change".
> SpacingAverage and variance of the time interval separating two consecutive occurrences of the state transition.
 
Information Description
UE IdentitySUPI
List of communication information (1..N)
> Communication characteristicsS-NSSAI and DNN
> SpacingAverage and variance of the time interval separating two consecutive PDU Session Establishment procedures corresponding to the communication characteristics.
> DurationAverage and variance of duration of PDU Sessions corresponding to the communication characteristics.
> TimestampTimestamp of the last PDU Session Establishment procedure corresponding to the communication characteristics.
NOTE:
The maximum size of the list (N) is defined per configuration and only the N entries with the highest average value of "Duration" are kept in the list. The list is ordered by descending order of "Duration".
Up

4.15.4.4  Internal Event Exposure Subscription/Unsubscription via UDM |R17|Word‑p. 347

This clause describes an indirect method of event exposure subscription in AMF and SMF via UDM for a UE or group of UEs. This can be used after the removal of UE context in the AMF including event exposure subscriptions, or the creation of new UE context in AMF or SMF. In this case, the UDM is responsible for (re)creating event exposure subscriptions in AMF and SMF.
Reproduction of 3GPP TS 23.502, Figure 4.15.4.4-1: Internal Event exposure subscription/unsubscription in AMF or SMF via UDM
Up
Step 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.).
Step 2.
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.
Step 3.
AMF answers with an Namf_EventExposure Subscribe/Unsubscribe response.
Step 4.
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.
Step 5.
SMF answers with an Nsmf_EventExposure Subscribe/Unsubscribe response.
Step 6.
UDM sends an Nudm_EventExposure Subscribe/Unsubscribe response to the consumer of event exposure.
Up

4.15.5Void

4.15.6  External Parameter ProvisioningWord‑p. 348

4.15.6.1  General

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

4.15.6.2  NEF service operations information flowWord‑p. 349

Reproduction of 3GPP TS 23.502, Figure 4.15.6.2-1: Nnef_ParameterProvision_Create / Nnef_ParameterProvision_Update / Nnef_ParameterProvision_Delete request/response operations
Up
Step 0.
NF subscribes to UDM notifications of UE and/or Group Subscription data updates.
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.
Step 1.
The AF provides one or more parameter(s) to be created or updated in a Nnef_ParameterProvision_Create or Nnef_ParameterProvision_Update or Nnef_ParameterProvision_Delete Request to the NEF.
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 ID).
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:
The AF may request to delete 5G VN configuration by sending Nnef_ParameterProvision_Delete to the NEF.
Step 2.
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 NEF receives AF provided ECS Address Configuration Information with Spatial Validity Condition referring to a geographical area, the NEF translates the Spatial Validity Condition into one of a Presence Reporting Area.
Step 3.
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.
Step 4.
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.
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.
When the 5G VN group data (as described in clause 4.15.6.3b) 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 Location Privacy Indication parameters or ECS Address Configuration Information), into AMF associated and SMF associated parameters. The UDM may use the AF ID 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.
Step 5.
UDM responds the request with Nudm_ParameterProvision_Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
Step 6.
NEF responds the request with Nnef_ParameterProvision_Create/Update/Delete Response. If the procedure failed, the cause value indicates the reason.
Step 7.
[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.
  1. 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, etc.) service operation. The AMF identifies whether there are overlapping parameter set(s) and merges the parameter set(s) in the Expected UE Behaviour, if necessary. 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.
  2. 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, 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.
    The SMF identifies whether there are overlapping parameter set(s) in the Expected UE behaviour and merges the parameter set(s), if necessary. 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 the parameter Communication duration time to determine to deactivate UP connection and to 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.
Up

4.15.6.3  Expected UE Behaviour parametersWord‑p. 351

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 associating 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). 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 IndicationIdentifies 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]
 
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.
Up

4.15.6.3a  Network Configuration parameters |R16|Word‑p. 352

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

4.15.6.3b  5G VN group data |R16|Word‑p. 353

The 5G VN group data is described in Table 4.15.6.3b-1.
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.
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.
Up

4.15.6.3c  5G VN Group membership management parameters |R16|Word‑p. 354

5G VN group membership management parameters that an AF may provide are described in Table 4.15.6.3c-1.
Parameters Description
List of GPSIList of 5G VN Group members, each member is identified by GPSI
External Group IDA identifier for 5G VN group
Up

4.15.6.3d  ECS Address Configuration Information Parameters |R17|

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 one UE identified by its GPSI, a group of UE or with any UE.
The AF-provided ECS Address Configuration Information may include DNN and/or S-NSSAI to be associated with the ECS Address Configuration Information. If it is not included in the AF-provided ECS Address Configuration Information, this may be determined by the NEF based on the AF Identifier.
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
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.
Parameters Description
ECS Address Configuration InformationConsists of:
  • one or more FQDN(s) and/or IP Address(es) of Edge Configuration Server(s);
  • an ECS Provider ID. The identifier of the Edge Configuration Server (ECS) Provider (such as Edge Computing Service Provider).
Spatial Validity ConditionThe Spatial Validity Condition may correspond to one of following alternatives:
  • a geographical area;
  • a Presence Reporting Area;
  • a list of TA(s);
  • a list of countries (list of MCC);
where ECS Address Configuration Information is applicable.
TargetThis may correspond to one of:
  • a UE identified by its GPSI;
  • a group of UE identified by an external group Id;
  • any UE.
 
Parameters Description
ECS Address Configuration Information As defined in Table 4.15.6.3d-1. The SMF is not to assumed to understand the internal structure of ECS Address Configuration Information.
Spatial Validity Condition As defined in Table 4.15.6.3d-1 but without the possibility of a geographical area and the possibility of a list of MCC.
Up

4.15.6.4  Set a chargeable party at AF session setupWord‑p. 356

Reproduction of 3GPP TS 23.502, Figure 4.15.6.4-1: Set the chargeable party at AF session set-up
Up
Step 1.
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(s) 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.
Step 2.
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.
Step 3.
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.
Step 4.
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.
Step 5.
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.
Up

4.15.6.5  Change the chargeable party during the sessionWord‑p. 357

Reproduction of 3GPP TS 23.502, Figure 4.15.6.5-1: Change the chargeable party during the session
Up
Step 1.
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.
Step 2.
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.
Step 3.
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.
Step 4.
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.
Step 5.
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.
Up

4.15.6.6  Setting up an AF session with required QoS procedureWord‑p. 358

Reproduction of 3GPP TS 23.502, Figure 4.15.6.6-1: Setting up an AF session with required QoS procedure
Up
Step 1.
The AF sends a request to reserve resources for an AF session using Nnef_AFsessionWithQoS_Create request message (UE address, AF Identifier, Flow description(s) or External Application Identifier, QoS reference, (optional) Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order), DNN, S-NSSAI) to the NEF. Optionally, a period of time or a traffic volume for the requested QoS can be included in the AF request. The NEF assigns a Transaction Reference ID to the Nnef_AFsessionWithQoS_Create request. The AF may in addition provide the following individual QoS parameters: Requested 5GS delay (optional), priority (optional), Requested GFBR, Requested MFBR, flow direction, Burst Size (optional), Burst Arrival Time (optional) at UE (uplink) or UPF (downlink), Periodicity (optional), Time domain (optional), Survival Time (optional). When Alternative Service Requirements are provided by the AF, a set of Alternative QoS Related parameters as in clause 5.7.1.2a of TS 23.501 (e.g. one or more from Alternative Requested GFBR, Alternative Requested MFBR) may be provided for each QoS Reference.
Step 2.
The NEF authorizes the AF request and may apply policies to control the overall amount of pre-defined 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.
If the NEF does not receive any of the individual QoS parameters as described in clause 6.1.3.22 of TS 23.503 from the AF, the steps 3, 4, 5, 6, 7, 8 are executed, otherwise, the steps 3a, 3b, 4a, 4b, 5, 6a, 7a, 7b, 8 are executed.
Step 3.
If the NEF does not receive any of the individual QoS parameters from the AF as described in clause 6.1.3.22 of TS 23.503, the NEF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Create request and provides UE address, AF Identifier, Flow description(s), the QoS reference and the optional Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order). Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (as defined in TS 23.503).
If Alternative QoS Related parameter set(s) are provided by the AF, they are sent to the PCF via TSCTSF. The TSCTSF determines the 5GS delay considering UE-DS-TT residence time.
Step 3a.
If the NEF receives any of the individual QoS parameters as described in clause 6.1.3.22 of TS 23.503 from the AF, the NEF forwards these received individual QoS parameters in the Ntsctsf_QoSandTSCAssistance_Create request message to the TSCTSF.
Step 3b.
The TSCTSF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Create request and provides UE address, AF Identifier, Flow description(s), the QoS reference and the optional Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order). Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (as defined in TS 23.203).
If the TSCTSF receives the Requested 5GS delay, the TSCTSF calculates a Requested PDB by subtracting the UE-DS-TT residence time from the Requested 5GS delay. If the TSCTSF receives any of the flow direction, Burst Arrival Time, Periodicity, Time domain, Survival Time from the NEF, the TSCTSF forwards these parameters in the TSC Assistance Container in the Npcf_PolicyAuthorization_Create request to the PCF. The TSCTSF sends the Requested PDB, the TSC Assistance Container, and other received individual QoS parameters in the Npcf_PolicyAuthorization_Create request to the PCF.
Step 4.
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 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. In addition, if the Alternative Service Requirements are provided, the PCF derives the Alternative QoS parameter set(s) from the one or more QoS reference parameters contained in the Alternative Service Requirements in the same prioritized order (as defined in TS 23.503).
If the NEF provides Alternative QoS Related parameter set(s), then for each set, the PCF sets the PDB in the corresponding Alternative QoS parameter set as in clause 5.7.1.2a of TS 23.501. It also sets the GFBR and MFBR according to the alternative requested values sent by the NEF. NEF specified parameter values are used to over-ride default values for the 5QI corresponding to the NEF provided QoS Reference in the Alternative Service Requirements.
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.
If the request is not authorized, or the required QoS is not allowed, NEF responds to the AF in step 5 with a Result value indicating the failure cause.
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 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. In addition, if the Alternative Service Requirements are provided, the PCF derives the Alternative QoS parameter set(s) from the one or more QoS reference parameters contained in the Alternative Service Requirements in the same prioritized order (as defined in TS 23.503).
The PCF sets the PDB and MDBV according to the received Requested PDB and Burst Size received from the TSCTSF. If the Requested PDB is not provided, the PCF determines the PDB that matches the QoS Reference. It also sets the GFBR and MFBR according to requested values sent by the TSCTSF. TSCTSF specified parameter values are used to over-ride default values for the 5QI corresponding to the TSCTSF provided QoS Reference.
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.
If the request is not authorized, or the required QoS is not allowed, TSCTSF responds to the NEF in step 4b with a Result value indicating the failure cause.
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.
Step 5.
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.
Step 6.
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.
Step 7.
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.
Step 7a.
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 TSCTSF notifying about the event.
Step 7b.
The TSCTSF sends Ntsctsf_QoSandTSCAssistance_Notify message with the event reported by the PCF to the NEF.
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.
Up

4.15.6.6a  AF session with required QoS update procedure |R16|Word‑p. 361

Reproduction of 3GPP TS 23.502, Figure 4.15.6.6a-1: AF session with required QoS update procedure
Up
Step 1.
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(s)], [QoS reference], [Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order)]) to NEF for updating the reserved resources. 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 in addition provide the following individual QoS parameters: Requested 5GS delay (optional), priority (optional), Requested GFBR, Requested MFBR, flow direction, Burst Size (optional), Burst Arrival Time (optional) at UE (uplink) or UPF (downlink), Periodicity (optional), Time domain (optional), Survival Time (optional). When Alternative Service Requirements are provided by the AF, a set of Alternative QoS Related parameters as specified in clause 5.7.1.2a of TS 23.501 (e.g. one or more from Alternative Requested GFBR, Alternative Requested MFBR) may be provided for each QoS Reference.
Step 2.
The NEF authorizes the AF request of updating AF session with required QoS and may apply policies to control the overall amount of pre-defined 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.
If the NEF does not receive any of the individual QoS parameters as described in clause 6.1.3.22 of TS 23.503 from the AF, then the steps 3, 4, 5, 6, 7 are executed, otherwise, the steps 3a, 3b, 4a, 4b, 5, 6a, 6b, 7 are executed.
Step 3.
If the NEF does not receive any of the individual QoS parameters from the AF as described in clause 6.1.3.22 of TS 23.503, the NEF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request and provides UE address, AF Identifier, Flow description(s), the QoS reference and the optional Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order). Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (as defined in TS 23.503).
If Alternative QoS Related parameter set(s) are provided by the AF, they are sent to the PCF via TSCTSF. The TSCTSF determines the 5GS delay considering UE-DS-TT residence time.
Step 3a.
If the NEF receives one or more of the individual QoS parameters as described in clause 6.1.3.22 of TS 23.503 from the AF, the NEF forwards these received individual QoS parameters in the Ntsctsf_QoSandTSCAssistance_Update request message to the TSCTSF.
Step 3b.
The TSCTSF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request and provides UE address, AF Identifier, Flow description(s), the QoS reference and the optional Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order). Any optionally received period of time or traffic volume is also included and mapped to sponsored data connectivity information (as defined in TS 23.203).
If the TSCTSF receives the Requested 5GS delay, the TSCTSF calculates a Requested PDB by subtracting the UE-DS-TT residence time from the Requested 5GS delay. If the Requested PDB is not provided, the PCF determines the PDB that matches the QoS Reference.
If the TSCTSF receives any of the flow direction, Burst Arrival Time, Periodicity, Time domain, Survival Time from the NEF, the TSCTSF forwards these parameters in the TSC Assistance Container in the Npcf_PolicyAuthorization_Update request to the PCF. The TSCTSF sends the Requested PDB, the TSC Assistance Container, and other received individual QoS parameters in the Npcf_PolicyAuthorization_Update request to the PCF.
Step 4.
If the PCF received request from the NEF in step 3, the PCF determines whether the request is authorized.
If the request is authorized, the PCF derives the required QoS parameters 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. In addition, if the Alternative Service Requirements are provided, the PCF derives the Alternative QoS parameter set(s) from the one or more QoS reference parameters contained in the Alternative Service Requirements in the same prioritized order (as defined in TS 23.503).
If the NEF provides Requested PDB, Requested GFBR, Requested MFBR or Burst Size, then the PCF sets the PDB and/or MDBV according to the received Requested PDB and Burst Size received from the NEF. It also sets the GFBR and MFBR according to the requested values provided by the NEF. NEF specified parameter values are used to over-ride default values for the 5QI corresponding to the NEF provided QoS Reference. If the NEF provides Alternative QoS Related parameter set(s), then for each set, the PCF sets the PDB and MDBV in the corresponding Alternative QoS parameter set as described in clause 6.1.3.22 of TS 23.503. It also sets the GFBR and MFBR according to the alternative requested values sent by the NEF. NEF specified parameter values are used to over-ride default values for the 5QI corresponding to the NEF provided QoS Reference in the Alternative Service Requirements.
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.
If the request is not authorized or the required QoS is not allowed, NEF responds to the AF in step 5 with a Result value indicating the failure cause.
Step 4a.
If the PCF received request from the TSCTSF in step 3b, the PCF determines whether the request is authorized.
If the request is authorized, the PCF derives the required QoS parameters based on the information provided by the TSCTSF and determines whether this QoS is allowed (according to the PCF configuration for this AF), and notifies the result to the TSCTSF. In addition, if the Alternative Service Requirements are provided, the PCF derives the Alternative QoS parameter set(s) from the one or more QoS reference parameters contained in the Alternative Service Requirements in the same prioritized order (as defined in TS 23.503).
If the TSCTSF provides Requested PDB, priority, Requested GFBR, Requested MFBR or Burst Size, then the PCF sets the PDB and/or MDBV according to the received Requested PDB and Burst Size received from the TSCTSF. If the Requested PDB is not provided from TSCTSF, the PCF determines the PDB that matches the QoS Reference. It also sets the GFBR and MFBR according to the requested values provided by the TSCTSF. TSCTSF specified parameter values are used to over-ride default values for the 5QI corresponding to the TSCTSF provided QoS Reference.
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.
If the request is not authorized or the required QoS is not allowed, TSCTSF responds to the NEF in step 4b with a Result value indicating the failure cause.
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.
Step 5.
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.
Step 6.
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.
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.
Step 6b.
The TSCTSF sends Ntsctsf_QoSandTSCAssistance_Notify message with the event reported by the PCF to the NEF.
Step 7.
The NEF sends Nnef_AFsessionWithQoS_Notify message with the event reported by the PCF to the AF.
Up

4.15.6.7  Service specific parameter provisioning |R16|Word‑p. 363

This clause describes the procedures for enabling the AF to provide service specific parameters to 5G system via NEF.
The AF may issue requests on behalf of applications not owned by the PLMN serving the UE.
The AF request sent to the NEF contains the information as below:
  1. Service Description.
    Service Description is the information to identify a service the Service Parameters are applied to. The Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an External Application Identifier.
  2. Service Parameters.
    Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
  3. Target UE(s) or a group of UEs.
    Target UE(s) or a group of UEs indicate the UE(s) who the Service Parameters shall be delivered to. Individual UEs can be identified by GPSI, or an IP address/Prefix or a MAC address. Groups of UEs can be identified by an External Group Identifiers as defined in TS 23.682. If identifiers of target UE(s) or a group of UEs are not provided, then the Service Parameters shall be delivered to any UEs using the service identified by the Service Description.
  4. Subscription to events.
    The AF may subscribe to notifications about the outcome of the UE Policies delivery due to service specific parameter provisioning.
The NEF authorizes the AF request received from the AF and stores the information in the UDR as "Application Data". The Service Parameters are delivered to the targeted UE by the PCF when the UE is reachable.
Figure 4.15.6.7-1 shows procedure for service specific parameter provisioning. The AF uses Nnef_ServiceParameter service to provide the service specific parameters to the PLMN and the UE.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.7-1: Service specific information provisioning
Up
Step 1.
To create a new request, the AF invokes an Nnef_ServiceParameter_Create service operation. The request may include subscription information to the report of the outcome of UE Policy delivery.
To update or remove an existing request, the AF invokes an Nnef_ServiceParameter_Update or Nnef_ServiceParameter_Delete service operation together with the corresponding Transaction Reference ID which was provided to the AF in Nnef_ServiceParameter_Create response message.
The content of this service operation (AF request) includes the information described in clause 5.2.6.11.
Step 2.
The AF sends its request to the NEF. The NEF authorizes the AF request. The NEF performs the following mappings:
  • Map the AF-Service-Identifier into DNN and S-NSSAI combination, determined by local configuration.
  • Map the External Application Identifier into the corresponding Application Identifier known in the core network.
  • Map the GPSI in Target UE Identifier into SUPI, according to information received from UDM.
  • Map the External Group Identifier in Target UE Identifier into Internal Group Identifier, according to information received from UDM.
If the AF subscribed to the outcome of UE Policy delivery, the NEF indicates where the NEF receives the corresponding notifications.
(in the case of Nnef_ServiceParameter_Create): The NEF assigns a Transaction Reference ID to the Nnef_ServiceParameter_Create request.
Step 3.
(in the case of Nnef_ServiceParameter_Create or Update): The NEF stores the AF request information in the UDR as the "Application Data" (Data Subset setting to "Service specific information") together with the assigned Transaction Reference ID.
(in the case of Nnef_ServiceParameter_delete): The NEF deletes the AF request information from the UDR.
Step 4.
The NEF responds to the AF. In the case of Nnef_ServiceParameter_Create response message, the response message includes the assigned Transaction Reference ID.
If the UE is registered to the network and the PCF performs the subscription to notification to the data modified in the UDR by invoking Nudr_DM_Subscribe (AF service parameter provisioning information, SUPI, Data Set setting to "Application Data", Data Subset setting to "Service specific information") at step 0, the following steps are performed:
Step 5.
The PCF(s) receive(s) a Nudr_DM_Notify notification of data change from the UDR.
Step 6.
The PCF initiates UE Policy delivery as specified in clause 4.2.4.3.
Step 7.
If the AF subscribed to notifications about the outcome of UE Policies delivery due to Service specific parameter provisioning the PCF notifies the outcome of the procedure to NEF sending Npcf_EventExposure_Notify.
Step 8.
When the NEF receives Npcf_EventExposure_Notify, the NEF performs information mapping (e.g. AF Transaction Internal ID provided in Notification Correlation ID to AF Transaction ID, SUPI to GPSI, etc.) and triggers the appropriate Nnef_ServiceParameter_Notify message.
Up

4.15.6.8  Set a policy for a future AF session |R16|Word‑p. 365

Reproduction of 3GPP TS 23.502, Figure 4.15.6.8-1: Set a policy for a future AF session
Up
Step 1.
The AF previously negotiated policy for background data transfer using the Procedure for future background data transfer as described in clause 4.16.7.2.
Step 2.
The AF requests that the previously negotiated policy for background data transfer be applied to a group of UE(s) or any UE, by invoking the Nnef_ApplyPolicy_Create service operation (AF Identifier, External Identifier or External Group Identifier, Background Data Transfer Reference ID). 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_ApplyPolicy_Create request. The NEF authorizes the AF request and stores the AF Identifier and the Transaction Reference ID.
Step 3.
The NEF invokes Nudm_SDM_Get (Identifier Translation, GPSI) to resolve the GPSI (External Identifier) to a SUPI or the NEF requests to resolve the External Group Identifier into the Internal Group Identifier using Nudm_SDM_Get (Group Identifier Translation, External Group Identifier).
Step 4a.
The NEF stores the AF request information in the UDR (Data Set = Application Data; Data Subset = Background Data Transfer, Data Key = Internal Group Identifier or SUPI).
Step 4b.
The NEF responds to the Nnef_ApplyPolicy_Create Request (Transaction Reference ID).
Step 5.
The PCF(s) that have subscribed to modifications of AF requests (Data Set = Application Data; Data Subset = Background Data Transfer, Data Key = Internal Group Identifier or SUPI) receive(s) a Nudr_DM_Notify notification of data change from the UDR.
Up

4.15.6.9  Procedures for AF-triggered dynamically changing AM policies |R17|Word‑p. 366

4.15.6.9.1  General
Access and mobility policies may be modified due to several inputs including the AF as described in clause 4.16.2. Clause 4.15.6.9 describes the procedures for triggering such modifications in scenarios belonging to "case B" of clause 4.16.2.0 that are initiated by the AF.
The following cases can be distinguished:
  • AF requests targeting an individual UE (identified by its SUPI or GPSI) without conditions related to the application traffic; these requests are routed (by the AF or by the NEF) to the PCF for the UE as described in clause 5.1.1.2 in TS 23.503. This case is described in clause 4.15.6.9.2.
  • AF requests targeting an individual UE (identified by its GPSI), a group of UEs (identified by an Internal Group Identifier or an External Group Identifier), any UE accessing a combination of DNN and S-NSSAI, or all UEs using an application identified by an External Application Identifier. This case is described in clause 4.15.6.9.3. For such requests the AF shall contact the NEF and the NEF stores the AF request information in the UDR. The PCF(s) receive a corresponding notification if they had subscribed to the creation / modification / deletion of the AF request information corresponding to UDR Data Keys / Data Sub-Keys. This is further described in clause 4.15.6.9.3. The AF is not aware if the target UEs are with or without an already established AM Policy Association and with or without ongoing PDU Sessions.
Up
4.15.6.9.2  Access and Mobility Policy authorization requests targeting an individual UE
This procedure is used for individual UEs when the request shall be applied independently of conditions related to the application traffic. Depending on the AF deployment (see clause 6.2.10 of TS 23.501), the AF may interact with NFs of the Core Network either directly or via the NEF. The procedure for the direct case is described in Figure 4.15.6.9.2-1, while the procedure for the NEF-mediated case is described in Figure 4.15.6.9.2-2.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.9.2-1: Handling an AF request targeting an individual UE without using NEF
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (AF, PCF, BSF, AMF) belong to the home PLMN.
Step 1.
An AM Policy Association is established for a UE as described in clause 4.16.1.
Step 2a.
The AF searches the PCF for the UE using Nbsf_Management_Subscribe with SUPI or GPSI as input, indicating that it is searching for the PCF that handles the AM Policy Association of the UE.
Step 2b.
The BSF provides to the AF the identity of the PCF for the UE for the requested SUPI or GPSI via an Nbsf_Management_Notify operation. If a matching entry already exists in the BSF when step 2a is performed, this shall be immediately reported to the AF.
Step 2c.
The AF sends to the PCF for the UE its request for the AM policy of the UE (identified by SUPI or GPSI) using Npcf_AMPolicyAuthorization (optionally providing a timer on how long this policy shall last, in which case the system behaviour upon expiration of this timer is as specified in TS 23.503). As part of the Npcf_AMPolicyAuthorization request, the AF may subscribe (within the Create and Update operations) or unsubscribe (within the Delete operation) to relevant events specified in clause 6.1.3.18 of TS 23.503, e.g. events related to change of service area coverage.
Step 3.
The PCF takes a policy decision and then an AM Policy Association Modification procedure initiated by the PCF for the UE may be performed as described in clause 4.16.2.2. If the AF has subscribed to access and mobility management related events (i.e. request for service area coverage outcome) in step 2, the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.9.2-2: Handling an AF request targeting an individual UE using NEF
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (AF, NEF, PCF, BSF, AMF) belong to the home PLMN, or the AF belongs to a third party with which the home PLMN has an agreement.
Step 1.
An AM Policy Association is established for a UE as described in clause 4.16.1.
2a. The AF sends to NEF its request for the AM policy of the UE (identified by GPSI) using Nnef_AMPolicyAuthorization (optionally providing a timer on how long this policy shall last, in which case the system behaviour upon expiration of this timer is as specified in TS 23.503). As part of the Nnef_AMPolicyAuthorization request, the AF may request to subscribe (within the Create and Update operations) or unsubscribe (within the Delete operation) for relevant events specified in clause 6.1.3.18 of TS 23.503, e.g. events for request for service area coverage outcome. The NEF stores the request and sends a response to the AF.
Step 2b.
The NEF searches the PCF for the UE using Nbsf_Management_Subscribe with SUPI as input parameter, indicating that it is searching for the PCF that handles the AM Policy Association of the UE.
Step 2c.
The BSF provides to the NEF the identity of the PCF for the UE for the requested SUPI via an Nbsf_Management_Notify operation. If a matching entry already exists in the BSF when step 2b is performed, this shall be immediately reported to the NEF.
Step 2d.
The NEF sends to PCF for the UE its request for the AM policy of the UE (identified by SUPI) using Npcf_AMPolicyAuthorization (having potentially translated GPSI to SUPI via UDM). As part of the Npcf_AMPolicyAuthorization request, the NEF may subscribe or unsubscribe (according to what the AF requested in step 2a) for relevant events specified in clause 6.1.3.18 of TS 23.503, e.g., events for change of service area coverage.
Step 2e.
The NEF informs the AF about events to which the AF has potentially subscribed (i.e., events for change of service area coverage) using Nnef_AMPolicyAuthorization_Notify.
Step 3.
The PCF takes a policy decision and then an AM Policy Association Modification procedure initiated by the PCF for the UE may be performed as described in clause 4.16.2.2. If the AF has subscribed to access and mobility management related events i.e. request for service area coverage outcome in step 2, then the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF as described in clause 4.16.2.2.
Up
4.15.6.9.3  Processing AF requests to influence AM policiesWord‑p. 368
With this procedure, the AF can provide its AM Policy related request (for one or multiple UEs) at any time.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.9.3: Handling an AF request to influence AM Policy
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (i.e. AF, NEF, PCF, BSF, UDR, AMF) belong to the home PLMN, or the AF belongs to a third party with which the home PLMN has an agreement.
The PCF for the UE and the PCF for the PDU Session can be the same entity, then steps 6a, 6b, 7a, and 7c are not performed, while step 7b is performed by that entity.
Step 1.
AM Policy Association establishment as described in clause 4.16.1.
Step 2.
The PCF for the UE subscribes to policy data related to AM influence (Data Set = Application Data; Data Subset = AM influence information, Data Key = S-NSSAI and DNN and/or Internal Group Identifier or SUPI).
Step 3a.
To create a new request, the AF provides "AM influence information" data to the NEF using the Nnef_AMInfluence_Create service operation (together with the AF identifier and potentially further inputs as specified in clause 5.2.6.23.2), including a target (one UE identified by SUPI or GPSI, a group of UEs identified by an External Group Identifier, or all UEs, noting that the "all UEs" option is applicable only if an External Application Identifier is also provided), an optional indication of target application traffic (DNN, S-NSSAI, and optionally an External Application Identifier), and requirements related to AM policy (e.g. service coverage requirements, throughput requirements). The request contains also an AF Transaction Id and may contain a timer on how long this policy shall last, in which case the system behaviour upon expiration of this timer is as specified in TS 23.503. If with this request the AF subscribes to events related with access and mobility management policies, the AF indicates also where it desires to receive the corresponding notifications. To update or remove an existing request, the AF invokes an Nnef_AMInfluence_Update or Nnef_AMInfluence_Delete service operation providing the corresponding AF Transaction Id.
Step 3b.
The NEF stores, updates, or removes the policy data of step 3a in the UDR, having translated any External Group Identifier to an Internal Group Identifier and any GPSI to a SUPI.
Step 3c.
The UDR informs the NEF about the result of the operation of step 3b.
Step 3d.
The NEF informs the AF about the result of the Nnef_AMInfluence operation performed in step 3a.
Step 4.
The UDR notifies the PCF(s) that have a matching subscription (from step 2) about the data stored, updated, or removed in step 3. If matching entries already existed in the UDR when step 3b is performed, this shall be immediately reported to the PCF. The PCF may check that an SM Policy association is established for the SUPI, DNN,S-NSSAI then subscribe to the SMF to Policy Control Request Trigger to detect the application traffic that triggers the allocation of a service area coverage or an allocation of RFSP index value, then steps 8 follows.
Step 5.
A PDU session may be established by the UE as described in clause 4.3.2, including the registration of the PCF for the PDU Session to the BSF as the PCF that manages this PDU Session providing as inputs the UE SUPI/GPSI, the UE address, and the DNN, S-NSSAI.
Step 6a.
The PCF for the UE may search the PCF for the PDU Session using Nbsf_Management_Subscribe with SUPI and (DNN, S-NSSAI) as parameters.
Step 6b.
The BSF provides to the PCF for the UE the identity of the PCF for the PDU Session and the UE address for the requested SUPI and (DNN, S-NSSAI) combination via an Nbsf_Management_Notify operation. If a matching entry already exists in the BSF when step 6a is performed, this shall be immediately reported to the PCF for the UE.
Step 7a.
The PCF for the UE may subscribe to the PCF for the PDU Session for the "application traffic start/stop" event (see clause 6.1.3.18 of TS 23.503), providing the UE address and the Application Identifier(s) and request notifications on start/stop of application traffic detected in a Npcf_PolicyAuthorization_Subscribe request.
Step 7b.
Application traffic start/stop detection is performed as described in steps 6 and 7 of Figure 4.16.14.2-1.
Step 7c.
The PCF for the PDU Session notifies the PCF for the UE about the detected application traffic start/stop event using Npcf_PolicyAuthorization_Notify.
Step 8.
The PCF takes a policy decision and then it may initiate an AM Policy Association Modification procedure initiated by the PCF for the UE may be performed as described in clause 4.16.2.2. If the AF has subscribed to access and mobility management related events. i.e. request for service area coverage outcome in step 3, then the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF as described in clause 4.16.2.2.
Up

4.15.6.10  Application guidance for URSP determination |R17|Word‑p. 369

This clause describes the procedures to allow an AF to provide guidance for URSP determination to 5G system via NEF. The AF may belong to the operator or to an external party. The PCF considered in this clause is in the Home PLMN as it is the PCF that determines the URSP for the UE.
The guidance for URSP determination may be used to provide 5GC with guidance for the URSPs depending on the UE location. This is further described in TS 23.548.
For providing guidance for URSP determination, the procedure defined in clause 4.15.6.7 is performed with the following considerations:
  1. Service Description indicates an AF Identifier.
  2. Service Parameters.
    Information on the AF guidance for URSP determination which consists of a list of rules that associate an application traffic descriptor with requested features for the candidate PDU sessions the application traffic may use:
    • An application traffic descriptor, whose definition corresponds to that of the URSP Traffic Descriptors (as defined for the URSP rule in TS 23.503 Table 6.6.2.1-2).
    • one or more sets of Route selection parameters, each parameter may correspond to:
    • (DNN, S-NSSAI). This may be provided by the AF or determined by the NEF based on the AF Identifier when it is not provided by the AF and the AF provides only one instance of AF guidance for URSP determination
    • a default Route selection precedence value to be used for the application traffic when Route selection precedence with a corresponding spatial validity condition is not provided.
    • Route selection precedence with a corresponding spatial validity condition that indicates where the Route selection parameters apply. This may correspond to a geographical area (i.e. geographic zone identifier).
    If the AF provides a geographical area as spatial validity condition, it is up to the NEF to transform this information into 3GPP identifiers (e.g. TAI(s)).
    NEF may, based on local configuration, complement missing service parameters. Additionally, based on operator's local policy, NEF may request for service specific authorization for the service parameters for an individual UE (e.g. to authorize the Corporate or MTC provider represented by the AF and the requested DNN, S-NSSAI for the related UE) before storing the service parameters into the UDR via Nnef_ServiceParameter_Create operation. If the request is targeting a group of UEs, NEF may also request for service specific authorization for the group related data (see table 4.15.6.3b-1), i.e. the DNN, S-NSSAI associated to the group.
  3. a specific UE, or a group of UE(s) or any UE that the AF request may be associated with.
  4. Subscription to events.
    The AF may subscribe to notifications about the outcome of the UE Policies delivery due to application guidance for URSP determination.
The usage of the AF guidance for application traffic is described in clause 6.2.4 in TS 23.548.
Figure 4.15.6.10-1 shows the enhanced procedure as defined in clause 4.15.6.7 for Application guidance for URSP determination.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.10-1: Service Specific Authorization
Up
Step 1.
The AF initiates the procedure as specified in clause 4.15.6.7.
Step 2.
The NEF sends Nudm_ServiceSpecificAuthorisation_Get Service Request including S-NSSAI/DNN and service type received from AF.
Step 3.
The UDM checks the list of subscribed/allowed S-NSSAI/DNNs for the UE and other service info (e.g. MTC provider is authorized for the UE).
Step 4.
The UDM responds to the NEF with the service authorization result. If authorization fails (e.g. DNN is not subscribed for the UE, UE subscription does not allow to modify URSP rules dynamically by an AF or by such specific AF or MTC provider), UDM returns a negative response with an appropriate error code and the NEF rejects the request with the proper error code to inform the AF about the request not authorized.
Step 5.
The procedure continues as specified in clause 4.15.6.7.
 
Figure 4.15.6.10-2 illustrates the procedure for updating or revoking an existing Service Specific Authorization.
Reproduction of 3GPP TS 23.502, Figure 4.15.6.10-2: Service Specific Authorization Update procedure
Up
Step 1.
The UDM may send a Service Specific Authorization Update information using Nudm_ServiceSpecificAuthorisation_UpdateNotify Request (GPSI, S-NSSAI, DNN, Result) message to the NEF to update a user's authorization.
Step 2.
The NEF sends Nudm_ServiceSpecificAuthorisation_UpdateNotify Response (cause) message to the UDM to acknowledge the authorization update.
Step 3.
If the authorization is revoked, the NEF removes the service specific parameters from the UDR.
Step 4.
The NEF informs the AF that the service parameters authorisation status has changed by sending Nnef_ServiceParameter_Notify Request (GPSI, TLTRI, Result) message to the AF.
Step 5.
The AF responds to the NEF with Nnef_ServiceParameter_Notify Response message.
Up

4.15.6.11Void

4.15.7  Network status reporting |R16|Word‑p. 372

This clause contains the detailed description and the procedures for the network status reporting capability.
An AF may request for being notified about the network status, in a specific geographical area or for a specific UE.
The following methods are supported:
  • The AF requests to be informed, one-time, about the network status. This procedure is referred to as one-time network status request;
  • The AF requests to be informed, continuously, about the network status. This procedure is referred to as continuous network status request;
The procedure as described in clause 6.1.1.2 or clause 6.1.2.2 in TS 23.288 is used by an AF to retrieve Network Status Result (NSR) from the network for a specific geographic area or for a specific UE.
After receiving the request for network status notification from the AF, the NEF retrieves user data congestion analytics information from NWDAF, as defined in TS 23.288.
Based on the user data congestion analytics information the NEF receives from the NWDAF, the NEF derives and reports the network status for the geographical area or for the UE as Network Status Result (NSR) to the AF. When reporting to the AF, the NSR shall not include any 3GPP location information.
When an AF requests one-time Network Status from the NEF, the NEF can optionally provide a time interval at which the AF is allowed to re-issue the same request for network status.
Up

4.15.8  Event exposure controlled by a DCCF |R17|

A DCCF can coordinate the subscriptions and notifications to event exposure in Network Functions. This is further described in TS 23.288.

4.15.9  Time Synchronization exposure |R17|Word‑p. 373

4.15.9.1  General

Time synchronization exposure allows an AF to configure time synchronization in 5GS. Depending on the time distribution method to use for the service (e.g. (g)PTP or 5G clock sync), the AF may require retrieving 5GS time synchronization capabilities prior to sending the time synchronization service request. For (g)PTP operation, the Time synchronization service allows an AF to subscribe to the UE availability for time synchronization service.

4.15.9.2  Exposure of UE availability for Time Synchronization service

The procedure is used by the AF to subscribe to notifications and to explicitly cancel a previous subscription for UE availability for time synchronization service. Cancelling is done by sending Nnef_TimeSynchronization_CapsUnsubscribe request identifying the subscription to cancel with Subscription Correlation ID.
Reproduction of 3GPP TS 23.502, Figure 4.15.9.2-1: Nnef_TimeSynchronization_CapsSubscribe, CapsUnsubscribe and CapsNotify operations
Up
Step 1.
The AF subscribes to the UE availability for time synchronization service (as identified by Event ID) and provides the associated Notification Target Address of the AF by sending Nnef_TimeSynchronization_CapsSubscribe request.
Event Reporting Information defines the type of reporting requested (e.g. one-time reporting, periodic reporting or event based reporting).
The Event Reporting Information may include DNN and slicing information (S-NSSAI) or an AF-Service-Identifier. If the DNN and S-NSSAI are omitted in the request, the NEF uses the AF-Service-Identifier to determine the target DNN and slicing information (S-NSSAI).
Additionally, the Event Reporting Information may include a list of UE identifiers (SUPIs or GPSIs) or Groups of UEs identified by an External Group Identifier that further define the subset of the target UEs. If the request does not include UE identifiers, the request is targeted to any UE with a PDU Session using the DNN and S-NSSAI. The NEF uses the UDM service to map the GPSIs to SUPIs and to map the External Group Identifier to Internal Group Identifier.
When the NEF processes the AF request the AF-Service-Identifier may be used to authorize the AF request.
Step 2.
The NEF discovers the TSCTSF. The NEF invokes the Ntsctsf_TimeSynchronization_CapsSubscribe request service operation to the selected TSCTSF.
The AF that is part of operator's trust domain may invoke the services directly with TSCTSF.
Step 3.
(in the case of Ntsctsf_TimeSynchronization_CapsSubscribe): The TSCTSF stores the AF request information in the UDR (Data Set = Application Data; Data Subset = Time-Sync data, Data Key = S-NSSAI and DNN and/or Internal Group Identifier or SUPI). The Time-Sync data contains a Notification Target Address to the TSCTSF.
(in the case of Ntsctsf_TimeSynchronization_CapsUnsubscribe): The TSCTSF deletes the AF request information in the UDR.
Step 4.
TSCTSF acknowledges the execution of Ntsctsf_TimeSynchronization_CapsSubscribe to the requester that initiated the request. The acknowledgement contains a Subscription Correlation ID that the requester can use to cancel or modify the subscription.
Step 5.
NEF acknowledges the execution of Nnef_TimeSynchronization_CapsSubscribe to the requester that initiated the request. The acknowledgement contains a Subscription Correlation ID that the AF can use to cancel or modify the subscription.
Step 6.
The PCF(s) that have subscribed to modifications of AF requests (Data Set = Application Data; Data Subset = Time-Sync data, Data Key = S-NSSAI and DNN and/or Internal Group Identifier or SUPI) receive(s) a Nudr_DM_Notify notification of data change from the UDR.
Step 7.
The PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of these PDU Sessions, the PCF invokes Npcf_PolicyAuthorization_Notify request to the TSCTSF Notification Target Address as included in the Time-Sync data in the UDR.
In order to ensure that the same TSCTSF instance is selected by the NEF (or AF) and the PCF, the PCF subscribes to notification of Time-Sync data change with the UDR as described in clause 4.16.5.1.
Step 8.
The TSCTSF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Create request message as in step 4 in Figure 4.3.6.4-1.
Step 9.
As part of Npcf_PolicyAuthorization_Create request, the TSCTSF uses the procedures as described in clause K.2.1 of TS 23.501 to determine the (g)PTP capabilities from the DS-TT. If the TSCTSF has not determined the (g)PTP capabilities from the NW-TT, the TSCTSF determines the capabilities using the procedures as described in clause K.2.1 of TS 23.501.
The TSCTSF composes the time synchronization capabilities for the DS-TT/UE(s) connected to the NW-TT based on the capability information received from the DS-TT(s) and NW-TT.
The TSCTSF maintains association between the user-plane Node ID, the time synchronization capabilities, the reference to the capabilities (as identified by the Subscription Correlation ID), the NEF or AF Notification Target Address, and list of the AF sessions with PCFs with this user-plane Node ID.
Step 10.
The TSCTSF sends Ntsctsf_TimeSynchronization_CapsNotify with Time Synchronization capability event (as described in Table 4.15.9.2-1) to the NEF. The message includes the time synchronization capabilities as composed in step 9. The message contains a list of UE identifiers to which the event is applicable and the associated user-plane Node ID identifying the NW-TT to where the UE/DS-TT(s) are connected to.
Step 11.
The NEF sends Nnef_TimeSynchronization_CapsNotify with Time Synchronization capability event (as described in Table 4.15.9.2-1) to the AF.
Step 12-15.
Upon PDU Session Establishment as defined clause 4.3.2.2.1, steps 6-9 are repeated for the new PDU Session.
Step 16.
If necessary, the TSCTSF may update the time synchronization capabilities for the DS-TT/UE(s) connected to the NW-TT based on the capability information received from the new DS-TT. The TSCTSF sends Ntsctsf_TimeSynchronization_CapsNotify containing the updated capabilities and the UE identifier of the new PDU Session to the NEF.
Step 17.
The NEF sends Nnef_TimeSynchronization_CapsNotify containing the updated capabilities and the UE identifier of the new PDU Session to the AF.
 
Table 4.15.9.2-1 describes the event for Time Synchronization capability. The event is detected when a UE/DS-TT establishes a PDU Session with an NW-TT, where DS-TT and NW-TT support time synchronization service as described in clause 4.4.8.3 in TS 23.501.
Time Synchronization Parameter Description
List of UE identitiesIdentifies the UEs to which the reported time synchronization capabilities apply.
User-Plane Node IDIdentifies the applicable NW-TT (NOTE 1).
Time synchronization distribution methodIdentifies the time synchronization distribution methods supported by 5GS for the reported UEs. Allowed values: IEEE Std 1588 [76] operation (i.e. as a Boundary Clock, peer-to-peer Transparent Clock, or end-to-end Transparent Clock) and transport protocol (Ethernet, UDP over IPv4, or UDP over Ipv6), IEEE Std 802.1AS [75] operation or Access Stratum-based 5G clock sync.
Supported PTP ProfilesIdentifies the PTP profiles supported by 5GS for the reported UE.
(g)PTP grandmaster capableIndicates separately whether 5GS supports acting as a gPTP or PTP grandmaster.
NOTE 1:
This is needed to limit the PTP instance into a single NW-TT. In this way the AF can know e.g. UE1/UE2/UE3 are served by NW-TT1, UE4/UE5/UE6 are served by NW-TT2. The AF can control the PTP instances per NW-TT.
 
Up

4.15.9.3  Time Synchronization activation, modification, and deactivationWord‑p. 375

This procedure can be used by the AF to activate, modify or deactivate the (g)PTP instances in 5GS.
The AF may activate the time synchronization service using the Nnef_TimeSynchronization_ConfigCreate service operation. The service operation creates a time synchronization configuration based on the service parameters as indicated in the create request. The AF may update the time synchronization configuration using the Nnef_TimeSynchronization_ConfigUpdate service operation. The AF may deactivate the time synchronization service using the Nnef_TimeSynchronization_ConfigDelete service operation, which deletes the corresponding time synchnonization service configuration.
The Nnef_TimeSynchronization_ConfigCreate and Nnef_TimeSynchronization_ConfigUpdate request may contain the parameters as described in Table 4.15.9.3-1.
Time Synchronization Parameter Description
Time synchronization distribution method Identifies the time synchronization distribution method requested by AF.
Allowed values: IEEE Std 1588 [76] operation (i.e. as a Boundary Clock, peer-to-peer Transparent Clock, or end-to-end Transparent Clock) and transport protocol (Ethernet, UDP over IPv4, or UDP over IPv6), IEEE Std 802.1AS [75] operation, or Access Stratum-based 5G clock sync.
PTP Profile Identifies the PTP profile requested by AF.
Grandmaster enabled Indicates whether AF requests 5GS to act as a grandmaster for PTP or gPTP (depending on the requested Time synchronization distribution method).
This is applicable for IEEE Std 1588 [76] or IEEE Std 802.1AS [75] operation.
[optional]
Grandmaster priority Indicates a priority used as defaultDS.priority1 when generating Announce message when 5GS acts as (g)PTP GM.
[optional]
Time Domain As defined in IEEE Std 1588 [76].
[optional]
Temporal Validity Condition Indicates start-time and stop-time attributes that describe the time period when the time synchronization service is active. [optional]
 
The AF may use Nnef_ Nnef_TimeSynchronization_CapsSubscribe service operation as described in clause 4.15.9.2 to learn the UE capabilities for time synchronization service. The Nnef_TimeSynchronization_CapsNotify service operation indicates the list of UE identities, User-plane Node ID, and the Subscription Correlation ID. The AF can use the Subscription Correlation ID and the user-plane node ID in the Nnef_TimeSynchronization_ConfigCreate service operation to identify the target of the request. The NEF uses the Subscription Correlation ID and user-plane node ID to determine the list of UEs and list of AF-sessions to which the Nnef_TimeSynchronization_ConfigCreate service operation is targeted to.
Reproduction of 3GPP TS 23.502, Figure 4.15.9.3-1: Nnef_TimeSynchronization_ConfigCreate, ConfigUpdate and ConfigUpdateNotify operations
Up
Step 1.
The AF creates a time synchronization service configuration by invoking Nnef_TimeSynchronization_ConfigCreate service operation. The request includes the parameters as described in table 4.15.9.3.1. The request contains a Subscription Correlation ID and user-plane node ID as a reference to the target of the UEs and AF-sessions.
The create request creates also a subscription for the changes in the time synchronization service configuration.
Step 2.
The NEF authorizes the request. After successful authorization, the NEF invokes the Ntsctsf_TimeSynchronization_ConfigCreate service operation with the corresponding TSCTSF.
Step 3.
The TSCTSF responds with the Ntsctsf_TimeSynchronization_ConfigCreate response, including a reference to the time synchronization service configuration.
Step 4.
The NEF responds with the Nnef_TimeSynchronization_ConfigCreate response, including a reference to the time synchronization service configuration.
Step 5-6.
The TSCTSF uses the Subscription Correlation ID and user-plane node ID in Ntsctsf_TimeSynchronization_ConfigCreate to determine the target UEs and corresponding AF-sessions. The TSCTSF uses the procedures described in clause K.2.2 of TS 23.501 to configure and initialize the PTP instances in the DS-TT(s) and NW-TT. The TSCTSF constructs a PMIC to each DS-TT/UE to activate the time synchronization service in DS-TT in respect to the service parameters in the request in step 1. The TSCTSF constructs PMIC(s) and UMIC to NW-TT to activate the time synchronization service in NW-TT in respect to the service parameters in the request in step 2.
The TSCTSF interacts with the PCF by triggering a Npcf_PolicyAuthorization_Update request message as described in clause 4.16.5.2. Upon reception of responses from each DS-TT and NW-TT, the TSCTSF determines the state of the time synchronization configuration.
The TSCTSF maintains association between list of AF-sessions, corresponding time synchronization configuration, and Subscription Correlation ID and user-plane node ID as given in step 1.
The TSCTSF constructs a PMIC to each DS-TT/UE to subscribe for the port management information changes in the DS-TT. The TSCTSF constructs PMIC(s) and UMIC to NW-TT to subscribe for the port management and user-plane management information changes in NW-TT.
The create request creates also a subscription for the changes in the time synchronization service configuration.
Step 7.
The TSCTSF notifies the NEF (or AF) with the Ntsctsf_TimeSynchronization_ConfigUpdateNotify service operation, containing the reference to the time synchronization service configuration and the current state of the time synchronization service configuration.
Step 8.
The NEF notifies the AF with the Ntsctsf_TimeSynchronization_ConfigUpdateNotify service operation, containing the reference to the time synchronization service configuration and the current state of the time synchronization service configuration.
Step 9.
Upon a change in the PTP instance in the DS-TT or NW-TT, the DS-TT or NW-TT report the change via PMIC or UMIC to the TSCTSF as described in clause K.2.2 of TS 23.501.
Upon PDU Session Establishment as defined clause 4.3.2.2.1, steps 4-7 in Figure 4.15.9.2-1 are repeated for the new PDU Session and the TSCTSF may notify the NEF (or AF) for the Time Synchronization capability event, optionally with the updated time synchronization capabilities, as described in step 10 in Figure 4.15.9.2-1.
As part of step 9 in Figure 4.15.9.2-1 the TSCTSF adds the new AF-session to the list of the AF sessions that are associated with the user-plane Node ID, the time synchronization capabilities, and the reference to the time synchronization capabilities (Subscription Correlation ID).
If the TSCTSF determines time synchronization service is active for the Subscription Correlation ID and user-plane node ID associated with the new AF-session, the TSCTSF uses the procedures described in clause K.2.2 of TS 23.501 to configure and initialize the PTP instances in the DS-TT of the new PDU Session.
Step 10.
The TSCTSF updates the state of the time synchronization configuration and may notify the NEF (or AF) with the Ntsctsf_TimeSynchronization_ConfigUpdateNotify service operation, containing the reference to the time synchronization service configuration and the updated state of the time synchronization service configuration.
Step 11.
The NEF notifies the AF with the Nnef_TimeSynchronization_ConfigUpdateNotify service operation, containing the reference to the time synchronization service configuration and the updated state of the time synchronization service configuration.
Up

4.15.9.4  Time Synchronization using 5G Reference time distribution: activation, modification, and deactivationWord‑p. 378


Up   Top   ToC