Method of providing a multicast/broadcast, mbms, service in a mobile telecommunications network

BACKGROUND OF THE INVENTION

<u>Field of the Intention</u>

0001This invention relates to a broadcast or multicast service in a telecommunications system. More explicitly, but not exclusively, the invention relates to the realisation of a Multicast Broadcast services in a radio access network (RAN) such as in the Universal Mobile Telecommunications Service (UMTS) radio access network in regard of Scheduling information for a Multimedia Broadcast/Multicast Service (MBMS). UMTS concerns a third generation radio network using wideband code division multiple access (W-CDMA) technology.

<u>Background Art</u>

0002A cellular communications system includes mobile user equipment (UEs), a radio access network (RAN) and one or more core networks (CNs), as illustrated in <figref idref="f0001">Figure 1</figref> for the UMTS case. A detailed overview over the architecture of a cellular telecommunications system of the third generation may be found in the 3GPP specification "UTRAN Overall Description" 3GPP TS25.401 and related specifications. Communication between the Ues 1 and the UTRAN 3 is provided via the Uu interface (Uu), whereas the communication between the UTRAN and the core networks 5 is done via the Iu interface (Iu).

0003A radio access network includes base stations and radio network controllers or base station controllers (RNC/ BSC). The base stations handle the actual communication across the radio interface, covering a specific geographical area also referred to as a cell. The radio network controllers control the base stations connected to it, but in addition perform other functionality like for example the allocation of radio resources and the control of local mobility. An RNC connects to one or more core networks via the Iu interface, to a number of base stations (node B's for the case of UTRAN) via the Iub interface and possibly to one or more other RNCs via the Iur interface. The core network includes a serving GPRS (General Packet Radio Service) support node (SGSN) and a broadcast/multicast - service centre (BM-SC). The BM-SC controls the distribution of the data to be transmitted via the MBMS service.

0004Communications Networks of the third generation (3G) such as the UMTS network provide Multimedia Broadcast Multicast Services (MBMS). MBMS is a point-to-multipoint service in which multimedia data such as audio, images or video data is transmitted from a single source entity to multiple recipients by using an uni-directional bearer service. The MBMS bearer service offers both a broadcast mode and a multicast mode. In the broadcast mode, the data are broadcasted to all users. In contrast, a user needs to subscribe to a particular MBMS service or a group of MBMS services with a service provider in order to receive multicast services. The operator may then announce the service or use a service discovery mechanism to inform users about the range of MBMS services available. If the user is interested in a particular MBMS service, the user joins the service, i.e. the user activates the MBMS multicast service. In this way the user becomes a member of a particular multicast group and indicates to the network that he or she wants to receive the MBMS data of a particular MBMS service.

0005The area in which a specific MBMS Bearer Service is available is referred to as the MBMS Service Area, or the MBMS Multicast (MC)-service area It is defined individually per MBMS Bearer Service, i.e. the MBMS service area is MBMS service specific. Such a MBMS service area consists of a number of cells. An MBMS MC-service area might not have any relation to other area of the network, such as the UTRAN Registration Areas (URA's), Routing Areas (RAs) or Location Areas (LAs). Thus, an MBMS MC-service area may consist of some cells of a URA, RA or LA, without necessarily including all cells of that URA, RA or LA.

0006More information regarding MBMS realisation in the UTRAN may be found in the corresponding stage-2 document "Introduction of Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN)", TS 25.346.v2.6.0.

0007Transmitting the same data to multiple recipients allows network resources to be shared. In this way the MBMS architecture is designed to enable an efficient usage of radio-network and core-network resources.

0008In order to initiate a MBMS session, the CN sends a session start command to the RNC. The Session Start command is used to indicate that the core network is ready to send data relating to a particular MBMS service. The Session Start command triggers the establishment of a bearer resource for MBMS data transfer. It is noted that the Session Start occurs independently of activation of the service by the user. This means that a user may activate a particular service either before or after a Session Start.

0009After receiving the Session Start command, the RNC send MBMS notifications to the UE in order to inform the UEs about forthcoming or even ongoing MBMS multicast data transfers. The RNC manages the use of the radio resources and decides whether the MBMS data will be transmitted using point to multipoint or point-to-point transfer mode on the radio interface. If there are sufficient UEs in a cell, the point-to-multipoint transfer mode is most efficient. If however the number of users in a cell is low, the point-to-point transfer mode may be most efficient. To decide which transfer mode to use, the RNC may perform a counting operation. Subsequently multimedia data relating to a particular MBMS service are transmitted from the CN via the RNC to the UEs during the data transfer phase.

0010When the BM-SC determines that there will be no more data to send, the CN sends a Session Stop command to the RNC and the bearer resources are released

0011If a user is no longer interested in a particular MBMS service, the user deactivates the service. Accordingly, the user leaves the multicast group if he or she does no longer wants to receive Multicast mode data of a specific MBMS bearer service.

0012It is noted that the phase subscription, joining and leaving are performed individually per user. The other phases, such as the notification and the data transfer, are performed for a particular service, i.e. for all users interested in the related service.

0013As of 3GPP RAN2 meeting number 41 (16-20 February 2004), the situation regarding how MBMS will be handled on the Uu interface has again become clearer. The current status of MBMS realisation in RAN2 is described in the 3GPP specification "Introduction of Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN)" TS 25.346 (v2.6.0).

0014During RAN2 meeting number 41, it was decided that there will be MBMS scheduling information provided on an secondary Common Control Physical Channel (SCCPCH), and that this scheduling information would concern the MBMS services provided on this SCCPCH.

0015Currently, scheduling information is already provided on the GSM/UMTS radio interface for the Cell Broadcast Service (CBS). Like MBMS, CBS is also a broadcast type of service (point-to-multipoint transmission). However CBS is restricted to much lower rates as MBMS and is focussed on text based services.

0016CBS is specified in the 3GPP specification "Short Message Service Cell Broadcast (SMSCB); support on the mobile radio interface for GSM" (TS 44.012), and 3GPP specification "Broadcast/Multicast Control (BMC) for UMTS" (TS 25.324).

0017One possibility to implement the scheduling for the MBMS service would be to apply a scheduling procedure in analogy to that described for the CBS service.

0018For the CBS service (see the specifications TS 44.012 and TS 25.324 for more details), it is exactly described which messages (based on message ids) are going to be sent in timeslots in the coming period. In UMTS, the maximum time period is described to be 2.56 seconds. The messages to be transmitted are indicated by message identifications (message Ids).

0019A straightforward application of the CBS approach would be to signal in the scheduling message which services are going to be provided within a certain time period. This time period can for example be determined to be the next 50 System Frame numbers (SFNs).

0020<patcit id="pcit0001" dnum="WO2004017540A"><text>WO 2004/017540 A</text></patcit> relates to the scheduling of the transmission of MBMS data in UMTS. When a UTREN provides an MBMS service, it designates a time at which each data for MBMS service is transmitted and transmits the corresponding time information to a terminal group which desires to receive a specific MBMS service. Accordingly, a terminal of the terminal group receives the MBMS service data during a section of the corresponding time information and also receives a control signal or other service than the MBMS service at another time. A broadcast/multicast control (BMC) layer performs functions of scheduling a cell broadcast message (CB) transferred from the core network and broadcasting the CB to UEs positioned in a specific cell. The CB message transferred from the upper layer is combined with information such as message ID, serial number or coding scheme and transfer in a form of the MC message to the RLC layer and to the MAC layer through a CTCH.

0021<patcit id="pcit0002" dnum="EP1180862A"><text>EP1180862</text></patcit> relates to accessing additional services broadcasted besides a main service. In digital broadcast systems, it is common to broadcast besides main services additional services like news services. These additional services are regularly updated and broadcasted by a service provider several times a day. In order to keep service data transmitted by the additional services up to date in a receiving device receiving the services, a method of accessing services is given according to which a respective service information about the services provided by service providers is extracted from a service presently received by the receiving device, and then at least one of the services about which service information was extracted according to the respective extracted service information might be accessed. Thus, the service data can automatically be updated by the receiving device itself, even if transmission conditions of an additional service like update rates change over the time.

0022It is the object of the present invention to provide an improved scheduling method. This object is solved by the subject matter of the independent claim 1. Preferred embodiments are described in the dependent claims.

0023According to one embodiment of the present invention, there is provided a method of providing a multicast and/or broadcast service in a mobile communications network, including transmitting data for a multicast and/or broadcast service from a network node to a mobile terminal, wherein transmission times for transmitting data relating to the service are scheduled and wherein scheduling information is transmitted from a network node to a mobile terminal, and wherein transmission of at least some of said data is delayed so that data relating to said service are grouped together before transmission.

0024According to another embodiment of the present invention, there is provided a method of providing multicast and/or broadcast services in a mobile communications network, wherein transmission times for the service are scheduled and scheduling information including the start times of the transmission related to a particular multicast and/or broadcast service is transmitted from a network node to a mobile terminal.

0025According to another embodiment of the present invention, there is provided a method of providing multicast and/or broadcast services in a mobile communications network, wherein transmission times for the services are scheduled and scheduling information is transmitted from a network node to a mobile terminal, and wherein the transmission periods covered by the scheduling information are specific to a particular multicast and/or broadcast service.

0026According to another embodiment of the present invention, there is provided a method of providing a multicast and/or broadcast service in a mobile communications network, wherein transmission times for the service are scheduled and scheduling information is transmitted from a network node to a mobile terminal, and wherein the scheduling information is provided according to a predefined schedule.

0027According to another embodiment of the present invention, there is provided a method of providing multicast and/or broadcast services in a mobile communications network, wherein transmission times for the services are scheduled and scheduling information is transmitted from a network node to a mobile terminal, and wherein scheduling information for different multicast and/or broadcast services provided on one channel is grouped together.

0028According to yet another embodiment of the present invention, there is provided a method of providing a multicast and/or broadcast service in a mobile communications network, wherein transmission times for the service are scheduled and scheduling information is transmitted from a network node to a mobile terminal, and wherein data related to said multicast and/or broadcast service to be transmitted from a network node to a mobile terminal are grouped together before transmission.

<u>Brief Description of Drawings</u>

0029Embodiments of the present invention will now be described, by example only, with reference to the accompanying figures, whereby: <ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">Figs. 1 and 2</figref> are schematic outlines of a mobile communications network, in which the present invention can be incorporated;</li><li><figref idref="f0002">Figs. 3A and B</figref> are schematic diagrams illustrating a first scheduling approach for a multicast and/or broadcast service according to the prior art and a second scheduling approach according to one embodiment of the present invention;</li><li><figref idref="f0003">Fig. 4</figref> is a schematic diagram illustrating the scheduling approaches for three different multicast and/or broadcast services incorporating different embodiments of the present invention; and</li><li><figref idref="f0004">Figure 5</figref> is a schematic diagram illustrating the scheduling approaches for six different multicast services incorporating yet different embodiments of the present invention.</li></ul>

<u>General Description</u><u>of the Invention</u>

0030<figref idref="f0001">Figure 2</figref> illustrates the architecture of a radio access network. The RAN comprises base stations 2, such as the so-called Node B's for the UTRAN, and radio network controllers 4 (RNC), also referred to as base station controllers (BSC). The base stations 2 handle the actual communication across the radio interface, covering a specific geographical area also referred to as a cell. The RNCs 4 control the base stations 2 connected to it, and also include other functionality for tasks such as the allocation of radio resources, i.e. the local mobility. The Radio Network Subsystem 6 (RNS) include An RNC 4 and base stations 2. An RNC 4 is connected to one or more core networks 8 via the Iu interface 12, to a number of base stations 2 via the Iub interface 10 and possibly to one or more other RNCs 4 via the Iur interface 14.

0031In a UMTS network, the Radio Resource Control (RRC) protocol is used across the radio interface, i.e. between the UE and UTRAN. These protocol end points interact by exchanging protocol parameters, by sending messages comprising of one or more information elements.

0032In order to set up a MBMS session, the RNC receives a respective request from the CN. This MBMS Session Start Request contains a MBMS Service Identification, specifies the MBMS Bearer Service Type and MBMS Session Attributes such as the MBMS Service Area Information or Quality of Service parameters. After the RNC receives the MBMS Session Start Request, it notifies the UEs which are interested in and have activated the particular MBMS service.

0033The MBMS Session Start Request contains all information necessary to set up an MBMS Radio Access Bearer (RAB). Upon reception of the Session Start message, the RNC executes an MBMS data bearer set up over the Iu interface, and subsequently informs the sending CN of the outcome of the set up in a MBMS Session Start response message.

0034For a particular MBMS service, data is then transferred via an MBMS RAB between the network and the UE.

0035In order to set up the connections between the RNC and the UE, the existing transport channel mechanism of the Forward Access Channel (FACH) over Iub is used in case of a point-to-multipoint (ptm) MBMS transmission. A ptm connection is established if the number of counted MBMS users in a cell exceeds a certain operator-defined threshold. Otherwise, a point-to-point (ptp) connection is established over the DTCH as defined for other dedicated services.

0036The CN sends the MBMS Session Stop command in a similar way to the RNC, and the RNC then notifies the interested and activated UEs of the end of the MBMS session. When the RNC receives an MBMS Session Stop Request, it releases the associated MBMS RAB resource.

Applying a "CBS-like solution" for MBMS

0037As described above a straightforward application of the CBS approach would be to signal in the scheduling message which services are going to be provided within a certain time period. This time period can for example be determined to be the next 50 System Frame numbers (SFNs).

0038A secondary Control Common Channel may carry 64kbps, may have Time Transmission Intervals (TTI) of 40ms and being adapted to carry 8 Transport Blocks (TBs) of each 320bits at every TTI. Furthermore, a maximum of 8 services could be provided per 4 SFNs, or 100 services in 50SFNs. For each service occurrence, the MAC identity needs to be identified (this may for example require 5 bits and 32 services on one SCCPCH).

0039The scheduling message would then have a maximum length of around 500bits per 0.5 seconds, generating overall a load of 1kbps.

0040The Cell Broadcast Service uses the so-called "Asynchronous Approach". This means that scheduling messages are not sent at fixed timing occasions. Instead, usually in every scheduling message the optimal timing for the next scheduling message is specified, i.e. just after the time period covered by the current scheduling message.

0041Although this type of solution can also be considered one possible valid solution for MBMS, it can be questioned if this type of straightforward application of the CBS to the MBMS case results in an optimal solution for MBMS or can be further improved.

<u>Best Modes for Carrying Out the Invention</u>

0042Starting from the above described CBS-like solution, the following issues need to be addressed: <ol id="ol0001" compact="compact"><li>1)What is the most efficient way to signal MBMS service scheduling information ? Is signalling the contents of every TTI (which MBMS services are going to be transmitted in that TTI) an efficient approach, or are there more efficient approaches for reducing the size of the scheduling information ?</li><li>2)Should scheduling information be provided at fixed positions in time (also called "synchronous"), or is it beneficial to allow an "asynchronous approach" like in CBS where the time interval between subsequent scheduling message can vary ?</li><li>3)How do we want to group the scheduling information, e.g. one message for all service on one SCCPCH, one message per service,....)?</li></ol>

