Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.502  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.2.11…   4.2.11.5…   4.3…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.3.3   4.3.4…   4.3.4.3   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…   4.11.1.2.2   4.11.1.2.3   4.11.1.3…   4.11.1.3.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.3.2.5…   4.15.4…   4.15.6…   4.15.6.7…   4.15.6.13…   4.15.6.14…   4.15.9…   4.15.9.4…   4.15.13…   4.15.13.4…   4.16…   4.16.4…   4.16.8…   4.16.11…   4.16.14…   4.16.15…   4.17…   4.17.9…   4.18…   4.19…   4.22…   4.23…   4.23.7…   4.23.7.3.3   4.23.7.3.4…   4.23.9…   4.23.9.4…   4.23.11…   4.24…   4.25…   4.25.6…   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   5.2.18…   A…   E…   F…   G   H… 
4.15.6.7 Service specific parameter provisioning  4.15.6.7.1 General  4.15.6.7.2 Service specific parameter provisioning by AF to HPLMN  4.15.6.7.3 Service specific parameter provisioning by AF to VPLMN  4.15.6.7a Authorization of service specific parameter provisioning  4.15.6.8 Set a policy for a future AF session  4.15.6.9 Procedures for AF-triggered dynamically changing access and mobility management policies  4.15.6.9.1 General  4.15.6.9.2 Processing AF requests to influence access and mobility management policies targeting an individual UE  4.15.6.9.3 Processing AF requests to influence access and mobility management policies  4.15.6.10 Application guidance for URSP determination  4.15.6.12 Parameter Provisioning when the UE is identified via UE addressing information 
...

 

4.15.6.7  Service specific parameter provisioning |R16|  p. 450

4.15.6.7.1  General |R18|  p. 450
This clause describes the procedures for enabling the AF to provide service specific parameters to 5G system via NEF.
The AF may issue requests on behalf of applications not owned by the PLMN serving the UE.
The AF request sent to the NEF contains the information as below:
  1. Service Description.
    Service Description is the information to identify a service the Service Parameters are applied to. The Service Description in the AF request can be represented by the combination of DNN and S-NSSAI, an AF-Service-Identifier or an External Application Identifier.
  2. Service Parameters.
    Service Parameters are the service specific information which needs to be provisioned in the Network and delivered to the UE in order to support the service identified by the Service Description.
    VPLMN ID(s) that indicates the PLMN(s) where the AF guidance on URSP determination and all its RSD(s), applies.
  3. Target UE(s) or a group of UEs or PLMN ID(s) of inbound roamers.
    Target UE(s) or a group of UEs or PLMN ID(s) of inbound roamers 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 are identified by an External Group Identifiers as defined in TS 23.682. If identifiers of target UE(s) or a group of UEs or PLMN ID(s) of inbound roamers are not provided, then the Service Parameters shall be delivered to any UEs of the PLMN of the NEF 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.
Up
4.15.6.7.2  Service specific parameter provisioning by AF to HPLMN |R18|  p. 450
Figure 4.15.6.7.2-1 shows procedure for service specific parameter provisioning. The AF uses Nnef_ServiceParameter service to provide the service specific parameters to the HPLMN and the UE. In the roaming case, PCF is replaced by H-PCF, the AMF interacts with the V-PCF which interacts with H-PCF.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.7.2-1: Service specific information provisioning by AF to HPLMN
Figure 4.15.6.7.2-1: Service specific information provisioning by AF to HPLMN
Up
Step 0a.
The AMF establishes UE Policy Association as specified in clause 4.16.11.
Step 0b.
PCF requests notifications from the UDR on changes in UE policy information.
Step 1.
To create a new request, the AF invokes an Nnef_ServiceParameter_Create service operation. The request may include subscription information to the report of the outcome of UE Policy delivery.
To update or remove an existing request, the AF invokes an Nnef_ServiceParameter_Update or Nnef_ServiceParameter_Delete service operation together with the corresponding Transaction Reference ID which was provided to the AF in Nnef_ServiceParameter_Create response message.
The content of this service operation (AF request) includes the information described in clause 5.2.6.11.
Step 2.
The AF sends its request to the NEF. The NEF authorizes the AF request. The NEF performs the following mappings:
  • Map the AF-Service-Identifier into DNN and S-NSSAI combination, determined by local configuration.
  • Map the External Application Identifier into the corresponding Application Identifier known in the core network.
