Technique for distributing content via different bearer types

Description of equivalent WO 2007068290 A1

0001Technique for Distributing Content via Different Bearer Types

0002Field of the Invention

0003The invention generally relates to the field of content distribution services such as television (TV) services. In particular, the invention relates to a content distribution technique that employs different transport bearer types.

0004Background of the Invention

0005Today, mobile TV services and other content distribution services are delivered over existing networks using so-called unicast delivery. Unicast delivery means that each user terminal gets its own unique data connection for accessing one or more content channels. One drawback of this approach is that it does not scale satisfactorily if an increasing number of user terminals is starting to use a particular service.

0006An alternative to unicast delivery is broadcast delivery. In a broadcast scenario each content channel is distributed to all user terminals simultaneously. In this way, the number of data connections can be significantly reduced because the number of re- quired data connections only depends on the number of distributed content channels and no longer on the number of active user terminals.

0007Although broadcasting reduces the number of required data connections, it is important to understand that broadcasting is not always the most efficient way of deJiver- ing content channels. In a typical broadcast scenario, content channels are transmitted even if there are no user terminals listening to them since the broadcasting system does not have any knowledge about who is listening to a channel and who is not. Furthermore, the transmission power of a broadcast bearer in a radio cell cannot be adapted to the receive conditions of different user terminals. Instead it must be sufficiently high such that even user terminals with bad coverage can still receive a good enough signal.

0008Compared to broadcast, unicast delivery has the advantage that network resources are only allocated if requested. Furthermore, with unicast delivery a base station can optimize its transmission power for each user terminal individually such that user terminals closer to the base station require less power than user terminals further away.

0009In addition to broadcast and unicast, multicast is a third transport alternative. Multi- cast adds group management capabilities to broadcast. However, support for multicast requires an increased implementation effort. Multicast support can for example be provided via the Multimedia Broadcast Multicast Service (MBMS).

0010Conventional TV content channels are typically located for a long time on one physi- cal transport bearer. This means that a frequency or a location in a multiplex scheme is permanently assigned to one content channel. Today's TV does not implement any function to automatically re-configure the content transmission parameters. However, there is also no need to offer a TV channel re-location functionality, since anyhow all transport channels are broadcast transport channels.

0011There is a need for a content distribution/reception technique that allows to make use of the combined advantages of different bearer types.

0012Summary of the Invention

0013According to one aspect of the invention, a method is provided for controlling the distribution of content via a first bearer type including at least one broadcast bearer and a second bearer type including at least one non-broadcast bearer. The method comprises the steps of providing a plurality of content channels, wherein each con- tent channel is associated with at least one of a bearer of the first type and a bearer of the second type, maintaining mapping information for the content channels, the mapping information being indicative of the associations between content channels and bearer types, and controlling content distribution in accordance with the associations between content channels and bearer types.

0014Each content channel can be distributed via exactly one bearer or simultaneously with a plurality of bearers. In the case a content channel is distributed via a plurality of bearers, the plurality of bearers may include at least one bearer of the first type and at least one bearer of the second type. The step of maintaining mapping information can be performed in various ways and may include at least one of generating, storing, and modifying (e.g. updating) mapping information. In one example, the mapping information comprises for each content channel a content channel identifier (such as a particular rank within a list or an explicit channel descriptor) and an associated access descriptor (e.g. an abstract denotation of a particular bearer type or an explicit description of a bearer having a particular bearer type). A mapping scheme comprising the mapping information can be realized in the form of an abstract mapping function, in the form of an explicit mapping table and/or in any other form suitable for establishing an association be- tween one or more content channels on the one hand and different bearer types on the other hand.

