When a BSS fails, all its BSS contexts affected by the failure become invalid and shall be deleted. BSS storage of data is volatile.

When an RNC/BSC fails, all its RNC/BSC contexts affected by the failure become invalid and shall be deleted. RNC/BSC storage of data is volatile. An SGSN that recognises unavailability of an RNC/BSC or receives a Reset from an RNC/BSC, shall locally release the RABs for all affected PDP contexts. Any affected PDP contexts that use Direct Tunnel and have an invalid tunnel in GGSN will be recovered when the SGSN receives an Iu connection establishment request from the MS or when the GGSN informed the SGSN that the GGSN has received a GTP error indication from RNC. When the RNC/BSC receives a GTP-U PDU for which no RAB context exists, the RNC/BSC shall discard the GTP-U PDU and return a GTP error indication to the originating node that may be SGSN or GGSN if Direct Tunnel is established. The RNC should ensure as far as possible that previously used TEID values are not immediately reused after an RNC restart, in order to avoid inconsistent TEID allocation throughout the network.

When an RNC/BSC fails, all its RNC/BSC contexts affected by the failure become invalid and shall be deleted. RNC/BSC storage of data is volatile. An SGSN that recognises unavailability of an RNC/BSC or receives a Reset from an RNC/BSC, shall locally release the RABs for all affected PDP contexts. If ISR is activated or direct tunnel is established, the S4-SGSN shall initiate release of the access bearer for all bearers towards the Serving GW as defined in Iu Release Procedure Using S4 in TS 23.060. For the other cases, the S4-SGSN may send the Release Access Bearers Request message to the Serving GW to remove the downlink user plane address and TEID as specified in TS 23.060. In addition, based on operator policy, the SGSN may initiate the Dedicated Bearer Deactivation procedure for bearers using streaming or conversational traffic class. Any affected EPS bearers contexts in Serving GW are recovered when the SGSN receives an Iu connection establishment request from the MS or when the Serving GW initiates the Network Triggered Service Request procedure as specified in TS 23.060. When the RNC/BSC receives a GTP-U PDU for which no RAB Context exists, the RNC/BSC shall discard the GTP-U PDU and return a GTP Error Indication to the originating node that may be SGSN or Serving GW if Direct Tunnel is established. An S4-SGSN that recognises unavailability of an RNC (e.g. no more SCTP association in service) or receives a Reset message from an RNC shall maintain the related MBMS bearer contexts but shall locally delete the RNC related information (i.e. Iu related resources) for all MBMS service association(s) or those indicated in the Reset message. See clause 8.26 of TS 25.413. Upon receipt of a Reset message from the RNC, the S4-SGSN should then subsequently re-establish the MBMS bearer services affected by the RNC failure by initiating MBMS Session Start procedure(s) towards the RNC. The S4-SGSN shall encode the contents of 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 received from the MBMS GW if the original parameters were updated) with the following exceptions:

• if the S4-SGSN has received recently an MBMS session re-establishment indication from the MBMS GW (i.e. within a past short period covering the time during which the same MBMS session may exist simultaneously in two S4-SGSNs of the S4-SGSN pool), the S4-SGSN shall set the "MBMS session re-establishment indication" flag to signal that this message is used to re-establish an MBMS session. Otherwise, the S4-SGSN shall not set "MBMS session re-establishment indication" flag;
• the S4-SGSN should set the estimated session duration to a value corresponding to the remaining duration of the session.

The RNC should accept an MBMS Session Start Request received for an ongoing MBMS session (i.e. with the same TMGI)

• from the same or a different SGSN than the SGSN that currently controls the MBMS session, if the message contains the "MBMS session re-establishment indication" flag; or
• from the SGSN that currently controls the MBMS session, if the RNC supports the option to maintain MBMS bearer contexts during a pre-configured time period after an Iu path failure and the message is received during that period without the "MBMS session re-establishment indication" flag.

If it accepts the request from the SGSN, and if the message contains the "MBMS session re-establishment indication" flag, the RNC shall:

• replace the Iu related resources for this MBMS service associated to the previous SGSN by those assigned in the MBMS Session Request (if different) and consider that the MBMS session is now being controlled by the new SGSN (if different from the previous SGSN); for IP Unicast over Iu, the RNC receives the user plane data for this MBMS session via the new SGSN (if different from the previous SGSN);
• the RNC shall leave the former M1 transport network IP multicast address and join the new M1 transport network IP multicast address (including the IP address of the multicast source) if the MBMS Session Start Request contains a different transport network IP multicast distribution address and/or a different IP multicast source address; the RNC shall also use the C-TEID received in the MBMS Session Start Request

Upon detection of an Iu path failure (i.e. no more SCTP association in service),

• the RNC shall release all the MBMS services affected by the Iu path failure either immediately or after a pre-configured time period if the corresponding MBMS bearer contexts are not re-established via any S4-SGSN;
• the S4-SGSN shall maintain the related MBMS bearer contexts but shall locally delete the RNC related information (i.e. Iu related resources) for all MBMS service association(s).

Upon recovery of the Iu path, the RNC should initiate a Reset procedure towards the related S4-SGSN. Upon receipt of the Reset message from the RNC, the S4-SGSN should behave as specified for RNC failure in clause 15.3.