Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  18.5.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.23.9  Branching Point or UL CL controlled by I-SMFp. 621

4.23.9.0  Overviewp. 621

The procedures in this clause describe the Addition, Removal and Change of PDU Session Anchor (PSA2), Branching Point or UL CL controlled by I-SMF. They all rely on following principles:
  1. When a (new) I-SMF is inserted (e.g. as described in clause 4.23.7 or clause 4.23.11), the I-SMF provides the DNAI list it supports to the SMF. This list is assumed to remain constant during the N16a association between the I-SMF and the SMF for a PDU Session.
  2. Based on the DNAI list information received from I-SMF, the SMF may then at any time provide or update the list of DNAI(s) of interest for this PDU Session to I-SMF. This may take place e.g. when the I-SMF provides the DNAI list it supports or when new or updated or removed PCC rule(s) is/are received by the SMF as defined in clause 4.23.6. This list of DNAI(s) of interest for this PDU Session indicates to the I-SMF the list of DNAI(s) candidate for local traffic steering within the PDU Session.
    An indication of whether Multi-homing is possible is also provided to the I-SMF and the I-SMF uses this information to decide whether multi-homing can be used for the PDU Session.
  3. Whenever the I-SMF has inserted or removed or changed a local offload capability the I-SMF invokes a Nsmf_PDUSession_Update Request to indicate to the SMF the list of corresponding DNAI(s). Based on this indication the SMF invokes a Nsmf_PDUSession_Update Request to send the corresponding N4 information to the I-SMF.
  4. Then SMF may then at any time invoke a Nsmf_PDUSession_Update Request to send N4 information to the I-SMF.
  5. The I-SMF may at any time send a Nsmf_PDUSession_Update Request to forward to the SMF N4 events received from a local UPF; this may e.g. correspond to traffic reporting.
  6. When source I-SMF is to be removed from a PDU Session (e.g. at I-SMF change or removal), the SMF issues the N4 information targeting the UL CL/BP (s) and L-PSA(s) controlled by this I-SMF, including requests to release the corresponding N4 Sessions.
    If the N9 forwarding tunnel to support the EAS session continuity controlled by I-SMF(s) is not established between the source ULCL and the target UL CL, when the Source I-SMF receives a Nsmf_PDUSession_ReleaseSMContext Request from AMF, it initiates a data forwarding timer (if indirect data forwarding applies) before releasing the resources of the PDU Session. When the Source I-SMF has received N4 release from SMF, it releases the UL CL/BP (s) and L-PSA(s) resources either directly if no data forwarding timer is started, or at the expiry of the data forwarding timer. Otherwise if the N9 forwarding tunnel to support the EAS session continuity controlled by I-SMF(s) is established between the source UL CL and target UL CL, the source I-SMF releases the UL CL/BP (s) and L-PSA(s) after no active traffic over the N9 forwarding tunnel.
    When IPv6 multi-homing is used and an I-SMF is removed, the SMF re-configure the UE to not use the original IP prefix @L-PSA(s).
Up

4.23.9.1  Addition of PDU Session Anchor and Branching Point or UL CL controlled by I-SMFp. 622

This clause describes a procedure to add a PDU Session Anchor and Branching Point or UL CL controlled by I-SMF.
Reproduction of 3GPP TS 23.502, Fig. 4.23.9.1-1: Addition of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF
Up
Step 1.
UE has an established PDU Session with a UPF including the PDU Session Anchor 1, which is controlled by SMF.The I-SMF and an I-UPF controlled by I-SMF have already been inserted for the PDU Session. Events described in item 1 and 2 of clause 4.23.9.0 have taken place.
Step 2.
At some point, using the list of DNAI(s) of interest for this PDU Session received from the SMF, the I-SMF decides to establish a new PDU Session Anchor e.g. due to UE mobility. The I-SMF selects a UPF and using N4 establishes the new PDU Session Anchor 2 (PSA2) of the PDU Session. During this step:
  • (if needed) the PSA2 CN Tunnel Info of the local N9 termination on the PSA2 may be determined,
  • In the case of IPv6 multi-homing applies to the PDU Session, a new IPv6 prefix corresponding to PSA2 is allocated by the I-SMF or by the UPF supporting the PSA2.
