HK1151158A - System and method for signaling availability of an mbms user service in multiple variants - Google Patents

Description

System and method for signaling availability of MBMS user services in multiple variants

Technical Field

The present invention generally relates to multimedia broadcast/multicast services (MBMS). More particularly, the present invention relates to signaling and processing information in an MBMS environment.

Background

This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily all those previously conceived or pursued. Therefore, references made in this section to the description and claims in this application are not prior art, and are not admitted to be prior art by inclusion in this section, except where expressly specified herein.

The third generation partnership project (3GPP) has defined MBMS for delivering multimedia content to a large set of receivers simultaneously. The 3GPP has published a set of MBMS specifications that cover all aspects of this service from radio access to content delivery applications and protocols.

MBMS can be divided into 3 general aspects-bearer services, delivery methods, and user services and applications. The MBMS bearer service provides a bit pipe for transporting IP traffic to a group of receivers in an efficient manner. Two delivery methods have been defined in MBMS-streaming and file downloading. Streaming delivery methods define protocols for delivering multimedia content for immediate consumption (e.g., mobile television channels). The file download delivery method supports the casting of multimedia files for storage and delayed consumption at the receiver. Complementary procedures for describing MBMS user services, for protecting delivered content, and for enhancing delivery robustness have also been defined. The MBMS user service can then utilize different delivery methods, unicast connections, associated procedures and MBMS bearer services for providing the desired application to the user.

The 3GPP Technical Specification (TS)26.346 section 11 specifies the metadata syntax for describing MBMS user services. The service description may be used to announce/advertise an upcoming multicast/broadcast event. The service description is mainly used to describe different delivery methods, access parameters for the service and any content protection applied to the service. 3GPP TS 25.346 describes an MBMS Radio Access Network (RAN).

One type of MBMS network is MBMS over single frequency network (mbsfn). The MBSFN mode uses a 16-QAM modulation scheme, for example, quadrature amplitude modulation with 16 constellation points. This modulation scheme provides higher bandwidth for MBMS user services than other schemes. However, MBSFN may not have large coverage and may be limited to certain locations in the MBMS network. Conventional coexistence such as non-MBSFN, MBMS and MBSFN may take at least several years.

In 3GPP release 7, media codec requirements are updated in order to support higher quality services. Specifically, the h.264 codec level has been upgraded from 1b (e.g., QCIF resolution of 128kbps (kilobits/second)) to 1.2 (e.g., CIF resolution of 384 kbps). To address the increased bit rates in the new regulatory classes, a larger bandwidth capacity is required than that provided by conventional MBMS bearer services (e.g., 256 kbps). One viable commercial arrangement involves providing low quality services to 3GPP release 6(Rel-6) terminals that are tailored to their capabilities. A release 7 terminal supporting MBSFN may benefit from increased capacity and receive higher quality of service. Currently, the user equipment is limited by the availability of MBSFN coverage and selects the service variant best suited for the user's needs.

Disclosure of Invention

Various embodiments provide systems and methods for signaling the availability of an MBMS user service in a number of variations. Various embodiments relate to using the additional capacity introduced by MBSFN in order to carry higher quality or more robust variants of services in MBMS. A broadcast multicast service center (BM-SC) may provide the same MBMS user services in two variants, one for regular MBMS and the other for MBSFN. The MBSFN variant of the service may be charged differently and then need to be protected separately. According to various embodiments, a user equipment is notified of: the same service exists in different variants. The user equipment may then select one of the available variants for consumption.

With various embodiments, partial deployment of MBSFN may be implemented in certain areas of an MBMS network while providing the same user services across MBSFN areas and regular MBMS areas. The extra capacity provided by MBSFN may be used to deliver different variants of services, e.g. services representing higher quality levels. The user equipment is provided with information about different variants of the services provided in each area and the relationship between these variants. Based on this information, the user equipment may then decide to switch from one variant to another variant when moving between different areas. According to one embodiment, the user equipment may switch back to regular service when leaving the MBSFN coverage area.

These and other advantages and features of the invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.

Drawings

Fig. 1 is a representation of an example situation where a user equipment product moves out of an MBSFN area and into a regular MBMS cell;

fig. 2 is a graphical representation showing a handover procedure between a conventional MBMS network and an MBSFN when a user equipment is consuming a specific user service;

fig. 3 is a flowchart illustrating an exemplary procedure by which a user equipment can join a regular MBMS service or an MBSFN service;

