D.2 Procedures

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

D.2.1 Addition of PSA and UL CL/BP controlled by I-SMF

The corresponding stage 2 call flow is specified in clause 4.23.9.1 of 3GPP TS 23.502 [29].

When the I-SMF decides to select a new PSA2 and/or a UL CL/BP (replacing the current I-UPF) for the PDU session, e.g. using the list of DNAI(s) of interest for this PDU Session received from the SMF, it shall establish PFCP sessions towards UL CL/BP and/or PSA2 respectively.

The I-SMF shall allocate PDR/FAR/URR/QER ID not larger than 255 and shall set Precedence value not smaller than 65536. The SMF shall allocate PDR/FAR/URR/QER ID from 256 onwards and shall set Precedence value not larger than 65535.

NOTE 1: Since PDRs provided by the SMF to control the traffic via PSA2 have higher precedence than PDRs generated by the I-SMF, the I-SMF need not modify the PDRs generated by its own. See the example further down.

For the PFCP session established between I-SMF and UL CL/BP:

– the I-SMF shall create at least a UL PDR to identify the UL traffic received from AN and a UL FAR to forward the traffic towards PSA1;

– the I-SMF shall create a DL PDR to identify the DL traffic from the PSA1 and a DL FAR to forward the traffic towards the AN;

NOTE 2: The I-SMF needs to include DL N9 F-TEID in the SMF PDUSession Update Request sent to SMF as specified in 3GPP TS 29.502 [50].

For the PFCP session established between I-SMF and PSA2:

– the I-SMF shall create at least an UL PDR to identify the UL traffic received from UL CL/BP and a UL FAR to forward the traffic towards the DN;

– the I-SMF shall create a DL PDR to identify the DL traffic from the DN and a DL FAR to forward the traffic towards the UL CL/BP;

NOTE 3: If IPv6 multi-homing applies to the PDU session, a new IPv6 prefix can be allocated by the PSA2, which is sent in SMF PDUSession Update Request to SMF.

Upon successful establishment of the PFCP sessions, the I-SMF indicates to the SMF that it has inserted an UL CL/BP and PSA by sending a SMF PDUSession Update Request to the SMF (see step 4 clause 4.23.9.1 of 3GPP TS 23.502 [29]).

When the I-SMF indicates to the SMF that it has inserted an UL CL/BP and PSA, the SMF shall send two PFCP Session Establishment Requests towards the I-SMF, one targeting the UL CL/BP and another one targeting the PSA2, with the following information:

1) PFCP Session Establishment Request for the UL CL/BP:

– For the support of the UL traffic offloaded towards PSA2:

– one Create Traffic Endpoint IE, just including a Traffic EndPoint ID; the UL traffic endpoint corresponds to the N3 endpoint of UL CL/BP; the UL traffic endpoint shall not contain information about the N3 interface, i.e. the Network Instance IE and the Local F-TEID IE shall not be included;

– at least one Create PDR IE with:

– the Source Interface set to "Access";

– the Traffic Endpoint IE referring to the UL traffic endpoint;

– any additional Packet Detection Information to define the UL traffic to match (e.g. SDF Filter, Application ID, Ethernet Packet Filter);

– any applicable PDR information, e.g. FAR ID, URR ID, QER ID.

UL PDRs shall not contain the Outer Header Removal IE.

– one UL FAR set to forward (or drop) the UL traffic, with the Destination Interface set to "Core". If more than one local PSA has been inserted by the I-SMF, the UL FAR shall indicate the Data Network Access Identifier associated to the local PSA towards which the UL traffic shall be forwarded; the UL FAR may do so otherwise.

– For the support of the DL traffic offloaded from PSA2:

– one Create Traffic Endpoint IE, including a Traffic EndPoint ID; the DL traffic endpoint shall not contain information about the N9 interface, i.e. the Network Instance IE and the Local F-TEID IE shall not be included;

– at least one Create PDR IE with:

– the Source Interface set to "Core";

– the Traffic Endpoint IE referring to the DL traffic endpoint;

– any applicable PDR information, e.g. FAR ID, URR ID, QER ID;

– one DL FAR set to forward (or drop) the DL traffic to the access network, with the Destination Interface set to "Access"; the DL FAR shall not contain the Outer Header Creation IE;

NOTE 4: The I-SMF is responsible for all the N3 and N9 protocol aspects (e.g. Network Instance, Local F-TEID, outer header creation or removal).

– any applicable QERs and/or URRs.

