5.22 PFCP sessions successively controlled by different SMFs of an SMF set (for 5GC)

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

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

5.22.1 General

A PFCP session may be controlled by different SMFs of an SMF Set using either one PFCP association per SMF Set and UPF as described in clause 5.22.2 (called SSET feature), or with each SMF of the SMF set establishing its own PFCP association with the UPF as described in clause 5.22.3 (called MPAS feature).

A UPF complying with this version of the specification and that supports being controlled by an SMF set shall support the procedures specified in clauses 5.22.3 (i.e. MPAS feature) and may support the procedures specified in clause 5.22.2 (i.e. SSET feature).

The requirements specified in this clause for the UPF, SMF and SMF set shall also apply to:

– combined PGW-U/UPF, combined PGW-C/SMF and combined PGW-C/SMF Set respectively;

– MB-SMF and MB-UPF, for MB-SMFs deployed in an MB-SMF set; and

– combined SMF/MB-SMF, combined UPF/MB-UPF for combined SMF/MB-SMFs Set.

An SMF supporting the SSET feature or the MAPS feature shall be ready to take over the control of a PFCP session from another SMF within the same SMF SET, upon receiving a request from a UPF requiring an SMF change, if possible.

5.22.2 With one PFCP association per SMF Set and UPF

When a UPF supports that a PFCP session can be successively controlled by different SMF(s) in the same SMF set, the following applies:

1) One SMF in the SMF set shall establish one single PFCP Association with the UPF for the SMF set; the Node ID in the PFCP Association Setup Request shall be set to an FQDN representing the SMF set.

The SMF shall indicate that it supports the SSET feature in the CP Function Features IE (see clause 8.2.58); this indicates to the UPF that the PFCP sessions established with this PFCP association can be successively controlled by different SMFs of an SMF set according to the procedure defined in this clause.

The SMF may also indicate the IP addresses of alternative SMFs within the SMF Set and the IP addresses of alternative PFCP entities pertaining to the same SMF in the Alternative SMF IP Address IE(s) in the PFCP Association Setup Request and in the subsequent PFCP Association Update Request messages. Those Alternative SMF IP Address IE(s) with the PPE (Preferred PFCP Entity) flag set to "1" are alternative PFCP entities that the UPF shall select preferably when such reselection is required as specified in the following bullet 4.

NOTE 1: Those Alternative SMF IP Address IE(s) with the PPE flag set to "1" are PFCP entities in the preferred binding entity corresponding to the binding level in the Binding Indication of the resource context created for the PDU session when binding procedures are supported in the SMF as specified in clause 6.12 of 3GPP TS 29.500 [74].

2) When establishing a PFCP session, the SEID that the SMF assigns in the CP F-SEID of the PFCP Session Establishment Request may be unique or not within the SMF set. However the assigned CP F-SEID shall be unique within the SMF set.

NOTE 2: The UPF does not (need to) know whether the SEID in the CP F-SEID is uniquely assigned in the SMF set or not.

3) Any SMF in the SMF set may issue requests to modify or delete the PFCP session, or to update or release the PFCP association. The UPF shall allow the related PFCP request to come from any other SMF from the same SMF set.

4) The UPF shall initiate PFCP session related requests (e.g. PFCP Session Report Request) towards another PFCP entity pertaining to the same SMF or another SMF of the SMF Set, if the IP address included in the CP F-SEID assigned to the PFCP session is not responsive, or if the UPF receives a GTP-U Error Indication from the SMF over the N4-u tunnel assigned to the N4 session for data forwarding if any.

The UPF shall firstly use the IP addresses included in those Alternative SMF IP Address IE(s) with the PPE flag set to "1" (if available) whenever possible, then it may use the IP addresses included in the Alternative SMF IP Address IE(s) without the PPE flag set to "1", to contact an alternative PFCP entity. Otherwise the UPF shall use the SMF set FQDN in the CP Node ID to discover alternative SMFs within the SMF Set, e.g. by querying the DNS or by performing a discovery request towards the NRF.

When sending the request to another PFCP entity pertaining to the same SMF or to the new SMF, the UPF shall set the SEID field to zero in the PFCP header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request.

5) When receiving a request from a UPF with the SEID field set to zero and CP F-SEID assigned by previous SMF, the SMF shall take over the control of the PFCP session from the previous SMF, unless it is needed to redirect the request to a different SMF (e.g. due to high load or because the corresponding session context has already been taken over by a different SMF in the same SMF set).

An SMF may redirect a UPF initiated PFCP session related request to another PFCP entity pertaining to the same SMF or to a different SMF in the SMF set by rejecting the request with the cause "Redirection Requested" and with the IP address of the new entity to contact. When sending the redirected request to the new entity, the UPF shall set the SEID field to zero in the header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request.

