WO2013127423A1

WO2013127423A1 - Apparatus and method for streaming content

Info

Publication number: WO2013127423A1
Application number: PCT/EP2012/053247
Authority: WO
Inventors: Mats Cedervall; Niklas Fondberg
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-02-27
Filing date: 2012-02-27
Publication date: 2013-09-06

Abstract

A method of streaming content comprises the steps of receiving (401) requests from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation, for example hyper text transfer protocol, and determining (405) whether the number of requests for the particular content has reached a threshold value. If so, the streaming of the particular content is triggered (407) to switch from the unicast mode of operation to a multicast mode of operation to the plurality of end nodes.

Description

Apparatus and Method for Streaming Content

Technical Field

The present invention relates to an apparatus and method for streaming content, and in particular to an apparatus and method for delivering content using a unicast mode such as hyper text transfer protocol (HTTP) and a multicast mode. Background

The internet is used to deliver content, such as multimedia content, between one node and another. Internet Protocol Television (IPTV) is a term used when delivering content in the form of broadcast TV services over an IP network, typically a broadband access network. The predominant IPTV service is

Broadcast TV, in which the normal non-IPTV channels, as well as additional channels with low penetration (i.e. channels that are less common), are transmitted over the broadband network from a head-end down to a user-end, for example a set top box (STB) of a user. It has become more and more common to stream unicast content using Hyper Text Transfer Protocol (HTTP) over recent years. The main reasons for this are that on the open internet HTTP is simple to use and it is error tolerant. HTTP also has the advantage of being able to pass through firewalls without problems.

More recently HTTP Adaptive Streaming (HAS) has gained increased interest. HAS refers to the case where the bandwidth of the stream is adjusted to suit the needs of a particular end user. For example, the bandwidth and processing capacity of an end user can be detected in real time, and used to adjust the quality of the content stream accordingly. As such, a tradeoff between quality and download speed can be provided to end users. In some systems the user can indicate the tradeoff required, while in other systems the tradeoff can be controlled automatically. HTTP Adaptive Streaming has also gained popularity in managed systems because of the inexpensive servers and other equipment that can be used. In particular, HTTP fragments can be cached by HTTP cache servers, without the caching servers needing to have any additional knowledge about what the files contain.

HTTP is particularly cost-efficient for systems where a user watches a large number of different content streams, for example YouTube™ video clips and other open internet video services. Among managed services, other

applications such as Personal Video Recorders (PVRs), TV of yesterday, time- shift TV, and so forth, can use HTTP in an efficient way.

Figure 1 shows an example of a conventional system, in which a HTTP cache server 101 streams unicast HTTP content 103i to 103_N to a plurality of ends nodes 105i to 105_N, each comprising a browser 107i to 107_N.

However, a disadvantage of HTTP is that, when it is used to send content to many users simultaneously, for example a live football match that is being watched simultaneously by many end users, the same content is sent in unicast mode to each of the end users. For example, if 100,000 users are watching the same football match over the internet the same packets will be sent 100,000 times through the network. This has the disadvantage of requiring a large network capacity, and reducing the amount of bandwidth available to network operators for other uses, or the amount of bandwidth available for other end users. As a result network nodes and cache servers can easily become overloaded, and all other HTTP traffic can suffer as a consequence.

Summary

It is an aim of the present invention to provide a method and apparatus which obviate or reduce at least one or more of the disadvantages mentioned above. According to a first aspect of the present invention, there is provided a method of streaming content. The method comprises the step of receiving requests from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation. The method comprises the steps of determining whether the number of requests for the particular content has reached a threshold value and, if so, triggering the streaming of the particular content to switch from the unicast mode of operation to a multicast mode of operation to the plurality of end nodes.

According to another aspect of the invention, there is provided a method for providing multicast content to a plurality of end nodes. The method comprises the steps of receiving a control signal from a unicast server node, the control signal indicating that a particular content stream is required to be streamed in a multicast mode of operation, informing the unicast server node of a multicast address that is to be used for the multicast streamed content, and streaming the particular content using a multicast mode of operation.

