Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 29.468  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   5…   6…

 

5  Procedures over the MB2 Reference Point

5.1  TMGI and Flow ID handling

The combination of TMGI and Flow Identifier shall uniquely identify an MBMS bearer. TMGI and Flow Identifier are defined in TS 23.246.
A TMGI shall be assigned by the BM SC upon request of the GCS AS. The BM SC shall provide an expiration time for each assigned TMGI or group of TMGIs to the GCS AS. The BM SC shall assign a TMGI, which is different from any other TMGI, which the BM SC has previously assigned and for which the timer has not yet expired and there is no active MBMS broadcast bearer. The GCS AS may request the BM SC to refresh the expiration timer for a TMGI. The BM SC and GSC AS shall store the TMGI until the timer expires.
The BM SC shall assign Flow Identifier values, which shall be unique for the corresponding TMGI. For each assigned TMGI, both BM SC and GCS AS shall store all assigned Flow Identifiers until the expiry of the timer of the TMGI, or until GCS AS requests the deallocation of the TMGI.
Up

5.2  TMGI Management

5.2.1  TMGI Allocation Procedure

The TMGI Allocation procedure may be used by the GCS AS to request a set of TMGIs, or to request the renewal of the expiration time for already allocated TMGIs.
To apply this procedure, the GCS AS shall send a GCS Action Request (GAR) command including the TMGI Allocation Request AVP. Within the TMGI Allocation Request AVP, the GCS AS shall indicate the number of requested new TMGIs, excluding any TMGIs for which only an expiration timer renewal is requested, in the TMGI Number AVP, and may include within TMGI AVPs TMGIs that are already allocated to the GCS AS, and for which the GCS AS wishes to obtain a later expiration time. The number of TMGIs requested may be zero, if this procedure is used only to renew the expiration time for already allocated TMGIs.
Upon reception of a GCS Action Request (GAR) command including the TMGI Allocation Request AVP, the BM SC shall determine whether the GCS AS is authorized to receive the requested TMGIs. If no Route Record AVP(s) are present, the BM SC shall derive the identity of the GCS AS from the Origin Host AVP. If Route Record AVP(s) are present, the BM SC shall authorize the request if the identity within the first Route Record AVP matches the GCS AS authorized to use the TMGIs. If the renewal of TMGIs has been requested, the BM-SC shall also determine whether the TMGIs are allocated to the requesting GCS AS and if yes, whether the renewal of TMGI expiration times is possible. The BM SC shall also determine an expiration time, which shall be applicable for all new TMGIs and all TMGIs for which the timer was renewed.
The BM SC shall then send the GCS Action Answer (GAA) command including the TMGI Allocation Response AVP. For a successful TMGI allocation, the TMGI Allocation Response AVP shall include TMGI AVPs and the MBMS Session Duration AVP. The TMGI AVPs shall contain all successfully allocated or refreshed TMGIs and the MBMS Session Duration AVP shall indicate their common new expiration time. For an unsuccessful TMGI allocation request, the TMGI Allocation Response AVP shall include the TMGI Allocation Result AVP. For a partial success (i.e. if some, but not all of the requested TMGIs are allocated or timers refreshed), the TMGI Allocation Response AVP shall include the TMGI AVPs, the MBMS Session Duration AVP and the TMGI Allocation Result AVP. The TMGI AVPs shall contain all successfully allocated or refreshed TMGIs and the MBMS Session Duration AVP shall indicate their common new expiration time. The TMGI Allocation Result AVP shall indicate both success and the reason(s) why the allocation or refresh failed for some TMGIs.
Up