0043In the following all of these issues will be discussed.

<u>First Embodiment</u>

How to signal MBMS service scheduling Information ?

0044A possible solution may be provided by signalling one scheduling indication per TTI, specifying which MBMS services are going to be transmitted. In this way the UTRAN scheduling typically distributes the transmission of the information belonging to a specific MBMS service at random over time. The above described solution is the straightforward application of the CBS solution.

0045However, for MBMS the delay of the service is not very critical. Considering only the delay of the data, a delay of for example up to 0.5 seconds does not pose any problem

0046Referring now to <figref idref="f0002">Figure 3</figref>, two different scheduling approaches for one MBMS service are described. In <figref idref="f0002">Figure 3A</figref> the scheduling approach of the CBS-like solution is illustrated. UTRAN transmits 1 TB for the service every 40ms TTI.

0047In <figref idref="f0002">Figure 3B</figref> an alternative scheduling approach is illustrated. The information transmitted by UTRAN for this MBMS service is grouped together. UTRAN now transmits 8 TBs every 8 TTIs. Grouping together the information to be transmitted as described above results in a maximum delay of 240ms.

0048With the alternative approach as illustrated in <figref idref="f0002">Figure 3B</figref> the number of scheduling messages can be reduced. Instead of having to indicate 8 instances at which the MBMS service will be transmitted, only one instance needs to be indicated. As long as the data can be delayed up to a period of time comparable to the scheduling interval covered by the scheduling message, scheduling of "grouped information" as described above is more efficient than scheduling the information separately.

