It is optional for the SGW to maintain the S5/S8 bearer contexts when the SGW detects a path failure to the MME/S4-SGSN (see clause 20.2.1). However upon detecting a path failure to the MME/S4-SGSN, an SGW that supports the network triggered service restoration procedure (see clause 25) should maintain the S5/S8 bearer contexts eligible for network initiated service restoration and proceed with the network triggered service restoration procedure with the following modification:

• if the path to the MME/S4-SGSN is down for a duration exceeding the maximum path failure duration and if there is no alternative reachable path, e.g. another MME/S4-SGSN in the same pool or another control plane IP address belonging to the same MME/S4-SGSN, the SGW should locally delete the maintained PDN connections associated with the failed path.

In addition, for UEs in connected state associated with the failed path, the SGW should continue sending downlink packets to the eNodeB/RNC as long as the impacted PDN connections are maintained, regardless of whether the SGW supports the network triggered service restoration procedure or not.

The SGW may support the PGW triggered SGW restoration for an S5 path failure. If so, then the SGW should support the PGW Restart Notification procedure. After detecting a path failure to the PGW, the SGW may delete all the PDN connections affected by the path failure and should also send a PGW Restart Notification message to the MME or S4-SGSN if the the PGW Restart Notification procedure is supported by the SGW and MME/S4-SGSN (see clause 16.1A.2). The SGW should proceed with the PGW triggered SGW restoration procedure (see clause 27.2.3.3) with the following modification:

• The SGW shall include the PGW F-TEID or PGW IP address and GRE key for control plane in the PGW Downlink Triggering Notification message that it sends to the MME/S4-SGSN, if this information is present in the PGW Downlink Triggering Notification/PMIP Update Notification message received from the PGW.

The MBMS GW may be provisioned with the list (or a sublist) of the MMEs pertaining to the MME pool. Upon detecting an Sm path failure, the MBMS GW should maintain the MBMS bearer contexts associated with the peer's MME IP address. During a transient Sm path failure (e.g. before the maximum path failure duration timer expires), the MBMS GW may process MBMS requests from the BM-SC and intended for the MME for which the Sm path has failed as follows:

• for new MBMS Session Start Request, the MBMS GW may select an alternative MME in the same MME pool and send the MBMS Session Start Request to this alternative MME;
• for MBMS Session Update Request or MBMS Session Stop Request, the MBMS GW may select an alternative MME in the same MME pool, send a MBMS Session Start Request message to this alternative MME and, if successful, send subsequently the MBMS Session Update Request or MBMS Session Stop Request to this alternative MME.

After having selected an alternative MME, the MBMS GW shall consider the MME answering to the MBMS Start Request as the controlling MME for the MBMS session and send any subsequent MBMS Session Update or MBMS Session Stop for this MBMS Session to this MME. When detecting a non-transient Sm path failure at the MBMS GW (e.g. the maximum path failure duration timer of the MBMS GW expires), the MBMS GW may move the control of all the affected active MBMS sessions to another MME in the same MME pool (if any other MME is reachable by the MBMS GW) by initiating new MBMS Session Start Request(s) to alternative MME(s). The maximum path failure duration timer of the MBMS GW should be configured with a shorter value than the maximum path failure duration timer of the MME to avoid interrupting active MBMS sessions upon a non-transient Sm path failure. The MBMS GW timer should be shorter than the MME timer by at least the period between two Echo Request messages sent by the MME, to avoid that the MME timer expires before the MBMS GW timer if the MME starts its timer before the MBMS GW. When sending an MBMS Session Start Request sent to an alternative MME, the MBMS GW shall encode the contents of the request with the same contents as in the original MBMS Session Start Request (or per the last MBMS Session Update Request sent by the MBMS GW if the original parameters were updated) with the following exceptions:

• the MBMS GW 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 received, the MBMS GW may change the relative start time ("time to MBMS data transfer" parameter) to fasten the restoration of the MBMS service in E-UTRAN;
• the MBMS GW should set the estimated session duration to a value corresponding to the remaining duration of the session.

