WO2004082210A2 - A method of transferring a data file between stations in a network - Google Patents

Abstract

The invention provides a method of transferring a data file from a first station to a second station, the first and second stations both being connected to a first connection interconnecting the first and second stations, the method comprising the steps of determining a required bandwidth for transferring the data file, determining an available bandwidth of the first connection, comparing the required bandwidth for transferring the data file with the available bandwidth on the first connection, and if the available bandwidth on the first connection is smaller than a predetermined fraction of the required bandwidth for transferring the data file, and if a second connection with the required bandwidth is available, connecting the first and second stations to the second connection and possibly disconnecting them from the first connection. The required bandwidth can be specified by the user due e.g. to a wish or a need for a maximum transfer time of the file, or by a system or network administrator due e.g. to a wish to move traffic from one band to another or from one network to another.

Description

A method of transferring a data file between stations in a network

This invention relates to communication between two or more stations over a wired or wireless network such as a local area network (LAN) governed e.g. by the IEEE 802.1 lb or Bluetooth standard, or another suitable standard. Wireless local networks are becoming more and more widespread in office and other professional environments, and are being introduced in private homes, too. Such local networks enable stations, and in particular portable stations such as laptop computers, personal digital assistants (PDA's), portable MP3 jukeboxes etc. to connect to an office infrastructure and to each other.

In networks it is usually good policy not to reserve or occupy excessively large bandwidths, i.e. considerably more than can be foreseen as being necessary for the planned activities. From time to time a user will need a larger bandwidth than is actually available or what is at his immediate disposal.

If two stations in e.g. an IEEE 802.1 lb wireless network are to transfer a large file in a short time, and a connection with a higher bandwidth than the actual network can provide is needed for the transfer to occur at maximum speed (speed can be limited either by available bandwidth or by the speed at which the end-stations can provide and consume data), it may be detrimental to the transfer speed, if the two stations have to share the available bandwidth on the network with other stations. In other cases a high, guaranteed bandwidth may be needed for e.g. a real-time application, possibly only for a shorter period, and the required bandwidth may not be readily available on the actual network. Typically, real-time applications care more about guarantees and short delays than throughput. If a third party device occupies the network (i.e. a portion of its bandwidth) at a "wrong" time, this may introduce undesired delays. In the above and in other cases the bandwidth limitation can be either a physical limitation in the network such as in the actually used, bandwidth-limited channel in a multi-channel network, or the bandwidth limitation can be caused by other traffic on the channel. WO 01/24453 discloses a multiplayer telecommunications network, which is suitable for use with the present invention.

In an IEEE 802.1 lb network it is often possible to operate two or more wireless networks within the same physical location, without interference, by using different parts of the frequency spectrum, i.e. different frequency bands. The invention can be implemented in point-to-point connections with only two stations involved in each connection, or in networks, typically with several stations connected to the network. A connection or a network can also be a frequency limited band of a broader bandwidth network with several such bands.

The invention provides a solution to the above-defined problem of transferring a data file from a first station to a second station, the first and second stations both being connected to a first connection interconnecting the first and second stations, by a method comprising the steps of determining a required bandwidth for transferring the data file and determining an available bandwidth of the first connection. The required bandwidth for transferring the data file is compared with the available bandwidth on the first connection, and if the available bandwidth on the first connection is smaller than a predetermined fraction of the required bandwidth for transferring the data file, and if a second connection with the required bandwidth is available, the first and second stations are connected to the second connection. Possibly, the first and second stations are also disconnected from the first connection. The required bandwidth can be specified by a user due e.g. to a wish or a need for a maximum transfer time of the file, and the "required" bandwidth may thus rather be a "desired" bandwidth. Or a system or network administrator may wish to move traffic from one band to another or from one location to another. Users often want the transfer of a file to be "as fast as possible", and waiting time is a nuisance. There is often not an objective requirement to transmission speed. What is decisive is whether the users find the difference between, or the ratio of, the available bandwidths to be significant for a switching from one connection to the other to be considered a benefit. The predetermined fraction of the required bandwidth for transferring the data file can thus be any (often subjectively defined) predetermined number and can, depending on the circumstances, be greater than 1, equal to 1 or smaller than 1.

The invention thus provides a method of operating two stations in e.g. an IEEE 802.1 lb wireless network. When it has been determined, based on predefined criteria, that a bandwidth higher than the bandwidth available on the actually used connection is required or desired for transferring a file from one station to the other over the connection, the stations involved (or their users) can agree on using another connection, possibly after a search for another connection with a higher available bandwidth has been performed and its available bandwidth has been confirmed. The stations involved may "negotiate" a breakout of the existing connection, i.e. to disconnect from the connection, or they can stay connected via the existing connection. The second network can be an already established network at the same physical location as the first network or at a different physical location.

In an embodiment of the invention using a wireless connection, if a new connection or network cannot be established at the actual location, the users of the involved stations are directed to a different location where the required bandwidth is available, e.g. due to less traffic or to higher capacity.

The invention preferably uses the Universal Plug and Play (UPnP) ContentDirectory Service (CDS) and Control Points on each station. The current version is the UPnP AV Architecture^.83 for Universal Plug and Play Version 1.0. Status: Preliminary Design (TPD), date: June 12, 2002, not yet finished. Other documents, specifically the ContentDirectory: 1 specification, have been standardized.

The AV (audio- visual) Architecture defines the general interaction between UPnP Control Points and UPnP AV devices. It is independent of any particular device type, content format, and transfer protocol. It supports a variety of AV devices such as TVs, VCRs, CD/DVD players/jukeboxes, settop boxes, stereo systems, MP3 players, still-image cameras, camcorders, electronic picture frames (EPFs), and the PC. The AV Architecture allows devices to support different types of formats for the entertainment content (such as MPEG2, MPEG4, JPEG, MP3, Windows Media Architecture (WMA), bitmaps (BMP), NTSC, PAL, ATSC, etc.) and multiple types of transfer protocols (such as IEC-61883/IEEE-1394, HTTP GET, RTP, HTTP PUT/POST, TCP/IP, etc.). The document describes the AV Architecture and how the various UPnP AV devices and services work together to enable various end-user scenarios.

The UPnP AV Architecture was explicitly defined to meet the following goals: - To support arbitrary transfer protocols and content formats.

To enable the AV content to flow directly between devices without any intervention from the Control Point. To enable Control Points to remain independent of any particular transfer protocol and content format. This allows Control Points to transparently support new protocols and formats.

Scalability, i.e. support of devices with very low resources, especially memory and processing power as well as full-featured devices.

In most (non-AV) UPnP scenarios, a Control Point controls the operation of one or more UPnP devices in order to accomplish the desired behavior. Although the Control Point is managing multiple devices, all interactions occur in isolation between the Control Point and each device. The Control Point coordinates the operation of each device to achieve an overall, synchronized, end-user effect. The individual devices do not interact directly with each another. All of the coordination between the devices is performed by the Control Point and not by the devices themselves.

Most AV scenarios involve the flow of (entertainment) content (i.e. a movie, song, picture, etc.) from one device to another. An AV Control Point interacts with two or more UPnP devices acting as source and sink, respectively. Although the Control Point coordinates and synchronizes the behavior of both devices, the devices themselves interact with each other using a non-UPnP ("out-of-band") communication protocol. The Control Point uses UPnP to initialize and configure both devices so that the desired content is transferred from one device to the other. However, since the content is transferred using an "out-of-band" transfer protocol, the Control Point is not directly involved in the actual transfer of the content. The Control Point configures the devices as needed, triggers the flow of content, then gets out of the way. Thus, after the transfer has begun, the Control Point can be disconnected without disrupting the flow of content. In other words, the core task (i.e. transferring the content) continues to function even without the Control Point present. As described in the above scenario, three distinct entities are involved: the Control Point, the source of the media content (called the "MediaServer"), and the sink for the content (called the "MediaRenderer").

The involved control point will often be included in either the source or the sink.

Today the most common task that end-users want to perform is to render (i.e. play) individual items of content on a specific rendering device. A content playback scenario involves three distinct UPnP components: a MediaServer, a MediaRenderer, and a UPnP Control Point. These three components (each with a well-defined role) work together to accomplish the task. In this scenario, the MediaServer contains (entertainment) content that the user wants to render (e.g. display or listen to) on the MediaRenderer. The user interacts with the user interface (Ul) of the Control Point to locate and select the desired content on the MediaServer and to select the target MediaRenderer. Another common task is to retrieve/upload data at maximum speed from/to a content directory, typically using http-get or http-post and/or the import/export actions of the content directory.

The MediaServer contains or has access to a variety of entertainment content, either stored locally or stored on an external device that is accessible via the MediaServer. The MediaServer is able to access its content and transmit it to another device via the network using some type of transfer protocol. The content exposed by the MediaServer may include arbitrary types of content including video, audio, and/or still images. The content is transmitted over the network using a transfer protocol and data format that is understood by the MediaServer and MediaRenderer. MediaServers may support one or multiple transfer protocols and data formats for each content item, or may be able to convert the format of a given content item into other formats on the fly. Examples of a MediaServer include a VCR, CD DVD player/jukebox, camera, camcorder, PC, set-top box, satellite receiver, audio tape player, etc.

The ContentDirectory Service, CDS, provides a set of actions that allow the Control Point to enumerate the content that the MediaServer can provide to the home network. The primary action of this service is Browse(). This action allows Control Points to obtain detailed information about each Content Item that the MediaServer can provide. This information (i.e. meta-data) includes properties such as its name, artist, date created, size, etc. Additionally, the returned meta-data identifies the transfer protocols and data formats that are supported by the MediaServer for that particular Content Item. The Control Point uses this information to determine if a given MediaRenderer is capable of rendering that content in its available format.

Within a home network many devices contain various types of content that other devices might require to access (e.g. music, videos, still images, document files etc.). As an example, a Media Server device might contain a significant portion of the user's audio, video, and still-image library. In order for the user to enjoy this content, he must be able to browse the objects stored on the Media Server, select a specific one, and cause it to be "played" on an appropriate rendering device (e.g. an audio player for music objects, a TV for video content, an Electronic Picture Frame for still-images, etc.). For maximum convenience, it is highly desirable to allow the user to initiate these operations from a variety of user interface (Ul) devices. In most cases, these Ul devices will either be a Ul built into the rendering device, or it will be a stand-alone Ul device such as a wireless PDA or tablet PC. In any case, it is unlikely that the user will interact directly with the device containing the content (i.e. the user won't have to walk over to the server device). In order to enable this capability, the service device needs to provide a uniform mechanism for Ul devices to browse the content on the server and to obtain detailed information about individual content objects. This is the purpose of the ContentDirectory Service, CDS. The ContentDirectory Service additionally provides a lookup/storage service that allows clients (e.g. Ul devices) to locate (and possibly store) individual objects (e.g. songs, movies, pictures, etc.) that the (server) device is capable of providing. For example, this service can be used to enumerate a list of songs stored on an MP3 player, a list of still- images comprising various slide-shows, a list of movies stored in a DVD Jukebox, a list of TV shows currently being broadcast (also known as an EPG), a list of songs stored in a CD Jukebox, a list of programs stored on a PVR (Personal Video Recorder) device, etc. Nearly any type of content can be enumerated via this ContentDirectory Service. For those devices that contain multiple types of content (e.g. MP3, MPEG2, JPEG, etc.), a single instance of the ContentDirectory Service can be used to enumerate all objects, regardless of their type.