0049Another advantage of this approach is that scheduling information for a specific MBMS service in bursts rather than spreading it over every TTI provides the UE with more opportunity to perform neighbouring cell measurements. Note that in order to make the most time available for neighbouring cell measurements, each TTI should preferably only contain data for one MBMS service.

0050However, the delays introduced by grouping together information as described above should be done with care, as in case that the bursts required to transmit the information become too long, the UE might again get problems with performing measurements.

Start of MBMS Service transmission

0051In addition to grouping data together for each MBMS service before transmission as described above, the transmission of scheduling information may be improved by indicating for each MBMS service the next instance or the next instances in which transmission for that MBMS service will start.

0052The instances can for example be indicated by a list of start SFNs, which identify the starting frame, or a list of start TTIs. However, since TTIs are not numbered, for implementing the latter proposal the TTIs needs to be numbered. This can be achieved by introducing a number for the TTls, for example at the end of the scheduling message.

0053Compared to a CBS-like approach, the proposed solutions result in a more efficient way of scheduling information. This may result in smaller scheduling messages. Also, the above described way of transmitting scheduling information facilitates the selection of good opportunities for performing neighbouring cell measurements for the UE.

<u>Second Embodiment</u>

Different time periods for different services

0054From a UE efficiency point of view, the period which is covered by the scheduling message should be as long as possible: it will enable the UE to plan its measurement periods well in advance and can result in large periods in which the UE can be absent without having to read an MBMS service or scheduling message.

