Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  16.5.1

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…   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.5.2  Change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions

The following procedure is triggered by SMF in order to change the PDU Session Anchor serving a PDU Session of SSC mode 3 for a UE. This procedure releases the existing PDU Session associated with an old PDU Session Anchor (i.e. UPF1 in Figure 4.3.5.2-1) after having established a new PDU Session to the same DN with a new PDU Session Anchor (i.e. UPF2 in Figure 4.3.5.2-1), which is controlled by the same SMF. The SMF may determine that a new SMF needs to be reallocated.
Reproduction of 3GPP TS 23.502, Figure 4.3.5.2-1: Change of SSC mode 3 PDU Session Anchor with multiple PDU Sessions
Up
Step 1.
The SMF determines that the serving UPF or the SMF needs to be changed. If the "Indication of application relocation possibility" attributes in the PCC rule indicates no DNAI change takes place once selected for this application, the SMF determines that the SMF can not be changed.
Step 2.
If the SMF had sent an early notification to the AF and the runtime coordination between 5GC and AF is enabled based on local configuration as specified in clause 4.3.6.3, according to the indication of "AF acknowledgment to be expected" included in AF subscription to SMF events, the SMF waits for a notification response from the AF. If the SMF receives a negative notification response from the AF, the SMF may stop the procedure.
The SMF invokes the Namf_Communication_N1N2MessageTransfer (PDU Session ID, SMF Reallocation requested indication, N1 SM container (PDU Session Modification Command (Cause, PCO (PDU Session Address Lifetime value)))) where PDU Session ID indicates the existing PDU Session to be relocated and Cause indicates that a PDU Session re-establishment to the same DN is required.
The SMF Reallocation requested indication indicates whether the SMF is requested to be reallocated.
The PDU Session Address Lifetime value is delivered to the UE upper layers in PCO and indicates how long the network is willing to maintain the PDU Session. The SMF starts a PDU Session Release timer corresponding to the PDU Session Address Lifetime value.
Step 3a.
The AMF forwards the NAS message to the UE. The UE can provide the release timer value to the upper layers if received in the PDU Session Modification Command.
Step 3b.
The UE acknowledges the PDU Session Modification Command.
Step 3c.
The AMF forwards the N1 SM container (PDU Session Modification Command ACK) received from the (R)AN to the SMF1 via Nsmf_PDUSession_UpdateSMContext service operation.
Step 3d.
The SMF1 replies with a Nsmf_PDUSession_UpdateSMContext Response.
Step 4.
If the UE receives PDU Session Modification Command, the UE may decide to initiate the PDU Session Establishment procedure described in clause 4.3.2.2, to the same DN with the following differences:
In Step 1 of clause 4.3.2.2.1, according to the SSC mode, UE generates a new PDU Session ID and initiates the PDU Session Establishment Request using the new PDU Session ID. The new PDU Session ID is included as PDU Session ID in the NAS request message, and the Old PDU Session ID which indicates the existing PDU Session to be released is also provided to AMF in the NAS request message.
In Step 2 of clause 4.3.2.2.1, if SMF reallocation was requested in Step 2 of this clause, the AMF selects a different SMF. Otherwise, the AMF sends the Nsmf_PDUSession_CreateSMContext Request to the same SMF serving the Old PDU Session ID.
In Step 3 of clause 4.3.2.2.1, the AMF include both PDU Session ID and Old PDU Session ID in Nsmf_PDUSession_CreateSMContext Request. The SMF detects that the PDU Session establishment request is related to the trigger in step 2 based on the presence of an Old PDU Session ID in the Nsmf_PDUSession_CreateSMContext Request. The SMF stores the new PDU Session ID and selects a new PDU Session Anchor (i.e. UPF2) for the new PDU Session.
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 sends a late notification to the AF before Step 11 of clause 4.3.2.2.1 and waits for a notification response from the AF. If the SMF received a negative notification response from the AF, the SMF may stop the procedure. Otherwise the SMF continue the following procedures to activate the UP path of the new PDU Session.
Step 5.
After the new PDU Session is established the UE starts using the IP address/prefix associated with the new PDU Session for all new traffic and may also proactively move existing traffic flow (where possible) from the old PDU Session to the new PDU Session.
Step 6.
The old PDU Session is released as described in clause 4.3.4 either by the UE before the timer provided in step 3 expires (e.g., once the UE has consolidated all traffic on new PDU Session or if the session is no more needed) or by the SMF upon expiry of this timer.
Up