0015The at least one non-broadcast bearer may comprise at least one unicast bearer and the at the least one broadcast bearer may comprise at least one multicast bearer. In addition to, or instead of, the at (east one multicast bearer, the at least one broadcast bearer may comprise one or more conventional broadcast bearers.

0016The method may further comprise the step of transmitting the mapping information to a recipient of one or more content channels. According to a first variant, the map- ping information is transmitted before the content recipient actually starts receiving content via one or more of the content channels. The first variant may be performed to notify the content recipient of the bearer and/or bearer type via which a particular content channel is or will be transmitted. According to a second variant, that can be combined with the first variant, the mapping information is transmitted to a content recipient while the content recipient is receiving one or more content channels. The second variant permits the content recipient to keep track of modifications in the mapping information. The modifications may result from switching a particular content channel between two bearers of the same type and/or of different bearer types.

0017Accordingly, the method may further comprise the steps of initiating bearer switching for at least one content channel between two bearers of the same type and/or of different bearer types, and maintaining the mapping information by modifying (i.e. updating) the mapping information in accordance with the bearer switching. Preferably, the modified mapping information is transmitted at least to those recipients cur- rently receiving the one or more content channels for which bearer switching has been or will be initiated. In a further implementation, the method additionally comprises the steps of evaluating switching control information, and deciding about initiation of bearer switching based on a result of the evaluation. The switching control information may include at least one of content usage information, time of the day, predicted user interest, and location information (such as a cell identifier) with regard to mobile content recipients. The switching control information (such as, in particular, content usage information and location information) may be gathered from the various content recipients. To this end, the content recipients may be configured to generate and transmit switching control information.

0018According to another aspect of the present invention, a method of selectively receiving content via one of a first bearer type including at (east one broadcast bearer and a second bearer type including at least one non-broadcast bearer is provided. The method comprises the steps of accessing mapping information indicating that a par- ticular content channel is distributed via at least one of a bearer of the first type and a bearer of the second type, and switching to a bearer of the type indicated in the mapping information for reception of the particular content channel.

0019The above method may additionally comprise the step of receiving modified mapping information during reception of the particular content channel. Thus, modifications in the mapping information for the particular content channel may be monitored, and based on detected modifications in the mapping information bearer switching may be performed.

0020A non-broadcast bearer (such as a unicast bearer) may be established between a content distribution controller and a content recipient not only for content reception. The non-broadcast bearer may for example also, or alternatively, be employed for an initial or repeated transfer of mapping information from the content distribution controller to the content recipient. Also, the non-broadcast bearer may be used for transmitting switching control information from the content recipient to the content distribution controller. Preferably, the non-broadcast bearer is maintained during a content distribution session regardless of bearer type changes taking place during the content distribution session with respect to the particular content channel to which the content distribution session pertains.

0021The invention may be practised in the form of a hardware solution, as a software solution or as a software/hardware combination. As far as a software solution is con- cerned, a computer program product is provided comprising program code portions for performing the steps of the method when the computer program product is run on one or more computing devices. The computer program product may be stored on a computer readable recording medium.

0022According to a hardware aspect, a device for controlling the distribution of content via a first bearer type including at least one broadcast bearer and a second bearer type including at least one non-broadcast bearer is provided. The controlling device comprises a provision component for providing a plurality of content channels, wherein each content channel is associated with at least one of a bearer of the first type and a bearer of the second type, a maintenance component for maintaining mapping information for the content channels, the mapping information being indicative of the associations between content channels and bearer types, and a controller for controlling the content distribution in accordance with the associations between content channels and bearer types.

0023According to a further hardware aspect, a device for selectively receiving content via one of a first bearer type including at least one broadcast bearer and a second bearer type including at least one non-broadcast bearer is provided. The receiving device comprises an access component for accessing mapping information indicating that a particular content channel is distributed via at least one of a bearer of the first type and a bearer of the second type, and a switch for switching to a bearer of the type indicated in the mapping information for reception of the particular content channel.

0024Brief Description of the Drawings

0025In the following, the invention will be described with reference to exemplary embodiments illustrated in the drawings, wherein:

0026Fig. 1 is a process flow diagram of a first method embodiment of the invention;

0027Fig. 2 is a process flow diagram of a second method embodiment of the present invention;

0028Fig. 3 is a schematic diagram of a content distribution controller embodiment of the present invention; Fig. 4 is a schematic diagram of a content recipient embodiment of the present invention;

0029Rg. 5 is a first schematic signalling diagram that can be utilized in the embodiments 5 of the present invention;

0030Rg. 6 is a second schematic signalling diagram that can be utilized in the embodiments of the present invention;

0031o Rg. 7 is a third schematic signalling diagram that can be utilized in the embodiments of the present invention; and

0032Rg. 8 is a process flow diagram of a channel switching embodiment of the present invention. 5

0033Detailed Description of the Preferred Embodiments

0034In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular sequences of steps, signalling protocols and o device configurations in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art that the present invention may be practised in other embodiments that depart from these specific details.

0035Moreover, those skilled in the art will appreciate that the functions explained herein 5 below may be implemented using software functioning in conjunction with a programmed microprocessor or general purpose computer, and/or using an application specific integrated circuit (ASIC). It will also be appreciated that while the current invention is primarily described in the form of methods and devices, the invention may also be embodied in a computer program product as well as a system compris- o ing a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that may perform the functions disclosed herein.

0036The technique of separating logical content channels from the underlying transport 5 bearers illustrated below advantageously supports a dynamic mapping between logical content channels and transport bearers of different types. The hybrid approach combining broadcast and non-broadcast bearers facilitates dynamic changes in the mapping with respect to non-broadcast transmitted content channels and broadcast transmitted content channels. It is thus possible to offer content distribution services such as mobile TV services selectively via a unicast network, an MBMS network, a Digital Video Broadcast-Handheld (DVB-H) network or any other network type in a resource optimized and flexible manner. Also, the content distribution concept can be implemented such that it is completely transparent to the user which bearer type is used for delivery of a particular content channel. This means that the user does in general not notice whether a content channel is delivered over a broadcast or non- broadcast bearer.

0037Fig. 1 shows a process flow diagram 100 of a first method embodiment relating to the control of content distribution via a first bearer type including at least one broadcast bearer and a second bearer type including at least one non-broadcast bearer.

0038In a first step 102, a plurality of content channels are provided. Each content channel is associated with at least one of a bearer of the first type and a bearer of the second type. For example, a first content channel may be associated with a broadcast bearer, a second content channel may be associated with a unicast bearer, and third content channel may associated with both a broadcast bearer and a unicast bearer.

0039In a second step 104, mapping information for the plurality of content channels is maintained. The mapping information is indicative of content channel/bearer type associations. In one variation, the maintenance of mapping information includes generating mapping information in accordance with the associations of step 102.

0040In a further step 106, content distribution is controlled in accordance with the content channel/bearer type associations. In this regard, the mapping information may constitute control information for the content distribution. However, according to another option, the mapping information may simply be reflective of the content dis- tribution control In the latter case, steps 104 and 106 may be performed in any order.

0041Fig. 2 shows a process flow diagram 200 of another method embodiment relating to the reception of content via one of a first bearer type including at least one broadcast bearer and a second bearer type including at least one non-broadcast bearer. In a first step 202, mapping information is accessed. The mapping information indicates that a particular content channel is distributed via a particular bearer type.

0042In a next step 204, switching to a bearer of the bearer type indicated in the mapping information is performed to enable reception of the particular content channel. The switching may be performed prior to reception of the particular content channel and/or during reception of the particular content channel.

0043In the following, two network components of a network system that permits the dy- namic distribution of content via different bearer types will be described in more detail. In this regard, Fig. 3 shows the network backend architecture in the form of a content distribution control device 300. The device 300 not only allows for a dynamic content distribution control. It also provides the content distribution sen/ices requested by one or more user terminals acting as clients.

0044When a new user terminal requests a content distribution service, a device component 1 first checks the terminal capabilities. If the requesting terminal does not support broadcast reception, it will receive a channel mapping table describing a "unicast-only" mapping in which all content channels are mapped to unicast bearers. This "unicast-only" mapping table is provided by component 2 and forwarded by component 1 via a first control connection to the terminal. If, on the other hand, the terminal is known to support broadcast reception, it will receive a mapping table which typically associates one or more content channels with unicast bearers and one or more further channels with broadcast bearers. This mapping table is provided by component 3 and forwarded by component 1 via the first control connection to the terminal.

0045A channel replication component 4 is configured to receive all incoming media packets corresponding to the available content channels. The channel replication compo- nent 4 replicates the incoming media packets for further processing both at the broadcast selector component 5 and the unicast selector component 6.

0046The broadcast selector component 5 maps media packets belonging to the content channels configured for broadcast distribution to k output channels which are further processed for delivery over broadcast bearers. In an optional encryption component 9, the k output channels generated in the broadcast selector component 5 are encrypted if service access protection is required. Without encryption, every user terminal capable of receiving broadcast channels can receive the content channels delivered over the broadcast bearers.

0047The encryption component 9 forwards the encrypted data packets to a broadcast gateway 10. The broadcast gateway 10 maps the incoming packet flows to the individual broadcast bearers as indicated by BCl to BCk.

0048The unicast selector component 6 selectively handles content channels that are to be delivered over unicast bearers. For each connected user terminal, the unicast selector component 6 selects one of the incoming content channels and forwards the corresponding media packets to the unicast connection established for the particular user terminal. Channel selection (and channel switching) requests are received from connected terminals via a second control connection and in accordance with a separate control protocol as will now be described in more detail.

0049In the present embodiment, the Real Time Streaming Protocol (RTSP) is used for establishing a unicast connection to a user terminal. To this end, an RTSP control component 7 communicating with the user terminal via a third control connection is provided. It should be noted that RTSP is only one possibility for connection establishment. Instead of RTSP, other control protocols fulfilling the same purpose could in principle also be used.

0050Still referring to Fig. 3, an optional service access protection component 8 is handling service access protection for those user terminals that are connected via unicast connections. The service access protection component 8 prevents unauthorized users from using a particular content service by checking for each incoming connection request whether the user terminal is actually authorized to use the content service.

0051Referring now to Fig. 4, the client side of the network system for content distribution will be explained in more detail. Fig. 4 shows a device 400 for selectively receiving content via different bearer types.

0052The device 400 includes an application component 402 that receives, via a first control connection, channel mapping information in the form of a mapping table from the server side shown in Fig. 3. The mapping table is maintained in a channel map- ping storage component 404. The mapping information contained in the mapping table is used by the receiver selection component 406 and the broadcast receiver component 408 as will be described below in more detail.

0053A second control connection is used by the application 402 to send channel selection commands to the backend device shown in Fig. 3, whereas a third control connection is used to establish a unicast connection via RTSP. To this end, an RTSP control component 410 is provided.

0054As shown in Fig. 4, unicast data are received by a unicast receiver component 412 via a unicast bearer (fourth connection), whereas broadcast data are received by the broadcast receiver component 408 via one or more broadcast bearers (fifth connection).

0055If the user selects a channel which is received over a unicast bearer, the receiver selection component 406 forwards packets received via the unicast bearer for further processing to a data/media splitter component 414. If, on the other hand, a channel is selected which is received over a broadcast bearer, the receiver selection component 414 forwards packets received over one of the broadcast bearers. An optional decryption component (not shown) decrypts packets received via the broadcast bearers in the case access protection is enabled.

0056The data/media splitter component 414 receives the packets forwarded by the receiver selection component 406 and separates mapping data received over a (logical) mapping data channel from media data. The mapping data channel is used to optionally send updates of the channel mapping table (e.g. as side information over the unicast or broadcast channels) in the case channel mapping is changed. The mapping data is forwarded by the data/media splitter component 414 to a mapping data processing component 416 which modifies the channel mapping information stired by the component 404 accordingly. The media data, on the other hand, is decoded and displayed to the user by the media processing component 418.

0057In a preferred implementation, the receiving device 400 - when it connects to the serving device 400 - first establishes a unicast connection through a session estab- lishment protocol such as RTSP. The unicast connection can be kept open through the lifetime of the content delivery session between the two devices 300, 400. However, the serving device 300 preferably only sends data over the unicast connection if the receiving device 400 has requested a channel which is (currently) delivered over a unicast bearer. Otherwise, the receiving device 400 receives the content channel over a broadcast bearer (while the unicast connection remains established). In addition to the unicast connection, the receiving device 400 can listen to one or more content channels on broadcast bearers. Preferably, the broadcast channels are delivered through MBMS (although other broadcast technologies could be used as well).

0058In the following, various signalling embodiments showing messages that can be ex- changed between the devices shown in Figs. 3 and 4, or any other devices adapted for distribution and reception of content channels via different bearer types, will be discussed. The embodiments will be explained with respect to the distribution of content in the form of mobile TV services. Of course, the signalling could also be used in context with other content distribution services.

0059In Fig, 5, a mobile TV start sequence messaging scenario for obtaining service configuration data at client application start-up is shown. When a user starts a local mobile TV client application 502 in the user terminal, the client application 502 sends a startreq message via the Hypertext Transfer Protocol (HTTP) to a mobile TV server application 504. The client application 502 could for example reside on the reception device 400 of Fig. 4, whereas the server application 504 could reside on the content distribution controlling device 300 of Fig. 3.

0060As shown in Fig. 5, the server application 504 responds to the start. req message with a startres message. The start.res message includes (among other information) service configuration information (in the form of a service configuration file) and the current channel mapping table.

0061The service configuration file describes content channels and transport bearer sepa- rately such that a dynamic mapping between content channels and transport bearers can be defined. The content channels in the service configuration file can be uniquely identified by a number, by a character string or by any other identification means. This identification allows to match the content channel descriptions with the local "key-binding" in the user terminal. In the service configuration file, the transport bearers are also uniquely identified, for example by their position within a list or by an explicit identifier (e.g. by a ServicelD). For each broadcast bearer used by a particular content distribution service, the following parameters should be specified:

0062IP Multicast Address/APN - ServicelD (optional)

0063Uniform Resource Identifier (URI) of Session Description Protocol (SDP) file

0064Since the unicast transport bearer is "shared" among all content channels, it needs to be specified just once by an SDP:

0065URI of SDP file

0066The reference to the SDP file contained in the Service Description can be local (e.g. the SDP may be contained in the Service Description) or it points to a server from which the SDP file can be obtained.

0067Additionally, each user terminal needs to know the address of the application server which receives any channel switching requests.

0068Also, each user terminal needs to know the channel mapping table. The channel mapping table describes the mapping between content channels and transport bearers listed in the Service Description. Assuming that five content channels are numbered from 1 to 5, and further assuming that there are two available broadcast bearers BC#1 and BC#2, the mapping table could look as follows:

0069I UC 2 UC 3 BC#1 4 UC

00705 BC#2

0071This mapping table indicates that content channels 3 and 5 are delivered over broadcast bearers BC#1 and BC#2, respectively, whereas all other content channels are delivered over unicast bearers. If required, one or more of the content channels may be associated with both a broadcast bearer and a unicast bearer. This means that the particular content channels could be received both via broadcast and via unicast. If the channel mapping changes while a user terminal is connected to the content server, the user terminal may be informed about the new channel mapping as exem- plarily shown in the signalling diagram of Fig. 6.

00725

0073To inform the mobile TV client application 502 about modifications in the channel mapping table, the mobile TV server application 504 sends an update message which includes a file (ChannelMap.conf) indicative of the new channel mapping. The update message may be distributed via all FLUTE data channels belonging to the particular o mobile TV service. This may include MBMS broadcast channels, Packet-Switched (PS) streaming channels (unicast), DVB-H broadcast channels, and other channels. The client application 502 may thus receive multiple copies of the ChannelMap.conf file.

0074The channel mapping may for example change in such a manner that the server aps plication 504 starts forwarding media packets of content channels via broadcast bearers and stops forwarding media packets of these channels over unicast bearers for clients who are able to receive broadcast transmissions. If an updated channel mapping indicates a transport bearer change - either from unicast to broadcast or vice versa - for the channel a user terminal is currently receiving, the client applica- o tion 502 running on the user terminal must change the input connection accordingly. This means in the embodiment shown in Fig. 4 that the receiver selection component 406 switches either from broadcast to unicast reception or vice versa.

0075The switch from a broadcasted content channel to a content channel delivered over a 5 unicast bearer (or vice versa) may explicitly be requested by a user terminal or commanded by the server application 504. If the user terminal requests such a switch, there exist two possible scenarios.

0076In a first scenario, the user terminal requests a switch from a broadcasted content o channel to content channel delivered over unicast. In this case, the client application 502 sends a general "change channel" command to the server application 504 as shown in the lower half of Fig. 6. The "change channel" command may include an indication of the content channel in question. The server application 504 locally detects that the channel in question is to be delivered over a unicast bearer and starts 5 forwarding media packets over the (preferably already established) unicast connection. As an alternative, the client application 502 could command the server application 504 explicitly to deliver the data of the indicated content channel over a unicast bearer. The client application 502 then stops listening to the broadcast bearer and starts listening to the unicast connection instead.

0077According to a second scenario, the user terminal requests a switch for a particular content channel that is currently delivered over a unicast connection to a broadcast bearer. Again, the client application 502 may send a general "change channel" command to the server. The server then locally detects that the requested content channel is to be delivered over a broadcast bearer and stops forwarding the media packets over the unicast bearer. Alternatively, the client application 502 could com- mand the server application 504 explicitly to stop the delivery of media packets over the unicast bearer. Then, the client stops listening to the unicast bearer and starts listening to the broadcast bearer instead.

0078In the embodiment shown in Rg. 6, either the client application 502 or the server application 504 decide independently about bearer switching. In a particular useful bearer switching implementation, the client application 502 running on the user terminal provides the server application 504 with switching control information (such as usage information and/or location information with regard mobile user terminals). The server application 504 gathers switching control information from various client application 502, evaluates the gathered switching control information, and decides about initiation of bearer switching based on a result on the evaluation. In addition, or alternatively, the server application 504 may take other switching control information such as time of the day and/or predicted user interest into account. Thus, a network operator operating the server application 504 can adapt the mapping based on usage statistics, based on interest shifts (a news channel may for example get more attention during an election day), based on the time of the day (during evening hours other content channels are of interest than in the afternoon), etc.

0079In the following, various exemplary bearer switching concepts will be discussed in more detail. In general, bearer switching aims at associating content channels of high interest (i.e. with many listening user terminals) with broadcast bearers and at associating content channels of lower interest with unicast bearers.

0080In the case of a unicasted content channel, an operator may derive usage informa- tion from the server application (such as a mobile TV server application or a streaming server application). However, for broadcasted content channels an operator generally does not have content usage information. Moreover, an operator of a mo- bile network can often not determine whether a group of connected user terminals is located in one and the same coverage cell (i.e. in a densely populate cell) or spread over a large number of coverage cells. This is sometimes a drawback because in the case of a densely populate cell, it would often be efficient to transfer a unicasted content channel to a broadcast bearer. These and other problems are addressed by the following embodiments.

0081First, a scenario relating to content distribution via a unicast bearer (e.g. a mobile TV service delivered via PS streaming) will described with reference to Rg. 7. In this scenario, the server application 504 is readily aware of usage information for individual content channels as it keeps tracks of the established unicast connections. In general, each user terminal has activated an RTSP streaming session and often also an HTTP based channel control session. The client application 502 running on the user terminal may thus send a channel switching command via HTTP to the server application 504 as shown in Rg. 7. For mobile content delivery solutions such as mobile TV solutions the channel switching command may not only include a channel identifier, but additionally a cell identifier or any other geographical identifier. In the case of mobility (e.g. handovers between neighbouring cells), cell identifier changes may be sent to the server application 504 via an update message. As an alternative, the server application 504 could retrieve location information for the mobile terminal on which the client application 502 is running by contacting the network based location information service associated with the mobile terminal.

0082If no HTTP based channel control session is available (e.g. in the case of a plain PS streaming solution), location information could be forwarded inside the RTSP session set-up message. Updated location information could be provided via the RTSP Set Params method. Alternatively, the server application 504 could use the network based location information service to get the required location information.

0083As a second scenario, content distribution via broadcast bearers (using e.g. MBMS or DVB-H) will be described. In broadcast scenarios, there is typically no usage or location feedback from the client applications. Legacy TV receivers, for example, do not include any functionality to send a usage report towards the network. Mobile TV receivers, however, are often integrated into third generation (3G) handsets and can therefore be configured to send usage report towards the network. The usage reports may be sent in particular time intervals (such as once every fifteen minutes) or together with event reports or request (e.g. relating to channel changes). In princi- ple, there are several alternatives to add a usage report functionality to client applications.

0084According to a first variant, usage reports could provided via a HTTP based feedback mechanism. According to the HTTP variant, the client application may use the HTTP POST method to upload usage information, or the HTTP GET message to request a new channel. Additionally, switching control information such as a cell identifier, an area identifier or, in the case of DVB-H, a multiplex identifier may be incorporated into the uploaded document or included into the HTTP header. The content channel identifier of the previously consumed (e.g. watched) content channel could also be provided as feedback.

0085Based on the content usage information, a usage reporting component of the server application may keep track of the number of users per content channel. To this end, a channel usage histogram may be used. In the case of a time based usage reporting scheme, either the identifier of the currently consumed content channel may be reported or, in the alternative, a detailed histogram (or statistics) of the content channels selected by the user within the particular reporting period.

0086Instead of a HTTP based feedback approach, the session initiation protocol (SIP)/IP multimedia subsystem (IMS) Notify method is used in a second variant. According to this variant, the server application subscribes to the usage reporting event on the user terminal. Optionally, a "virtual subscription" may be used. This means that the SIP/IMS notification procedure could be configured without subscribe method from the server application. The notification message can be generated responsive to a channel change event or on a timed basis (e.g. in regular intervals). In the case the notification message is triggered by a change of a content channel, the Notify message can be sent immediately after the content channel has been changed. Optionally, the previously consumed content channel may be a part of the notification.

0087The above variants exemplarily illustrated a few possibilities for providing switching control information such as content usage information and location information to the server application. Based on the switching control information received from the client applications and/or determined locally, the server application may dynamically change the channel/bearer type mapping. In the following, an embodiment of a dynamic mapping mechanism will be described with reference to the process flow diagram 800 of Rg. 8. The mechanism shown in Hg. 8 is started periodically per content channel. Alternatively, the mechanism could be executed per content channel after a predefined amount of channel switching events have occurred. For instance, the mechanism may be executed each time after 1000 changes to and/or from a particular content channel have been counted.

0088Referring now to Rg. 8, the mechanism starts with a waiting period 802. During the waiting period 802, it is constantly monitored in step 804 whether a timer has expired. The timer may be set, for example, somewhere between 5 and 60 minutes (e.g. to 15 minutes).

0089Upon expiry of the timer in step 804, the method proceeds with step 806. Step 806 determines if location information is available for the user terminals receiving the particular content channel. In the case no (or no precise) location information is available, the mechanism proceeds with step 808. In step 808, a mean member den- sity assuming a homogenous usage in the service area is determined. On the other hand, if it is determined in step 806 that location information is available, the mechanism proceeds with step 810. In step 810 the mean member density per coverage cell is calculated. Optionally, the mechanism may additionally calculate a peak density, give a 95% tile or apply any weighting function.

0090After the mean member density per cell has been calculated in either one of steps 808 and 810, the mechanism proceeds with step 812. In step 812 it is determined if the particular content channel for which the mechanism is executed is mapped to a unicast bearer. If it is determined that the channel is mapped to a unicast bearer, it is then determined in step 814 if the mean density is above a predefined broadcast switching threshold. If the mean density is above the predefined broadcast switching threshold, then the content channel currently transmitted via a unicast connection is put on a broadcast bearer in step 820.

0091If, on the other hand, it is determined in step 812 that the particular content channel is currently not mapped to a unicast bearer, it is then determined in a next step 816 if the mean member density is below a predefined unicast switching threshold. Should the mean member density be below the unicast switching threshold, then, in step 822, the channel currently associated with a broadcast bearer is put on a uni- cast bearer. Accordingly, the broadcast switching threshold and the unicast switching threshold ensure that the available resources are utilized in an efficient manner. In the case of a high mean member density, content distribution via a broadcast bearer generally makes better use of the available resources, while in the case of a low mean member density unicast transmission is preferred. It should be noted that the mechanism may use different thresholds for switching to a broadcast bearer and for switching to a unicast bearer. Optionally, a hysteresis may be implemented to avoid flip-flop effects. One possible hysteresis implementation prevents further transport bearer switches during a predefined period of time (or before a predefined number of channel change events) after the last transport bearer switch has occurred. Another option would be to change the transport bearer mapping only if the determinations in blocks 814 and 816 have repeatedly indicated the need for a change in the mapping scheme.

0092After a bearer switching operation decision in step 820 or in step 822 has been performed, or if the mean member density is below the broadcast switching threshold/above the unicast switching threshold (decision blocks 814 and 816), the timer is reset in step 818 and the mechanism loops back to step 802.

0093In context with bearer switching in either one of steps 820 and 822, the mapping information (such as a mapping table) will need to be updated. According to a first option, the updated mapping scheme (or an updated, channel-related portion thereof) may immediately be sent to the active client applications. According to another option, the updated mapping scheme (or mapping scheme portion) is only sent after the mechanism shown in Fig. 8 has been executed for all content channels. In the case of the second option, the actual bearer switching (steps 820 and 822) may be executed only after all content channel mappings have been checked. Optionally, the decision relating to mapping changes may also consider the capabilities of the connected user terminals. If, for example, a large portion of the user terminals has no broadcast capabilities, a change of the transport bearer mapping to broadcast bearers is often not feasible.

0094As has become apparent from the above description of preferred embodiments, the content distribution technique described herein allows a seamless integration of uni- cast and broadcast delivery within the same type of service (which, in some of the examples is mobile TV). This integration allows a network operator to decide which content channels are to be delivered over unicast bearers and which should be deliv- ered over broadcast bearers. With an additional decision mechanism it is possible to automatically select a channel mapping scheme which utilizes the available broadcast bearers in an efficient manner. Another advantage is the fact that legacy user terminals (e.g. user terminals supporting only unicast content distribution) can connect to 5 a service even if some content channels are scheduled for broadcast transmission. In such a scenario, the content channels may then additionally be delivered via unicast connections to the legacy user terminals,

0095In the above embodiments, the server application keeps track of how many user io terminals are currently listening to a particular content channel. Accordingly, the server application can optimize the mapping between content channels and transport bearers. In one implementation, those content channels with the highest number of users will be mapped to the available broadcast transport bearers, whereas the remaining content channels are delivered over unicast bearers. Of course, more sophis- i5 ticated mapping implementations could be used as well.

0096While the present invention has been described with respect to particular embodiments (including certain device arrangements and certain orders of steps within various methods), those skilled in the art will recognize that the present invention is not 2o limited to the specific embodiments described and illustrated herein. Therefore, it is to be understood that this disclosure is only illustrative. Accordingly, it is intended that the invention be limited only by the scope of the claims appended hereto.

009725

009830