Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.007  Word version:  19.0.0

Top   Top   Up   Prev   Next
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… 
28 Restoration of data in the CSS  28.1 Restart of the CSS  29 MBMS Heartbeat procedure  30 Restoration of the SCEF  30.1 Restart of the SCEF 
...

 

28  Restoration of data in the CSS |R11|  p. 104

28.1  Restart of the CSS  p. 104

The periodic backup of CSS data to non-volatile storage is mandatory.
When a CSS restarts after failure it shall perform the following actions for the subscriber data records that have been affected by the CSS fault:
  • reload all data from the non-volatile back-up;
  • send a "Reset" message to each VLR where one or more of its MSs may be registered to the CSS. This causes each VLR concerned to mark each relevant roaming user record "Location Information Not Confirmed by CSS", and
  • send a "Reset" message to each SGSN where one or more of its MSs may be registered to the CSS. This causes each SGSN to mark each relevant MM context "Location Information Not Confirmed by CSS".
  • send a "Reset" message to each MME where one or more of its UEs may be registered to the CSS.
Up

29  MBMS Heartbeat procedure |R12|  p. 104

The BM-SC, MBMS GW and GCS AS may support the MBMS Heartbeat procedure over the SGmb or MB2-C reference point to probe the liveliness and detect the restart of a peer MBMS node.
This procedure is optional to support and use for MBMS deployments without an intermediate Diameter Agent between the BM-SC and the MBMS GW or GCS AS. A BM-SC, MBMS GW or GCS AS which support the MBMS restoration procedures as specified in this specification shall support and use the MBMS Heartbeat procedure for MBMS deployments with an intermediate Diameter Agent between the BM-SC and MBMS GW or GCS AS.
The restart of a peer MBMS node is detected using a Restart-Counter AVP. The Restart-Counter AVP contains a value that is incremented monotonically whenever the MBMS node restarts with loss of previous states.
The MBMS Heartbeat Request and Answer messages shall contain the Restart-Counter AVP set to the local restart counter of the sending node. Other MBMS messages sent over the SGmb or MB2-C reference point may also contain the Restart-Counter AVP if contacting the peer node for the first time or if the local restart counter has been incremented.
Upon receipt of a Restart-Counter AVP in a MBMS Heartbeat Request or Answer or in any other SGmb or MB2-C signalling message, the receiving node shall compare the value of the received Restart-Counter AVP with the previous Restart counter value stored for this peer entity and
  • if no previous value was stored, the Restart counter value received in the SGmb or MB2-C signalling message shall be stored for the peer;
  • if the value of the received Restart-Counter AVP is greater than the Restart-Counter previously received from the same MBMS node, the receiver shall consider that the peer MBMS node has restarted.
An intermediate Diameter Agent shall not modify the Restart-Counter AVP when proxying SGmb or MB2-C signalling between the BM-SC and MBMS GW or GCS AS.
The BM-SC, MBMS GW and GCS AS shall support the detection of an SGmb or MB2-C path failure by sending an MBMS Heartbeat Request message periodically when no other signalling is exchanged over those interfaces between those nodes. The MBMS Heartbeat Request message shall be repeated one or more times if no MBMS Heartbeat Answer is received. The SGmb or MB2-C path shall be considered to be down if the peer MBMS node does not respond to a configured number of consecutive MBMS Heartbeart Requests. MBMS Heartbeat Requests shall only be sent on a per node basis (i.e. not on a per MBMS session basis).
See TS 29.061 and TS 29.468 for further details.
Up

30  Restoration of the SCEF |R13|  p. 105

30.1  Restart of the SCEF  p. 105

When an SCEF restarts after failure and has lost all or parts of his data, it shall reply to a report from MME, SGSN or HSS containing a SCEF reference ID for which it has no data with an error cause "SCEF_REFERENCE_ID_UNKNOWN" in the reply indicating that the SCEF reference ID provided in the message does not exist in the SCEF.
If an HSS receives a reply message with error cause set to "SCEF_REFERENCE_ID_UNKNOWN", it shall stop reporting and delete the event localy.
If an MME/SGSN receives reply message with error cause set to "SCEF_REFERENCE_ID_UNKNOWN", it shall stop reporting, initiate a notification to the HSS with cause "SCEF_REFERENCE_ID_UNKNOWN" and delete the event.
An HSS receiving a notification with cause "SCEF_REFERENCE_ID_UNKNOWN", it shall delete the event localy.
Up

30.1.1  Mobile Originated NIDD procedure  p. 105

During the Mobile Originated NIDD procedure, if the MME receives a MO-Data-Answer from the SCEF with a failure cause that UE cannot be found, the MME shall deactivate the corresponding PDN connection towards the UE with the cause "re-activation required", or initiate an explicit detach procedure with reattached required procedure, as appropriate, see TS 24.301.

Up   Top   ToC