fig. 4 is a flow chart illustrating an exemplary procedure by which a user equipment may join a regular MBMS service or an MBSFN service in response to the user equipment leaving a current cell while the MBMS service is being consumed;

FIG. 5 is an overview diagram of a system in which various embodiments may be implemented;

FIG. 6 is a perspective view of an electronic device that may be used in conjunction with the implementation of various embodiments of the present invention; and

fig. 7 is a schematic representation of circuitry that may be included in the electronic device of fig. 6.

Detailed Description

In MBSFN, signals from multiple cells may be combined by the user equipment in a similar manner to combining multipath signal components from a single cell. The user equipment receiving the MBMS service provided in MBSFN mode does not affect the user equipment's behavior on unicast carriers. In particular, the mobility of the user equipment on the unicast carrier is not affected by the reception of the MBMS service provided on the cell operating in MBSFN mode and may imply: reception of MBMS services provided on a cell operating in MBSFN mode may become impossible due to limited support for band combinations for MBMS single frequency network reception and unicast reception.

MBSFN requires that all receiving nodes involved in simulcast transmissions using conventional MBMS and MBSFN are strictly time synchronized and that the same content is delivered to each of the involved receiving nodes. It is assumed that all such involved nodes share the same Controlling Radio Network Controller (CRNC). It should be noted that MBSFN areas are limited to areas controlled by a single Radio Network Controller (RNC).

For Time Division Duplex (TDD), some or all of the time slots may utilize an MBSFN transmission mode. Such time slots are configured by the RNC to use the same scrambling code on the participating receiving nodes. Any non-MBSFN slots continue to use the scrambling code associated with the cell ID. The slots operating in MBSFN mode are formed together, while synchronized neighboring cells transmit exactly the same data on the MBSFN cluster. For Frequency Division Duplexing (FDD), receiving nodes participating in MBSFN transmission operate on all time slots of a radio frame. Thus, MBSFN transmission occupies the entire carrier in FDD case. For TDD, part or all of the carriers may be used for MBSFN. An MBSFN-enabled user equipment may receive MBMS via a carrier operating in FDD or TDDMBSFN mode, and may also acquire unicast and MBMS services (e.g., services not provided via MBSFN by another carrier).

In conjunction with MBSFN, higher order modulation techniques (e.g., 16-QAM) may be used for the secondary common control physical channel (S-CCPCH), and with 3.84/7.68 megacycles per second (Mcps) TDD, higher order modulation techniques of the new burst type may be used to support longer delay spreads. Receiving MBMS services over a network operating in MBSFN mode typically requires the user equipment to register with a Public Land Mobile Network (PLMN) in order to perform higher layer procedures, such as subscribing to MBMS broadcast services. The user equipment may obtain the service details via a point-to-point connection through the carrier for providing unicast service. The user equipment selects an MBSFN cluster to receive the MBMS service as part of one of the registered PLMNs or part of an equivalent PLMN list. It should be noted that with the ability to broadcast multiple PLMNs in a Master Information Block (MIB), network sharing is supported on carriers operating in MBSFN mode as if it were supported on carriers supporting unicast services.

For MBSFN clusters in 1.28Mcps TDD mode, there may be no configured physical synchronization channel and pilot channel, and there may be no MBSFN cluster selection/reselection procedure. A user equipment that needs to receive an MBMS service delivered in an MBSFN cluster may first get synchronized with a non-MBSFN cell associated with the MBSFN cluster. The user equipment may then search for MBSFN clusters with information indicated in the system information of the non-MBSFN cells. From the user equipment's perspective, the registered PLMNs of the MBSFN cluster may be the same as the PLMNs that the user equipment registered from the associated unicast carrier.

The MBSFN cluster may provide MBMS service only in a point-to-multipoint (PtM) mode. Counting and point-to-point (PtP) establishment procedures may not be supported in cells operating in MBSFN mode.

For FDD and 3.84/7.68Mcps TDD, selection between MBSFN clusters is done in a manner similar to cell selection performed for cells not operating in MBSFN mode. The user equipment may consider the minimum received power of a common pilot channel (CPICH) (FDD) or a primary common control physical channel (P-CCPCH) (3.84/7.68Mcps TDD) in order to determine when to receive the MBMS service broadcasted in the MBSFN mode. However, the user equipment may not be required to perform inter-frequency measurements for other MBSFN clusters except for the background search procedure for receiving other MBSFN clusters.

