Content for TS 23.007 Word version: 18.4.0

1… 2… 4… 5… 6… 10… 11… 12… 14… 15… 15A… 16… 17… 17A… 17B… 17C… 18… 20… 20.3… 21… 22… 25… 27… 28… 31… 31.3… 31.4… 31.6…

15A.1 eNodeB Failure 15A.2 S1-AP path failure 15A.3 MCE Failure 15A.4 M3AP path failure 15A.5 Other MCE functionality for MBMS restoration 15A.6 Other MME related functionality for MBMS restoration
...

15A Restoration of data in E-UTRAN |R8| p. 41

An MME which does not support UE context retention at SCTP recovery and recognises unavailability of an eNodeB (e.g. no more SCTP association in service) or an MME which receives a Reset or a S1 Setup message with UE Retention Information not set to "ues-retained" from an eNodeB, shall locally delete the eNodeB related information ("eNodeB Address in Use for S1-MME" and "eNodeB UE S1AP ID"). In this case, the MME initiates release of all S1 bearers towards the Serving GW by sending a Release Access Bearer Request message as defined in the S1 Release procedure in TS 23.401. The MME shall initiate the Dedicated Bearer Deactivation procedure to deactivate the GBR bearers in the packet core; as an option, the MME may defer the deactivation of the GBR bearers for a short period (e.g. in the order of seconds) so as to allow the re-establishment of the corresponding radio and S1 bearers and thus avoid the GBR bearers deactivation if the MME receives a NAS Service Request or a GTP-C Downlink Data Notification message as a result of the SGW having received an Error Indication message from the eNodeB (see clause 22).

If the Serving GW receives Release Access Bearers Request message, the Serving GW shall release all eNodeB related information (address and TEIDs) for the UE, but other elements of the UE's Serving GW context shall not be affected. Any Bearer contexts affected by eNodeB failure that have no valid S1-U tunnel in Serving GW are recovered during the UE Triggered Service Request or during the Network Triggered Service Request procedure as specified in TS 23.401.

An MME, which supports UE context retention at SCTP recovery and recognises unavailability of an eNodeB (e.g. no more SCTP association in service), shall keep the UEs in ECM-CONNECTED and suspended UE Context data for UEs in ECM-IDLE, which have used the S1 signalling connection before it was broken. Upon the subsequent S1 Setup procedure, the MME and the eNB may agree that UE-related contexts and related signalling connection that have been existing before the S1 Setup shall not be affected as specified in the clause 19.2.2.8 of TS 36.300.

The eNodeB should ensure as far as possible that previously used TEID values are not immediately reused after an eNodeB restart, in order to avoid inconsistent TEID allocation throughout the network.

15A.1.2 PWS restoration |R12| p. 41

After an (H)eNodeB has restarted, it shall delete all its warning message data. If the warning message service is operational in one or more cell(s) of the (H)eNodeB, the (H)eNodeB shall send a PWS Restart Indication message, which shall include the identity of the (H)eNodeB, the identity of the restarted cell(s), and the TAI(s) and EAI(s) with which the restarted cell(s) are configured, to the CBC to request the CBC to re-load its warning message data if applicable.

The (H)eNB should send the PWS Restart Indication message via two MMEs of the MME pool, if possible, to ensure that the CBC receives the message even if one MME cannot propagate it to the CBC (e.g. due to an SBc path failure).

For HeNBs, the HeNB GW (respectively the MME) shall check the cell identity (respectively the HeNB identity) received in the PWS Restart Indication, as specified in clause 4.6.2 of TS 36.300.

Upon receipt of a PWS Restart Indication message, the CBC shall consider that the warning message service is restarted in the reported cell(s), i.e. the service is operational and no warning messages are being broadcast in the cell(s). The CBC shall then re-send the warning message data (with the same message identifier and serial number) to the (H)eNodeB for these cells, if any. When doing so, the CBC:

shall include the identity of the (H)eNodeB received in the PWS Restart Indication into the Write-Replace-Warning-Request message(s) to enable the MME to forward the message(s) only to the (H)eNodeB (or HeNB GW) involved in the restart;
should set the warning area list to the identities of the cell(s) to be reloaded which are relevant to the warning message data being reloaded; and
may update the number of broadcasts requested, if necessary.

The CBC shall consider a PWS Restart Indication message received shortly after a preceding one for the same cell identity as a duplicate restart indication for that cell which it shall ignore.

Likewise, in other scenarios where the (H)eNodeB may need to reload its warning message data (e.g. when an individual cell is restarted), the (H)eNodeB shall send a PWS Restart Indication message (including the identity of the (H)eNodeB, the identity of the restarted cell(s), and the TAI(s) and EAI(s) with which the restarted cell(s) are configured) to the CBC to request the CBC to re-load its warning message data if applicable. The (H)eNodeB, MME and CBC shall then proceed as specified above for an (H)eNodeB restart.

15A.2 S1-AP path failure |R11| p. 42

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

the eNodeB shall either release the RRC connection of the affected UEs, or if UE context retention at SCTP recovery is supported, the eNodeB shall keep those UEs in RRC_CONNECTED and suspended UE Context data for UEs in ECM-IDLE, which have used the S1 signalling connection before it was broken;
the MME shall proceed as specified for the eNodeB failure in clause 15A.1.

The eNodeB shall continue to broadcast warning messages, if any, during an S1AP path failure. Upon recovery of the S1AP path, the eNodeB shall proceed as if no S1AP path failure had occurred.

During an S1AP path failure, the warning message data stored in the eNodeB may become desynchronized with the CBC, e.g. if the CBC attempts to modify the warning message data during the S1AP path failure. The CBC and MME(s) should support the Write-Replace-Warning-Indication and Stop-Warning-Indication procedures (see TS 23.041) to keep the warning message data synchronized in the eNodeB and the CBC.

