ETSI TS 102 744-3-8 V1.1.1 (2015-10)

TECHNICAL SPECIFICATION
Satellite Earth Stations and Systems (SES);
Family SL Satellite Radio Interface (Release 1);
Part 3: Control Plane and User Plane Specifications;
Sub-part 8: NAS Layer and User Plane Operation
for MBMS Services
2 ETSI TS 102 744-3-8 V1.1.1 (2015-10)

Reference
DTS/SES-00299-3-8
Keywords
3GPP, GPRS, GSM, GSO, interface, MSS, radio,
satellite, TDM, TDMA, 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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
http://portal.etsi.org/tb/status/status.asp
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.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Abbreviations . 7
4 Introduction . 7
4.1 Network Architecture . 7
4.2 Protocol Architecture . 8
5 MBMS NAS Layer Operations . 9
5.1 MBMS Mobility Management procedures . 9
5.1.1 GPRS Attach to BM Domain . 9
5.1.1.1 Successful GPRS Attach Procedure . 9
5.1.1.2 Unsuccessful GPRS Attach Procedure . 10
5.1.2 GPRS Detach . 10
5.1.2.0 General . 10
5.1.2.1 CN-initiated GPRS Detach Request . 10
5.1.2.2 UE-initiated GPRS Detach Request . 11
5.2 MBMS Service Management Procedures . 12
5.2.1 MBMS Service Activation . 12
5.2.1.0 General . 12
5.2.1.1 MBMS Context Activation . 12
5.2.1.2 CN-initiated MBMS Context Activation . 13
5.2.1.3 Unsuccessful MBMS Context Activation (Service not authorized) . 14
5.2.1.4 Unsuccessful MBMS Context activation (Critical failure or Layer 2 establishment rejection) . 14
5.2.2 MBMS Context Deactivation . 15
5.2.2.0 General . 15
5.2.2.1 UE Initiated MBMS Context Deactivation . 15
5.2.2.2 Core Network Initiated MBMS Context Deactivation . 16
5.3 MBMS Bearer Management procedures . 16
5.3.1 Radio Access Bearer Release. 16
5.3.2 MBMS Radio Access Bearer Release . 17
5.3.3 MBMS Radio Access Bearer Modify . 17
5.3.4 MBMS Radio Access Bearer Modification Request . 17
5.3.5 MBMS Service modification . 18
5.3.6 MBMS Service Removal . 19
6 Mobility Management Behaviour . 20
6.1 Spot Beam Handover. 20
6.2 Inter-RNC operation (via different satellites) . 21
6.3 Inter-system mobility . 21
7 Exception handling . 21
7.1 Forced Detach (CN Initiated) . 21
7.2 Primary PDP Context deactivation (while MBMS Contexts present) . 21
8 IP User Plane Handler for MBMS Services . 22
8.0 General . 22
8.1 UE-TE Controller triggered MBMS Services via R-interface . 22
8.1.1 Activation of MBMS Services . 22
8.1.2 Deactivation of MBMS Services . 22
8.2 Directly Connected TEs - use of IGMP as a trigger . 22
ETSI
4 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
8.2.0 General . 22
8.2.1 Joining and leaving multicast services . 22
8.2.2 Maintenance of multicast services - IGMP query mechanism . 23
8.3 Routers in the mobile domain - PIM-SM triggered MBMS Services . 23
8.3.1 Joining and leaving multicast services . 23
8.3.2 Source Specific Multicast (SSM) and Any Source Multicast (ASM) with Rendezvous point in the
terrestrial domain . 23
8.3.2.0 General . 23
8.3.2.1 Multicast Receivers with a Mobile Domain Router . 24
8.3.2.2 ASM Multicast Sources with a Mobile Domain Router . 25
8.3.2.3 SSM Multicast Sources with a Mobile Domain Router . 26
8.3.3 Rendezvous Point in the Mobile Domain . 27
8.3.3.0 General . 27
8.3.3.1 Multicast Receivers with a Mobile Domain Rendezvous Point . 28
8.3.3.2 Multicast Sources with a Mobile Domain Rendezvous Point . 28
8.3.4 Maintenance of IP-Multicast Services using PIM-SM . 29
8.4 BMSC triggered MBMS Services . 29
History . 30