In an MBSFN cluster, MIB may be broadcast only, i.e. system information blocks 3, 5/5 repeats (bis) and 11. The content of the other system information blocks may be ignored by the user equipment. MBSFN clusters on one frequency may indicate the services and presence provided by other MBSFN clusters on a different frequency. MBSFN clusters on one frequency may also indicate other MBSFN frequencies that have to be selected so that the user equipment knows available services that are not provided by the currently selected MBSFN cluster and whose availability is not indicated on the current MBSFN cluster. The selection of MBSFN frequencies based on this information is implemented specifically for the user equipment. The selection of MBSFN frequencies by the user equipment may be completely service dependent, since inter-frequency measurements for MBSFN frequencies are not available. For FDD and 3.84/7.68Mcps TDD, the user equipment may only need to find one MBMS cluster on another frequency that meets the selection criteria. Other frequencies on which the MBMS service is broadcast in MBSFN mode are indicated on MBSFN frequencies.

Clusters operating in MBSFN mode do not provide paging information because MBSFN clusters are not seen by the user equipment as suitable cells. Cells in the MBSFN cluster belong to a different MBMS service area than cells of the carrier providing unicast service. This allows the RNC to know which services are intended to be transmitted on the cells of the MBSFN cluster. The same MBMS bearer service may not be provided on both the MBSFN cluster and the unicast cell. The minimum MBMS service area must be equal to one MBSFN cluster. The MBMS bearer service is transmitted in a complete MBSFN cluster.

The following describes example embodiments for a TDD user equipment operating on a carrier in MBSFN mode. In various embodiments, TDD user equipment operating on a carrier that is not MBSFN-dedicated complies with MBMS procedures specified for radio resource control state. Receiving MBMS on a cell operating in MBSFN mode is independent of the reception of services on the frequency on which the user equipment is logged in to acquire the user equipment behavior of unicast or MBMS services. For receiving MBMS services on a TDD cell dedicated to MBSFN operation, the user equipment is conceptually an independent component that receives MBMS services on a TDD cell dedicated to MBSFN.

The TDD component of the user equipment for receiving MBMS services on a TDD carrier dedicated to downlink MBSFN may perform various tasks. For example, the TDD component can receive services provided via MBSFN independent of RRC state transition for any non-MBSFN component of the user equipment. The TDD component can also obtain details regarding a Multicast Control Channel (MCCH) provided via a Broadcast Control Channel (BCCH) of a cell providing MBSFN and can listen to the MCCH for details of MBMS services provided in a p-t-m fashion on a TDD Downlink (DL) -only carrier. In addition, the TDD component can search for an appropriate TDD MBSFN cluster that provides MBMS services that it may be interested in. Each TDD MBSFN only needs to support the Broadcast Channel (BCH) and Forward Access Channel (FACH) transport channels as well as the physical channels P-CCPCH, SCCPCH and SCH on a TDD carrier. TDD MBSFN may optionally support MBMS notification indicator channel (MICH) on TDD carrier and it is also expected to receive S-CCPCH configuration information by system information block 5 via BCH on TDD carrier (user equipment only expects to receive system information blocks 3, 5 and 11 in addition to the master information block).

The following describes exemplary embodiments for FDD user equipment on a carrier operating in MBSFN mode. In various embodiments, FDD user equipment operating not dedicated to MBSFN complies with the MBMS procedures specified for the radio resource control state. Receiving MBMS on a cell operating in MBSFN mode is independent of user equipment behaviour for receiving services on the frequency on which the user equipment is logged in to acquire unicast or MBMS services. For receiving MBMS services on an FDD cell dedicated to MBSFN operation, the user equipment is conceptually a separate component that receives MBMS services on an FDD cell dedicated to MBSFN.

An FDD component of a user equipment operating in a receive-only mode on an FDD carrier operating in an MBSFN mode may perform various tasks. For example, the FDD component may receive services provided via MBSFN independent of RRC state transition for any non-MBSFN components of the user equipment. The FDD component may also acquire details related to the MCCH provided via the BCCH of the cell providing the MBSFN and may listen to the MCCH for details of MBMS services provided on FDD-only Downlink (DL) carriers in a p-t-m manner. Further, the FDD component may search for an appropriate FDD MBSFN cluster. Each FDD MBSFN is only required to support BCH and FACH transport channels and physical channels P-CCPCH, SCCPCH, MICH and SCH on FDD carriers. The FDD MBSFN may optionally support MICH on FDD carriers and it is also desirable that it receives S-CCPCH configuration information by system information block 5 via BCH on FDD carriers (in addition to the master information block, the user equipment only desires to receive system information blocks 3, 5 and 11).

