Content for TS 23.007 Word version: 19.0.0

1… 2… 4… 5… 6… 10… 11… 12… 14… 15… 15A… 16… 17… 17A… 17B… 17C… 18… 20… 20.3… 21… 22… 25… 27… 28… 31… 31.3… 31.4… 31.6…

20.3 User plane path failure detection and handling 20.3.1 General 20.3.2 MBMS GW functionality 20.3.2.1 SGi-mb path failure 20.3.3 BM-SC functionality 20.3.3.1 SGi-mb path failure 20.3.4 With Control and User plane Separation of SGW or PGW nodes 20.3.4A Reporting of a Peer GTP-U Entity Restart 20.3.5 SGW functionality 20.3.5.1 S1-U path failure 20.3.6 MME functionality 20.3.6.1 S1-U path failure
...

20.3 User plane path failure detection and handling |R10| p. 77

20.3.1 General p. 77

GTP-U entities shall support detection of path failure by using Echo Request / Echo Response messages in the following way. A path counter shall be reset each time an Echo Response is received on the path and incremented when the T3-RESPONSE timer expires for any Echo Request message sent on the path. The path shall be considered to be down if the counter exceeds N3-REQUESTS.

Upon detecting a path failure, the network node should notify the failure via the Operation and Maintenance system and may either

delete the bearer contexts associated with the path in failure; or
maintain the bearer contexts associated with the path in failure during an operator configurable maximum path failure duration. The network node shall delete the maintained resources if the path is still down when this duration expires.

An MME may also perform relevant restoration procedure(s) if the S1-U path failure notification feature as specified in the following clause(s) is supported.

20.3.2 MBMS GW functionality |R12| p. 77

20.3.2.1 SGi-mb path failure p. 77

An MBMS GW may support the detection of an SGi-mb path failure.

Upon detecting a non-transient SGi-mb path failure (operator configurable maximum path failure duration), based on operator's policy, the MBMS GW may tear down the affected MBMS sessions by sending MBMS Session Stop Request message(s) to the MME/SGSN(s) serving the MBMS sessions and Session Termination Request message(s) to the BM-SC with a terminating cause signalling a user plane failure.

20.3.3 BM-SC functionality |R12| p. 77

20.3.3.1 SGi-mb path failure p. 77

Upon receipt of a Session Termination Request message from an MBMS GW with a terminating cause signalling a user plane failure, the BM-SC may attempt to re-establish the MBMS session via the same MBMS GW (using different user plane resources over SGi-mb) or an alternative MBMS GW.

When re-establishing the MBMS session, the BM-SC shall encode the MBMS Session Start Request with the same contents as in the original MBMS Session Start Request (or per the last MBMS Session Update Request sent by the BM-SC if the original parameters were updated) with the following exceptions:

the BM-SC shall set the "MBMS session re-establishment indication" flag to signal that this message is used to re-establish an MBMS session;
if no absolute start time ("MBMS data transfer start" parameter) has been sent, the BM-SC may change the relative start time ("time to MBMS data transfer" parameter) to fasten the restoration of the MBMS service in E-UTRAN;
the BM-SC should set the estimated session duration to a value corresponding to the remaining duration of the session;
the BM-SC shall provide the new user plane resources assigned to the MBMS session over SGi-mb.

If the MBMS session is not re-established and if it was activated by a Group Communication Service Application Server(s) (GCS AS), the BM-SC shall notify the GCS AS that the MBMS session has been deactivated.

20.3.4 With Control and User plane Separation of SGW or PGW nodes |R14| p. 78

With a split SGW or PGW (see TS 23.214), user plane path failure detection and handling shall be supported as specified in clause 20.3.1 with the following additional requirements:

upon detecting a GTP-U user plane path failure, the SGW-U or PGW-U shall report the user plane path failure to the SGW-C or PGW-C respectively, by sending an PFCP Node Report Request (see TS 29.244) including a User Plane Path Failure Report with the IP address of the remote GTP-U peer(s) towards which a failure has been detected;
upon detecting a failed GTP-U user plane path become recovered, the SGW-U or PGW-U shall report the user plane path recovery to the SGW-C or PGW-C respectively, by sending an PFCP Node Report Request (see TS 29.244) including a User Plane Path Recovery Report with the IP address of the remote GTP-U peer(s) associated with the user plane path recovered;
upon being notified about the user plane path failure, when deciding to delete the bearer contexts associated with the path in failure, the SGW-C or PGW-C shall modify or delete the affected PFCP sessions in the SGW-U or PGW-U.

An SGW-C may support S1-U path failure notification feature as specified in clause 20.3.5.

20.3.4A Reporting of a Peer GTP-U Entity Restart |R17| p. 78

When Control Plane and User Plane Separation (CUPS) is deployed, to reduce massive amount of Sx signalling to report the receiving of GTP-U Error Indication messages and to perform subsequent PFCP Session Modification for PFCP sessions affected by the peer GTP-U restart, a user plane function (SGW-U or PGW-U) and a control plane function (SGW-C or PGW-C) may optionally support reporting of a peer GTP-U entity restart.