5.2.2  TMGI Deallocation ProcedureWord‑p. 11
The TMGI Deallocation procedure may be used by the GCS AS to immediately release a set of TMGIs, irrespective of their expiration times.
To apply this procedure, the GCS AS shall send a GCS Action Request (GAR) command including the TMGI Deallocation Request AVP. If the GCS AS desires to deallocate some, but not all currently allocated TMGIs, it shall include TMGI AVPs for all TMGIs that are to be deallocated within the TMGI Deallocation Request AVP. If the GCS AS desires to deallocate all currently allocated TMGIs, it shall not include TMGI AVPs within the TMGI Deallocation Request AVP.
Upon reception of a GCS Action Request (GAR) command including the TMGI Deallocation Request AVP, the BM SC shall determine whether the GCS AS is authorized to deallocate the TMGIs. If no Route Record AVP(s) are present, the BM SC shall derive the identity of the GCS AS from the Origin Host AVP. If Route Record AVP(s) are present, the BM SC shall authorize the request if the identity within the first Route Record AVP matches the GCS AS authorized to use the TMGIs.
The BM SC shall then send the GCS Action Answer (GAA) command and shall include a TMGI Deallocation Response AVP for each TMGI contained in the TMGI Deallocation Request AVP. Each TMGI Deallocation Response AVP shall include the affected TMGI in the TMGI AVP. For an unsuccessful TMGI deallocation, the TMGI Deallocation Response AVP shall also include the TMGI Deallocation Result AVP.
When the GCS AS requests the deallocation of a TMGI with some related active MBMS bearers, the BM SC shall terminate those bearer(s).
Up

5.2.3  TMGI Expiry Notification Procedure

At timer expiry for a TMGI, the BM SC shall notify the GCS AS by sending a GCS-Notification-Request (GNR) command including one TMGI Expiry AVP.
If there are active MBMS bearer(s) related to an expiring TMGI, the BM SC shall terminate those bearer(s) and shall notify the GCS AS about the bearer termination by including MBMS Bearer Event Notification AVP(s) in the GNR in accordance with the MBMS Bearer Status Indication Procedure in clause 5.3.5.
Up

5.3  MBMS Bearer Control Procedures

5.3.1  General

The GAR command described in subclause 5.3.2, subclause 5.3.3 and subclause 5.3.4 may contain more than one MBMS Bearer Request AVPs requesting the activation, modification or deactivation of different MBMS bearers.

