The present invention relates to methods for streaming content and to corresponding devices. Background

In communication networks, such as cellular networks as specified by 3GPP (3 ^rd Generation Partnership Project), it is known to use unicast transmissions and multicast or broadcast transmissions for the purpose of delivering streamed content to client devices, e.g., as specified in "Transport of MPEG-2 TS Based DVB Services over IP Based Networks", DVB BlueBook A86 (March 2015). One example is a technology referred to as Multicast Adaptive Bitrate (M-ABR), e.g., as specified in CableLabs "IP Multicast Adaptive Bit Rate Architecture Technical Report", OC-TR-IP-MULTI-ARCH-V01 -141 1 12 (2014), which utilizes IP (Internet Protocol) Multicast for scalable and cost efficient delivery in combination with client driven rate adaptation. Specifically, the client device can probe the available link quality and select a stream of segments which complies with this link quality.

In typical scenarios, the last or second last hop in of the transmission chain limits the available bitrate. For example, this hop may extend across a radio link, e.g., based on WLAN (Wireless Local Area Network) or LTE (Long Term Evolution), or a DSL (Digital Subscriber Line) link which means that throughput is limited by a bitrate limit imposed by the technology, line conditions, radio conditions, or concurrent users.

In order to allow for utilizing existing kinds of players supporting adaptive bitrate, e.g., HTTP (Hypertext Transfer Protocol) Live Streaming (HLS) and also existing DRM (Digital Rights Management) schemes, it is known to utilize a client-side proxy, which translates between a format used by the player, e.g., HLS, and a format used for multicast transmissions in different quality levels, e.g., HLS over UDP (User Datagram Protocol). The client-side proxy may then manage rate adaptation by joining a multicast channel providing the appropriate quality level for the current link quality. When the player joins a multicast-video stream delivered by M-ABR, a tune-in operation is performed. For a typical tune-in operation, it can be assumed that that the each segment of the video stream contains (at least) a full GOP (Group of Picture). In the tune-in operation, the streaming client typically needs to find the start of a segment, which contains required information for processing the video stream, such as decoding of video content. When using MPEG-TS (MPEG-TS: "Motion Picture Experts Group Transport Stream") based segments, each segments starts with a Program Association Table (PAT), followed by a Program Map Table (PMT) and then it continues with an l-Frame start. The l-Frame is the first frame in a GOP. The start of a segment therefore typically acts as an access point for the video stream.

Typically, the streaming client tunes-in to the multicast video stream at an arbitrary point of time, e.g., triggered by the user selecting a channel. Then the streaming client needs to wait until the start of a segment is found and the information required for processing the video stream can be received. Then, buffering of the video content can start. However, it may take some time until the buffer has reached a sufficient fill level and to start playback of the video stream.

In order to speed up filling the buffer during the tune-in operation, solutions referred to as "Fast Channel Change (FCC)", e.g., as specified in "Server-Based Fast Channel Change in DVB-IPTV Systems", DVB BlueBook A152 (August 2010), or "Rapid Acquisition of Multicast Streams" (RAMS), e.g., as specified in RFC 6285 (June 201 1 ), additionally utilize unicast delivery of the streamed content. Specifically, the streaming client requests a unicast burst of data to fill up the buffer using RTP (Real-time Transport Protocol). The duration of the unicast burst may be calculated assuming a certain overspeed (e.g. transmission of the unicast burst at 130% of the multicast bitrate). However, in some scenarios it is not straightforward to find an appropriate point of time for switching from the unicast delivery to the multicast delivery. For example, in case of HLS, a description of the stream which is provided to the streaming client, referred to as "HLS manifest" describes that a certain segment is available, but does not indicate when segments will become available in the future. This may result in excessive length of the unicast burst and overloading of the utilized radio link by data transmitted both in the unicast delivery mode and the multicast delivery mode. Specifically when utilizing a link with limited capacity such redundant transmission of parts of the stream is undesirable. Accordingly, there is a need for techniques which allow for efficiently streaming content using both multicast delivery and unicast delivery. Summarv

According to an embodiment of the invention, a method of streaming content is provided. According to the method, a client device receives a first set of one or more segments of streamed content in a unicast transmission mode. Further, the client device receives a synchronization stream indicating, separately from the streamed content, a timing of segments of the streamed content transmitted in a multicast transmission mode. Based on the indicated timing, the client device controls switching to receiving a second set of one or more segments of the streamed content transmitted in the multicast transmission mode.

According to a further embodiment of the invention, a method of streaming content is provided. According to the method, a server transmits a stream of segments of streamed content in a multicast transmission mode. Further, the server transmits a synchronization stream indicating, separately from the streamed content, a timing of the segments of streamed content transmitted in the multicast transmission mode. The indicated timing enables a client device to control switching from receiving a first set of one or more segments of the streamed content in a unicast transmission mode to receiving a second set of one or more segments of the streamed content in the multicast transmission mode. According to a further embodiment of the invention, a client device is provided. The client device is configured to receive a first set of one or more segments of streamed content in a unicast transmission mode. Further, the client device is configured to receive a synchronization stream indicating, separately from the streamed content, a timing of segments of the streamed content transmitted in a multicast transmission mode. Further, the client device is configured to control, based on the indicated timing, switching to receiving a second set of one or more segments of the streamed content transmitted in the multicast transmission mode.

