ETSI TS 129 468 V15.8.0 (2020-01)

TECHNICAL SPECIFICATION
Universal Mobile Telecommunications System (UMTS);
LTE;
Group Communication System Enablers for LTE (GCSE_LTE);
MB2 reference point;
Stage 3
(3GPP TS 29.468 version 15.8.0 Release 15)

3GPP TS 29.468 version 15.8.0 Release 15 1 ETSI TS 129 468 V15.8.0 (2020-01)

Reference
RTS/TSGC-0329468vf80
Keywords
LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 2 ETSI TS 129 468 V15.8.0 (2020-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 3 ETSI TS 129 468 V15.8.0 (2020-01)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 7
2 References . 7
3 Definitions, symbols and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Architectural Overview . 9
4.1 Reference Model . 9
4.2 Functional Elements . 9
4.2.1 Group Communication Service Application Server (GCS AS) . 9
4.2.2 Broadcast-Multicast Service Centre (BM-SC). 10
5 Procedures over the MB2 Reference Point . 10
5.1 TMGI and Flow ID handling . 10
5.2 TMGI Management . 11
5.2.1 TMGI Allocation Procedure . 11
5.2.2 TMGI Deallocation Procedure . 11
5.2.3 TMGI Expiry Notification Procedure . 12
5.3 MBMS Bearer Control Procedures . 12
5.3.1 General . 12
5.3.2 Activate MBMS Bearer Procedure . 12
5.3.3 Deactivate MBMS Bearer Procedure . 13
5.3.4 Modify MBMS Bearer Procedure . 13
5.3.5 MBMS Bearer Status Indication Procedure . 14
5.4 BM-SC selection . 15
5.5 BM-SC overload control . 15
5.6 Restoration Procedures . 15
5.6.1 General . 15
5.6.2 Restart Counter . 15
5.6.3 GCS AS initiated Heartbeat Procedure . 15
5.6.4 BM-SC initiated Heartbeat Procedure . 16
5.6.5 GCS AS procedures after detection of BM-SC Restart . 16
5.6.6 BM-SC procedures after detection of GCS AS Restart . 16
5.6.7 GCS AS procedures upon detection of MB2-C path failure . 16
5.6.8 BM-SC procedures upon detection of MB2-C path failure . 16
6 MB2-C Protocol . 16
6.1 Protocol support . 16
6.1.1 Use of Diameter base protocol . 16
6.1.2 Transport protocol . 17
6.1.3 Advertising Application Support . 17
6.2 Initialization and maintenance of connection and session . 17
6.3 Security on the MB2-C interface . 17
6.4 MB2-C specific AVPs . 17
6.4.1 General . 17
6.4.2 BMSC-Address AVP . 18
6.4.3 BMSC-Port AVP . 19
6.4.4 MBMS-Bearer-Event AVP . 19
6.4.5 MBMS-Bearer-Event-Notification AVP . 19
6.4.6 MBMS-Bearer-Request AVP . 19
6.4.7 MBMS-Bearer-Response AVP . 20
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 4 ETSI TS 129 468 V15.8.0 (2020-01)
6.4.8 MBMS-Bearer-Result AVP . 20
6.4.9 MBMS-Start-Time AVP . 21
6.4.10 Radio-Frequency AVP . 21
6.4.11 TMGI-Allocation-Request AVP . 21
6.4.12 TMGI-Allocation-Response AVP . 22
6.4.13 TMGI-Allocation-Result AVP. 22
6.4.14 TMGI-Deallocation-Request AVP . 22
6.4.15 TMGI-Deallocation-Response AVP . 22
6.4.16 TMGI-Deallocation-Result AVP . 23
6.4.17 TMGI-Expiry AVP . 23
6.4.18 TMGI-Number AVP . 23
6.4.19 MB2U-Security AVP . 23
6.4.20 Local-M1-Information AVP . 24
6.4.21 Local-MB2-U-Information AVP . 24
6.4.22 MBMS-eNB-IP-Multicast-Address AVP . 24
6.4.23 MBMS-eNB-IPv6-Multicast-Address AVP . 24
6.4.24 MBMS-GW-SSM-IP-Address AVP . 24
6.4.25 MBMS-GW-SSM-IPv6-Address AVP . 24
6.4.26 Common-Tunnel-Endpoint-Identifier AVP . 24
6.4.27 FEC-Request AVP . 24
6.4.28 ROHC-Request AVP . 25
6.4.29 ROHC-Full-Header-Periodicity AVP . 25
6.4.30 ROHC-Profile AVP . 25
6.4.31 Userplane-Protocol-Result AVP . 25
6.4.32 ROHC-Result AVP . 25
6.4.33 FEC-Result AVP . 26
6.4.34 ROHC-Max-CID AVP . 26
6.5 MB2-C re-used AVPs . 26
6.5.1 General . 26
6.5.2 Supported-Feature-List AVP . 28
6.5.2.1 Use of the Supported-Features AVP . 28
6.5.2.2 Supported-Feature-List AVP for the MB2-C application . 28
6.6 MB2-C Messages . 29
6.6.1 Command-Code Values . 29
6.6.2 GCS-Action-Request (GAR) command. 29
6.6.3 GCS-Action-Answer (GAA) command . 29
6.6.4 GCS-Notification-Request (GNR) command . 30
6.6.5 GCS-Notification-Answer (GNA) command . 30
7 MB2-U Protocol . 31
7.1 Protocol Stack . 31
7.2 Procedures . 32
Annex A (informative): Call Flows . 34
A.1 TMGI Management . . 34
A.1.1 TMGI Allocation Procedure . 34
A.1.2 TMGI Deallocation Procedure . 34
A.1.3 TMGI Expiry Notification . 35
A.2 MBMS Bearer Control Procedures . 36
A.2.1 Activate MBMS Bearer Procedure . 36
A.2.2 Deactivate MBMS Bearer Procedure . 36
A.2.3 Modify MBMS Bearer Procedure . 37
A.2.4 MBMS Bearer Status Indication Procedure . 38
A.3 Restoration Procedures . 39
A.3.1 GCS AS initiated Heartbeat Procedure . 39
A.3.2 BM-SC initiated Heartbeat Procedure . 39
Annex B (normative): Diameter message priority mechanism . 40
B.1 General . 40
B.2 MB2-C interface . 40
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 5 ETSI TS 129 468 V15.8.0 (2020-01)
B.2.1 General . 40
B.2.2 GCS AS behaviour . 40
B.2.3 BM-SC behaviour . 40
C.1 General . 41
C.2 GCS AS behaviour . 41
C.3 BM-SC behaviour. 41
Annex D (informative): Change history . 42
History . 43

ETSI
3GPP TS 29.468 version 15.8.0 Release 15 6 ETSI TS 129 468 V15.8.0 (2020-01)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
Y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.

ETSI
3GPP TS 29.468 version 15.8.0 Release 15 7 ETSI TS 129 468 V15.8.0 (2020-01)
1 Scope
This document defines the protocol for the MB2 reference point between the Group Communication Service
Application Server (GCS AS) and the Broadcast-Multicast Service Centre (BM-SC).
The MB2 reference point and related stage 2 procedures are defined in TS 23.468 [4] as part of the Group
Communication System Enablers for LTE. The stage 1 requirements for Group Communication System Enablers are
specified in TS 22.468 [2].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 22.468: "Group Communication System(GCSE)".
[3] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional
description".
[4] 3GPP TS 23.468: "Group Communication System Enablers for LTE (GCSE_LTE); stage 2".
[5] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
[6] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[7] 3GPP TS 29.212: "Policy and Charging Control (PCC); Reference points".
[8] 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".
[9] 3GPP TS 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)".
[10] 3GPP TS 33.246: "Security of Multimedia Broadcast/Multicast Service (MBMS)".
[11] IETF RFC 791: "Transmission Control Protocol".
[12] IETF RFC 768: "User Datagram Protocol".
[13] IETF RFC 2234: "Augmented BNF for syntax specifications".
[14] Void
[15] IETF RFC 4960: "Stream Control Transmission Protocol".
[16] IETF RFC 5719: "Updated IANA Considerations for Diameter Command Code Allocations".
[17] IETF RFC 5996: "The Internet Key Exchange (IKE)".
[18] IETF RFC 3947: "Negotiation of NAT-Traversal in the IKE".
[19] IETF RFC 3948: "UDP Encapsulation of IPsec ESP Packets".
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 8 ETSI TS 129 468 V15.8.0 (2020-01)
[20] IETF RFC 4303: "IP Encapsulating Security Payload (ESP)".
[21] IETF RFC 6347: "Datagram Transport Layer Security Version 1.2".#
[22] 3GPP TS 23.007: "Restoration procedures".
[23] 3GPP TS 29.229: "Cx and Dx interfaces based on the Diameter protocol".
[24] 3GPP TS 36.300: "E-UTRA and E-UTRAN overall description; Stage 2".
[25] IETF RFC 7944: "Diameter Routing Message Priority".
[26] IETF RFC 8583: "Diameter Load Information Conveyance".
[27] IETF RFC 6733: "Diameter Base Protocol".
[28] 3GPP TS 23.285: "Architecture Enhancements for V2X services".
[29] IETF RFC 5795: "The Robust Header Compression (ROHC) Framework".
[30] IETF RFC 3095, "Robust Header Compression (ROHC): Framework and four profiles: RTP,
UDP, ESP, and uncompressed"
[31] IETF RFC 6363: "Forward Error Correction (FEC) Framework,".
[32] Void.
[33] 3GPP TS 29.214: " Policy and Charging Control over Rx reference point".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply:
MBMS bearer: The service provided by the EPS to deliver the same IP datagrams to multiple receivers in a designated
location.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
ARP Allocation and Retention Priority
AVP Attribute-Value Pair
BM-SC Broadcast-Multicast Service Centre
DRMP Diameter Routing Message Priority
DSCP Differentiated Services Code Point
DTLS Datagram Transport Layer Security
ESP Encapsulating Security Payload
FEC Forward Error Correction
GAA GCS-Action-Answer
GAR GCS-Action-Request
GCS Group Communication Service
GCSE Group Communication System Enablers
GCS AS Group Communication Service Application Server
GNA GCS-Notification-Answer
GNR GCS-Notification-Request
MBMS-GW MBMS Gateway
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 9 ETSI TS 129 468 V15.8.0 (2020-01)
PCRF Policy and Charging Rules Function
P-GW PDN Gateway
ROHC Robust Header Compression
TMGI Temporary Mobile Group Identity
UDP User Datagram Protocol
V2X Vehicle-to-Everything
4 Architectural Overview
4.1 Reference Model
Figure 4.1-1 shows a high level reference model of the architectural elements relevant to understand the MB2 reference
point. More complete reference models for GCSE are contained in TS 23.468 [4].
Application
PLMN
domain
Rx
PCRF
Gx
GCS AS
SGi
P-GW
MB2-U
MB2-C
SGi-mb
UE MBMS-GW BM-SC
SGmb
Scope of this
GC1
specification
Figure 4.1-1: Reference Model
NOTE: The GC1 reference point between the UE and the GCS AS is unspecified in the present release. Data
related to the GC1 reference point are transported via the Sgi reference point between GCS AS and
P-GW.
For the V2X Localized User Plane supported feature, the reference model in Annex B.3 of 3GPP TS 23.285 [28]
applies.
4.2 Functional Elements
4.2.1 Group Communication Service Application Server (GCS AS)
The GCS AS is defined in TS 23.468 [4] and supports the following functionality:
- Exchanging GC1 signalling with the UE.
- Receiving unicast uplink data from the UE via the SGi reference point.
- Delivery of data to all the UEs belonging to a group using unicast delivery over the SGi reference point and/or
MBMS delivery over the MB2 reference point.
- Support for service continuity procedures for a UE to switch between unicast delivery and MBMS delivery.
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 10 ETSI TS 129 468 V15.8.0 (2020-01)
- For MBMS delivery:
- MB2-C procedures defined in TS 23.468 [4], for requesting the BM-SC to activate, deactivate, modify an
MBMS bearer, allocate/deallocate TMGI.
- Forwarding of data to be delivered via an MBMS bearer to the BM-SC via the MB2-U reference point.
In addition to the functions defined in 3GPP TS 23.468 [4], an GCS AS which acts as a V2X Application Server may
support the following functions:
- For the V2X Localized User Plane supported feature, MB2-C procedures defined in 3GPP TS 23.285 [28]
subclause 5.4.2.2 for requesting the BM-SC to activate an MBMS bearer for local MBMS based MBMS data
delivery.
4.2.2 Broadcast-Multicast Service Centre (BM-SC)
The BM-SC is defined in TS 23.246 [3], with additions related to the MB2 reference point in TS 23.468 [4], and
supports the following functionality:
- MBMS Broadcast Mode procedures defined in TS 23.246 [3] (stage 2) and in TS 29.061 [6] (stage 3).
- MB2-C procedures defined in TS 23.468 [4], for activating, deactivating, modifying an MBMS bearer,
allocating/deallocating TMGI and notifying the TMGI expiry or the MBMS Bearer condition to GCS AS.
- SGmb procedures for controlling MBMS broadcast bearers defined in TS 29.061 [6].
- Reception of user data from the GCS AS via the MB2-U reference point and forwarding those data via the
SGi-mb reference point as described in TS 29.061 [6].
In addition to the functions defined in 3GPP TS 23.468 [4], the BM-SC may support the following functions for V2X
services:
- For the V2X Localized User Plane supported feature, MB2-C procedures defined in 3GPP TS 23.285 [28]
subclause 5.4.2.2 for receiving Local MBMS information defined in 3GPP TS 23.285 [28] from an GCS AS
which acts as a V2X Application Server.
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 [3].
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.
NOTE: As defined in TS 23.246 [3], TMGIs need to be globally unique. It is assumed that the BM-SC uses a
configured range of TMGI values.
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.
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 11 ETSI TS 129 468 V15.8.0 (2020-01)
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.
NOTE 1: During the TMGI Allocation Procedure, the BM-SC does not activate MBMS. However TMGIs, for
which the expiration time is renewed, may already have active MBMS bearers.
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.
5.2.2 TMGI Deallocation Procedure
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).
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 12 ETSI TS 129 468 V15.8.0 (2020-01)
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.
5.3 MBMS Bearer Control Procedures
5.3.1 General
The GAR command described in subclauses 5.3.2, 5.3.3 and 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 Procedure
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.
NOTE: The GCS AS can find out whether the BM-SC supports the MBMS Cell List feature and the V2X
Localized User Plane feature prior to applying the Activate MBMS Bearer Procedure the first time by
using the TMGI Allocation Procedure in advance.
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 IETF RFC 6363 [31]) 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 IETF RFC 5795 [29] and
IETF RFC 3095 [30]) 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 3GPP TS 23.246 [3]. 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
ETSI
3GPP TS 29.468 version 15.8.0 Release 15 13 ETSI TS 129 468 V15.8.0 (2020-01)
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 3GPP TS 23.246 [3]. 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 3GPP TS 29.061 [6], the BM-SC shall indicate that the bearer activation procedure is still in progress
in the MBMS-Bearer-Resu
...