Various embodiments provide systems and methods for signaling the availability of an MBMS user service in a number of variations. Various embodiments relate to using the additional capacity introduced by MBSFN in order to carry higher quality or more robust variants of the service in MBMS. The broadcast multicast service center (BM-SC) provides the same MBMS user services in two variants, one for regular MBMS and the other for MBSFN. The MBSFN variant of the service may be charged differently and then need to be protected separately. According to various embodiments, a user equipment is notified of: the same service exists in different variants and thus the user equipment may then select one of the available variants for consumption.

With various embodiments, partial deployment of MBSFN may be implemented in certain areas of an MBMS network while providing the same user services across MBSFN areas and regular MBMS areas. The extra capacity provided by MBSFN may be used to deliver different variants of services, e.g. services representing higher quality levels. The user equipment is aware of the relationship between the different variants of the service so that it can switch back to the regular service when leaving the MBSFN coverage area.

If concurrent reception of MBSFN and regular MBMS is feasible, the MBSFN broadcast may carry data that is complementary to the regular MBMS broadcast. For example, an enhanced video layer according to Scalable Video Coding (SVC) may be broadcast by an MBSFN cluster, while a base video layer is broadcast with a regular MBMS cell. Another example relates to sharing one media component (e.g., an audio stream) with a conventional MBMS broadcast while providing a high quality variant of the video stream over MBSFN.

The relation between different transmissions (MBMS multicast/broadcast and MBSFN broadcast) is indicated to the user/user equipment. In various embodiments, this relationship may be alternative or supplemental.

Implementations of various embodiments relate to using signaling in MBMS service descriptions. Different variants of the service and their respective relationships are described to the user/user equipment. In one particular implementation, a "userServiceDescription" XML fragment is extended to signal: the user service description is a variant of the same MBMS user service. The following is an example of a modified "userServiceDescription" fragment:

<？xml version＝″1.0″encoding＝″UTF-8″？>

<xs:schema xmlns＝″urn:3GPP:metadata:2005:MBMS:userServiceDescription″

xmlns:xs＝″http://www.w3.org/2001/XMLSchema″

targetNamespace＝″urn:3GPP:metadata:2005:MBMS:userServiceDescription″elementFormDefault＝″qualified″>

<xs:element name＝″bundleDescription″type＝″bundleDescriptionType″/>

<xs:complexType name＝″bundleDescriptionType″>

<xs:sequence>

<xs:element name＝″userServiceDescription″type＝″userServiceDescription Type″maxOccurs＝″unbounded″/>

<xs:any namespace＝″##other″minOccurs＝″0″maxOccurs＝″unbounded″processContents＝″lax″/>

</xs:sequence>

<xs:attribute name＝″fecDeseription URI″type＝″xs:anyURI″use＝″optional″/>

<xs:anyAttribute processContents＝″skip″/>

</xs:complexType>

<xs:complexType name＝″userServiceDescriptionType″>

<xs:sequence>

<xs:element name＝″name″type＝″nameType″minOccurs＝″0″maxOccurs＝″unbounde d″/>

<xs:element name＝″serviceLanguage″type＝″xs:language″minOccurs＝″0″maxOccurs＝″unbounded″/>

<xs:element name＝″requiredCapabilities″type＝″requirementsType″minOccurs＝″0″maxOccurs＝＝″1″/>

<xs:element name＝″serviceGroup″type＝″serviceGrouptype″maxOccurs＝″unbounded″/>

<xs:element name＝″deliveryMethod″type＝″deliveryMethodType″maxOccurs＝″unbounded″/>

<xs:element name＝″accessGroup″type＝″accessGroupType″minOccurs＝″0″maxOccurs＝″unbounded″/>

<xs:any namespace＝″##other″minOccurs＝″0″maxOccurs＝″unbounded″processContents＝″lax″/>

</xs:sequence>

<xs:attribute name＝″serviceId″type＝″xs:anyURI″use＝″required″/>

<xs:anyAttribute processContents＝″skip″/>

</xs:complexType>

<xs:complexType name＝″accessGroupType″>

