Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

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

 

4.3.6  Application Function influence on traffic routingWord-p. 138
4.3.6.1  General
Clause 4.3.6 describes the procedures between an Application Function and the SMF to maintain an efficient user plane path for Application Functions that require it.
As described in TS 23.501, clause 5.6.7, an Application Function may send requests to influence SMF routeing decisions for User Plane traffic of PDU Sessions. The AF requests may influence UPF (re)selection and allow routeing of user traffic to a local access (identified by a DNAI) to a Data Network. The AF may also provide in its request subscriptions to SMF events.
The following cases can be distinguished:
  • AF requests targeting an individual UE by a UE address; these requests are routed (by the AF or by the NEF) to an individual PCF using the BSF. This is described in clause 4.3.6.4.
  • NOTE 1:
    Such requests target an on-going PDU Session. Whether the AF needs to use the NEF or not is according to local deployment.
  • AF requests described in clause 5.6.7 of TS 23.501 targeting a group of UE(s), or any UE accessing a combination of DNN and S-NSSAI, or targeting individual UE by a GPSI as described in table 5.6.7-1. These AF requests may also affect UE(s) with an established PDU session. For such requests the AF shall contact the NEF and the NEF stores the AF request information in the UDR. 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 defined in TS 23.501, clause 6.3.7.2 and further described in clause 4.3.6.2.
NOTE 2:
Such requests can target on-going or future PDU Sessions.
If the AF interacts with PCF via the NEF, the NEF performs the following mappings where needed:
  • Map the AF-Service-Identifier into DNN and S-NSSAI combination, determined by local configuration.
  • Map the AF-Service-Identifier into a list of DNAI(s) and Routing Profile ID(s) determined by local configuration.
  • The NEF can only provide this mapping when the DNAI(s) being used by the applications are statically defined. When the DNAI(s) where applications are instantiated may vary dynamically, the AF should provide the target DNAI(s) in its request together with either Routing Profile ID(s) or with N6 traffic routing information.
  • 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.
  • Map the geographic zone identifier(s) in Spatial Validity Condition into areas of validity, determined by local configuration.
Up
4.3.6.2  Processing AF requests to influence traffic routing for Sessions not identified by an UE addressWord-p. 140
Up
NOTE 1:
The 5GC functions used in this scenario are assumed to all belong to the same PLMN (HPLMN in non-roaming case or VPLMN in the case of a PDU Session in LBO mode).
NOTE 2:
Nnef_TrafficInfluence_Create or Nnef_TrafficInfluence_Update or Nnef_TrafficInfluence_Delete service operations invoked from an AF located in the HPLMN for local breakout and home routed roaming scenarios are not supported.
Step 1.
To create a new request, the AF invokes an Nnef_TrafficInfluence_Create service operation. The content of this service operation (AF request) is defined in clause 5.2.6.7. The request contains also an AF Transaction Id. If it subscribes to events related with PDU Sessions the AF indicates also where it desires to receive the corresponding notifications (AF notification reporting information).
To update or remove an existing request, the AF invokes an Nnef_TrafficInfluence_Update or Nnef_TrafficInfluence_Delete service operation providing the corresponding AF Transaction Id.
Step 2.
The AF sends its request to the NEF. If the request is sent directly fom the AF to the PCF, the AF reaches the PCF selected for the existing PDU Session by configuration or by invoking Nbsf_management_Discovery service.
The NEF ensures the necessary authorization control, including throttling of AF requests and, as described in clause 4.3.6.1, mapping from the information provided by the AF into information needed by the 5GC.
Step 3.
(in the case of Nnef_TrafficInfluence_Create or Update): The NEF stores the AF request information in the UDR (Data Set = Application Data; Data Subset = AF traffic influence request information, Data Key = AF Transaction Internal ID, S-NSSAI and DNN and/or Internal Group Identifier or SUPI).
NOTE 3:
Both the AF Transaction Internal ID and, S-NSSAI and DNN and/or Internal Group Identifier or SUPI are regarded as Data Key when the AF request information are stored into the UDR, see Table 5.2.12.2.1-1.
(in the case of Nnef_TrafficInfluence_delete): The NEF deletes the AF requirements in the UDR (Data Set = Application Data; Data Subset = AF traffic influence request information, Data Key = AF Transaction Internal ID).
The NEF responds to the AF.
Step 4.
The PCF(s) that have subscribed to modifications of AF requests (Data Set = Application Data; Data Subset = AF traffic influence request information, Data Key = S-NSSAI and DNN and/or Internal Group Identifier or SUPI) receive(s) a Nudr_DM_Notify notification of data change from the UDR.
Step 5.
The PCF determines if existing PDU Sessions are potentially impacted by the AF request. For each of these PDU Sessions, the PCF updates the SMF with corresponding new PCC rule(s) by invoking Npcf_SMPolicyControl_UpdateNotify service operation as described in steps 5 and 6 in clause 4.16.5.
If the AF request includes a notification reporting request for UP path change, the PCF includes in the PCC rule(s) the information required for reporting the event, including the Notification Target Address pointing to the NEF or AF and the Notification Correlation ID containing the AF Transaction Internal ID.
Step 6.
When a PCC rule is received from the PCF, the SMF may take appropriate actions to reconfigure the User plane of the PDU Session such as:
  • Adding, replacing or removing a UPF in the data path to e.g. act as an UL CL or a Branching Point e.g. as described in clause 4.3.5.
  • Allocate a new Prefix to the UE (when IPv6 multi-Homing applies)
  • Updating the UPF in the target DNAI with new traffic steering rules
  • Subscribe to notifications from the AMF for an Area Of Interest via Namf_EventExposure_Subscribe service operation