5.3.2  Activate MBMS Bearer ProcedureWord‑p. 12
The Activate MBMS Bearer procedure may be used by the GCS AS to cause allocation of resources for MBMS bearer(s).
To apply this procedure, the GCS AS shall send a GCS Action Request (GAR) command including one MBMS Bearer Request AVP for each bearer that is to be activated. Within the MBMS Bearer Request AVP, the GCS AS shall include the MBMS StartStop Indication AVP set to "START" and the QoS Information AVP, and the GCS AS may include the TMGI AVP, the MBMS Start Time AVP and the MB2U Security AVP. If the MBMS Cell List feature is supported, the GCS AS shall also include the MBMS-Cell-List AVP, or the MBMS Service Area AVP, or both. If the MBMS Cell List feature is not supported, the GCS AS shall also include the MBMS Service Area AVP. If the GCS AS does not yet know whether the BM SC supports the MBMS Cell List feature and includes the MBMS-Cell-List AVP, it shall also include the MBMS Service Area AVP.
If the V2X Localized User Plane feature is supported, the GCS AS may include the Local-M1-Information AVP and the Local-MB2-U-Information AVP within the MBMS Bearer Request AVP.
If the GCS AS includes both the MBMS-Cell-List AVP and the MBMS Service Area AVP in the MBMS Bearer Request AVP, then the provided service areas shall be a complete set of the service areas that contains all the provided cells.
If the FEC feature is supported, the GCS AS may include the FEC-Request AVP in the MBMS Bearer Request AVP to request that BM-SC applies FEC (see RFC 6363) to the downlink media streams within the MBMS bearer that are described by the FEC-Request AVP.
If the ROHC feature is supported, the GCS AS may include ROHC-Request AVP(s) together with ROHC-Max-CID AVP in the MBMS Bearer Request AVP to request that BM-SC applies ROHC (see RFC 5795 and RFC 3095) to the downlink media streams within the MBMS bearer that are described by the ROHC-Request AVP(s).
Upon reception of a GCS Action Request (GAR) command including the MBMS Bearer Request AVP with the MBMS StartStop Indication AVP set to "START", the BM SC shall determine whether the GCS AS is authorized to use the TMGI. If no Route Record AVP(s) are present, the BM SC shall derive the identity of the GCS AS from the Origin Host AVP. If Route Record AVP(s) are present, the BM SC shall authorize the request if the identity within the first Route Record AVP matches the GCS AS authorized to use the TMGI. If the GCS AS is authorized to use the TMGI, the BM SC shall allocate MBMS resources to support content delivery of the MBMS bearer to the requested MBMS broadcast area (as described via the MBMS-Cell-List AVP and/or MBMS Service Area AVP) using the Session Start procedure defined in TS 23.246. If an MBMS-Cell-List AVP but no MBMS Service Area AVP is included in the MBMS-Bearer-Request AVP, the BM-SC shall derive MBMS service areas from the cells in the MBMS-Cell-List AVP based on operator policy. If both an MBMS-Cell-List AVP and an MBMS-Service-Area AVP are included, the BM-SC shall either derive MBMS service areas from the cells in the MBMS-Cell-List AVP based on operator policy and ignore the information in the MBMS-Service-Area AVP, or directly provide the information received within the MBMS-Service-Area AVP in the Session Start procedure defined in TS 23.246. If no TMGI AVP is included in the MBMS Bearer Request AVP, the BM SC shall allocate a new TMGI. The BM SC shall allocate a new Flow Identifier. The BM SC shall decide whether to use MB2 U Security, and shall take into account related requests of the GCS AS, as received within the MB2U Security AVP in the MBMS Bearer Request AVP.
If the new MBMS service area overlaps with the service area of any active bearer with the same TMGI, the BM SC should reject the activation request with the result code "Overlapping MBMS Service Area".
The BM SC shall then send GCS Action Answer (GAA) command including an MBMS Bearer Response AVP. The BM SC shall include an MBMS Bearer Response AVP for each MBMS Bearer Request AVP that was included in the GAR. The MBMS Bearer Response AVP shall be included in the same position in the GAA that the corresponding MBMS Bearer Request AVP had in the GAR.
For a successful MBMS bearer activation, the MBMS Bearer Response AVP shall include the TMGI AVP, the MBMS-Flow-Identifier AVP, the MBMS Session Duration AVP, the BMSC Address AVP and BMSC Port AVP, and may include Radio Frequency AVP(s) as MBMS bearer related service description. If MB2 U Security is applied, the MBMS Bearer Response AVP shall also include the MB2U Security AVP. If FEC and/or ROHC was requested the MBMS Bearer Response AVP shall also include Userplane-Protocol Result AVP(s) indicating the success or failure of the FEC and/or RHC activation. If the BM-SC is configured to receive a delayed session start response from the MBMS GW as defined in TS 29.061, the BM-SC shall indicate that the bearer activation procedure is still in progress in the MBMS-Bearer-Result AVP.
If the V2X Localized User Plane supported feature is supported, and the Local-M1-Information AVP and Local-MB2-U-Information AVP are received from the GCS AS, and the BM-SC determines to use the local MBMS information, the BM-SC shall include the BMSC-Address AVP and the BMSC-Port with the IP address and port included in the received Local-MB2-U-Information AVP in the MBMS Bearer Response AVP. Otherwise, the BM-SC shall include the BMSC-Address AVP and the BMSC-Port with the IP address and port allocated by the BM-SC in the MBMS Bearer Response AVP.
Up