ETSI
5 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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 (http://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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
The present document is part 3, sub-part 8 of a multi-part deliverable. Full details of the entire series can be found in
ETSI TS 102 744-1-1.
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.
Introduction
This multi-part deliverable (Release 1) defines a satellite radio interface that provides UMTS services to users of UEs
via geostationary (GEO) satellites in the frequency range 1 518,000 MHz to 1 559,000 MHz (downlink) and
1 626,500 MHz to 1 660,500 MHz and 1 668,000 MHz to 1 675,000 MHz (uplink).
ETSI
6 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
1 Scope
The present document defines the operation of Multimedia Broadcast Multicast Services (MBMS) in support of
efficient delivery of IP multicast traffic across the Family SL satellite radio interface. This includes extensions to the
Non-Access Stratum (NAS) Layer peer-to-peer interface (defined in ETSI TS 124 007 [1] and ETSI TS 124 008 [2])
between the User Equipment (UE) and a new architectural entity defined as the Broadcast Multicast Service Node
(BMSN). In addition, extensions to the IP User Plane Handler (UPH) to interpret IP multicast management and routing
protocols are defined in the present document to allow automated triggering of MBMS services as defined for the
Family SL satellite radio interface.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 124 007: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Mobile radio interface signalling layer 3; General Aspects
(3GPP TS 24.007 Release 4)".
[2] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3 (3GPP TS 24.008 Release 4)".
[3] ETSI TS 102 744-1-4: "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio
Interface (Release 1); Part 1: General Specifications; Sub-part 4: Applicable External
Specifications, Symbols and Abbreviations".
[4] ETSI TS 102 744-3-2: "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio
Interface (Release 1); Part 3: Control Plane and User Plane Specifications; Sub-part 2: Bearer
Control Layer Operation".
[5] ETSI TS 102 744-3-6: "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio
Interface (Release 1); Part 3: Control Plane and User Plane Specifications; Sub-part 6: Adaptation
Layer Operation".
[6] ETSI TS 102 744-3-7: "Satellite Earth Stations and Systems (SES); Family SL Satellite Radio
Interface (Release 1); Part 3: Control Plane and User Plane Specifications; Sub-part 7: NAS Layer
Interface Extensions for MBMS Services".
ETSI
7 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 123 246: "Universal Mobile Telecommunications System (UMTS); Multimedia
Broadcast/Multicast Service (MBMS); Architecture and functional description (3GPP TS 23.246
Release 7)".
3 Abbreviations
For the purposes of the present document, the abbreviations in clause 3 of ETSI TS 102 744-1-4 [3] apply.
4 Introduction
4.1 Network Architecture
Figure 4.1 presents the network architecture of this multi-part deliverable (Release 1) illustrating the entities which are
responsible for the provision of Multimedia Broadcast Multicast Services (MBMS). This includes:
• the Broadcast Multicast Service Node (BMSN), which contains the agents for the Non-Access Stratum
signalling and for replication of traffic associated with MBMS via multiple RNCs; and
• the Broadcast Multicast Service Centre (BMSC), which contains the Broadcast Multicast Management
Function (BMMF) responsible for control of access to MBMS Services.

Figure 4.1: Network architecture showing BM domain entities
The Gmb interface is used to control access to the Multimedia Broadcast and Multicast Services (MBMS) that are
offered by the Broadcast Multicast domain of the Core Network (the BMSN and the BMSC). This interface performs
the functions as defined in ETSI TS 123 246 [i.1] and in addition provides capabilities that allow the features of the
satellite-specific elements of the multicast services to be administered by the BMMF within the BMSC (not shown in
these diagrams as it is a functional entity within the BMSC).
ETSI
8 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
4.2 Protocol Architecture
The function of the satellite radio interface NAS Layer is to provide support to the IP User Plane Handler (UPH). The
NAS Layer uses the services provided by the Adaptation Layer (AL). Figure 4.2 illustrates the position of the NAS
Layer within the Family SL air interface protocol stack. An overview of the radio interface layering and relationship to
the NAS Layer is provided in ETSI TS 102 744-3-7 [6], clause 4.1.
The present document defines the operation of the extension to the NAS Layer peer-to-peer interface (defined in
ETSI TS 124 007 [1] and ETSI TS 124 008 [2]) between the RNC and the UE that is required in order to support the
Family SL implementation of MBMS, as shown in Figure 4.2.
IP
IP
IGMP/PIM-SM
UPH UPH
NAS Layer Messages
BMSM BMSM
RABM/
MRABM
BMM BMM
Non-Access Stratum
RE LA Y
AL AL RANAP RANAP
Lower Lower
Lower Layers Lower Layers
Layers Layers
Access Stratum
UE RNC CN
U I
sl u
Figure 4.2: Satellite Network Higher Layers (NAS and IP)
The NAS Layer is responsible for the following:
• Radio Access Bearer Management;
• MBMS Radio Access Bearer Management;
• Broadcast Multicast Mobility Management (BMM);
• Broadcast Multicast Session Management (BMSM).
Protocol entities in the BM domain of the NAS Layer use message transport services provided by the Adaptation Layer
to communicate with their peers through a single Service Access Point (SAP):
• BMMAL-SAP: BMM to Adaptation Layer Service Access Point Broadcast Multicast (BM) domain.
This SAP inherits functionality from the GMMAL-SAP described in detail in ETSI TS 102 744-3-6 [5].
The NAS Layer functionality described in the present document constitutes an extension to the 3GPP Session
Management behaviour, with the full functionality of the Session Management entity and these extensions being
implemented in the BMSM entity. In addition, extensions to the User Plane Handler to support interpretation of IP
multicast related signalling protocols are described in the present document.
ETSI
9 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5 MBMS NAS Layer Operations
5.1 MBMS Mobility Management procedures
5.1.1 GPRS Attach to BM Domain
5.1.1.1 Successful GPRS Attach Procedure
The GPRS Mobility Management Procedures and Security Mode Procedures which operate towards the PS domain are
utilized for the BM Domain. If a combined PS/CS Attach procedure is employed to minimize signalling across the radio
interface, then the GMM signalling is directed to the PS domain and the mobility management state is locally
transferred (within the UE protocol stack) to the BMM and MM entities for the BM and CS domain respectively;
otherwise independent GPRS Attach procedures are applied for the PS and BM domains and a separate mobility
management state is maintained in the BMM and GMM entities.

TE UE RAN BMSN BMMF/ HLR
2. UDT (ATTACH REQUEST
1. AT+CGATT=1
RANAP ATTACH
3. B : IUEM(
(IMSI))
EQUEST 4. GPRSATTACH REQUEST
R (IMSI))
(IMSI)
RANAP
6. B :
TTACH CCEPT
5. GPRSA A
OMMON
C ID(IMSI)
7. BRANAP: DT
(ATTACH ACCEPT)
8. DDT:
(ATTACH ACCEPT)
9. AT: OK
Figure 5.1: Successful GPRS Attach procedure towards the BM domain
The procedure is illustrated in Figure 5.1 and described as follows:
1) The Attach Request procedure may be initiated by an external AT Command sent to the UE (or the UE may be
configured internally to attach to the BM domain on power-up).
2) The UE initiates the GPRS Attach procedure by sending an Attach Request (IMSI) to the PS Domain of Core
Network encapsulated in an UplinkDirectTransfer AL message.
3) The RAN creates an IuConnectionIdentifier handler for the UE and forwards the Attach Request (IMSI)
message to the BMSN encapsulated in an Initial_UE_Message.
4) The BMSN creates a handler for this Iu signalling connection and associates it to the IMSI. It then creates and
sends a GPRS Attach Request to the BMMF to verify if this IMSI is provisioned in the system (full Identity
Check and Security Mode procedures may be applied at this stage).
5) If the IMSI is provisioned and allowed to access the BM domain then the BMMF sends a GPRS Attach Accept
to the BMSN.
6) he BMSN creates a CommonID (IMSI) message and sends it to the RAN via the newly created Iu Signalling
connection. This informs the RNC of the permanent NAS identity (IMSI) of a user and allows the RNC to
create a reference between the IMSI and the UE Specific Signalling connection.
7) The BMSN sends a GPRS Attach Accept to the UE encapsulated in a Direct Transfer Iu message.
8) The RAN forwards the Attach Accepts message to the UE which updates its GMM state.
9) The initiator of the AT Command receives an OK in response to its initial command, acknowledging the
successful completion of the procedure (if the command was initiated by the TE).
At the conclusion of the GPRS Attach and Security Mode Procedures, the signalling connection between the UE and the
BM domain is available and secured for BM Session Management operation, as defined in clause 5.2.
ETSI
10 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5.1.1.2 Unsuccessful GPRS Attach Procedure
An unsuccessful GPRS Attach procedure may occur for a number of reasons, including:
1) The IMSI for the UE is not provisioned for operation with the BM domain;
2) Security mode procedures fail;
3) Communications within the Access Stratum are unreliable.
Until the GPRS Attach Procedure towards the BM succeeds (or a Combined Attach procedure succeeds), no further
BMSM signalling can take place.
5.1.2 GPRS Detach
5.1.2.0 General
The GPRS Detach procedure may be initiated by either the User Equipment or the Core Network to remove the
mobility management association between the UE and the CN.
5.1.2.1 CN-initiated GPRS Detach Request
If the UE was attached to multiple domains using a combined Attach procedure, a GPRS Detach procedure initiated by
any of the Core Network domains will result in loss of connectivity between the UE and all Core Network Domains,
including the BM Domain.
If the UE utilized a specific Attach procedure towards the BM domain, then the UE shall only modify the mobility
management state held in the BMM entity in response to a GPRS Detach procedure initiated by the BM domain,
Upon reception of a GPRS Detach Request initiated by the BM Domain of the Core Network, the UE shall
acknowledge the Detach Request to the BM Domain. All PDP Context information shall be implicitly deleted by both
the UE and the CN, and all RABs shall be considered implicitly deleted by the UE. The CN shall issue an IuSignalling
Connection Release Request, and all RABs shall be considered implicitly deleted by the RAN.

