4.15.6 External Parameter Provisioning

23.5023GPPProcedures for the 5G System (5GS)Release 18TS

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

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.

4.15.6.2 NEF service operations information flow

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

0. NF subscribes to UDM notifications of UE and/or Group Subscription data updates.

NOTE 1: The NF can subscribe to Group Subscription data from UDM in this step and be notified of Group Subscription data updates in step 7 using the Shared Data feature defined in TS 29.503 [52].

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 [50]. The Analytics ID is set to any of the values specified in clause 6.7.1 of TS 23.288 [50].

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.

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 Identifier).

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

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

– Expected UE Behaviour parameters (see clause 4.15.6.3); or

– Network Configuration parameters (see clause 4.15.6.3a); or

– External Group Id and 5G VN group data (i.e. 5G-VN configuration parameters) (see clause 4.15.6.3b), or

– 5G VN group membership management parameters (see clause 4.15.6.3c); or

– Location Privacy Indication parameters of the "LCS privacy" Data Subset of the Subscription Data (see clause 5.2.3.3.1 and clause 7.1 of TS 23.273 [51]); or

– MTC Provider Information;

– AF provided ECS Address Configuration Information (see clause 4.15.6.3d).

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

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.

NOTE 2: For non-roaming case and no authorisation or validation by the UDM required and if the request is not associated with a 5G VN group, the NEF can directly forward the external parameter to the UDR via Nudr_DM_Update Request message. And in this case, the UDR responds to NEF via Nudr_DM_Update Response message.

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.

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) or 5G VN group membership is updated, the UDR notifies to the subscribed PCF by sending Nudr_DM_Notify as defined in clause 4.16.12.2.

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

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

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

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

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

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

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.

a) 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.

b) 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.

NOTE 3: The NEF (in NOTE 1) or the UDM (in step 3) can also update the corresponding UDR data via Nudr_DM_Create/Delete as appropriate.

NOTE 4: The change of AF provided ECS configuration information is not meant to apply immediately: the UDM interface to the SMF can refer to Shared Data for the Subscription provided ECS configuration information.

4.15.6.3 Expected UE Behaviour parameters

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 [2].

Table 4.15.6.3-1: Description of Expected UE Behaviour parameters

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

The Expected UE Moving Trajectory and the Expected Time and Day of Week in Trajectory may be used by the AMF. All other parameters may be used by the AMF and by the SMF.

The Scheduled Communication Type and the Traffic Profile should not be used by the AMF to release the UE when NAS Release Assistance Information from the UE is available.

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

4.15.6.3a Network Configuration parameters

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

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

Table 4.15.6.3a-1: Description of Network Configuration parameters

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

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

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

– Extended Connected time for MICO mode;

– when to send reachability notifications to AF relative to expected reachability events (e.g. paging occasions).

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

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

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

4.15.6.3b 5G VN group data

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

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

Parameters	Description
DNN	DNN for the 5G VN group
S-NSSAI	S-NSSAI for the 5G VN group
PDU Session Type	PDU Session Types allowed for 5G VN group
Application descriptor	There may be multiple instances of this information; this information may be used to build URSP sent to 5G VN group members (NOTE 1)
Information related with secondary authentication / authorization	This may indicate: – the need for secondary authentication/authorization (as defined in clause 5.6 of TS 23.501 [2]); – 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 [20], the PCF may be configured with a mapping from Application Descriptor to other information required to construct the URSP rules, e.g. IP filters and SSC mode.

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

4.15.6.3c 5G VN Group membership management parameters

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

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

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

4.15.6.3d ECS Address Configuration Information Parameters

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

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

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

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.

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

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

Parameters

Description

ECS Address Configuration Information

One or more ECS Configuration Information as defined in clause 8.3.2.1 of TS 23.558 [83].

Target

This may correspond to one of:

– a group of UE identified by an external group Id;

– any UE.

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

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

4.15.6.4 Set a chargeable party at AF session setup

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

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 information or External Application Identifier, Sponsor Information, Sponsoring Status, Background Data Transfer Reference ID, DNN, S-NSSAI) to the NEF. The Sponsoring Status indicates whether sponsoring is started or stopped, i.e. whether the 3rd party service provider is the chargeable party or not. The Background Data Transfer Reference ID parameter identifies a previously negotiated transfer policy for background data transfer as defined in clause 4.16.7. The NEF assigns a Transaction Reference ID to the Nnef_ChargeableParty_Create request.

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.

NOTE: Based on operator configuration, the NEF may skip this step. In this case the authorization is performed by the PCF in step 3.

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 [20]), Background Data Transfer Reference ID (if received from the AF) and Sponsoring Status (if received from the AF) to the PCF.

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.

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.

