20 Path management procedures

23.0073GPPRelease 18Restoration proceduresTS

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

20.1 General

This clause specifies path management procedures for GTP-C based, PMIP and PFCP based interfaces.

For GTP based interfaces, Echo Request / Response procedure is used. The usage depends on the GTP-C version in the following way:

– GTPv1-C entity may periodically send an Echo Request message as specified in 3GPP TS 29.060 [8].

– GTPv2 entity shall probe the liveliness of each peer with which it is in contact by sending an Echo Request messages (see TS 29.274 [13]). When and how often a GTPv2 Echo Request message may be sent is implementation specific but an Echo Request shall not be sent more often than every 60 s on each path. This does not prevent resending an Echo Request with the same sequence number according to the T3-RESPONSE timer.

It is recommended that GTPv2 Echo Request should be sent only when a GTP-C entity has not received any GTP response message for a previously sent request message on the GTP-C path for, an implementation dependent period of time.

A GTP-C entity (both GTPv1-C and GTPv2) shall be prepared to receive an Echo Request message at any time and it shall reply with an Echo Response message.

For the PMIP based S5/S8 interface, the SGW and PGW shall detect respectively a peer PGW and SGW as currently unavailable by sending a series of PMIPv6 Heartbeat Request messages, and not receiving within a period of time respectively a PMIPv6 Heartbeat Response message (see 3GPP TS 29.275 [16]).

For PFCP based Sxa/Sxb/Sxc interfaces, the CP function shall detect a peer UP function (or vice versa) as currently unavailable by sending a series of PFCP heartbeat Request messages, and not receiving within a period of time respectively a PFCP Heartbeat Response message (see 3GPP TS 29.244 [43]).

For URCMP based S17 interface, the URCMP entity shall detect a peer URCMP entity as currently unavailable by sending a series of URCMP heartbeat Request messages, and not receiving within a period of time respectively a URCMP Heartbeat Response message (see 3GPP TS 29.674 [44]).

20.2 Signalling path failure detection and handling

20.2.1 General

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

PMIP entities shall support detection of path failure as specified for Failure Detection in IETF RFC 5847 [22].

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

– delete the PDN connections (EPS bearer contexts) or PDP contexts associated with this peer’s IP address; or

– maintain the PDN connections (EPS bearer contexts) or PDP contexts associated with the peer’s IP address 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. The network node may delete the maintained resources if control/user plane signalling is received across other interface(s) during the path failure and before the maximum path failure duration timer expires.

NOTE 1: During transient path failures (e.g. path failures not exceeding few minutes at most), maintaining the EPS bearer contexts or PDP contexts associated with the peer’s IP address enables the delivery of end user services (when the path is reestablished again) and also avoids unnecessary signalling in the network for restoring those connections.

NOTE 2: It is not intended to maintain PDN connections during long path failures (e.g. exceeding few minutes at most) as this would imply undesirable effects like undue charging.

The following clauses specify further specific network element requirements.

20.2.2 SGW functionality

20.2.2.1 S11/S4 path failure

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.

20.2.2.2 S5 path failure

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).

NOTE: The PGW Restart Notification procedure can help the MME to restore the PDN connections earlier since the SGW will detect the S5 path failure and send PGW Restart Notification triggering a PDN connection restoration at the MME, before the PGW sends the PGW Downlink Triggering Notification.

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.

20.2.3 MBMS GW functionality

20.2.3.1 Sm path failure

The MBMS GW may be provisioned with the list (or a sublist) of the MMEs pertaining to the MME pool.

NOTE 1: The MBMS GW expects only one MME of the MME pool in BM-SC requests received across the SGmb interface.

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.

NOTE 2: Each MME of the MME pool provisioned in the MBMS GW supports an M3 interface with the MCE(s).

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).

NOTE 3: This allows to re-establish the MBMS sessions when a MME fails without restart.

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.

NOTE 4: This enables the MCE to receive a MBMS Session Start request from the new MME controlling the MBMS session before the MCE receives a request to stop the MBMS service from the previous controlling MME.

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.

NOTE 5: Per the requirements above, if the MBMS GW had started an MBMS session within an MME with the MBMS Service Area (1, 2, 3) and receives during an Sm path failure (towards this MME) an MBMS Session Update from the BM-SC modifying the MBMS Service Area to (3, 4, 5), the MBMS GW will encode the original MBMS Service Area (1, 2, 3) in the MBMS Session Start Request sent to the alternative MME and subsequently send an MBMS Session Update Request with the MBMS Service Area (3,4,5) to the new MME controlling the MBMS session.