According to a further embodiment of the invention, a server is provided. The server is configured to transmit a stream of segments of streamed content in a multicast transmission mode. Further, the server is configured to transmit a synchronization stream indicating, separately from the streamed content, a timing of the segments of streamed content transmitted in the multicast transmission mode. The indicated timing enables a client device to control switching from receiving a first set of one or more segments of the streamed content in a unicast transmission mode to receiving a second set of one or more segments of the streamed content in the multicast transmission mode. According to a further embodiment of the invention, a computer program or computer program product is provided, e.g., in the form of a non-transitory storage medium, which comprises program code to be executed by at least one processor of a client device. Execution of the program code causes the client device to receive a first set of one or more segments of streamed content in a unicast transmission mode. Further, execution of the program code causes the client device to receive a synchronization stream indicating, separately from the streamed content, a timing of segments of the streamed content transmitted in a multicast transmission mode. Further, execution of the program code causes the client device to control, based on the indicated timing, switching to receiving a second set of one or more segments of the streamed content transmitted in the multicast transmission mode.

According to a further embodiment of the invention, a computer program or computer program product is provided, e.g., in the form of a non-transitory storage medium, which comprises program code to be executed by at least one processor of a server. Execution of the program code causes the server to transmit a stream of segments of streamed content in a multicast transmission mode. Further, execution of the program code causes the server to transmit a synchronization stream indicating, separately from the streamed content, a timing of the segments of streamed content transmitted in the multicast transmission mode. The indicated timing enables a client device to control switching from receiving a first set of one or more segments of the streamed content in a unicast transmission mode to receiving a second set of one or more segments of the streamed content in the multicast transmission mode. Details of such embodiments and further embodiments will be apparent from the following detailed description of embodiments.

Brief Description of the Drawings Fig. 1 schematically illustrates a communication network system for implementing streaming of content according to an embodiment of the invention.

Fig. 2 schematically illustrates a further communication network system for implementing streaming of content according to an embodiment of the invention.

Fig. 3 schematically illustrates multicast streams as utilized according to an embodiment of the invention. Fig. 4 shows data flows in an exemplary scenario according to an embodiment of the invention. Fig. 5 shows an example of processes according to an embodiment of the invention.

Fig. 6 shows a flowchart for schematically illustrating a method according to an embodiment of the invention. Fig. 7 shows a flowchart for schematically illustrating a further method according to an embodiment of the invention.

Fig. 8 schematically illustrates a client device according to an embodiment of the invention. Fig. 9 schematically illustrates a server according to an embodiment of the invention. Detailed Description of Embodiments

In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail and with reference to the accompanying drawings. The illustrated embodiments relate to streaming of content in a communication network. The communication network is assumed to enable delivery of streamed content from a server to one or more client devices. For example such client device may be connected through a radio interface to the server. Such radio interface may for example be based on a cellular radio technology, e.g., the LTE technology, or on a WLAN radio technology. Further, such client device may also be connected through a wire based technology to the server. Such wire based technology may for example be based on a DSL technology, a coaxial cable networking technology, or an optical fiber networking technology. In some scenarios, also combinations of such technologies may be used for connecting the client device to the server.

In the illustrated concepts, it is assumed that both a multicast transmission mode and a unicast transmission mode are utilized for delivery of streamed content from the server to a certain client device. As used herein, the "multicast transmission mode" refers to a transmission mode in which a single transmission is addressed to multiple recipients. The multicast transmission mode may for example be based on IP Multicast as specified in IETF RFC 1 1 12 (August 1989), FLUTE as specified in RFC3926 (October 2004), and/or FCAST as specified in RFC 6968 (July 2013). The "unicast transmission mode" refers to a transmission mode in which a transmission is addressed to only one recipient. The multicast unicast transmission mode may for example be based on HTTP as specified in IETF RFC 7230 (June 2014) or protocols derived therefrom. The streamed content may for example correspond to multimedia content, for which continuous playback at the client device is desired. A synchronization stream, in the following also referred to as "sync stream" is provided for enabling the client device to efficiently control switching from receiving the streamed content in the unicast transmission mode to receiving the streamed content in the multicast transmission mode. Specifically, this switching may be controlled with the aim of avoiding redundant transmission of parts of the streamed content in both the unicast transmission mode and the multicast transmission mode. Accordingly, excessive utilization of a link with limited capacity, e.g., an LTE or WLAN radio link or a DSL link, can be avoided. The sync stream indicates a timing of segments of the streamed content transmitted in the multicast transmission mode. This is accomplished separately from the streamed content, i.e., the sync stream does not include the streamed content. Accordingly, the sync stream can be transmitted at a low bitrate, without significant utilization of the limited link capacity. From the sync stream the client device may determine when a certain segment of the streamed content will be transmitted in the multicast transmission mode and then switch to receiving this segment. Before this switching, the client device may receive a set of preceding segments in the unicast transmission mode. The latter segments may for example be used for expedited filling of a buffer storing the streamed content at the client device. In typical scenarios, this may allow for starting playback of the streamed content in less than a second.

Fig. 1 schematically illustrates an example of a system which may be utilized in a communication network for streaming of content as outlined above. As illustrated, the system is based on a client device 100 and a source server 200. Through the communication network, the client device 100 is connected to the source server 200. As illustrated, the connection of the client device 100 to the source server 200 extends across a subscriber interface, e.g., a radio link based on an LTE or other cellular radio technology or a WLAN radio technology, or a wire-based link, such as a DSL link.