4.15.6.5 Change the chargeable party during the session

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

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.

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.

NOTE: Based on operator configuration, the NEF may skip this step. In this case the authorization is performed by the PCF in step 3.

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 [20]), Background Data Transfer Reference ID (if received from the AF) and Sponsoring Status (if received from the AF) to the PCF.

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.

4.15.6.6 Setting up an AF session with required QoS procedure

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

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 information or External Application Identifier, QoS Reference or individual QoS parameters, Alternative Service Requirements (as described in clause 6.1.3.22 of TS 23.503 [20]), 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 AF may, instead of a QoS Reference, provide one or more of the following individual QoS parameters: Requested 5GS Delay (optional), Requested Priority (optional), Requested Guaranteed Bitrate, Requested Maximum Bitrate, Maximum Burst Size and Requested Packet Error Rate. Regardless of whether the AF request is formulated using a QoS Reference or individual QoS parameters, the AF may also provide one or more of the following parameters that describe the traffic characteristics flow direction, Burst Arrival Time at UE (uplink) or UPF (downlink), Periodicity, Time domain, Survival Time, Capability for BAT adaptation, BAT Window. The optional Alternative Service Requirements provided by the AF shall either contain QoS References or Requested Alternative QoS Parameter Set(s) in a prioritized order as described in clause 6.1.3.22 of TS 23.503 [20].

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

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

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

3. If the NEF determines to contact the PCF directly without invoking the TSCTSF, the NEF uses the UE address to discover the PCF from the BSF. The NEF forwards received parameters to the PCF in the Npcf_PolicyAuthorization_Create request. Any optionally received period of time or traffic volume mapped and forwarded as sponsored data connectivity information (as defined in TS 23.503 [20]).

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

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

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

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

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

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

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

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 of the PCC rule based on the information provided by the NEF and determines whether this QoS is allowed (according to the PCF configuration) and notifies the result to the NEF. If the AF is considered to be trusted by the operator, the PCF sends the Npcf_PolicyAuthorization_Create response message directly to AF.

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

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

NOTE 1: The PCF derived Alternative QoS parameter set(s) for the PCC rule are subsequently used to establish Alternative QoS Profile(s). The Alternative QoS Profile parameters provided to the NG-RAN are specified in clause 5.7.1.2a of TS 23.501 [2].

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.

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

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

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

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

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

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.

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 [20].

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 [20].

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.

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

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.

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

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

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

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

4.15.6.6a AF session with required QoS update procedure

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

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 information], [QoS Reference or individual QoS parameters], [Alternative Service Requirements (as described in clause 6.1.3.22 of TS 23.503 [20])]) 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, instead of a QoS Reference, provide one or more of the following individual QoS parameters: Requested 5GS Delay (optional), Requested Priority (optional), Requested Guaranteed Bitrate, Requested Maximum Bitrate, Maximum Burst Size and Requested Packet Error Rate. Regardless whether the AF request is formulated using a QoS Reference or individual QoS parameters, the AF may also provide one or more of the following parameters that describe the traffic characteristics: flow direction, Burst Arrival Time at UE (uplink) or UPF (downlink), Periodicity, Time domain, Survival Time, Capability for BAT adaptation, BAT Window. The optional Alternative Service Requirements provided by the AF shall either contain QoS References or Requested Alternative QoS Parameter Set(s) in a prioritized order as specified in clause 6.1.3.22 of TS 23.503 [20].

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

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

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

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

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

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

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

4. The PCF processes the Npcf_PolicyAuthorization_Update request according to the actions described in step 4 of clause 4.15.6.6.

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

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

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

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.

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, or when an Alternative Service Requirement is being applied.

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

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

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

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

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

4.15.6.7 Service specific parameter provisioning

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.

NOTE 1: In the case of architecture without CAPIF support, the AF is locally configured with the API termination points for the service. In the case of architecture with CAPIF support, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [54].

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 [23]. 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.

Figure 4.15.6.7-1: Service specific information provisioning

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.

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.

2a. The NEF may invoke Nudm_SDM_Get service operation to perform the following mappings:

– 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 AF indicates where the AF receives the corresponding notifications.

(in the case of Nnef_ServiceParameter_Create): The NEF assigns a Transaction Reference ID to the Nnef_ServiceParameter_Create request.

2b. (in the case of Nnef_ServiceParameter_Create or Update): The NEF may need to authorize the service specific parameter provisioning request with the UDM by sending a Nudm_ServiceSpecificAuthorisation_Create service operation as defined in clause 4.15.6.7a.

NOTE 2: The NEF skips the mapping of GPSI or External Group Identifier in step 2a if it needs to authorize the service specific parameter provisioning request with the UDM as the response of the authorization request from UDM includes the SUPI or Internal Group Identifier.

