WO2011050996A1

WO2011050996A1 - Technique for notifying changes on a multimedia broadcast multicast service specific system information

Info

Publication number: WO2011050996A1
Application number: PCT/EP2010/006679
Authority: WO
Inventors: Mai-Anh Phan; Jörg Huschke
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2009-11-02
Filing date: 2010-11-02
Publication date: 2011-05-05

Abstract

A technique for notifying changes on a MBMS specific system information is presented. A method implementation comprises the step of using MBMS specific notification occasions to indicate changes in an MBMS specific SIB. In a first realization, indicating the changes comprises extending a MCCH notification message by an indicator bit to indicate the changes. In a second realization, a different radio frame offset for MBMS specific SIB notification messages is used to indicate the changes. In a third realization, a first M-RNΗ being different from a second M-RNΗ for MBMS specific SIB notification messages is defined to indicate the changes used for MBMS specific SIB.

Description

TECHNIQUE FOR NOTIFYING CHANGES ON A MULTIMEDIA BROADCAST MULTICAST

SERVICE SPECIFIC SYSTEM INFORMATION

TECHNICAL FIELD

The present invention disclosure generally relates to service provisioning networks. In particular a technique for notifying changes on a Multimedia Broadcast Multicast Service (MBMS) specific system information is presented.

BACKGROUND

For MBMS, broadcast services are generally offered within a large geographic area, consisting of one or more cells. Since all these cells distribute the same services, the spectral efficiency of MBMS transmission can be optimized by applying MBMS single frequency network (MBSFN) operation, which means that identical data is transmitted on the same time-frequency radio resources from each cell. The cells that offer the same set of MBMS services and the same scheduling of MBMS service sessions on the same time-frequency radio resources belong to one MBSFN area.

On the broadcast control channel (BCCH) of each cell supporting MBMS transmission, there is a MBMS specific System Information Block (SIB), also known as SIB13, that carries information about each MBSFN area and parameters related to the

corresponding MBMS control channel (MCCH). The MCCH is needed for the User Equipment (UE) to obtain service specific information necessary for MBMS service reception, e.g. physical multicast channel (PMCH) configuration such as modulation and coding scheme, MBMS subframe allocation etc.

In order to avoid periodic reading of the complete system information and reduce battery consumption, notification mechanisms to inform the UE about system information changes exist. There are basically two notification methods to indicate system information changes on all SIBs except for SIB10 and SIB11 to UEs as explained in the document 3GPP TS 36.331 "E-UTRA; Radio Resource Control (RRC); Protocol specification (Release 8)". The first method is based on the

systemlnfoValueTag contained in SIBl, and the second method is based on the paging mechanism defined for Long Term Evolution (LTE). In order to notify changes on the MBMS specific SIB, the two existing notification mechanisms listed above can be reused without requiring additional specification efforts. These two methods and also related drawbacks will be explained in more detail as follows.

According to the first method, systemlnfoValueTag ^'m SIB1 changes. This will cause ALL UEs to read ALL SIBs other than SIBIO and SIB11. Further, the

systemlnfoValueTag is assumed valid for 3 hours = 180 minutes; on average changes are only possible every (180 / 32 = 5.625) minutes. That is, frequent changes in the order of several seconds cannot be supported.

The second method introduces a two-step approach. In a first step, the UE finds the paging Radio Network Temporary Identifier (P-RNTI) on the Physical Downlink Control Channel (PDCCH) and in a second step it reads the corresponding paging message, which includes systemlnfoModification, on PDSCH, as shown below:

Paging ::= SEQUENCE {

paging ecordList PagingRecordUst OPTIONAL, -- Need ON

systemlnfoModification ENUMERATED {true} OPTIONAL, -- Need ON

etws-Indicat^'on ENUMERATED {true} OPTIONAL,— Need ON

nonCritjcalExtension SEQUENCE {} OPTIONAL— Need OP

}