2) PFCP Session Establishment Request for the PSA2:

– For the support of the UL traffic offloaded at PSA2:

– one Create Traffic Endpoint IE, just including a Traffic EndPoint ID; the UL traffic endpoint shall not contain information about the N9 interface, i.e. the Network Instance IE and the Local F-TEID IE shall not be included;

– at least one Create PDR IE with:

– the Source Interface set to " Access ";

– the Traffic Endpoint IE referring to the UL traffic endpoint;

– any applicable PDR information, e.g. FAR ID, URR ID, QER ID;

UL PDRs shall not contain the Outer Header Removal IE;

– one UL FAR set to forward (or drop) the UL traffic, with the Destination Interface set to "Core".

– For the support of the DL traffic offloaded at PSA2:

– one Create Traffic Endpoint IE, including a Traffic EndPoint ID and any additional information to define the DL traffic endpoint (e.g. Network Instance IE, UE IP Address IE); the DL traffic endpoint corresponds to the N6 endpoint of PSA2;

– at least one Create PDR IE with:

– the Source Interface set to "Core";

– the Traffic Endpoint IE referring to the DL traffic endpoint;

– any additional Packet Detection Information to define the DL traffic to match (e.g. SDF Filter, Application ID, Ethernet Packet Filter);

– any applicable PDR information, e.g. FAR ID, URR ID, QER ID;

– one DL FAR set to forward (or drop) the DL traffic, with the Destination Interface set to " Access "; the DL FAR shall not contain the Outer Header Creation IE.

NOTE 5: The I-SMF is responsible for all the N3 and N9 protocol aspects (e.g. Network Instance, Local F-TEID, outer header creation or removal).

– Any applicable QERs and/or URRs.

In the PFCP Session Establishment Request for the UL CL/BP, the SMF shall not include any N4 rules for the UL and DL traffic via PSA1 (i.e. non-offload traffic exchanged between AN and PSA1).

The I-SMF shall translate the SMF instructions into N4 instructions to send to the UL CL/BP and PSA2, for the UL and DL traffic in one or more PFCP Session Modification Request message(s) (the I-SMF has already created a PFCP session in the UL CL/BP and PSA2 in steps 2 and 3 of Figure 4.23.9.1-1 of 3GPP TS 23.502 [29]). In particular:

– the I-SMF shall map the UL and DL traffic endpoints requested to be created by the SMF in the UL CL/BP and PSA2 respectively to the UL and DL traffic endpoints created in the UL CL/BP and in PSA2 for UL and DL traffic; the I-SMF shall update the DL traffic endpoint in PSA2 if necessary, e.g. with any Framed-Route or Framed-IPv6-Route information received from the SMF;

– the I-SMF shall add the Outer Header Removal IE to the UL PDR of the UL CL/BP;

– the I-SMF shall add an Outer Header Creation IE to DL PDR(s) of the UL CL/BP to add a GTP-U header set to the 5G-AN F-TEID, and to add a Network Instance IE if needed;

– the I-SMF shall update the UL FAR of the UL CL/BP and the DL FAR of the PSA2 with N9 protocol information, if the UL CL/BP and PSA2 are located on different UPFs; if more than one local PSA has been inserted by the I-SMF, the I-SMF shall derive the local PSA towards which the UL traffic shall be forwarded from the Data Network Access Identifier IE indicated in the UL FAR over N16a.

– the I-SMF shall overwrite the Apply Action IE of the DL FAR received from the SMF according to the User Plane connection state of the PDU session, e.g. to request the UPF to buffer packets if the PDU session is deactivated, or to forward the DL packets otherwise;

– the I-SMF shall merge the N4 information received for the UL CL/BP and the PSA2 if the UL CL/BP and PSA2 are located on the same UPF.

The I-SMF shall return two PFCP Session Establishment Response messages to the SMF for UL CL/BP and PSA2 respectively. In the PFCP Session Establishment Response messages, the I-SMF may set the Node ID IE and UP F-SEID IE to the ones provided by the UL CL/BP and the PSA2. The Created PDR and Created Traffic Endpoint shall not be included.

The I-SMF shall generate by itself the N4 rules to control the UL and DL traffic via PSA1 (i.e. non-offload traffic exchanged between AN and PSA1), and send such N4 rules to the UL CL/BP together with the N4 rules mapped from the N4 information sent by the SMF.

EXAMPLE: Example of addition of PSA2 and UL CL controlled by I-SMF:

1) in step 3 of clause 4.23.9.1 of 3GPP TS 23.502 [29], when establishing the PFCP session between I-SMF and UL CL/BP, the I-SMF can provide the following PDRs/FARs to the UL CL/BP:

UL PDR1 (UL F-TEID 1 is allocated to receive UL traffic from NG-RAN ) and
UL FAR1 (forward all traffic towards PSA1);

DL PDR2 (N9 DL F-TEID is allocated to receive DL traffic from PSA1 which will be reported in SMF PDUSession Update Request towards SMF) and
DL FAR2 (forward all traffic towards NG-RAN N3 F-TEID).

2) in step 2 of clause 4.23.9.1 of 3GPP TS 23.502 [29], when establishing the PFCP session between I-SMF and PSA2, the I-SMF can provide the following PDRs/FARs to PSA2:

UL PDR1 (to receive traffic from UL CL, i.e. including the UL F-TEID of UL CL) and
UL FAR1 (forward all traffic towards DN);

DL PDR2 (to receive traffic from DN) and
DL FAR2 (forward all traffic towards UL CL’s N9 DL F-TEID).

3) in step 6 of clause 4.23.9.1 of 3GPP TS 23.502 [29], the SMF sends an SMF PDUSession Update Request to the I-SMF encapsulating binary encoded PFCP Session Establishment Request messages to request to offload service traffic towards PSA2, e.g. for a service which is identified by app-id 100;

In the PFCP Session Establishment Request message for PSA2, the SMF includes:

UL PDR 256 (where the PDI includes app-id =100) and
UL FAR 256 (forward all traffic towards DN);

DL PDR 257 (sending traffic to UL CL, where the PDI includes app-id=100) and
DL FAR 257 (sending traffic to UL CL).

In the PFCP Session Establishment Request message for UL CL, the SMF includes:

UL PDR 256 (where the PDI includes app-id =100) and
UL FAR 256 (forward traffic towards PSA2);

DL PDR 257 (identifying all traffic received from PSA2) and
DL FAR 257 (forward traffic toward access);

4) in step 7 of clause 4.23.9.1 of 3GPP TS 23.502 [29], the I-SMF maps rules received in 3) in the PFCP Session Modification Request message to the PSA2, and the PDR1 and PDR2 provisioned earlier by I-SMF during the PFCP session establishment procedure will not be matched for the application traffic identified by app-id 100 due to a lower precedence.

5) in step 8 of clause 4.23.9.1 of 3GPP TS 23.502 [29], the I-SMF can maps rules received in 3) in the PFCP Session Modification Request message to the UL CL, the PDR1 (forwarding all traffic to PSA1) provisioned earlier by I-SMF during the PFCP session establishment procedure will not be matched for the application traffic identified by app-id 100 due to a lower precedence.

D.2.2 Removal of PSA and UL CL/BP

The corresponding stage 2 call flow is specified in clause 4.23.9.2 of 3GPP TS 23.502 [29].

When the I-SMF indicates to the SMF that it is removing a UL CL/BP and PSA, the SMF shall send two PFCP Session Deletion Requests towards the I-SMF, one for the UL CL/BP and another one for the PSA2. The I-SMF shall return two PFCP Session Deletion Responses to the SMF (including usage reports if applicable, see clause 7.5.7.1).

D.2.3 Change of PSA

The corresponding stage 2 call flow is specified in clause 4.23.9.3 of 3GPP TS 23.502 [29].

When the I-SMF indicates to the SMF a change of traffic offload, the SMF shall send a PFCP Session Establishment Request (for the new DNAI), a PFCP Session Deletion Request (for the old DNAI) towards the I-SMF, and a PFCP Session Modification Request for the UL CL/BP if needed. The I-SMF shall behave as described in clauses D.2.1 and D.2.2 and return a PFCP Session Establishment Response, a PFCP Session Deletion Response and a PFCP Session Modification Response if needed.

D.2.4 Traffic Usage Reporting

The SMF may request the I-SMF to report traffic usage measurements as specified in the rest of this specification.

The I-SMF shall report traffic usage measurements to the SMF as specified in the rest of this specification, i.e. in PFCP Session Report Request, PFCP Session Modification Response and PFCP Session Deletion Response messages.

D.2.5 Updating N4 information towards I-SMF

The SMF may send PFCP Session Modification Requests with updated PFCP rules (e.g. updated PDR, QER URR), targeting the UL CL/BP or PSA2, as specified in the rest of this specification. The I-SMF shall return PFCP Session Modification Responses accordingly.

