WO2010099984A1

WO2010099984A1 - Method and system for efficiently using available network access resources

Info

Publication number: WO2010099984A1
Application number: PCT/EP2010/001437
Authority: WO
Inventors: Sebastian Kiesel; Martin Stiemerling
Original assignee: Nec Europe Ltd.
Priority date: 2009-03-06
Filing date: 2010-03-08
Publication date: 2010-09-10

Abstract

A method for efficiently using available network access resources, wherein a plurality of nodes (1) is located within the same local area (2), each of said nodes being equipped with at least a first interface - access-link (3) - providing Internet connectivity with a certain bandwidth and a second interface - sharing link (4) - connecting said nodes locally with each other, is characterized in that two or more nodes - participating nodes (1 ) - of said plurality of nodes collaborate with each other by coordinating the deployment of their access-links (3) to achieve a cumulative bandwidth. Furthermore, a corresponding system is disclosed.

Description

METHOD AND SYSTEM FOR EFFICIENTLY USING AVAILABLE NETWORK ACCESS RESOURCES

The present invention relates to a method for efficiently using available network access resources, wherein a plurality of nodes is located within the same local area, each of said nodes being equipped with at least a first interface - access-link - providing Internet connectivity with a certain bandwidth and a second interface - sharing link - connecting said nodes locally with each other.

Furthermore, the present invention relates to a system for efficiently using available network access resources, including a plurality of nodes being located within the same local area, each of said nodes being equipped with at least a first interface - access-link - providing Internet connectivity with a certain bandwidth and a second interface - sharing link - connecting said nodes locally with each other.

There exist several different access technologies for connecting a computer or similar device to the Internet. Each of them is more or less restricted with respect to the reliability (e.g., uptime, error rate) and the achievable data rate (bandwidth). To mitigate this problem, there are multiple technologies that are used to increase reliability or bandwidth by using multiple network links, to satisfy customer demands. These demands can be, for instance, a higher availability of the network connection by using multiple links from different providers; or to increase the throughput as there is only a limited deployed capacity (x-DSL, Digital Subscriber Line). The techniques used to get to this point are typically called channel- bonding, multi-channel (Point-to-Point-Protocol PPP/Virtual Private Network VPN), link bundling, etc.

However, none of these existing approaches considers the specific needs of the user applications in detail, nor do they assume that the resources to be bundled are under different administrative control, nor do these techniques consider changing network environments. Changing in this context means that links can appear and vanish forever (much more volatile) and that links do not necessarily have an on/off characteristic (e.g., wireless links, but also DSL links, can heavily vary in their bandwidth).

The present invention assumes a collection of various network access technologies, e.g., DSL, GPRS (General Packet Radio Service), or UMTS (Universal Mobile Telecommunications System), which offer - compared to fixed line broadband network access like e.g., FTTH (Fibre To The Home) - a more restricted service: In general, the achievable throughput (bit rate) is lower, and it may vary over time and even drop to zero, e.g., if the user leaves the wireless coverage area or if a link is going down. Furthermore, transmission of data over certain network access technologies is usually more expensive than in other networks, e.g., mobile wireless is more expensive as a fixed line or wireless LAN (Local Area Network). Despite these limitations, this type of network access is sufficient to run various applications, such as WWW (World Wide Web) or email, with satisfactory user experience. However, for more demanding applications, e.g., download of a podcast (i.e., or larger files in general) and peer-to-peer applications (such as file sharing or Internet Protocol Television IPTV), each of the named technologies may not qualify, as the bandwidth is not sufficient.

It is therefore an object of the present invention to improve and further develop a method and a system of the initially described type in such a way that network access resources that are available for individual nodes are enhanced so that even nodes with restricted and scare network access resources benefit from being enabled to run more demanding applications.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim, such a method is characterized in that said two or more nodes - participating nodes - of said plurality of nodes collaborate with each other by coordinating the deployment of their access-links to achieve a cumulative bandwidth.

Furthermore, the aforementioned object is accomplished by a system comprising the features of independent claim 18. According to this claim, such a system is characterized in that two or more nodes - participating nodes - of said plurality of nodes collaborate with each other by coordinating the deployment of their access- links to achieve a cumulative bandwidth.

