WO2013038455A1

WO2013038455A1 - Peer selection with offloading and mobility

Info

Publication number: WO2013038455A1
Application number: PCT/JP2011/005229
Authority: WO
Inventors: Yu Xuan Zhou; Hong Cheng
Original assignee: Panasonic Corporation
Priority date: 2011-09-15
Filing date: 2011-09-15
Publication date: 2013-03-21

Abstract

A system with ability to consolidate terminal mobility status and predict potentially matched offloading peers which enables optimized peer selection is presented. The system comprises of a mobility information table that iterated among peers to gather their status information; one terminal device who can predict the possibility of a peer offloading to the same local network based on mobility information table; one P2P tracker application server that provides general control on the P2P sessions; one P2P peer that understands its mobility capacity and instant offloading status. The invention proposes a method that tracker server distributes an information table with a set of peers sharing the same content; the set of peers updates their offloading status and capacity whenever changes happened; the set of peers use consolidated information table to perform peer re-selection during the P2P session; finalized information table is updated to P2P tracker application server for future use. In the invention, server is blind to offloading techniques but only offers overall traffic control.Information gathering and decision making are completed at terminal side.

Description

PEER SELECTION WITH OFFLOADING AND MOBILITY

The present invention pertains to the field of telecommunication in a packet-switched communication network. More particularly, it targets at a peer to peer content distribution system with mobile terminals. Furthermore, it proposes a method using terminal consolidated information tables to assist peer selection considering peer offloading and mobility status.

P2P is an attractive novel technology, which uses scattered resources distributed within network to support content sharing. It has revolutionized the business of media distribution over past ten years by reducing the Internet content sharing cost down significantly. This trend is strengthened when nowadays mobile terminals become powerful enough to support large data transmission, and it will reinforced by future consumer-electronic devices embedded with network capacity. However, most mobile devices are still limited by the wireless access they use. The cellular network resources consumed by mobile devices are still limited and costly. Additionally, current cellular network still cannot support data transmission as fast as local network. Therefore when using mobile terminal device for P2P service, it needs to consider the usage of core 3G/4G network resource alongside the service quality.

In order to tackle the large volume data transmission problem within mobile communication networks, 3GPP has recently developed several techniques to offload the traffic to the nearest point of exit, e.g. LIPA (Local IP Access) and SIPTO (Selected IP Traffic Offloading) where selected traffic is directed to local network or gateway closer to the access point {Non-Patent Document 1}; Seamless and Non-seamless WLAN Offloading where Wi-Fi is used to carry data delivery {Non-Patent Document 2} {Non-Patent Document 3}; etc. These offloading would be activated based on mobile terminal location, connection status, subscriptions, destination of the traffic, operator policies, etc. It is obvious that with the offloading, mobile terminals for the P2P service could avoid transporting the contents over the cellular core network, and thus can avoid high cost and achieve better Quality of Service. Therefore, it is natural for the P2P service to strive selecting suitable peers such that the offloading path could be utilized.

A typical peer selection procedure is described in 3GPP TR23.844 {Non-patent document 4}. Tracker Application Server ("AS" or "Server" in the rest of the descriptions) is responsible to generate and respond a peer list when requested by the Terminal device. Terminal device contact peers on peer list for bitmap fetching. The AS construct the peer list considering metrics of access type, traffic condition, path cost information, location information, and capabilities and workload of terminal devices. Obviously, it does not consider the potential offloading possibilities in the peer list construction. Moreover, as mentioned, the offloading status of the mobile terminal could be highly dynamic, and the AS may not have sufficient information to evaluate when making the peer list. Requiring the AS to keep track of all the potential peers offloading status would result in large amount of signaling load to the cellular core network and AS, which can bring adversary effects. The AS is also not suitable for the offloading handling, as it may require it to understand all types of offloading techniques, which could be access technology specific and are evolving.

Several other prior works also touched the problem of peer selection optimization for mobile terminals. In {Patent document 1}, it has taken into account of physical distances between peers in cellular communications, trying to put nearby peers into the peer list. In {Patent document 2}, peers are selected based on peer ranking provided by the network operator. {Patent document 3} introduces a method that operator node selects peers based on operator preference stored in it.

3GPP TR23.829v10.0.0 "Local IP Access and Selected IP Traffic Offload"; Stage 2 (Release 10), 2011-03-29; 3GPP TS23.261v10.1.0 "IP flow mobility and seamless Wireless Local Area Network (WLAN) offload; 3GPP TS23.402v10.4.0 "Architecture enhancements for non-3GPP accesses; 3GPP TR23.844v0.3.0, "Feasibility Study on IMS Based Peer-to-Peer Content Distribution Services; Stage 2 (Release 11)"