Up
4.3.6.3  Notification of User Plane Management EventsWord-p. 141
The SMF may send a notification to the AF if the AF had subscribed to user plane management event notifications as described in clause 4.3.6.2 and in TS 23.501, clause 5.6.7. The following are the examples of such events:
  • A PDU Session Anchor identified in the AF subscription request has been established or released.
  • A DNAI has changed.
  • The SMF has received a request for AF notification and the on-going PDU Session meets the conditions to notify the AF.
  • Ethernet PDU Session Anchor Relocation as defined in clause 4.3.5.8.
The SMF uses notification reporting information received from PCF to issue the notification either via an NEF (2a, 2b and 4a, 4b) or directly to the AF (2c and 4c).
The following flow depicts the sequence of events:
Up
Step 1.
A condition for an AF notification has been met as described above. The SMF sends notification to the NF that is subscribed for SMF notifications. Further processing of the SMF notification depends on the receiving NF, as shown in steps 2a and 2c.
Step 2a.
If early notification via NEF is requested by the AF, the SMF notifies the NEF of the target DNAI of the PDU Session by invoking Nsmf_EventExposure_Notify service operation.
Step 2b.
When the NEF receives Nsmf_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.) as applicable according to TS 23.501, clause 5.6.7, and triggers the appropriate Nnef_TrafficInfluence_Notify message. In this case, step 2c is not applicable.
Step 2c.
If early direct notification is requested by the AF, the SMF notifies the AF of the target DNAI of the PDU Session by invoking Nsmf_EventExposure_Notify service operation.
Step 2d.
The AF replies to Nnef_TrafficInfluence_Notify by invoking Nnef_TrafficInfluence_AppRelocationInfo service operation either immediately or after any required application relocation in the target DNAI is completed. AF includes N6 traffic routing details corresponding to the target DNAI. AF may reply in negative e.g. if the AF determines that the application relocation cannot be completed successfully and/or on time.
Step 2e.
When the NEF receives Nnef_TrafficInfluence_AppRelocationInfo, the NEF triggers the appropriate Nsmf_EventExposure_AppRelocationInfo message.
Step 2f.
The AF replies to Nsmf_EventExposure_Notify by invoking Nsmf_EventExposure_AppRelocationInfo service operation either immediately or after any required application relocation in the target DNAI is completed. AF includes N6 traffic routing details corresponding to the target DNAI. AF may reply in negative e.g. if the AF determines that the application relocation cannot be completed successfully on time.
Step 3.
The SMF enforces the change of DNAI or addition, change, or removal of a UPF.
If the runtime coordination between 5GC and AF is enabled based on local configuration, according to the indication of "AF acknowledgment to be expected" included in AF subscription to SMF events, the SMF may wait for a response from the AF to the early notification before this step. The SMF does not perform this step until it receives a positive response from the AF, as described in TS 23.501, clause 5.6.7.
Step 4a.
If late notification via NEF is requested by the AF, the SMF notifies the NEF of the target DNAI of the PDU Session by invoking Nsmf_EventExposure_Notify service operation.
If the runtime coordination between 5GC and AF is enabled based on local configuration, according to the indication of "AF acknowledgment to be expected" included in AF subscription to SMF events, the SMF may send late notification and wait for a positive response from the AF before activating the new UP path, as described in TS 23.501, clause 5.6.7. If the SMF receives the notification of AF instance changes that indicates the target local DN is associated with another AF instance, the SMF conducts NEF to send notification to the target AF (different from the AF in steps 2b and 2c), and cancels any future notification message to source AF.
Step 4b.
When the NEF receives Nsmf_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.) as applicable according to TS 23.501, clause 5.6.7, and triggers the appropriate Nnef_EventExposure_Notify message. In this case, step 4c is not applicable.
4c. If late direct notification is requested by the AF, the SMF notifies the AF of the target DNAI of the PDU Session by invoking Nsmf_EventExposure_Notify service operation. If the SMF receives the notification of AF instance changes that indicates the target local DN is associated with another AF instance, the SMF sends notification to the target AF (different from the AF in steps 2b and 2c), and cancels any future notification message to source AF.
Step 4d.
The AF replies to Nnef_TrafficInfluence_Notify by invoking Nnef_TrafficInfluence_AppRelocationInfo service operation either immediately or after any required application relocation in the target DNAI is completed. AF includes N6 traffic routing details corresponding to the target DNAI. AF may reply in negative e.g. if the AF determines that the application relocation cannot be completed successfully on time.
Step 4e.
When the NEF receives Nnef_TrafficInfluence_AppRelocationInfo, the NEF triggers the appropriate Nsmf_EventExposure_AppRelocationInfo message.
Step 4f.
The AF replies to Nsmf_EventExposure_Notify by invoking Nsmf_EventExposure_AppRelocationInfo service operation either immediately or after any required application relocation in the target DNAI is completed. AF includes N6 traffic routing details corresponding to the target DNAI. AF may reply in negative e.g. if the AF determines that the application relocation cannot be completed successfully on time.
Up
4.3.6.4  Transferring an AF request targeting an individual UE address to the relevant PCFWord-p. 143
Up
Depending on the AF deployment (see TS 23.501, clause 6.2.10), the AF may send the AF request to PCF directly, in which case step 1 is skipped, or via the NEF.
Step 1.
[Conditional] If the AF sends the AF request via NEF, the AF sends Nnef_TrafficInfluenceCreate/Update/Delete Request targeting an individual UE address to the NEF. This request corresponds to an AF request to influence traffic routing that targets an individual UE address.
When NEF receives an AF request from AF, the NEF ensures the necessary authorization control and, as described in clause 4.3.6.1, mapping from the information provided by the AF into information needed by the 5GC. The NEF responds to the AF.
Step 2.
[Conditional] AF/NEF consumes Nbsf_Management_Discovery service operation (providing at least the UE address) to find out the address of the relevant PCF if the PCF address is not available on the NEF based on local configuration, otherwise step 1 is skipped.
NOTE:
The AF/NEF finds the BSF based on local configuration or using the NRF.
Step 3.
BSF provides the PCF address in the Nbsf_Management_Discovery response to AF/NEF.
Step 4.
If step 1 was performed, NEF invokes the Npcf_PolicyAuthorization service to the PCF to transfer the AF request. If an AF sends the AF request directly to the PCF, AF invokes Npcf_PolicyAuthorization service and the PCF responds to the AF.
Step 5.
The PCF updates the SMF with corresponding new PCC rule(s) with PCF initiated SM Policy Association Modification procedure as described in clause 4.16.5.2. When a PCC rule is received from the PCF, the SMF may take appropriate actions, when applicable, to reconfigure the User plane of the PDU Session, such as:
  • Adding, replacing or removing UPF(s) in the data path, e.g. to act as UL CL, Branching Point, and/or PDU Session Anchor e.g. as described in clause 4.3.5.
  • Allocate a new Prefix to the UE (when IPv6 multi-Homing applies).
  • Updating the UPF regarding the target DNAI with new traffic steering rules.
  • Subscribe to notifications from the AMF for an Area Of Interest via Namf_EventExposure_Subscribe service operation.