Fig. 1 illustrates a wireless network with a plurality of stations connected to the network.

Fig. 2 illustrates a new network created for the use of two of the stations in Fig. 1 for the transfer of a file between the two stations.

Fig. 3 illustrates schematically a station for use with the invention.

In the following a preferred embodiment of the invention will be described. In Fig. 1 is shown a first network with a plurality of stations A, B, C and D connected to form the first network. The first network is a wireless network operating in accordance with the IEEE 802.1 lb standard or the Bluetooth specification, and the invention uses the Universal Plug and Play (UPnP) ContentDirectory Service (CDS) and Control Points on each station. It is desired to transfer a data file to a first station A from a second station B. Decisions can be made by human interference by an operator, or automatically by the stations involved or by the network, e.g. by an application running on one or both of the stations. Likewise, actions can be taken and method steps can be performed by human interference or automatically. The following steps are preferably performed.

1. Station A decides on initiating a data transfer with station B. In a preferred embodiment station A implements a UPnP Control Point, and station B implements a UPnP content directory. Station A has selected a file F for downloading from station B. A and B both run UPnP over IP over the first network. 2. Station A calculates whether the first network can provide the transfer satisfactorily, or whether a breakout of the first network would be beneficial. A possible criterion depends on the estimated available bandwidth in the first network, e.g. a maximum bandwidth, or the current average network load. Another criterion depends on breakout options, e.g. a possible new UPnP "breakout" service which has a "SupportedNetworks" action (e.g. Bluetooth, IEEE 802.1 la/b), matching with networks supported by station A. A third criterion is if the estimated bandwidth on breakout is much larger than the estimated bandwidth in the first network. If a suitable second network has been identified, and it has been decided that a breakout would be beneficial, step 3 below will be performed.