According to another aspect of the invention, there is provided a node for controlling the streaming of content to end nodes. The node comprises a receiving unit for receiving request signals from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation. A node comprises a processing unit configured to determine whether the number of requests for the particular content has reached a threshold value and, if so, trigger the streaming of at least some of the particular content to switch from the unicast mode of operation to a multicast mode of operation to the plurality of the end nodes.

According to another aspect of the present invention, there is provided an end node for receiving content from a remote node. The end node comprises an interface unit configured to transmit a request signal to a remote node, for requesting receipt of a particular content. The interface unit is configured to include an indication in the request signal that the end node is capable of switching from a unicast mode of receiving content to a multicast mode of receiving content.

According to another aspect of the present invention, there is provided a node for multicasting content to a plurality of end nodes. The node comprises a processing unit adapted to receive a control signal from a unicast server node, the control signal indicating that a particular content stream is required to be streamed in a multicast mode of operation. The processing unit is further adapted to inform the unicast server node of the multicast address to be used for the multicast streamed content. The node comprises a converter unit adapted to convert content received in a unicast format into a multicast signal for transmission to the end nodes.

According to another aspect of the present invention, there is provided a network as defined in the appended claims.

Brief description of the drawings

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the following drawings in which: Figure 1 shows a typical network for streaming content to end users using Hyper Text Transfer Protocol (HTTP);

Figure 2 shows a network according to an embodiment of the present invention; Figure 3 shows an example of the steps performed in the network according to the embodiment of Figure 2; Figure 4 shows the steps performed by a node of a network according to an embodiment of the invention; Figure 5 shows a node of a network according to an embodiment of the invention;

Figure 6 shows the steps performed by an end node of a network, according to an embodiment of the invention;

Figure 7 shows an end node of a network according to an embodiment of the invention;

Figure 8 shows the steps performed by a node for multicasting content in a network, according to an embodiment of the invention; and

Figure 9 shows a node for multicasting content in a network, according to an embodiment of the invention. Detailed description

It is noted that embodiments of the invention will be described below in relation to streaming content in the form of Internet Protocol Television (IPTV) using Hyper Text Transfer Protocol (HTTP). It is noted, however, that the invention is intended to embrace any type of content being streamed or delivered.

Furthermore, although the embodiments of the invention refer to the use of HTTP, other protocols providing unicast delivery are also intended to be embraced by the embodiments of the invention.

The embodiments of the present invention are concerned with redirecting or changing unicast streams, such as HTTP streams, to multicast streaming when many users are accessing the same unicast stream. For example, embodiments of the invention are configured to redirect HTTP streams from multicast servers when the number of users accessing the same content stream has reached a particular threshold. An overview of a network comprising various nodes according to embodiments of the invention will first be provided in relation to Figures 2 and 3.

Figure 2 shows a network comprising an end node 210 (or user node), a HTTP server node 230 and a multicast server node 240. Only one end node 210 is shown in the figure, although it will be appreciated that the network will comprise a plurality of such end nodes. Examples of end nodes are set-top- boxes (STBs) or internet protocol television terminals (IPTV terminals), although the invention is intended to embrace any type of end node. It is noted that although the multicast server node 240 is shown as forming a separate entity to the HTTP server node 230, the embodiments of the invention are also intended to encompass the functionality of the multicast server 240 being incorporated into the HTTP server node 230, or vice versa.

