GB2526289A

GB2526289A - Resource management in a cellular network

Info

Publication number: GB2526289A
Application number: GB1408870.2A
Authority: GB
Inventors: Youssef Chami; Inigo Guemes; Rocio Ortiz
Original assignee: Vodafone IP Licensing Ltd
Current assignee: Vodafone IP Licensing Ltd
Priority date: 2014-05-19
Filing date: 2014-05-19
Publication date: 2015-11-25
Anticipated expiration: 2034-05-19
Also published as: GB201408870D0; WO2015177040A1; GB2526289B

Abstract

Resources are allocated for providing a multicast or broadcast service in a cellular single frequency network (SFN) comprising one or more base stations and a plurality of subscriber terminals. Information representative of transmission resource requirements for the multicast or broadcast service is received at a resource manager of the cellular network. The resource manager is then used to allocate resources across the cellular network, so as to balance those resource requirements across it. If resources necessary for a broadcast/multicast service exceed a threshold, then the resource manager checks to see if resources allocated to non-broadcast/multicast services, in the original SFN or a neighbouring SFN, can be reallocated. The broadcast/multicast data may be allocated to specific subframes of a dataframe and to the same number of subframes of each frame. Some subframes may be reserved for unicast services if the number of unicast terminals present exceeds a threshold.

Description

RESOURCE MANAGEMENT IN A CELLULAR NETWORK

Field of the Invention

This invention relates to a method of managing resources in a cellular network, and in particular, but not exclusively, to the management of resources in a point to multipoint distribution technique such as Evolved Multimedia Broadcast Multicast Service (eMBMS) in a Long Term Evolution (LTE) cellular network.

Background of the Invention

The Third Generation Partnership Project (3GPP) has been developing enhancements to cellular systems to allow their operation for public safety or emergency services (ES) communications. These are especially intended to work with the Long Term Evolution (LTE) architecture. Aims of this approach may include: reduced cost; improved functionality; and increased flexibility in comparison with existing public safety communication infrastructure, such as the Terrestrial Trunked Radio (TETRA) network.

Key functionalities for ES communications are Push to Talk (PTT) and Group Call communication. The existing architecture includes a number of data routing schemes, including multicast and unicast capabilities, which can be used for Group Call functionality. These are provided using the Multimedia Broadcast Multimedia Service (MBMS), which is known as eMBMS in LTE networks.

Details of these may be found in 3GPP Technical Specification (TS) 22.468 v.12.0.0 and TS 23.768 v.12.0.0.

According to network statistics and the UK government requirements, utilisation in the "Busy Hour" (BH) is considerably higher than at other times of the day. The consequence of this is that Radio resources need to be designed so that both the commercial and the emergency services have sufficient resources to handle the Busy Hour traffic, without considerably impacting each other.

Further, different Radio Base Stations (such as a NodeB, eNode, femtocell or similar) are likely to experience the BH at different times. As a result, it would be desirable for each base station to be allocated different resources at different times, in order to optimise the overall network resources across the day.

Current network architecture does not however offer any methodology for improving and/or optimising the allocation of resources in such situations. The present invention seeks to address such shortcomings.

Summary of the Invention

According to a first aspect of the present invention, there is provided a method of allocating resources for providing a multicast or broadcast service in a cellular network, as set out in claim 1. A computer program in accordance with claim 19 and a Resource Manager in accordance with claim 20 are also provided.

According to an ancillary aspect of the present invention (any part of which may be combined with the invention as defined above) there is provided, in one aspect, a method for interfacing a cellular network with a service manager that is at least logically separate from the cellular network and controls a service provided to at least one of a plurality of subscriber terminals over the cellular network. The method comprises: receiving information in a first format from the service manager indicative of the resource and/or performance requirements for the service; and communicating the received information to a network functions module of the cellular network in a second format that permits the network functions module to interpret the information indicative of the resource and/or performance requirements, so that the network functions module may be configured to operate in a manner which is dependent upon the requirements of the service.