EP2320624A1, "Method for managing a P2P network based on cellular communications", Mghazli and Taburet, Alcatel Lucent WO2011025608A1, "Network Assisted Mobile Centric Peer Selection Method", BI Hao and WU Jian Jun, Motorola WO2010064965A1, "Method for Selection of Suitable Peers in a Peer-to-Peer (P2P) Network", Damola Ayodele, Johnsson Andreas, and Kolhi Johan, Ericsson

However, none of the listed literature provides satisfactory solution to utilize offloading factor in the P2P peer selection strategy. {Patent document 1} solution is built on an assumption that it is better for nearby terminals serve each other. This is not fully true with offloading case. Due to the different offloading and access technology used, terminals close to each other or using the same access technology may not necessarily have a shorter path between them. For example, a terminal using LIPA access may have a shorter path to another terminal using WiFi access in another building, than to some terminal next to it attached to the same cellular base station.

{Patent document 2} and {Patent document 3} propose operator ranking or preference should be the dominant factor of peer assessment. It is logically correct but very difficult to apply on its own. Due to the mobility of terminals, operators or operator nodes need to retrieve instant information of terminals from MME/SGSN to work out a feasible peer ranking. But the present cellular network provides no interface between control point (MME/SGSN) and P2P tracker application server. Therefore P2P tracker application server has no way to know the instant status of mobile terminals, not to mention offloading status.

The offloading status of the mobile terminal can also be a varying factor. For example, a mobile terminal having the offloading capability may not always have the offloading connection established. Therefore, it is not always possible for the network to make decisions based purely on the current status of the mobile terminal. A mobile terminal could use a normal connection to communicate with the AS, and establish another offloading connection after received the peer list to communicate with the peer for data retrieving.

In view of the above, it is obvious that a more comprehensive peer selection solution is required to fully make use of the offloading potentials of the mobile terminals in the P2P service.

It is an objective of the invention to address the above-mentioned problems, shortcomings, and incompleteness. In particular, it aims to realize optimized peer selection in mobile P2P system considering instant peer mobility and offloading status.

Another objective of the invention is to minimize the impact to the tracker server. Even with new offloading techniques emerging in the future, the proposed invention still can be applied without changing the AS logic.

In one aspect, the solution provided system, methods, and apparatus for managing paths in the peer to peer data communication comprising a plurality of mobile terminals, wherein each of the mobile terminal is capable of receiving data from one or more of the other mobile terminals; and a Server that is capable of grouping one or more of the mobile terminals into a Peer Set for a peer to peer data communication; whereby, in use, the Server initiates a Mobility Status Table based on the Peer Set and distributes the Mobile Status Table to a mobile terminal in the Peer Set; the mobile terminals in the Peer Set exchange and update the Mobility Status Table according to their local information; and the mobile terminals in the Peer Set select one or more mobile terminal to start the peer to peer data communication according to the Mobility Status Table.

In another aspect, the solution makes use of terminals' knowledge of offloading and mobility configurations to support peer selection. The terminals exchange and stores status and make their decisions locally. Server is updated only when necessary.

In another aspect, the server is capable of initiating a MST update when it decides that the Peer Set is changed.

In yet another aspect, peer triggered status update and peer re-selection is enabled when mobility changes. Mobile terminal status changes unpredictably. Usually this change will not be updated to server and server will not inform affected mobile terminals. In the presented invention, such status change will trigger MST update among peer mobile terminals and enable them to make adjustment on whether switch to another peer. The status change information may not be updated to server immediately. Peers will select a suitable time to send it. This avoids too much signaling towards server.

With these solutions, mobile terminals are able to select peers with matched offloading peers. Server is shielded from to the second tier peer selection and will not actively participate in re-selection procedure. Mobile terminal devices make their decisions based on MST exchanged among the mobile terminals. Update messages to server are minimized; meanwhile user will not miss any chance to improve his experience by choosing the best peer to connect when having a P2P session.