A segmenter 210 is provided for generating segments of the streamed content. In the example of Fig. 1 , the segmenter 210 is assumed to be part of the source server 200. However, it is to be understood that the segmenter 210 could also be provided separately from the source server 200, e.g., by a content provider from which the streamed content originates. The segmenter 210 converts the streamed content to at least one stream of segments. In some scenarios, the segmenter 210 may convert the streamed content to multiple streams of segments, and each of these multiple streams may convey the streamed content in a different quality level. The streamed content may for example correspond to multimedia content, e.g., video content or audio content. In the example as further detailed below, it is assumed that the streamed content corresponds to video content, and the streams each correspond to an MPEG-TS based on the HLS protocol. However, it is to be understood that the illustrated concepts may also be applied to other kinds of content and to other stream formats, such as ISO-BMFF as used in ISO/IEC 23009-1 : 2014 (May 2014).

As further illustrated, the source server 200 is further provided with a storage 220. The storage 220 receives the segments of the streamed content from the segmenter 210 and stores them so that they are available for transmission in the multicast transmission mode and/or unicast transmission mode. The storage 220 may for example be based on one or more hard disks or similar kinds of mass storage technology. As further illustrated, the source server 200 is provided with a multicast transmitter (MC-TX) 230. The MC-TX 230 is responsible for transmission of the segments of the streamed content in the multicast transmission mode. In the illustrated example, it is assumed that the streamed content is transmitted in multiple streams of different quality levels. The MC-TX 230 thus sets up multiple multicast groups, each corresponding to one of the quality levels, and transmits the segments of a given quality level in the corresponding multicast group. The multicast transmission mode may for example utilize a multicast file delivery protocol such as FLUTE as specified by IETF RFC 6726 or FCAST as specified by IETF RFC 6968. Such multicast file delivery protocol may operate in connection with a multicast or broadcast service supported by the communication network, such as MBMS (Multimedia Broadcast Multicast Service) as specified by 3GPP TS 23.246 V12.5.0 (2015-03) and/or IP multicast as specified by IETF RFC 1 1 12.

As further illustrated, the source server 200 is provided with a HTTP server 240. The HTTP server is responsible for transmission of the segments of the streamed content in the unicast transmission mode. In the illustrated example, it is assumed that the uncast transmission mode is based on conventional HLS mechanisms, such as using the HTTP GET method for receiving a request for a segment and transmitting the segment in response to such request.

The client device 100 is provided with a multicast receiver (MC-RX) 1 10 which is responsible for receiving the segments of the streamed content transmitted in the multicast transmission mode. For this purpose, the MC-RX 1 10 may join one of the multicast groups set up by the MC-TX 230. Here, it should be noted that in typical scenarios the MC-TX 220 will transmit the segments even if the MC-RX 1 10 has not joined one of the multicast groups, e.g., to enable reception of the segments by other client devices. Nonetheless, the load on the subscriber interface may depend on whether the MC-RX 1 10 has joined one of the multicast groups and on which multicast group was joined by the MC-RX 1 10. For example, it is typically more efficient to deliver the segments of the streamed content across the subscriber interface if the MC-RX 1 10 actually joined the corresponding multicast group. In some scenarios, the MC- RX 1 10 may also support a file repair mechanism, e.g., based on using HTTP for requesting missing data from the HTTP server 240. For example, the MC-RX 1 10 may request missing data packets using packet numbers, e.g., as identified by a FEC (Forward Error Correction) payload identifier such as SBN (Source Block Number) and ESI (Encoding Symbol Identifier). Further, the MC-RX 1 10 may request a certain range from an incompletely received segment, e.g., using an HTTP range headers.

As further illustrated, the client device 100 is provided with an HTTP client 120. The HTTP client 120 is responsible for receiving the segments of the streamed content transmitted by the HTTP server 240 in the unicast transmission mode. In the illustrated example, it is assumed that the uncast transmission mode is based on conventional HLS mechanisms as defined in the Informational Internet-Draft "HTTP Live Streaming draft-pantos-http-live- streaming-16" by R. Pantos, Ed., W. May, Apple Inc., available under https://tools.ietf.org/html/draft-pantos-http-live-streaming -16ref (April 2015). These mechanisms for example involve using the HTTP GET method for transmitting a request for a segment and receiving the segment in response to such request.

Further, the client device 100 is provided with a storage 130 in which the segments received by the MC-RX 1 10 and the HTTP client 120 are stored. The storage 130 may be implemented on the basis of one or more mass storage devices, such as hard disks, solid state disks, or flash memory devices.

As further illustrated, the client device 100 is provided with a player 140 which is responsible for playback of the streamed content. For this purpose, the player fetches segments of the streamed content from the storage and processes the data of the segments as required for the playback. This may for example involve decoding video data and/or audio data. In accordance with the conventional HLS mechanisms, the player may first buffer three segments before rendering of the streamed content starts. The fetching of the segments from the storage 130 may be based on conventional HLS mechanisms, such as using the HTTP GET method for transmitting a request for a segment and receiving the segment in response to such request. Accordingly, the HTTP client 120 and the storage 130 may act as a streaming proxy 150 for the HTTP based transactions of HLS mechanisms implemented by the player 140. However, this streaming proxy 150 will not only utilize the conventional HLS mechanisms for receiving the streamed content based on the unicast transmission mode from the HTTP server 240, but also utilize the multicast transmission mode to receive the streamed content via the MC-RX 1 10. From the perspective of the player 140, this combined usage of the unicast transmission mode and the multicast transmission mode may be implemented in a transparent manner, so that various kinds of existing software or hardware players can be utilized as the player 140. Specifically, the player 140 itself does not need to be specifically adapted to support the utilization of the multicast transmission mode.