According to the invention it has been recognized that, in some scenarios, there is not typically a single user interested in an item out of the Internet, but typically there are multiple users consuming the same resource, such as the same IPTV channel or web page. The invention assumes a group of nodes, which are all equipped with a network access technology that offers access to the Internet, possibly with the constraints as described above. Furthermore, it is assumed that the nodes in the group are able to communicate with each other using a second, different communication network technology, which provides high link capacity free of charge (e.g., WLAN in asd-hoc mode), but does not provide direct Internet access. This second assumption usually implies that the nodes have to be in physical proximity for a reasonable time span. However, this physical context may be moving, e.g., if all mobile terminals are placed inside the same railway coach. The second, group-internal communication facility is used to coordinate the usage of the precious individual Internet access links and for group-internal redistribution of data that has been retrieved from the Internet by one group member. Thus, not all nodes have to up- or download the same piece of data from/to the Internet individually, but instead the resource to be accessed is sliced into pieces and accessed in a joint effort, increasing performance and reducing costs.

The present invention proposes that nodes that want to retrieve a resource from the Internet, but possibly do not have enough bandwidth to access it reasonably or wish to use bandwidth more efficiently, form an alliance with other nodes in their vicinity that are possibly in the same situation to enable coordinated joint access to the desired resource. To this end nodes may actively search for other terminals. The collaboration of nodes for establishing a cumulative bandwidth and for obtaining the required throughput is achieved by the nodes coordinating the deployment of their access-links, i.e. coordinating the distribution of download and upload. As a result of this coordination of scare resources, an individual node has to download and upload only parts of the desired resource. Consequently, since the described coordination of download/upload significantly improves the efficiency of using available network access resources, the present invention allows - A -

demanding applications, like e.g. P2P-TV, also for nodes with restricted network access and, even if the nodes are on the move.

According to a preferred embodiment it may be provided that the participating nodes use their sharing links to build a local network that can be used for collaboration among the nodes to achieve a cumulative bandwidth. The local network can, for example, use the IEEE 802.11 ad-hoc mode, or use an 802.11 base station to connect each of the nodes. For instance, it may be provided that the participating nodes form a link-local IP network among each other, for instance, either using IPv4 or IPv6 self-assigned link local addresses. These addresses can be used to establish communication amongst the participating nodes. The nodes can use a local identifier (e.g., an opaque string, a number, etc) to identify whether they are on the same link or area. This local identifier must be globally unique so that only nodes in a certain area are exchanging data.

With respect to an efficient establishment of a collaboration of nodes, the nodes' sharing-link may use service discovery techniques to discover other nodes in the same area that are willing to participate in the access-link coordination. Service discovery techniques may include, but not limited to, SDP (Service Discovery Protocol, UPnP (Universal Plug and Play) and/or Bonjour, which is a specific implementation of the zeroconf-system.

With regard to a further enhancement of the efficiency of the collaboration establishment process, the discovery process can benefit from additional knowledge of the nodes about their context, such as the fact that they are located in a specific area, for instance in a specific railroad coach. This knowledge may be derived, for example, from user input, by querying topology information services, e.g., IETF ALTO (Application-Layer Traffic Optimization), or from location beacons, such as RFID tags in train coaches.

In a specific embodiment the nodes may use the information about their location to form a location-specific tag that describes this location. An example for such a tag can be "ICE2190", if the nodes are located in a train with the number ICE 2190. This tag may be stored in a repository together with the node's ID (e.g., within the ALTO service). The node's ID might be a system specific ID, an IP address, or any other unique identifier. The repository may be maintained in the Internet or in another location that is accessible by other nodes within the same location.

Alternatively or additionally, nodes in the same location may be supported by an entity local to the location, e.g., a train network infrastructure, i.e., the wireless access points in the train or RFID tags sticking to the train. This information may be used by the nodes to build a specific IPv6 address (i.e., with a specific prefix for this purpose), where the lower part of the prefix may be constructed out of the location information. This information may be stored in a repository together with the node's ID (e.g., within the ALTO service). Again, the repository may be maintained in the Internet or in another location that is accessible by other nodes within the same location. Preferably, the repository is the same as the one used for storing the location-specific tag mentioned above.

By using a repository as described above, it may be provided that a new node arriving in a location builds the respective information, i.e. either a location-specific tag or an IPv6 address with location-specific part of the prefix, or both. Thereby the node is enabled to use this information in order to query the repository to find other nodes that are in the same location.

In addition to the general expression of will to participate in the collaboration, discovery messages exchanged among nodes may also contain some additional information, in particular information on how much external bandwidth a node is willing to contribute. Furthermore, discovery messages may include additional context information that might be helpful for assessing the quality of a bandwidth contribution offered by a node, for instance information on how long the node will presumably stay in the location. For example, a node may be excluded from the collaboration, even if he offers to contribute a large amount of bandwidth, in case the node will be staying in the location for a very short time period only, e.g. because the owner of the node will be leaving a train right at the next station.