The above and other objects and features of the invention will appear more fully hereinafter from a consideration of the following description taken in connection with the accompanying drawing wherein the solution is illustrated by way of example, in which FIG.1 is a diagram illustrating the architecture of tracker application server. It includes central control unit 58; peer service response function 57; integrated peer information database 50; message transmission unit 60. The integrated information database further consists of MST information base 51 and other information base 52. FIG. 2 is the architecture of mobile terminal device.It includes MST processor 75, offloading peer match function 78, device information database 70, central control function 80 and message transmission unit 85. The device information database further consists of MST base 71 and other information base 72. FIG. 3 is an example structure of Mobility Status Table. It is built by source peers (81~83) and destination peers (85~87). The Diagonal field (e.g. 90, 96, 98) is peer's own capacity; while the rest intersection fields (e.g. 91, 92, 95, 97) are the status of connections from source peer to destination peer. FIG. 4 is the flowchart of a tracker application server when a terminal joins P2P service. Besides the basic step 154 that generates the peer list, step 158 is added to attach to peer list an independent MST with selected peers. FIG. 5 is the flowchart of a mobile terminal when it joins P2P service. Upon receiving a peer list (170), terminal checks its offloading capacity (172) and perform second tier peer selection (176). Then it fills MST (180) and updates it to other peers (184). FIG. 6 is an example operation flowchart of peers during a P2P session. FIG. 7 is a message flow diagram illustrating the procedure of a new terminal joins P2P service. FIG. 8 is a message flow diagram illustrating the procedure of peer triggered status update and peer re-selection during a P2P session. It also includes steps to update server.

In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanied drawings, which form a part hereof, and which is shown by way of illustration, specific examplary embodiments of which the invention may be practiced. Each embodiment is described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that otherembodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention isdefined only by the appended claims. In the following description, for the purpose of explanation, specific numbers, times, structures, protocols, and other parameters are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to anyone skilled in the art that the present invention may be practiced without these specific details.

As the mobile terminals have better understanding of their own instant mobility/offloading capability/status than a network based Server, the invention proposed to use peer-assisted status consolidation and localized peer re-selection method. In the solution, mobile terminal devices provide their offloading capacity when request for a P2P service. The Tracker Server records this parameter. If a mobile terminal is capable of offloading, the Tracker AS attaches a basic peer list in the response with an information table called Mobility Status Table (MST), which contains recently updated information from offloading capable peers that can serve the mobile terminal. The Tracker AS also can designate a representative peer that is in charge of updating the Server of the latest MST when necessary. Upon receiving the basic peer list with MST, the mobile terminal checks its offloading configuration and tries to choose peers that can offload to the same local network. After establishing connections with selected peers, mobile terminal updates its information in MST and then exchanges MST with other peers in the list. Peer mobile terminals update MST based on their offloading status and keep a copy locally. Later if any peer detects an offloading status changes, it will trigger MST update among the peers in MST. Updated MST is use for peer re-selection during the P2P session. The Tracker AS will receive a copy of the completed MST when a predefined condition is met, and store it for future usage.

This way, the MST is maintained and used among the mobile terminals in the peer list chosen by the Tracker AS. The signaling for the MST updates does not need to go through the Tracker AS, and therefore significantly reduced the load on the core network and the processing on the Tracker AS. This allows must faster handling in the peer selection and re-selection, and offers better scalability for the P2P deployment, as the Tracker AS would have the resources to serve more sessions.

Figure 1 is an example architecture of a P2P tracker AS that supports the present invention. The Central Control Function 58 is the major session control unit. It handles messages from Tx/Rx module 60. Peer status update messages are sent to Integrated Peer Information Database 50, new P2P service request will be forwarded to Peer Service Responding Function 57, and the rest P2P session control tasks will be handled by the Central Control Function 58.

Peer Service Respond Function consists of two units: Peer List Generator 55 and MST Generator 56. MST is an information table recording offloading related parameters of the selected peers. A detailed explanation of example MST is introduced shown in Figure 3.

Peer List Generator 55 generates a basic peer list that deemed suitable for a mobile terminal requesting for a P2P Service, for example by choosing peers downloading the same content as the content requested by the mobile terminal. This peer list may be filtered by additional criteria that are required by the proper operation of the P2P service, for example, to remove the terminals that deemed not suitable due to operator's policy, subscription, battery status, charging considerations, etc.

The MST Generator 56, is in charge of selecting a group of peers with offloading capacity from the basic peer list. This group of peers could be a sub set of the basic peer list. Selection criteria for the peers to form the MST can be set by service providers, for example, only include those peers who just started downloading, or only include those peers with a WiFi capability, or is running a certain version of the application.

The size of MST varies according to operational factors. If there are millions of peers sharing the same content, server will break them into different groups (e.g. based on location) and each group forms a MST. If server feels there are too many unnecessary status update from peers, it will increase the size of MST, that means put more peers into one MST. Through this way, peers in a group needs more time to consolidate their status and there are fewer groups to send update messages.