<xs:sequence>

<xs:element name＝″accessBearer″type＝″xs:string″maxOccurs＝＝″unbounded″/>

</xs:sequence>

<xs:attribute name＝″id″type＝″accessGroupIdType″use＝″required″/>

</xs:complexType>

<xs:complexType name＝″deliveryMethodType″>

<xs:sequence>

<xs:any namespace＝″##other″minOccurs＝″0″maxOccurs＝″unbounded″processContents＝″lax″/>

</xs:sequence>

<xs:attribute name＝″accessGroupId″type＝″accessGroupIdType″use＝″optional″/>

<xs:attribute name＝″associatedprocedureDescriptionURI″type＝″xs:anyURI″use＝″optional″/>

<xs:attribute name＝″protectionDescriptionURI″type＝″xs:anyURI″use＝″optional″/>

<xs:attribute name＝″sessionDeseriptionURI″type＝″xs:anyURI″use＝″required″/>

<xs:attribute name＝″accesspointName″type＝″xs:anyURI″use＝″optional″/>

<xs:anyAttribute processContents＝″skip″/>

</xs:complexType>

<xs:complexType name＝″nameType″>

<xs:simpleContent>

<xs:extension base＝″xs:string″>

<xs:attribute name＝″lang″type＝″xs:language″use＝″optional″/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:simpleType name＝″accessGroupIdType″>

<xs:restriction base＝″xs:nonNegativeInteger″>

</xs:restriction>

</xs:simpleType>

<xs:complexType name＝″requirementsType″>

<xs:sequence>

<xs:element name＝″feature″type＝″xs:unsignedInt″minOccurs＝″1″maxOccurs＝″unbounded″/>

</xs:sequence>

</xs:complexType>

<xs:complexType name＝″serviceGroupType″>

<xs:sequence>

<xs:element name＝″serviceRef″type＝″xs:anyURI″minOccurs＝″0″maxOccurs＝”unbounded”>

</xs:sequence>

<xs:attribute name＝″groupID″type＝″xs:anyURI″use＝″required″/>

<xs:attribute name＝″relationship″type＝″serviceRelationType″use＝″required″/>

</xs:complexType>

<xs:simpleType name＝″serviceRelation Type″>

<xs:restriction base＝″xs:string″>

<xs:enumeration value＝″alternative″>

<xs:enumeration value＝″Base″>

<xs:enumeration value＝″Enhancement″>

</xs:restriction>

</xs:simpleType>

</xs:schema>

the following is an exemplary instantiation of two user service descriptions, including alternative variants of the same user service. The second of the two service descriptions includes a capacity requirement to check the support for MBSFN.

<userServiceDescription serviceId＝″http://www.example.com/servicel/alternativel″>

<name lang＝″en″>Service 1，QCIF</name>

<serviceLanguage>en</serviceLanguage>

<requiredCapabilities>

<feature>2</feature>

<feature>6</feature>

</requiredCapabilities>

<deliveryMethod sessionDescriptionURI＝″http://www.example.com/servicel/alternativel/session.sdp″/>

<serviceGroup groupID＝″group 1″relationship＝″alternative″/>

</userServiceDescription>

</bundleDescription>

----------------------------------------------------------------

<bundleDescription fecDescriptionURI＝″http://www.example.com/servicel/alternative2/fec.sdp″>

<userServiceDescription serviceId＝″http://www.example.com/servicel/alternative2″>

<name lang＝″en″>Service 1，CIF</name>

<serviceLanguage>en</serviceLanguage>

<requiredCapabilities>

<feature>2</feature>

<feature>13</feature>

<feature>14</feature>

</requiredCapabilities>

<deliveryMethod sessionDescriptionURI＝″http://www.example.com/servicel/alternative2/session.sdp″/>

<serviceGroup groupID＝″group 1″relationship＝″alternative″/>

</userServiceDescription>

</bundleDescription>