15A.3 MCE Failure |R12| p. 42

When an MCE fails, the MCE shall release all the MBMS services affected by the failure locally and towards E-UTRAN within which the MBMS bearer services are active, either immediately or after a pre-configured time period if the corresponding MBMS bearer contexts are not re-established via any MME.

An MME that recognises unavailability of an MCE (e.g. no more SCTP association in service) or receives a Reset or a M3 Setup Request message from an MCE shall maintain the related MBMS bearer contexts but shall locally delete the MCE related information (i.e. M3 related resources) for all MBMS service association(s) or those indicated in the RESET message. See clauses 8.5 and 8.7 of TS 36.444.

Upon receipt of a Reset or M3 Setup Request message from the MCE, the MME should then subsequently re-establish the MBMS bearer services affected by the MCE failure by initiating MBMS Session Start procedure(s) towards the MCE. The MME 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 MME 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 MMEs of the MME pool), the MME shall set the "MBMS session re-establishment indication" flag to signal that this message is used to re-establish an MBMS session. Otherwise, the MME shall not set "MBMS session re-establishment indication" flag;
if no absolute start time ("MBMS data transfer start" parameter) has been received, the MME may change the relative start time ("time to MBMS data transfer" parameter) to fasten the restoration of the MBMS service in E-UTRAN;
the MME should set the estimated session duration to a value corresponding to the remaining duration of the session.

The MCE shall be able to accept MBMS session requests with an absolute start time ("MBMS data transfer start" parameter) in the past.

NOTE 1:

During an Sm path failure when the MBMS GW moves the control of an MBMS session to an alternative MME in the MME pool (see clause 20.2.3.1), the MBMS session can exist in the old and in the new MME for a short period of time. This time period is not bigger than the value of the maximum Sm path failure timer configured at the MME. If an MCE happens to restart during this time, both MMEs will try to re-establish the MBMS session. In this case, it needs to be ensured that the control of the MBMS session remains at the new MME, whatever the order of the MBMS Session Start Request messages the MCE will receive from both MMEs. The setting of the "MBMS session re-establishment indication" flag by the new MME as specified above ensures that the new MME, which has acquired the control of the MBMS session in the recent past, will get the control of the MBMS session.

15A.4 M3AP path failure |R12| p. 43

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

the MCE shall release all the MBMS services affected by the M3AP path failure locally and towards E-UTRAN within which the MBMS bearer services are active, either immediately or after a pre-configured time period if the corresponding MBMS bearer contexts are not re-established via any MME;
the MME shall maintain the related MBMS bearer contexts but shall locally delete the MCE related information (i.e. M3 related resources) for all MBMS service association(s).

Upon recovery of the M3AP path, the MCE should initiate a Reset or M3 Setup Request procedure towards the related MME. Upon receipt of the Reset or M3 Setup Request message from the MCE, the MME should then subsequently re-establish the MBMS bearer services affected by the M3AP path failure by initiating MBMS Session Start procedure(s) towards the MCE. The MME 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 received from the MBMS GW if the original parameters were updated) with the following exceptions:

if the MME 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 MMEs of the MME pool), the MME shall set the "MBMS session re-establishment indication" flag to signal that this message is used to re-establish an MBMS session. Otherwise, the MME shall not set "MBMS session re-establishment indication" flag;
if no absolute start time ("MBMS data transfer start" parameter) has been received, the MME may change the relative start time ("time to MBMS data transfer" parameter) to fasten the restoration of the MBMS service in E-UTRAN;
the MME should set the estimated session duration to a value corresponding to the remaining duration of the session.

The MCE shall be able to accept MBMS session requests with an absolute start time ("MBMS data transfer start" parameter) in the past.

NOTE 1:

During an Sm path failure when the MBMS GW moves the control of an MBMS session to an alternative MME in the MME pool (see clause 20.2.3.1), the MBMS session can exist in the old and in the new MME for a short period of time. This time period is not bigger than the value of the maximum Sm path failure timer configured at the MME. If an M3AP path failure and recovery happens during this time, both MMEs will try to re-establish the MBMS session. In this case, it needs to be ensured that the control of the MBMS session remains at the new MME, whatever the order of the MBMS Session Start Request messages the MCE will receive from both MMEs. The setting of the "MBMS session re-establishment indication" flag by the new MME as specified above ensures that the new MME, which has acquired the control of the MBMS session in the recent past, will get the control of the MBMS session.

15A.5 Other MCE functionality for MBMS restoration |R12| p. 44

The MCE should accept an MBMS Session Start Request received for an on-going MBMS session (i.e. with the same TMGI)

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

If the MCE accepts the request from the MME, and if the message contains the "MBMS session re-establishment indication" flag,

the MCE shall replace the M3 related resources for this MBMS service associated to the previous MME by those assigned in the MBMS Session Start Request (if different) and consider that the MBMS session is now being controlled by the new MME (if different from the previous MME);
the eNodeB(s) involved in the broadcast of the MBMS session 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 eNodeB(s) shall also use the C-TEID received in the MBMS Session Start Request.

The MCE shall be able to accept MBMS session start/update/stop requests with an absolute start time ("MBMS data transfer start" or "MBMS data transfer stop" parameter) in the past.

15A.6 Other MME related functionality for MBMS restoration |R13| p. 44

When establishing MBMS bearer services in an MCE to ensure the distribution of content from ongoing MBMS sessions to an MCE which modifies the lists of the MBMS Service Areas it serves via the MCE Configuration Update procedure (see clause 5.9.2 of TS 23.246), the MME shall encode the MBMS Session Start Request as specified in clause 15A.3 upon receipt of a Reset or M3 Setup Request message from the MCE.