Alternatively, an SMF may forward the UPF request to another PFCP entity pertaining to the same SMF or to a new SMF in the SMF set; the new PFCP entity or the new SMF answers to the UPF, including the CP F-SEID IE with the IPv4 or IPv6 address of the new entity respectively and the same or a modified SEID, and optionally including the N4-u F-TEID that the UPF shall use for sending data towards the new entity.

NOTE 3: This allows to address cases where a different SMF would have been reselected in the 5GC for the PFCP session, e.g. by an AMF.

6) An SMF may also update, at any time, a PFCP session by including the CP F-SEID with the IPv4 or IPv6 address of a new SMF and/or a new SEID assigned by the new SMF in a PFCP Session Modification Request.

7) The UPF shall not trigger the restoration procedures specified in 3GPP TS 23.527 [40] for a PFCP session that can be controlled by different SMFs of an SMF set when a heartbeat failure is detected for the IP address of the assigned CP F-SEID. Restoration procedures shall be triggered only if heartbeat procedures fail with all the IP addresses of all the SMFs in the SMF set.

NOTE 4: The above requirements enable all SMFs of a same SMF set to successively control a given PFCP session without causing extra signalling over the N4 interface.

8) A UPF supporting the SSET feature shall support UE IP address/prefix allocation in the UP function (see clause 5.21).

5.22.3 With one PFCP association per SMF and UPF

If multiple PFCP associations are setup between an UPF and the SMFs in an SMF set, the following applies:

1) Each SMF in the SMF set shall establish its own PFCP association with the UPF and shall provide the Node ID IE set to an FQDN or IP address of the SMF and the SMF Set ID IE set to an FQDN representing the SMF set. All SMFs of an SMF set shall indicate the same SMF Set ID. Alternatively, if PFCP Association Setup is initiated by UPF as defined in clause 6.2.6.3, each SMF in the SMF set shall provide this information in PFCP Association Setup Response message.

The SMF shall indicate that it supports the MPAS feature (Multiple PFCP Associations to the SMFs in an SMF set) in the CP Function Features IE (see clause 8.2.58); this indicates to the UPF that the PFCP sessions established with this PFCP association can be successively controlled by different SMFs of the same SMF set according to the procedure defined in this clause.

The SMF may also provide a list of alternative IP addresses of PFCP entities pertaining to the same SMF in the Alternative SMF IP Address IE in the PFCP Association Setup Request message and in the subsequent PFCP Association Update Request messages. Those Alternative SMF IP Address IE(s) with the PPE flag set to "1" are alternative PFCP entities that the UPF shall select preferably when such reselection is required as specified in the following bullet 6.

The UPF and SMF shall identify the PFCP association by the Node ID of the SMF and UPF respectively.

Likewise, when an SMF is added or removed from the SMF set, this SMF shall establish or tear down its PFCP association with the UPF. Alternatively, when an SMF updates its SMF SET ID using the PFCP Association Update procedure, the UPF shall maintain the existing PFCP sessions served by this SMF and use the new SMF Set ID of the SMF if the UPF needs to later reselect a different SMF instance for these PFCP sessions (as defined in step 6).

NOTE 1: The UPF does not (need to) know whether the SEID in the CP F-SEID is uniquely assigned in the SMF set or not. The SMF and the UPF identifies the PFCP session by its own CP F-SEID and UP F-SEID respectively.

3) Any SMF in the SMF set may issue requests to modify or delete the PFCP session. When the SMF controlling a PFCP session changes, the SMF that takes over the control of the PFCP session shall provide its own Node ID and may provide a new CP F-SEID.

The UPF shall allow the PFCP session modification or deletion request to come from any other PFCP association from the same SMF set.

4) At any time, an SMF may update a PFCP session by including the CP F-SEID with the IPv4 or IPv6 address of a new SMF and/or a new SEID assigned by the new SMF in a PFCP Session Modification Request.

5) When receiving a request from a UPF with the SEID field set to zero and CP F-SEID assigned by previous SMF, the SMF shall take over the control of the PFCP session from the previous SMF, unless it is needed to redirect the request to a different SMF in the same SMF set (e.g. due to high load or because the corresponding session context has already been taken over by a different SMF in the same SMF set).

An SMF may redirect a UPF initiated PFCP session related request to another PFCP entity pertaining to the same SMF or to a different SMF in the SMF set by rejecting the request with the cause "Redirection Requested" and with the IP address of the new entity to contact. When sending the redirected request to another PFCP entity pertaining to the same SMF or to the new SMF, the UPF shall set the SEID field to zero in the header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request.