Fig. 3 is a flow diagram illustrating one exemplary embodiment of a process by which a user equipment may select an appropriate service based on MBSFN support and availability. At 300 of fig. 3, a user equipment processes a received service announcement. At 310, it is determined whether a service alternative is available using MBSFN, i.e., whether the service can be provided by using MBSFN completely. If not, the user equipment simply joins the regular MBMS service at the desired time at 320. However, if the service is available by using MBSFN, the user equipment checks if it can support MBSFN and if the user equipment prefers a higher capacity service at 330. If the service over MBSFN is not desired by or not supported by the user equipment, the user equipment joins the regular MBMS service at the desired time at 350. However, if service over MBSFN is supported and desired at 340, the user equipment checks the availability of MBSFN at 360 and determines whether the user equipment is in an MBSFN area at 370. For example, the network may transmit information to the user equipment via a paging channel regarding whether the current area is an MBSFN coverage area, and this information may be used to make a decision. If the user equipment is not in the MBSFN area, the user equipment joins the regular MBMS service at the desired time at 380. On the other hand, if the user equipment is in the MBSFN area, then at 390, the user equipment joins the MBSFN service at the desired time. As previously described, the user equipment may also receive service over both regular MBMS and MBSFN at 390 in some cases, such as where the enhancement information is provided over MBSFN and the base information is provided over regular MBMS. It should be noted that the various processes depicted in fig. 3 may be performed in a different order than described herein. For example, the user equipment may check whether it supports MBSFN before checking whether it provides service in MBSFN mode.

Another embodiment relates to the case where the user equipment moves out of the MBSFN area and into an area supported only by the regular MBMS service. This is depicted in fig. 1 as a whole, where the user equipment 100 exits the MBSFN coverage area 110 and then enters a regular MBMS cell 120, i.e. a cell without MBSFN coverage. In response to this movement, a handover has to take place between MBSFN and regular MBMS in order to maintain reception of the service in question. An exemplary embodiment of a handover is depicted in fig. 2. In fig. 2, the BM-SC200 broadcasts or multicasts both regular MBMS (for consumption in the regular MBMS coverage area 210) and MBSFN (for consumption in the MBSFN coverage area 110). When the user equipment 100 switches from the MBSFN coverage area 110 to the regular MBMS coverage area 210 (or vice versa), the handover procedure allows the user equipment 100 to continue receiving the same user service, albeit possibly at a different quality level.

Fig. 4 is a flow diagram illustrating an exemplary process that may occur when a user equipment leaves a current cell while consuming an MBMS service, indicated at 400. At 410, it is determined whether a specific MBMS service is available through both modes, e.g., MBSFN and regular MBMS. If the service is provided only through the conventional MBMS, the user equipment continues to receive the conventional MBMS service at 420. However, if the service is provided through both the conventional MBMS and the MBSFN, the paging information is checked at 430 and it is determined whether the next cell supports MBSFN at 440. If the next cell (e.g., the cell to which the user equipment moved) does not support MBSFN, then at 450 the user equipment continues to receive or join the regular MBMS service if not already doing so. If the next cell supports MBSFN, the user equipment checks user preferences, settings and MBSFN capabilities of the user equipment at 460 and determines whether the user equipment desires and supports MBMS services over MBSFN at 470. If the user equipment does not desire or support services over MBSFN, the user equipment joins the regular MBMS service at the desired time at 480. However, if a service over MBSFN is desired and supported, then at 490, the user equipment joins the MBMS service over MBSFN. As previously described, at 490, in some cases, the user equipment may also receive services over both regular MBMS and MBSFN, such as where the enhancement information is provided over MBSFN and the base information is provided over regular MBMS. It should be noted that the various processes depicted in fig. 4 may be performed in a different order than described herein.

Fig. 5 illustrates a system 10 in which various embodiments may be used, including a plurality of communication devices that may communicate over one or more networks. The system 10 may comprise any combination of wired or wireless networks including, but not limited to, a mobile telephone network, a wireless Local Area Network (LAN), a bluetooth personal area network, an ethernet LAN, a token ring LAN, a wide area network, the internet, etc. System 10 may include both wired and wireless communication devices.

For example, the system 10 shown in fig. 5 includes a mobile telephone network 11 and the internet 28. The communication network 11 may be a mobile telephone network, a digital broadcast broadband network or any other similar communication network and combinations thereof. Communications between entities of the communication network 11 may be unidirectional or bidirectional. Connectivity to the internet 28 may include, but is not limited to, long range wireless connections, short range wireless connections, and various wired connections including, but not limited to, telephone lines, cable lines, power lines, and the like.