4.3.5.3  Change of SSC mode 3 PDU Session Anchor with IPv6 Multi-homed PDU SessionWord‑p. 126
Clause 4.3.5.3 describes a procedure for service continuity with SSC mode 3 that uses the multi-homed PDU Session described in TS 23.501, clause 5.6.4.3. In this case the SMF prepares a new PDU Session Anchor first and then notifies the UE of the existence of a new IP prefix, as depicted in Figure 4.3.5.3-1. This procedure is applicable only to PDU Sessions of IPv6 type.
Reproduction of 3GPP TS 23.502, Figure 4.3.5.3-1: Change of PDU Session Anchor with IPv6 Multi homed PDU Session
Up
The UE has an established PDU Session with the PDU Session Anchor (i.e. UPF1 in Figure 4.3.5.3-1). The PDU Session's User Plane involves at least the (R)AN and the PDU Session Anchor.
Step 1.
At some point the SMF decides to allocate to the PDU Session the PDU Session with a new PDU Session Anchor.
Step 2.
The SMF selects a new UPF and using N4 configures the UPF as a new PDU Session Anchor (i.e. UPF2 in Figure 4.3.5.3-1) of the multi-homed PDU Session. In the process a new IPv6 prefix (IP@2) is allocated for the PDU Session. If the PCF has subscribed to the IP allocation/release event, the SMF performs a Session Management Policy Modification procedure as defined in clause 4.16.5 to provide the new allocated IPv6 prefix to the PCF. The PCF invokes Nbsf_Management_Update service operation to register the tuple (IPv6 prefix, PCF id) for the PDU session identified by (SUPI, DNN, S-NSSAI) in the BSF.
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 sends an early notification to the AF after the new UPF (new PSA) is selected and waits for a notification response from the AF. If the SMF receives a negative notification response from the AF, the SMF may stop the procedure.
Step 3.
The SMF selects a Branching Point (BP) UPF as described in Clause of 6.3.3 of TS 23.501. The selection of BP UPF may consider the location of UPF1 and UPF2 to ensure a suitable location of the BP UPF relative to the UPF1 and the UPF2.
Step 4.
The SMF configures via N4 the UPF selected in step 3 (BP UPF in Figure 4.3.5.3-1) as a Branching Point for the multi-homed PDU Session. It provides the Branching Point with the necessary UL traffic forwarding rules (related with the prefix of the IPv6 source address of UL traffic). Also, the SMF provides AN Tunnel Info for N3 tunnel setup and CN Tunnel Info for N9 tunnel setup to the BP UPF and obtains CN Tunnel Info from the BP UPF.
Step 5-6.
The SMF performs N4 Session Modification procedure with PSAs. During this procedure, the SMF provides CN Tunnel Info received from the BP UPF to set up an N9 tunnel between BP and PSAs.
Step 7.
The SMF invokes the Namf_Communication_N1N2MessageTransfer service operation containing N2 SM Information with CN Tunnel Info for the N3 tunnel setup.
Step 8.
The AMF sends an N2 Request including N2 SM Information received from the SMF to the (R)AN. The (R)AN acknowledges to the AMF with an N2 Response.
Step 9a.
The AMF carries the N2 Response sent by the (R)AN to the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation.
9\step b. The SMF responds to Nsmf_PDUSession_UpdateSMContext service operation from the AMF.
Step 10-11.
If the runtime coordination between 5GC and AF is enabled based on local configuration as specified in clause 4.3.6.3, according to the indication of "AF acknowledgment to be expected" is included in AF subscription to SMF events, the SMF sends a late notification to the AF and waits for a notification response from the AF. If the SMF receives a negative notification response from the AF, the SMF may stop the procedure.
The SMF notifies the UE of the availability of the new IP prefix. This is performed using an IPv6 Router Advertisement message (RFC 4861 [6]). The SMF sends a Router Advertisement to the UE via the new PSA with a new prefix (IP@2) and sends another Router Advertisement to the UE via the old PSA with the old prefix (IP@1) and zero value in the preferred lifetime field and a value in the valid lifetime field according to RFC 4862 [8]. The UE shall update the valid lifetime of the old prefix (IP@1) to the signalled value regardless of the remaining lifetime. The valid lifetime value indicates the time how long the SMF is willing to keep the old prefix. The valid lifetime value may be decided by SMF based on local configuration.
The UE starts using IP@2 for all new traffic and may also proactively move existing traffic flow (where possible) from IP@1 to IP@2.
Step 12.
After the timer expires, the SMF releases the UE's old IPv6 prefix (IP@1). At this point the UE implicitly releases the old IP prefix. The SMF sends an N4 Session Modification Request to the BP to release UP resource for N9 tunnel between the BP and old PSA.
Step 13.
The SMF releases the old PDU Session context with the old PDU Session Anchor (UPF1 in Figure 4.3.5.3-1). If the PCF has subscribed to the IP allocation/release event, the SMF performs a Session Management Policy Modification procedure as defined in clause 4.16.5 to notify the PCF of the IPv6 prefix release. The PCF shall invoke Nbsf_Management_Update service operation to remove the tuple (IPv6prefix, PCF id) for the PDU session identified by (SUPI, DNN,S-NSSAI) in BSF.
Step 14-18.
The SMF may optionally release the Branching Point from the User Plane path.
Up


Up   Top   ToC