Content for TS 23.527 Word version: 19.2.0
4.4 SMF Restoration Procedures
4.4.1 General
4.4.2 Restoration Procedure for SMF Restart
4.4.2.1 General
4.4.2.2 Restart of an SMF in a SMF Set
4.4.3 Restoration Procedure for SMF Failure without Restart
4.4.3.1 General
4.4.3.2 Failure of an SMF in a SMF set
...
...
4.4 SMF Restoration Procedures p. 9
4.4.1 General p. 9
When a SMF fails, all its PDU session contexts and PFCP associations affected by the failure may become invalid and may be deleted.
When the SMF that fails is deployed as part of an SMF set, the PDU session contexts that were served by that SMF are maintained by the SMF set. The MPAS and SSET procedures specified for SMF set in clause 5.22 of TS 29.244 enable the restarted SMF to continue serving its own PFCP sessions, or other SMFs of an SMF set to take over seamlessly the PFCP sessions that were served by the SMF that fails.
If F-TEID allocation is performed in the SMF, the SMF should ensure as far as possible that previously used F-TEID values are not immediately reused after a SMF restart, in order to avoid inconsistent TEID allocation throughout the network.
4.4.2 Restoration Procedure for SMF Restart p. 10
4.4.2.1 General |R18| p. 10
During or immediately after a SMF Restart, the SMF shall place local SMF-C Recovery Time Stamp value in all Heartbeat Request/Response messages.
The UPF will receive the SMF recovery time stamps in PFCP heartbeat requests/responses.
When a UPF detects that a peer PFCP entity in the SMF has restarted (as specified in clause 4.2), the UPF shall delete all session contexts affected by the PFCP entity restart that it may have stored. When the UPF receives a GTP-U PDU not matching any PDRs, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (e.g. other UPF, gNB or N3IWF).
4.4.2.2 Restart of an SMF in a SMF Set |R18| p. 10
During or immediately after the restart of an SMF in an SMF set, using the MPAS or SSET procedure specified for SMF set in clause 5.22 of TS 29.244, the SMF shall not modify the local SMF Recovery Time Stamp value in its Heartbeat Request/Response messages.
Accordingly, the UPF does not detect that the peer PFCP entity in the SMF has restarted and will not delete the session contexts that were served by the restarted PFCP entity in the SMF.
When re-establishing its PFCP association with the UPF, the restarted SMF shall set the PFCP Session Retention Information IE to request the UPF to retain all its existing PFCP sessions if a PFCP association was already established in the UPF for the same Node ID (see clause 6.2.6.2.1 of TS 29.244). Accordingly, the UPF shall retain all PFCP sessions that were established with the existing PFCP association and which have not been moved to other SMFs of the SMF set, if a PFCP association was already established at the UPF for the same Node ID.
4.4.3 Restoration Procedure for SMF Failure without Restart p. 10
4.4.3.1 General |R18| p. 10
When a UPF detects that a peer PFCP entity in the SMF is not reachable for a preconfigured time, and the MPAS or SSET procedure specified for SMF set in clause 5.22 of TS 29.244) are not used, the UPF shall delete all the session contexts affected by the peer PFCP entity failure that it may have stored.
4.4.3.2 Failure of an SMF in a SMF set |R18| p. 10
When the MPAS or SSET procedure specified for SMF set in clause 5.22 of TS 29.244) is used, when the UPF detects that a peer PFCP entity in an SMF is not responsive for a preconfigured time, or upon being instructed by SMF(s) of the SMF set to move PFCP sessions, the UPF shall move the PFCP sessions (other than those PFCP sessions excluded from the restoration) that were served by the failed PFCP entity to another PFCP entity in the same SMF or another SMF, as specified in clause 5.22 of TS 29.244 and clause 4.7.3.
Figure 4.4.3.2-1 depicts an example call flow for a failure (without restart) of an SMF in an SMF set using the MPAS or SSET feature.
Step 0.
When a UPF detects that none of the SMF of the SMF set is responsive for a preconfigured time, the UPF shall delete all the session contexts established by any SMF of the SMF set that it may have stored.
When using the MPAS feature, the SMFs of the SMF set establish PFCP associations with the UPF, including the SMF Set ID IE set to an FQDN representing the SMF Set and optionally Alternative SMF IP Address IE(s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set.
When using the SSET feature, one SMF of the SMF set establishes one PFCP association with the UPF for the SMF set, optionally including Alternative SMF IP Address IE(s) of alternative PFCP entities in the same SMF or different SMFs of the SMF set. In this case, the UPF considers that the SMF1, SMF2 and SMF3 represent different PFCP entities.
The SMFs of the SMF set establish PFCP sessions in the UPF, optionally providing a FQ-CSID and/or a Group ID as described in clause 4.7.2. The SMF may also indicate to the UPF if the PFCP session shall be excluded from the restoration procedure as specified below, i.e. the PFCP session shall be deleted locally, e.g. for a PFCP session established for transporting Radius signaling between the SMF and the Radius server via the UPF.
Step 1.
The SMF1 fails without restart.
Step 2.
The SMFs of the SMF set may request the UPF to move group(s) of PFCP sessions, each identified by a FQ-CSID, Group ID or CP IP Address, to alternative SMF(s) of the SMF set.
Step 3.
Upon being instructed by the SMFs to move PFCP sessions, or upon detecting that the SMF1 is not responsive, the UPF sends subsequent PFCP Session Report Request messages to the alternative SMFs of the SMF set, as specified in clause 5.22 of TS 29.244 and clause 4.7.3. The UPF sets the SEID field to zero in the PFCP header of the PFCP Session Report Request and includes the old CP F-SEID that was assigned by the previous SMF in the request.
The UPF may send a PFCP Session Report Request message proactively to an alternative SMF in the SMF set, i.e. when there is no Downlink Data Report, nor Usage Report, nor Error Indication Report, nor User Plane Inactivity Report, nor TSC Management Information Report, nor Session Report, to be included in the message; in this case, the UPF shall set Report Type to the "UISR" and may indicate the reason for sending the request message, e.g. "move the PFCP session due to the SMF not responding", "move the PFCP session due to the SMF failure", "move the PFCP session instructed by the SMF in a PFCP Session Set Modification Request".
The UPF may send a PFCP Session Report Request message reactively to the alternative SMFs of the SMF set only when there is a report to send, e.g. a Downlink Data Report, a Usage Report, an Error Indication Report, a User Plane Inactivity Report, a TSC Management Information Report, a Session Report. The UPF may also send a PFCP Session Report Request message when it receives payload packets (pertaining to an affected PFCP session) which is intended to be forwarded to the old SMF via N4-u (as instructed via a UL PDR and a UL FAR), e.g. a packet containing a Route Solicitation message for a IPv6 PDU session; in this case, the UPF shall set Report Type to the "UISR" and may indicate the reason for sending the request message (as described above), in addition, the UPF shall indicate to the SMF there are pending payload packets to be sent towards the new SMF via a new N4-u tunnel in the message.
Upon receiving such requests, the SMF takes over the control of the PFCP sessions from the previous SMF and sends PFCP Session Report Response messages including, for each PFCP session, the CP F-SEID IE with the IPv4 or IPv6 address of the new PFCP entity 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.
Alternatively (not depicted in the Figure), the SMF may redirect a PFCP Session Report Request to a different SMF of the same SMF set, either by rejecting the request with the cause "Redirection Requested" and with the IP address of the new entity to contact, or by forwarding the request to another PFCP entity pertaining to the same SMF or another SMF in the SMF set. In the former case, the UPF resends a PFCP Session Report Request to the new PFCP entity to contact. In the latter case, the new PFCP entity sends a PFCP Session Report Response including the CP F-SEID IE with the IPv4 or IPv6 address of the new PFCP entity 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.