With respect to an efficient management of the collaboration, a decision function may be provided that, e.g. subsequent to the discovery phase, determines the sum of all external bandwidths the nodes are willing to contribute. More specifically, it may be provided that the available bandwidth is calculated either by passive observation of the actual throughput or by collaborative testing of bandwidth. The collaborative testing can help to avoid the issues of overbooking, as the transmission rate of one node may go down if another one starts downloading.

Further, the decision function may decide whether this sum, i.e. the cumulative bandwidth, is sufficient for accessing the desired resource. In this context the decision function may be configured to take into consideration that some multimedia resources are available in different quality levels (e.g., screen resolution), requiring different download bandwidths. The decision function may be used to select the best encoding that can be downloaded with the available resources. If the aggregated cumulative bandwidth is still not sufficient for the lowest quality level, the nodes may be informed that the resource cannot be accessed reasonably even in a joint effort. Furthermore, the decision function may check whether the sharing-link has enough capacity to exchange the data locally.

According to a preferred embodiment, a control system is provided that keeps availability records for the access-links of each of the participating nodes. The control system may be a single control node or a distributed mechanism. The availability record may be built during the run time of the system and can also have historical or empirical data as seed. The availability records may include a distribution where the probability for access-link failures over time is listed (e.g., how often a link will be unavailable for a given period of time). In case the resource to be downloaded is subdivided in single resource units, e.g. referred to as chunks or atomic units, the availability records may be used to schedule which of the links is assigned to download a certain resource unit at what time and under what probability. The scheduling can use application-specific facts, such as, for example, that not all resource units are needed in case of video transmissions, if the video can be restored out of parts (e.g., by means of forward error correction (FEC), or multiple description encoding). The availability records may be updated during runtime, by using the transmission results of the transmitted atomic units of each link. The control system can also decide to assign the same resource unit to multiple access-links at the same time. Such redundancy may be useful, if the resource unit is fully required and must be received by the system in any case. When a resource unit is retrieved, it is shared with the other participating nodes via the sharing-link. This ensures that all nodes receive all chunks and can use them, e.g., for their trading logic (e.g. tit-for-tat).

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claims 1 and 18 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will we explained.

In the drawings the only

Fig. illustrates a usage scenario of a method according to an embodiment of the present invention with collaborating nodes being located in a train.

Some applications have a high resource demand in comparison to the available network access resources, such as file sharing or peer-to-peer TV, but not limited to. These applications are used by a group of people interested in the offered service (content) in an uncoordinated way with respect to where those people, better their computers (devices or mobile terminals in general) are located.

For example, in the scenario illustrated in the Fig. multiple mobile terminals 1 are located on a train 2 and each of the mobile terminals 1 has an Internet connection using a wireless access technology (called access-link 3). These access-links 3 can either be, but not limited to, GPRS or UMTS. Another case (not sketched in the Fig.) is, where multiple users in a house are accessing the Internet via DSL- links and do not coordinate their actions to retrieve certain data (e.g., P2PTV live streaming).

The access-links 3 can, for example, be constrained in terms of bandwidth or other parameters, but must not necessarily. The mobile terminals 1 use their access- links 3 to access data in the Internet, such as WWW or IPTV. For most WWW applications this works fine (also for other client/server applications), as the reduced link bandwidth results in a user experience (especially waiting times), which is worse than on a fixed-line broadband access, but still acceptable.

However, for different classes of applications, less bandwidth just means no usable service, or the same piece of data is unnecessarily downloaded multiple times. One well-known class is IPTV or P2P-IPTV. IPTV in general is not usable via mobile wireless access (GPRS & UMTS), as the bandwidth does not allow transferring video/audio in a reasonable TV quality. On the other hand, for file sharing there is typically no good way of coordinating the download behavior of multiple peers that are located in the same house.

Many possible use cases exist for the present invention, like e.g. web site access (using HTTP) and file transfer (using FTP); however, in the following the appliance of the present invention in the context of a peer-to-peer application will be exemplarily described. Peer-to-peer applications are typically using a distribution mechanism for exchanging data between different peers. This distribution mechanism is typically based on a smallest atomic unit, i.e., a data chunk. The algorithms used are based on this chunk concept, but other concepts with sub- units of a unit are also possible. For example, a web page typically consists out of multiple elements, where each element can be seen as an atomic unit that can be retrieved independently of other elements.