After detecting an Sm path failure, the MBMS GW shall determine whether the failure is transient or non transient from the perpective of the MME (e.g. the MBMS GW is provisioned with the maximum path failure timer of the MME). The MBMS GW shall assume that the failure is non transient from the perspective of the MME if the Sm path recovers after a period longer than the maximum path failure timer of the MME plus the period between two Echo Request messages sent by the MME, to ensure that the MME also determines this is a non transient path failure if the MBMS GW starts its timer before the MME. The MBMS GW shall consider that the MBMS session has been released by the MME if the Sm path failure is non transient for the MME. If the Sm path failure remains transient for the MME, the MBMS GW shall behave as follows upon detecting the Sm path recovery:

• if the MBMS GW has already moved the control of the MBMS session to an alternative MME(s), the MBMS GW shall send an MBMS Session Stop Request message to the MME previously controlling the MBMS session with a "Local MBMS bearer context release" indication to instruct that MME to release its MBMS bearer context locally, without sending any message to the MCE(s).
• if the MBMS GW has not yet moved the control of the MBMS session to an alternative MME (e.g. if the MBMS restoration procedures are not supported in the network),
  • if the Sm path failure is transient from the perspective of the MBMS GW, the MBMS GW shall consider that MBMS session is still controlled by the related MME and proceed as if there had been no Sm path failure;
  • if the Sm path failure is non transient from the perspective of the MBMS GW, the MBMS GW shall send an MBMS Session Start Request to the MME for the session and encode it as specified above (for a message sent to an alternative MME).

The MBMS GW may be provisioned with the list (or a sub list) of the SGSNs belonging to the SGSN pool. An MBMS GW and SGSN shall handle Sn path failure similar to the Sm path failure as described in clause 20.2.3.1 For IP Unicast over Sn/Iu when the SGSN changes the MBMS GW has to move the user plane which is affected by the Sn-path failure additionally.

In deployments without a Diameter Agent between the BM-SC and the MBMS GW, the MBMS GW shall detect an SGmb path failure using either:

• mechanisms as specified in the Diameter Base Protocol (e.g. transport connection failure, BM-SC peer not responding, Diameter Device-Watchdog-Request and Device-Watchdog-Answer messages during periods when there is no need for other MBMS signalling); or
• the MBMS Heartbeat procedure (see clause 29), if this procedure is supported.
  In deployments with a Diameter Agent between the BM-SC and the MBMS GW, the MBMS GW shall detect an SGmb path failure using the MBMS Heartbeat procedure (see clause 29).

Upon detecting an SGmb path failure, the MBMS GW should maintain the MBMS bearer contexts associated with the peer's BM-SC during an operator configurable maximum path failure duration. If the SGmb path to the BM-SC is down for a duration exceeding the maximum path failure duration, the MBMS GW should deactivate all the related MBMS Bearer contexts locally and send MBMS Session Stop Requests towards all MME/SGSNs in which the MBMS bearer services are active. The MBMS GW shall pass on the "MBMS session re-establishment indication" flag in the MBMS Session Start Request it sends to MME/SGSNs if received from the BM-SC. The MBMS GW shall pass on the "Local MBMS bearer context release" indication in the MBMS Session Stop Request it sends to MME/SGSNs if received from the BM-SC. The MBMS GW shall accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from the same BM-SC that currently controls the MBMS session if the message includes the "MBMS session re-establishment indication" flag. The MBMS GW shall replace the SGmb related resources for this MBMS service by those received in the MBMS Session Start Request (if different). The MBMS GW should not send MBMS Session Start Request message(s) towards the involved MME/SGSN(s) if no parameters other than the estimated duration and relative start time have changed.

Upon detecting an Sm path failure, the MME should maintain the MBMS bearer contexts associated with the peer's MBMS GW IP address during an operator configurable maximum path failure duration. The MME should behave as specified for the case of an MBMS GW restart (see clause 17A.1) if the Sm path to the MBMS GW is down for a duration exceeding the maximum path failure. The MME shall pass on the "MBMS session re-establishment indication" flag in the MBMS Session Start Request it sends to MCEs if received from the MBMS GW. The MME should accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from a different MBMS GW than the MBMS GW that currently controls the MBMS session if the message includes the "MBMS session re-establishment indication" flag. If it accepts the request from the new MBMS GW, the MME shall replace the Sm related resources (i.e. TEID-C) for this MBMS service associated to the previous MBMS GW by those associated to the new MBMS GW and consider that the MBMS session is now being controlled by the new MBMS GW. The MME shall then send an MBMS Session Start Request message including the "MBMS session re-establishment" flag (and the new M1 transport parameters) towards all involved MCE(s). The MME may accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from a different MBMS GW than the MBMS GW that currently controls the MBMS session even if the message does not include the "MBMS session re-establishment indication" flag. If it accepts the request from the new MBMS GW, the MME shall replace the Sm related resources (i.e. TEID-C) for this MBMS service associated to the previous MBMS GW by those associated to the new MBMS GW and consider that the MBMS session is now being controlled by the new MBMS GW; the MME shall then either:

• stop the on-going MBMS bearer service and then start the new MBMS bearer service (without including the "MBMS session re-establishment indication" flag in the MBMS Session Start Request sent to the MCE(s)); or
• behave as if it had received an MBMS Session Start Request including the "MBMS session re-establishment indication" flag (i.e. include the "MBMS session re-establishment indication" flag in the MBMS Session Start Request sent to the MCE(s)).

The MME shall accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from the same MBMS GW that currently controls the MBMS session if the message includes the "MBMS session re-establishment indication" flag. The MME shall replace the Sm related resources (i.e. TEID-C) for this MBMS service by those received in the MBMS Session Start Request (if different). The MME should not send MBMS Session Start Request message(s) towards the involved MCE(s) if no parameters other than the estimated duration and relative start time have changed. The MME shall reject an MBMS Session Stop Request received for an on-going MBMS bearer service from a different MBMS GW than the MBMS GW that currently controls the MBMS session. The MME shall release the MBMS bearer context resources locally without sending any message to the MCE(s) if it receives a MBMS Session Stop Request with a "Local MBMS bearer context release" indication for an on-going MBMS bearer service from the MBMS GW currently controlling the MBMS session.

The MME may support invoking the PGW triggered SGW restoration (see clause 27.2.3) upon receiving a PGW Downlink Triggering Notification message when the S11 path for the related UE is still available (see clause 20.2.1). If so, upon receiving a PGW Downlink Triggering Notification while the S11 path for the related UE is still available, the MME should proceed with the PGW triggered SGW restoration procedure (see clauses 27.2.3.2 and 27.3.2.2) with the following modifications:

• if the PGW F-TEID or PGW IP address and GRE key for control plane received in the PGW Downlink Triggering Notification message does not match the stored PGW F-TEID or PGW IP address and GRE key for control plane of any PDN connection(s) for that UE, the MME shall not proceed with the PGW triggered SGW restoration procedure but just respond to the SGW with a PGW Downlink Triggering Acknowledge message with an acceptance cause code;
• if the PGW F-TEID or PGW IP address and GRE key for control plane received in the PGW Downlink Triggering Notification message matches the stored PGW F-TEID or PGW IP address and GRE key for control plane of any PDN connection(s) for that UE, the MME shall proceed with the PGW triggered SGW restoration procedure.
• if the related UE is in connected mode, the MME may restore the PDN connection(s) of that UE by performing the MME triggered Serving GW relocation procedure as defined in clause 5.10.4 of TS 23.401.

Upon detecting an Sn path failure, the S4-SGSN should maintain the MBMS bearer contexts associated with the peer's MBMS GW IP address during an operator configurable maximum path failure duration. The S4-SGSN should behave as specified for the case of an MBMS GW restart (see clause 17A.1) if the Sn path to the MBMS GW is down for a duration exceeding the maximum path failure. The S4-SGSN shall pass on the "MBMS session re-establishment indication" flag in the MBMS Session Start Request it sends to RNCs if received from the MBMS GW. The S4-SGSN should accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from a different MBMS GW than the MBMS GW that currently controls the MBMS session if the message includes the "MBMS session re-establishment indication" flag. If it accepts the request from the new MBMS GW, the S4-SGSN shall replace the Sn related resources (i.e. TEID-C) for this MBMS service associated to the previous MBMS GW by those associated to the new MBMS GW and consider that the MBMS session is now being controlled by the new MBMS GW. The S4-SGSN shall then send an MBMS Session Start Request message including the "MBMS session re-establishment" flag (and the new M1 transport parameters) towards all involved RNC(s). The S4-SGSN may accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from a different MBMS GW than the MBMS GW that currently controls the MBMS session even if the message does not include the "MBMS session re-establishment indication" flag. If it accepts the request from the new MBMS GW, the S4-SGSN shall replace the Sn related resources (i.e. TEID-C) for this MBMS service associated to the previous MBMS GW by those associated to the new MBMS GW and consider that the MBMS session is now being controlled by the new MBMS GW; the S4-SGSN shall then either:

• stop the on-going MBMS bearer service and then start the new MBMS bearer service (without including the "MBMS session re-establishment indication" flag in the MBMS Session Start Request sent to the RNC(s)); or
• behave as if it had received an MBMS Session Start Request including the "MBMS session re-establishment indication" flag (i.e. include the "MBMS session re-establishment indication" flag in the MBMS Session Start Request sent to the RNC(s)).

The S4-SGSN shall accept an MBMS Session Start Request received for an on-going MBMS bearer service (i.e. with the same TMGI and, if provided, MBMS Flow Identifier) from the same MBMS GW that currently controls the MBMS session if the message includes the "MBMS session re-establishment indication" flag. The S4-SGSN shall replace the Sn related resources (i.e. TEID-C) for this MBMS service by those received in the MBMS Session Start Request (if different). The S4-SGSN should not send MBMS Session Start Request message(s) towards the involved RNC(s) if no parameters other than the estimated duration and relative start time have changed. The S4-SGSN shall reject an MBMS Session Stop Request received for an on-going MBMS bearer service from a different MBMS GW than the MBMS GW that currently controls the MBMS session. The S4-SGSN shall release the MBMS bearer context resources locally without sending any message to the RNC(s) if it receives a MBMS Session Stop Request with a "Local MBMS bearer context release" indication for an on-going MBMS bearer service from the MBMS GW currently controlling the MBMS session.

The S4-SGSN may support invoking the PGW triggered SGW restoration (see clause 27.2.3) upon receiving a PGW Downlink Triggering Notification and the S4 path of the related UE is still available (see clause 20.2.1). If so, S4-SGSN shall proceed as defined for the MME in clause 20.2.4.2, with the following modification:

• if the related UE is in connected mode, the S4-SGSN may restore the PDN connection(s) of that UE by performing the S4-SGSN triggered Serving GW relocation procedure as defined in clause 9.2.2.4 of TS 23.060.

In deployments without a Diameter Agent between the BM-SC and the MBMS GW, the BM-SC shall detect an SGmb path failure using either:

• mechanisms as specified in the Diameter Base Protocol (e.g. transport connection failure, MBMS GW peer not responding, Diameter Device-Watchdog-Request and Device-Watchdog-Answer messages during periods when there is no need for other MBMS signalling); or
• the MBMS Heartbeat procedure (see clause 29), if this procedure is supported.

In deployments with a Diameter Agent between the BM-SC and the MBMS GW, the BM-SC shall detect an SGmb path failure using the MBMS Heartbeat procedure (see clause 29). Upon detecting an SGmb path failure, the BM-SC should maintain the related MBMS bearer contexts. During a transient SGmb path failure (e.g. before the maximum path failure duration timer expires), the BM-SC should consider all related MBMS bearer contexts as active in the MBMS GW. The BM-SC may initiate new MBMS sessions via an alternative MBMS GW (if available). The BM-SC should defer any MBMS session update or stop procedure for on-going MBMS sessions in the MBMS GW affected by the SGmb path failure until the transient path failure ends. When detecting a non-transient SGmb path failure (e.g. the maximum path failure duration timer of the BM-SC expires), the BM-SC should re-establish the active MBMS bearer services affected by the SGmb path failure by initiating MBMS Session Start procedure(s) towards an alternative MBMS GW (if available) or towards the same MBMS GW (once the SGmb path is recovered). 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. The maximum path failure duration of the BM-SC should be configured with a shorter value than the maximum path failure duration timer of the MBMS GW to minimize the interruption of the active MBMS sessions upon a non-transient SGmb path failure. The BM-SC timer should be shorter than the MBMS GW timer by at least the period between two Diameter Device-Watchdog-Request messages or MBMS Heartbeat Request messages sent by the MBMS GW, to avoid that the MBMS GW timer expires before the BM-SC timer if the MBMS GW starts its timer before the BM-SC. When re-establishing the active MBMS bearer services affected by the SGmb path failure, 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.

