17E Restoration of data in the GCS AS

23.0073GPPRelease 18Restoration proceduresTS

17E.1 Restart of the GCS-AS

After a GCS AS restart, the GCS AS loses its MBMS bearer contexts and the knowledge of the TMGIs it had been allocated by the BM-SC(s) before restarting.

When the BM-SC detects the restart of a GCS AS, it shall behave as described in clause 17D.2.

17E.2 Restart of the BM-SC

In deployments without a Diameter Agent between the GCS AS and the BM-SC, the GCS AS shall detect a restart in the BM-SC 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 GCS AS and the BM-SC, the GCS AS 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 GCS AS, does not reflect the state of the remote MBMS peer but the state of the Diameter Agent.

When the GCS AS detects a restart of the BM-SC, the GCS AS shall assume that all the TMGIs that had been assigned by the restarted BM-SC have been de-allocated and that all the related MBMS bearers have been deactivated.

The GCS AS may restore the MBMS delivery using the MB2-C procedures specified in 3GPP TS 29.468 [35].