MST Generator 56 will also designate a Representative Peer in the list. The Representative Peer is responsible to send consolidated MST back to the Tracker AS according to defined rules in MST. For example, if the Tracker AS set a rule that maximum update interval is 10-minute, the Representative Peer needs to update the Tracker AS after every 10min. The Tracker AS should select those peers with less workload and more computational power to be the Representative Peer, and avoid those peer nearly finish downloading. Representative Peer may be indicated in MST explicitly, e.g. by the IP address, FQDN, IMSI, NAI, etc. It may also be only a logic entity. This means Representative Peer is not a fixed mobile terminal. In this case, the Tracker AS does not need to assign update task to a specific peer. The peers select and decide among themselves the mobile terminal that should act as the Representative Peer, according to their status and information provided in the MST. For example, the peer receiving the MST first can become the representative peer by default. Later, peers can decide among themselves who will send the update. When any peer having a change in offloading status should update MST to server after triggered the MST update among the peers. In this case, the status changed peer is the Representative Peer.

Figure 2 illustrates an example architecture of a mobile terminal that supports the present invention, consisting of a Tx/Rx Function 85 that transmits and receives messages, a Central Control Function 80 that processes session related requests and performs adjustments, a MST Processor 75 which interprets the incoming MST and updates it with suitable information, an Offloading Peer Match Function 78 that matches peers who can offload to the same local network with the terminal, and a Device Information Database 70 that records configurations and instant status of the device and other peers sharing the same content. Device Information Database is further consists of MST base 71 which stored the latest MST; and Other Information Base 72 where session and terminal related information is stored.

In this system, Tx/Rx Function 85 receives messages from network and passes it to Central Control Function 80. If the message is just for information update, Central Control Function updates it to Other Information Base 72. All MST related messages are sent to MST Processor 75 for interpretation. Basically there are two types of updating messages for MST, server-initiated, and peer-initiated. The server-initiated message means that the received MST is a new version and is recently distributed from server for its FIRST iteration among peers. This type of MST usually carries new joined peer information and cleans up peers that have left the session. For a specific mobile terminal, this MST may be received from another peer. It is still considered as server-initiated as only as the peers in the MST are different. Peer-initiated message is an update of the previously iterated MST. It only carries updates of existing peers. This message is sent when a peer changes its mobility status.

MST Processor 75 retrieved stored MST in MST Base 71, comparing it with received message. According to their timestamps, MST Processor 75 decides whether to update the stored MST or not. Updated MST is passed to Offloading Peer Match Function 78 for decision. Offloading Peer Match Function compares the offloading status of current mobile terminal with the status of other peers. If there is a peer who is offloading to the same local network but still does not have connection with current terminal, it will mark it as a matched peer that needs to contact. If there is a peer who can offload to the same local network but still not offloading, it will mark it as potential offloading peer needs trigger to offload.

Decisions of peer matching are forwarded to Central Control Function 80 to take indicated actions. If no action required, it will further forward the update message to the next peer in MST. There is an exceptional case that if MST is failed to send to the next peer, for example next peer in MST is suddenly out of coverage; then the current terminal should skip this peer and choose the next. However if next non-responsive peer is also the last peer in MST, current terminal should stop sending the update message.

Figure 3, is an example of Mobility Status Table (MST). Peers in the same table are sharing the same content. One peer can appear in multiple MSTs if it is sharing multiple contents with different peers. In this table, first row contains identities of source peers (81, 82, 83). First column contains identities of destination peers (85, 86, 87). The content data flow from source peer to destination peer. In a usual form, the MST will have the source peers and destination peers in the same order, i.e. Peer-1 81 and Peer-1 85 are pointing to the same mobile terminal. With this layout, the diagonal entries contain the offloading status and capability information of the mobile terminals. For example 90, 96, 98, these are the diagonal entries corresponding to peer-1, peer-2, peer-3, respectively. These entries contain the peer device capacity and configuration. In particular, sector 90 contains the allowed CSG that may be used for offloading and current tracking area of Peer-1, and also all possible APN(s) Peer-1 can access.

The off-diagonal entries in the MST describe instant status of P2P connection from source peer to destination peer. For example entry 95 describes the connection status from Peer-1 to Peer-2. Information includes APN used by the connection, IP address pairs involved, approximate finish time, etc. If this is a bidirectional connection, the correlated information, which is the connection status from Peer-2 to Peer-1, will be shown in another sector 91. If there is no connection between two peers, NULL information is filled in the sector (e.g. 92).

In this example table, Representative Peer is designated specifically to be Peer-3, as in the last row of first column 99. Update rule is also written in last row of second column 100 as a periodic pattern. However, as mentioned earlier, the Representative Peer may not be explicit carried in MST. It can be the first peer receiving MST from server, e.g. Peer-1, or the last peer in MST, e.g. Peer-3. If Tracker AS trusts peers, it may just open a port listening to update and rely on peers to choose their representatives. Likewise, the update rules are also an optional. It is included in the only when the Tracker AS needs to explicitly control updating pattern, e.g. reporting at a frequency different from default settings, or setting a special event that should trigger the reporting to the Tracker AS, etc.