Step 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.
Step 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.
(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.
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.
For PIN service, PCF generates the URSP rules with PIN ID in the Traffic Descriptor as specified in Table 6.6.2.1-2 of TS 23.503.
Step 6.
The PCF initiates UE Policy delivery as specified in clause 4.2.4.3.
Step 7.
If the AF subscribed to notifications about the outcome of UE Policies delivery due to Service specific parameter provisioning 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 including the SUPI, the list of GPSI(s) if available, and if provided in the step 2a, the Internal-Group-Id.
If the 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.
If the PCF determines that it cannot yet deliver URSP Rules that are based on the service parameters from the AF, then the PCF may report in the interim status that URSP Rules have not yet been delivered by the PCF 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.
Step 8.
When the NEF receives Npcf_EventExposure_Notify, the NEF performs information mapping (e.g. AF Transaction Internal ID provided in Notification Correlation ID to AF Transaction ID, SUPI to GPSI, Internal-Group-Id to External-Group-Id, etc.) and triggers the appropriate Nnef_ServiceParameter_Notify message.
Up
4.15.6.7.3  Service specific parameter provisioning by AF to VPLMN |R18|  p. 452
Figure 4.15.6.7.3-1 shows procedure for service specific parameter provisioning by the AF to VPLMN.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.7.3-1: Service specific information provisioning by AF to VPLMN
Figure 4.15.6.7.3-1: Service specific information provisioning by AF to VPLMN
Up
Step 0a.
Same as in step 0a of Figure 4.15.6.7.2-1.
Step 0b-0c.
The V-PCF may request to V-UDR on changes in UE policy information and H-PCF may subscribe to H-UDR.
Step 1-2.
Steps 1-2 of Figure 4.15.6.7.2-1 apply with the following differences:
  • The AF and NEF belong to the VPLMN. The AF may belong to third party with agreement with VPLMN.
  • When the AF provides application guidance on URSP Rule determination to the VPLMN, it will target "PLMN ID(s) of inbound roamers". The NEF in the VPLMN rejects any request for a GPSI or an External-Group-ID of a different PLMN.
Step 3-5.
Steps 3-5 of Figure 4.15.6.7.2-1 apply with the following differences:
  • AF, NEF and UDR belong to VPLMN. The AF may belong to third party with agreement with VPLMN.
  • The UDR in the VPLMN notifies the V-PCF(s) that have subscribed to the reception of application guidance on URSP determination.
  • In step 5, the V-PCF receives updates on application guidance on URSP determination for the PLMN ID of a SUPI that has a UE Policy Association established. The PLMN ID of the SUPI is included in the target "PLMN ID(s) of inbound roamers" in step 2. In this case, the V-PCF checks whether application guidance on URSP determination applies for the SUPI as specified in clause 6.1.2.2.4 of TS 23.503.
Step 5a.
The V-PCF sends the Service Parameters including the mapped HPLMN S-NSSAI values to the H-PCF and subscribes to the result of the delivery of UE Policies if the delivery result was requested by the AF, using the event reporting on "Notification on outcome of UE Policies delivery" described in clause 6.1.3.18 of TS 23.503.
The H-PCF requests V-PCF to notify the result of UE policy delivery to the UE.
Step 6.
The H-PCF generates new or updated URSP Rules considering the Service Parameters received from the V-PCF in step 5a as specified in clause 6.1.2.2.4 of TS 23.503.
Step 7-8.
Steps 7-8 of Figure 4.15.6.7.2-1 apply with the following differences:
  • Notification is sent from V-PCF to the AF belonging to the VPLMN or third party with agreement with VPLMN.
Up

4.15.6.7a  Authorization of service specific parameter provisioning |R17|  p. 454

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).
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.7a-1: Service Specific Authorization for an individual UE or group of UEs
Figure 4.15.6.7a-1: Service Specific Authorization for an individual UE or group of UEs
Up
Step 1.
The AF initiates the procedure as specified in clause 4.15.6.7.
Step 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.
Step 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.
Step 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.
Step 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.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.7a-2: Service Specific Authorization Update procedure
Figure 4.15.6.7a-2: Service Specific Authorization Update procedure
Up
Step 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).
Step 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.
Step 2.
The NEF sends Nudm_ServiceSpecificAuthorisation_UpdateNotify Response message to the UDM to acknowledge the authorization update.
Step 3.
If the authorization is revoked, the NEF removes the service specific parameters from the UDR.
Step 4.
The NEF informs the AF that the service parameters authorisation status has changed by sending Nnef_ServiceParameter_Notify Request (GPSI or External Group Id, TLTRI, Status, Cause) message to the AF to update the authorization.
Step 5.
The AF responds to the NEF with Nnef_ServiceParameter_Notify Response message.
Up

