WO2007066257A1

WO2007066257A1 - Streaming data over a wireless link

Info

Publication number: WO2007066257A1
Application number: PCT/IB2006/054498
Authority: WO
Inventors: Ozcan Mesut; Jozef P. Van Gassel
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-12-05
Filing date: 2006-11-29
Publication date: 2007-06-14

Abstract

A data transfer device comprises a data reception device operable to receive multimedia data, to store such received multimedia data, and to transfer stored multimedia data to a processing device. The data reception device includes a data buffer for storing data and is operable to receive data in a single data transfer burst sufficient to fill the data buffer to a first predetermined amount, such a data transfer burst being initiated when the data buffer stores less than a second predetermined amount of data. The data reception device is operable to request and transfer data using HyperText Transfer Protocol (HTTP), or the data reception device is operable to request and control data transfer using Real-time Streaming Protocol (RTSP), and to transfer requested data using Real-Time Transport Protocol (RTP).

Description

Streaming data over a wireless link

The present invention relates to streaming data over a wireless link, and in particular, but not exclusively, to streaming of multimedia content.

A wireless network interface is a major energy consumer in a mobile multimedia device, especially when the interface is active and transferring data. Such a mobile device could be used, for example, for receiving audio and/or video streams from a media server or for streaming audio/video (A/V) to a media renderer. In known systems for streaming media over a wired or wireless IP (internet protocol) network, HTTP (Hyper Text Transfer Protocol) or RTP (Real-time Transport Protocol) data transfer protocols are used. HTTP is usually used for web browsing, where the client pulls data from a server. RTP can be described as a push protocol, where data, usually audio visual (A/V) data, is transmitted in packets at a certain rate from a server to a user device. RTP has better real-time properties than HTTP and makes it possible to multicast a stream to a multiple number of clients without consuming more network bandwidth in a manner similar to broadcasting.

As is well known, the wireless networking protocol used for streaming audio/video data over an IP network is IEEE 802.11. Network controllers usually have a Power Save (PS) mode in which major functions are disabled most of the time so as to reduce power consumption.

In power save mode the network controller sleeps between beacons and only wakes up at beacon intervals to receive a Beacon frame. Beacon frames are transmitted by an Access Point (AP) or another device in the network at fixed intervals. They are used to keep the devices in the network synchronized and to announce any buffered frames for devices in the power save mode by means of traffic indication maps. If a device in power save mode detects that there is a buffered frame for it, then the device requests that frame by

transmitting a PS-Poll frame. A station requesting a frame with a PS-Poll must stay awake until it is delivered. Under contention-based service, however, the access point can deliver a frame at any point. A station cannot return to the sleep mode until it receives a Beacon frame in which its bit in the traffic indication map is clear. Usually network controllers stay active for a while after receiving or transmitting a frame in power save mode also to maximize performance. If the interface would enter the sleep mode immediately after transmitting or receiving a frame in the power save mode, the maximum data rate of the interface in power save mode would drop dramatically during bulk transfers. Staying in the active mode a little longer helps to maximize data rate when the interface doesn't know when the next frame will arrive.

Known mobile multimedia devices suffer from the significant problem that valuable battery energy can be wasted despite communications means facilitating a power save mode.

Embodiments of the present invention, therefore, provide techniques for reducing power consumption in mobile multimedia servers/renderers.

According to a first aspect of the present invention, there is provided a data transfer device comprising a data reception device operable to receive multimedia data, to store such received multimedia data, and to transfer stored multimedia data to a processing device, wherein the data reception device includes a data buffer for storing data and is operable to receive data in a contiguous data transfer burst sufficient to fill the data buffer to a first predetermined amount, such a data transfer burst being initiated when the data buffer stores less than a second predetermined amount of data, and wherein the data reception device is operable to transfer data using a data streaming protocol.

