Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  16.5.1

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 ExposureWord‑p. 306

4.15.4.1  General

The exposure of events internally within the 3GPP NFs are 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 AMF

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.
  • 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 delievered 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 delievered 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.
  • During Network Triggered Service Request procedure, if the UE does not respond to paging, when the AMF considers the UE as unreachable the AMF notifies the NF consumers that have subscribed for UE reachability event, 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.
Up

4.15.5Void

4.15.6  External Parameter ProvisioningWord‑p. 307

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. 308
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 TS 23.288, clause 6.1.1.2. The Analytics Id is set to any of the values specified in TS 23.288, clause 6.7.1.
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.
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.
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 the Network Configuration parameters or the 5G VN configuration parameters or Location Privacy Indication parameters), 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 parameters, 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 AMF-Associated 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 parameter set, DNN/S-NSSAI, etc.) service operation.
    The SMF stores the received SMF-Associated 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 SMF-Associated 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. 310
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 retrives the AMF-Associated Expected UE Behaviour parameters from UDM which may related to both PDU session(s) and SMS transmission. SMF retrives the SMF-Associated Expected UE Behaviour parameters from UDM for the specific PDU session. AMF and SMF uses the Expected UE Behaviour parameters as described in clause 5.4.6.2 in TS 23.501.
Expected UE Behaviour parameter
Description

Expected UE Moving Trajectory
Identifies the UE's expected geographical movement
Example: A planned path of movement
Stationary Indication
Identifies whether the UE is stationary or mobile [optional]
Communication Duration Time
Indicates for how long the UE will normally stay in CM-Connected for data transmission.
Example: 5 minutes.
[optional]
Periodic Time
Interval Time of periodic communication
Example: every hour.
[optional]
Scheduled Communication Time
Time and day of the week when the UE is available for communication.
Example: Time: 13:00-20:00, Day: Monday.
[optional]
Battery Indication
Identifies power consumption criticality for the UE: if the UE is battery powered with not rechargeable/not replaceable battery, battery powered with rechargeable/replaceable battery, or not battery powered.
[optional]
Traffic Profile
Identifies the type of data transmission: single packet transmission (UL or DL), dual packet transmission (UL with subsequent DL or DL with subsequent UL), multiple packets transmission
[optional]
Scheduled Communication Type
Indicates that the Scheduled Communication Type is Downlink only or Uplink only or Bi-directional [To be used together with Scheduled Communication Time]
Example: <Scheduled Communication Time>, DL only.
[optional]

The Expected UE Moving 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. 311
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 classified in the UDM as AMF-Associated parameters and sent to the AMF.
The AMF may use the Maximum Latency parameter to configure the time between UE reachability events (e.g. MICO mode duration, Periodic Registration Timer value).
The AMF may use the Maximum Response Time parameter as guide to configure:
  • Active Time or 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) and/or the maximum value of Maximum Response Time(s) as the AMF-Associated parameters. If the configured 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 parameter. 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 SMF-associated parameters 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).
Up

4.15.6.3b  5G VN group data |R16|Word‑p. 312
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 TS 23.501, clause 5.6);
  • 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.


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. 313
5G VN group membership management parameters that an AF may provide are described in Table 4.15.6.3c-1.
Parameters
Description

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

4.15.6.4  Set a chargeable party at AF session setup

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 wuth 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), Sponsor Information, Sponsoring Status, Background Data Transfer Reference ID) 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 asssigns 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.203), 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. 314
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.203), 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. 315
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), QoS reference, (optional) Alternative Service Requirements (containing one or more QoS reference parameters in a prioritized order)) 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.
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, steps 3 and 4 are 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 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).
Step 4.
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 for this AF), 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 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 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 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 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 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. 316
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.
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, steps 3 and 4 are 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 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).
Step 4.
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 for this AF), 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 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 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 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. 317
This clause describes the procecures 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 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 delived to any UEs using the service identified by the Service Description.
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.
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 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.
(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.
Up

4.15.6.8  Set a policy for a future AF session |R16|Word‑p. 319
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 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.7  Network status reporting |R16|

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

Up   Top   ToC