Fig. 2 schematically illustrates a further example of a system which may be utilized in a communication network for streaming of content as outlined above. The system of Fig. 2 includes a client device 100 and a source server 200. Further, the system includes an edge server 300. As compared to the source server 200, the edge server is located closer to the client device 100. Through the communication network, the client device 100 is connected to the source server 200 and to the edge server 300. As illustrated, the connection of the client device 100 to the source server 200 and to the edge server 300 extends across a subscriber interface, e.g., a radio link based on an LTE or other cellular radio technology or a WLAN radio technology, or a wire-based link, such as a DSL link. The system of Fig. 2 is in many aspects similar to the system of Fig. 1 , and in Fig. 2 elements which correspond to those of Fig. 1 have been identified by the same reference signs. In the following it will be refrained from repeatedly describing elements or functionalities which correspond to those of Fig. 1.

In the system of Fig. 2, the edge server 300 may act as a local source for fetching segments of the streamed content using the unicast transmission mode. In this way, a load contribution within the communication network associated with the transmission of segments in the unicast transmission mode, specifically in view of situations in which multiple client devices request the same segment. Such unicast requests may be handled in a more efficient manner by locating additional sources of the segments as close as possible to the client devices.

In the illustrated example, the edge server 300 is provided with a multicast receiver (MC-RX) 310 which is responsible for receiving the segments of the streamed content transmitted in the multicast transmission mode. For this purpose, the MC-RX 310 may joins the multicast groups set up by the MC-TX 230. Further, the edge server 300 is provided with an HTTP proxy 320. The HTTP proxy 320 is responsible for receiving the segments of the streamed content transmitted by the HTTP server 240 in the unicast transmission mode and for forwarding the received segments in the unicast transmission mode towards requesting client devices, e.g., towards the client device 100. Further, the edge server 300 is provided with a storage 330 in which the segments received by the MC-RX 310 and the HTTP client 320 are stored. The storage 130 may be implemented on the basis of one or more mass storage devices, such as hard disks, solid state disks, or flash memory devices.

As compared to the system of Fig. 1 , the HTTP client 120 of the client device 100 may issue requests for transmission of segments in the unicast transmission mode towards the HTTP proxy 320 of the edge server 300, and the HTTP proxy 320 of the edge server 300 may respond to such request by transmitting the requested segment from the storage 330. Only if the requested segment is not available in the storage 330, the HTTP proxy 320 may need to request the segment from the HTTP server 240 of the source server 200. It can thus be avoided that the unicast transmission mode generates excessive load within the communication network, in particular on a link between the source server 200 and the edge server 300. The multicast transmission mode supports a file repair mechanism, the edge server 300 may also act as a source from which the MC-RX 1 10 can request the data needed for file repair. For example, the MC-RX 1 10 may use HTTP for requesting missing data from the HTTP proxy 320. For example, the MC-RX 1 10 may request missing data packets using packet numbers, e.g., as identified by a FEC payload identifier such as SBN and ESI. Further, the MC-RX 1 10 may request a certain range from an incompletely received segment, e.g., using an HTTP range headers.

In the systems of Figs. 1 and 2, the MC-TX 240 not only transmits the stream(s) including the segments of the streamed content, in the following also referred to as multicast content streams, but further also transmits the sync stream, which does not include the streamed content but indicates a timing of the segments in the multicast content streams. The sync stream may be generated by the MC-TX 230. Similar to the multicast content streams, the sync stream is received by the MC-RX 1 10 of the client device 100. The sync stream may indicate the timing of the segments of the multicast content streams by being organized in segments which are transmitted synchronously with the segments of the multicast content streams and include an identifier of the synchronously transmitted segment of the multicast content stream. In the illustrated example, this identifier corresponds to a sequence number and an URL (Uniform Resource Locator) of the segment of the multicast content stream. From the sync stream, the client device 100 may derive when a specific segment, identified by a certain sequence number and URL, will become available in the multicast content stream. In particular, the client device 100 may utilize the indicated timing to determine segment boundaries relative to reception and switch from reception of the streamed content in the unicast transmission mode (by the HTTP client 120) to reception of the streamed content in the multicast transmission mode (by the MC-RX 1 10) at the start of a certain segment in the multicast content stream. This allows for avoiding redundant transmission of this segment in the unicast transmission mode, while at the same time enabling the client device 100 to receive information transmitted at the start of the segment which is required for processing the segment. For example, in the assumed scenario of using an MPEG-TS, a PAT and PMT are transmitted at the start of a segment, and receiving this information may enable the player 140 start processing of the segment without further delay.

Fig. 3 schematically illustrates an example of how the multicast content streams and the sync stream may be organized. In the illustrated example, three multicast content streams of different quality levels are provided: a high-quality multicast content stream (designated by HQ), a medium quality multicast content stream (designated by MQ), and a low quality multicast content stream (designated by LQ). As can be seen, a bandwidth (BW) required for transmission of the multicast content stream increases with the quality level, and a bandwidth required for transmission of the sync stream is even lower than the bandwidth required for transmission of the low quality multicast content stream, because the sync stream does not include the streamed content.