Peers in the MST are selected by the Tracker AS, but the Tracker AS does not need to understand the details in MST. The Tracker AS just form it according to the knowledge of who has offloading capacity, who is currently downloading the same content, who are mobile terminals, etc. Essentially, the initial MST sent out from the Tracker AS may have all the entries, e.g. 90 to 98, empty. Peers will fill in the MST entries and exchange it among themselves. Decision making based on MST is carried out at terminal side. The Tracker AS just receives updated MSTs and stores them into the Integrated Information Database. Later when a newly joined terminal requests for peer list, the Tracker AS respond with an MST built based on the information stored in the Integrated Information Database with related peers inside.

Figure 4, is the flowchart of an example logic the Tracker AS uses when a mobile terminal joins the P2P service. Since status update and offloading matching tasks are carried at terminal side in the present invention, the Tracker AS only performs minimum processing. When the Tracker AS receives a P2P service request at step 150, it generates a basic peer list in 154 by selecting those peers who can serve the request. Then the Tracker AS selects a group of peers which have offloading capacity and sharing the same content as requested (157). Mobility information of these peers is filtered from Integrated-MST to form a MST. This MST is attached to the basic peer list (158). The basic peer list and MST with selected peers are sent back to the mobile terminal that has requested for P2P service in step 162.

Figure 5, is the flowchart of the example logic used by a mobile terminal device when it joins P2P service. In step 170, the mobile terminal requests for P2P service with its offloading capacity. If it is capable of offloading, it will receive a peer list with MST; otherwise only basic peer list is provided by the Tracker AS. Upon receive the peer list (may be with MST), mobile terminal device performs the following actions based on offloading capacity (172). If not capable of offloading, mobile terminal follows normal procedure to contact peers in peer list (188). However, if it is capable of offloading, the mobile terminal will use MST to match peers offloading status with its own and select a suitable set of peers to contact (176). For selected peers, terminal contacts each of them to verify its offloading status and requests bitmap after connection established in step 177. If target peer is capable of offloading but have not yet established the offloading path, mobile terminal device may trigger the peer to start offloading by indicating the required information in the bitmap request, e.g. indication the APN or CSG.

As long as downloading started, the new joined terminal becomes a peer. Then this new peer should fill status of all its connections with other peers to MST in step 180 and forward the updated MST to the next peer in step 184. The mobile terminal can decide how to choose the next peer in forwarding the MST. It is obvious to anyone skill in the art that this does not affect the general principle of the invention. For example, next peer can be chosen according to the sequence of their position in MST. Alternatively, if the mobile terminal devices are powerful enough to calculate an optimal path traverse the peers, it can also decide to forward the MST following the optimal path.

Figure 6, is the flowchart of an example logic that can be used by the mobile terminals acting as peers during a P2P session. Peers' behavior varies depending on the offloading capacity. In the flowchart, step 250 is to differentiate the capability of the mobile terminal, and thus decide on the following actions. If the peer (mobile terminal) is not capable of offloading, the peer performs normal functions for P2P service (i.e. 295). If the peer is capable of offloading, it starts two parallel functions. The first one is a function that monitors its own mobility changes 252, and the other is a function that listens to update messages from other peers 256. Any stabilized status changes 254 or incoming update message will trigger peer to update the MST in 258. If current peer is not the last one in MST (270), it should send a copy of updated MST to the next peer in MST in step 278, otherwise it should decide whether to update server (274) if it is the representative peer.

After handling MST update, the peer (mobile terminal) can use the new MST to do peer re-selection. That is, match its offloading status with peers whose status has recently changed (280). If such peer re-selection procedure succeeded (281) and a proper peer is found to setup an offloading connection, peer will try to establish offloading connection with new selected peer in step 284. Upon establishment of the connection, the peer may trigger a round of MST update with its new connection status (286).

Figure 7 describes the message flow when new terminal joins the P2P service. Device1 350 is the mobile terminal that requests for P2P service. Device2 351 and Device3 352 are peers already in P2P session, sharing the same content as Device1 requested. Device2 can offload to the same local network as Device1 but Device3 cannot. Server 353 is the Tracker AS acting as the portal entity that a terminal contacts when request for P2P service.

At Step 355, Device1 requests for some contents through P2P system. In the request, Device1 inserts its offloading capacity for server's reference. The offloading capacity means whether Device1 is able to offload if local network is available and what type of access point it is capable to offload to. For example Device1 may support LIPA through home eNodeB and L-GW, and it may also support WiFi or WiMax. In this case, the Device1 may indicate in the capacity information three different entries, each contains information for one particular technology. An example format of the capacity information element could be like following