The end node 210 comprises an interface unit 21 1 configured to send HTTP request signals 212 to the HTTP server node 230. In addition to requesting the download of a particular content, a request signal 212 also contains an indication that the end node is able to switch from a unicast mode of operation to a multicast mode of operation. In other words, the request signal 212 provides an indication about whether or not the particular end node making the request is capable of switching from receiving content from a unicast source, to receiving content from a multicast source. The interface unit 21 1 therefore acts as a local unicast(HTTP)/Multicast proxy in the end node, that handles the requests coming from a browser 218. An end node 210 can provide the required indication in the HTTP header information, for example, that it supports multicast reception of HTTP fragments. The HTTP request signals 212 are typically generated by the browser 218 within the end node 210. The browser 218 may be a conventional browser, with the interface unit 21 1 adapted to provide the unicast/multicast indication. For example, a user-agent header can be used to convey information about the user agent, such as the capabilities etc of the user agent.

Alternatively, extension headers may be used to convey this information.

The HTTP server node 230 comprises a HTTP cache 231 for storing various content, such as video clips, TV footage, or any other form of content that a user may wish to receive. This content may in turn be received from a higher level source 250, such as the servers of a service provider. A receiving unit 232 receives request signals 212 from a plurality of end nodes 210, each end node 210 requesting the download of content. A processing unit 233 is configured to determine whether the number of requests for a particular content, for example a particular video clip, has reached a threshold value. If so, the processing unit 233 is configured to trigger the streaming of that particular content to switch from a unicast mode of operation to a multicast mode of operation to the plurality of end nodes 210. As such, the HTTP server 230 effectively notices that it has received a certain amount of requests for the same stream, and then triggers multicast streaming of that particular content. It is noted that all of the unicast streams for that particular content may be replaced by a multicast stream. Alternatively, at least part of the unicast streams for that particular content are replaced by a multicast stream.

The processing unit 233 of the HTTP server node 230 is configured to send a control signal 215 to the multicast server node 240. The HTTP server node 230 also sends the particular content 216, i.e. HTTP data, to the multicast node 240. Upon receiving the control signal 215, a processing unit 241 within the multicast node 240 is configured to provide the HTTP server node 230 with a multicast address that it intends using to multicast that particular content. The multicast server 240 also comprises a HTTP-to-Multicast converter 242 for converting the HTTP content into multicast format, for transmission as a multicast stream 217. File delivery over unidirectional transport, FLUTE, is an example of a protocol that can be used to deliver the HTTP fragments over the multicast stream 217, for example as described in the Internet Engineering Task Force (IETF)

Recommendation RFC 3926. The data itself is not changed, only the protocols used to carry the data. A HTTP fragment can be considered as a file that can be transported using the FLUTE protocol as described above.

Upon receipt of the multicast address, the HTTP server node 230 is adapted to inform one or more of the plurality of end nodes 210 of the multicast address for the particular content. As such the HTTP server node 230 responds to the end nodes by indicating that there is a multicast stream for this content. The multicast address can be conveyed using HTTP header information, for example. According to one embodiment the multicast address can be

transmitted to each end node 210 which has indicated in its request signal 212 that it has the ability to receive in unicast mode or multicast mode. Alternatively, the HTTP server can be configured to only transmit the multicast address to a certain number of end nodes 210, for example if only a certain amount of bandwidth needs to be saved, or depending on the number of end nodes that have requested a particular content. According to yet another alternative, the HTTP server node may be configured to send the multicast address to all end nodes that are receiving that particular content, regardless of whether or not the end nodes have indicated that they are able to receive in unicast or multicast modes. The multicast address may be sent in an extension header, or a URL format in a redirect signal, for example. The former is transparent to user agents that do not understand it. Other methods may also be used without departing from the invention.

Upon receipt of the multicast address from the HTTP server node 230, an end node 210 is able to join the multicast stream for that particular content. An end node 210 can join the multicast stream by sending out an IGMP_JOIN message, or other methods of joining multicast streams. The end node 210 can store the HTTP fragments it receives from the multicast steam 217 in a local cache 213. If a fragment is missing in the local cache 213 the end node 210 can either wait for the missing fragment to arrive on the multicast stream 217, or if that does not seem likely (for example because only newer fragments are being received on the multicast stream 217), it can request or retrieve the missing fragment (or fragments) from the HTTP server node 230.