BMMF
TE UE RAN
BMSN
1. MANAGEMENT COMMAND
RANAP DT
2. B :
(DETACH UE)
DDT ETACH EQUEST
3. : (D R ) (DETACH REQUEST)
4. UDT (DE TACH ACCEPT)
RANAP ETACH
5. B : DT(D
CCEPT
A )
All PDP contexts &
Bearer Contexts
6. BRANAP: IU RELEASE
All Contexts and
released implicitly
OMMAND
C
RABs released
implicitly
7. BRANAP : IU RELEASE
COMPLETE
All RABs
released
impli citly
Figure 5.2: BM domain-initiated GPRS Detach Request
The procedure is illustrated in Figure 5.2 and described as follows:
1) A management entity, such as the BMMF issues a management command instructing the BMSN to detach an
UE.
2) The BMSN initiates a Detach Request towards the UE.
3) Upon receipt of the Detach Request on the interface, the UE GMM enters into PMM-Detached state.
ETSI
11 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
4) The UE deletes all connection state and responds to the BMSN by forwarding a Detach_Accept message via
the RAN encapsulated in an Uplink Direct Transfer message.
5) The RAN sends this NAS message to the BMSN via the IuBM interface in a Direct Transfer Iu container.
6) The BMSN initiates an Iu Release Command to remove the UE-specific signalling connection between the
RAN and the PS domain of the CN.
7) The RNC implicitly releases all RABs and completes the Iu Release command.
5.1.2.2 UE-initiated GPRS Detach Request
If the UE utilized a combined Attach procedure, then the Detach procedure will be directed to the PS domain.
If the UE utilized a specific Attach procedure to obtain access to the BM domain, then the UE shall initiate a specific
GPRS Detach procedure towards the BM domain.
All connection states within the UE are deleted implicitly.