It has been determined that, although keeping the controller in power save mode saves a considerable amount of energy when the device is idle, switching between the active and power save modes costs energy because of the described behavior of devices in power save mode. If a device switches between the two modes regularly, then considerable amounts of energy can be wasted in the switching process. This is especially true in case of streaming A/V content, where relatively small data packets are transmitted regularly at the stream bit rate. This can lead to a high frequency of mode changing when the device moves to the power save mode between data packet transfers.

A device according to claim 1 can have reduced power consumption, by reducing the number of transitions between active and power save modes.

In one particular embodiment, the data reception device is operable to request and transfer data using HyperText Transfer Protocol (HTTP). In an alternative embodiment, the data reception device is operable to request and control data transfer using Universal Plug and Play (UPnP) protocol, and to transfer requested data using Real-Time Transport Protocol (RTP). In a further alternative embodiment, the data reception device is operable to request and control data transfer using Real-time Streaming Protocol (RTSP), and to transfer requested data using Real-Time Transport Protocol (RTP).

The reception device may be operable to request transmission of data when an amount of data stored in the data buffer is less than a second predetermined amount.

The device may further comprise a wireless network interface for receiving data via a wireless communications link.

Another aspect of the present invention provides a mobile multimedia device comprising a processing device operable to process multimedia data, and a data transfer device according to the first aspect of the invention.

Another aspect of the present invention provides a multimedia server device comprising a processing device operable to process multimedia data, and a data transfer device according to the first aspect of the invention.

According to a second aspect of the present invention, there is provided a method for transferring data to a mobile multimedia device which includes a processing device operable to process multimedia data, and a data reception device operable to receive multimedia data, to store such received multimedia data, and to transfer stored multimedia data to the processing device, the method comprising the steps of:

a) determining an amount of data stored in the data reception device;

b) if the amount of data stored in the data reception device is below a second predetermined level:

b 1 ) requesting transfer of data;

b2) receiving data sufficient to fill the data buffer to a first predetermined amount in a contiguous data transfer burst;

c) if the amount of data stored in the data reception device is greater than or equal to the second predetermined level, repeating steps a) to c),

wherein data transfer is performed using a streaming protocol.

Embodiments of the present invention are thus able to reduce power consumption in wireless devices, by enabling fewer transitions between the power save and active modes of the device. Fig. 1 illustrates a wireless system incorporating mobile and stationary media servers/renderers;

Fig. 2 is a block diagram illustrating one aspect of the present invention; Fig. 3 is a flow chart illustrating another aspect of the present invention; and Fig. 4 shows power consumption graphs.

Figure 1 shows a mobile multimedia device 2 and a home media server 6 connected to a wireless Access Point (AP) 4 via a wireless link 3 and a wired link 5, respectively. The home media server 6 may be connected in a wired or wireless manner to the access point 4.

The mobile device 2 can act as a media server and/or client/renderer. It is also possible that the mobile device connects wirelessly to the home server 6 or another mobile device in an ad-hoc manner without needing an access point. A simplified schematic block diagram of a Client/Server arrangement is depicted in Figure 2. The mobile media device 2 comprises a client device 21, a data buffer 22, and a codec device 23. The home server 6 includes a server device 61 and a storage device (HDD) 62. The server device 61

communicates with the client device 21 via a wireless link 3. The wireless link 3 may include an access point, or may be a peer-to-peer ad hoc link.

In the present invention, data packets are transferred from the server device 61 to the client device 21 in a contiguous burst that is sufficient to fill the data buffer 22. The received data packets are then temporarily stored in the data buffer 22 until required by the codec device 23. Data to be transmitted from the server 61 is cached until transmission is required, as will be described below.

Figure 3 is a flow chart illustrating steps in a method embodying one aspect of the present invention. Data packets are transferred to the client device 21 when the filling of the buffer 22 is below a certain threshold L (low-water mark), and so a check is made at step A to determine whether this is the case. The low-water mark L should be large enough to cover any latency in the network and the server in order to make sure that the buffer never gets empty. An empty buffer during playback may cause frozen video on a screen.

