6 MBMS Attributes and Parameters
23.2463GPPArchitecture and functional descriptionMultimedia Broadcast/Multicast Service (MBMS)Release 17TS
6.1 MBMS UE Context
The MBMS UE Context is used in Multicast Mode and contains UE-specific information related to a particular MBMS bearer service that the UE has joined. An MBMS UE Context is created in the UE, SGSN,GGSN and BM-SC Membership function when the UE joins an MBMS bearer service. In the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of the MBMS UE Context from the old SGSN.
In Iu mode, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism to the BSC/SRNC at least when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service Activation. MBMS UE Contexts are provided to the Iu mode BSC/SRNC regardless whether MBMS Sessions are ongoing or not (i.e. before, between and after Sessions). In addition, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism when a UE, which has an MBMS UE Context active, moves to PMM-Connected state via the MBMS Service Request procedure for the purpose of MBMS.
In the UE and SGSN, the MBMS UE Context is stored as part of the MM Context for the UE. The MBMS UE Context is stored in the GGSN. There is one MBMS UE Context per MBMS bearer service that the UE has joined.
In the Iu mode BSC/RNC, the MBMS UE Contexts are stored as part of the UE Context of the BSC/RNC.
The content of the MBMS UE Context is described in Table 1.
Table 1: MBMS UE Context
|
Parameter |
Description |
UE |
SGSN |
GGSN |
RNC |
BSC |
BM-SC |
|
IP multicast address |
IP multicast address identifying an MBMS bearer that the UE has joined. |
X |
X |
X |
X |
Iu – X Gb – none |
X |
|
APN |
Access Point Name on which this IP multicast address is defined. |
X |
X |
X |
X |
Iu – X Gb – none |
X |
|
GGSN Address in Use |
The IP address of the GGSN currently used |
X |
|||||
|
SGSN address |
The IP address of SGSN |
X |
|||||
|
TMGI |
Temporary Mobile Group Identity allocated to the MBMS bearer. |
X |
X |
X |
Iu – X Gb – none |
||
|
RAI |
The Routing Area Identity |
(5) |
|||||
|
Linked NSAPI |
NSAPI of the PDP context used by the UE to carry IGMP/MLD signalling. |
X |
X |
||||
|
IMSI |
IMSI identifying the user. |
(1) |
(1) |
X |
(2) |
Iu – (2) Gb – (3) |
X |
|
TI |
Transaction Identifier |
X |
X |
||||
|
TEID for Control Plane |
The Tunnel Endpoint Identifier for the control plane between SGSN and GGSN. |
X |
X |
||||
|
MBMS_NSAPI |
Network layer Service Access Point Identifier which identifies an MBMS UE Context. |
X |
X |
X |
X |
||
|
Additional MBMS Trace Info |
Identifies additional information required to perform trace. |
(4) |
(4) |
(4) |
|||
|
Trace Reference |
Identifies a record or a collection of records for a particular trace. |
(4) |
(4) |
(4) |
(4) |
||
|
Trace Type |
Indicates the type of trace. |
(4) |
(4) |
(4) |
(4) |
||
|
Trigger Id |
Identifies the entity that initiated the trace. |
(4) |
(4) |
(4) |
(4) |
||
|
OMC Identity |
Identifies the OMC that shall receive the trace record(s). |
(4) |
(4) |
(4) |
(4) |
||
|
(1) In the UE and SGSN, the IMSI is available within the MM Context which contains the MBMS UE Context. (2) The IMSI is available within the UE Context which contains the MBMS UE Context. (3) IMSI availability does not depend on MBMS. (4) Trace parameters are only stored if trace is activated. (5) RAI is available within the MM Context of the UE. |
|||||||
6.2 MBMS Bearer Context
The MBMS Bearer Context, which is referred to as MBMS Service Context in RAN, contains all information describing a particular MBMS bearer service and is created in each node involved in the delivery of the MBMS data.
In MBMS multicast mode a MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS UE Context is created in the node or when a downstream node requests it. The MBMS Bearer Context is statically configured in the BM-SC Proxy and Transport Function; how this is done is out of the scope of this specification. The MBMS Bearer Context is created in the Iu mode BSC and in SRNC when a first MBMS UE Context is created in BSC/SRNC. MBMS Session Start procedure may create MBMS Bearer Context in a BSC/RNC which has no MBMS Bearer Context yet.
In MBMS broadcast mode, an MBMS Bearer Context is created in the MME/SGSN, MBMS GW/GGSN and RAN as a result of the MBMS Session Start procedure.
An MBMS Bearer Context, once created, can be in one of two states reflecting the bearer plane resource status of the corresponding MBMS bearer service.
Figure 6: MBMS Bearer Context State Model
‘Active’ reflects the state of an MBMS Bearer Context in which bearer plane resources are required in the network for the transfer of MBMS data. This state is maintained as long as there is a corresponding MBMS session ongoing.
‘Standby’ reflects the state of an MBMS Bearer Context in which no bearer plane resources are required in the network for the transfer of MBMS data. This state is maintained as long as there is no corresponding MBMS session ongoing.
In MBMS broadcast mode, the MBMS Bearer Context is always implicitly in state ‘active’ (since it is created as a result of an MBMS Session Start procedure) and does not use the MBMS Bearer Context State Model in Figure 6.
The content of the MBMS Bearer Context is described in Table 2.
Table 2: MBMS Bearer Context for GPRS
|
Parameter |
Description |
RAN |
SGSN |
GGSN |
BM-SC |
|---|---|---|---|---|---|
|
Multicast/broadcast mode |
MBMS bearer service in broadcast or multicast mode |
X |
X |
X |
X |
|
IP multicast address( |
IP multicast address identifying the MBMS bearer described by this MBMS Bearer Context. |
X |
X |
X |
X |
|
APN |
Access Point Name on which this IP multicast address is defined. |
X |
X |
X |
X |
|
TMGI |
Temporary Mobile Group Identity allocated to the MBMS bearer service. |
X |
X |
X |
X |
|
Flow Identifier (broadcast mode only) |
Location dependent subflow of the MBMS bearer service. When present, the Flow Identifier together with the TMGI uniquely identify the MBMS Bearer Context. |
X |
X |
X |
|
|
GGSN TEID-C |
Tunnel Endpoint Identifier of GGSN for control plane. |
X |
|||
|
GGSN IP Address for Control Plane in use |
The IP address of the GGSN used for the control plane. |
X |
|||
|
State |
State of bearer plane resources (‘standby’ or ‘active’) |
X |
X |
X |
X |
|
Required MBMS Bearer Capabilities |
Minimum bearer capabilities the UE needs to support |
X |
X |
X |
|
|
QoS |
Quality of Service required for the MBMS bearer service. |
X |
X |
X |
X |
|
MBMS Service Area |
Area over which the MBMS bearer service has to be distributed. |
X |
X |
X |
X |
|
List of downstream nodes |
List of downstream nodes that have requested the MBMS bearer service and to which notifications and MBMS data have to be forwarded. |
X |
X |
X |
|
|
Number of UEs |
Number of UEs hosted by the node that have joined the multicast MBMS bearer service. |
X |
X |
||
|
List of PMM-CONNECTED UEs |
List of PMM-CONNECTED UEs which have activated an MBMS service. |
X2) |
|||
|
List of RAs |
List of RAs, each of which contains at least one UE that has joined the MBMS bearer service. |
X1) |
X1) |
||
|
IP multicast and Source address for distribution |
IP addresses identifying the SSM channel used for user plane distribution on the backbone network |
X |
X |
X |
|
|
MBMS HC indicator |
Flag set by BM-SC if it is using compressed header for the payload. |
X |
X |
X |
|
|
NOTE 1: It is an optional parameter. NOTE 2: It is available only for UTRAN, not for GERAN. NOTE 3: For GGSN, the list at least includes the couples of the SGSN IP addresses and TEIDs for control plane, and the couples for user plane. NOTE 4: GSN that supports both IPv4 and IPv6 address types, stores only the IP address in use. NOTE 5: For SGSN, the list includes the registered DRNC. NOTE 6: The GGSN shall include SGSN Address for user data and TEID-U for downstream SGSNs that do not accept the IP multicast backbone distribution. |
|||||
Table 3: MBMS Bearer Context for EPS (E-UTRAN/UTRAN) broadcast mode only
|
Parameter |
Description |
RAN |
MME/ SGSN |
MBMS-GW |
BM-SC |
|---|---|---|---|---|---|
|
MBMS GW TEID-C |
Tunnel Endpoint Identifier of MBMS GW for control plane. |
X |
|||
|
TMGI |
Temporary Mobile Group Identity allocated to the MBMS bearer service. |
X |
X |
X |
X |
|
Flow Identifier |
Location dependent subflow of the MBMS bearer service. When present, the Flow Identifier together with the TMGI uniquely identify the MBMS Bearer Context. |
X |
X |
X |
|
|
MBMS GW IP Address for Control Plane in use |
The IP address(es) of the MBMS GW used for the control plane. |
X (note 2) |
|||
|
MBMS GW IP Address for User Plane in use |
The IP address of the MBMS GW used for the user plane. |
X (note 2) |
|||
|
C-TEID |
Common Tunnel Endpoint Identifier of MBMS GW for user plane |
X |
X |
||
|
QoS parameters |
Quality of Service required for the MBMS bearer service. |
X |
X |
X |
X |
|
MBMS Service Area |
Area over which the MBMS bearer service has to be distributed. |
X |
X |
X |
X |
|
List of downstream nodes |
List of downstream nodes that have requested the MBMS bearer service and to which notifications have to be forwarded. |
X |
X |
X |
|
|
IP multicast address(es) and IP Source address(es) for distribution |
IP addresses identifying the SSM channel used for user plane distribution on the backbone network. The IP multicast address and paired IP address of the multicast source shall be of the same IP type. |
X |
X |
X |
|
|
MBMS HC indicator |
Flag set by BM-SC if it is using compressed header for the payload. |
X |
X |
||
|
SGSN IP Address and TEID for User Plane over Sn-U |
The IP address and TEID of SGSN used for the user plane over Sn-U when some RNCs have not accepted IP multicast distribution. |
X |
|||
|
List of cell ID(s) |
Cell(s) for which the MBMS bearer service may be distributed. |
X |
X |
X |
X |
|
NOTE 1: It is an optional parameter. NOTE 2: An MBMS GW that supports both IPv4 and IPv6 address types, stores both IP addresses. NOTE 3: For SGSN, the list includes the registered DRNC. NOTE 4: For MBMS GW, the list includes the couples of the SGSNs and MMEs IP addresses and TEIDs for control plane. NOTE 5: Header Compression is only supported for UTRAN and for Mission Critical services over E-UTRAN for this Release. NOTE 6: An MBMS-GW or an MME that supports IPv4 and IPv6 M1 multicast address types stores both IPv4 and IPv6 pairs of source and multicast addresses. The alternative IP multicast address and paired IP address of the multicast source are of the same IP type. NOTE 7: It is applicable for LTE only. |
|||||
6.3 Quality-of-Service
6.3.1 Quality-of-Service for GPRS
It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast MBMS bearer services. All QoS attributes related to the UMTS bearer service described in TS 23.107 [3] are applicable to MBMS bearer services. Compared to point-to-point bearer services the following limitations exist:
– For traffic class, only the background and streaming classes shall be supported.
– For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or corrupted SDUs (actual values are for the background and streaming classes are 10-2 and 10-1).
– For maximum bit-rate, see the values described in TS 22.246 [6].
– For Guaranteed bit rate of the Streaming Traffic Class: depending on radio resource usage by other services, some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not reject a MBMS Session Start Request message even if one or more cells do not have enough resources to establish radio bearers.
MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging or downloading. Buffering, shaping schemes and packet dropping may be applied to the traffic flow to adapt to the available resources and changing network conditions. The total transfer time is not critical for background class bearer services since the content must normally have been received in totality and stored in the UE before the user can access it.
MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming. As for point-to-point bearer services, the network should minimise the packet transfer delay of streaming class bearer services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt to the available resources.
The principle difference between background and streaming classes for MBMS is the support of a guaranteed bit-rate in the streaming case. No indication is provided to the UE in cases where the RAN cannot provide the requested QoS. As a result, some UEs may not receive the MBMS session or parts of it. For background class, the RAN may continue to distribute data in congestion conditions but at potentially high packet loss rates, therefore the MBMS user service will have to provide sufficient redundancy within the data to be able to cope with the high packet loss.
MBMS user services that would normally use MBMS bearer services of background class may however decide to use a streaming class MBMS bearer service if the MBMS user service cannot cope with high packet loss.
The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer services.
As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on radio level low SDU error ratios are difficult to achieve. When the resulting packet error ratio is not suitable for the MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a point-to-point PDP context.
6.3.2 Quality-of-Service for EPS
It shall be possible for the network to control quality-of-service parameters for sessions of broadcast MBMS bearer services. All EPS QoS attributes related to the EPS bearer service are applicable to MBMS bearer services.
For EPS, only GBR MBMS service is defined and the MBMS bearer service QoS includes the parameters QCI, ARP, GBR and MBR (TS 23.401 [16]).
For E-UTRAN MBMS bearer service for NB or M UE categories, operator defined QCIs may be configured in the BMSC and in the EUTRAN.
The BMSC may take into account the UE Capability for MBMS received via Activate MBMS Bearer Request in addition to the QoS requirements of the service and map that to a QCI value that is sent using MBMS Session Start Procedure towards EUTRAN (see TS 23.682 [29]).
BMSC may be configured to take into account the UE Category for MBMS to derive operator defined QCIs.
An example mapping is shown below for a service with otherwise the same QoS requirements:
Table 6.3.2-1: QCI association with UE Categories
|
UE Categories supported |
Operator defined QCI (not standardised) |
|
IoT UE type M2 |
a |
|
Both UE Category M1 and M2 UEs |
b |
|
IoT UE type NB2 |
c |
|
Both UE Category NB1 and NB2 |
d |
The BMSC may receive coverage level information for MBMS in addition to the UE Category for MBMS. When coverage information is received, and the BMSC is configured to take into account the coverage level, then BMSC generates the appropriate QCI based on the UE Category for MBMS and coverage level information for the MBMS service as defined in TS 23.682 [29].
An example mapping is shown below for a service with otherwise the same QoS requirements including coverage level:
Table 6.3.2-2: QCI association with UE Categories and coverage level
|
UE Categories supported |
Operator defined QCI (not standardised) |
|
IoT UE type M2, Coverage level: Medium |
a |
|
IoT UE type M2, Coverage level: Normal |
b |
|
IoT UE type M2 Coverage level: High |
c |
|
Both UE Category M1 and M2 UEs |
d |
|
IoT UE type NB2 |
e |
|
Both UE Category NB1 and NB2 |
f |
NOTE 1: The QCI to and from UE Capability for MBMS needs to be the same in E-UTRAN and BMSC.
Each GBR MBMS bearer service is associated with the following MBMS bearer level QoS parameters:
– QoS Class Identifier (QCI);
– Allocation and Retention Priority (ARP);
– Maximum Bit Rate (MBR);
– Guaranteed Bit Rate (GBR).
Unlike point-to-point EPS bearers, the MBR of a particular GBR bearer service shall be set equal to the GBR.
NOTE 2: UE-AMBR and APN-AMBR do not apply to MBMS bearer services.
Compared to point-to-point bearer services the following limitations exist:
– For Guaranteed bit rate: depending on radio resource usage by other services, some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not reject a MBMS Session Start Request message even if one or more cells do not have enough resources to establish radio bearers.
– MBMS bearer admission control within E-UTRAN is constrained by the E-UTRAN resources that are configured for MBMS.
In the case of E-UTRAN, established MBMS bearers may not always use all the resources configured for MBMS. When the resources configured for MBMS are not fully utilised, the E-UTRAN may schedule delivery of traffic from point-to-point bearers using some of the un-utilised MBMS resources (refer to TS 36.213 [25]).
GBR MBMS bearer services are best suited for the transport of MBMS user services where a constant bit rate is needed. As for point-to-point bearer services, the network should comply with the transfer delay for GBR QCI’s (TS 23.203 [23]). Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt to the available resources. The BM-SC ensures that the bit rate is not larger than the MBR. There is no radio aware flow shaping in the BM-SC.
The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer services at MBMS bearer service establishment.
When the MBMS bearer service experience a packet error ratio which is not suitable for the MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a point-to-point PDP context or PDN connection.
6.3.3 MBMS QoS distribution tree
MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many BSCs/RNCs, many SGSNs and one or more GGSNs. Furthermore some bearer resources may be shared between many users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS distribution tree shall be established with the same QoS.
MBMS distribution tree shall have the same QoS for all its branches.
When a branch of the MBMS distribution tree has been created, it is not possible for another branch (e.g. due to arrival of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of already established branches.
There is no QoS (re-)negotiation between network elements (e.g. between RNC and SGSN). This implies that some branches may not be established if QoS requirement cannot be accepted by the concerned network node.
6.4 Temporary Mobile Group Identity
Temporary Mobile Group Identity (TMGI) is used for MBMS notification purpose. The BM-SC allocates a globally unique TMGI per MBMS bearer service. The structure of the TMGI is defined in TS 23.003 [13].
For Multicast MBMS bearer services the TMGI is transmitted to UE via the MBMS Multicast Service Activation procedure. For Broadcast Service the TMGI can be obtained via service announcement see " Service Announcement".
The TMGI is a radio resource efficient MBMS bearer service identification, which is equivalent to the MBMS bearer service identification consisting of IP multicast address and APN.
6.5 IP Multicast distribution
6.5.1 General
For GPRS in GGSN or for EPS in MBMS GW it shall by configuration be possible to enable distribution of MBMS payload by using IP Multicast in the backbone network. IP Multicast distribution is done from GGSN to RNC downstream nodes or from MBMS GW to eNodeB or RNC downstream nodes. The Source Specific Multicast (SSM) service model shall be used by nodes and routers as specified in RFC 4607 [21] and RFC 4604 [22].
6.5.2 IP Multicast distribution for GERAN Iu-mode and UTRAN for GPRS
Fallback to legacy point-to-point distribution is done for RNC nodes which do not support IP Multicast distribution.
NOTE: Support of fallback assumes the corresponding SGSNs have user plane functionality.
The GGSN chooses an IP Multicast address for distribution and a Source address as well as a common TEID-U (C‑TEID). The proposed IP Multicast and Source address for distribution and the C-TEID is indicated by the GGSN to the downstream SGSNs at Session Start. The SGSN forwards the request to the downstream RNC (and BSC in Iu mode) at Session Start. The RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start Response to the SGSN. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in order to join the bearer service multicast distribution. At Session Stop the RNC shall correspondingly report to the backbone in order to leave the bearer service multicast distribution.
If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the GGSN. The SGSN does not respond to the GGSN until it has received responses from all RNCs. The SGSN shall indicate to the GGSN if IP Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point distribution is required (by one or more RNCs). The SGSN will also establish a normal MBMS point-to-point GTP-U tunnel to GGSN if there are BSCs in Gb mode in the MBMS distribution tree.
The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use unicast distribution.
IP Multicast distribution is only used within a PLMN. In the roaming case the GGSN establishes normal MBMS point-to-point GTP-U tunnels to SGSNs/RAN nodes in other networks.
GGSN shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607 [21]. When several GGSN are used for MBMS payload distribution, the used IP Multicast addresses and common TEIDs shall be coordinated by configuration. Clashes between common TEIDs allocated by GGSN and TEIDs allocated by RNC should be avoided by coordinated TEID ranges.
The GTP-U Error Indication mechanism shall be disabled for MBMS bearers using IP Multicast distribution. The receiving node controls itself what is received using the IGMPv3/MLDv2 protocol, RFC 4604 [22].
The MBMS payload with the synchronization information received from the BM-SC included, shall be distributed by the GGSN with IP Multicast to the RNC. The synchronization information is used in the radio interface for the user data transmission synchronization across the RNCs as described in TS 25.346 [10]. It is up to RAN configurations whether the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery.
6.5.3 IP Multicast distribution for E-UTRAN and UTRAN for EPS
The MBMS GW chooses an IP Multicast address for distribution or, optionally, in the case of E-UTRAN access (e.g. in deployments with a mix of IPv4 and IPv6 eNodeBs and/or backhauls) and if the MBMS‑GW supports both IPv4 and IPv6, both an IPv4 and an IPv6 IP Multicast address for distribution. The IP Multicast Addresses may be unique for the MBMS bearer service, or it may be reused from another active MBMS bearer service with an identical service area and of the same QoS. The proposed IP Multicast and Source addresses for distribution is indicated by the MBMS GW to the downstream MMEs and/or SGSNs at Session Start. The MME/SGSN forwards the request to the downstream eNodeB/RNC at Session Start.
In the UTRAN case, the RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start Response to the SGSN. The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in order to join the bearer service multicast distribution. For an IP Multicast address that is shared by several MBMS bearer services, RNC only reports to the backbone once. At Session Stop the RNC shall correspondingly report to the backbone in order to leave the bearer service multicast distribution. For a MBMS bearer service that shares the IP Multicast address with one or more other MBMS bearer service(s), the RNC does only report to the backbone at session stop of the last remaining bearer service that has used a shared IP Multicast address. If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the MBMS GW. The SGSN does not respond to the MBMS GW until it has received responses from all RNCs or until a configurable time has elapsed (e.g. with a recommended default of 5 seconds). The SGSN shall indicate to the MBMS GW if IP Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point distribution is required (by one or more RNCs). The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use unicast distribution.
IP Multicast distribution is only used within a PLMN.
MBMS GW shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607 [21]. When several MBMS GWs are used for MBMS payload distribution, the used IP Multicast addresses shall be coordinated by configuration. Clashes between common TEIDs allocated by MBMS GW and TEIDs allocated by eNodeB/RNC should be avoided by coordinated TEID ranges.
The receiving node controls itself what is received using the IGMPv3/MLDv2 protocol RFC 4604 [22].
The MBMS payload with the synchronization information received from the BM-SC shall be distributed by the MBMS GW with IP Multicast to the eNodeB/RNC. The synchronization information is used in the radio interface for the user data transmission synchronization across the eNodeBs and RNCs as described in TS 25.346 [10]. It is up to RAN configurations whether the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery.
Mobility between cells may cause limited MBMS data loss towards the UE. Therefore, MBMS user services should be able to cope with potential data loss caused by UE mobility.