0055From a UTRAN scheduling efficiency point of view, the period should be as short as possible (preferably no scheduling info) in order to maintain maximum flexibility with respect to which MBMS service to schedule when. If the period covered by the scheduling message is too long, the UTRAN may have to buffer too much data.

0056This will be illustrated by the following example: Assume that a scheduling message covers 60 seconds. Consider now that immediately after a scheduling message has been sent, continuous downlink data for a 256kbps service starts to arrive. In this case the UTRAN needs to buffer 1.9MB of data for this particular MBMS service.

0057On the other hand, for MBMS services of a lower rate longer periods of inactivity might be advantageous. These periods of inactivity may for example be 30 seconds long.

0058It might be thought that a potential disadvantage is that to allow scheduling periods to be of different length for different services might generate more service asynchronism between cells of different RNCs, for the following reason. In MBMS a terminal may combine the MBMS data received from different cells in order to improve the quality of reception. This requires that the transmission of the data in the two cells is, to some extent, aligned in time. However, such combining is not supported between cells of different RNCs. Hence, this asynchronism/ misalignment between cells of different RNCs is not considered to be a real drawback in practice.

0059Consider a second example: for a text based service and a low rate service of 1kbps, a 10 second discontinuous transmission (DTX) decreases the UE power for reading the scheduling message by a factor of 20 when compared to 0.5s scheduling message interval, and requires very little buffer capacity in the RNC. For the text based service the required buffer capacity is almost zero, and for the 1kbps service it is 1.2kB.