D.2.6 PDU session release

Corresponding stage 2 requirements are specified in clauses 4.23.3a and 4.23.5.2 of 3GPP TS 23.502 [29].

If an UL/CL or BP was inserted in the data path by the I-SMF:

– In scenarios where the I-SMF sends a Release Request to the SMF, e.g. UE deregistration procedure, the I-SMF shall first send a PFCP Session Deletion Request to the UL CL/BP and local PSA to retrieve non-zero traffic usage reports, before sending the Release Request over N16a to the SMF. If the I-SMF needs to report traffic usage measurements to the SMF for the UL CL/BP and/or for the local PSA, the I-SMF shall encapsulate one PFCP Session Report Request for the UL CL/BP and/or one PFCP Session Report Request for the local PSA in the Release Request sent over N16a to the SMF. The SMF shall encapsulate corresponding PFCP Session Report Response(s) in the Release Response.

If more traffic usage measurements need to be reported to the SMF, the I-SMF shall send one or more Update Request(s) towards the SMF before sending a Release Request.

Upon receiving the Release Request from the I-SMF, the SMF shall consider that the PFCP sessions between the I-SMF and UL CL/BP and local PSA have been deleted.

– In scenarios where the I-SMF sends an Update Request to the SMF, e.g. UE initiated PDU session release, if the I-SMF needs to report traffic usage measurements to the SMF for the UL CL/BP and/or for the local PSA, the I-SMF may encapsulate one PFCP Session Report Request for the UL CL/BP and/or one PFCP Session Report Request for the local PSA in the Update Request sent over N16a to the SMF (i.e. in step 3a of Figure 4.3.4.3-1 of 3GPP TS 23.502 [29])). If so, the SMF shall encapsulate corresponding PFCP Session Report Response(s) in the Update Response.

The SMF shall then send two PFCP Session Deletion Requests towards the I-SMF, one for the UL CL/BP and another one for the local PSA, in the subsequent Update Request initiated by the SMF towards the I-SMF to trigger the release of the PDU session (i.e. in step 3a of Figure 4.3.4.3-1 of 3GPP TS 23.502 [29]). The I-SMF shall encapsulate corresponding PFCP Session Deletion Response(s) in the Update Response (i.e. in step 14 of Figure 4.3.4.3-1 of 3GPP TS 23.502 [29]), including usage reports if applicable, see clause 7.5.7.1. The PFCP Session Deletion Response may indicate that additional usage reports need to be signalled; if so, the I-SMF shall send additional Update Request(s) towards the SMF encapsulating PFCP Session Report Requests and the SMF shall return Update Response (s) encapsulating PFCP Session Report Responses. When the last usage report has been received, the SMF shall notify the I-SMF that the PDU session is released (in step 16a of Figure 4.3.4.3-1 of 3GPP TS 23.502 [29]).

D.2.7 Simultaneous change of UL CL/BP and PSA controlled by I-SMF

The corresponding stage 2 call flow is specified in clause 4.23.9.4 of 3GPP TS 23.502 [29]. Figure D.2.7-1 specifies the details of the signalling interactions between the SMF and the I-SMF, and between the I-SMF and the UL CL/BPs and PSAs.

Figure D.2.7-1 – Simultaneous change of UL CL/BP and PSA controlled by I-SMF

1-2. These steps are the same as described in clause D.2.1 and correspond to steps 2 and 3 of Figure 4.23.9.4-1 of 3GPP TS 23.502 [29].

3. The I-SMF indicates to the SMF that it has inserted an UL CL/BP and PSA if both the I-SMF and the SMF support the "N9FSC" feature defined in clause 6.1.8 of 3GPP TS 29.502 [50], or the I-SMF indicates to the SMF a change of UL CL/BP and PSA if either the I-SMF or the SMF does no support the "N9FSC" feature.

4. When the I-SMF indicates to the SMF an insertion of UL CL/BP and PSA, and data forwarding between the new and old UL CL/BPs for EAS session continuity is required, the SMF shall send to the I-SMF a PFCP Session Establishment Request (for the new DNAI) and a PFCP Session Establishment Request for the new UL CL/BP.