In another ancillary aspect, there is provided a method for interfacing a cellular network with a service manager that is at least logically separate from the cellular network and controls a service provided to at least one of a plurality of subscriber terminals over the cellular network. The method comprises: receiving information in a second format from a network functions module of the cellular network indicative of radio link quality relating to the at least one of a plurality of subscriber terminals; and communicating the received information to the service manager in a first format that permits the service manager to interpret the information indicative of the radio link quality, so that resource and/or performance requirements for the service may be configured on the basis of the radio link quality.

The two aspects may also be combined. According to either aspect (or their combination), a number of optional additional features may be considered.

These will be discussed briefly below.

Optionally, the service manager is a part of a subscriber terminal configured to operate the service at the subscriber terminal. For example, the service manager may be an application operating on the subscriber terminal. Alternatively, the service manager may be a part of a service provider network, configured to manage the service provided to a plurality of subscriber terminals.

Preferably, the resource and/or performance requirements are based on one or more of: a compression coding scheme for the service; a latency requirement for the service; a number of time slots required for the service; a Quality of Service, QoS, requirement for the service.

The service may be a Push to Talk, PTT, application. The service may be a multicast or broadcast service. Then, the network functions module may be a Broadcast Multicast Service Centre, BM-SC.

There is further provided an Application Program Interface (API) having program code which, when executed by a processor, carries out the method according to any ancillary aspect. A network entity comprising a processor configured to operate the API of the ancillary aspect and/or a subscriber terminal comprising a processor configured to operate the API of the ancillary aspect are also provided.

Aspects of the present invention thus provide techniques for implementing group calling communications over a commercial cellular network, for example a 40 (LTE) cellular network, and in particular in a manner that optimises use of the network so that both commercial and emergency service users can coexist with no or minimal mutual impact, even during Busy Hours.