NOTE 6: If the previous MME received an MBMS Session Update Request from the MBMS GW but could not propagate it to the MCE due to a M3AP path failure, the contents of the MBMS Session Start Request sent to the MCE via the new MME can also differ from the parameters sent to the MCE via the previous MME for the parameters that can be modified by the MBMS session update procedure (i.e. MBMS Session Area, MBMS Time to Data Transfer, MBMS Data Transfer Start).

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).

NOTE 7: The MBMS GW cannot know whether the MME will see the Sm path failure as transient or non transient if the Sm path recovers in the period between the maximum path failure timer of the MME plus and minus the period between two Echo Request messages sent by the MME. This can possibly lead the MBMS GW to send an MBMS Session Stop request to the MME for a session that has already been terminated by the MME (if the MME determined the failure is non transient) or to send an MBMS Session Start request (with the "MBMS session re-establishment indication" flag) to the MME for a session that is still alive at the MME (if the MME determined the failure is transient).

20.2.3.2 Sn path failure

The MBMS GW may be provisioned with the list (or a sub list) of the SGSNs belonging to the SGSN pool.

NOTE: The MBMS GW expects only one SGSN of the SGSN pool in BM-SC requests received across the SGmb interface.

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.

20.2.3.3 SGmb path failure

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).

NOTE 1: A transport connection failure does not allow to identify a failure of the remote MBMS peer. Likewise, it is not possible to rely on Diameter Device-Watchdog-Request / Answer messages to test the responsiveness of the remote MBMS node during periods when there is no need for other MBMS signalling as these messages are only exchanged between Diameter peers with a direct transport connection.

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.

NOTE 2: This enables to free corresponding radio resources in E-UTRAN/UTRAN for MBMS services if the BM-SC has failed without restart.

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.

20.2.4 MME functionality

20.2.4.1 Sm path failure

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.

NOTE 1: This enables to free corresponding radio resources in E-UTRAN for MBMS services if the MBMS GW has failed without restart.

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.

NOTE 2: Upon a non-transient SGmb path failure, if the BM-SC moves the control of an MBMS session to an alternative MBMS GW, the same MME can receive an MBMS Session Stop Request from the old MBMS GW after an MBMS Session Start Request from the new MBMS GW.

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.

20.2.4.2 S5 path failure

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;

NOTE 1: This can happen e.g. if the PDN connection has already been restored by the MME upon receipt of a preceding PGW Restart Notification message. In this case, the PDN connection remains hanging in the PGW until the timer monitoring the maximum duration to restore the PDN connection expires in the PGW.

– 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 3GPP TS 23.401 [15].

NOTE 2: This avoids to tear down the S1 connection of the UE and thus to negatively affect other PDN connections of that UE that would not be impacted by the S5 path failure.

20.2.5 SGSN functionality

20.2.5.1 Sn path failure

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.

NOTE 1: This enables to free corresponding radio resources in UTRAN for MBMS services if the MBMS GW has failed without restart.

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:

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.

NOTE 2: Upon a non-transient SGmb path failure, if the BM-SC moves the control of an MBMS session to an alternative MBMS GW, the same S4-SGSN can receive an MBMS Session Stop Request from the old MBMS GW after an MBMS Session Start Request from the new MBMS GW.

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.

20.2.5.2 S5 path failure

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 3GPP TS 23.060 [5].

20.2.6 BM-SC functionality

20.2.6.1 SGmb path failure

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.

NOTE 2: Re-establishing an MBMS session via an alternative MBMS GW can generate network signalling over many interfaces and interrupt transiently the delivery of the MBMS data stream due to the need for related eNB/RNCs to switch to the new IP multicast group over M1. Thus during a transient SGmb path failure it is recommended to defer any MBMS session update or stop procedure for on-going MBMS sessions in the MBMS GW affected by the SGmb path failure. However if the MBMS session update or stop procedure is for time critical services, the BM-SC can immediately 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) as specified below, and subsequently send the MBMS Session Update or Stop message.

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.

NOTE 3: This enables to re-establish the MBMS sessions when a MBMS GW fails without restart.

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.