Typically, peers do the downloading only for their own local interest and try to maximize the throughput of their local connection. However, part of the distribution mechanism is an incentive mechanism that keeps track of how many chunks are downloaded to a peer and how many are uploaded. Typically, this mechanism (e.g., tit-for-tat or others) are used to keep freeriders out of the system, i.e., peers that only download but not upload. However, this mechanism also prevents peers with a low uplink bandwidth (mobile nodes) connection from obtaining a reasonable downlink speed. As will be described in more detail below, the present invention extends the peer-to-peer chunk scheduling mechanism from a selfish peer behavior to more cooperative behavior.

As already mentioned above, peer-to-peer applications are typically obtaining a series of chunks from different sources to re-construct a data file or a sequence for video/audio live streaming. The retrieval of chunks can follow any order, rarest first, random, or sequential. A sequential order will be used for the following explanation, but the approach is not limited to this.

Each participating node/peer 1 is equipped with at least two interfaces, one for connecting to the Internet (via the respective Internet Service Provider) and one for connecting locally. The interface connecting to the Internet is called access-link 3 and the link connecting locally is called sharing-link 4. The access-link 3 may be constrained in the sense of having bandwidth limitations, but provides Internet connectivity while being static at one location or while being on the move. The participating nodes 1 are located in the same spot, e.g., in the same local area, the same coach, or in the same train 2, as illustrated in the Fig.

Each participating node 1 can use its own access-link 3 to get an amount of B₁ bandwidth (which in fact is the bandwidth delivered by the mobile wireless access network). The access link 3 bandwidth B₁ is insufficient to obtain a data set D in a given time frame (e.g., to receive enough video frames in time to display the video to a human). However, the cumulative bandwidth of all n participating nodes 1

B = ∑ k, ^* B,

1

is sufficient to obtain a data set D in a given time frame. The parameter k is a scaling factor {O ≤ k, < 1 ), as not every participating node 1 is willing to devote its full bandwidth). In the embodiment illustrated in the Fig., the nodes 1 perform the following steps to reach the point where they can collaborate to achieve a cumulative bandwidth:

1. The participating nodes 1 are using their sharing-link 4 to build a local network that can be used for the next steps. This local network can, for example, use the IEEE 802.1 1 ad-hoc mode, or use an 802.11 base station to connect each of the nodes 1.

2. The participating nodes 1 use the established sharing-link 4 to form a link- local IP network, for instance, either using IPv4 or IPv6 self-assigned link local addresses. These addresses are used to establish communication amongst the participating nodes 1. The nodes 1 can use a local identifier (e.g., an opaque string, a number, etc) to identify whether they are on the same link or area. This local identifier must be globally unique so that only nodes in a certain area are exchanging data.

3. The sharing-link 4 uses service discovery techniques (SDP, UPnP, Bonjour, etc) to discover nodes that are willing to participate in the access-link coordination. The discovery process can benefit from additional knowledge of the terminals about their context, such as the fact that they are located in a specific railroad coach. This knowledge may be derived, for example, from user input, by querying topology information services (e.g., IETF ALTO), or from location beacons, such as RFID tags in train coaches.

4. In addition to the expression of will to participate, the discovery messages also contain some additional information, such as how long the node will stay in this location, and how much external bandwidth it is willing to contribute.

5. After this discovery phase a decision function determines the sum of all external bandwidths the nodes 1 are willing to contribute, and decides whether this sum is sufficient for accessing the desired resource. Some multimedia resources are available in different quality levels (e.g., screen resolution), requiring different download bandwidths. The decision function may be used to select the best encoding that can be downloaded with the available resources.

6. The participating nodes 1 are coordinating the usage of the access-links. The mobile terminals 1 use now, before starting to download chunks, their sharing- link 4 to negotiate which mobile terminal 1 will download which chunk or series of chunks. Once they have agreed on this, each mobile terminal 1 starts downloading the assigned series of chunks to its local cache. When a chunk is retrieved, it is shared with the other participating mobile terminals 1 via the sharing-link 4. This ensures that all terminals receive all chunks and can use them, e.g., for their trading logic (e.g. tit-for-tat).

It is to be noted that the steps listed above are also applicable, in the case that S, is sufficient to obtain the required data fast enough (i.e. in cases B₁ is larger or equal than the required bandwidth), as the nodes 1 do coordinate their download behavior for a more efficient resource usage.

Advantages of the present invention compared to current state of the art techniques can be summarized as follows:

HTTP, which is often used to access WWW pages that consist of smaller units (text, images, style sheets, etc.) has some means for reducing download volume by means of proxy caches, but there is no standardized way to discover them, and there is no mechanism that can be used by "normal" clients to jointly download something.