The capacity information is carried as an extended field in the service request message like SIP INVITE or REFER. This information is required for the embodiment that MST is generated by server. For fully distributed peer selection with offloading, peers offload capacity need not inform server.

After receiving the P2P service request, the Tracker AS generates a basic peer list according to the information provided by Device1 in Step 356. For example, this peer list includes all the mobile terminals that have been registered with the Tracker AS that is downloading the requested contents and matches some other pre-selection criteria, e.g. expected to be in the session at least more than 5 minutes, etc. If Device1 is capable of offloading, the Tracker AS also attaches an MST with the basic peer list in

steps

362 and 365. Within the MST, those peers who share the same contents as Device1 and also are capable of offloading are included. A typical example of the MST is as shown in Figure 3.

The basic peer list and MST are sent to Device1 in a response message like SIP INFO or 200OK. Upon receiving the response from server, Device1 analyzes the MST and predicts the offload probability of peers. Device1 will refer to MST to locate those peers that may offload to the same local network for bitmap fetching (370). When checking the MST, the Device1 only needs to review the peers that have the same offloading capabilities. For example, if the Device1 supports LIPA, it would only need to check the peers that also indicated LIPA capacities in the MST. And, the Device1 can check the CSG IDs, the L-GW addresses, the Local H(e)NB Network ID, the APNs, etc, and verifies that the offloading peer could be connected to the same network. By checking this, the Device1 can further down select the peers for establishing the session. It is obvious to anyone skilled in the art that the Device1 may also use some other local or access technologies specific policy or criteria to help selecting the peers. For example, if the offloading technology is WLAN, the Device1 may prefer a peer that is connected to the same local network but not the same Access Point, because the media is shared. And, if there are multiple peers, the Device1 may make use of some operation defined policies, for example the ANDSF ISRP or the Operator Policies for IP Interface Selection (OPIIS) rules to decide which access is preferred, e.g. WiFi non-seamless offload is preferred over LIPA.

This step is called "predict" because usually server does not have instant status of all peers. Therefore the MST provided by server may have some time lag, and Device1 use MST to predict possible offloading peers and can contact them for status verification before confirming the peer.

In an alternative solution, the Device1 may trigger a round of MST update first before making decision. It makes decision more reliable but may introduce longer delay before starting a P2P session. In step 375, Device1 follows standard procedures to set up connection with selected peer and start downloading the content.

Steps in 380 are for MST update. Since Device1 is the new joined peer, there will be a new column and new row added in MST. Device1 needs to inform others of its existence, not only those peers having connection with it. So it sends update message in Step 384 using SIP message like REFER or INFO, including the new MST with its own offloading capacity information. Compared to the old version stored in local database of peers, this new version of MST does not include those irresponsive peers and peers that have left the session. The Tracker AS may also re-organize the peer groups.

Peers receiving the message will update their local stored MST, as in

step

386 and 390. Using the updated MST, peers are able to judge whether the information change enables a potential offloading path to/from another peer via the same local network. If so, it may perform peer re-selection and set up a new connection with the offloading enabled peer. In the embodiment, MST is updated in sequence (as in step 384 and 388). However, the update route could be optimized, e.g. using graph theory, such that the forwarding path could be shortened.

In step 395, the representative peer, Device3, sends the completed MST, which has been updated by all the other peers, to the Tracker AS, e.g. using a SIP INFO message. It sends MST immediately instead of checking MST update rules because this MST contains information of a newly joined mobile terminal. The Tracker AS uses the updated MST to create a new mobile terminal connection status (398) entry in its aggregated MST for future P2P request. With this update to the aggregated MST at the Tracker AS, the newly joined terminal becomes a stable peer in the P2P system. Following peer status update will follow the procedure described in Figure 8.

Figure 8 illustrates an example message flow for peer triggered update and peer re-selection in the present invention. In step 460, Device1 mobility status changes. For example it moves from outside into a house where WLAN is available. It then updates local stored MST with information of indoor WLAN in step 462 and trigger MST update iteration by sending MST update information to the next peer (Device2) in the MST in step 470. The message is carried by SIP messages like INFO or OPTIONS.

After receiving the message, Device2 updates its locally stored MST in step 472. As there is no peer added or removed from the MST, Device2 knows that this is just a peer status update. It then checks whether the status change makes Device1 a possible peer to use an offload path. If they can offload to the same network, Device2 will re-INVITE Device1 to establish an offloading connection between them for the P2P session.

