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.

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).

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.

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.

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 IPv4v6 feature is supported, the BM-SC IPv4 address and BM-SC IPv6 address may be both provided as the BMSC-Address AVP, otherwise only one BM-SC IP address may be provided as the BMSC-Address AVP. If the V2X Localized User Plane 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. If the IPv4v6 feature is supported, the BM-SC IPv4 address and BM-SC IPv6 address may be both provided as the BMSC-Address AVP, otherwise only one BM-SC IP address may be provided as the BMSC-Address AVP.

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.

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.

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 e.g. due to TMGI expiry or MBMS-GW error, MBMS bearer activation failure due to no established MBMS-GW, MBMS-GW transient error or SGmb path failure. 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, may also include the MBMS-Bearer-Event-Diagnostic-Info AVP to indicate the diagnostics reason of the event. 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 and may take further actions for the affected bearer based on the notified different event and diagnostic information.

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.

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

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.

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.

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.

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.

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.

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.