3. Station A indicates to station B that a suitable second network has been identified, and station A negotiates with station B to break out of the first network. The breakout service can have a "RequestBreakout" action specifying the second network to which the break out is desired. Station B can refuse to break out of the first network, for example if station B is engaged with other stations connected to the first network. If station B supports multiple networks, station B can accept being connected to the second network and still stay connected to the first network. If station B accepts to break out of the first network, a final handshake action and breakout occurs after a short timeout.

4. Stations A and B set up the agreed second network with agreed parameters, and either one of the stations A and B starts the second network, the other station joins in, and the transfer of the file over the second network can be initiated. After completion of the transfer of the file between stations A and B over the second network, stations A and B can either stay connected to the second network, or they can break out of the second network and re-join the original first network or possibly another network. If the actually used connection camiot provide the required bandwidth for transferring a file between two stations, it may be relevant to connect to another band of the available spectrum using the above-described method.

It may also be that the locally available spectrum cannot provide the required bandwidth. Wireless connections e.g. in accordance with IEEE 802.1 lb or Bluetooth are short-range connections. IEEE 802.1 lb and Bluetooth use overlapping frequency ranges, which can give rise to interference. When breaking out of a Bluetooth connection to an IEEE 802.1 lb connection it is beneficial to stop sending Bluetooth packets, because Bluetooth packets decrease the bandwidth of the IEEE 802.1 lb connection. It may also be that the locally available spectrum can be occupied and the network set up by stations A and B is a low bandwidth connection, since the available spectrum is shared with other wireless networks established between other stations. By moving to another location where the spectrum is less occupied, the stations involved can establish a network in an unoccupied part of the spectrum. The method of the invention provides the possibility of directing the users of stations A and B to another (nearby) location where the required bandwidth is available due to the short-range characteristics of the standard and frequency spectrum used. This may require knowledge of the existence of such a location, and the users of stations A and B will then be informed of the location, and they are encouraged to move to that location and to connect their stations A and B at the new location. In the alternative, the users are encouraged to find a location with less wireless activity in the actual frequency band. This will preferably happen automatically under the control of a controller and is particularly useful in short-range applications.