When the I-SMF indicates to the SMF a change of UL CL/BP and PSA, or when the I-SMF indicates to the SMF an insertion of UL CL/BP and PSA and data forwarding between the new and old UL CL/BPs for EAS session continuity is not required, the SMF shall send to the I-SMF a PFCP Session Establishment Request (for the new DNAI), a PFCP Session Deletion Request (for the old DNAI), a PFCP Session Deletion Request for the old UL CL/BP and a PFCP Session Establishment Request for the new UL CL/BP. The I-SMF shall behave as described in clauses D.2.1 and D.2.2 and return two PFCP Session Establishment Responses and two PFCP Session Deletion Responses.

The following signalling applies if both the I-SMF and the SMF support the "N9FSC" feature and data forwarding between the new and old UL CL/BPs for EAS session continuity is required.

Step 4 is same as described in clause D.2.1, in addition, the SMF shall send the following additional information to the I-SMF:

– in the PFCP Session Establishment Request for the new UL CL/BP:

– Create PDR(s) IE for the UL traffic to forward to the old UL CL/BP with:

– the Source Interface set to "Access";

– the Traffic Endpoint IE referring to the UL traffic endpoint;

– any additional Packet Detection Information to define the UL traffic to match for N9 forwarding (e.g. SDF Filter, Application ID, Ethernet Packet Filter);

– any applicable PDR information, e.g. FAR ID, QER ID;

– the UL PDR shall not contain the Outer Header Removal IE;

– the Precedence value of the above UL PDR for N9 forwarding to the old UL CL/BP shall be set to a higher precedence than the UL PDR for the new UL CL/BP to support the UL traffic offloaded towards the PSA2, if the same Packet Detection Information applies.

– one UL FAR, set to "forward" the UL traffic to the old UL CL/BP, with the Destination Interface set to "Core"; the UL FAR shall not contain the Outer Header Creation IE.

– the following additional information in the Update Request:

– the indication that a N9 forwarding tunnel between UL CLs/BPs is required;

– the list of Rule IDs pointing to the UL PDRs included in the PFCP Session Establishment Request for the new UL CL/BP to establish the UL N9 data forwarding in the new UL CL/BP;

– the value of the timer to detect the end of activity on the N9 forwarding tunnel.

NOTE: The UL PDR(s) for UL traffic offloaded towards PSA2 will not be matched as long as the UL PDR(s) for UL traffic forwarding to the old UL CL/BP is installed in the target UL CL/BP if the same Packet Detection Information applies, since the latter PDR(s) has a higher precedence than the former.

5. The step is same as described in clause D.2.1, i.e. the SMF updates the remote PSA (PSA1) via N4 with the DL Tunnel Info of the Target UL CL/BP for the downlink traffic.

6. The I-SMF shall map the above rules received in the PFCP Session Establishment Request message to the new UL CL/BP. In particular:

– the I-SMF shall add the Outer Header Removal IE to the UL PDR(s) of the UL CL/BP for the UL traffic to be forwarded to the old UL CL/BP;

– the I-SMF shall add an Outer Header Creation IE to the UL FAR of the UL CL/BP to add a GTP-U header set to the old N3 UL F-TEID in the old UL CL/BP if it can be reused;

– the I-SMF shall provision a DL PDR to receive DL traffic forwarded from the old UL CL/BP and a DL FAR to forward the received DL traffic towards the NG-RAN. The new UL CL/BP shall assign a new N9 DL F-TEID for the old UL CL/BP.

7. The I-SMF returns two PFCP Session Establishment Responses to the SMF.

8. The step is same as described in clause D.2.1.

9. The I-SMF shall send the following information to the old UL CL/BP in the PFCP Session Modification Request based on the additional information received in the Update Request from the SMF and the PFCP Session Establishment Response from the new UL CL/BP:

– the I-SMF shall update the Outer Header Creation IE in the DL FAR of the old UL CL/BP to add a GTP-U header set to the F-TEID assigned by the new UL CL/BP for DL traffic forwarding;

– the I-SMF shall update the UL PDR(s) to receive UL traffic forwarded from the new UL CL/BP, if the old UL CL/BP needs to assign a new N9 DL F-TEID for the new UL CL/BP;

– instruct the old UL CL/BP to report user inactivity on the N9 forwarding tunnel by provisioning the received time in the User Plane Inactivity Timer IE (as specified in clause 5.11.2).

If the old UL CL/BP assigns a new N9 DL F-TEID to receive the UL traffic from the new UL CL/BP, the I-SMF shall send a PFCP Session Modification Request message to the new UL CL/BP to add an Outer Header Creation IE to the UL FAR of the UL CL/BP to add a GTP-U header set to the new N9 UL F-TEID assigned by the old UL CL/BP for UL traffic forwarding, and to add a Network Instance IE if needed.