Up
4.3.7  CN-initiated selective deactivation of UP connection of an existing PDU SessionWord-p. 144
The following procedure is used to deactivate UP connection (i.e. data radio bearer and N3 tunnel) for an established PDU Session of a UE in CM-CONNECTED state.
For an always-on PDU Session, the SMF should not configure the UPF to report inactivity.
Up
Step 1.
The SMF determines that the UP connection of the PDU Session can be deactivated in following cases:
  • During handover procedure, if all the QoS Flows of a PDU Session are rejected by the target NG-RAN (as described in clause 4.9.1), or if a PDU Session is failed to setup indicated by the AMF (see step 7 of clause 4.9.1.3.3). SMF proceeds with step 2 and step 3, the steps 5 to 9 are skipped;
  • The UPF detects that the PDU Session has no data transfer for a specified Inactivity period as described in clause 4.4.2.2;
  • For a LADN PDU Session, the AMF notifies to the SMF that the UE moved out of the LADN service area; or
  • The AMF notifies to the SMF that the UE moved out of the Allowed Area.
The SMF may decide to release the UPF of N3 terminating point. In that case the SMF proceeds with step 2 and step 3. Otherwise, if the SMF decides to keep the UPF of N3 terminating points, the SMF proceeds with step 4.
Step 2.
The SMF may initiate an N4 Session Release procedure to release the intermediate UPF of N3 terminating point. If there are multiple intermediate UPFs, this step can be performed for each UPFs to be released. The SMF needs to initiate N4 Session Modification procedure to the UPF (i.e. N9 terminating point or PDU Session Anchor) connecting to the released UPF in step 3.
Step 3.
If the intermediate UPF(s) of N3 terminating point is released in step 2, the SMF initiates an N4 Session Modification procedure towards the UPF (PDU Session Anchor or another intermediate UPF) connecting to the released UPF, indicating the need to remove CN Tunnel Info for N9 tunnel of the corresponding PDU Session. In this case, the UPF connecting to the released UPF buffers the DL packets for this PDU Session or drops the DL packets for this PDU session or forwards the DL packets for this PDU session to the SMF, based on buffering instruction provided by the SMF as described in clause 5.8.3.2 or clause 5.8.3.3 of TS 23.501. If the PDU Session corresponds to a LADN and the UE moved out of the LADN service area, the SMF may notify the UPF connecting to the released UPF to discard downlink data for the PDU Sessions and/or to not provide further Data Notification messages.
Otherwise, N4 Session Modification procedure occurs toward N3 terminating point.
Step 4.
If the UPF of N3 terminating point is not released in step 2, the SMF initiates an N4 Session Modification procedure indicating the need to remove AN Tunnel Info for N3 tunnel of the corresponding PDU Session. In this case, the UPF buffers the DL packets for this PDU Session or drops the DL packets for this PDU session or forwards the DL packets for this PDU session to the SMF, based on buffering instruction provided by the SMF as described in clause 5.8.3.2 or clause 5.8.3.3 of TS 23.501. If the PDU Session corresponds to a LADN and the UE moved out of the LADN service area, the SMF may notify the UPF to discard downlink data for the PDU Sessions and/or to not provide further Data Notification messages.
Step 5.
The SMF invokes the Namf_Communication_N1N2MessageTransfer service operation (PDU Session ID, N2 SM Information (N2 Resource Release Request (PDU Session ID))) to release the NG-RAN resources associated with the PDU Session.
Step 6.
The AMF sends the N2 PDU Session Resource Release Command including N2 SM information (N2 Resource Release Request (PDU Session ID)) received from the SMF via N2 to the NG-RAN.
Step 7.
The NG-RAN may issue NG-RAN specific signalling exchange (e.g. RRC Connection Reconfiguration) with the UE to release the NG-RAN resources related to the PDU Session received from the AMF in step 5. When a User Plane connection for a PDU Session is released, the AS layer in the UE indicates it to the NAS layer.
If the UE is in RRC Inactive state, this step is skipped. When the UE becomes RRC Connected state from RRC Inactive state, the NG-RAN and UE synchronize the released radio resources for the deactivated PDU Session as described in TS 36.331 and TS 38.331.
Step 8.
The NG-RAN acknowledges the N2 PDU Session Resource Release Command to the AMF including N2 SM Resource Release Ack (User Location Information, Secondary RAT Usage Data).
Step 9.
The AMF invokes the Nsmf_PDUSession_UpdateSMContext service operation (N2 SM Information(Secondary RAT Usage Data)) to acknowledge the Namf service received in step 5.
Up

Up   Top   ToC