Since the multicast server 240 transmits the same HTTP packets as would have been transmitted previously (albeit with a multicast address rather than a unicast address), the applications running in the end node devices (for example STBs) are not aware of how the packets were delivered.

Further details of the operation of the network shown in Figure 2 will now be given in relation to Figure 3. Figure 3 shows an example of the communication that might take place between end nodes 2010, HTTP server node 2030 and multicast server 2040 (corresponding to nodes 210, 230 and 240 of Figure 2, respectively). It is noted that the order of certain signals may be changed without departing from the scope of the invention. As mentioned above, communication between the HTTP server node 2030 and the multicast server node 2040 may take place between different network nodes, or within the same network node.

In step 301 a first end node 2010, for example a first STB (STB-i ), sends a request for the download of a particular HTTP content to the HTTP server node 2030. In step 302 the HTTP server node 2030 determines whether the number of requests for that particular content have reached or crossed a threshold. If not, the HTTP server node 2030 downloads a unicast HTTP content stream to the first end node, STB^ step 303 In step 304 a second end node 2010, for example a second STB (STB₂), sends a request for the download of the same particular HTTP content to a HTTP server node 2030. In step 305 the HTTP server node 2030 determines whether the number of requests for that particular content have reached or crossed a threshold. If not, the HTTP server node 2030 downloads a unicast HTTP content stream to the second end node, STB₂, step 306.

This process continues until step 307, in which an "Nth" end node 2010, for example a Nth STB (STB_N), sends a request for the download of the same particular HTTP content to the HTTP server node 2030. In step 308 the HTTP server node 2030 determines whether the number of requests for that particular content have reached or crossed a threshold. Upon detecting that the number of requests has reached a threshold, the HTTP server node 2030 then instructs the multicast server 2040 to commence multicast transmission of that particular content, step 309. The HTTP content to be multicast is also transmitted to the multicast server, step 310. Alternatively, this content may be received at the multicast server 2040 from another source, such as the source which normally provides the content to the HTTP server node 2030. It will be appreciated that these steps can be made in any order, or together.

In response to receiving a request to commence a multicast mode of operation, the multicast server 2040 provides a multicast address to the HTTP server node 2030, step 31 1 . The HTTP server node 2030 then informs a plurality of end nodes, for example STBi to STB_N, of the multicast address that is being used to multicast the desired content, steps 312, 314, 316. Upon receipt of the multicast address, each end node STBi to STB_N is able to switch to the multicast mode of operation, steps 313, 315 and 317, respectively. Each end node STBi to STB_N is then able to receive the multicast content stream, step 318.

It will be appreciated that some end nodes will begin to receive a particular content in unicast mode, i.e. from a unicast source, and then switch to receiving the same content from a multicast source during receipt of the particular content. However, it is noted that if a request for the particular content is received from an end node after the threshold has already been reached, then such an end node can receive the content in multicast mode from the outset. For example, upon checking if the threshold has been reached, the HTTP server can immediately inform the end node of the multicast address for that particular content, such that the new end node can start to receive the content in the multicast mode from the outset.

Figure 4 shows the steps performed by a node of a network according to an embodiment of the invention, for example the steps performed by a HTTP server node. In step 401 the node receives requests from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation, for example using a hyper text transfer protocol. In step 405 it is determined whether the number of requests for the particular content has reached a threshold value. If so, this triggers the streaming of the particular content to switch from a unicast mode of operation to a multicast mode of operation to the plurality of end nodes, step 407. If it is determined in step 405 that the threshold has not been reached, the content can be continued to be delivered in unicast mode to requesting end nodes, step 403.

The step of triggering a multicast mode of operation may comprise the steps of causing one or more of the end nodes to switch from a unicast mode of reception to a multicast mode of reception.