5.3.3  Deactivate MBMS Bearer ProcedureWord‑p. 13
The Deactivate MBMS Bearer procedure may be used by the GCS AS to cause deallocation of resources for MBMS bearer(s).
To apply this procedure, the GCS AS shall send a GCS Action Request (GAR) command including one MBMS Bearer Request AVP for each bearer that is to be deactivated. Within the MBMS Bearer Request AVP, the GCS AS shall include the MBMS StartStop Indication AVP set to "STOP", the TMGI AVP and the MBMS Flow Identifier AVP to designate the bearer to be deactivated.
Upon reception of a GCS Action Request (GAR) command including the MBMS Bearer Request AVP with MBMS StartStop Indication AVP set to "STOP", the BM SC shall determine whether the GCS AS is authorized to use the TMGI. If no Route Record AVP(s) are present, the BM SC shall derive the identity of the GCS AS from the Origin Host AVP. If Route Record AVP(s) are present, the BM SC shall authorize the request if the identity within the first Route Record AVP matches the GCS AS authorized to use the TMGI. If the GCS AS is authorized to use the TMGI, the BM SC shall stop the broadcast to the MBMS bearer identified by the TMGI AVP and the MBMS Flow Identifier AVP and shall deallocate MBMS resources used for the MBMS bearer using the Session Stop procedure defined in TS 23.246.
The BM SC shall then send GCS Action Answer (GAA) command including an MBMS Bearer Response AVP. The BM-SC shall include an MBMS Bearer Response AVP for each MBMS Bearer Request AVP that was included in the GAR. The MBMS Bearer Response AVP shall be included in the same position in the GAA that the corresponding MBMS Bearer Request AVP had in the GAR. For a successful MBMS bearer deactivation, the MBMS Bearer Response AVP shall include the TMGI AVP and the MBMS-Flow-Identifier AVP.
Up

5.3.4  Modify MBMS Bearer Procedure

The Modify MBMS Bearer procedure may be used by the GCS AS to cause modification of the priority and pre-emption values for an MBMS bearer, the MBMS broadcast area, or both.
To apply this procedure, the GCS AS shall send a GCS Action Request (GAR) command including one MBMS Bearer Request AVP for each bearer that is to be modified. Within the MBMS Bearer Request AVP, the GCS AS shall include The MBMS StartStop Indication AVP set to "UPDATE", the TMGI AVP and the MBMS Flow Identifier AVP to designate the bearer to be modified. The GSC AS may include the MBMS Service Area AVP, the QoS Information AVP and/ or, if the MBMS Cell List feature is supported, the MBMS-Cell-List AVP. However, at least one of the MBMS Service Area AVP, the MBMS-Cell-List AVP and the QoS Information AVP shall be included. The QoS Information AVP shall only be used to modify the Allocation and Retention Priority (ARP), and shall otherwise indicate the same values that were supplied when the activation of the MBMS bearer was requested. If the GCS AS includes both the MBMS-Cell-List AVP and the MBMS Service Area AVP in the MBMS Bearer Request AVP, the provided service areas shall be a complete set of the service areas that contains all the provided cells.
If the FEC feature is supported, the GCS AS may include the FEC-Request AVP in the MBMS Bearer Request AVP to request that BM-SC applies FEC (see RFC 6363) to the downlink media streams within the MBMS bearer that are described by the FEC-Request AVP.
If the ROHC feature is supported, the GCS AS may include ROHC-Request AVP(s) together with ROHC-Max-CID AVP in the MBMS Bearer Request AVP to request that BM-SC applies ROHC (see RFC 5795 and RFC 3095) to the downlink media streams within the MBMS bearer that are described by the ROHC-Request AVP(s).
Upon reception of a GCS Action Request (GAR) command including the MBMS Bearer Request AVP with MBMS StartStop Indication AVP set to "UPDATE", the BM SC shall determine whether the GCS AS is authorized to use the TMGI. If no Route Record AVP(s) are present, the BM SC shall derive the identity of the GCS AS from the Origin Host AVP. If Route Record AVP(s) are present, the BM SC shall authorize the request if the identity within the first Route Record AVP matches the GCS AS authorized to use the TMGI. If the GCS AS is authorized to use the TMGI, the BM SC shall modify the characteristics of the MBMS bearer using the Session Update procedure defined in TS 23.246. If an MBMS-Cell-List AVP but no MBMS Service Area AVP is included in the MBMS Bearer Request AVP, the BM SC shall derive MBMS service areas from the cells in the MBMS-Cell-List AVP based on operator policy. If both an MBMS-Cell-List AVP and an MBMS Service Area AVP are included, the BM-SC shall either derive MBMS service areas from the cells in the MBMS-Cell-List AVP based on operator policy and ignore the information in the MBMS Service Area AVP, or directly provide the information received within the MBMS Service Area AVP in the Session Update procedure defined in TS 23.246.
If the MBMS broadcast area is being modified, the BM SC shall ensure that the new MBMS broadcast area is not overlapping with the MBMS broadcast area of any other existing MBMS bearer(s) with the same TMGI, in accordance with TS 23.246. Otherwise, the BM SC should reject the modification request with the result code Overlapping MBMS Service Area.
The BM SC shall then send the GCS Action Answer (GAA) command including an MBMS Bearer Response AVP. The BM-SC shall include an MBMS Bearer Response AVP for each MBMS Bearer Request AVP that was included in the GAR. The MBMS Bearer Response AVP shall be included in the same position in the GAA that the corresponding MBMS Bearer Request AVP had in the GAR. For a successful MBMS bearer modification, the MBMS Bearer Response AVP shall include the TMGI AVP and the MBMS-Flow-Identifier AVP, and may include Radio Frequency AVP(s). If FEC and/or ROHC was requested the MBMS Bearer Response AVP shall also include Userplane-Protocol Result AVP(s) indicating the success or failure of the FEC and/or RHC activation.
Up