The procedure of "update and check" is carried on until reaching the last peer (Device3) in the MST. In Figure 8, Device3 is the representative peer for this group. Thus it should decide whether to send a copy of the updated MST to server in step 485. The decision is made based on update rules specified in MST, or by some principles consented in this group. For example, representative peer should update the MST to the Tracker AS if more than 10 updates happened within 2 minutes. If MST is sent (490), the Tracker AS should update its aggregated information database accordingly.

The above presented embodiment requires partial participation of the Tracker AS. That is, server selects a set of peers to generate MST while terminals using MST to perform peer selection. In another alternative operation, the operation could be purely terminal based without any server participation. In this alternative operation, the MST is generated and maintained within peers sharing the same content.

The Tracker AS provides the basic peer list to the terminals as in the current art when the mobile terminal request for P2P service. Among the peers in the P2P session, a MST is generated and maintained. When a new mobile terminal joins the P2P service, it first chooses peers based on basic peer list from the Tracker AS. When the mobile terminal contacts the selected peer for bitmap, it may include its offloading capacity information in the request. The selected peer seeing the offloading capacity information will attach a copy of MST in the response message. Mobile terminal device can now use MST to improve peer selection, e.g. by selecting another peer that has offloading capabilities. At the same time, the mobile terminal can trigger an MST update by exchanging status information with all the peers listed in the MST.

In this operation, all peers in the group need to have a copy of the MST. Any pre-defined event, e.g. change of offloading status, new peer joining, or peer leaving, will trigger update of MST within the group of peers. Server needs to know nothing of offloading and MST.

There is yet another operation alternative where the MST is split into pieces and distributes among peers. Each peer is in charge of a certain segment of MST and there is index to locate these segments. This can be realized using mechanisms like CHORD and Distributed Hash Table. For example there are a group of 30 peers exchanging the same content. Within them, three powerful peers are selected to store the MST. Peer1 has the first part of the MST with initially joined 10 peers; Peer2 has the second part of the MST with later joined 10 peers, and Peer3 has the third part of the MST with most recently joined 10 peers. There is an index table in all 30 peers indicating that the first set of peer (10 peers) status is stored in Peer1, second set of peer status is stored in Peer2, and so on. If a peer belong to the first set changes its status, it will search the index table and only updates Peer1. If Peer3 needs the status of peers belong to the first set, it will request from Peer1 for the first part of MST. Through this way, memory usage is reduced because each peer only needs to store a small part of the MST, and messages exchanges are reduced since updates only need to be conducted to the specific peer who holds the part of MST. The terminals only need to spare some extra searching time to locate the target segment for each update message.

In another alternative operation, the Tracker AS can also assist in peer re-selection. In this operation, the Tracker AS needs to understand all the offloading techniques and the detail structure of MST. Mobile terminals will not make any decision but simply consolidate their mobility status in MST and submit it to the Tracker AS, on a scheduled time or periodically, using for example SIP INFO messages. The Tracker AS pairs peers who can offload to the same network. If pairing succeeded, it instructs the peer pair to set up offloading connection using messages like SIP OPTIONS. Peers will follow the Tracker AS's instruction to switch on-going P2P flow to offloading connection if the peer pair already has a connection between them, or to establish an offload connection for bitmap fetching if they don't have existing connection. The matching procedure is repeated at Tracker AS every time a MST update is received.

In the above description of the operations, Session Initiation Protocol (SIP) messages are used as example of signaling illustration. It is obvious to anyone skilled in the art that the signaling between peers and the Tracker AS can use other signaling protocols without affecting the general principle of the invention, as long as the necessary information of the MST and the offloading capacity information are carried properly.

Each functional block used in the description of the embodiments as given above can be realized as LSI, typically represented by the integrated circuit. These may be produced as one chip individually or may be designed as one chip to include a part or all. Here, it is referred as LSI, while it may be called IC, system LSI, super LSI, or ultra LSI, depending on the degree of integration. Also, the technique of integrated circuit is not limited only to LSI and it may be realized as a dedicated circuit or a general-purpose processor. FPGA (Field Programmable Gate Array), which can be programmed after the manufacture of LSI, or a reconfigurable processor, in which connection or setting of circuit cell inside LSI can be reconfigured, may be used. Further, with the progress of semiconductor technique or other techniques derived from it, when the technique of circuit integration to replace LSI may emerge, the functional blocks may be integrated by using such technique. For example, the adaptation of bio-technology is one of such possibilities.

Claims