State-of-the-art P2P software, such as BitTorrent, exchanges atomic units of data ("chunks"). A chunk trading logic assures some kind of fair resource sharing, i.e., freeriders that consume data without providing resources will be excluded. However, all known systems first download a chunk and then start trading with it. Especially on slow links (GPRS) this may lead to race conditions, i.e., two peers downloading the same chunk simultaneously. The proposed scheme coordinates the downloads before they actually start, i.e., the peers could use their precious bandwidth for downloading different chunks. In combination with the high-speed local network this creates greater benefit for all group members. It can also be used to coordinate the uploads, as upload capacity is typically even more limited and the upload rate is used by peer-to-peer system to judge the "quality" of a peer. Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for efficiently using available network access resources, wherein a plurality of nodes is located within the same local area, each of said nodes being equipped with at least a first interface - access-link (3) - providing Internet connectivity with a certain bandwidth and a second interface - sharing link (4) - connecting said nodes locally with each other, c h a r a c t e r i z e d i n that two or more nodes - participating nodes (1) - of said plurality of nodes collaborate with each other by coordinating the deployment of their access-links (3) to achieve a cumulative bandwidth.

2. Method according to claim 1 , wherein said participating nodes (1) use said sharing links (4) to form a link-local IP network among each other.

3. Method according to claim 1 or 2, wherein IPv4 or IPv6 self-assigned link local addresses are used for enabling communication amongst said participating nodes (1).

4. Method according to any of claims 1 to 3, wherein said nodes use service discovery techniques to discover via said sharing links (4) other nodes that are willing to participate in said access-link coordination.

5. Method according to claim 4, wherein the discovery process takes into consideration the knowledge of nodes about their context, in particular their location.

6. Method according to any of claims 1 to 5, wherein nodes use the knowledge about their location to generate location-specific tags that are stored in an accessible repository together with said nodes' identifiers.

7. Method according to any of claims 1 to 6, wherein nodes use location information received from a supporting entity to generate specific IP addresses that are stored in an accessible repository together with said nodes' identifiers.

8. Method according to claim 6 or 7, wherein said specific IP addresses are IPv6 addresses with the lower part of the prefix being constructed out of said location information.

9. Method according to claim 8, wherein nodes arriving in said local area query said repository to find other nodes located in the same local area.

10. Method according to any of claims 4 to 9, wherein discovery messages include information regarding said participating nodes' (1) intended bandwidth contribution.

11. Method according to any of claims 1 to 10, wherein a decision function is provided that determines said cumulative bandwidth as the sum of the bandwidth contributions of all participating nodes (1).

12. Method according to claim 11 , wherein said decision function decides whether said cumulative bandwidth is sufficient for accessing a desired resource.

13. Method according to claim 11 or 12, wherein said decision function selects an appropriate quality level for downloading resources that matches with said cumulative bandwidth.

14. Method according to any of claims 11 to 13, wherein said decision function informs said participating nodes (1) in case said cumulative bandwidth is not sufficient even for downloading a lowest available quality level.

15. Method according to any of claims 1 to 14, wherein a control system is provided that keeps availability records for each of said participating nodes' (1) access-links (3).

16. Method according to claim 15, wherein said availability records are employed to schedule the download of a resource among the access-links (3) of said participating nodes (1).

17. Method according to any of claims 1 to 16, wherein the resource to be downloaded is subdivided into single resource units, and wherein each resource unit, after being downloaded via an access link (3) of at least one of said participating nodes (1 ), is shared with the other participating nodes (1 ) via said sharing-links (4).

18. System for efficiently using available network access resources, in particular for executing a method according to any of claims 1 to 17, including a plurality of nodes being located within the same local area, each of said nodes being equipped with at least a first interface - access-link (3) - providing Internet connectivity with a certain bandwidth and a second interface - sharing link (4) - connecting said nodes locally with each other, c h a r a c t e r i z e d i n that two or more nodes - participating nodes (1) - of said plurality of nodes collaborate with each other by coordinating the deployment of their access-links (3) to achieve a cumulative bandwidth.

19. System according to claim 18, including a decision function for determining said cumulative bandwidth as the sum of the bandwidth contributions of all participating nodes (1 ).

20. System according to claim 18 or 19, including a repository being configured to store location-specific tags and/or location-specific IPv6 addresses generated by nodes together with said nodes' identifiers.

21. System according to claim 20, wherein said repository is maintained in the Internet.

22. System according to any of claims 18 to 21 , including a control system being configured to keep availability records for each of said participating nodes' (1) access-links (3).