Preferred embodiments of the present invention provide a method to dynamically control the availability of [TE resources, such as baseband unit resources, radio subframes or other radio resources, especially for enhanced Multimedia Broadcast Multimedia Service (eMBMS) communications. The availability of LTE subframes is preferably dynamically evaluated by implementation of an algorithm; the algorithm determines if eMBMS resources should be allocated according to pre-defined criteria being met.

Other preferred embodiments provide for an application programming interface (API) which is used to facilitate communication of resource allocation between LTE network nodes in a commercial 40 cellular network, and service provider functionality nodes (that are at the subscriber terminal or an external network), which may be provided by third party service suppliers.

Preferred embodiments of the present invention thus provide additional intelligence at the Base Station, so as to allow real-time monitoring of, for example, radio resource utilisation and radio resource sharing between different Access Nodes/Gateways. Aspects of the present invention thus, in preferred embodiments, provide one or more of the following advantages: * More optimised resource allocation based on information from both a service manager and the cellular network. The service manager generally controls provision of the communications service in the higher layers of the networking protocol stack (application, possibly including presentation, session or both). The cellular network provides the lower layers of the networking protocol stack (which may include any one or more of: physical; data link; network; and transport). Thus, there may be a logical separation in the way that the service is managed and provided, with the service manager normally setting end-to-end parameters, for example Quality of Service (Q0S) and the cellular network controlling provision of the service at the connectivity layers.

* Improved balancing of resource requirements across the cellular network between the multicast or broadcast service and one or more alternative services (such as unicast services).

is * Better allocated resources for a multicast or broadcast service (such as a Push-To-Talk, PTT, service) across a Single Frequency Network (SFN).

* Better sharing of resources at a base station, for example between a baseband unit of the base station and other radio resources or frequency or band load sharing.

* Interfacing between the cellular network and the service manager (which may be an application at a subscriber terminal or UE) for optimal configuring or network functions based on resource and/or performance requirements and/or optimal configuring of resource and/or performance requirements based on radio link quality and/or bandwidth allocations. In particular, this may use an Application Program Interface (API).

Further preferred features of the invention are set out in the accompanying claims and will further become apparent from a consideration of the following specific description of a particularly preferred embodiment. Additional advantages will also be discussed below.

Brief description of the drawings

The invention may be put into practice in a number of ways, and some preferred embodiments will now be described by way of example only and with reference to the accompanying drawings, in which: Figure 1 shows a schematic diagram of an existing network architecture for a cellular network interfaced with an external service provider, and including network base stations (BS); Figure 2 schematically depicts a Resource Manager associated with a base station, and embodying the present invention; Figure 3 shows a schematic representation of a Long Term Evolution (LTE) data frame, subdivided into a plurality of subframes, and illustrative of the impact on network capacity of methods embodying the present invention; Figure 4 shows a schematic representation of a network of adjoining cells in a cellular network, and illustrative of resource allocation at a cell boundary in accordance with embodiments of the present invention; and Figure 5 shows a flow chart of decisions taken by the Resource Manager of Figure 2, in order to allocate resources.

Detailed description of preferred embodiments

Referring first to Figure 1, there is shown a schematic diagram of an existing network architecture for a cellular network 100 interfaced with an external service provider 200. In this case, the cellular network 100 has an LTE (E-UTRAN) architecture and the external service provider 200 is for Emergency Service (ES) communications, but these are simply illustrations of one suitable network architecture, in order to allow an explanation of the present invention.

The cellular network comprises: eNodeB (base station) / Multi-cell Coordination Entity (MCE) systems 110; a Multimedia Broadcast Multimedia Service (MBMS) Gateway (GW) 120; a network Broadcast Multicast Service Centre (BM-SC) 130; a Mobility Management Entity 140; a Serving Gateway (S-OW) 150; a Packet Data Network Gateway (P-GW) 160; and a Network Management Systems (NMS) and Selt-Organising Network (SON) 170. Two eNodeB/MCE systems 110 are shown as an example, but it will be understood that more are typically present in a practical implementation. The external service provider 200 comprises: a Home Subscriber Server 210; and an external BM-SC 220. The User Equipment (UE) 300 interfaces with the external service provider 200 through the cellular network 100. In this context, a UE may be considered to include any subscriber-specific unit (such as a SIM card), application or data, in combination with a hardware communications device. The UF is normally serviced by one eNodeB/MCE system 110, but it may be served by multiple eNodeB/MCE systems 110 or simply be within the coverage area of multiple eNodeB/MCE systems 110. An external content or service provider 400 may also interface with the cellular network 100 via the network BM-SC 130.

This network architecture is adapted for providing enhanced MBMS (eMBMS) services. Interfaces between the network entities for providing such services are also shown and, where appropriate, labelled. The thin solid line between the UE 300 and external service provider 200 represents eMBMS user data. The thick solid lines represent eMBMS service and security layer data. The denser dashed lines (for example between the MME 140 and MBMS OW 120) represent eMBMS signalling and the thinner dashed lines (such as between the network BM-SC 130 and external BM-SC 220) represent eMBMS sync protocol.

LTE and similar cellular networks (such as the architecture depicted in Figure 1) desirably control their resources and the services that a particular customer can use, especially when the content is being routed directly to or from an external company (particularly the external service provider 200) or the Internet. These controls can be effectively performed at a point where a traffic routing or a switching decision is made.

A large percentage of service and user functionality traffic in the network of Figure 1 can, it is proposed in accordance with embodiments of the present invention, be handled in a more intelligent and dynamic manner. Embodiments of the invention in particular provide enhanced eMBMS functions using a Resource Manager, together with Application Program Interfaces (APIs) positioned logically between the service and user functionality layers and the 4G (LIE) network itself.

The provision of such additional functionality in a network such as (but not limited to) that of Figure 1 permits dynamic change of the data flow from unicast to multicast based on the number of users per cell, sites or regions and/or the resources used per cell/sites. All these techniques reduce the investment required by a mobile operator to carry the data on its own Radio/ backhaul and core transport or cellular core infrastructure.

Referring next to Figure 2, there is shown a schematic representation of such a Resource Manager 450. The Resource Manager is of course not typically a physical entity but is instead a software module comprising logic which is illustrated as a series of logic components 460. However, the Resource Manager 450 may also be understood as a processor or logic operating to provide this functionality.

The Resource Manager is preferably logically, if not physically, located at or in communication with the eNodeB base stations 110. Resource requirements for the network -and in particular resource requirements for the UE 300 running eMBMS services such as Push to Talk (PIT) are received by the Resource Manager as shown. The logic within the Resource Manager 450 makes resource decisions based upon the information received, in a manner to be explained more fully below, and resource allocation instructions are then issued by the Resource Manager 450.

Typically, some or all of the UE5 300 which communicate with the Resource Manager 450 are associated with a third party service provider. For example, some or all of the UEs 300 for which it is desirable to allocate resources may belong to the Emergency Services.

This may be understood as a method of allocating resources for providing a multicast or broadcast service in a cellular network comprising one or more base stations and a plurality of subscriber terminals. Information representative of resource requirements for subscriber terminals to be provided with the multicast or broadcast service from a service manager is received at a resource manager of the cellular network. The resource manager is then used to allocate resources across the cellular network, so as to balance those resource requirements across it. The resources are typically transmission resources of the at least one base station, as will be discussed below. The service manager is preferably at least logically separate from the cellular network and controls the multicast or broadcast service for at least one of the plurality of subscriber terminals. As discussed above, the service manager may control higher layers of the protocol stack, whereas the cellular network manages lower layer operation.

Preferably, some of the plurality of subscriber terminals are provided with the multicast or broadcast service managed by the service manager and at least one other subscriber terminal is provided with one or more alternative services (such as unicast services). The resource manager is then used to balance the resource requirements across the cellular network between the multicast or broadcast service and the one or more alternative services. The resource manager 450 may be part of a base station, part of another network entity or an individual network entity within the cellular network.

To facilitate communications in some cases, an application program interface (API) may be provided. In this context, we will refer to a node operating in accordance with the API as an API for ease of reference. The API is positioned, logically, between the UEs 300 and the Resource Manager 450 at the base -10-stations 110. The API translates information received from the UEs 300 into a format that can be utilised by the Resource Manager 450, to permit the latter to make the necessary assessment based upon predetermined criteria. The API may also provide additional functionality and services in the other direction, that is, in the provision of information to applications running on UEs 300. For example, the API may facilitate the provision of radio link quality information (for example, based upon the Quality of Signal -QoS -function) to applications, allow control of the eMBMS area size and allocated time slot, and or control the applications to allow, disallow or adapt the applications on a dynamic basis.

With this overview, the various additional functionalities proposed in accordance with particularly preferred implementations will now be described in turn.

Dynamic Radio Resource Management for eMBMS As explained in the introduction above, there are particular issues surrounding resource availability in a cellular network, with a capacity bottleneck reaching a peak during the Busy Hour (BH). The Resource Manager 450 addresses this problem in a number of ways, such as sharing of resource between baseband units and other radio resources, frequency or band load sharing of eMBMS users, and consolidating users on a reduced number of frequency bands so as to save energy.

In the known implementation of the Access Network architecture there is no intelligence at the access edge (base station) to allow monitoring of local resources and a more dynamic allocation between unicast and Multicast resources An eNodeB Base Station or Multicell Coordination Entity MCE 110 (Figure 1) can be considered to comprise two main parts: a radio frequency part and a baseband part. The radio frequency part may handle the transmission of radio frequency signals between the antenna of the eNodeB Base Station 110 (or a -11 -Femtocell, for example) and the UE 300, and convert radio frequency signals into digital baseband signals (and vice versa). The baseband part may be responsible for controlling and managing the transmission of the baseband signals to other components of the mobile telecommunications network 100.

In this embodiment, a Resource Manager 450 logically (if not physically) in communication with the Base Stations 110 provides baseband resources and the capability to manage these resources according to a set of rules. In state of the art cellular networks, the baseband parts of conventional base stations are used for unicast calls. The base stations 110 provide radio frequency connections between the Base Stations 110 and UEs 300.

The baseband resources include those provided by NodeB (3G) and eNodeB (4G), referred to as the BaseBand Unit (BBU).

The architecture described above provides additional intelligence at the Base Station and allows real-time monitoring of radio resource utilisation and radio resource sharing between different base stations. This may enable a number of functionalities.

1. Sharing of resources between BaseBand unit and other radio resources.

BaseBands and! or resource blocks that are under-utilised are able to make use of spare resources from one or another of the baseband resources. This leads to more efficient network dimensioning, as access nodes are able to draw from unused resources in nodes when they reach high utilisation. This will limit the need to over engineer the capacity of the network, as would otherwise be mandated if that network were to cope with Busy Hour traffic.

2. Frequency or band load sharing of enhanced Multimedia Broadcast Multimedia Service (eMBMS) users, if eMBMS is configured across multiple frequencies or cells; and!or -12- 3. During low load, moving users from one frequency band to another for the same or different talk groups, so that the other spectrum or frequency can then be turned off. Switching off of unused baseband resources provides a reduction in operational costs and in CO2 emissions. A more dynamic resource management allows resources to be drawn from other under-utilised access nodes or from a single source pool, and for resources in the access nodes to be switched off entirely, during periods of low utilization.

The embodiment may be implemented in the network architecture 100 as follows: 4G: The local BBU occupancy is monitored by the averaged Resource Blocks (RB5) used for the eMBMS and non-eMBMS users. The used RB, the time-slot per radio frames and the number of active users per sector per frequency band.

3G: The local BBLJ resources monitored per 5MHz: for R99 (Release 99) traffic: utilisation [%] is proportional to the number of DCH (Dedicated Channels), the code-tree number and the control channels, and for HSPA (High Speed Packet Access) traffic: utilisation [%] of eMBMS and non-eMBMS users is proportional to the number of users and the offered throughput per active users. If the number of bit/HZ/user goes below or exceed predefined thresholds, the local BBU and spectrum band might be activated/ deactivated.

In the above examples, the radio load is monitored by the Resource Manager 450, although other efficiency characteristics may alternatively or additionally be monitored, e.g. number of users and the quality of service the UE experiences.

The decision to activate/de-activate the local BBU or radio transmitter, or share external BBU5 used by a particular MBMS coordination entity (MCE) can be made at the BM-SC 130, separate Gateway 150, 160, or at a Self-Organised Network 170.

Application Programming Interface (API) -13-As mentioned above, the present invention also provides, in preferred embodiments, an API which defines the language that each of the software modules of the platform use to communicate with one another, so as to coordinate and optimise application delivery to users. The platform negotiates with each application the specific resource and performance requirements, based on the application characteristics, allowing the application directly to communicate the scheduling performance requirements, rather than using a predefined set of quality of service (QoS) parameters. This negotiation between the platform and the applications is facilitated by the API.

The API may also facilitate the provision of radio link quality information (e.g. from the QoS function) to applications.

The API may further enable the platform to control use of the eMBMS area size and allocated time-slot or applications -e.g. to allow, disallow or adapt the applications.

By way of example, the application may be a Push To Talk (PTT) application, such as Group Call. The nature of PTT communications is that there is a virtually continuous succession of small data packets in which voice data is communicated. The voice data must be communicated with no (or, at least, minimal) latency, in order that a conversation can be performed successfully.

The PTT application is able to compress voice data before transmission using a variety of techniques/CODECs. The compression techniques/CODECs may range from a relatively low compression technique, which provides high quality voice reproduction but requires a large bandwidth, to a much higher compression technique which provides reduced voice quality and which requires a much lower bandwidth.

The API is operable to provide details of the application characteristics to the network functions part of the platform, i.e. the BM-SC (broadcast multicast -14-service centre) 130. This makes the network functions part of the platform aware of the characteristics of the application. In the present example, as the application is a PTT application, the network functions part may be made aware that the application will tend to transmit continuous successions of small data packets that require transmission with no or low latency. The network function may then be configured appropriately.

The API may further be operable to allow the network functions part to communicate radio link quality information to the application. For example, the network functions part may receive information regarding the application characteristics (via the API), and may then in consequence allocate radio link resources to that application. This allocation of radio link resources may be communicated by the network functions part to the application (via the API). The application may then select an appropriate number of time-slots required for eMBMS and the compression technique/CODEC, in dependence upon the radio link quality available. During a PTT call, the available radio link quality may be communicated regularly from the network functions part to the application (via the API) to allow the application to vary the compression technique/CODEC used in accordance with changes to the radio link quality.

The network functions part may control how the applications work (via the API).

The network functions part may allow, disallow or adapt the applications that are hosted in the services part of the platform. For example, the network functions part may require the PTT application to use a particular compression technique/CODEC if radio link bandwidth is restricted and the number of eMBMS radio resources reaches a limit.

If the radio link quality information received by the application indicates that bandwidth is restricted, the application may adapt its communications to the users such that latency of the communications is increased uniformly for all of the users. This means that each user then experiences the same delay as the other users, so that each of the users is in turn provided with the same experience. -15-

In this context, it may be understood that a method is provided for interfacing a cellular network with a service manager that is at least logically separate from the cellular network and controls a service provided to at least one of a plurality of subscriber terminals over the cellular network. Information is received in a first format from the service manager indicative of the resource and/or performance requirements for the service. The received information is then communicated to a network functions module of the cellular network in a second format that permits the network functions module to interpret the information indicative of the resource and/or performance requirements, so that the network functions module may be configured to operate in a manner which is dependent upon the requirements of the service. Additionally or alternatively, information is received in the second format from a network functions module of the cellular network indicative of radio link quality relating to the at least one of a plurality of subscriber terminals. The received information is then communicated to the service manager in the first format that permits the service manager to interpret the information indicative of the radio link quality, so that resource and/or performance requirements for the service may be configured on the basis of the radio link quality.

Allocation of Services The control means (where the PTT service provider 200 is located) is responsible for allocating the service instance for each user on the application layer based on the popularity of the service and the location of the UE 300. This may be understood as a separate service provider entity, as discussed above. The network means is, by contrast, responsible for allocating network resources or capacity, capability and available resources to host another instance of a service for commercial and Emergency service users. This typically describes the cellular network. -16-

For certain low popularity PIT calls or services, or where the available capacity or capability is limited, the service can be hosted from another Base Station / MCE 110.

For some services/functions, where the source and destination client applications are in the same geographical region, being served by the same site (e.g. BTS location) or site cluster (e.g. finite number of sites), the access node /gateway ensures that the server for the service is located close to both users, and the traffic is routed between the users within the site. An example of this scenario is the network in a box concept (essentially providing a stand-alone base station) that may be deployed in an area in which no network coverage is available.

A specific example of implementation of methods embodying the present invention in the case of an [TE network will now be provided, with reference to Figures 3, 4 and 5. The decision strategy is, as will be seen, based on number of users, network load, performance, and selected area.

Referring first to Figure 3, an LTE data frame is shown. The LTE frame is 10 ms in length and is split into ten 1 ms subframes (SF0... .5F9) as also shown in Figure 3.

According to embodiments of the present invention, eMBMS is implemented by being allocated to all of (or none of) the subframes which are available.

For instance, eMBMS can use one subframe every frame (e.g. SF1 of the frame below); or every 2nd frame; or every 4th frame or every 8th frame (for higher data rates, it can also use 2, 3,or 4 subframes every frame.) Small numbers of voice calls do not require a lot of capacity, so the default would be to allocate one eMBMS subframe every 8 frames (= 80 ms). This is 1/80th of the capacity of the 10MHz carrier, i.e. 1.25%. -17-

The data in the eMBMS subframe has to be identical in all the cells in the MBSFN area. However the capacity of the subframe is limited, so, not ALL of the speech can be transmitted for all of the groups in a country in one subframe. So the country would instead be covered with a "3 colour reuse pattern" of MBSFN areas. At the border of the MBSFN areas, interference should be limited, so the same MBMS subframe should not be used (either for unicast or multicast) in the cells adjacent to the MBSFN area. In the MBSFN border areas, 2 or 3 subframes are then removed from normal traffic carrying capability.

This leads to a 3*1.25 = 3.75% capacity reduction in the MBSFN border area.

This is however anticipated to be a worst case, as not all the cells will be at the border of 2 or 3 MBSFN areas.

This might therefore be the minimum resources allocated for eMBMS resources.

The time slots can be increased or decreased dynamically due to the number of users and/or the number of talk groups in a given location.

eMBMS resources can be dynamically managed at the serving and the neighbouring cells to reduce the interference impact.

The additional number of slots allocated can also be dependent on the number of unicast commercial users. For example, a pre-set number of slots for a given number of commercial unicast users can be implemented (e.g. slots 7 and 8 are reserved where commercial users exceed a pre-set value).

Also, additional cells to allocate eMBMS resources may be determined by the location of the eMBMS user. For example, bordering cells may be instructed to increase eMBMS resources for incoming eMBMS users, by increasing the size of the MBSFN area size. The location of eMBMS users may be determined by the Base Station 110 or a self-organising network (SON) 170, as illustrated in Figure 4. The UE 300 in figure 4 is approaching the cells shaded grey. These cells are instructed to ensure that eMBMS resources are allocated prior to the eMBMS -18-users being handed over into the cell, and therefore increasing the MBSFN area size to include these two cells.

Figure 5 shows an example decision tree that explains the eMBMS resource allocation. Resources may be re-allocated in the SFN from a non-multicast or broadcast service to the multicast or broadcast service. The re-allocated resources may be unused (available) or in use for provision of the non-multicast or broadcast service. It is advantageous to check that at least one (or some or all) of the re-allocated resources can be used for the multicast or broadcast service in both the SFN and one or more neighbouring SFNs, to avoid interterence as discussed above. Additionally or alternatively, resources may be re-allocated in a neighbouring SFN from a non-multicast or broadcast service to the multicast or broadcast service. Again, the re-allocated resources may be available or in use for provision of the non-multicast or broadcast service. In some scenarios, it may be useful to reallocate resources in a neighbouring SFN even without re-allocating resources in the currently serving SEN, so that a change of a user or users to the neighbouring SFN so that the re-allocated resources may then be used to provide the multicast or broadcast service.

Although a specific embodiment of a preferred method has been described, it will be recognised that a number of alternative techniques maybe employed. For instance, whilst the above description relates to an ES implementation, it will be understood that alternative types of multicast and/or broadcast service may be implemented in a similar way. Also, whilst the embodiments described herein concern 3G and/or 4G systems, it will be understood that this may be extended to other type of cellular network system. -19-

Claims

CLAIMS1. A method of allocating resources for providing a multicast or broadcast service in a cellular network comprising one or more base stations and a plurality of subscriber terminals, the method comprising: receiving, at a resource manager of the cellular network, information representative of resource requirements for subscriber terminals to be provided with the multicast or broadcast service from a service manager; and using the resource manager to allocate resources across the cellular network, so as to balance those resource requirements across it.
2. The method of claim 1, wherein the service manager is at least logically separate from the cellular network and controls the multicast or broadcast service for at least one of the plurality of subscriber terminals.
3. The method of claim 2, wherein some of the plurality of subscriber terminals are provided with the multicast or broadcast service managed by the service manager and at least one other subscriber terminal is provided with one or more alternative services, the method comprising using the resource manager to balance the resource requirements across the cellular network between the multicast or broadcast service and the one or more alternative services.
4. The method of any preceding claim, wherein the resources are transmission resources of the at least one base station.
5. The method of any preceding claim, wherein the information representative of resource requirements indicates one or more of: a number of subscriber terminals requiring the multicast or broadcast service; a geographical area for the subscriber terminals requiring the multicast or broadcast service; a traffic load for the multicast or broadcast service; and a desired a Quality of Service, QoS, for the multicast or broadcast service.

-20 -
6. The method of any preceding claim, wherein the cellular network comprises a plurality of base stations and wherein the multicast or broadcast service is provided by the cellular network using a Single Frequency Network, SFN, the plurality of base stations being grouped to define at least one SFN.
7. The method of claim 6, further comprising: checking if a traffic load allocated to the multicast or broadcast service for a predetermined period of time within a SFN exceeds a threshold value; if the traffic load exceeds the threshold value, checking if the SFN has resources allocated to non-multicast or broadcast services that may be re-allocated; and allocating resources from non-multicast or broadcast services within the SFN and/or another SFN neighbouring the SFN to the multicast or broadcast service.
8. The method of claim 7, further comprising: checking if the other SFN neighbouring the SFN has resources allocated to non-multicast or broadcast services that may be re-allocated; and wherein the step of allocating resources comprises allocating resources from non-multicast or broadcast services within the SFN and/or the other SFN neighbouring the SFN to the multicast or broadcast service.
9. The method of claim 8, wherein the step of allocating available resources comprises allocating at least one resource common to both the SFN and the other SFN neighbouring the SFN from non-multicast or broadcast services to the multicast or broadcast service.
10. The method of any one of claims 7 to 9, wherein the resource comprises a combination of a radio channel and a defined time period.
11. The method of any one of claim 7 to 10, wherein the step of checking if the SFN has resources and/or the step of checking if the other SFN neighbouring the -21 -SEN has resources allocated comprises checking for resources in use for providing non-multicast or broadcast services may be re-allocated and wherein the step of allocating resources from non-multicast or broadcast services comprises re-allocating the resources in use for providing non-multicast or broadcast services to the multicast or broadcast service.
12. The method of any preceding claim, wherein the multicast or broadcast service comprises transmissions including data encoded within a plurality of data frames, each frame comprising a plurality, n, of subframes (n»=2), the method further comprising: using the resource manager to allocate one or more of the subframes in at least some of the data frames to carry the transmissions.
13. The method of claim 12, wherein multicast or broadcast service data is carried in each of the frames, the method further comprising: using the resource manager dynamically to allocate the number of subframes in each data frame, in accordance with the prevailing resource requirements.
14. The method of claim 13, further comprising using the resource manager to allocate the multicast or broadcast service data to the same number of subframes in each frame.
15. The method of any one of claims 12 to 14, further comprising using the resource manager to reserve one or more subframes of each frame for use by a unicast service, when it is determined that the number of subscriber terminals using the unicast service exceeds a threshold number.
16. The method of any preceding claim, wherein the step of using the resource manager to allocate resources across the cellular network comprises one or more of: sharing of resources at a base station between a baseband unit of the base station and other radio resources; changing resource blocks allocated -22 -to the multicast or broadcast service at a base station; frequency or band load sharing of subscriber terminals to be provided with the multicast or broadcast service between transmission frequencies and/or base stations; during low load, moving subscriber terminals from one frequency band to another to allow switching off of radio resources at one or more base stations.
17. The method of any preceding claim, wherein the multicast or broadcast service employs a Multimedia Broadcast Multimedia Service, MBMS.
18. The method of claim 17, wherein the cellular network is a Long Term Evolution, LTE, network and the multicast or broadcast service employs an enhanced Multimedia Broadcast Multimedia Service (eMBMS).
19. A computer program which, when executed by a processor, carries out the method of any preceding claim within the said cellular network.
20. A resource manager at least logically associated with one or more base stations in a cellular network, the resource manager being operable to allocate resources across that cellular network in accordance with any of claims 1 to 18.