After an MME restart, the MME shall delete all MM Bearer contexts affected by the restart that it may have stored. When the MBMS GW detects a restart in an MME (see clause 18 "GTP-C based restart procedures") with which it has at least one MBMS Bearer context, the MBMS-GW should re-establish the active MBMS bearer services affected by the MME restart by initiating MBMS Session Start procedure(s) towards the restarted MME (or an alternative MME in the same MME pool). The MBMS GW shall encode the MBMS Session Start Request with the same contents as in the original MBMS Session Start Request (or as per the last MBMS Session Update Request received from the BM-SC 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.

The MCE shall be able to accept MBMS session requests with an absolute start time ("MBMS data transfer start" parameter) in the past. The MBMS GW shall not delete the MBMS Bearer context unless all SGSNs/MMEs serving the MBMS bearer service and connected to the MBMS GW have restarted and the MBMS-GW does not support re-establishing MBMS bearer services after an MME restart. If the MCE receives an M3 Reset message from the MME (i.e. in case the restart event has resulted in loss of some or all M3 transactions reference information) with which it has at least one MBMS Bearer context, the MCE shall deactivate all the related MBMS Bearer contexts locally and towards E-UTRAN within which the MBMS bearer service is 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 and an SGW supporting the optional network triggered service restoration procedure shall behave as specified in clause 25. When the MME which does not support the optional network triggered service restoration procedure as specified in clause 25 receives a Downlink Data Notification message for which no MM context exists, the MME returns a Downlink Data Notification Acknowledge message to the Serving GW with an appropriate cause. The Serving GW shall delete the related Bearer context related to MME; and if there is no ISR associated S4-SGSN recorded on the related Bearer context the Serving GW shall also notify the PDN GW to delete the Bearer context.

For attach, where the UE is unknown in the MME (i.e. the MME has no MM context for the UE) the MME shall create an MM context for the UE and shall set the indicators "Location Information Confirmed in HSS", "Subscriber Data Confirmed by HSS", "Location Information Confirmed by CSS" and "Subscriber Data Confirmed by CSS" to "Not Confirmed". If authentication is required, the MME shall retrieve the authentication data. The MME then performs an "Update Location" to the HSS. If this is successful, the MME shall set the indicators "Location Information Confirmed in HSS" and "Subscriber Data Confirmed by HSS" to "Confirmed". If the VPLMN supports Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN, the MME may perform an "Update VCSG Location" to the CSS if the requested cell is a CSG/hybrid cell. If this is successful, the MME shall set the indicators "Location Information Confirmed by CSS" and "Subscriber Data Confirmed by CSS" if the CSS has the valid CSG subscription data to "Confirmed". For tracking area update, where the UE is unknown in the MME (i.e. the MME has no MM context for the UE) or for inter-MME tracking area update, where the UE is unkown in the old MME, the MME shall reject the TA update with an appropriate cause. In order to remain attached, the UE shall then perform a new attach and should (re-)activate its EPS Bearer contexts. If the MME has an MM context for the UE, and the indicator "Location Information Confirmed in HSS" or "Subscriber Data Confirmed by HSS" is set to "Not Confirmed" the MME shall perform an "Update Location" to the HSS. If this is successful, the MME shall set the indicators "Location Information Confirmed in HSS" and "Subscriber Data Confirmed by HSS" to "Confirmed". If the indicators "Location Information Confirmed by CSS" or "Subscriber Data Confirmed by CSS" is set to "Not Confirmed", and the VPLMN supports Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN, the MME may perform an "Update VCSG Location" to the CSS if the requested cell is a CSG/hybrid cell. If this is successful, the MME shall set the indicators "Location Information Confirmed by CSS" and "Subscriber Data Confirmed by CSS" if the CSS has the valid CSG subscription data to "Confirmed". If the MME has an MM context for the UE with the indicator "Subscriber Data Confirmed by HSS" marked "Confirmed" the originated transmission shall be handled in the normal way. The MME retrieves subscriber data from the HSS by sending an "Update Location" request, which triggers an "Update Location" answer which contains the subscriber data. The MME retrieves CSG subscriber data from the CSS by sending an "Update VCSG Location" request, which triggers an "Update VCSG Location" answer which may contain the valid CSG subscription data.

An MME and a VLR supporting mobile terminated CS service delivery via an alternative MME in MME pool shall behave as specified in clause 26. When the MME receives a request for CS paging from an MSC/VLR for an IMSI unknown by the MME, if the "MME-Reset" indicator is set to "true", the MME sends the paging request with the location information provided by the VLR. If no such location information is provided, the MME should page for the UE in all the tracking areas corresponding to that MME. The MME may support and apply this procedure to a UE using extended idle mode DRX for MT-SMS service. If the "MME-Reset" indicator is set to "false" and the IMSI is unknown or the UE is marked as EMM-DEREGISTERED by the MME, the paging request is rejected. If the "MME-Reset" indicator is set to "false" and the IMSI is known and the UE is marked as EMM-REGISTERED by the MME, the paging request shall be sent to the UE.

An MME and an SGW supporting the optional network triggered service restoration procedure shall behave as specified in clause 25.

For service request, where the UE is unknown in the MME (i.e. the MME has no MM context for the UE), the MME shall reject the service request with an appropriate cause. In order to remain attached, the UE shall then perform a new attach and should (re-)activate its EPS Bearer contexts. If the MME has an MM context for the UE, and the indicators "Location Information Confirmed by CSS" or "Subscriber Data Confirmed by CSS" is set to "Not Confirmed", and the VPLMN supports Autonomous CSG Roaming and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN, the MME may perform an "Update VCSG Location" to the CSS if the requested cell is a CSG/hybrid cell. If this is successful, the MME shall set the indicators "Location Information Confirmed by CSS" and "Subscriber Data Confirmed by CSS" if the CSS has the valid CSG subscription data to "Confirmed". The MME retrieves CSG subscriber data from the CSS by sending an "Update VCSG Location" request, which triggers an "Update VCSG Location" answer which may contain the valid CSG subscription data.

During the Mobile Terminated NIDD procedure, if the SCEF receives a MT-Data-Answer from the MME/SGSN with a failure cause that UE cannot be found, the SCEF shall delete all the bearer contexts of this UE and may notify the Operation and Maintenance network element.

When an MME detects that a peer SGW has failed with or without restart (relying on restart counter as specified in clause 18 "GTP-C based restart procedures" or implementation e.g. preconfigured path failure timer) it shall either:

• as a default delete all PDN connection table data/MM bearer contexts associated with the peer node that has failed as well as freeing any internal MME resources associated with those PDN connections. The MME may optionally perform other implementation specific actions such as to clear external resources (e.g. S1-MME messages to clear eNodeB resources) or more advanced forms of restoration;

or

• follow the procedures specified in clause 27 to restore the PDN connections affected by the SGW failure, if the MME and the PGW support these procedures.

The behaviour of an MME when it detects that a peer MBMS GW hast restarted is described in clause 17A.1.

When the MME detects a restart in an MCE (i.e. when the MME receives an M3 Reset or M3 Setup Request message from the MCE) with which it has at least one MBMS Bearer context, the MME shall behave as specified in clause 15A.3.

When an MME detects that a peer UCMF has failed with or without restart (relying on restart counter as specified in clause 19B "URCMP based restart procedures" or implementation e.g. a preconfigured path failure timer as specified in clause 20 "Path management procedures"), it shall consider the dictionary mapping information received from the failed UCMF is deprecated, the subscription to get notifications from the UCMF become invalid; the MME may retrieve such mapping information upon subsequent UE - AMF signalling e.g. at registration procedure.

See Clause 23.

If the MME supports the feature, the following procedures apply. During a PDN connection establishment, the MME shall provide one MME FQ-CSID containing exactly one CSID for that particular PDN connection to the SGW in the S11 Create Session Request. The MME shall store the Node-ID and CSID values from the FQ-CSID provided by the SGW and the PGW in the S11 Create Session Response in its PDN Connection table maintained as part of MME MM and EPS Bearer Contexts as specified in Table 5.7.2-1 in TS 23.401. The MME should ensure as far as possible that previously used FQ-CSIDs are not immediately reused after a partial/full failure of an MME. The MME determines that the SGW supports partial failure handling by the presence of the SGW FQ-CSID in the S11 Create Session Response.

If the MME supports the feature the following procedures apply. When an MME detects that it has undergone a partial failure, it shall verify that one or more corresponding CSID(s) are present for the component(s) undergoing a partial fault. If there is no such CSID, then the following does not apply. When one or more CSIDs are currently assigned, the MME shall perform the following. The MME may perform implementation-specific operations to clean up any residual state associated with the CSID(s). The MME shall send a GTPv2 Delete PDN Connection Set Request containing all the MME CSID(s) of the component(s) failing in MME FQ-CSID(s) to the SGW peers that support the feature. Upon receiving a GTPv2 Delete PDN Connection Set Response message with Cause value "Success", the MME shall conclude that the SGW peer has initiated the internal deletion of the PDN connections corresponding to the FQ-CSID(s) present in the GTPv2 Delete PDN Connection Set Request message. Regardless of the "Cause" value in the response, the MME is not required to perform any further recovery actions towards SGW and PGW peers for PDN connections in the connection set identified by the MME FQ-CSID(s).

If the MME supports the feature, the following procedures apply. When an MME receives a GTPv2 Delete PDN Connection Set Request message from an SGW, the MME shall retrieve all the PDN connections corresponding to each of the FQ-CSID(s) present in the message. The MME shall delete all the retrieved PDN connections and the associated resources. Other implementation-specific actions may be performed. As a response, the MME shall send a GTPv2 Delete PDN Connection Set Response message with appropriate Cause value immediately to the SGW.

If an MME and an SGW support the feature, the following procedures apply. During an S11 procedure, impacting an existing PDN connection removal or modification the following apply:

1. If the SGW is being relocated then the MME shall clear the currently stored SGW FQ-CSID .
2. If an MME relocation occurs (for example, TAU with MME change), or if an SGW relocation occurs, (for example, TAU with SGW change), the MME shall include its MME FQ-CSID in the S11 Create Session Request for SGW change and the S11 Modify Bearer Request for MME change without SGW change.
3. Additionally, if MME decides to change own FQ-CSID, the MME shall include MME FQ-CSID in other S11 messages.
4. If the MME receives a FQ-CSID value of an SGW over S11, the MME shall overwrite the current stored SGW FQ-CSID value with the received value.
5. If the MME receives a FQ-CSID value of a PGW over S11, the MME shall overwrite the current stored PGW FQ-CSID value with the received value.
6. During a S11 procedure removing an existing PDN connection the MME removes the PDN data as well as any stored FQ-CSID values(s) of the PGW FQ-CSID and SGW FQ-CSID. The same actions are done on the old MME if there is an MME relocation.

The MME determines that the SGW supports partial failure handling by the presence of the SGW FQ-CSID in the S11 Create Session Response with SGW change; and S11 Modify Bearer Response without SGW change.