4.15.6.8  Set a policy for a future AF session |R16|  p. 456

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

4.15.6.9  Procedures for AF-triggered dynamically changing access and mobility management policies |R17|  p. 456

4.15.6.9.1  General  p. 456
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 6.2.1.6 of TS 23.503, This case is described in clause 4.15.6.9.2.
  • AF requests targeting an individual UE (identified by its GPSI), a group of UEs (identified by an Internal Group Identifier or an External Group Identifier), any UE accessing a combination of DNN and S-NSSAI, or any UE, or any inbound roaming UEs identified by their home PLMN ID(s) using an application identified by an External Application Identifier. 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. 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. This case is described in clause 4.15.6.9.3.
Up
4.15.6.9.2  Processing AF requests to influence access and mobility management policies targeting an individual UE  p. 457
This procedure is used for individual UEs when the request shall be applied independently of conditions related to the application traffic. Depending on the AF deployment (see clause 6.2.10 of TS 23.501), the AF may interact with NFs of the Core Network either directly or via the NEF. The procedure for the direct case is described in Figure 4.15.6.9.2-1, while the procedure for the NEF-mediated case is described in Figure 4.15.6.9.2-2.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.9.2-1: Handling an AF request targeting an individual UE without using NEF
Figure 4.15.6.9.2-1: Handling an AF request targeting an individual UE without using NEF
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (AF, PCF, BSF, AMF) belong to the home PLMN.
Step 1.
An AM Policy Association is established for a UE as described in clause 4.16.1.
Step 2a.
The AF searches the PCF for the UE using Nbsf_Management_Subscribe with SUPI or GPSI as input, indicating that it is searching for the PCF that handles the AM Policy Association of the UE.
Step 2b.
The BSF provides to the AF the identity of the PCF for the UE for the requested SUPI or GPSI via an Nbsf_Management_Notify operation. If a matching entry already exists in the BSF when step 2a is performed, this shall be immediately reported to the AF.
Step 2c.
The AF sends to the PCF for the UE its request for 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). As part of the Npcf_AMPolicyAuthorization request, the AF may subscribe (within the Create and Update operations) or unsubscribe (within the Delete operation) to relevant events specified in clause 6.1.3.18 of TS 23.503, e.g. events related to change of service area coverage.
Step 3.
The PCF takes a policy decision and then an AM Policy Association Modification procedure initiated by the PCF for the UE may be performed as described in clause 4.16.2.2. If the AF has subscribed to access and mobility management related events (i.e. request for service area coverage outcome) in step 2, the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.9.2-2: Handling an AF request targeting an individual UE using NEF
Figure 4.15.6.9.2-2: Handling an AF request targeting an individual UE using NEF
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (AF, NEF, PCF, BSF, AMF) belong to the home PLMN, or the AF belongs to a third party with which the home PLMN has an agreement.
Step 1.
An AM Policy Association is established for a UE as described in clause 4.16.1.
Step 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). As part of the Nnef_AMPolicyAuthorization request, the AF may request to subscribe (within the Create and Update operations) or unsubscribe (within the Delete operation) for relevant events specified in clause 6.1.3.18 of TS 23.503, e.g. events for request for service area coverage outcome. The NEF stores the request and sends a response to the AF.
Step 2b.
The NEF searches the PCF for the UE using Nbsf_Management_Subscribe with SUPI as input parameter, indicating that it is searching for the PCF that handles the AM Policy Association of the UE.
Step 2c.
The BSF provides to the NEF the identity of the PCF for the UE for the requested SUPI via an Nbsf_Management_Notify operation. If a matching entry already exists in the BSF when step 2b is performed, this shall be immediately reported to the NEF.
Step 2d.
The NEF sends to PCF for the UE 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, e.g. events for change of service area coverage.
Step 2e.
The NEF informs the AF about events to which the AF has potentially subscribed (i.e. events for change of service area coverage) using Nnef_AMPolicyAuthorization_Notify.
Step 3.
The PCF takes a policy decision and then an AM Policy Association Modification procedure initiated by the PCF for the UE may be performed as described in clause 4.16.2.2. If the AF has subscribed to access and mobility management related events i.e. request for service area coverage outcome in step 2, then the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF as described in clause 4.16.2.2.
Up
4.15.6.9.3  Processing AF requests to influence access and mobility management policies  p. 459
With this procedure, the AF can provide its request to influence access and mobility management policies (for one or multiple UEs) at any time.
Reproduction of 3GPP TS 23.502, Fig. 4.15.6.9.3-1: Handling an AF request to influence access and mobility management policies Policy
Figure 4.15.6.9.3-1: Handling an AF request to influence access and mobility management policies Policy
Up
This procedure concerns 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. This procedure concerns also the local breakout roaming case where the involved entities (i.e. AF, NEF, PCF, BSF, UDR, AMF) serving the UE belong to the VPLMN or the AF belongs to a third party with which the VPLMN 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.
Step 1.
AM Policy Association establishment as described in clause 4.16.1.
Step 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 or PLMN ID of inbound roamers)).
Step 3a.
To create a new request, the AF provides "AM influence information" data to the NEF using the Nnef_AMInfluence_Create service operation (together with the AF identifier and potentially further inputs as specified in clause 5.2.6.23.2), including a target (one UE identified by GPSI, a group of UEs identified by an External Group Identifier, or any UE (for non roaming case), or any inbound roaming UEs identified by their PLMN ID(s)), 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 AF 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.
The target "any UE" is applicable if an External Application Identifier or list of (DNN, S-NSSAI) is also provided.
The target "any inbound roaming UEs identified by their PLMN ID(s)" is applicable if an External Application Identifier or list of (DNN, S-NSSAI) is also provided.
To update or remove an existing request, the AF invokes an Nnef_AMInfluence_Update or Nnef_AMInfluence_Delete service operation providing the corresponding AF Transaction Id.
Step 3b.
The NEF stores, updates, or removes the policy data of step 3a in the UDR, having translated any External Group Identifier to an Internal Group Identifier and any GPSI to a SUPI.
Step 3c.
The UDR informs the NEF about the result of the operation of step 3b.
Step 3d.
The NEF informs the AF about the result of the Nnef_AMInfluence operation performed in step 3a.
Step 4.
The UDR notifies the PCF(s) that have a matching subscription (from step 2) about the data stored, updated, or removed in step 3. If matching entries already existed in the UDR when step 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.
Step 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.
Step 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.
Up

