An Updated Tutorial is available here. Please click here if not redirected in 10 seconds
Introduction
Point to multipoint services exist today which allow data from a single source entity to be transmitted to multiple endpoints. These services are expected to be used extensively over wireless networks, hence there is a need for a capability in the PLMN to efficiently support them. The Multimedia Broadcast/Multicast Service (MBMS) will provide this capability for such broadcast/multicast services provided by the home environment and other VASPs.
MBMS is an IP datacast (IPDC) service that can be offered via exsiting UMTS and GSM networks. It would be possible for the user to interact with this service via an uplink channel. This feature causes this service to be more complicated as it is not as straightforward as a Unicast service like conventional digital telivision.
MBMS is a UMTS release 6 feature and according to [1] it is already very popular with operators and equipment manafacturers. It is expected that Networks would be supporting MBMS by Q4, 2007 while UE's will be supporting MBMS by Q2, 2008. As per [1], 30% of UE's will be supporting MBMS by 2010. Release 6 was finalised in June 2005.
It is important to note that MBMS is not just a technology to preserve capacity or reduce costs - by providing an efficient means to reliably distribute multimedia content over 3G networks but also an opportunity for 3G network operators to deliver new and innovative revenue-generating services to their subscribers.
Difference between Broadcast and Multicast
| BROADCAST | MULTICAST |
|---|---|
| Broadcast service is a unidirectional point-to-multipoint service in which data is transmitted from single source to multiple UE's in the associated broadcast area | Muticast service is a unidirectional point-to-multipoint service in which data is transmitted from single source to Multicast group in associated Multicast area. |
| These are push type services. The end user does not have to subscribe to be part of broadcast group | The end user has to be part of Multicast group to receive them. |
| No interaction possible | Interaction possible. In this case multicast users have a return channel for the interaction procedure. |
| They are free | They could be free or paid type. |
Broadcast and Multicast before Release 6
To date, the following services (defined in R99 and R4) are available:
- A cell broadcast service (CBS) [15, 16] allowing for low bit-rate data to be transmitted to all subscribers in a set of given cells over a shared broadcast channel. This service offers a message-based service
- An IP-Multicast service [13, 14] allowing for mobile subscribers to receive multicast traffic. This service does not allow for multiple subscribers to share radio or core network resources and as such does not offer any advantages as far as resource utilization within the PLMN and over the radio access network.
General Description of MBMS [2]
3GPP has defined two modes of operation of MBMS
- the broadcast mode
- the multicast mode
MBMS broadcast mode
The broadcast mode is a unidirectional point-to-multipoint transmission of multimedia data (e.g. text, audio, picture, video) from a single source entity to all users in a broadcast service area. The broadcast mode is intended to efficiently use radio/network resources e.g. data is transmitted over a common radio channel. Data is transmitted in the broadcast service area as defined by the network (Home environment). MBMS data transmission should adapt to different RAN capabilities or different radio resource availability, e.g. by reducing the bitrate of the MBMS data.
Figure above gives an example of how a network can be configured to broadcast a variety of high bit rate services to users within the associated broadcast service area. A broadcast service received by the UE, involves one or more successive broadcast sessions. A broadcast service might, for example, consist of a single on-going session (e.g. a media stream) or may involve several intermittent sessions over an extended period of time (e.g. messages).
The difference between the CBS of R99 and Broadcast of R6 is that CBS is used for low bit rate services (messaging) while the broadcast mode enables the broadcast of multimedia services (Audio, Video etc).
An example of a service using the broadcast mode could be advertising or a welcome message to the network. As not all users attached to the network may wish to receive these messages then the user shall be able to enable/disable the reception of these broadcast service on his UE. The broadcast mode differs from the multicast mode in that there is no specific requirement to activate or subscribe to the MBMS in broadcast mode.
The broadcast mode should allow terminals to minimise their power consumption. It is expected that charging data for the end user will not be generated for this mode. The reception of the traffic in the broadcast mode is not guaranteed. The receiver may be able to recognize data loss.
MBMS multicast mode
The multicast mode allows the unidirectional point-to-multipoint transmission of multimedia data (e.g. text, audio, picture, video) from a single source point to a multicast group in a multicast service area. The multicast mode is intended to efficiently use radio/network resources e.g. data is transmitted over a common radio channel. Data is transmitted in the multicast service area as defined by the network (Home environment). In the multicast mode there is the possibility for the network to selectively transmit to cells within the multicast service area which contain members of a multicast group. MBMS data transmission should adapt to different RAN capabilities or different radio resource availability, e.g. by reducing the bitrate of the MBMS data.
A multicast service received by the UE, involves one or more successive multicast sessions. A multicast service might, for example, consist of a single on-going session (e.g. a multimedia stream) or may involve several intermittent multicast sessions over an extended period of time (e.g. messages). An example of a service using the multicast mode could be a football results service for which a subscription is required.
Unlike the broadcast mode, the multicast mode generally requires a subscription to the multicast subscription group and then the user joining the corresponding multicast group. The subscription and group joining may be made by the PLMN operator, the user or a third party on their behalf (e.g. company). Unlike the broadcast mode, it is expected that charging data for the end user will be generated for this mode.
Reception of multicast services cannot be guaranteed over the access network. For many applications and services guaranteed data reception may be carried out by higher layer services or applications which make use of MBMS. Multicast mode should allow terminals to minimise their power consumption.
The multicast mode defined in this specification should not be confused with IP Multicast (discussed above). There are similarities between these two services and such similarities may be exploited in 3GPP networks given that 3GPP multicast mode has been defined with consideration to maximizing efficiency on the radio interface and of network resources.
Multicast mode shall be inter-operable with IETF IP Multicast. This could allow the best use of IP service platforms to help maximize the availability of applications and content so that current and future services can be delivered in a more resource efficient manner. Figure above shows a general high level overview of multicast mode network.
MBMS Architecture [4, 5]
The MBMS architecture is based on the following principles:
- MBMS architecture shall enable the efficient usage of radio-network and core-network resources, with the main focus on the radio interface efficiency. Specifically, multiple users should be able to share common resources when receiving identical traffic.
- The MBMS architecture shall support common features for MBMS multicast and broadcast modes, e.g. both modes shall preferably use the same low-layer bearer for data transport over the radio interface.
- The MBMS architecture does not describe the means by which the BM-SC obtains the service data. The data source may be external or internal to the PLMN e.g content servers in the fixed IP network, any UE attached to the PLMNMBMS shall support both IP multicast and IP unicast sources.
- MBMS architecture should re-use, to the extent possible, existing 3GPP network components and protocol elements thus minimizing necessary changes to existing infrastructure and providing a solution based on well-known concepts.
- MBMS shall be a point-to-multipoint bearer service for IP packets in the PS domain.
- MBMS shall be interoperable with IETF IP Multicast.
- MBMS shall support IETF IP Multicast addressing.
- It shall be possible for UEs to receive MBMS when the terminal is attached.
- It shall be possible for UEs to receive MBMS data in parallel to other services and signalling (e.g. paging, voice call).
- MBMS shall support different quality of service levels. The mechanisms for this are for further study, one example is repetitions to all users.
- MBMS service areas shall be defined per individual service with a per cell granularity.
- MBMS is not supported in the CS domain.
- When the UE is already receiving data of an MBMS service, it shall be possible for the UE to be notified about a forthcoming and potentially about an ongoing data transfer from other MBMS services.
- Charging data shall be provided per subscriber for MBMS multicast mode .
- The MBMS bearer service concept should contain the decision making process for selection of point-to-point or point-to-multipoint configurations.
- The architecture should be able to provide home MBMS multicast services to users when roaming outside their home network as subject to interoperator agreements.
- MBMS should be designed to minimise power consumption within the mobile station.
- Applications shall be tolerant to packet loss and duplication caused by e.g. UE mobility or transmission loss.
- The backwards compatibility of the MBMS service to the R99 IP multicast delivery mechanism shall be considered. Interworking possibilities between MBMS capable network elements and non-MBMS capable network elements (e.g. interworking with R99 IP Multicast service GGSNs) shall be described.
- The MBMS standard should avoid placing excessive signalling load requirements on the network. In particular, the MBMS standard should permit operators to configure their networks so that when a UE, which is not actually receiving a media stream, changes between GSM and UMTS cells in the same Routeing Area, there is no significant signalling traffic load on the network.
MBMS Architecture
MBMS Architecture is as shown above. The dotted lines means functions / reference points that are optional. Gp applies only when SGSN and GGSN are in different PLMN.
SGSN: In the MBMS architecture the SGSN performs user individual service control functions and the SGSN concentrates all individual users of the same MBMS service into a single MBMS service. The SGSN maintains a single connection with the source of the MBMS data.
GGSN: The GGSN terminates the MBMS GTP tunnels from the SGSN and links these tunnels via IP multicast with the MBMS data source.
BM-SC: The BM-SC is an MBMS data source. MBMS data may be scheduled in the BM-SC, e.g. for transmission to the user every hour. It offers interfaces over that content provider can request data delivery to users. The BM-SC may authorise and charge content provider.
MBMS Data Sources: The architecture allows for other MBMS broadcast/multicast data sources. Internal data sources may directly provide their data. Data delivery by external sources is controlled by Border Gateways (BG) which may allow for example data from single addresses and ports to pass into the PLMN for delivery by an MBMS service.
Optional Network Elements:
- The SGSN may use CAMEL to handle pre-paid services, e.g. credit checking for on-line charging.
- The Cell Broadcast Centre (CBC) may be used to announce MBMS services to the users. How this is accomplished is FFS.
- The BM-SC might use OSA-SCS to interact with third parties.
RAN MBMS Requirements
The following RAN requirements have been identified [7]:
- MBMS data transfer shall be downlink only.
- QoS attributes shall be the same for MBMS Multicast and Broadcast modes.
- During MBMS data transmission it shall be possible to receive paging messages, which also should contain some additional information, such as CLI.
- Simultaneous reception of MBMS and non-MBMS services shall depend upon UE capabilities.
- Simultaneous reception of more than one MBMS services shall depend upon UE capabilities.
- A notification procedure shall be used to indicate the start of MBMS data transmission. This procedure shall contain MBMS RB information.
- A mechanism to enable the Network to move MBMS subscribers between cells is required.
- MBMS UE multicast activation (Joining) shall be transparent to UTRAN.
- A mechanism is required that enables the non-transmission of MBMS multicast mode in a cell which does not contain any MBMS UEs joined to the multicast group.
- Reception of MBMS shall not be guaranteed at RAN level. MBMS does not support individual retransmissions at the radio link layer, nor does it support retransmissions based on feedback from individual subscribers at the radio level. This does not preclude the periodic repetitions of the MBMS content based on operator or content provider scheduling or retransmissions based on feedback at the application level.
- MBMS shall not prevent the capability for SRNS/SBSS relocation.
- A mechanism to provide UTRAN the received QoS per UE is not required as part of MBMS.
- UE controlled "service based" cell selection/reselection shall not be permitted.
- Handover and SGSN relocation shall not be affected by an active MBMS session.
- In the case of UTRAN only, guaranteed 'QoS' linked to a certain initial downlink power setting is not required; however, the purpose and possibility of some reporting mechanism could be identified to measure the delivered QoS.
- MBMS Multicast mode transmissions should use dedicated resources (p-t-p) or common resources (p-t-m). The selection of the connection type (p-t-p or p-t-m) is operator dependent, typically based on downlink radio resource environment such as radio resource efficiency. A "threshold" related to the number of users may be utilised, resulting in the need for a mechanism to identify the number of subscribers in a given "area".
- MBMS solutions to be adopted should minimise the impact on the RAN physical layer and maximise reuse of existing physical layer and other RAN functionality.
- MBMS charging should be transparent to the RAN.
- MBMS should allow for low UE power consumption.
- Header compression should be used.
- MBMS should not prevent support for SGSN in pool.
- Data loss during cell change should be minimal.
The following MBMS Notification Requirements have been identified:
- MBMS notification shall be transmitted within the MBMS service area.
- MBMS notification shall be sent so it could be received by all UEs with an activated MBMS service, regardless of their RRC state or the lack of an RRC connection.
- MBMS notification should maximise the reuse of existing channels.
- MBMS notification should allow terminals to minimise their power consumption, meaning that UEs with an activated MBMS service should not listen permanently, but at regular intervals to MBMS notification.
- Reception of MBMS notification cannot be guaranteed.
- UEs may receive MBMS notification and simultaneously monitor other occasions, e.g. UE dedicated paging and CBS messages. The avoidance of collisions cannot be guaranteed. If collisions occur, the UE dedicated Paging has higher priority (UE requirement).
MBMS Services [3]
MBMS User Services are classified according to the method used to distribute these services. There are three types of MBMS User Service considered within 3GPP:
- Streaming services: A continuous data flow providing a stream of continuous media (i.e. audio and video) is a basic MBMS User Service. Like digital video broadcasting, supplementary information of text and/or still images (static media) is also important. For example, if text includes URLs of some content on the Internet, a user can easily access the content without entering the URL for herself. Still images may also be used for banner images that advertise some product or service. These static media need to be synchronized and displayed with audio/video streams.
- File download services: This service delivers binary data (file data) over an MBMS bearer. An MBMS client (i.e. UE) activates an appropriate application, and utilises the delivered data. The most important functionality for this service is reliability. In other words, it is necessary that the user receive all the data sent in order to experience the service.
- Carousel services: Carousel is a service that combines aspects of both the Streaming and File download services described above. Similar to the streaming service this service includes time synchronisation. However, the target media of this service is only static media (e.g. text and/or still images). Time synchronization with other media is also required. For example, text objects are delivered and updated from time to time. Still images may also be collated to display low frame-rate video. In common with the download service this service also includes reliability (typically 100% reliability is not always necessary). The benefit of this service is that it is possible over a low bit-rate bearer. An example of an application utilising the Carousel service is a 'ticker-tape' type service in which the data is provided to the user repetitively and updated at certain times to reflect changing circumstances.
Some example service scenarios for MBMS User services are as follows:
Text notification service
Media: Text
Precondition: The user is a member of a MBMS Multicast group supplying text alerts.
Actions: At an appropriate time an alert is sent to the user's mobile handset using the MBMS Multicast service.
Post condition: The user receives the alert using her mobile handset and takes appropriate action.
Local Area Information distribution (Scenario 1)
Media: Text & Text with low quality video
Precondition: The user is a registered with an MBMS Broadcast service providing information to the local area such as local news and weather reports.
Actions: Information in the form of text & text with low quality video is distributed to the user's mobile handset by the MBMS Broadcast service. The text may be scrolled on the mobile handset. The information distributed by the MBMS Broadcast Service may be repeated periodically and updated at appropriate intervals.
Post condition: The user is aware of events that have taken place within the local area and can view appropriate images.
Local Area Information distribution (Scenario 2)
Media: Video & Audio
Precondition: The user is a registered with an MBMS Broadcast service providing streaming audio and/or visual content related to a local area, such as audio and visual guides to local attractions, traffic reports etc…
Actions: Audio and/or visual information is distributed to the user's mobile handset by the MBMS Broadcast service. The user is able experience the content on her mobile device. The user is able to receive the MBMS broadcast service continuously throughout the local area. At some points the user is able to interact with the content of the MBMS Broadcast service in order to access specific information regarding items being presented within the content. The user is able to activate/deactivate reception of the MBMS service at any time.
Post condition: The user experiences and interacts with the content provided and is therefore able to obtain information regarding the local area and act accordingly.
Multicast distribution
Media: Text & Text with still images
Precondition: The user is a member if a MBMS multicast group providing personally tailored content such as targeted advertising etc…
Actions: Information is provided by the MBMS Multicast service in the form of text & text with still images, to the user's mobile handset based on her subscription to the Multicast group and current location.
Post condition: The user receives tailored content and is able to utilize this as appropriate.
Audio Distribution
Media: Stereo Audio
Precondition: The user is registered with an MBMS Broadcast service providing stereo quality streaming audio content.
Actions: Audio content is distributed to the user's mobile handset by the MBMS Broadcast service. Whilst listening to the audio content the user is able to interact with the service using the capabilities of the mobile handset (e.g. messaging).
Post condition: The user is able to enjoy the stereo quality audio content and interacts with the service as appropriate.
Software Download
Media : File
Preconditions :Need to update/download software in UE, the User is subscribed to MBMS User Service, OTA download is supported in UE
Actions: The operator compiles a list of affected users and sends them a text message (using MBMS) explaining the problem and that the user should select the MBMS application on their handset. The user sees a message inviting her to activate the Enable Upgrade, selects 'yes' and the software patch transferred by the MBMS User Service, including verification parameters.
Postcondition :The software once installed allows the user to view the MMs that she couldn't see before.
MBMS Channel Structure
There exists two transmission modes to provide the MBMS service:
- Point-to-point transmission (p-t-p/PTP)
- Point-to-multipoint transmission (p-t-m/PTM)
Figure above [17] shows an example scenario where one cell uses p-t-m while an other cell has only one joines UE which is kept in p-t-p state. From the MBMS operation point of view, procedures are obviously simpler if the content is always provided in a point-to-multipoint manner without shifting users back and forth between different states.
Point-to-Point Transmission
Point-to-point transmission is used to transfer MBMS specific control/user plane information as well as dedicated control/user plane information between the network and one UE in RRC Connected Mode. It is used only for the multicast mode of MBMS.
For a UE in CELL_FACH and Cell_DCH, DCCH or DTCH is used, allowing all existing mappings to transport channels.
Point-to-multipoint Transmission
Point-to-multipoint transmission is used to transfer MBMS specific control/user plane information between the network and several UEs in RRC Connected or Idle Mode. It is used for broadcast or multicast mode of MBMS.
Logical Channels
MBMS point-to-multipoint Control Channel (MCCH):
This logical channel is used for a p-t-m downlink transmission of control plane information between network and UEs in RRC Connected or Idle Mode. The control plane information on MCCH is MBMS specific and is sent to UEs in a cell with an activated (joined) MBMS service. MCCH can be sent in S-CCPCH carrying the DCCH of the UEs in CELL_FACH state, or in standalone S-CCPCH, or in same S-CCPCH with MTCH. The MCCH is always mapped to one specific FACH in the S-CCPCH as indicated on the BCCH. If MCCH is the only logical channel mapped in to the FACH, the absence of the TCTF field is explicitly signalled otherwise the TCTF field is used in MAC header to identify MCCH logical channel type. In case of soft combining, the MCCH is mapped to a different S-CCPCH (CCTrCH in TDD) than MTCH. Reception of paging has priority over reception of MCCH for Idle mode and URA/CELL_PCH UEs.
MBMS point-to-multipoint Traffic Channel (MTCH):
This logical channel is used for a p-t-m downlink transmission of user plane information between network and UEs in RRC Connected or Idle Mode. The user plane information on MTCH is MBMS Service specific and is sent to UEs in a cell with an activated MBMS service. The MTCH is always mapped to one specific FACH in the S-CCPCH as indicated on the MCCH. The TCTF field is always used in MAC header to identify MTCH logical channel type.
MBMS point-to-multipoint Scheduling Channel (MSCH):
This logical channel is used for a p-t-m downlink transmission of MBMS service transmission schedule between network and UEs in RRC Connected or Idle Mode. The control plane information on MSCH is MBMS service and S-CCPCH specific and is sent to UEs in a cell receiving MTCH. One MSCH is sent in each S-CCPCH carrying the MTCH. The MSCH is always mapped to one specific FACH in the S-CCPCH as indicated on the MCCH. Due to different error requirements the MSCH is mapped to a different FACH than MTCH. If MSCH is the only logical channel mapped in to the FACH, the absence of the TCTF field is explicitly signalled otherwise the TCTF field is used in MAC header to identify MSCH logical channel type.
Transport Channel
FACH is used as a transport channel for MTCH, MSCH and MCCH.
Physical Channel
SCCPCH is used as a physical channel for FACH carrying MTCH or MCCH or MSCH.
Mapping between channels
Only in downlink, the following connections between logical channels and transport channels exist:
- MCCH can be mapped to FACH
- MTCH can be mapped to FACH
- MSCH can be mapped to FACH
The mappings as seen from the UE and UTRAN sides are shown in Figure a and Figure b below respectively [6]:
Figure a: Logical channels mapped onto transport channel, seen from the UE side
Figure b: Logical channels mapped onto transport channel, seen from the UTRAN side
Data Flows through Layer 2
Data flow for MCCH mapped to FACH:
For MCCH, the RLC mode to be employed is UM-RLC, with required enhancements to support out of sequence SDU delivery. A MAC header is used for logical channel type identification.
Data flow for MTCH mapped to FACH
For MTCH, the RLC mode to be employed is UM-RLC, with required enhancements to support selective combining. Quick repeat may be used in RLC-UM. A MAC header is used for logical channel type identification and MBMS service identification.
Data flow for MSCH mapped to FACH:
For MSCH, the RLC mode to be employed is UM-RLC. A MAC header is used for logical channel type identification.
MBMS Notification Indicator Channel
MBMS notification utilizes a new MBMS specific PICH called the MBMS Notification Indicator Channel (MICH) in each cell.
MBMS Signalling Examples
MBMS Service Activation
The following scenario gives an example message flow for UE joining an MBMS service. The example chosen is the one where the UE is in DRNC in state Cell-DCH receiving possible other services. This is the first UE joining the MBMS service in SRNC and DRNC.
- UE performs NAS procedure for MBMS Service Activation or having activated the service previously goes into PMM connected state. UE is in a cell in the DRNC. There is no MBMS context for this service in the DRNC.
- The Core Network initiates the MBMS UE Linking procedure by sending RANAP MBMS UE Linking Request message to provide the SRNC with the list of MBMS Service Ids activated by this UE. (Parameters: TMGIs, PTP RB id)
- RNC sends an RANAP MBMS UE Linking Response message to Core Network after RNC updates the MBMS Service Context.
- As the SRNC has no MBMS context for this service, it does not know the IP Multicast address or APN for this service. The SRNC request these from the SGSN using the connectionless RANAP Uplink Information Exchange Request message. (Parameters: TMGI.)
- SGSN responds with RANAP Uplink Information Exchange Response message. (Parameters: TMGI, IP Multicast Address and APN.)
- UE linking in the DRNC is performed using the RNSAP MBMS Attach Command message over the Iur interface. (Parameters: TMGIs)
- As the DRNC has no MBMS context for this service, it does not know the IP Multicast Address and APN for this service. The DRNC request these from the SRNC using the connectionless RNSAP Information Exchange Initiation Request message. (Parameters: MBMS Bearer Service List)
- SRNC responds with RNSAP Information Exchange Initiation Response message (Parameters: TMGI, IP Multicast Address and APN)
- An MBMS Service Context for the service is created in the DRNC.
- The DRNC informs the Core Network that it would like to receive MBMS Session Start Request messages by sending an RANAP MBMS Registration Request message. (Parameters: Registration Request type, TMGI, IP Multicast Address, APN, Global RNC id.)
- Core Network replies with an RANAP MBMS Registration Response message.
MBMS Session Start
The following is an example scenario for an MBMS Session Start. The RNC decides to perform counting and offer the service over PTM bearer. The UE is receiving a lower priority MBMS service over a PTP bearer. The UE capability does not allow reception of PTP and PTM bearers simultaneously.
- When the MBMS session starts the SGSN informs all RNCs that is connected to this SGSN of the availability of data and requests the establishment of the User plane bearer using RANAP MBMS Session Start message . This also establishes the SCCP connection for the MBMS service. (Parameters: TMGI, Session id, Repetition number, Bearer Service type, Iu signaling connection id, RAB parameters, PDP type, Session Duration, Service Area, Frequency layer convergence flag, RA list of idle mode UEs, Global CN-id)
- The RNC responds with an RANAP MBMS Session Start Response message. Since there are UEs in this RNC that have joined the service, it sets up the RAB for the MBMS service. (Parameters: Iu transport layer information)
- CRNC updates the MICH using NBAP MBMS Notificaiton Update Command. This message is updated for every change in MICH. (Parameters: C-ID, Common Physical Channel ID, Modification Period, MICH CFN, NI Information.)
- RNC is in the Service Area for the service. The RNC notifies the UE(s) about the start of the MBMS service by updating the RRC MBMS Modified Services Info message on the MCCH. This is sent on DCCH for UEs in Cell-DCH and on MCCH for other UEs. (Parameters: TMGI, Session id, UE action required, MBMS preferred frequency, Continued MCCH reading)
- RNC takes a decision to perform UE counting in order to evaluate what is the optimal method for MBMS delivery.
- RNC requests UE to set up PMM connection using RRC MBMS Access Info message on MCCH. (Parameters: TMGI and probability factor.)
- A fraction of (or all) UEs who have joined the MBMS service establishes PMM connection towards CN. UE linking is done by the CN when Iu-ps connection is established for these UEs.
- After counting, CRNC has enough information to make PTP/PTM decision. In this scenario there were enough UEs to exceed the threshold to justify ptm transmission.
- The CRNC establishes the S-CCPCH and FACH which will carry the MTCH by using the Common Transport Channel Setup procedure.
- CRNC informs UE of the MTCH channel used for the MBMS service in the cell and its neighbouring cells using the RRC MBMS Common P-T-M RB Info, MBMS Current Cell P-T-M RB Info, MBMS Neighbouring Cell P-T-M RB Info messages on MCCH. (Parameters: TMGI, MBMS UTRAN Cell Group Identifier, logical channel, transport channel, physical channel information, MSCHInformation per MBMS service.)
- UE is receiving a lower priority MBMS service on a PTP bearer. UE capability does not allow reception of a PTP and PTM bearer simultaneously.
- UE requests the release of the PTP bearer for the other lower priority service using RRC MBMS Modification Request message. (Parameters: RB to be released.)
- RNC releases the PTP RB of the other lower priority MBMS service.
- MBMS data transmission for this service on the PTM bearer.
- RNC may request the release of the Iu connection for the UEs that were moved to PMM connected state during the counting process.
References
[1] TeliaSonera: Multimedia Broadcast/Multicast services (MBMS) White Paper (August 2004)
[2] 3GPP TS 22.146 - Multimedia Broadcast/Multicast Service; Stage 1 (Release 6)
[3] 3GPP TS 22.246 - Multimedia Broadcast/Multicast Service (MBMS) user services; Stage 1 (Release 6)
[8] 3GPP TS 26.346 - Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6)
[9] Nokia: Multicast in UMTS; 83390 Advanced Topics in Broadband Networks
[11] Nokia White Paper: IP Datacast Terminals – Description of Implementation Principles
[13] 3GPP TS 22.060: "General Packet Radio Service (GPRS); Service description; Stage 1".
[14] 3GPP TS 23.060: “General Packet Radio Service (GPRS); Service description; Stage 2"
[15] 3GPP TS 25.324: “Broadcast/Multicast Control BMC”
[16] 3GPP TS 23.041: “Technical Realization of Cell Broadcast Service (CBS)”