Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.007  Word version:  18.5.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…

 

17C  Restoration of data in the TWAN |R11|p. 59

17C.1  Restart of the TWANp. 59

17C.1.1  TWAN Failurep. 59

When a TWAN fails, all its Bearer contexts/PDN connections affected by the failure become invalid and may be deleted. TWAN storage of subscriber data is volatile.
When the TWAN receives a GTP-U PDU over GTPv2 based S2a for which no Bearer context exists, it shall discard the GTP-U PDU and return a GTP error indication to the originating node (i.e. the PGW).
The TWAN should ensure as far as possible that previously used TEID values are not immediately reused after a TWAN restart, in order to avoid inconsistent TEID allocation throughout the network.
When the TWAN receives a user packet with an unknown GRE Key over PMIPv6 based S2a, the TWAN shall discard the packet and optionally respond back with an ICMP message, as specified in Section 8.2 of RFC 2473 and Section 8.3 of RFC 2473 for the node unreachable error case.
Up

17C.1.2  Restoration Proceduresp. 60

After a TWAN restart, the TWAN shall delete all Bearer contexts affected by the restart that it may have stored and place local TWAN restart counter value in all GTPv2 Echo requests/responses messages and PMIPv6 heartbeat responses the TWAN sends to the PGW.

17C.1A  Restart of a peer nodep. 60

17C.1A.1  PGW Failurep. 60

The TWAN will receive the PGW restart counter in GTPv2 Echo requests/ responses and PMIPv6 heartbeat responses that the TWAN receives from the PGW.
When a TWAN detects that a peer PGW has restarted (see clause 18 "GTP-C based restart procedures" and clause 19 "PMIPv6 based restart procedures") it shall delete all PDN connection table data/bearer contexts associated with the peer node that fails, and may free the associated internal TWAN resources.
Up

17C.2  Partial Failure Handling at TWANp. 60

17C.2.1  Generalp. 60

See clause 23.
The partial failure feature is optional for TWAN.
If the TWAN does not support the feature then partial failure handling does not apply to that specific PDN connection.

17C.2.2  Procedures during PDN Connection Establishmentp. 60

If the TWAN supports the feature, the following procedures apply.
During a PDN connection establishment, the TWAN shall provide one TWAN FQ-CSID containing exactly one CSID for that particular PDN connection to the PGW. The TWAN shall store the Node-ID and CSID from the FQ-CSID provided by the PGW for that particular PDN connection in its PDN Connection table.
The TWAN determines that the PGW supports partial failure handling by the presence of the PGW FQ-CSID in the Create Session Response for GTPv2 based S2a and/or Proxy Binding Acknowledgement message for PMIPv6 based S2a.
Up

17C.2.3  Procedures during TWAN Partial Failurep. 60

If the TWAN supports the feature, the following procedures apply.
When a TWAN detects that it has undergone a partial failure, it shall verify that one or more corresponding CSID(s) are present for the component 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 TWAN shall perform the following.
The TWAN may perform implementation-specific operations to clean up any residual state associated with the CSID(s).
The TWAN shall send Delete PDN Connection Set Request containing all the TWAN CSIDs of the component(s) failing in TWAN FQ-CSID over the GTPv2 based S2a interface or PMIPv6 Binding Revocation Indication with G bit set message containing the equivalent TWAN FQ-CSID(s) over the PMIPv6 based S2a interface to PGW peers supporting the feature.
On the GTPv2 based S2a interface, upon receiving a GTPv2 Delete PDN Connection Set Response message with Cause value "Success", the TWAN shall conclude that the PGW 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. Similarly, on the PMIPv6 based S2a interface, upon receiving a successful PMIPv6 Binding Revocation Acknowledgment message with G bit set, the TWAN shall conclude that the PGW has initiated the internal deletion of the PDN connections corresponding to the CSID(s) present in the PMIPv6 Binding Revocation Indication message.
The TWAN is not required to perform any further recovery actions towards PGW peers for PDN connections in the connection set identified by the PGW FQ-CSID(s).
Up

17C.2.4  Procedures during PGW Partial Failurep. 61

If the TWAN supports the feature, the following procedures apply.
When an TWAN receives a GTPv2 Delete PDN Connection Set Request or PMIP6 Binding Revocation Indication with G bit set message from a PGW, the TWAN shall retrieve all the PDN connections corresponding to each of the FQ-CSID(s) present in the message. The TWAN shall delete all the retrieved PDN connections, and may free the associated internal TWAN resources.
As a response, the TWAN shall send a GTPv2 Delete PDN Connection Set Response message with an appropriate Cause value or a PMIPv6 Binding Revocation Acknowledgment message with G bit set to the PGW.
Up

17C.2.5  Procedures during PDN Connection Removal or Modificationp. 61

For the modification of an existing PDN connection established over S2a, if the corresponding TWAN and PGW support the partial failure feature, when the TWAN receives an FQ-CSID value of a PGW over S2a, the TWAN shall overwrite the currently stored FQ CSID value with the received value.
For the removal of an existing PDN connection established over S2a, if the corresponding TWAN and PGW support the partial failure feature, a TWAN removes the corresponding PDN data as well as any relevant stored FQ-CSID value of the PGW FQ-CSID.
Up

17D  Restoration of data in the BM-SC |R12|p. 61

17D.1  Restart of the BM-SCp. 61

When a BM-SC fails, all its MBMS Bearer contexts affected by the failure become invalid and will be deleted.
After a BM-SC restart, all the MBMS Bearer contexts stored in the BM-SC 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 BM-SC. If Group Communication Service (GCS) is supported, the BM-SC also loses the knowledge of the TMGIs it had allocated to the Group Communication Service Application Server(s) (GCS AS) before restarting.
When the MBMS GW detects the restart of a BM-SC, it shall behave as described in clause 17A.2.3.
When the GCS AS detects the restart of a BM-SC, it shall behave as described in clause 17E.1. The restoration of MBMS services by content providers other than GCS AS after a BM-SC failure or restart is out of scope of 3GPP.
Up

17D.2  Restart of the GCS ASp. 61

In deployments without a Diameter Agent between the GCS AS and the BM-SC, the BM-SC shall detect a restart in the GCS AS 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 BM-SC shall detect a restart in the GCS AS using the Diameter Restart-Counter AVP as specified in the MBMS Heartbeat procedure (see clause 29).
When the BM-SC detects a restart of the GCS AS, the BM-SC shall deallocate (locally) all the TMGIs that had been assigned to the restarted GCS AS and the BM-SC shall stop all the related MBMS bearers to free the corresponding resources in E-UTRAN.
Up

17E  Restoration of data in the GCS AS |R12|p. 62

17E.1  Restart of the GCS-ASp. 62

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-SCp. 62

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).
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 TS 29.468.
Up

17F  Restoration of data in the UCMF |R16|p. 62

17F.1  Restart of the UCMFp. 62

The UCMF is assumed as a front-end application function with a persistent database connected. The UCMF may restart but all dictionary mapping information between UE Radio Capability and UE Radio Capability IDs can be retained, hence, in this case, a UCMF shall not update its Recovery Time Stamp if the UCMF has restarted.

17F.2  Restart of the MMEp. 63

When a UCMF detects that a peer MME 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 delete the subscription created by the failed MME.
Up

Up   Top   ToC