After detecting an SGmb path failure, the BM-SC shall determine whether the failure is transient or non transient from the perpective of the MBMS GW (e.g. the BM-SC is provisioned with the maximum path failure timer of the MBMS GW). The BM-SC shall assume that the failure is non transient from the perspective of the MBMS GW if the SGmb path recovers after a period longer than the maximum path failure timer of the MBMS GW plus the period between two Diameter Device-Watchdog-Request messages or MBMS Heartbeat Request messages sent by the MBMS GW, to ensure that the MBMS GW also determines this is a non transient path failure if the BM-SC starts its timer before the MBMS GW. The BM-SC shall consider that the MBMS session has been released by the MBMS GW if the SGmb path failure is non transient for the MBMS GW. If the SGmb path failure remains transient for the MBMS GW, the BM-SC shall behave as follows upon detecting the SGmb path recovery:

• if the BM-SC has already moved the control of the MBMS session to an alternative MBMS GW, the BM-SC shall send an MBMS Session Stop Request message to the MBMS GW previously controlling the MBMS session with a "Local MBMS bearer context release" indication to instruct that MBMS GW to release the MBMS bearer context locally in the MBMS GW and in the associated MME/SGSN(s) without sending any message to the MCE/RNC(s).
• if the BM-SC has not yet moved the control of the MBMS session to an alternative MBMS GW (e.g. if the MBMS restoration procedures are not supported in the network),
  • if the SGmb path failure is transient from the perspective of the BM-SC, the BM-SC shall consider that the MBMS session is still controlled by the related MBMS GW and proceed as if there had been no SGmb path failure;
  • if the SGmb path failure is non transient from the perspective of the BM-SC, the BM-SC shall send an MBMS Session Start Request to the MBMS GW for the session and encode it as specified above (for a message sent to an alternative MBMS GW).

In deployments without a Diameter Agent between the BM-SC and the GCS AS, the BM-SC shall detect an MB2-C path failure using either:

• mechanisms as specified in the Diameter Base Protocol (e.g. transport connection failure, GCS AS peer not responding, Diameter Device-Watchdog-Request and Device-Watchdog-Answer messages during periods when there is no need for other MB2 signalling); or
• the MBMS Heartbeat procedure (see clause 29), if this procedure is supported.

In deployments with a Diameter Agent between the BM-SC and the GCS AS, the BM-SC shall detect an MB2-C path failure using the MBMS Heartbeat procedure (see clause 29). Upon detecting a non-transient MB2-C path failure, the BM-SC shall deallocate (locally) all the TMGIs that had been assigned to the GCS AS and the BM-SC shall stop all the related MBMS bearers to free the corresponding resources in E-UTRAN.

The PGW may support invoking the PGW triggered SGW restoration procedure (see clause 27.2.3) when detecting a path failure to an SGW (see clause 20.2.1). If so, after detecting a path failure to an SGW, the PGW should maintain the S5 bearer contexts eligible for restoration and proceed with the PGW triggered SGW restoration procedure with the following modifications:

• for GTP-based S5, the PGW shall include the PGW F-TEID for control plane in the PGW Downlink Triggering Notification message;
• for PMIP-based S5, the PGW shall include the PGW IP address and uplink GRE key for control plane in the PMIP Update Notification message;

In deployments without a Diameter Agent between the BM-SC and the GCS AS, the GCS AS shall detect an MB2-C path failure using either:

• mechanisms as specified in the Diameter Base Protocol (e.g. transport connection failure, BM-SC peer not responding, Diameter Device-Watchdog-Request and Device-Watchdog-Answer messages during periods when there is no need for other MB2 signalling); or
• the MBMS Heartbeat procedure (see clause 29), if this procedure is supported.

In deployments with a Diameter Agent between the BM-SC and the GCS AS, the GCS AS shall detect an MB2-C path failure using the MBMS Heartbeat procedure (see clause 29). Upon detecting a non-transient MB2-C path failure, the GCS AS shall assume that all the TMGIs that had been assigned by the BM-SC have been de-allocated and that all the related MBMS bearers have been deactivated. The GCS AS may restore the MBMS delivery e.g. via a different BM-SC using the MB2-C procedures specified in TS 29.468.

If the path to the SGW-U is down, the SGW-C should handle this as SGW-U Failure without Restart, see clause 16.1A.4. If the path to the SGW-C is down, the SGW-U should handle this as SGW-C Failure without Restart, see clause 16.1A.3.

If the path to the PGW-U is down, the PGW-C should handle this as PGW-U Failure without Restart, see clause 17.1A.4. If the path to the PGW-C is down, the PGW-U should handle this as PGW-C Failure without Restart, see clause 17.1A.3.