If yes, then the server device 61 is instructed by the client to transfer data packets to the client device 21, and hence to the data buffer 22 (step B). The data is transferred in a contiguous burst, so that the receiving device does not enter the power save mode during transfer of this data. If the data buffer 22 is determined (step C) to be full, then the server device 61 is instructed by the client to end data transfer (step D). The process then repeats, awaiting the filling of the data buffer 22 to hit the low- water mark L.

In this way, data packets are transferred from the Server 6 to the Client 2 in one contiguous burst and are buffered at the client device 2. The buffered data packets are consumed at the stream bit rate by the codec 23. In embodiments of the invention, the data buffer 22 is filled as fast as possible and when full data transfer is stopped until the buffer filling hits a certain low- water mark. Then the buffer is refilled. The filling of the buffer 22 in one contiguous burst means that the number of transitions between the power save and active modes can be minimized, thus saving energy.

Data packets are transferred from the server device 61 to the client device 21 at a rate higher than the stream bit rate of the codec device 23. The sending of data packets in high rate bursts means that the client device is able to enter the power save mode for a significant period of time, and the number of transitions between modes can be reduced. Hence, the average power consumption can be reduced, as will be shown with reference to Figure 4.

The data transfer is performed using a suitable streaming protocol or combination of protocols. For example, HyperText Transfer Protocol (HTTP) can be used for control and transfer of the data packets. Alternatively, the data transfer can be requested and controlled using Universal Plug and Play (UPnP) protocol, or by using Real-time Streaming Protocol (RTSP). In the latter two cases, Real-Time Transport Protocol (RTP) is used for the data transfer itself.

The power consumption of a wireless PC card during 1.7 Mb/s video playback is shown in Figure 4. The default behavior is shown in Figure 4a, where data is transferred at the stream bit rate. Although only a small part of the bandwidth is used, the idle time between the data packets is not sufficiently long for the wireless card to enter the PS mode. In Figure 4b the power consumption during playback via a 1 MB buffer with burst refilling is shown. The power consumption is 36% reduced from 1.1 W to 0.7 W. The power reduction depends on the characteristics of the network adapter, the stream bit rate and the buffer size.

When the mobile device 2 acts as a Client, it can playback A/V files energy- efficiently over a wireless link from standard servers using HTTP or RTP. Since the buffering scheme is implemented in the client device 21 and the client device 21 controls the server device 61. The implementation for HTTP is straightforward: the client device 21 issues a HTTP GET request to start a stream over a TCP link and reads data into a buffer from a TCP socket. When the data buffer is full reading from the socket is stopped until the filling of the buffer hits the low- water mark. The TCP protocol takes care of stopping the server from transmitting data when data cannot be consumed by the client. For RTP additional control is required since RTP is a push protocol where the client device 21 has little or no control over the server device 61. The server continuously transmits packets. If the client cannot keep up with the transmission rate then packets are dropped, resulting in hick- ups in the stream.

RTSP (Real-Time Streaming Protocol) can be used in combination with RTP to control a server device. RTSP can be considered as network remote control for the server. RTSP packets are transmitted using either TCP or UDP. Data packets are transferred out-of- band, with respect to RTSP packets, using RTP. RTSP is similar to HTTP in syntax and operation and supports the following methods: SETUP, PLAY, RECORD, PAUSE and TEARDOWN. The PLAY and the PAUSE methods are especially useful for the buffering scheme. With the PLAY method, a Speed parameter can be specified. Using this parameter, the Client can request the server to deliver data at a particular speed, e.g. "Speed: 2.0" means data should be delivered at a rate twice the stream bit rate. This way the buffer can be filled at high speed and when the buffer is full or nearly full the data transfer can be paused using the PAUSE method. When the buffer is nearly empty - buffer filling is below a low- water mark - the client resumes data transfer by using the PLAY method with the Speed option set. Of course similar control can also be realized using another standard or a proprietary protocol.