4.15.6.10  Application guidance for URSP determination |R17|  p. 460

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 may be in the Home PLMN, as it is the PCF that determines the URSP for the UE, or in the VPLMN and then the Application guidance for URSP determination is provided to the PCF in the HPLMN via the PCF of the VPLMN. The PCF in the VPLMN translates the Service Parameters values provided by the AF for inbound roamer to values applicable to the HPLMN, e.g. S-NSSAI as described in TS 23.503.
The guidance for URSP determination may be used to provide 5GC with guidance for the URSPs depending on the UE location. This is further described in TS 23.548.
For providing guidance for URSP determination, the procedure defined in clause 4.15.6.7 is performed with the following considerations:
  1. Service Description indicates an AF Identifier.
  2. Service Parameters.
    Information on the AF guidance for URSP determination which consists of a list of 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 Table 6.6.2.1-2). When AF provides application guidance for URSP determination for PIN, the application traffic descriptor shall include PIN ID.
    • 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. In the case of AF guidance for URSP determination for PIN, this shall be provided by the AF.
    • Requested PDU session type.
      • 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).
    • VPLMN ID(s) that indicates the PLMN(s) where the AF guidance on URSP determination and all its RSD(s), applies.
    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)).
    An AF sets the Requested PDU session type if the AF requests to change the PDU session type of the URSP rules.
    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.
  3. The Target UE identifier(s) that may be a specific UE, identified by a GPSI, or a group of UE(s), identified by an External-Group-ID, or any UE of the PLMN of the NEF, or the PLMN ID(s) of inbound roamers that the AF request may be associated with.
    The information on the AF guidance for URSP determination provided by the AF may be associated to:
    1. UEs of the PLMN (of the NEF) when roaming in other PLMNs. In this case, the AF guidance for URSP determination targets to a specific UE, a group of UEs or any UE of the PLMN. In this case, the AF guidance for URSP determination associated to a specific UE, a group of UEs or any UE of the PLMN shall be also associated with the corresponding VPLMN(s) where the AF guidance for URSP determination shall be applied if the UE roams to that VPLMN(s). The list of VPLMN ID(s) is included in the Service Parameters.
    2. An inbound roamer from one or more PLMN(s). In this case, the AF targets the AF guidance for URSP determination only with the inbound roamers of corresponding PLMN(s). The PLMN ID is included in the Service Parameters.
  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.6 of TS 23.548.
Up

4.15.6.11  Void

4.15.6.12  Parameter Provisioning when the UE is identified via UE addressing information |R17|  p. 462

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.

Up   Top   ToC