0060In the following it is discussed what the longest sensible period is for which scheduling information could be provided. Assuming a typical longest discontinuous reception (DRX) cycle of 5 seconds, and assuming that it will take about 1 longest DRX cycle to notify UEs of a service unavailability, and 2 DRX cycles for session availability, in principle an expected interruption of more than 15 seconds could already be handled by temporarily making the service unavailable. However, this will require the use of additional notification indicators (NI). Therefore, it appears that to use the service available -> service unavailable -> service available transition sequence is only advantageous if a service interruption on the order of a minute or more is expected.

0061Since the SFN cycle covers a 40 seconds period, a straightforward compromise is to allow service interruptions up to one SFN cycle to be signalled with the scheduling information

0062Above a solution has been described which allows the scheduling information to cover different periods for different services. This can for example be achieved by specifying a smart mechanism with respect to when the UE is required to read the next scheduling message (see Third Embodiment below).

0063By allowing the scheduling information to cover different time periods for different services, the UE does not have to read unnecessarily additional scheduling message. In this way the power consumption can be reduced.

0064The advantage of providing different scheduling time periods for different services is illustrated by the following example.

0065It is assumed that the UTRAN can indicate ("predict") the scheduling information for a high rate service for a period of 1 second in advance, and for a low rate service for up to a minute. In this case a UE only interested in the low rate service will only need to read the scheduling message every minute.

0066On the other hand, if the scheduling information would only cover 1 second for both high and low rate services, even the UE which is only interested in the low rate service is required to read a scheduling message every second.

