Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  17.6.0

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.4…   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2…   4.11.3…   4.12…   4.12.6…   4.12a…   4.12b…   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.3.2.5…   4.15.4…   4.15.6.7…   4.15.7…   4.16…   4.16.4…   4.16.8…   4.16.11…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24…   4.25…   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   5.2.18…   A…   E…   F…

 

4.15.6.7  Service specific parameter provisioning |R16|p. 375

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

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

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

Reproduction of 3GPP TS 23.502, Fig. 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. 380

4.15.6.9.1  Generalp. 380
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. This case is described in clause 4.15.6.9.2.
  • AF requests targeting an individual UE (identified by its GPSI), a group of UEs (identified by an Internal Group Identifier or an External Group Identifier), any UE accessing a combination of DNN and S-NSSAI, or all UEs using an application identified by an External Application Identifier. This case is described in clause 4.15.6.9.3. For such requests the AF shall contact the NEF and the NEF stores the AF request information in the UDR. The PCF(s) receive a corresponding notification if they had subscribed to the creation / modification / deletion of the AF request information corresponding to UDR Data Keys / Data Sub-Keys. This is further described in clause 4.15.6.9.3. The AF is not aware if the target UEs are with or without an already established AM Policy Association and with or without ongoing PDU Sessions.
Up
4.15.6.9.2  Processing AF requests to influence access and mobility management policies targeting an individual UEp. 380
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
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
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 policiesp. 382
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
Up
This procedure concerns only non-roaming scenarios, i.e. to cases where the involved entities serving the UE (i.e. AF, NEF, PCF, BSF, UDR, AMF) belong to the home PLMN, or the AF belongs to a third party with which the home PLMN has an agreement.
The PCF for the UE and the PCF for the PDU Session can be the same entity, then 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).
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 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.
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. 383

This clause describes the procedures to allow an AF to provide guidance for URSP determination to 5G system via NEF. The AF may belong to the operator or to an external party. The PCF considered in this clause is in the Home PLMN as it is the PCF that determines the URSP for the UE.
The guidance for URSP determination may be used to provide 5GC with guidance for the URSPs depending on the UE location. This is further described in TS 23.548.
For providing guidance for URSP determination, the procedure defined in clause 4.15.6.7 is performed with the following considerations:
  1. Service Description indicates an AF Identifier.
  2. Service Parameters.
    Information on the AF guidance for URSP determination which consists of a list of 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).
    • one or more sets of Route selection parameters, each parameter may correspond to:
    • (DNN, S-NSSAI). This may be provided by the AF or determined by the NEF based on the AF Identifier when it is not provided by the AF and the AF provides only one instance of AF guidance for URSP determination
    • a default Route selection precedence value to be used for the application traffic when Route selection precedence with a corresponding spatial validity condition is not provided.
    • Route selection precedence with a corresponding spatial validity condition that indicates where the Route selection parameters apply. This may correspond to a geographical area (e.g. a civic address or shapes).
    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.
  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.
Up

4.15.6.11Void

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

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