5.3.5  MBMS Bearer Status Indication ProcedureWord‑p. 14
The BM SC may use the MBMS Bearer Status Indication Procedure to notify the GCS AS of conditions affecting the delivery of services that use MBMS Delivery, for instance the termination of an MBMS bearer.
To apply this procedure, the BM SC shall send a GCS-Notification-Request (GNR) command including one MBMS Bearer Event Notification AVP for each bearer with an event to be notified. Within the MBMS Bearer Event Notification AVP, the BM SC shall indicate the bearer event using the MBMS-Bearer-Event AVP and shall include and the TMGI AVP and the MBMS Flow Identifier AVP to designate the affected bearer. If FEC and/or ROHC is applied the MBMS Bearer Event Notification AVP may also include Userplane-Protocol Result AVP(s) indicating the success or failure of the FEC and/or ROHC execution.
Upon reception of a GCS-Notification-Request (GNR), the GSC AS shall reply with a GCS-Notification-Answer (GNA) command.
Up

5.4  BM-SC selection

To discover the BM SC with which to establish the MB2 C session, the GCS AS may use:
  • a pre-configured BM SC identity
  • Diameter routing

5.5  BM-SC overload control

Upon receiving a request from the GCS AS, if the BM SC is in an overload condition, the BM SC may respond to the GCS AS with a GCS-Action-Answer command containing the Result-Code AVP with the value set to DIAMETER_TOO_BUSY, see RFC 6733.
The GCS AS may implement a back off timer. When this timer is running, the GCS AS does not initiate MB2 C requests. Once the timer expires, the GCS AS may re-attempt to use the BM SC. The algorithm the BM SC uses for the back off timer is out of scope of this 3GPP specification.
Up

5.6  Restoration ProceduresWord‑p. 15

5.6.1  General