NOTE 4: This enables the MCE/RNC to receive a MBMS Session Start request from the new MME/SGSN (and MBMS GW) controlling the MBMS session before the MCE/RNC receives a request to stop the MBMS service from the previous controlling MME/SGSN (and MBMS GW).

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.

NOTE 5: If the BM-SC is instructed to modify an MBMS Session during the SGmb path failure, the contents of the MBMS Session Start Request sent to the MBMS GW after the SGmb path failure can also differ from the parameters sent to the MBMS GW before the SGmb path failure for the parameters that can be modified by the MBMS session update procedure (i.e. MBMS Session Area, MBMS Time to Data Transfer, MBMS Data Transfer Start).

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).

NOTE 6: The BM-SC cannot know whether the MBMS GW will see the SGmb path failure as transient or non transient if the SGmb path recovers in the period between the maximum path failure timer of the MBMS GW plus and minus the period between two Diameter Device-Watchdog-Request messages or MBMS Heartbeat Request messages sent by the MBMS GW. This can possibly lead the BM-SC to send an MBMS Session Stop request to the MBMS GW for a session that has already been terminated by the MBMS GW (if the MBMS GW determined the failure is non transient) or to send an MBMS Session Start request (with the "MBMS session re-establishment indication" flag) to the MBMS GW for a session that is still alive at the MBMS GW (if the MBMS GW determined the failure is transient).

20.2.6.2 MB2-C path failure

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).

NOTE 1: A transport connection failure does not allow to identify a failure of the remote MBMS peer. Likewise, it is not possible to rely on Diameter Device-Watchdog-Request / Answer messages to test the responsiveness of the remote MBMS node during periods when there is no need for other MB2 signalling as these messages are only exchanged between Diameter peers with a direct transport connection.

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.

20.2.7 PGW functionality

20.2.7.1 S5 path failure

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;

20.2.8 GCS AS functionality

20.2.8.1 MB2-C path failure

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:

– 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).

NOTE 1: A transport connection failure does not allow to identify a failure of the remote MBMS peer. Likewise, it is not possible to rely on Diameter Device-Watchdog-Request / Answer messages to test the responsiveness of the remote MBMS node during periods when there is no need for other MB2 signalling as these messages are only exchanged between Diameter peers with a direct transport connection.

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 3GPP TS 29.468 [36].

20.2.9 Sx interface functionality

20.2.9.1 Sxa path failure

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.

20.2.9.2 Sxb path failure

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.

20.3 User plane path failure detection and handling

20.3.1 General

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.

NOTE 1: During transient path failures (e.g. path failures not exceeding few minutes at most), maintaining the bearer contexts associated with the peer’s IP address enables the delivery of end user services (when the path is re-established again) and also avoids unnecessary signalling in the network for restoring those bearers.

NOTE 2: It is not intended to maintain bearer contexts during long path failures (e.g. exceeding few minutes at most) as this would imply undesirable effects like undue charging.

20.3.2 MBMS GW functionality

20.3.2.1 SGi-mb path failure

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

NOTE 1: How an MBMS GW detects an SGi-mb path failure is implementation specific. E.g. an MBMS GW can monitor the receipt of downlink user plane from the BM-SC (synchronization sequences are transmitted continuously e.g. in case of MBSFN transmissions, even if there is no MBMS user data to be sent).

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.

NOTE 2: This enables to free corresponding radio resources in E-UTRAN/UTRAN and to attempt to re-establish the MBMS session(s).

20.3.3 BM-SC functionality

20.3.3.1 SGi-mb path failure

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;

– 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

With a split SGW or PGW (see 3GPP TS 23.214 [42]), 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 3GPP TS 29.244 [43]) 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 3GPP TS 29.244 [43]) 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.

NOTE: The SGW-C and PGW-C need to take care to smooth the signalling load towards the SGW-U and PGW-U if a large number of PFCP sessions are affected by the user plane path failure.

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

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.

NOTE: The UP function can learn if the restarted GTP-U entity is a RNC or eNB by using the Destination Interface Type included in the Forwarding Parameters in the FAR (which contains the F-TEID that had been allocated by the restarted GTP-U entity).

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

20.3.5.1 S1-U path failure

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

20.3.6.1 S1-U path failure

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 3GPP TS 23.401 [15].

– 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 3GPP TS 23.401 [15].

– the MME should deactivate the corresponding PDN connections using the "reactivation requested" cause value as specified in clause 5.10.3 of 3GPP TS 23.401 [15] 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).