For example, the step of triggering a multicast mode of operation may comprise the steps of sending a control signal to a multicast server, the control signal indicating that a multicast mode of operation is to be used for the particular content, and receiving a multicast address from the multicast server, the multicast address relating to the address being used in the multicast mode of operation. One or more of the plurality of end nodes can then be informed of the multicast address for the particular content.

A request received from an end node may comprise an indication that the end node is able to switch from a unicast mode of operation to a multicast mode of operation. According to such a situation, the step of informing can be carried out with respect to a plurality of nodes which have indicated that they are able to switch from a unicast mode to a multicast mode. The unicast content is sent to the multicast server, for multicast transmission by the multicast server.

As indicated earlier, if a request for the particular content is received from an end node after the threshold has already been reached, then such an end node can receive the content in multicast mode from the outset. In such a scenario the method performed in the HTTP server node would comprise the steps of receiving from an end node a request for the particular content, and determining if the request contains an indication that the end node is able to receive content in both a unicast mode and a multicast mode. If so, it is determined whether the number of end nodes already receiving that particular content is above a threshold value and, if so, a multicast address is sent to the end node, for enabling the end node to join a multicast stream for that particular content.

Figure 5 shows a node of a network according to an embodiment of the invention, for example a node for controlling the streaming of content to end nodes. The node 500, for example a HTTP server node, comprises a receiving unit 532 for receiving request signals 503 from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation. The unicast mode can use a hyper text transfer protocol, for example. A processing unit 533 is configured to determine whether the number of requests for the particular content has reached a threshold value and, if so, trigger the streaming of at least some of the particular content to switch from the unicast mode of operation to a multicast mode of operation to the plurality of end nodes. According to one embodiment the content being streamed is stored in a HTTP cache 531 . The content may have been received in turn from a remote source 505 (not shown), or even stored at such a remote source, and passed to the end nodes under control of the HTTP server node 500. The processing unit 533 is adapted to send a control signal 507 to a multicast server, the control signal 507 indicating that a multicast mode of operation is to be used for the particular content. The processing unit 533 is also adapted to receive a multicast address from the multicast server, and inform one or more of the plurality of end nodes of the multicast address for the particular content. The multicast address may be sent in an extension header, or a URL format in a redirect signal, for example. The former is transparent to user agents or end nodes that do not understand it. Other methods may also be used without departing from the invention. Figure 6 shows the steps performed by an end node of a network, according to an embodiment of the invention. In step 601 the end node transmits to a remote node a request for the receipt of a particular content. The request comprises an indication that the end node is capable of switching from a unicast mode of receiving content to a multicast mode of receiving content.

According to one embodiment the method performed in the end node may also comprise the steps of receiving content from the remote node in a unicast mode of operation during a first period, and receiving a multicast address from the remote node. In such an embodiment the end node switches to receiving the content from a multicast source during a second period, in response to receiving the multicast address from the remote node. According to another embodiment, the method performed in the end node comprises the steps of receiving a multicast address from the remote node, and obtaining the content from a multicast source in response to receiving the multicast address from the remote node.

Figure 7 shows an end node 710 of a network according to an embodiment of the invention, for receiving content from a remote node using a unicast mode such as hyper text transfer protocol. The remote node may comprise a HTTP server node, for example. The end node 710 comprises an interface unit 71 1 configured to transmit a request signal 712 to a remote node, for requesting receipt of a particular content. The interface unit 71 1 is configured to include an indication in the request signal 712 that the end node is capable of switching from a unicast mode of receiving content to a multicast mode of receiving content.

The interface unit 71 1 may be adapted to switch from receiving content from a unicast source to receiving content from a multicast source, in response to receiving a multicast address from the remote node.

