17A Restoration of data in the MBMS GW

23.0073GPPRelease 18Restoration proceduresTS

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

17A.1 Restart of the MBMS GW

When a MBMS GW fails, all its MBMS Bearer contexts affected by the failure become invalid and will be deleted. MBMS GW storage of subscriber data is volatile.

After a MBMS GW restart, all the MBMS Bearer contexts stored in the MBMS GW and affected by the restart become invalid and will be deleted. All the SGmb Diameter sessions affected by the restart are also lost in the MBMS GW.

When the SGSN/MME detects a restart in a MBMS GW (see clause 18 "GTP-C based restart procedures") with which it has MBMS Bearer contexts activated, it shall deactivate all the related MBMS Bearer contexts locally and towards E-UTRAN/UTRAN in which the MBMS bearer service is active. The MME shall initiate a M3AP Reset procedure (see clause 8.5 of 3GPP TS 36.444 [28]), or an MBMS Session Stop procedure per affected MBMS service (see clause 8.3 of 3GPP TS 36.444 [28]), towards the MCE(s) to deactivate the related MBMS services in E-UTRAN. The SGSN shall initiate an MBMS Session Stop procedure per affected MBMS service (see clause 8.38 of 3GPP TS 25.413 [29]), towards the RNC(s) to deactivate the related MBMS services in UTRAN.

If the MBMS GW receives a non-initial message (i.e. MBMS session update or MBMS session stop request) from the BM-SC for which no SGmb Diameter session exists, the MBMW GW shall discard the message and return a Diameter error indication to the originating BM-SC.

In deployments without a Diameter Agent between the BM-SC and the MBMS GW, the BM-SC shall detect a restart in the MBMS GW using either:

– the Diameter Origin-State-Id AVP as specified in the Diameter Base Protocol. To enable fast detection of restart, the Diameter Origin-State-Id AVP shall be included (at least) in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands; or

– the Diameter Restart-Counter AVP as specified in 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 a restart in the MBMS GW using the Diameter Restart-Counter AVP as specified in the MBMS Heartbeat procedure (see clause 29).

NOTE 1: The intermediate Diameter Agent can remove or update the Diameter Origin-State-Id AVP, e.g. if it needs to modify the Origin-Host-ID. Thus the Diameter Origin-State-Id AVP, if received by the BM-SC or MBMS GW, does not reflect the state of the remote MBMS peer but the state of the Diameter Agent.

When the BM-SC detects a restart in a MBMS GW with which it has at least one MBMS Bearer context, the BM-SC shall maintain the related MBMS bearer context(s), assume that all related SGmb Diameter session(s) have been terminated and clean-up internal resources associated with these lost session(s). The BM-SC should then re-establish the active MBMS bearer services affected by the MBMS GW restart by initiating MBMS Session Start procedure(s) towards the restarted MBMS GW (or an alternative MBMS GW). 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 2: If the BM-SC is instructed to modify an MBMS Session during the MBMS GW failure/restart, the contents of the MBMS Session Start Request sent to the MBMS GW after the MBMS GW restart can also differ from the parameters sent to the MBMS GW before its restart 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).

17A.2 Restart of a peer node

17A.2.1 MME failure

The behaviour of an MBMS GW when it detects that a peer MME has restarted is described in clause 14.1.1.

17A.2.2 SGSN failure

The behaviour of an MBMS GW when it detects that a peer SGSN has restarted is described in clause 11.1.

17A.2.3 BM-SC failure

In deployments without a Diameter Agent between the BM-SC and the MBMS GW, the MBMS GW shall detect a restart in the BM-SC using either:

– the Diameter Restart-Counter AVP as specified in 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 a restart in the BM-SC using the Diameter Restart-Counter AVP as specified in the MBMS Heartbeat procedure (see clause 29).

NOTE: The intermediate Diameter Agent can remove or update the Diameter Origin-State-Id AVP, e.g. if it needs to modify the Origin-Host-ID. Thus the Diameter Origin-State-Id AVP, if received by the BM-SC or MBMS GW, does not reflect the state of the remote MBMS peer but the state of the Diameter Agent.

When the MBMS GW detects a restart of the BM-SC with which it has at least one MBMS Bearer context, the MBMS GW shall assume that all related SGmb Diameter session(s) have been terminated and shall deactivate all the related MBMS Bearer contexts locally and towards E-UTRAN/UTRAN in which the MBMS bearer service is active by sending MBMS Session Stop messages to their controlling MME/SGSNs.