(in the case of Nnef_ServiceParameter_delete): The NEF requests the UDM to remove the authorization of the service specific parameters provisioned by sending a Nudm_ServiceSpecificAuthorisation_Remove service operation.

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.

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:

5. The PCF(s) receive(s) a Nudr_DM_Notify notification of data change from the UDR.

NOTE 3: PCF does not have to subscribe for each UE the application specific information, e.g. if PCF has already received the application specific information for a group of UE or for a DNN by a subscription of other UE. The same application specific information is delivered to every UE in a group or a DNN.

6. The PCF initiates UE Policy delivery as specified in clause 4.2.4.3.

7. If the AF subscribed to notifications about the outcome of UE Policies delivery due to Service specific parameter provisioning targeting a single UE and the PCF is notified of UE Policy Container from the AMF, the PCF notifies the UE Policy delivery result contained in the UE Policy container as the outcome of the procedure to NEF by sending Npcf_EventExposure_Notify.

If PCF is notified about UE Policy delivery failure from the AMF due to UE not reachable, the PCF may determine to retry step 6 of this procedure when the UE becomes reachable. In such a case, the PCF may report the interim status i.e. UE is temporarily unreachable as the outcome of the procedure to NEF by sending Npcf_EventExposoure_Notify.

If the PCF determines the failure of the UE Policies delivery procedure, the PCF notifies the failure with an appropriate cause such as UE is unreachable as the outcome of the procedure to NEF by sending Npcf_EventExposure_Notify.

The content of event reporting in this step is described in clause 6.1.3.18 of TS 23.503 [20].

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.

4.15.6.7a Authorization of service specific parameter provisioning

Figure 4.15.6.7a-1 shows the procedure to authorize the service specific parameter provisioning requests (e.g. for Application guidance for URSP determination as defined in clause 4.15.6.10).

Figure 4.15.6.7a-1: Service Specific Authorization for an individual UE or group of UEs

1. The AF initiates the procedure as specified in clause 4.15.6.7.

2. The NEF sends Nudm_ServiceSpecificAuthorisation_Create Request including the GPSI or External Group Id, S-NSSAI/DNN, service type, (optional) AF ID, (optional) MTC Provider Information and notification address to receive updates of the authorization from UDM.

3. The UDM maps the GPSI or External Group Id included in the request from the NEF to SUPI or Internal Group Id.

If the request is for an individual UE, 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).

If the request is for a group of UEs, the UDM checks whether the group related data (e.g. DNN/S-NSSAI group related data, see table 4.15.6.3b-1) and other service info, e.g. MTC provider is authorized for the group.

4. The UDM responds to the NEF with the service authorization result. If authorization succeeds, the UDM includes the SUPI or Internal Group Id mapping the GPSI or External Group Id provided by the NEF.

If authorization fails (e.g. DNN is not subscribed for the UE or it is different from the group related data, UE subscription or group related data 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.

NOTE 1: The MTC Provider Information can be used by any type of Service Providers (MTC or non-MTC) or Corporate or External Parties for, e.g. to distinguish their different customers.

5. The procedure continues as specified in clause 4.15.6.7.

Figure 4.15.6.7a-2 illustrates the procedure for updating or revoking an existing Service Specific Authorization.

Figure 4.15.6.7a-2: Service Specific Authorization Update procedure

0. UDM provided a successful authorization for a request to provision service specific parameters as defined in Figure 4.15.6.7a-1. The authorization for the provisioning of the service specific parameters is modified in UDM (e.g. due to subscription withdrawal or to the DNN associated to the authorization being removed from UE subscription).

1. The UDM sends a Nudm_ServiceSpecificAuthorisation_UpdateNotify Request (GPSI or External Group Id, SUPI or Internal Group Id, S-NSSAI, DNN, Service Type, (optional) AF ID, (optional) MTC Provider Information, Status, Cause) message to the NEF to update a UE’s or group of UEs’ authorization.

2. The NEF sends Nudm_ServiceSpecificAuthorisation_UpdateNotify Response message to the UDM to acknowledge the authorization update.

3. If the authorization is revoked, the NEF removes the service specific parameters from the UDR.

4. The NEF informs the AF that the service parameters authorisation status has changed by sending Nnef_ServiceParameter_Notify Request (GPSI or External Group Id, TLTRI, Status, Cause) message to the AF to update the authorization.

5. The AF responds to the NEF with Nnef_ServiceParameter_Notify Response message.

4.15.6.8 Set a policy for a future AF session

Figure 4.15.6.8-1: Set a policy for a future AF session

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.

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.

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

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

4b. The NEF responds to the Nnef_ApplyPolicy_Create Request (Transaction Reference ID).

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.

4.15.6.9 Procedures for AF-triggered dynamically changing access and mobility management policies

4.15.6.9.1 General

Access and mobility management 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 [20] 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.

4.15.6.9.2 Processing AF requests to influence access and mobility management policies 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 [2]), 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.