The end node 710 may comprise a local cache 713 for storing received content. The end node may also be adapted to retrieve any missing fragments of the received content from the remote node. Figure 8 shows the steps performed by a node for multicasting content in a network according to an embodiment of the invention, for example the steps performed by a multicast server node when providing content to a plurality of end nodes. The method comprises the steps of receiving a control signal from a unicast server node, the control signal indicating that a particular content stream is required to be streamed in a multicast mode of operation, step 801 . The node informs the unicast server node of a multicast address that is to be used for the multicast streamed content, step 805. The node streams the particular content using a multicast mode of operation, step 805. It is noted that steps 803 and 805 may be performed in any order, or simultaneously. The content to be multicast may be received from the unicast server node.

Alternatively, the content to be streamed may be received from another source. In such a scenario the unicast server node can inform the multicast server node where to retrieve the required content which is to be multicast. The step of streaming the content in the multicast mode of operation may comprise the step of streaming hyper text transfer protocol content using a file delivery over unidirectional transport scheme, known as a FLUTE scheme.

Figure 9 shows a node 900 for multicasting content in a network according to an embodiment of the invention, for example a node 900 for multicasting content to a plurality of end nodes. The node comprises a processing unit 941 adapted to receive a control signal 915 from a unicast server node, the control signal 915 indicating that a particular content stream is required to be streamed in a multicast mode of operation, The processing unit 941 is further adapted to inform the unicast server node of the multicast address to be used for the multicast streamed content, for example using the control signal 915. A converter unit 942 is adapted to convert HTTP content 916 received in a unicast format into a multicast signal 917 for transmission to the end nodes. The HTTP content 916 may be received from a HTTP server node.

The embodiments described above provide an improved scalability in the network and offload HTTP caches. For example, if 100,000 STBs are watching a HTTP stream a caching server needs to send 100,000 HTTP streams, whereas a multicast server has the advantage of only sending one stream, for example to the next router. Then the routers and switches in the network distribute the content. The embodiments of the invention have the advantage of improving network bandwidth when a plurality of end users start to download the same content stream, and when the plurality of users reaches a certain threshold value.

The embodiments of the invention also have an advantage in that the normal HTTP stack a browser uses does not need to be aware of how the HTTP fragments are fetched. Therefore, it can be a standard HTTP stack. Although the embodiments of the invention have been described as switching from unicast to multicast mode when the number of unicast streams of the same content reaches a particular level, the embodiments of the invention may also be configured to switch back from multicast to unicast mode. For example, the switch back to unicast mode may be triggered if the number of requests for a particular unicast content, or the number of recipients of the multicast stream, falls below a particular threshold. The threshold may be the same or a different threshold to the first threshold. This may involve detecting or determining that end nodes have left the multicast stream. A switch from multicast to unicast may also be triggered in order to lower the load on a node, for example a node that performs the HTTP to multicast translation. These embodiments may also involve switching only a predetermined or limited number of end nodes back to a unicast mode.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A method of streaming content, the method comprising the steps of:

receiving requests from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation;

determining whether the number of requests for the particular content has reached a threshold value and, if so;

triggering the streaming of the particular content to switch from the unicast mode of operation to a multicast mode of operation to the plurality of end nodes.

2. A method as claimed in claim 1 , wherein the step of triggering a multicast mode of operation comprises the steps of causing one or more of the end nodes to switch from a unicast mode of reception to a multicast mode of reception.

3. A method as claimed in claim 1 or 2, wherein the step of triggering a multicast mode of operation comprises the steps of:

sending a control signal to a multicast server, the control signal indicating that a multicast mode of operation is to be used for the particular content;

receiving a multicast address from the multicast server, the multicast address relating to the address being used in the multicast mode of operation; and

informing one or more of the plurality of end nodes of the multicast address for the particular content.

4. A method as claimed in claim 3, wherein a request received from an end node comprises an indication that the end node is able to switch from a unicast mode of operation to a multicast mode of operation, and wherein the step of informing is carried out with respect to a plurality of nodes which have indicated that they are able to switch from a unicast mode to a multicast mode.

5. A method as claimed in claim 3 or 4, further comprising the step of sending the unicast content to the multicast server, for multicast transmission by the multicast server.