Step 3.
The I-SMF may select a UPF that will be acting as UL CL or Branching Point and replace the current I-UPF.
If a new UPF that will act as UL CL/Branching Point is selected (i.e. the existing I-UPF is replaced), the I-SMF uses N4 establishment to provide the 5G AN Tunnel Info, the PSA1 and (where applicable) PSA2 CN Tunnel Info to the new UPF.
Step 4.
The I-SMF invokes Nsmf_PDUSession_Update Request (Indication of UL CL or Branching Point insertion, IPv6 prefix @PSA2, DNAI(s) supported by PSA2, DL Tunnel Info of the new UL CL/Branching Point, if any) to SMF. Whether the UL CL/Branching Point and PSA2 are supported by the same UPF is transparent to the SMF. Multiple local PSAs (i.e. PSA2) may be inserted at one time, each corresponds to a DNAI and/or an IPv6 prefix in the case of multi-homing.
The I-SMF informs the SMF that a UL CL or Branching Point is inserted, the I-SMF provides DNAI(s) supported by PSA2 to the SMF. The DL Tunnel Info of UL CL/Branching Point is provided to SMF if a new UPF is selected to replace I-UPF in step 3.
In the case of IPv6 multi-homing PDU Session, the IPv6 prefix @PSA2 is also provided to SMF.
The SMF performs the Session Management Policy Modification procedure as defined in clause 4.16.5 to provide the new allocated IPv6 prefix to the PCF. The SMF may also send a notification to the AF, as described in clause 4.3.6.3.
The DNAI(s) supported by PSA2 may be used by the SMF to determine which PCC rules are to be applied at UPF(s) controlled by the I-SMF. The SMF acknowledges the Nsmf_PDUSession_Update from the I-SMF
Step 5.
If a new DL Tunnel Info of UL CL/ Branching Point has been provided in step 4, the SMF updates the PSA1 via N4 with the CN Tunnel Info for the downlink traffic. Now the downlink packets from PSA1 are sent to UE via the new UPF which will act as Branching Point/UL CL. The SMF may also update the forwarding rules in PSA1 if some traffic is to be moved to UPFs controlled by I-SMF.
Step 6.
The SMF provides I-SMF with N4 information for the PSA and for the UL CL with a SMF initiated Nsmf_PDUSession_Update Request (set of (N4 information, involved DNAI), Indication of no DNAI change, Indication of no local PSA change)). The SMF generates N4 information for local traffic handling based on PCC rules and CHF requests that will be enforced by UPFs controlled by I-SMF. The N4 information for local traffic handling corresponds to N4 rules (PDR, FAR, URR, QER, etc.) related with the support of a DNAI. This is described in clause 5.34.6 of TS 23.501. N4 information for local traffic handling may indicate information (as the 5G AN Tunnel Info) that the SMF does not know and that the I-SMF needs to determine itself to build actual rules sent to the UPF(s). If the rule is applied to the local PSA, the N4 information includes the associated DNAI.
If the "Indication of application relocation possibility" or "UE IP address preservation indication" attributes are included in the PCC rule, the SMF includes the corresponding Indication of no DNAI change and Indication no local PSA change respectively.
If the CN Tunnel Info at the PSA1 has changed, the SMF may also provide its new value.
The I-SMF uses N4 information for local traffic handling received from the SMF as well as 5G AN Tunnel Info received from the 5G AN via the AMF and local configuration to determine N4 rules to send to the UPF(s) it is controlling.
Step 7.
The I-SMF updates the PSA2 via N4 providing N4 rules determined in step 6. It also provides the Branching Point or UL CL CN Tunnel Info for down-link traffic if the PSA2 and the UL CL/Branching Point are supported by different UPF(s).
Step 8.
The I-SMF updates the Branching Point or UL CL via N4 providing N4 rules determined in step 6.
Step 9.
The I-SMF Issues a Nsmf_PDUSession_Update Response to SMF that may include N4 information received from the local UPF(s).
Step 10.
Steps 6-8 of clause 4.3.5.4 are performed. In the case of IPv6 multi-homing PDU Session, the SMF notifies the UE of the IPv6 prefix @PSA2 and updates the UE with IPv6 multi-homed routing rule via a PSA controlled by the SMF.
Step 11.
If a new UPF is selected to replace I-UPF in step 3, the I-SMF uses N4 Release to remove the I-UPF of the PDU Session. The I-UPF releases resources for the PDU Session.
Up

4.23.9.2  Removal of PDU Session Anchor and Branching Point or UL CL controlled by I-SMFp. 625

