Content for TS 23.527 Word version: 19.0.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 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.
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.
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.