The restoration procedures enable the BM SC and GCS AS to detect an MB2 C path failure or the restart of the peer node, as specified in TS 23.007.
The BM SC and GCS AS shall detect an MB2 C path failure or the restart of the peer node as specified in TS 23.007, i.e. either making use of mechanisms of the Diameter base protocol, or of the Heartbeat procedures and procedures related to the Restart Counter AVP defined in clause 5.6.2, clause 5.6.3 and clause 5.6.4. The Heartbeat procedure and the procedures related to the Restart Counter AVP are optional to support for both BM SC and GCS AS.
The use of the Heartbeat procedure and the Restart Counter AVP shall be negotiated between the BM SC and GCS AS using the Supported Features AVP upon contacting the peer node for the first time.
Up

5.6.2  Restart Counter

The BM SC shall maintain a local restart counter which shall be incremented monotonically whenever the BM SC restarts with loss of previous states. After the BM SC starts (or restarts with loss of previous states), it shall include the Restart Counter AVP indicating the local value of its restart counter in the first message it sends to any peer GCS AS.
The GCS AS shall store the received restart counter value for each peer BM SC it communicates with. If the new received restart counter value for a peer BM SC is incremented, the BM SC has restarted.
The GCS AS shall also maintain a local restart counter which shall be incremented monotonically whenever the GCS AS restarts with loss of previous states. After the GCS AS starts (or restarts with loss of previous states), it shall include the Restart Counter AVP indicating the local value of its restart counter in the first message it sends to any peer BM SC.
The BM SC shall store the received restart counter value for each peer GCS AS it communicates with. If the new received restart counter value for a peer GCS AS is incremented, the GCS AS has restarted
Up

5.6.3  GCS AS initiated Heartbeat Procedure

To detect an MB2-C path failure or the outage or restart of a peer BM SC, the GCS AS shall send GARs including the Restart Counter AVP indicating the local value of its restart counter periodically to each peer BM SC when no other signalling is exchanged between those two nodes. The GCS AS shall repeat sending the GAR one or more times if no GAA is received. The GCS AS shall consider the MB2-C path to be down if it does not receive a GAA to a configured number of consecutive GARs
If the BM SC receives a GAR including the Restart Counter AVP, it shall reply with a GAA including the Restart Counter AVP indicating the local value of its restart counter.
Up

5.6.4  BM-SC initiated Heartbeat Procedure

To detect an MB2-C path failure or the outage or restart of a peer GCS AS, the BM-SC shall send GNRs including the Restart Counter AVP indicating the local value of its restart counter periodically to each peer GCS AS when no other signalling is exchanged between those two nodes. The BM SC shall repeat sending the GNR one or more times if no GNA is received. The BM-SC shall consider the MB2-C path to be down if it does not receive a GNA to a configured number of consecutive GNRs .
If the GCS AS receives a GNR including the Restart Counter AVP, it shall reply with a GNA including the Restart Counter AVP indicating the local value of its restart counter.
Up

5.6.5  GCS AS procedures after detection of BM-SC Restart

When the GCS AS detects that the the BM SC has restarted, 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; and
  • may restore the MBMS delivery.

5.6.6  BM-SC procedures after detection of GCS AS RestartWord‑p. 16
When the BM SC detects that the GCS AS has restarted, the BM-SC:
  • shall deallocate (locally) all the TMGIs that had been assigned to the GCS AS; and
  • shall stop all the related MBMS bearers.

5.6.7  GCS AS procedures upon detection of MB2-C path failure

Upon detecting a non-transient MB2-C path failure, the GCS AS:
  • shall assume that all the TMGIs that had been assigned by the BM-SC have been de-allocated and that all the related MBMS bearers have been deactivated; and
  • may restore the MBMS delivery.

5.6.8  BM-SC procedures upon detection of MB2-C path failure

Upon detecting a non-transient MB2-C path failure, the BM-SC shall:
  • deallocate (locally) all the TMGIs that had been assigned to the GCS AS; and
  • stop all the related MBMS bearers.


Up   Top   ToC