An example of this is a group of school children in a school yard, where several of the children each are using a wireless station such as a mobile phone interconnected in one or more local networks, e.g. in accordance with IEEE 802.1 lb or a

Bluetooth piconet. Two of the children have decided to transfer a song file from the station of one of the children to the station of the other over the network. It turns out that the transfer is too slow due to heavy local traffic that occupies bandwidth, and they decide to move to a more "quiet" location in the school yard, i.e. a location with less wireless local traffic and thus a larger available bandwidth. As they move to the other location their stations indicate that the transfer speed is indeed increasing.

A further possibility is illustrated in Fig. 3 where station A communicates with a load meter, which is a device or an application that monitors the local traffic density, i.e. the occupied bandwidth and keeps track on the available bandwidth of networks at different locations.

A user of a station can hereby be alerted to the fact that the available bandwidth is not or no longer optimal, or if it for other reasons is desirable to have traffic moved to another network. The user can, in a simple manner, improve the available bandwidth on his actual location, or he can be directed to another location where the required bandwidth is available.

Claims

CLAIMS:

1. A method of transferring a data file from a first station (A) to a second station (B), the first and second stations both being connected to a first connection interconnecting the first and second stations, the method comprising the steps of: determining a required bandwidth for transferring the data file, - determining an available bandwidth of the first connection, comparing the required bandwidth for transferring the data file with the available bandwidth on the first connection, and if the available bandwidth on the first connection is smaller than a predetermined fraction of the required bandwidth for transferring the data file, and if a second connection with the required bandwidth is available, connecting the first and second stations (A, B) to the second connection.

2. A method according to claim 1 characterized by disconnecting the first and second stations (A, B) from the first connection.

3. A method according to claim 1 characterized in that the first connection is a first network, and that the second connection is a second network.

4. A method according to claim 1 characterized in that the first connection is a first frequency band in a frequency spectrum, and that the second connection is a second frequency band in the frequency spectrum.

5. A method according to any one of claims 1 -4, characterized in that the first connection is at a first location and the second connection is at a second location different from the first location.

6. A method according to claim 5, characterized in that an indicator of locally available bandwidth is used to indicate the available bandwidth at the first location and the available bandwidth at the second location.

7. A method according to claim 6, characterized by informing a user of the first station (A) of the available bandwidth at the second location.

8. A method according to any one of claims 1-7, characterized in that the network is in accordance with the IEEE 802.11 standard.

9. A method according to any one of claims 1 -8, characterized by the use of Universal Plug and Play ContentDirectory Service and Control Points.