6. A method as claimed in claim 1 , further comprising the steps of:

receiving from an end node a request for the particular content;

determining if the request contains an indication that the end node is able to receive content in both a unicast mode and a multicast mode and, if so;

determining whether the number of end nodes already receiving that particular content is above a threshold value and, if so;

sending a multicast address to the end node, for enabling the end node to join a multicast stream for that particular content.

7. A method in an end node for receiving content from a remote node using unicast mode of streaming, the method comprising the steps of transmitting to the remote node a request for the receipt of a particular content, wherein the request comprises an indication that the end node is capable of switching from a unicast mode of receiving content to a multicast mode of receiving content.

8. A method as claimed in claim 7, further comprising the steps of:

receiving content from the remote node in a unicast mode of operation during a first period;

receiving a multicast address from the remote node; and

switching to receiving the content from a multicast source during a second period, in response to receiving the multicast address from the remote node.

9. A method as claimed in claim 7, further comprising the steps of:

receiving a multicast address from the remote node; and obtaining the content from a multicast source in response to receiving the multicast address from the remote node.

10. A method for providing multicast content to a plurality of end nodes, the method comprising the steps of:

receiving a control signal from a unicast server node, the control signal indicating that a particular content stream is required to be streamed in a multicast mode of operation;

informing the unicast server node of a multicast address that is to be used for the multicast streamed content; and

streaming the particular content using a multicast mode of operation.

1 1 . A method as claimed in claim 10, wherein content to be multicast is received from the unicast server node.

12. A method as claimed in claim 10 or 1 1 , wherein the step of streaming the content in the multicast mode of operation comprises the step of streaming content using a file delivery over unidirectional transport, FLUTE, scheme.

13. A method as claimed in any one of claims 1 to 12, wherein the unicast content is streamed using hyper text transfer protocol, HTTP, or HTTP adaptive streaming, HAS.

14. A node for controlling the streaming of content to end nodes, the node comprising:

a receiving unit for receiving request signals from a plurality of end nodes for a particular content to be streamed to the end nodes using a unicast mode of operation; and a processing unit configured to determine whether the number of requests for the particular content has reached a threshold value and, if so, trigger the streaming of at least some of the particular content to switch from the unicast mode of operation to a multicast mode of operation to the plurality of the end nodes.

15. A node as claimed in claim 14, wherein the processing unit is further adapted to:

send a control signal to a multicast server, the control signal indicating that a multicast mode of operation is to be used for the particular content;

receive a multicast address from the multicast server; and

inform one or more of the plurality of end nodes of the multicast address for the particular content.

16. An end node for receiving content from a remote node, the end node comprising:

an interface unit configured to transmit a request signal to a remote node, for requesting receipt of a particular content, wherein the interface unit is configured to include an indication in the request signal that the end node is capable of switching from a unicast mode of receiving content to a multicast mode of receiving content.

17. An end node as claimed in claim 16, wherein the interface unit is adapted to switch from receiving content from a unicast source to receiving content from a multicast source, in response to receiving a multicast address from the remote node.

18. An end node as claimed in claim 16 or 17, further comprising a local cache for storing received content.

19. An end node as claimed in claim 18, wherein the end node is adapted to retrieve any missing fragments of the received content from the remote node.

20. A node for multicasting content to a plurality of end nodes, the node comprising:

a processing unit adapted to receive a control signal from a unicast server node, the control signal indicating that a particular content stream is required to be streamed in a multicast mode of operation, wherein the processing unit is further adapted to inform the unicast server node of the multicast address to be used for the multicast streamed content; and

a converter unit adapted to convert content received in a unicast format into a multicast signal for transmission to the end nodes.

21 . A network comprising a node as claimed in any one of claims 14 to 15, an end node as claimed in any one of claims 16 to 19, and a node as claimed in claim 20.

22. A network as claimed in claim 21 , wherein the node of claims 14 or 15 and the node of claim 20 form part of the same node.