Exemplary communication devices of system 10 may include, but are not limited to, mobile electronic devices 50 in the form of mobile telephones, combined Personal Digital Assistants (PDAs) and mobile telephones 14, PDAs 16, Integrated Messaging Devices (IMDs) 18, desktop computers 20, notebook computers 22, and the like. The communication device may be stationary or mobile while being carried by a traveling person. The communication device may also be in a mode of transportation including, but not limited to, an automobile, truck, taxi, bus, boat, airplane, bicycle, motorcycle, etc. Some or all of the communication devices may send and receive calls and messages over a wireless connection 25 to the base station 24 and communicate with the service provider over the wireless connection 25 to the base station 24. The base station 24 may be connected to a network server 26, which server 26 supports communication between the communication 11 and the internet 28. The system 10 may include additional communication devices and different types of communication devices.

The communication devices of the various embodiments discussed herein may communicate using various transmission techniques including, but not limited to, Code Division Multiple Access (CDMA), global system for mobile communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), transmission control protocol/internet protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), email, Instant Messaging Service (IMS), bluetooth, IEEE 802.11, and the like. A communication device may communicate using various media including, but not limited to, radio, infrared, laser, cable connection, and the like.

Figures 6 and 7 illustrate one representative mobile telephone 12 within which various embodiments may be implemented. Any or all of the devices described herein may include any and/or all of the features described in fig. 6 and 7. It should be understood, however, that the present invention is not intended to be limited to one particular type of electronic device. The mobile telephone 12 of figures 6 and 7 includes a housing 30, a display 32 in the form of a liquid crystal display, a keypad 34, a microphone 36, an ear-piece 38, a battery 40, an infrared port 42, an antenna 44, a smart card 46 in the form of a UICC according to one embodiment, a card reader 48, radio interface circuitry 52, codec circuitry 54, a controller 56 and a memory 58. The individual circuits and elements are all of a type well known in the art.

The present invention is described in the general context of method steps or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

Software and web implementations of the various embodiments could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps or processes, correlation steps or processes, comparison steps or processes and decision steps or processes. It should also be noted that the words "component" and "module," as used herein and in the claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.

Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside on a chipset, mobile device, desktop computer, laptop computer, or server. The application logic, software or an instruction set is preferably maintained on any one of a variety of conventional computer-readable media. In the context of this document, a "computer-readable medium" can be any media or means that can contain, store, communicate, propagate, or transport the instructions for use by or in connection with the instruction execution system, apparatus, or device.

The foregoing description of embodiments has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit embodiments of the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments were chosen and described in order to explain the principles and the nature of various embodiments and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all combinations of methods, apparatus, modules, systems, and computer program products.

Claims (26)

1. A method, comprising:

determining whether a service is provided at least through a multimedia broadcast/multicast service (MBSFN) over a single frequency network;

if the service is provided through MBSFN, performing at least one of the following:

determining whether the user equipment supports MBSFN and desires to receive the service using the MBSFN; and

determining whether the user equipment is in an area capable of receiving the MBSFN;

processing the service using a conventional multimedia broadcast/multicast service (MBMS) if the user equipment does not support MBSFN, if the user equipment does not wish to receive the service using the MBSFN, or if the user equipment is not located in an area capable of receiving the MBSFN; and

if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is located in an area capable of receiving the MBSFN, processing the service using the MBSFN.

2. The method of claim 1, wherein the determination of whether the service is provided at least over the MBSFN is made in response to the user equipment moving between cells while consuming an MBMS service.

3. The method of claim 1, wherein the determination of whether the service is provided over the MBSFN is made in response to the user equipment receiving a service advertisement.

4. The method of claim 1, wherein if the service is not provided through MBSFN, the service is received using the regular MBMS.

5. The method of claim 1, wherein if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is in an area capable of receiving the MBSFN, the service is received using both the MBSFN and the regular MBMS.

6. The method of claim 1, wherein if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is in an area capable of receiving the MBSFN, the service is received using only the MBSFN.

7. The method of claim 1, wherein the determination of whether the service is provided at least over the MBSFN is made based on signaling received from the remote device.

8. A computer program product, embodied on a computer-readable medium, comprising computer code for performing the processes of claim 1.

9. An apparatus, comprising:

a processor; and

a memory unit communicatively connected to the processor and comprising:

computer code for determining whether a service is provided at least over a multimedia broadcast/multicast service (MBSFN) over a single frequency network;

computer code for, if the service is provided over MBSFN, performing at least one of:

determining whether the user equipment supports MBSFN and desires to receive the service using the MBSFN; and

determining whether the user equipment is in an area capable of receiving the MBSFN;