10. If the User Plane Inactivity Report is received from the old UL CL/BP due to the User Plane Inactivity Timer expires, the I-SMF indicates to the SMF that it is removing the old UL CL/BP and PSA0.

11. The SMF shall send to the I-SMF a PFCP Session Deletion Request (for the old DNAI) and a PFCP Session Deletion Request for the old UL CL/BP.

12-14. The I-SMF shall remove the UL PDR(s) identified by the received Rule ID(s) in the target UL CL/BP and the PFCP sessions in old UL CL/BP/PSA0.

15. The I-SMF returns two PFCP Session Deletion Responses to the SMF.

D.2.8 Simultaneous change of UL CL/BP and PSA controlled by different I-SMFs

The corresponding stage 2 call flow is specified in clause 4.23.9.5 of 3GPP TS 23.502 [29]. Figure D.2.8-1 specifies the details of the signalling between the SMF and the I-SMF, and between the I-SMFs and the UL CL/BPs and PSAs.

Figure D.2.8-1 – Simultaneous change of UL CL/BP and PSA controlled by different I-SMFs

1-2. These steps are the same as described in clause D.2.7.

3. The target I-SMF indicates to the SMF the insertion of UL CL/BP and PSA.

4. The SMF shall send to the target I-SMF a PFCP Session Establishment Request (for the new DNAI) and a PFCP Session Establishment Request for the new UL CL/BP.

In addition, to support the EAS session continuity, the SMF may send additional information to the target I-SMF as defined in step 4 of clause D.2.7.

5-6. The target I-SMF shall behave as described in step 5 and 6 of clause D.2.7. In addition, the target I-SMF shall provision a URR with a User Plane Inactivity Timer IE in the new UL CL/BP, based on the user plane inactivity time received from the SMF, and associate it to the UL PDR(s) used detecting the UL traffic to forward towards the old UL CL/BP and the DL PDR(s) used for detecting the DL traffic from the old UL CL/BP (as specified in clause 5.11.3).

7-8. These steps are the same as described in clause D.2.7.

9. The target I-SMF shall send an Nsmf_PDUSession_UpdateSMContext Request (N9 forwarding tunnel required, target UL CL N9 forwarding tunnel info, value of the timer to detect the end of activity on the N9 forwarding tunnel to support the EAS session continuity) to the source I-SMF, as specified in clause 5.2.2.3.x of 3GPP TS 29.502 [50].

10. The source I-SMF shall send the following information to the old UL CL/BP in the PFCP Session Modification Request based on the information received from the target I-SMF:

– the source I-SMF shall update the Outer Header Creation IE in the DL FAR of the old UL CL/BP to add a GTP-U header set to the F-TEID assigned by the new UL CL/BP for DL traffic forwarding;

– instruct the old UL CL/BP to report user inactivity on the N9 forwarding tunnel by provisioning the received time in the User Plane Inactivity Timer IE (as specified in clause 5.11.2).

11. The source I-SMF shall return information to the target I-SMF, e.g. F-TEID in old UL CL/BP on receiving the UL traffic from the new UL CL/BP, as specified in clause 5.2.2.3.x of 3GPP TS 29.502 [50]. The source I-SMF may return the old N3 UL F-TEID if it can be reused or a new N9 UL F-TEID assigned by the old UL CL/BP for UL traffic forwarding.

12. The target I-SMF shall update the UL FAR of the UL PDR(s) for UL data forwarding (to the old UL CL/BP) in new UL CL/BP with the F-TEID received.

13. Upon being notified about user plane inactivity of the N9 forwarding tunnel by the new UL CL/BP, the target I-SMF shall release the UL PDR(s) for UL data forwarding (to the old UL CL/BP) and the DL PDR(s) for DL data received (from the old UL CL/BP) in the new UL CL/BP.

14. Upon being notified about user plane inactivity of the N9 forwarding tunnel by the old UL CL/BP, the source I-SMF indicates to the SMF that it is removing the old UL CL/BP and PSA0.

15. The SMF shall send to the source I-SMF a PFCP Session Deletion Request (for the old DNAI) and a PFCP Session Deletion Request for the old UL CL/BP.

16-17. The source I-SMF shall remove the PFCP sessions in old UL CL/BP/PSA0.

18. The source I-SMF returns two PFCP Session Deletion Responses to the SMF.

Annex E (Informative):
Procedures Related to MPTCP Functionality