<u>Third Embodiment</u>

Synchronous &lt;-&gt; Asynchronous scheduling information

0067In the CBS solutions, the scheduling information is not necessarily provided at fixed points in time. Instead, a scheduling message follows the last message sent in the previous scheduling period.

0068This approach is referred to as "asynchronous", and provides additional flexibility to the UTRAN for the following reason. If for example the scheduling information for a certain scheduling period increases, but the UTRAN wants to keep the scheduling messages within a certain size, the UTRAN can decide to decrease the scheduling period covered by each scheduling message.

0069An alternative is provided by the so-called "synchronous approach": Here, the MBMS scheduling information is provided according to a pre-determined schedule. The information regarding the schedule of the scheduling information is typically provided to the UE by a signalling means or message other than the actual scheduling message.

0070If a UE misses a scheduling message, for example due to an incorrect cyclic redundancy check (CRC), the UE acts in a similar way in both the asynchronous and the synchronous approach. In both cases the UE has to read the MBMS point-to-multipoint traffic channel (MTCH) on the SCCPCH continuously and handles any information it receives for the MBMS services it is interested in, until the next scheduling message is received.

0071However, the situation is more complicated for the asynchronous approach, i.e. in case that the scheduling information is allowed to have different periods for different services.

0072This will be described by means of the example below.

0073A scheduling message send at the time SFN=0 has the following contents: <ul id="ul0002" list-style="dash" compact="compact"><li>Service 1: SFN=10, SFN=20, SFN=30, SFN=40</li><li>Service 2: SFN = 210</li></ul>

0074A UE which is only interested in MBMS service 2 does not read the SCCPCH until SFN210. Then the UE continues to read the SCCPCH after SFN210 until it receives the next scheduling message. The next scheduling message may for example be sent at SFN250.

0075Thus the approach of receiving the SCCPCH after the last know MBMS Service "start-TTI" might consume a lot of power, and might even consume more power than in the case that the UE reads the scheduling message regularly. Therefore, this asynchronous approach is disadvantageous.

0076On the other hand, if the scheduling messages are provided at known occasions, and scheduling messages are sent according to the general rule that any scheduling message should include all start-TTI's up to the next scheduling message after the highest indicated start-TTI, the UE only needs to read the first scheduling message after the last indicated start-TTI for the service in which the UE is interested.

0077Below an example is described for a synchronous scheduling approach.

0078A scheduling message is provided at every SFNmod64=0 and the scheduling message includes the following information: <ul id="ul0003" list-style="dash" compact="compact"><li>Service 1: SFN=10, SFN=20, SFN=30, SFN=40</li><li>Service 2: SFN = 210</li></ul>

0079A UE interested in service 1 needs to read the next scheduling message at SFN=64. Thus it listens to any transmissions between SFN=40 and SFN=64. The UE only interested in MBMS service 2 reads the next scheduling message at SFN=256.

0080It is noted that the UTRAN may indicate the SFN of a future scheduling message in case the UTRAN knows in advance that the service is not going to be provided for quite a long period to come, but does not know at which point in time it will start to transmit the data again.

0081Therefore, synchronous scheduling is considered the more advantageous approach. Accordingly, scheduling information is provided in accordance with a predefined schedule. Thus, the UE does not need to have received the previous scheduling message in order to know the timing of the next scheduling message.

0082Together with the approach described above in the second embodiment, a scheme is realised in which UEs only need to read scheduling messages which are relevant for them. This will result in a reduction of the power consumption for UEs which are only interested in services for which the scheduling information can be provided well in advance.

<u>Fourth Embodiment</u>

0083How to transport/group the scheduling information over the SCCPCH

0084In a CBS-like solution, all the scheduling information to be provided in the next scheduling period is collected and transmitted in one message.

0085In this way reception of scheduling information is facilitated for UEs interested in multiple CBS messages, since all the relevant information is provided in one message rather than in more than one message transmitted as different occasions.

0086An alternative approach is to provide the scheduling information for different MBMS services at different points in time instead of collecting all the information in one message.

0087The following approaches for providing MBMS scheduling information are considered useable: <ol id="ol0002" compact="compact"><li>1)a solution in which the MBMS scheduling information is provided grouped for all MBMS services provided on this SCCPCH;</li><li>2)a solution in which the MBMS scheduling information for different MBMS services might be provided at different points in time.</li></ol>