Figure 4.15.6.9.2-1: Handling an AF request targeting an individual UE without using NEF

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.

1. An AM Policy Association is established for a UE as described in clause 4.16.1.

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.

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.

2c. The AF sends to the PCF for the UE its request for influencing the access and mobility management 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 [20]). 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 [20], e.g. events related to change of service area coverage.

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.

Figure 4.15.6.9.2-2: Handling an AF request targeting an individual UE using NEF

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.

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 influencing the access and mobility management 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 [20]). 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 [20], e.g. events for request for service area coverage outcome. The NEF stores the request and sends a response to the AF.

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.

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.

2d. The NEF sends to PCF for the UE the request for influencing the access and mobility management 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 [20], e.g. events for change of service area coverage.

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.

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.

4.15.6.9.3 Processing AF requests to influence access and mobility management policies

With this procedure, the AF can provide its request to influence access and mobility management policies (for one or multiple UEs) at any time.

Figure 4.15.6.9.3-1: Handling an AF request to influence access and mobility management policies Policy

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 step 5 is not performed and the PCF itself determines the start/stop of application traffic or SM policy establishment/termination for a DNN, S-NSSAI and proceeds with step 6.

1. AM Policy Association establishment as described in clause 4.16.1.

2. The PCF for the UE may subscribe 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).

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 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, a list of (DNN, S-NSSAI)(s) and optionally a list of External Application Identifier(s) and requirements related to access and mobility management policies (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 access and mobility management related events, 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.

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.

3c. The UDR informs the NEF about the result of the operation of step 3b.

3d. The NEF informs the AF about the result of the Nnef_AMInfluence operation performed in step 3a.

NOTE 1: Steps 1, 2 and 3 can occur in any order.

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 2 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 step 6 follows.

5. Steps 2 to 10 in Figure 4.16.14.2.1-1 applies if access and mobility management policies depend on application in use, or steps 2 to 5 in Figure 4.16.14.2.2-1 applies if access and mobility management policies depend on SM Policy Association establishment and termination for a DNN, S-NSSAI combination

6. The PCF for the UE takes a policy decision and then it may initiate an AM Policy Association Modification procedure 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.

NOTE 2: The PCF for the UE can subscribe to the "start/stop of application traffic detection" events for multiple applications with different application identifiers in the same Npcf_PolicyAuthorization_Subscribe request. When PCF receives the notifications for multiple applications, the PCF for the UE can determine which access and mobility management policy to apply based on local configuration and operator policy.

4.15.6.10 Application guidance for URSP determination

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.

NOTE 1: The operator can negotiate with external party (typically a Corporate represented by an AF) dedicated DNN(s) and/or S-NSSAI(s) for the traffic of UE(s) of this external party. UE(s) of the external party can be identified by a group identifier.

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 [74].

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 URSP 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 [4] 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

Editor’s note: It is FFS whether the AF can provide SSC mode.

– 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 (e.g. a civic address or shapes).

NOTE 2: The different sets of Route selection parameters indicate different sets of PDU Session information (DNN, S-NSSAI) that can be associated with applications matching the application traffic descriptor. Each set is meant to apply for a specific (set of) spatial validity condition. Each set is associated with a Route selection precedence to cope with the case where multiple spatial validity conditions overlap.

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 UDM 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. If the request is targeting a group of UEs, NEF may also request UDM 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. If the request is targeting any UE (all UEs), NEF authorizes the request based on local policy (e.g. based on AF Id) without requesting for any service specific authorization from UDM. NEF requests UDM for service specific authorization for the service parameters provisioned via the Nudm_ServiceSpecificAuthorisation_Create service operation as defined in clause 4.15.6.7a.

If a group of UEs or any UE is requested, each individual UE authorization is performed at a later stage by PCF.

NOTE 3: The operator needs to ensure the consistency between the group related data and the UE group members subscription data, i.e. if a group is authorized for a given DNN/S-NSSAI as defined in the group related data, it needs to be ensured that all UE members of the group are provisioned with such DNN/S-NSSAI, since no individual UE check is required to be done by NEF against UDM.

NOTE 4: AF guidance for application traffic is not related with 5G VN 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 [74].

4.15.6.11 Void

4.15.6.12 Parameter Provisioning when the UE is identified via UE addressing information

Handling of Parameter Provisioning requests targeting an individual UE when the UE is identified via UE addressing information is described in clause 4.15.3.2.13. Once this has taken place, the Parameter Provisioning as described in other (sub)clauses of clause 4.15.6 may apply.