computer code for processing the service using conventional multimedia broadcast/multicast service (MBMS) if the user equipment does not support MBSFN, if the user equipment does not wish to use the MBSFN to receive the service, or if the user equipment is not located in an area capable of receiving the MBSFN; and

computer code for, if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is located in an area capable of receiving the MBSFN, processing the service using the MBSFN.

10. The apparatus of claim 9, wherein the determination of whether the service is provided at least over the MBSFN is made in response to the user equipment moving between cells while consuming an MBMS service.

11. The apparatus of claim 9, wherein the determination of whether the service is provided over the MBSFN is made in response to the user equipment receiving a service advertisement.

12. The apparatus of claim 9, wherein the service is received using the regular MBMS if the service is not provided through MBSFN.

13. The apparatus of claim 9, wherein if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is in an area capable of receiving the MBSFN, the service is received using both the MBSFN and the regular MBMS.

14. The apparatus of claim 9, wherein if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is in an area capable of receiving the MBSFN, the service is received using only the MBSFN.

15. The apparatus of claim 9, wherein the determination of whether the service is provided at least over the MBSFN is made based on signaling received from the remote device.

16. An apparatus, comprising:

means for determining whether a service is provided at least through a multimedia broadcast/multicast service (MBSFN) over a single frequency network;

means for performing, if the service is provided over MBSFN, at least one of:

determining whether the user equipment supports MBSFN and desires to receive the service using the MBSFN; and

determining whether the user equipment is in an area capable of receiving the MBSFN;

means for processing the service using regular multimedia broadcast/multicast service (MBMS) if the user equipment does not support MBSFN, if the user equipment does not wish to receive the service using the MBSFN, or if the user equipment is not located in an area capable of receiving the MBSFN; and

means for processing the service using the MBSFN if the user equipment supports MBSFN, if the user equipment wishes to receive the service using the MBSFN, and if the user equipment is located in an area capable of receiving the MBSFN.

17. A method, comprising:

transmitting a service to a user equipment through at least one of a conventional multimedia broadcast/multicast service (MBMS) and a multimedia broadcast/multicast service (MBSFN) over a single frequency network;

transmitting signaling information to the user equipment regarding whether the service is provided over the MBSFN,

thus, the user equipment may use the transmitted information to determine whether it should handle the service over at least the MBSFN.

18. The method of claim 17, wherein the signaling information comprises information related to: if the service is provided over the MBSFN, whether the service being transmitted over the MBSFN is one of an alternative and a complement to the service being transmitted over conventional MBMS.

19. The method of claim 18, wherein if the service being transmitted over the MBSFN is complementary to the service being transmitted over the regular MBMS, the service being transmitted over the MBSFN includes enhancement information and the service being transmitted over the regular MBMS includes base information.

20. The method of claim 17, wherein the signaling information is transmitted in at least one user service description fragment.

21. A computer program product, embodied on a computer-readable medium, comprising computer code for performing the processes of claim 17.

22. An apparatus, comprising:

a processor; and

a memory unit communicatively connected to the processor and comprising:

computer code for transmitting a service to a user equipment over at least one of a conventional multimedia broadcast/multicast service (MBMS) and a multimedia broadcast/multicast service over a single frequency network (MBSFN);

computer code for transmitting signaling information to the user equipment regarding whether the service is provided over the MBSFN,

thus, the user equipment may use the transmitted information to determine whether it should handle the service over at least the MBSFN.

23. The apparatus of claim 22, wherein the signaling information comprises information related to: if the service is being provided over the MBSFN, whether the service being transmitted over the MBSFN is one of an alternative and a complement to the service being transmitted over a regular MBMS.

24. The apparatus of claim 23, wherein, if the service being transmitted over the MBSFN is complementary to the service being transmitted over the regular MBMS, the service being transmitted over the MBSFN includes enhancement information and the service being transmitted over the regular MBMS includes base information.

25. The apparatus of claim 22, wherein the signaling information is transmitted in at least one user service description fragment.

26. An apparatus, comprising:

means for transmitting a service to a user equipment through at least one of a conventional multimedia broadcast/multicast service (MBMS) and a multimedia broadcast/multicast service (MBSFN) over a single frequency network;

means for transmitting signaling information to the user equipment regarding whether the service is provided over the MBSFN,

thus, the user equipment may use the transmitted information to determine whether it should handle the service over at least the MBSFN.