0088The first approach might be beneficial for UEs interested in multiple services and result in a lower UE power consumption for these situations.

0089The second approach might be beneficial for UEs interested in a limited number of MBMS services (e.g. only one), since they do not need to read a scheduling message signalled at an additional time instance.

<u>Examples</u>

0090Referring now to <figref idref="f0003">Figure 4</figref>, an example of providing three different MBMS services on one SCCPCH will be described. In this example different elements of how to provide scheduling information for a MBMS service as described above in the first three embodiments are combined. The approach combines the element of grouping of data and indicating the start SFNs as described in the first embodiment, the element of providing scheduling information having different periods for different MBMS services as described in the second embodiment and the element of providing a synchronous schedule as described in the third embodiment: <ul id="ul0004" list-style="none" compact="compact"><li>In this example, on a 64kbps SCCPCH, three services are provided: <ol id="ol0003" compact="compact"><li>1) a 32 kbps service (MBMS service 1, indicated by dark shading);</li><li>2) a variable rate service with a delay tolerance of a 640ms (MBMS service 2, indicated by light shading); and</li><li>3) a low rate service with a large delay tolerance (MBMS service 3, indicated by hatching).</li></ol></li></ul>

0091The scheduling information is provided every 640ms (i.e. in SFN 256, 320,....). The table below indicates the contents of the scheduling messages transmitted at SFN256, SFN300, SFN384 and SFN448. <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="4"><colspec colnum="1" colname="col1" colwidth="24mm" /><colspec colnum="2" colname="col2" colwidth="24mm" /><colspec colnum="3" colname="col3" colwidth="24mm" /><colspec colnum="4" colname="col4" colwidth="24mm" /><tbody><row rowsep="0"><entry rowsep="1" align="right" valign="bottom">SFN256:</entry><entry rowsep="1" align="right" valign="bottom">SFN320</entry><entry rowsep="1" align="right" valign="bottom">SFN384</entry><entry rowsep="1" align="right" valign="bottom">SFN448</entry></row><row rowsep="0"><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry></row><row><entry align="right" valign="bottom">Service1: 256</entry><entry align="right" valign="bottom">Service 1: 320</entry><entry align="right" valign="bottom">Service1: 384</entry><entry align="right" valign="bottom">Service 1: 448</entry></row><row rowsep="0"><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry></row><row><entry align="right" valign="bottom">Service2: 296</entry><entry align="right" valign="bottom">Service2: 360</entry><entry align="right" valign="bottom">Service2: 424</entry><entry align="right" valign="bottom">Service2: 488</entry></row><row rowsep="0"><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry><entry align="right" valign="bottom">MBMS</entry></row><row><entry align="right" valign="bottom">Service3: 508</entry><entry align="right" valign="bottom">Service3: 508</entry><entry align="right" valign="bottom">Service3: 508</entry><entry align="right" valign="bottom">Service3: 508</entry></row></tbody></tgroup></table></tables>

0092It can be seen from the table that the first scheduling message transmitted at SFN256 indicates the start transmitting times for Services 1,2 and 3 as SFN256, SFN296 and SFN508, respectively, The second scheduling message transmitted at SFN320 indicates the start transmitting times for Services 1,2 and 3 as SFN320, SFN360 and SFN508, respectively,

0093Referring now to <figref idref="f0004">Figure 5</figref> another example of providing six different MBMS services on one SCCPCH is illustrated. Each of these six MBMS services is indicated by a different style of shading or hatching.

0094Again the scheduling information is provided every 640ms, and the two scheduling messages transmitted at SFN256 and SFN320 are illustrated. It can be seen from <figref idref="f0004">Figure 5</figref> that the SCCPCH is highly loaded by providing six different MBMS services

0095Although the present invention has been described in the context of Multicast Broadcast services in the UMTS RAN, it is appreciated that it may also be applied to other similar systems. For UMTS, it is expected to be applicable to Release 6 and later releases.

0096It is to be understood that the various aspects of the different embodiments described above may be implemented individually or in any possible combination.

0097It is to be understood that the embodiments described above are preferred embodiments only. Various features may be omitted, modified or substituted by equivalents without departing from the scope of the present invention defined in the accompanying claims.