When a RTP server does not support RTSP or the RTSP Speed option or another RTSP-like control protocol, another way of realizing the low-power operation at the client device is to use a "power aware" Access Point. Such an access point then implements the buffering scheme described in the previous paragraph. That is, the access point includes a data buffer for receiving, and storing temporarily, data from the server device. The access point then transfers the stored data to the client device on request/by agreement. The access point receives a data packet from the server device at the stream bit rate, buffers it internally then sends it to the client device in bursts. The Client and AP must of course communicate and agree for such a low-power streaming service for example using the UPnP protocol.

The device offering the low-power streaming service does not need to be an Access Point. It may also be another type of device on the network that offers such a service.

When the mobile device acts as a media server, and the client device is not "power-aware", the only way to have the low-power operation at the server device is to use an intermediary device, such as an access point, that offers the low-power service mentioned above. The applications of the invention include battery-powered devices that have wireless networking capabilities, and embodiments are especially suitable to mobile audio/video jukeboxes with streaming capabilities over an IEEE 802.11.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The words "comprising" and "comprises", and the like, do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice-versa. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer, if appropriate. In a claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A data transfer device comprising:

a data reception device (21, 22) operable to receive multimedia data, to store such received multimedia data, and to transfer stored multimedia data to a processing device, wherein the data reception device (21, 22) includes a data buffer (22) for storing data and is operable to receive data in a contiguous data transfer burst sufficient to fill the data buffer (22) to a first predetermined amount, such a data transfer burst being initiated when the data buffer (22) stores less than a second predetermined amount of data, and

wherein the data reception device (21, 22) is operable to transfer data using a data streaming protocol.

2. A device as claimed in claim 1, wherein the data reception device (21, 22) is operable to request and transfer data using HyperText Transfer Protocol (HTTP).

3. A device as claimed in claim 1, wherein the data reception device (21, 22) is operable to request and control data transfer using Universal Plug and Play (UPnP) protocol, and to transfer requested data using Real-Time Transport Protocol (RTP).

4. A device as claimed in claim 1, wherein the data reception device (21, 22) is operable to request and control data transfer using Real-time Streaming Protocol (RTSP), and to transfer requested data using Real-Time Transport Protocol (RTP).

5. A device as claimed in any one of the preceding claims, wherein the data reception device (21, 22) is operable to request transmission of data when an amount of data stored in the data buffer (22) is less than a second predetermined amount.

6. A device as claimed in any one of the preceding claims, further comprising a wireless network interface for receiving data via a wireless communications link (3).

7. A mobile multimedia device comprising a processing device (23) operable to process multimedia data, and a data transfer device (21, 22) as claimed in any one of the preceding claims.

8. A multimedia server device (61) comprising a comprising a processing device operable to process multimedia data, and a data transfer device (21, 22) as claimed in any one of claims 1 to 6.

9. A method for transferring data to a mobile multimedia device which includes a processing device operable to process multimedia data, and a data reception device operable to receive multimedia data, to store such received multimedia data, and to transfer stored multimedia data to the processing device, the method comprising the steps of:

a) determining an amount of data stored in the data reception device;

b 1 ) requesting transfer of data;

wherein data transfer is performed using a streaming protocol.

10. A method as claimed in claim 9, wherein the request and transfer data of data is performed using HyperText Transfer Protocol (HTTP).

11. A method as claimed in claim 9, wherein the request and control of data transfer is performed using Universal Plug and Play (UPnP) protocol, and data transfer is performed using Real-Time Transport Protocol (RTP).

12. A method as claimed in claim 9, wherein the request and control of data transfer is performed using Real-time Streaming Protocol (RTSP), and data transfer is performed using Real-Time Transport Protocol (RTP).

13. A method as claimed in any one of claims 9 to 12, wherein data is received over a wireless communications link.