A GTP-U entity, e.g. in a SGW-U or a PGW-U, may detect the restart of the peer GTP-U entity as specified in clause 18A.

When the user plane function detects the peer GTP-U entity has restarted via receiving one or more GTP-U Error Indication message(s) or Echo Request/Response message(s) containing a larger Recovery Time Stamp, and when the control plane function supports Reporting of a GTP-U Entity Restart, it shall send a PFCP Node Report Request message to the control plane function to report that:

the peer GTP-U entity identified by Remote GTP-U Peer IE has restarted; and
all PFCP sessions associated with the restarted peer GTP-U entity have been modified by the user plane function, i.e. the F-TEID(s) that had been allocated by the restarted GTP-U entity have been removed from the FARs and the Apply-Action in these FARs changed to BUFF and NOCP, if the restarted GTP-U entity is a RNC or eNB.

The control plane function shall send a PFCP Node Report Response message to acknowledge the receipt of the report of the peer GTP-U entity restart; and the control plane may further behave as if it receives a GTP-U Error Indication Report for those PFCP sessions affected by the peer GTP-U entity restart, e.g. to trigger Downlink Data Notification procedure as part of Network Triggered Service Request procedure if the restarted GTP-U entity is a RNC or eNB. (see also clauses 21.7 and 21.8)

20.3.5 SGW functionality |R15| p. 79

20.3.5.1 S1-U path failure p. 79

An SGW, with or without CUPS support, may optionally support the following S1-U path failure notification feature.

If the feature is supported and deployed in the network, after detecting a S1-U user plane path failure:

If the SGW decides to keep the bearer contexts associated with the failed path (e.g. when the operator configurable maximum path failure duration timer has not expired), the SGW shall notify the MME of the S1-U path failure in subsequent signalling procedures associated with those PDN connections that are affected by the failed S1-U path as follows:
- when the SGW receives a Create Session Request message with eNodeB F-TEID(s), e.g. in an S1/X2 handover with SGW relocation procedure, or a Modify Bearer Request message or a Modify Access Bearer Request message, e.g. in a Service Request procedure:
  - if all default bearer contexts are associated with failed S1-U paths, the SGW shall reject the request messages with the cause code "S1-U Path Failure" at the message level;
  - if the bearer context(s) associated with the failed S1-U path(s) is not the default bearer context, the SGW may partially accept the Create Session Request or the Modify Bearer Request message and shall include the cause code "S1-U Path Failure" at the bearer context level for the bearer context(s) associated with failed S1-U path(s);
  - if at least one of default bearers among multiple PDN connections from the same UE is not associated with the failed S1-U path, the SGW may partially accept the Modify Access Bearer Request message including the cause code "S1-U Path Failure" at the bearer context level for the bearer context associated with failed S1-U path;
- at reception of downlink packets to be sent towards an S1-U bearer associated with a failed S1-U path, the SGW shall send a Downlink Data Notification message with the cause code "S1-U Path Failure".
If the SGW decided to delete the bearer contexts associated with the failed path, the SGW shall include a cause code "S1-U path failure" in the Delete Bearer Request message.

20.3.6 MME functionality |R15| p. 79

20.3.6.1 S1-U path failure p. 79

An MME may optionally support the following S1-U path failure notification feature.

If the feature is supported and deployed in the network, after receiving the cause code "S1-U Path Failure" in a Create Session Response or a Modify Bearer Response or a Modify Access Bearer Response or a Downlink Data Notification or a Delete Bearer Request message:

the MME shall derive the S1-U path information (e.g. the eNB F-TEID and the SGW F-TEID) from the UE Context and mark it as failed, and the MME shall store such information for a configurable period, and before the configured period is expired;
- the MME should avoid selecting the SGW with a failed S1-U path towards the eNB for subsequent PDN connection establishment procedures and mobility procedures with SGW relocation;
- if an alternative SGW without an S1-U path failure is available, the MME shall perform an SGW relocation procedure at a Service Request procedure for the PDN Connection(s) where the default bearer is associated with a failed S1-U path as specified in clause 5.10.4 of TS 23.401.
- if an alternative SGW without an S1-U path failure is available, the MME should perform an SGW relocation procedure for all active PDN connections where the default bearer is associated with the failed S1-u path as specified in clause 5.10.4 of TS 23.401.
the MME should deactivate the corresponding PDN connections using the "reactivation requested" cause value as specified in clause 5.10.3 of TS 23.401 if it receives a Delete Bearer Request with the cause "S1-U Path Failure" for deleting the PDN connection;
the MME shall deactivate the corresponding E-RAB for the bearer context(s) associated with failed S1-U path(s) if it receives a Delete Bearer Request message with the cause "S1-U Path Failure" for deleting dedicated bearer context(s).