The drawback of the second method is that frequent PDCCH usage during all paging occasions can reduce the signaling capacity and, thus, the system performance for unicast users. It is an impact on non-MBMS UEs that this mechanism will require all UEs to read the paging message and all SIBs other than SIBIO and SIB11.

Specific system information changes, e.g. related to the Earthquake and Tsunami Warning System (ETWS) carried in SIBIO and SIB11, are indicated with a specific information element (IE) in the paging message, e.g. the etws-Indication. Thus, changes in specific SIBs can be separately notified without forcing UEs to read all system information messages. The notification mechanism of ETWS changes on SIBIO and/or SIB11 ensures that only ETWS capable UEs read primary and / or secondary notification on SIBIO or SIB11, respectively. However, all paged UEs have to read the paging message.

Similar to the notification mechanism used for ETWS, it is also possible to introduce a new optional IE to indicate MBMS specific changes on the MBMS specific SIB, i.e. SIB13, e.g. by introducing a non-critical extension, mbms-Indication, in the paging message as illustrated below.

Paging ::= SEQUENCE {

PagingRecordList PagingRecordList OPTIONAL, -- Need ON

systemlnfoModification ENUMERATED {true OPTIONAL, - Need ON

etws-Indication ENUMERATED {true} OPTIONAL, -- Need ON

nonCriOcalExtension SEQUENCE {

mbms-Indication ENUMERATED {true} OPTIONAL, - Need ON nonCriticalExtension SEQUENCE {}

}

OPTIONAL, -- Need OP

} This implies a minor specification effort, i.e. only addition of one optional field in the paging message. Similar to the drawbacks of the second notification method using the paging mechanism, frequent PDCCH usage during all paging occasions reduces the signaling capacity and thus, the system performance for unicast users. It is an impact on non-MBMS UEs that this will cause all UEs to frequently read the paging message.

Currently, 3GPP only supports static MBSFN areas, i.e. cells can only be added to or removed from one MBSFN area by operation and maintenance (O&M). For future releases, it shall be possible to dynamically change MBSFN areas depending on the user density interested in specific services. In the latter case, each cell can be added to or removed from a MBSFN area in the order of seconds. These changes are also reflected on the MBMS specific SIB.

The systemlnfoValueTag, which occupies 5 bits, is supposed to be valid for 3 hours. Consequently, systemlnfoValueTag can be set to 32 different values, thus changes can occur every 180 min / 32 = 5.625 min on average. However, this period is significantly larger than the expected change interval. Existing notification mechanisms that can be used for the MBMS specific SIB have an impact on non-MBMS UEs. Apart from the fact that changing the systemlnfoValueTag or\ SIBl is not suitable to support notification of MBMS specific SIB, the notification mechanisms for system information changes also force non-MBMS UEs to wake up again to read the paging message as well as all SIBs (except for SIB10 and SIB11). Also with the introduction of mbms-Indication in the paging message, non-MBMS UEs would still have to read the paging message before they can fall back into sleep mode.

In other words, it is realized that the MBMS specific SIB (e.g. SIB13) will need different handling than other SIBs if forward compatibility to support dynamically changing MBSFN areas is required. In contrast to any other SIB, the MBMS specific SIB may in such a scenario change rather frequently. [Existing schemes force non- MBMS UEs to re-read all system information messages if changes on MBMS specific SIB are notified. Consequently, existing notification schemes reused for changes on SIB13 would increase UE power consumption for non-MBMS UEs.

SUMMARY

Since existing notification mechanisms for system information changes cannot fulfil MBMS specific requirements regarding the frequency of change and further have a negative impact on non-MBMS users, there is a need for an improved technique to notify changes on MBMS specific system information.

According to a first aspect, a method is provided for notifying changes on a Multimedia Broadcast Multicast Service, MBMS, specific system information, wherein the method comprises the step of using MBMS specific notification occasions to indicate changes in an MBMS specific System Information Block, SIB.

Accordingly, impact on non-MBMS UEs can be minimized. In addition, firstly, non- MBMS UEs can lower UE power consumption because wake up at MBMS specific notification occasions is not required, and as a consequence, they can avoid reading MBMS triggered paging messages and re-reading system information messages upon changes of the MBMS specific SIB. Secondly, there is no impact on PDCCH load in non- MBSFN subframes caused by MBMS specific issues. Thirdly, integration in existing network solutions is easy.

The MBMS specific notification occasions may be located at occasions used to notify session starts on a MBMS Control Channel, MCCH. Further, the MBMS specific SIB, on which the changes have occurred, may be SIB13 as defined in the Long Term

Evolution, LTE, radio protocols. That is, backward compatibility with legacy (e.g. prior to LTE) devices is further enhanced. Further, it is to be noted that for this description, "SIB13" is used at several occurrences to denote the "MBMS specific SIB"; this does not preclude that other SIBs may serve as MBMS specific SIB. Still further, the changes in the MBMS specific SIB may be dynamic MBMS single frequency network, MBSFN, area changes. That is, impact of the MBMS service on non-MBMS users is reduced while at the same time allowing an increased flexibility for changes of MBSFN areas, i.e. cells may be added to or removed from an MBMS single frequency network (MBSFN) within short time intervals, e.g. in the order of seconds. In a first realization, indicating the SIB13 changes comprises extending an MBMS Control Channel, MCCH, notification message by an indicator bit, and utilizing the indicator bit to indicate the changes. Accordingly, network resources are exploited in an efficient manner. In the first realization, the method is performed in a communication network having a plurality of MBMS single frequency network, MBSFN, areas, and the indicator bit is one of reserved bits not needed for indication of different MBSFN areas. In that case, if all available bits in the MCCH notification message are used for distinguishing session starts in the different MBSFN areas, a number of supported MBSFN areas may be reduced by 1. Alternatively, if there are reserved bits in the MCCH notification message, a number of reserved bits may be reduced by 1. Accordingly, network resources are further saved by minimizing the additional overhead involved in MBMS changes signalling. The first realization also covers a data structure for notifying changes on a Multimedia Broadcast Multicast Service, MBMS, specific system information, wherein the data structure comprises a field adapted to store the content of a MBMS Control Channel, MCCH, notification message, and a field adapted to store an indicator bit being utilized to indicate changes in an MBMS specific System Information Block, SIB. Preferably, the data structure is used in a communication network having a plurality of MBSFN areas, and the indicator bit is one of reserved bits not needed for indication of different MBSFN areas. Further, if all available bits in the MCCH notification message are used for distinguishing session starts in the different MBSFN areas, a number of supported MBSFN areas may be reduced by 1. Alternatively, if there are reserved bits in the MCCH notification message, a number of reserved bits may be reduced by 1.

Accordingly, the data structure enables all advantages as described above in

conjunction with the first realization.

According to a second realization, indicating the SIB13 changes comprises using a different radio frame offset to indicate the changes, and transmitting a SIB13 notification message and a MCCH notification message at the different radio frame offset. Accordingly, the MBMS UE complexity can be reduced and it only has to wake up at one additional occasion.

In the second realization, the MBMS notification message is associated with one predetermined MBMS Radio Network Temporary Identifier, M-RNTI. Further, in the transmitting step, the SIB13 and MCCH notification message may be transmitted on different subframes specified by using the different radio frame offset. That is, increase in overall system complexity can be avoided, and UE power consumption can be minimized specifically for non-MBMS users.

Further, the SIB13 notification message may comprise one bit to indicate the change, and the SIB13 notification message has downlink control information, DCI, format different from a given DCI format and having the same payload size. In the latter case, the given DCI format may be 1C. Using a different DCI format means that the contents is interpreted differently. Accordingly, the MCCH notification message is not modified such that sufficient bits compared to the first realization are left in the MCCH

notification message to indicate session starts for the maximum number of supported MBSFN areas also for narrow bandwidths, such as 1.4 MHz. In a third realization, indicating the changes comprises defining a first MBMS Radio Network Temporary Identifier, M-RNTI, to indicate the change on SIB13, the first M- RNTI being different from a second M-RNTI used for a MCCH notification message, and transmitting at least one SIB13 notification message associated with the first M-RNTL Accordingly, UE wake up times can be restricted to one MBMS specific notification occasion.

In the third realization, a plurality of notification messages is transmitted, a first part of those messages are the MBMS notification messages that are to indicate the SIB13 change is associated with the first M-RNTI, and a second part of those messages are the MBMS notification messages that are not to indicate the SIB13 change, e.g. to indicate MCCH changes is associated with the second M-RNTI. In addition, a mapping between the M-RNTIs is fixedly defined in a system specification. Alternatively, the mapping between the M-RNTIs is signalled via the broadcast control channel, BCCH. Thus, network resources are exploited in an efficient manner.

Moreover, there is provided a computer program product comprising program code portions for performing the above described method when the computer program product is executed on one or more computing devices. Preferably, the computer program product is stored on a computer readable recording medium.

Finally, a network element for notifying changes in an MBMS specific system

information is provided, wherein the network element comprises a component adapted to use MBMS specific notification occasions to indicate changes in an MBMS specific SIB. Accordingly, the network element yields all advantages inherent to the above described method. According to the above described first realization, in the network element, the component for using MBMS specific notification occasions comprises a component adapted to extend an MCCH notification message by an indicator bit, and a component adapted to utilize the indicator bit to indicate the changes. With respect to the above described second realization, in the network element, the component for using MBMS specific notification occasions comprises a component adapted to use a different radio frame offset to indicate the changes, and a component adapted to transmit a SIB13 notification message and a MBMS notification messages at the different radio frame offset.

Concerning the above described third realization, in the network element, the component for using MBMS specific notification occasions comprises a component adapted to define a first M-R TI to indicate the MBMS specific SIB change, the first M- fWn being different from a second M-RIVTI used for a MCCH notification message, and a component adapted to transmit at least one SIB13 notification message associated with the first M-RNTI.

BRIEF DESCRIPTION OF THE DRAWINGS Other objects, advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in

conjunction with the accompanying drawings.

Figs, la and lb illustrate an evolved NodeB comprising an electric circuitry for performing the method according to embodiments of the present invention; shows, according to a first embodiment, an apparatus for notifying changes on an MBMS specific system

information; shows, according to the first embodiment, a method for notifying changes on an MBMS specific system

information; shows, according to the first embodiment, a data structure for notifying changes on an MBMS specific system information; shows, according to a second embodiment, an apparatus for notifying changes on an MBMS specific system information; shows, according to the second embodiment, a method for notifying changes on an MBMS specific system information; shows, according to a third embodiment, an apparatus for notifying changes on an MBMS specific system

information; and shows, according to the third embodiment, a method for notifying changes on an MBMS specific system

information;

DETAILED DESCRIPTION

Figure la shows schematically an embodiment of an eNB 100. The eNB 100 comprises an output unit 102 for wireless communication 120 with a mobile unit 130 and comprises a unit 101 using MBMS specific notification occasions to indicate changes on MBMS specific SIBs to mobile units applying MBMS services.

Figure lb schematically shows an embodiment of the eNB 100 as an alternative way of disclosing an embodiment of the eNB 100 illustrated in figure la. Comprised in the eNB 100 are here a processing unit 103, which is either a single unit or a plurality of units to perform different steps of procedures described herein. The eNB 100 also includes an output unit 102 for wireless communication 120 with a mobile station 130.

Furthermore, the eNB 100 comprises at least one computer program product 104 in the form of a non-volatile memory comprising a computer program 105 with code means which when run on the eNB 100 causes said eNB 100 to perform the steps of the procedures described earlier.

MBMS specific notification occasions already exist to indicate session starts on different MCCHs. There are generally multiple notification occasions during one MCCH modification period to ensure sufficient reception reliability.

On the PDCCH, the Downlink Control Information (DCI) for MCCH notification is masked with an M-RNTI supporting a payload size of DCI format 1C. The available bits are supposed to be used to indicate changes in different MBSFN areas, and thus on different MCCHs. The number of available bits depends on the bandwidth.

Further, MBMS UEs in RRCJDLE and RRC_CONNECTED mode may wake up to find MBMS specific notification. The MBMS specific notification occasions may be located in MBSFN subframes. This has no impact on non-MBMS UEs, and the new

mechanism can be easily integrated.

In the following description, for purposes of explanation and not limitation, specific details are set forth (such as particular signalling steps) in order to provide a thorough understanding of the technique presented herein. It will be apparent to one skilled in the art that the present technique may be practised in other embodiments that depart from these specific details.

Moreover, those skilled in the art will appreciate that the services, functions and steps explained herein below may be implemented using software functioning in conjunction with a programmed microprocessor, or using an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP) or general purpose computer. It will also be appreciated that while the following embodiments are described in the context of methods and devices, the technique presented herein may also be embodied in a computer program product as well as in a system comprising a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that execute the services, functions and steps disclosed herein. First Embodiment (Figs. 2 to 4^

Use MCCH notification message introducing indicator bit for MBMS SIB: This

embodiment uses the existing MCCH notification message and extends it. One of the reserved bits that are not needed for the indication of different MBSFN areas is used to indicate a change of the MBMS specific SIB.

In other words, notification messages that are used to indicate session starts on MCCH(s) can be extended. The notification message contains one bit that can be used to indicate a change on SIB13. The other bits are used to indicate the affected MBSFN areas as discussed before. The notification message indicating both session starts on MCCH and changes on SIB13 is transmitted at MBMS specific notification occasions. The frequency depends on the MCCH modification period and the change frequency on SIB13.

· Unused bits in MCCH notification message can be used for SIB13 notification. • If all available bits in the notification message are used to distinguish session starts in different MBSFN areas, the number of supported MBSFN areas is reduced by 1 (see also Fig. 4). Otherwise, if there are reserved bits in the notification message, the number of reserved bits decreases by 1 (see also Fig. 4).

The maximum number of supported MBSFN areas per cell may be set to 8. This is the minimum number of bits that can be transmitted reusing DCI format 1C for a bandwidth of 1.4 MHz. Therefore, for a bandwidth of 1.4 MHz, the maximum number of supported MBSFN areas may be restricted to 7 with option 1. Since the use of narrow bandwidth is expected to be rare and need of more than 7 MBSFN areas on 1.4 MHz is unlikely, it is assumed that this restriction is uncritical.

Fig. 2 shows an apparatus (eNB 100) according to the first embodiment, comprising a core functionality (e.g. a central processing unit (CPU), a dedicated circuitry or a software module) 1001 or the computer program 105, a memory (and/or database) 1002 or the computer program product 104, a transmitter 1003 or the output unit 102, a receiver 1004, an extender 1005 and a utilizer 1006. As indicated by the dashed extension of the functional block of the CPU 1001, the extender 1005 and the utilizer 1006 (and the component for transmitting 1003 and the component for receiving 1004) may at least partially be functionalities running on the CPU 1001, or may alternatively be separate functional entities or means being controlled by the CPU 1001 and supplying the same with information.

The CPU 1001 may be configured, for example by software residing in the memory 1002, to process various data inputs and to control the functions of the memory 1002, the transmitter 1003 and the receiver 1004 (as well as the extender 1005 and the utilizer 1006). The memory 1002 may serve for storing code means for carrying out the methods according to the aspects disclosed herein, when run on the CPU 1001.

It is to be noted that the transmitter 1003 and the receiver 1004 may alternatively be provided as an integral transceiver. It is further to be noted that the

transmitters/receivers may be implemented as physical transmitters/receivers for transceiving via an air interface (e.g., between the eNB 100 and the mobile unit 130), as routing entities (e.g., for transmitting/receiving data packets), as

functionalities for writing/reading information into/from a given memory area, as interfaces between network elements, or as any suitable combination of the above. At least one of the components for extending 1005 and for utilizing 1006 as well as the entire eNB 100, or the respective functionalities carried out, may also be implemented as a chipset, module or subassembly.

Fig. 3 illustrates the first embodiment of a method for notifying changes in an MBMS specific system information. As shown in Fig. 3, a communication network 10 may comprise the eNB 100 and the mobile unit 130. In the signalling diagram of Fig. 3, signalling between elements is indicated in the horizontal direction, while time aspects between signalling are reflected in the vertical arrangement of the signalling sequence as well as in the sequence numbers.

As shown in Fig. 3, in step Sl-1, the extender 1005 extends a MBMS Control Channel, MCCH, notification message by an indicator bit. Then, in step Sl-2, the utilizer 1006 uses the indicator bit to indicate the changes on the MBMS specific SIB. Further, as shown in Fig. 4, the first embodiment also covers a data structure 200 for notifying changes regarding MBMS specific system information. The data structure comprises a field 201 adapted to store the content of a MCCH notification message, and a field 202 adapted to store an indicator bit being utilized to indicate changes in an MBMS specific SIB. It is noted that the term "extending" covers both adding a bit to the MCCH notification message and reusing an existing bit. Preferably, the method and/or the data structure is used in a communication network having a plurality of MBMS single frequency network, MBSFN, areas, and the indicator bit is one of reserved bits not needed for indication of different MBSFN areas. So, if there are reserved bits in the MBMS notification message, a number of reserved bits may be reduced by 1. Alternatively, if all available bits in the MCCH notification message are used for distinguishing session starts in the different MBSFN areas, a number of supported MBSFN areas may be reduced by 1. It is considered that the notification message which is currently only used for session start notification on MCCH(s) can be easily extended with minimum impact on the MBMS UE. The only possible restriction might be the support of both 1.4 MHz and 8 MBSFN areas. However, this is a minor restriction to allow only 7 MBSFN areas in small bandwidth scenarios. Furthermore, it is rather improbable that such scenarios will ever occur.

Second Embodiment ( Fias. 5 and 6)

Time division for MBMS notification: According to this embodiment the MBMS notification is separated by time division. Notification for session starts on MCCH and changes on MBMS SIB can be transmitted at different notification occasions using the same M-RNTI. These messages can be transmitted on different subframes that are specified by using radio frame offsets which can be signalled on MBMS specific SIB. The notification message to indicate changes on MBMS specific SIB has a different DCI format with same payload size, i.e. DCI format 1C would be reused again, and would only carry one single indicator bit, while the remaining bits can be reserved for future purposes.

Figs. 5 and 6 show an apparatus and a method, respectively, according to the second embodiment. For brevity of description, only the parts differing from the above described first embodiment will be described. As is clear from Fig. 5 and 6, the user 1005/the using step S2-1 replaces the extender 1005 and the utilizer 1006/the extending step Sl-1 and the utilizing step Sl-2 of the first embodiment.

Accordingly, in step S2-1, the user 1005 uses a different radio frame offset to indicate the changes in MBMS. Further, in step S2-2, the transmitter 1003 or output unit 102 transmits a MBMS specific SIB (e.g. SIB13) notification message and a MCCH notification message at the different radio frame offset. Preferably, the MBMS specific SIB notification message is associated with one predetermined MBMS Radio Network Temporary Identifier, M-RNTI. Further, in the transmitting step, the MBMS specific SIB notification message and the MCCH

notification message may be transmitted on different subframes specified by using the radio frame offset. Additionally, the MBMS specific SIB notification message may comprise one bit to indicate the change on the MBMS specific SIB, and the same MBMS specific SIB notification message may have a downlink control information, DCI, format different from a given DCI format and having the same payload size. Preferably, the given DCI format is 1C.

Third Embodiment (Figs. 7 and 8)

In order to transmit a notification message for the MBMS specific SIB change, this embodiment introduces a new M-RNTI that is different than the

used for MCCH notification message. The mapping of the M-RNTIs to different MBMS notification purposes can be fixed as defined in the specification or signaled on BCCH. This method maintains the UE wake-up times compared to the first embodiment. In other words, notification message for MCCH session starts and SIB13 changes use different M-RNTIs. The transmission of both messages may be configured at the same MBMS specific occasions to minimize the power consumption of MBMS UEs.

• Sufficient bits are left to indicate session starts for the maximum number of supported MBSFN areas also for a bandwidth of 1.4 MHz. Both notification messages can be transmitted at the same subframe.

• Requires an additional M-RNTI

• Uses additional resources (e.g. 8 CCEs) for each SIB13 change notification

message.

• The MBMS UE must decode an additional DCI message on PDCCH.

Figs. 7 and 8 show an apparatus and a method, respectively, according to the third embodiment. For brevity of description, only the parts differing from the above described first embodiment will be described. As is clear from Fig. 7 and 8, the definer 1005/the defining step S3-1 replaces the extender 1005 and the utilizer 1006/the extending step Sl-1 and the utilizing step Sl-2 of the first embodiment. Accordingly, in step S3-1, the definer 1005 defines a first M-RNTI to indicate the changes on MBMS specific SIB, the first M-R TI being different from a second M-RNTI being used for a MCCH notification message. Then, in step S3-2, the transmitter 1003 or the output unit 102 transmits at least one MBMS notification message associated with the first M-RNTI.

Preferably, a plurality of notification messages is transmitted, and if so, a first part of those messages are MBMS specific SIB notification messages that are to indicate the changes is associated with the first M-RNTI, and a second part of those messages are MBMS notification messages that are not to indicate the changes on MBMS specific SIB, e.g. to indicate a MCCH change, is associated with the second M-RNTL In this case, a mapping between the M-RNTIs may be fixedly defined in a system specification.

Alternatively, the mapping between the M-RNTIs may be signalled via the broadcast control channel, BCCH.

It will be appreciated by those skilled in the art that the embodiments described above may be adapted or extended in various ways. Accordingly, the scope of the invention is defined solely by the claims that follow and the elements recited therein.

Claims

1. A method for notifying changes on a Multimedia Broadcast Multicast Service, MBMS, specific system information, wherein the method comprises the step of:

- using MBMS specific notification occasions to indicate changes in an MBMS

specific System Information Block, SIB.

2. The method according to claim 1, wherein the MBMS specific notification occasions are located at occasions used to notify session starts on a MBMS Control Channel, MCCH.

3. The method according to claim 1 or 2, wherein the MBMS specific SIB, on which the changes have occurred, is SIB13 as defined in the long term evolution, LTE, radio protocols.

4. The method according to any one of claims 1 to 3, wherein the changes in the MBMS specific SIB are dynamic MBMS single frequency network, MBSFN, area changes.

5. The method according to any one of claims 1 to 4, wherein indicating the changes comprises:

extending (Sl-1) a MBMS Control Channel, MCCH, notification message by an indicator bit; and

utilizing (Sl-2) the indicator bit to indicate the changes.

6. The method according to claim 5, wherein

the method is performed in a communication network having a plurality of MBMS single frequency network, MBSFN, areas, and

- the indicator bit is one of reserved bits not needed for indication of different MBSFN areas.

7. The method according to claim 6, wherein, if all available bits in the MCCH notification message are used for distinguishing session starts in the different MBSFN areas, a number of supported MBSFN areas is reduced by 1.

8. The method according to claim 6, wherein, if there are reserved bits in the MCCH notification message, a number of reserved bits is reduced by 1.

9. The method according to any one of claims 1 to 4, wherein indicating the changes comprises:

- using (S2-1) a different radio frame offset to indicate the changes; and

- transmitting (S2-2) a MBMS specific SIB notification message and a MBMS

Control Channel, MCCH, notification message at the different radio frame offset.

10. The method of claim 9, wherein the MBMS specific SIB notification message is associated with one predetermined MBMS Radio Network Temporary Identifier, M- RNTI.

11. The method according to claim 9 or 10, wherein, in the transmitting step, the MBMS specific SIB notification message and the MCCH notification message are transmitted on different subframes specified by using the radio frame offset.

12. The method according to any one of claims 9 to 11, wherein:

the MBMS specific SIB notification message comprises one bit to indicate the changes, and

- the MBMS specific SIB notification message has a downlink control information, DCI, format different from a given DCI format and having the same payload size.

13. The method according to claim 12, wherein the given DCI format is 1C.

14. The method according to any one of claims 1 to 4, wherein indicating the changes comprises:

defining (S3-1) a first MBMS Radio Network Temporary Identifier, M-RNTI, to indicate the changes, the first M-RNTI being different from a second M-RNTI used for a MBMS Control Channel, MCCH, notification message; and

transmitting (S3-2) at least one MBMS specific SIB notification message associated with the first M-RNTI.

15. The method according to claim 14, wherein

a plurality of notification messages is transmitted,

a first part of the notification messages are the MBMS specific SIB notification messages that are to indicate the changes is associated with the first M-RIMTI, and

a second part of the notification messages are the MCCH notification messages that are not to indicate the changes is associated with the second M-RNTl.

16. The method according to claim 15, wherein a mapping between the M-RNTIs is fixedly defined in a system specification.

17. The method according to claim 15, wherein a mapping between the M-RNTIs is signalled via the broadcast control channel, BCCH.

18. A computer program product comprising program code portions for performing the method of any one of the preceding claims when the computer program product is executed on one or more computing devices.

19. The computer program product of claim 18, stored on a computer readable recording medium.

20. A network element (100) for notifying changes on a Multimedia Broadcast Multicast Service, MBMS, specific system information, wherein the network element comprises:

- a component (1001; 101) adapted to use MBMS specific notification occasions to indicate changes in an MBMS specific System Information Block, SIB.

21. The network element according to claim 20, wherein the component for using MBMS specific notification occasions comprises:

a component (1005) adapted to extend a MBMS Control Channel, MCCH, notification message by an indicator bit; and

a component (1006) adapted to utilize the indicator bit to indicate the changes.

22. The network element according to claim 20, wherein the component for using MBMS specific notification occasions comprises:

a component (1005) adapted to use a different radio frame offset to indicate the changes; and a component (1003; 102) adapted to transmit a MBMS specific SIB notification message and a MBMS Control Channel, MCCH, notification messages at the different radio frame offset.

23. The network element according to claim 20, wherein the component for using MBMS specific notification occasions comprises:

a component (1005) adapted to define a first MBMS Radio Network Temporary Identifier, M-RIMTI, to indicate the changes, the first M-RNTI being different from a second M-RNTI used for a MBMS Control Channel, MCCH, notification message; and

a component (1003; 102) adapted to transmit at least one MBMS specific SIB notification message associated with the first M-RNTL

24. A data structure (200) for notifying changes on a Multimedia Broadcast Multicast Service, MBMS, specific system information, wherein the data structure comprises: a field (201) adapted to store the content of a MBMS Control Channel, MCCH, notification message; and

- a field (202) adapted to store an indicator bit being utilized to indicate changes in an MBMS specific System Information Block, SIB.

25. The data structure according to claim 24, wherein

the data structure is used in a communication network having a plurality of MBMS single frequency network, MBSFN, areas, and;

26. The data structure according to claim 25, wherein, if all available bits in the MCCH notification message are used for distinguishing session starts in the different MBSFN areas, a number of supported MBSFN areas is reduced by 1.

27. The data structure according to claim 25, wherein, if there are reserved bits in the MCCH notification message, a number of reserved bits is reduced by 1.