This clause describes a procedure to remove a PDU Session Anchor and Branching Point or UL CL controlled by I-SMF.
Reproduction of 3GPP TS 23.502, Fig. 4.23.9.2-1: Removal of PDU Session Anchor and Branching Point or UL CL controlled by I-SMF
Up
Step 1.
UE has an established PDU Session with a UPF including the PDU Session Anchor 1 (controlled by SMF) and the UL-CL/BP and the PDU Session Anchor 2 (controlled by I-SMF). Events described in item 1 and 2 of clause 4.23.9.0 have taken place.
At some point the I-SMF decides to remove the PDU Session Anchor 2 and UL-CL/BP function, e.g. due to UE mobility.
Step 2.
The I-SMF may select a new UPF acting as new I-UPF and replace the existing I-UPF which was acting as UL-CL/BP before.
If a new UPF acting as new I-UPF is selected, the I-SMF uses N4 establishment to provide the PSA1 CN Tunnel Info and (R)AN Tunnel Info to the new I-UPF.
Step 3.
The I-SMF invokes Nsmf_PDUSession_Update Request (Indication of Removal of traffic offload, Removal of IPv6 prefix @PSA2, DNAI associated with the PSA2, DL Tunnel Info of new I-UPF, if any) to SMF. Multiple local PSAs may be removed, in this case, the I-SMF provides for each local PSA to be removal, the associated DNAI and an IPv6 prefix in the case of multi-homing.
The I-SMF informs the SMF that local traffic offload is removed. In the case of IPv6 multi-homing, the I-SMF also notifies the SMF with the removal of the IPv6 prefix @PSA2.
The SMF issues a SM Policy Association Modification (clause 4.16.5) corresponding to the IP address allocation/release PCRT(Policy Control Request Trigger). The SMF may also send a notification to the AF, as described in clause 4.3.6.3.
Step 4.
If a new UPF that replaces existing I-UPF is selected in step 2, the SMF updates the PSA1 via N4. It provides the CN Tunnel Info of the new I-UPF for the downlink traffic. The SMF may update the packet handling rules in PSA1 as now all traffic is to be moved to PSA1.
Step 5.
In the case of IPv6 multi-homing, the SMF notifies the UE to stop using the IPv6 prefix corresponding to PSA2. Also the SMF sends IPv6 multi-homed routing rule along with the IPv6 prefix corresponding to PSA1 to the UE. Based on the information provided in the Router Advertisement, the UE starts using the IPv6 prefix (corresponding to PSA1) for corresponding traffic.
Step 7.
The SMF provides I-SMF with N4 information for the local UPF(s) with a SMF initiated Nsmf_PDUSession_Update Request; The N4 information indicates the removal of the traffic offload rules.
Step 8.
If a new UPF that replaces existing I-UPF is selected in step 2, the I-SMF releases the old I-UPF. Otherwise the I-SMF updates the existing I-UPF with new rules in order to remove the UL-CL/BP functionality from that I-UPF.
If a new UPF that replaces existing I-UPF is selected in step 2, the SMF updates the (R)AN with the new I-UPF CN Tunnel Info.
If the PSA2 is not collocated with UL-CL/BP function, the I-SMF releases it via N4.
Step 9.
The I-SMF answers to the SMF with a Nsmf_PDUSession_Update Response SMF that may include N4 information received from the local UPF(s).
Up

4.23.9.3  Change of PDU Session Anchor for IPv6 multi-homing or UL CL controlled by I-SMFp. 626

This clause describes a change of UL-CL/BP function, e.g. addition of a new PDU Session Anchor (i.e. PSA2) and release of the existing additional PDU Session Anchor (i.e. PSA0), via modifying IPv6 multi-homing or UL CL rule in the same Branching Point or UL CL under controlled by the same I-SMF.
Reproduction of 3GPP TS 23.502, Fig. 4.23.9.3-1: Change of PDU Session Anchor for Branching Point or UL CL controlled by I-SMF
Up
Step 1.
The UE has an established PDU Session with a UPF including the PDU Session Anchor 1(controlled by SMF) and the PDU Session Anchor 0 (PSA0) and an I-UPF acting as UL CL or BP (controlled by I-SMF). Events described in item 1 and 2 of clause 4.23.9.0 have taken place.
Step 2.
At some point the I-SMF decides to establish a new PDU Session Anchor and release the existing PDU Session Anchor e.g. due to UE mobility. The I-SMF selects a UPF and using N4 establishes the new PDU Session Anchor 2 of the PDU Session.
In the case of IPv6 multi-homing PDU Session, the I-SMF ensures allocation of a new IPv6 prefix corresponding to PSA2.
Step 3.
The I-SMF invokes Nsmf_PDUSession_Update Request (Indication of Change of traffic offload, (new allocated IPv6 prefix @PSA2, DNAI(s) supported by PSA2), (Removal of IPv6 prefix @PSA0, DNAI(s) supported by PSA0)) to SMF.
The I-SMF informs the SMF that a change of traffic offload may occur. Multiple local PSAs may be changed. The I-SMF provides:
  • for each local PSA to be added, the DNAI now reachable and in the case of multi-homing: the new allocated IPv6 prefix @PSA2;
  • for each local PSA no more reachable, the DNAI no more reachable and in the case of multi-homing, the old IPv6 prefix @PSA0.
Step 4.
The SMF may issue a SM Policy Association Modification (clause 4.16.5) corresponding to the IP address allocation/release PCRT. The SMF may also send an "early" notification to the AF, as described in clause 4.23.6.3.
Step 5.
The SMF generates the N4 information based on DNAI(s) information received in step 3.The SMF provides I-SMF with N4 information for the PSA and for the UL CL with a SMF initiated Nsmf_PDUSession_Update Request (set of (N4 information, involved DNAI), Indication of no DNAI change, Indication of no local PSA change)). The information includes N4 information to remove the traffic offload related to the DNAI(s) that are no more reachable and to enable the traffic offload related to the DNAI(s) that are now reachable.
Step 6-7.
Same as step 7-8 of clause 4.23.9.1
Step 8.
The I-SMF releases via N4 the PSA0 if PSA0 is not collocated with UL CL/BP, or updates the UL CL/BP to remove corresponding rules if PSA0 is collocated with UL CL/BP.
Step 9.
The I-SMF issues a Nsmf_PDUSession_Update Response to SMF that may include N4 information received from the local UPF(s) including the PSA0.
Step 10.
Same as step 7-8 of clause 4.3.5.4 are performed.
Up

Up   Top   ToC