Alternatively, an SMF may forward the UPF request to another PFCP entity pertaining to the same SMF or another SMF in the SMF set; the new PFCP entity or the new SMF answers to the UPF, including the CP F-SEID IE with the IPv4 or IPv6 address of the new entity respectively and the same or a modified SEID, and optionally including the N4-u F-TEID that the UPF shall use for sending data towards the new entity.

NOTE 2: This allows to address cases where a different SMF would have been reselected in the 5GC for the PFCP session, e.g. by an AMF.

6) The UPF shall initiate PFCP session related requests (e.g. PFCP Session Report Request) towards another PFCP entity pertaining to the same SMF or to another SMF in the SMF set with which the UPF has established associations with the same SMF Set ID, if the IP address included in the CP F-SEID assigned to the PFCP session is not responsive, heartbeat failure towards IP address of the CP F-SEID assigned to the PFCP session, or if the UPF receives a GTP-U Error Indication from the SMF over the N4-u tunnel assigned to the N4 session for data forwarding.

When sending the request to the new entity, the UPF shall set the SEID field to zero in the PFCP header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request.

7) The UPF shall not trigger the restoration procedures specified in 3GPP TS 23.527 [40] for a PFCP session that can be controlled by different SMFs of an SMF set when a heartbeat failure is detected. Restoration procedures shall be triggered only if heartbeat procedures fail with all of the SMFs in the SMF set (i.e. the SMFs with which the UPF has established associations with the same SMF Set ID).

8) If an SMF or UPF fails, the peer PFCP node that detects that error shall remove the PFCP association locally.

9) A UPF supporting the MPAS feature shall support UE IP address/prefix allocation in the UP function (see clause 5.21).

5.22.4 Restoration of PFCP Sessions associated with an FQ-CSID, Group ID or PGW-C/SMF IP Address

As specified in clause 31.6 of 3GPP TS 23.007 [24] and clause 4.6 of 3GPP TS 23.527[40], for deployments with PGW-C/SMF Set, the CP function (e.g. a PGW-C or a SMF) and the UP function (a PGW-U or a UPF) may support the feature "Restoration of PFCP Sessions associated with one or more PGW-C/SMF FQ-CSID(s), Group Id(s) or PGW-C/SMF IP address(es)". A CP function and a UP function that supports this feature shall behave as specified in clause 5.22.2 or 5.22.3 with the following additional requirements:

1) A UP function that supports this feature shall indicate so to the CP function by setting the RESPS feature bit in the UP Function Feature IE (see clause 8.2.25).

2) The PGW-C/SMF in a PGW-C/SMF Set may allocate a globally unique Group Id to a PFCP session, in the PFCP Session Establishment Request message during the PFCP session establishment procedure and may update the Group Id associated to the PFCP session in a PFCP Session Modification Request message if necessary. The UP function shall store the Group Id associated to a PFCP session. At most one Group ID may be associated to a PFCP session.

3) Alternatively, if partial failure handling is supported, the PGW-C/SMF may assign an FQ-CSID to a PFCP session as specified in clause 31 of 3GPP TS 23.007 [24] and clause 4.6 of 3GPP TS 23.527 [40].

4) The PGW-C/SMF (either the PGW-C/SMF serving the PFCP sessions or another PGW-C/SMF in the same Set taking over the control of the PFCP sessions) may send a PFCP Session Set Modification Request message to the PGW-U/UPF(s), including either one or more PGW-C/SMF FQ-CSID IE(s) allocated earlier, or one or more Group Id IE(s) allocated earlier, or one or more CP (PGW-C/SMF) IP Addresses and an Alternative SMF IP Address IE, to request the PGW-U/UPF(s) to send subsequent PFCP Session Report Request messages to the same or an alternative PGW-C/SMF (as indicated in the Alternative SMF IP Address IE) for the PFCP Sessions which are associated with the PGW-C/SMF FQ-CSID(s) or the Group Id IEs, or which have their F-SEID containing the CP IP Address. The PGW-C/SMF may instruct the UP function to move sessions associated with different PGW-C/SMF FQ-CSID(s), Group Ids or CP IP Addresses, to different PGW-C/SMF addresses.

5) When the PGW-U or UPF sends subsequent PFCP Session Report Request message to the indicated alternative PGW-C/SMF address, the PGW-U or UPF may receive either a new PGW-C/SMF FQ-CSID or a new Group Id for that PFCP session in the PFCP Session Report Response message from the new PGW-C/SMF.

NOTE: The above procedure enables a PGW-C/SMF to move groups of sessions to one or more different PGW-C/SMF instances, e.g. during a partial failure in a PGW-C/SMF or when a PGW-C/SMF is shutting down (e.g. scale-in operation), in one signal PFCP message. This allows the PGW-C/SMF to control how PFCP sessions are re-distributed in the SMF set.