As further illustrated, each of the segments of the multicast content streams is identified by a sequence number (..., #X-2, #X-1 , #X, #X+1 , #X+2, #X+3, ...). The sequence number may be utilized for identifying the position of s given segment in the stream. In addition, each segment may also be identified by a URL. The URL may also be utilized for requesting transmission of the segment in the unicast transmission mode. Further, the URL may also allow for distinguishing between the segments of different quality levels. It should be noted that the sequence numbers may be incremented by one from one segment to the next segment of the stream, as illustrated in Fig. 3. However, other step sizes could be utilized as well, e.g., a step size corresponding to a time duration of the segment.

As further illustrated, the sync stream is organized in segments which are transmitted synchronously with the segments of the multicast content streams and carry the same sequence number as the synchronously transmitted segments of the multicast content streams. Further, the segments of the sync stream may also indicate the URLs of the synchronously transmitted segments of the multicast content streams. Accordingly, by receiving and analyzing the sync stream, the client device 100 may determine when a certain segment will become available in one of the multicast content streams, without receiving the multicast content stream. Further, the client device 100 may infer from the sync stream which segments of the streamed content should be fetched by the unicast transmission mode, to expedite buffer filling and reduce an associated delay before playback of the streamed content can start. Each segment of the multicast content stream may be represented by two IP packets in the sync stream, one at the beginning of the segment and one at the end of the segment.

Fig. 4 illustrates an exemplary scenario in which the client device utilizes the sync stream for efficiently switching to reception of the streamed content in the multicast transmission mode.

As illustrated, the segmenter 210 continuously outputs segments of streamed content, which in the illustrated example are continuously transmitted by the MC-TX 230 in the multicast content stream. In the illustrated example, there is an offset of one segment between the availability of a certain segment from the segmenter and transmission of this segment in the multicast content stream. However, it is to be understood that this offset may be different in other scenarios. Further, there may also be scenarios where the segmenter 210 does not operate in realtime during the multicast delivery of the streamed content and all segments are already generated before the multicast delivery starts.

In the multicast content stream, gaps are inserted between segment boundaries to facilitate joining or leaving the multicast content stream. In the illustrated example, transmission of segment #7 starts at TO, and during transmission of segment #7, reception of the stream at by the client device 100 is assumed to be activated at T1 , e.g., by the user selecting a corresponding channel. Accordingly, at the time when the reception of the streamed content is activated, transmission of segment #7 in the multicast content stream is in progress. At least some of the segments of the streamed content are also available for retrieval in the unicast transmission mode. In the illustrated example, it is assumed that a HLS manifest provided to the client device 100 when activating the reception references segments #5 to #7.

As further illustrated, the sync stream indicates the boundaries of the segments transmitted in the multicast content stream and also identifies the segment which is currently transmitted in the multicast content stream. As mentioned above, the specific segment being transmitted may be identified in terms of its sequence number and/or URL. In the illustrated example the client device 100 is assumed to join the sync stream when activating the reception. At this point, the client device 100 may infer from the sync stream that transmission of segment #7 is currently in progress in the multicast content stream. At T2, the client device 100 may derive from the sync stream that segment that transmission of segment #8 started in the multicast content stream and also infer when transmission of the next segments (i.e., segment #9, segment #10) will start in the multicast content stream.

On the basis of the sync stream, the client device 100 may thus infer boundaries of the segments in the multicast content stream and synchronize its operations to these boundaries. In the illustrated scenario, it is assumed that the sync stream and the multicast content stream traverse the same transmission path through the communication network, so that time alignment of the segments of the sync stream and the corresponding segment in the multicast content stream is preserved up to reception by the client device 100. Having derived the segment boundaries and the segment numbers from the sync stream, the client device 100 may determine a set of segments of the streamed content which is to be requested in the unicast transmission mode. In the illustrated example, this set of segments includes old segments which are no longer available through the multicast content stream, in the illustrated example segments #5 to #7, but also segments which are still available through the multicast content stream, in the illustrated example segments #8 and #9. These segments are assumed to be requested in a lower quality level than the segments of the multicast content stream, so that filling of a playback buffer can be expedited and playback can start as soon as possible. In the illustrated example, the playback starts at T3, when three segments (segments #5 to #7) have been received in the unicast transmission mode. At that time, transmission of segment #9 in the multicast content stream has already started, so that joining the multicast content stream would only allow for incomplete reception of segment #9. Accordingly, the client device 100 decides on the basis of the timing derived from the sync stream to join the multicast content stream at the beginning of segment #10 and requests also segments #8 and #9 in the unicast transmission mode. As further illustrated, when joining the multicast content stream at T4, the client device 100 also leaves the sync stream.

Fig. 5 further illustrates processes underlying the example of Fig. 4. The processes of Fig. 5 involve the MC-TX 230, the edge server 300, the MC-RX 1 10, and the streaming proxy 150. The processes enable the player 140 (not illustrated in Fig. 5) to receive the streamed content by unicast and multicast transmissions. In the case of unicast transmissions the player 140 would receive the streamed content via the streaming proxy 150 and the edge server 300. In the case of multicast transmissions the player 140 would receive the streamed content via the streaming proxy 150 and the MC-RX 1 10. From the perspective of the player 140, the utilization of these different transmission paths may be handled in a transparent manner. Accordingly, the player 140 may communicate with the streaming proxy 150 in the same way as with a conventional source of streamed content.

In the processes of Fig. 5, the streaming proxy 150 initiates reception of the streamed content by requesting a HLS manifest by sending a HTTP GET message 501 to the edge server 300. The streaming proxy 150 may request HLS manifest based on previously received channel access information. Such channel access information may for example include a URL of the HLS manifest (e.g., a URL of a master playlist or variant playlists) and multicast access information, such as IP Multicast address, UDP ports, additional protocol information like FLUTE Transport Session Id (TSI), source address for SSM (Source Specific Multicast), or the like.

The edge server 300 responds to the request by sending the HLS manifest in HTTP OK message 502 to the streaming proxy 150. Further, the MC-RX 1 10 joins the sync stream for this content by sending message 503 towards the MC-TX 230. In response to receiving message 503, the MC-TX 230 includes the MC-RX 1 10 into the multicast group of the sync stream, so that future segments of the sync stream will also be addressed to the MC-RX 1 10. At that point, the streaming proxy 150 is able to receive the sync stream, as illustrated by 504.

As further illustrated, the streaming client 150 then starts to fetch segments of the streamed content from the edge server 300. Initially, the streaming client requests segment #5 (assumed to be the oldest available segment referenced in the HLS manifest) by sending HTTP GET message 505 towards the edge server 300. The edge server 300 responds to the request by sending segment #5 in HTTP OK message 506 to the streaming proxy 150. At this point, the MC-RX 1 10 infers from the sync stream that transmission of segment #7 is currently in progress in the multicast content stream. For example, this may be detected on the basis of an IP packet transmitted in the sync stream at the end boundary of segment #7. In view of the timing indicated by the sync stream, the MC-RX 1 10 decides to join the multicast sync stream at the beginning of segment #10, thereby leaving sufficient time for expedited buffer filling and enabling reduced delay before starting playback of the received content (after having received segments #5 to #7). In view of this decision, the streaming proxy 150 continues to utilize the unicast transmission mode to also request segments #6, #7, #8, and #9 from the edge server 300, as illustrated by HTTP GET messages 508, 510,

512, and 514, and the edge server responds by sending these segments in the unicast transmission mode to the streaming proxy, as illustrated by HTTP OK messages 509, 51 1 ,

513, and 515.

As illustrated by step 516, the MC-RX 1 10 may then estimate a bitrate which matches the available link quality and select an multicast content stream of corresponding quality level, e.g., the medium quality multicast content stream. The MC-RX 1 10 then leaves the sync stream, as indicated by message 517 and joins the selected multicast content stream just before transmission of segment #10 starts, as illustrated by message 518. As illustrated by 519, the MC-RX 1 10 may then receive segment #10 and future segments of the selected multicast content stream in the multicast transmission mode from the MC-TX 230 and then provide it to the streaming proxy 150, as illustrated by message 520. It is to be understood that similar processes as illustrated in Fig. 5 could also be implemented in a system without edge server, such as illustrated in Fig. 1 . In such cases, the unicast transactions of Fig. 5 could be performed by the streaming client 150 and a server which also includes the MC-TX 230. Fig. 6 shows a flowchart for illustrating a method which may be utilized for implementing the illustrated concepts in a client device, e.g., the client device 100. If a processor-based implementation of the client device is used, the steps of the method may be performed by one or more processors of the client device. In such a case the client device may further comprise a memory in which program code for implementing the below described functionalities is stored.

At step 610, the client device may receive stream information. For example, the stream information may include a HLS manifest or similar stream description, and multicast access information, such as IP Multicast address, UDP ports, additional protocol information like FLUTE TSI, source address for SSM, or the like.

At step 620, the client device receives a segment of streamed content in a unicast transmission mode. This may be accomplished based on the stream information received at step 610, e.g., based on URLs indicated by the stream description. The segments of the streamed content may for example be based on the HLS protocol and be received by requesting the segments by HTTP based mechanisms. At step 630, the client device receives a synchronization stream, such as the above- mentioned sync stream. The synchronization stream indicates a timing of segments of the streamed content transmitted in a multicast transmission mode. The synchronization stream indicates the timing separately from the streamed content, i.e., does not include the streamed content. The synchronization stream may be transmitted in the multicast transmission mode and for example include segments transmitted synchronously with the segments of the streamed content to indicate boundaries of the segments of the streamed content transmitted in the multicast transmission mode. The synchronization stream may include, for each segment of the streamed content transmitted in the multicast transmission mode, an indication which identifies the segment and which is transmitted synchronously with the segment. Such indication may include URL of the segment and/or a sequence number of the segment.

Based on the indicated timing, the client device controls switching to receiving one or more segments of the streamed content transmitted in the multicast transmission mode.

As illustrated by step 640, the controlling of the switching may involve determining the timing of the segments of the streamed content transmitted in the multicast transmission mode, e.g., by determining when transmission of a certain segment in the multicast transmission will start.

At step 650, the client device may then decide whether to switch to the reception of the segments transmitted in the multicast transmission mode. For example, if the timing determined at step 640 indicates that segments directly preceding the next segment for which transmission in the multicast transmission mode is about to start have already been received in the unicast transmission mode, the client device may decide to switch to receive the next segment in the multicast transmission mode. In other words, the client device may switch to reception in the multicast transmission mode when the reception in the unicast transmission mode has reached alignment with the timing of the segments transmitted in the multicast transmission mode.

If the client device does not decide to switch to reception in the multicast transmission mode, the client device may return to step 620 to receive another segment of the streamed content in the unicast transmission mode, as indicated by branch "N". Otherwise, if the client device decides to switch to reception in the multicast transmission mode, the client device may proceed to step 660 to receive one or more segments of the streamed content in the multicast transmission mode, as indicated by branch "Y". Accordingly, based on the timing indicated by the synchronization stream, the client device controls switching from receiving a first set of one or more segments of the streamed content transmitted in the unicast transmission mode to receiving a second set of one or more segments of the streamed content transmitted in the multicast transmission mode. The client device may determine the first set of one or more segments of the streamed content depending on the indications in the synchronization stream and request transmission of the first set of one or more segments of the streamed content in the unicast transmission mode. In some scenarios, the client device may determine, based on the indicated timing, a time of a gap between two consecutive segments of the streamed content transmitted in the multicast transmission mode and performing the switching to the reception in the multicast transmission mode the time of the determined gap. In particular, the client device may switch to the reception in the multicast transmission mode at a time which avoids missing the start of the upcoming segment transmitted in the multicast transmission mode.

The first set of one or more segments of the streamed content, transmitted in the unicast transmission mode, may be received at a different quality level than the second set of one or more segments of the streamed content, transmitted in the multicast transmission mode. In particular, the first set of segments may be received at a lower quality level, thereby enabling the client device to perform buffer filling in an expedited manner, without causing excessive load on a link utilized for receiving the segments.

In some scenarios, the client device may estimate a link quality of a link for receiving the second set of one or more segments of the streamed content and, based on the estimated link quality, select a quality level for receiving the second set of one or more segments of the streamed content. In this way, the client device may implement rate adaptation for the reception of segments in the multicast transmission mode. For example, in the case of a higher link quality, a higher quality level may be selected for receiving the second set of one or more segments of the streamed content. Similarly, in the case of a lower link quality, a lower quality level may be selected for receiving the second set of one or more segments of the streamed content.

Accordingly, a client device which operates according to the method of Fig. 6 may be provided with a module configured to receive a first set of one or more segments of streamed content in a unicast transmission mode, such as explained in connection with step 620, a module configured to receive a synchronization stream indicating, separately from the streamed content, a timing of segments of the streamed content transmitted in a multicast transmission mode, such as explained in connection with step 630, and a module configured to control, based on the indicated timing, switching to receiving a second set of one or more segments of the streamed content transmitted in the multicast transmission mode, such as explained in connection with steps 640 and 650. It should be understood that the client device may also include further modules for implementing other functionalities as described above, such as functionalities of the player 140, and that the modules of the client device do not necessarily represent a hardware structure of the client device, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

Fig. 7 shows a flowchart for illustrating a method which may be utilized for implementing the illustrated concepts in a server, e.g., the server 200. If a processor-based implementation of the server is used, the steps of the method may be performed by one or more processors of the server. In such a case the server may further comprise a memory in which program code for implementing the below described functionalities is stored.

At step 710, the server may send stream information. For example, the stream information may include a HLS manifest or similar stream description, and multicast access information, such as IP Multicast address, UDP ports, additional protocol information like FLUTE TSI, source address for SSM, or the like.

At step 720, the server transmits a stream of segments of streamed content in a multicast transmission mode. This may for example involve setting up a multicast group and addressing the transmitted segments to client devices which are member of the multicast group. The segments of the streamed content may for example be based on the HLS protocol.

At step 730, the server may also transmit one or more segments of the streamed content in a unicast transmission mode. This may for example involve receiving a request for a specific segment and responding to the request by sending the requested segment, e.g., using HTTP based mechanisms.

At step 740, the server transmits a synchronization stream, such as the above-mentioned sync stream. The synchronization stream indicates a timing of segments of the streamed content transmitted in a multicast transmission mode. The synchronization stream indicates the timing separately from the streamed content, i.e., does not include the streamed content. The synchronization stream may be transmitted in the multicast transmission mode and for example include segments transmitted synchronously with the segments of the streamed content to indicate boundaries of the segments of the streamed content transmitted in the multicast transmission mode. The synchronization stream may include, for each segment of the streamed content transmitted in the multicast transmission mode, an indication which identifies the segment and which is transmitted synchronously with the segment. Such indication may include URL of the segment and/or a sequence number of the segment. The server may generate the synchronization stream in the course of transmitting the segments of the streamed content in the multicast transmission mode. The timing indicated by the synchronization stream enables a client device, e.g., the client device 100, to control switching from receiving a first set of one or more segments of the streamed content in a unicast transmission mode, e.g., segments transmitted by the server at step 730, to receiving a second set of one or more segments of the streamed content in the multicast transmission mode, e.g., segments transmitted by the server at step 720.

Accordingly, a server which operates according to the method of Fig. 7 may be provided with a module configured to transmit a stream of segments of streamed content in a multicast transmission mode, such as explained in connection with step 720, and a module configured to transmit a synchronization stream indicating, separately from the streamed content, a timing of the segments of streamed content transmitted in the multicast transmission mode, such as explained in connection with step 730. The timing indicated by the synchronization stream enables a client device to control switching from receiving a first set of one or more segments of the streamed content in a unicast transmission mode to receiving a second set of one or more segments of the streamed content in the multicast transmission mode. Further, the server may be provided with a module configured to transmit a stream of segments of streamed content in the unicast transmission mode, such as explained in connection with step 710. It should be understood that the sever may also include further modules for implementing other functionalities as described above, such as functionalities of the segmenter 210, and that the modules of the server do not necessarily represent a hardware structure of the server, but may also correspond to functional elements, e.g., implemented by hardware, software, or a combination thereof.

It is to be understood that the methods of Figs. 6 and 7 may also be combined in a system which includes one or more client devices operating according to the method of Fig. 6 and a server operating according to the method of Fig. 7. Fig. 8 illustrates exemplary structures which may be used for implementing the above concepts in a client device 800, such as the client device 100. The client device 800 may for example correspond to a mobile phone or to some other type of portable or stationary computing device.

As illustrated, the client device 800 may include an interface 810 for enabling access of the client device 800 to the communication network. The interface 810 may implement to the subscriber interface illustrated in Figs. 1 and 2, or may serve for connecting the client device 800 to such subscriber interface. The interface 810 may for example be configured to connect the client device 800 via a DSL link, a cellular radio link, or a WLAN link to the communication network. Further, the client device 800 may include one or more processors 850 coupled to the interface 810, and a memory 860 coupled to the processor(s) 850. The memory 860 may include a Read Only Memory (ROM), e.g., a flash ROM, a Random Access Memory (RAM), e.g., a Dynamic RAM (DRAM) or Static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. The memory 860 includes suitably configured program code to be executed by the processor(s) 850 so as to implement the above- described functionalities of a client device. In particular, the memory 860 may include various program code modules for causing the client device 800 to perform processes as described above, e.g., corresponding to the method steps of Fig. 6.

As illustrated, the memory 860 may include a multicast reception module 870 for implementing the above-described functionalities of receiving segments of streamed content in the multicast transmission mode, such as explained in connection with step 660 of Fig. 6, and receiving the synchronization stream, such as explained in connection with step 630 of Fig. 6. Further, the memory 860 may include a unicast reception module 880 for implementing the above-described functionalities of receiving segments of streamed content in the unicast transmission mode, such as explained in connection with step 620 of Fig. 6. Further, the memory 860 may also include a control module for implementing the above- described functionalities of controlling switching from unicast reception to multicast reception based on the timing indicated by the synchronization stream.

It is to be understood that the structures as illustrated in Fig. 8 are merely schematic and that the client device 800 may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or processors. Also, it is to be understood that the memory 860 may include further types of program code modules, which have not been illustrated, e.g., program code modules for implementing known functionalities of a client device, e.g., functionalities of a player for playback of streamed content. According to some embodiments, also a computer program may be provided for implementing functionalities of the client device 800, e.g., in the form of a physical medium storing the program code and/or other data to be stored in the memory 860 or by making the program code available for download or by streaming.

Fig. 9 illustrates exemplary structures which may be used for implementing the above concepts in a server 900 which is accessible through a communication network, e.g., the server 200 as illustrated in Fig. 1 or 2. As illustrated, the server 900 may include a client interface 910 to a communication network, through which one or more client devices may connect to the server 900. In accordance with the illustrated concepts, the client interface 910 is assumed to support at least the multicast transmission mode. In some scenarios, the client interface 910 may support both the multicast transmission mode and the unicast transmission mode. Further, the server 900 may include a network interface 920, e.g., for receiving the streamed content from an external source, such as an origin or a content provider.

Further, the server 900 may include one or more processors 950 coupled to the interfaces 910, 920, and a memory 960 coupled to the processor(s) 950. The memory 960 may include a ROM, e.g., a flash ROM, a RAM, e.g., a DRAM or SRAM, a mass storage, e.g., a hard disk or solid state disk, or the like. The memory 960 includes suitably configured program code to be executed by the processor(s) 950 so as to implement the above-described functionalities of a server. In particular, the memory 960 may include various program code modules for causing the server 900 to perform processes as described above, e.g., corresponding to the method steps of Fig. 7.

As illustrated, the memory 960 may include a multicast transmission module 970 for implementing the above-described functionalities of transmitting segments of streamed content in the multicast transmission mode, such as explained in connection with step 760 of Fig. 7, and transmitting the synchronization stream, such as explained in connection with step 740 of Fig. 7. Further, the memory 960 may include a unicast transmission module 980 for implementing the above-described functionalities of transmitting segments of streamed content in the unicast transmission mode, such as explained in connection with step 730 of Fig. 7. Further, the memory 960 may also include a sync stream generation module for implementing the above-described functionalities of generating the synchronization stream, such as explained in connection with step 740 of Fig. 7. It is to be understood that the structures as illustrated in Fig. 9 are merely schematic and that the server 900 may actually include further components which, for the sake of clarity, have not been illustrated, e.g., further interfaces or processors. Also, it is to be understood that the memory 960 may include further types of program code modules, which have not been illustrated, e.g., program code modules for implementing known functionalities of a streaming server, such as processing of data according to a streaming protocol. According to some embodiments, also a computer program may be provided for implementing functionalities of the server 900, e.g., in the form of a physical medium storing the program code and/or other data to be stored in the memory 960 or by making the program code available for download or by streaming.

As can be seen, the concepts as described above may be used for efficiently streaming content in a communication network. Specifically, the concepts may be used to allow efficient switching from a unicast transmission mode to a multicast transmission mode, thereby allowing a low delay before playback of streamed content may start while at the same time avoiding redundant transmissions and excessive load on utilized network links.

It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. For example, the illustrated concepts may be applied in connection with various communication network technologies. Also, it should be noted that in some scenarios the above-mentioned functionalities of the client device may be implemented separately from the player. For example, the functionalities of the client device 100, in particular the MC-RX 1 10 and the streaming proxy 150 could be implemented in a first client device, such as a home gateway or multimedia router, and the functionalities of the player 140 could be implemented in a second client device, such as a streaming box, a television, a smartphone, a tablet computer, a mobile or stationary personal computer, a gaming console, or the like. Further, the illustrated concepts may be applied in connection with various kinds of streaming technologies and content types. Moreover, it is to be understood that the above concepts may be implemented by using correspondingly designed software to be executed by one or more processors of an existing device, or by using dedicated device hardware. Further, it should be noted that the illustrated client device and server may each be implemented as a single device or as a system of multiple interacting devices.