A method to facilitate peer selection through terminal consolidated information in a peer-to-peer session, comprising:
an initiating step that a tracker server sends an Mobility Status Table with a selected set of offloading capable peers;
an exchanging step that the selected peers in the Mobility Status Table exchange the Mobility Status Table to consolidate their instantaneous offloading status
an optimization step that the peers optimize peer selection during P2P session based on Mobility Status Table.
The method according to claim 1, the set of peers in a Mobility Status Table is sharing the same content.
The method according to claim 1, server manages size and distributing frequency of the Mobility Status Table during a P2P session.
The method according to claim 1, Mobility Status Table is updated to tracker server based on pre-set rules.
The method according to claim 4, Mobility Status Table updating rules is set before Mobility Status Table is exchanged among peers.
The method according to claim 4, Mobility Status Table updating rules can be changed during the session.
The method according to claim 1, peers fill in its status and status of connections with other peers in the Mobility Status Table.
The method according to claim 7, peer status includes peer's offloading status and configurations, potential access type.
The method according to claim 7, connection status with other peers includes IP address, access type, offloading point, approximate transmission finish time.
The method according to claim 1, peers in the table keep a copy of the completed Mobility Status Table for future Peer Re-selection until P2P session terminates.
The method according to claim 10, peers use completed Mobility Status Table to predict possibility of offloading to the same local network as other peers.
The method according to claim 10, the local copy of Mobility Status Table is over-written when new Mobility Status Table comes from the tracker server.
A system for managing paths in the peer to peer data communication comprising:
a plurality of mobile terminals, wherein, each of the mobile terminal is capable of receiving data from one or more of the other mobile terminals; and
a Server that is capable of grouping one or more of the mobile terminals into a Peer Set for a peer to peer data communication;
whereby, in use,
the Server initiates a Mobility Status Table based on the Peer Set and distributes the Mobility Status Table to a mobile terminal in the Peer Set;
the mobile terminals in the Peer Set update and share the Mobility Status Table according to their local information; and
the mobile terminals in the Peer Set select one or more mobile terminal to start the peer to peer data communication according to the Mobility Status Table.
A system for managing paths in the peer to peer data communication of claim 13, wherein the Server receives and stores a copy of the Mobility Status Table from one of the mobile terminal in the Peer Set, and construct a new Mobility Status Table based on the Mobility Status Table when the Server decides that the Peer Set changes.
A system for managing paths in the peer to peer data communication of claim 13, wherein the Mobility Status Table includes information of the mobile terminals in the Peer Set on the existing connections and potential connections that can be established for the peer to peer data communication.
A system for managing paths in the peer to peer data communication of claim 13, wherein a mobile terminal in the Peer Set is capable of updating other mobile terminals when the Mobility Status Table is modified due to a local connection status change.
A system for managing paths in the peer to peer data communication of claim 16, wherein the mobile terminals is capable of deciding a sub set of the mobile terminals in the Peer Set to be updated based on the modification to the Mobility Status Table.
A system for managing paths in the peer to peer data communication of claim 16, wherein the mobile terminals in the Peer Set are capable of deciding when to update the Server of the modified Mobility Status Table based on embedded rules.
A system for managing paths in the peer to peer data communication of claim 16, wherein the Server is capable of configuring a mobile terminal in the Peer Set to report when the Mobility Status Table is changed.
A system for managing paths in the peer to peer data communication of claim 13, wherein the Server is capable of indicating in the Mobility Status Table a preferred set of mobile terminals.
A system for managing paths in the peer to peer data communication of any of the claim 16, wherein the mobile terminals are capable of adjusting the connection and member of the peer to peer data communication based on an updated Mobility Status Table.
A terminal device configured to exchange and update offloading status information in the Mobility Status Table and perform optimal peer selection based on it, comprising:
a central control section that controls the P2P session, exchanges Mobility Status Table with peers, submits Mobility Status Table to server based on processing result from Mobility Status Table processor;
a Mobility Status Table processor section that process incoming Mobility Status Table and device information to update the local copy of Mobility Status Table;
a device information database that stores a local copy of Mobility Status Table and other device and P2P session related information; and
an offloading peer match function that matches offloading configurations of the terminal device to peers in Mobility Status Table.
The terminal device according to claim 22, offloading peer match function suggests central control section to trigger target peer for offloading if matches found.
A tracker server configured to provide peer list with a Mobility Status Table containing selected set of peers, comprising:
a peer list generating section that provide a basic peer list for requested content;
a Mobility Status Table generating section that selects a set of peers to form a Mobility Status Table based on offloading capacity information stored in the server;
an integrated peer information database stores previous updated Mobility Status Table from peers and other information related to all P2P sessions; and
a central control section that controls peer list generation, Mobility Status Table generation, integrated peer information database, and P2P sessions.