BMMF
TE UE RAN  BMSN
1. AT+CGACT=0
3. BRANAP: DT
2. U : (D R )
DT ETACH EQUEST
(DE TACH R EQUEST)
4. BRANAP: DT (DETACH
ACCE PT)
5. DDT (DETACH ACCE PT)
All PDP contexts&
6. AT OK
Bearer Contexts
7 . B : I R
RANAP U ELEASE
C released implicitly
OMMAND
8. BRANAP: IU RELEASE
COMPLETE
All Contexts and
RABs released
implicitly All RABs
released
implicitly
Figure 5.3: UE-initiated GPRS Detach Procedure
The procedure is illustrated in Figure 5.3 and described as follows:
1) A trigger (AT command) requests the UE to detach from the Core Network.
2) The UE GMM entity enters in PMM-detached state and initiates a Detach Request towards the BMSN via the
RAN in an Uplink Direct Transfer message on its UE signalling.
3) The RAN forwards the message to the Core Network via the IuBM interface in a Direct Transfer message.
4) Upon reception of the NAS message, the BMSN implicitly triggers the deactivation of its PDP Context and
associated RAB. The BMSN responds to the UE by forwarding a Detach_Accept message to the RAN in a
Downlink Direct Transfer message.
5) The RAN sends this NAS message to the UE via the UE-specific signalling interface. At this point, all RABs
connections are released in the UE.
6) The UE signals the successful detach to the TE.
7) The BMSN initiates an Iu Release Command to remove the UE-specific signalling connection between the
RAN and the PS domain of the CN.
8) The RNC completes the Iu Release command and implicitly deletes all RABs.
ETSI
12 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5.2 MBMS Service Management Procedures
5.2.1 MBMS Service Activation
5.2.1.0 General
MBMS Services are delivered to UEs using MBMS Radio Access Bearers established during the MBMS Context
activation procedure.
Whenever it is necessary to deliver a MBMS Service to a UE, the MBMS Context Activation procedure will be initiated
at the UE, either by an external trigger or by a Request from the BMSN. In the former case, it is required that the
external control entity has a-priori knowledge of the MBMS Temporary Multicast Group Identifier (TMGI) as it shall
be signalled in the request from the Terminal Equipment (TE) using the appropriate AT Command.
5.2.1.1 MBMS Context Activation
Figure 5.4 shows the procedure initiated by the UE that triggers the MBMS Context Activation.
`
TE UE RAN BMSN BMMF
2.BRANAP: DT
UDT CTIVATE
1. (A _MBMS  3. MBMS_SERVICE
(ACTIVATE_MBMS
CONTEXT_REQUEST (APN,
ACCESS REQUEST
CONTEXT_REQUEST
TMGI)) IMSI TMGI LAC
( , APN, , ,
(APN,TMGI))
MBMS BEARER CAPABILI TIES)
5. BRANAP:
RAB_A SSIGN_REQ
4.MBMS_SERVICE
(RAB- TO- BE-SETUP- MODIFY
ACCESS ACCEPT
(RAB - ID, MBMS_SERVICE-ID
(TMGI, QOS, TFT)
REQ MB CONTEXT STATE
- - - ,
CN_UP _IP, CN_TEID))
RETUNE HANDOVER
6. /
7. RETUNE/HANDOVER ACK
RANAP
10.B :
RAB_AS SIGN_RESPONSE
ESTABLISH
8.
RAB SETUP MODIFY
( - -
RAB ID ONTEXT
( _ , MBC _ID,
9. ESTABLISH ACK
MBCONTEXT_STATE,
RAN _UP _IP, RAN_TEID))
11.BRANAP : DT
12. DDT:
CTIVATE ONTEXT
(A _MBMSC _
(ACT IVATE _MBMSCONTEXT
ACCEPT (TFT))
_AC CEPT (TFT))
Figure 5.4: MBMS Context Activation Procedure
The procedure is illustrated in Figure 5.4 and described as follows:
1) The UE creates a handler (Enhanced Network Service Access Point Identifier (NSAPI)) for this MBMS
Context and transmits an Activate_MBMS_Context_Request (Enhanced NSAPI, Multicast Address, Access
Point Name (APN), TMGI) to the RAN in an Uplink Direct Transfer message towards the BM domain.
2) The RAN identifies that this Uplink Direct Transfer contains a message for the BM domain and forwards the
Activate_MBMS_Context_Request (Enhanced NSAPI, Multicast Address, APN, TMGI) to the BMSN using a
Direct Transfer Message via the already established UE-specific Iu signalling connection.
3) The BMSN sends a request to the Authorization entity to determine if the UE is authorized to access the
requested MBMS Service within the APN.
4) Providing the UE is authorized to access the MBMS Service, the Authorization entity will accept the request
and provides the BMSN with QoS, TFT, allocation/retention priority, asymmetry indicator and group cipher
key information (if applicable).
5) The BMSN requests the establishment of a MBMS Radio Access Bearer for support of IP Multicast traffic
bound to the MBMS Service. The BMSN specifies the transport layer information including the IP Address
and GTP TEID to be used by the RAN for forwarding traffic associated with this MBMS Radio Access Bearer
towards the CN.
ETSI
13 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
6) At reception of the RAB Assignment Request, the RAN determines whether there is sufficient capacity to
support the MBMS Radio Access Bearer QoS requirements, and if necessary triggers a Retune or Handover
procedure.
7) Upon reception of the Retune or Handover message the UE acknowledges the Retune or Handover message
8) The RAN then sends an Establish message to associate the UE with the MBMS Radio Access Bearer.
9) The UE acknowledges the association using an EstablishAck message.
10) The RAN confirms that the MBMS Radio Access Bearer has been successfully established, and provides a
reference to the MBMS Context (using an RNC GTPu IP Address and RNC GTP Tunnel Endpoint Identifier
as a reference) with which the UE is associated using a RAB Assignment Response. The RAN provides the
CN with the MBMS Context ID with which the MBMS Radio Access Bearer is associated. If this is a newly
created MBMS Context ID, the value of the MBMS Context State information element will indicate that the
RNC is waiting to be configured with the MBMS Context State by the CN. If the MBMS Radio Access Bearer
is associated with an existing MBMS Context, then the MBMS Context State information will reflect the
current MBMS Context State of the associated MBMS Context.
11) The BMSN completes the NAS transaction by sending an Activate_MBMS_Context_Accept(TMGI, TFT)
message to the UE in a Direct Transfer message via the UE-specific Iu signalling connection with the RAN.
If the required IP multicast group/source is not currently being received by the BMSN, then the BMSN
generates a Protocol Independent Multicast - Session Management (PIM-SM) join message towards the
upstream routers, rendezvous point or multicast source.
12) The RAN forwards the Activate_MBMS_Context_Accept(TMGI) towards the UE in a DownlinkDataTransfer
message via the UE-specific-signalling connection.
5.2.1.2 CN-initiated MBMS Context Activation

TE UE RAN BMSN BMMF
1. BRANAP: DT
DT
2. D (REQUEST_MBMSCONTEXT_
(REQUEST_MBMSCONTEXT_A CTIVATION INKED
A ( L NSAPI,
CTIVATION INKED
( L NSAPI, ULTICAST DDRESS
M A , TMGI))
ULTICAST DDRESS
M A , TMGI))
3. MBMS Bearer Context Activation

Figure 5.5: CN initiated MBMS Context Activation
The procedure is illustrated in Figure 5.5 and described as follows:
1) The BMSN initiates a Request_MBMS_Context_Activation(Linked NSAPI, Multicast Group Address, TMGI)
message towards the UE and sends it to the RAN in a BRANAP (downlink) Direct Transfer message via the
established Iu Signalling connection.
2) The RAN forwards the Request_MBMS_Context_Activation message to the UE in a DownlinkDataTransfer
message via the UE-specific-signalling connection.
3) The MBMS Context Activation Procedure initiated from the UE is described in clause 5.2.1.1.
ETSI
14 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5.2.1.3 Unsuccessful MBMS Context Activation (Service not authorized)
Figure 5.6: Unsuccessful MBMS Context Activation- Service not authorized
The procedure is illustrated in Figure 5.6 and described as follows. Transactions 1 to 3 are described in clause 5.2.1.1.
1) The Authorization entity determines that the UE is not authorized to access the MBMS Service (TMGI) and
responds to the request with a MBMS_Service_Access_Reject(cause).
2) The BMSN informs the UE that the MBMS Context cannot be activated and specify the cause. The message is
sent to the RAN in a Direct Transfer message on the Iu interface.
3) The RAN forwards the NAS message to the UE. The UE destroys the handler for this MBMS Context.
5.2.1.4 Unsuccessful MBMS Context activation (Critical failure or Layer 2
establishment rejection)
Figure 5.7 shows the same initial transactions for activation of the MBMS Context described in clause 5.2.1.1 with the
difference that a critical failure occurs during L2 establishment and the UE fails to complete its Establish procedure
(transaction 9 on Figure 5.7).
Figure 5.7: MRAB establishment Failed - Layer 2 failure
1) The RAN informs the BMSN that the MRAB establishment was unsuccessful (RAB failed to establish).
2) The BMSN builds an Activate_MBMS_Context_Reject and sends it to the UE via the RAN. No further action
is required from the BMSN.
3) The RAN forwards the NAS message to the UE to inform it that the MBMS Context activation procedure has
failed. The UE destroys it MBMS Context handler.
ETSI
15 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5.2.2 MBMS Context Deactivation
5.2.2.0 General
The MBMS Context deactivation is a normal procedure when a UE no longer requests access to a specific MBMS
Service. The MBMS Context deactivation is either initiated by the UE (for example after reception of an external AT
command) or the Core Network (following reception of an IP Multicast Internet Group Management Protocol (IGMP)
or PIM-SM "leave" message from the UE via the PDP Context). Following the MBMS Context deactivation procedure,
the Core Network may release the MBMS Context if the UE was the last one associated to it (see clause 5.3.6).
5.2.2.1 UE Initiated MBMS Context Deactivation
This procedure will be triggered in the UE by reception of an AT Command (APN) or equivalent signal on an external
interface.
Note that Deactivate_PDP_Context_Request NAS primitive is used to initiate the deactivation of the MBMS Context.
Figure 5.8: MBMS Context Deactivation - UE initiated
The procedure is illustrated in Figure 5.8 and described as follows:
1) Upon receipt of the appropriate trigger, such as an AT command via an external interface, the UE removes the
TFT handler associated to the MBMS Context.
2) The UE transfers the NAS message Deactivate_PDP_Context_Request towards the RAN using an Uplink
Direct Transfer message. The Transaction Identifier value is the same as the one used in the
Activate_MBMS_Context_Request message triggered to access the MBMS Service not any more required.
3) The RAN forwards this NAS message to the BMSN via the IuBM interface.
4) The BMSN requests that a Deactivate_PDP_Context_Accept is sent to the UE.
5) The RNC forwards the message to the UE.
6) The UE deletes the MBMS Context and signals it via the external interface.
7) The BMSN requests the RAN to release the MRAB from this MBMS Context as described in clause 5.2.2. It
should be noted that the MBMS Context will not be released unless this is the last UE associated with this
MBMS Context.
ETSI
16 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
5.2.2.2 Core Network Initiated MBMS Context Deactivation
This procedure allows the Core Network to trigger the deactivation of a MBMS Context to stop the delivery of a
MBMS Service to/from a UE. This is a normal procedure following reception of a trigger.
`
UE
TE MT RAN BMSN BMMF
1. BRANAP: DT
2. DDT
(DEACTIVATE PDP
(DEACTIVATE PDP
CONTEXT REQUEST)
CONTEXT REQUEST)
4. BRANAP: DT
3. UDT (DEACTIVATE PDP
(DEACTIVATE PDP
CONTEXT ACCEPT)
CONTEXT ACCEPT)
5. M RA B Release
Figure 5.9: MBMS Context Deactivation - Core Network initiated
The procedure is illustrated in Figure 5.9 and described as follows:
1) The BMSN constructs a Deactivate_PDP_Context_Request and forwards it to the UE (via the RAN) in order
to deactivate the MBMS Context delivering a MBMS Service not any more required.
2) The RAN forwards the NAS message to the UE using a Downlink Direct Transfer message through the UE
Specific signalling connection.
3) The UE acknowledges the receipt of the MBMS Context deactivation.
4) The RAN relays the NAS message to the BMSN.
5) The BMSN instructs the RAN to release the MRAB associated with the MBMS Context as described in
clause 5.2.2. It should be noted that the MBMS Context will not be released unless this is the last UE
associated with this MBMS Context.
5.3 MBMS Bearer Management procedures
5.3.1 Radio Access Bearer Release
The procedure illustrated in Figure 5.10 shows the BMSN requesting the release of a unicast Radio Access Bearer.
Figure 5.10: RAB Release
The procedure is described as follows:
1) The BMSN sends a RAB Assignment Request containing the RAB_ID of the RAB to release and the cause for
release.
2) The RAN signals the release of the connection to the UE.
3) The UE acknowledges the release.
ETSI
17 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
4) The RAN confirms the release of the Radio Access Bearer to the BMSN.
Note that the BMSN may request the release of more than one RAB in a single RAB Assignment Request primitive.
Transactions 2, 3 and 5 would repeated for each RAB.
5.3.2 MBMS Radio Access Bearer Release
The procedure illustrated in Figure 5.11 shows the BMSN requesting the release of a MBMS Radio Access Bearer.
Figure 5.11: MRAB Release
The procedure is described as follows:
1) The BMSN sends a RAB Assignment Request containing the RAB_ID/MRAB_ID of the MRAB to release
and the cause for release.
2) The RAN signals the release of the connection to the UE.
3) The UE acknowledges the release.
4) The RAN confirms the release of the MBMS Radio Access Bearer to the BMSN.
Note that the BMSN may request the release of multiple RAB/MRAB in a single RAB Assignment Request primitive.
Transactions 2, 3, 5 and 6 would repeated for each RAB/MRAB.
5.3.3 MBMS Radio Access Bearer Modify
Figure 5.12 shows a RAB Assignment Request primitive initiated by the BMSN to request the change of state of a
MBMS Radio Access Bearer. If the reason for this modification is a change of state of the MBMS Context, then this
procedure is initiated for each UE associated to the MBMS Context which state has been changed.
``
TE MT RAN BMSN BMMF
UE
1. BRANAP:
RAB_ASSIGN_REQ (RAB-TO-
BE-SETUP-MODIFIED
(RAB-ID, MBMS-SERVICE-ID,
REQ-MB-CONTEXT-STATE))
2. BRANAP:
RAB_ASSIGN_RESP (RAB-
SETUP-MODIFY-LIST
(RAB-ID, MB-CONTEXT-ID,
MB-CONTEXT-STATE))
Figure 5.12: MBMS Radio Access Bearer Modify Procedure
5.3.4 MBMS Radio Access Bearer Modification Request
Mobility management and physical-bearer radio resource management decisions taken by an RNC result use either the
handover or retuning mechanisms over the satellite interface. Both of these procedures result in a similar set of
interactions on the RAN-CN interface, in that a UE may be associated with a new MBMS Context, and the state of the
MRAB delivered to this UE may change depending upon the availability of radio resources (or geographical location of
the UE).
ETSI
18 ETSI TS 102 744-3-8 V1.1.1 (2015-10)
This procedure is initiated by the RAN whenever there is a change of state of the association between an UE and a
MBMS Context (due to a handover taking
...