KR20140054382A - System and method for mobility and multi-homing content retrieval applications - Google Patents

Abstract

The controller function under the client application in the TCP / IP stack or session layer monitors status and status information associated with session-based application layer functions (e.g., content retrieval) and sends one or more sessions from the first client interface (E.g., 3G, 4G, LTE, 802.11x, WiMAX) and to different application function serving entities (e.g., different content servers, cache servers, service providers).

Description

[0001] SYSTEM AND METHOD FOR MOBILITY AND MULTI-HOMING CONTENT RETRIEVAL APPLICATIONS [0002]

The present invention relates generally to multi-homing or mobile hosts, and more specifically but not exclusively, that content search is seamlessly performed when the hosts transition between communication networks, Lt; / RTI >

A mobile or multi-homing host may use its own Layer 3 network access point (Layer 3) while a content search session is running, for example while the client is retrieving data from a remote server. network access point (i.e., IP address). Such an interface change may be desirable because the " new " interface is better than the " old " interface and the network congestion is lower. The interface will also have to change as the user moves from one network coverage area to another.

For a client's new interface, data transfer may be more appropriate for a server than another server to send data to the host's old interface. This may be because the new server is closer to the client's new interface. It is also possible that a network connecting to one of the interfaces has an application layer proxy, while a network supporting another interface may not have such a proxy or have a different proxy. Although such proxy information may be preconfigured on a mobile / multi-homing host, the remote address used for content retrieval must be changed when the interface changes.

For at least the above reasons, it is desirable to provide the ability to change the server delivering content along with the interface used for content retrieval by the client.

Content retrieval applications typically use stream-oriented transport protocols such as TCP, SCTP, or MPTCP to ensure that the client connects to the content server and delivers the content reliably and legitimately. When TCP is used as the underlying transport protocol, the transport connection can not be moved to a different interface without interfering with alternate client-server sessions. When SCTP is used, the client can move traffic from the old interface to the new interface. However, it is not possible to change the server at the same time, because the SCTP control block on the old server holds connection-specific information that is not shared with the new server. The same problem occurs when MPTCP is used for connection. Moreover, SCTP and MPTCP are not generally supported on the Internet.

There are several mobility / multi-homing protocols that accept the functionality of session endpoint mobility on Layer 3 and thus are transparent to the transport and application layer. Mobile IP protocol families, SHIM6 and LTE are examples. Some of these solutions require additional network nodes such as home agents or specialized gateways (MIPv4, MIPv6, DSMIP, PMIP, LTE). Unfortunately, none of these solutions allow the content server to change during ongoing data retrieval.

Content-centric networks (e.g., "Networking Named Content" such as Jacobson et al., CoNEXT'09, Emerging Networking Experiments and Technologies ), Which is the fifth International Conference of the United Nations. However, these proposals do not match current IP-layer and transport-layer protocols. For the same reason, they do not match existing network infrastructure or the Internet.

There are application-layer solutions where connection point changes and server changes are built into the client application itself. Such applications may intercept the data transfer in the middle, terminate the corresponding transfer connection, reset the new transfer connection and request the remaining data from the same or new server. These solutions can be tailored to specific application layer protocols as well as data types of content, but they need to be implemented separately by all client applications. This is very cumbersome and, by its nature, does not support legacy or legacy applications.

Unfortunately, even though there are several content retrieval techniques for changing the server used to deliver content and / or the interface used by the client for content retrieval, none of these techniques are compatible with existing or emerging transport protocols But it is not possible to support existing client applications.

An object of the present invention is to solve the above-mentioned problems.

Embodiments in which substantially contiguous content retrieved by a multi-homing or mobile host may change its own interface during content retrieval as well as the content server used by the client session without interfering with the content retrieval session for the client The various drawbacks of the prior art are addressed.

In various embodiments, controller functionality is implemented within a TCP / IP stack or under a client application on a session layer. The controller function monitors the various commands used by the application layer protocol to maintain state and status information associated with application layer functions (e.g., content retrieval), so that the application layer functions can communicate with different client interfaces (E.g., 3G, 4G, LTE 802.11x, WiMAX) and / or to different application function serving entities (e.g., different content servers, cache servers, service providers).

In one embodiment, an apparatus for moving a content retrieval session associated with a content retrieval application at a host from a first server through a first interface to a second server via a second interface includes a processor, 2 interface to establish a transport connection with the second server; Sending a content request message to a second server via a second interface, the content request message including an identifier associated with the content being searched and an indication of the content portions received by the content search application; Analyzing a content bearing data stream received via a second interface to identify additional content portions received by the content search application; To the content search application, to transmit identified content portions that have not been received by the content search application.

In another embodiment, a method of moving a content retrieval session associated with a content retrieval application at a host from a first server through a first interface to a second server via a second interface includes: Establishing a transmission connection with the terminal; Transmitting a content request message to a second server via a second interface, the content request message including an identifier associated with the content being searched and an indication of content portions received by the content search application; Analyzing a content-containing data stream received via a second interface to identify additional content portions received by the content search application; And sending, to the content retrieval application, the identified content portions that have not been received by the content retrieval application.

In various embodiments, the controller function under the client application in the TCP / IP stack or session layer may monitor status and status information associated with session-based application layer functions (e.g., content retrieval) (E.g., a different content server, a cache server, a service provider) with a second client interface (e.g., 3G, 4G, LTE, 802.11x, WiMAX) .

The contents herein can be more readily understood by considering the following detailed description together with the accompanying drawings.
1 is a high-level block diagram of a communication system including a host device in accordance with one embodiment.
Figures 2 to 3 are high-level block diagrams of host devices suitable for use in the communication system of Figure 1.
4 is a protocol diagram illustrating a methodology in accordance with one embodiment.
5 is a flow chart illustrating a methodology in accordance with one embodiment.
Figure 6 is a high-level block diagram of a computer suitable for use in performing the functions described herein.
To facilitate understanding, like reference numerals have been used, where possible, to designate identical elements that are common to the figures.

While the overall capability to change a server that delivers content along with an interface used by a multi-homing or mobile host to a client to a content retrieval application in a transparent manner is shown and described herein, / Capabilities that are related or unrelated can also be initiated.

Various embodiments may be used to modify content with an interface used by a client for content retrieval while maintaining compliance with existing and evolving transport protocols, .

Various embodiments are applicable to mobile and / or multi-homing hosts that utilize applications for content retrieval from servers residing on the network. Examples of such content search sessions include downloads from web servers, such as those performed during web browsing sessions, web based video streaming sessions, HTTP based file transfer sessions and other non-state based content search sessions . Embodiments are able to transparently change the network interfaces as well as the content delivery server while the host continues to deliver data to the client application, i. E. Without interrupting or restarting the application.

Embodiments provide a secure, idempotent method invocation used by a client application that supports an offset feature and is illustratively described with respect to the beginning of the content Instructs the remote server to start delivering content at a specific offset.

In one embodiment, the content retrieval is based on the Hypertext Transfer Protocol (HTTP) protocol, and the client uses the GET method to invoke the content retrieval session. The HTTP protocol supports such an offset feature. In the case of HTTP, the RANGE command, which should be inserted in the HTTP request header with the octets of the amount of already received content, can be used.

1 illustrates a high-level block diagram of a communication system including a host device in accordance with one embodiment. 1 illustrates a system 100 that enables a multi-homing or mobile host 110 to communicate with multiple networks 120 and retrieve content from each of the content sources 140 from the networks. Lt; / RTI >

According to various embodiments discussed herein, the host 110 may retrieve content from a server associated with the first network without restarting the content distribution or otherwise interfering with the host content retrieval application To a session for retrieving content from a server associated with a second network.

Host 110 illustratively includes a first interface 112-1 that interfaces with a first network 120-1, a second interface 112-2 that interfaces with a second network 120-2, A client 114, a client 116, and an interface manager 118.

The client 116 is shown as including a content retrieval application (CRA), which establishes sessions with remote entities, such as content servers, (Not shown) and / or presentation circuitry (not shown) associated with the host 110, and to send the received content to the host 110 And signaling.

The controller 114 is locally located between the client 116 and the interfaces 112. In various embodiments, the controller 114 monitors some or all of the data traffic and / or control signals propagated between the client 116 and the interfaces 112. The controller 114 responds to the interface manager 118 to adapt the use of the interfaces 112 by the client 116. In general, the operation of the controller 114 may not be visible to the client 116. In various embodiments, the interface manager 118 may allow the controller 114 to communicate only through the first interface 112-1 or only through the second interface 112-2, To generate control signals and / or data traffic flowing through the combiner (112).

The interface manager 118 causes the controller 114 to select which of the interfaces 112 is to be used to support data traffic and / or control signals between the client 116 and the interfaces 112 . Interface manager 118 is shown communicating with controller 114 via an interface control (IC) signal path.

In some embodiments, the IC signal path is unidirectional in that it represents which interface of the interfaces 112 available to the interface manager is to be selected by the controller 114 for use by the client 116. In some embodiments, to be.

In some embodiments, the IC signal path may be used by the interface manager 118 and controller 114 to understand client requirements, interface requirements, conditions of the interface 112, conditions of the communication networks 120, and the like. It is bidirectional in that they communicate with each other to transmit information. Similarly, the interface manager 118 may include conditional trigger conditions that cause the controller 114 to select a new interface 112 or to perform some other function when sensed as being generated by the controller 114 Communication can be performed.

In various embodiments, conditions associated with the selection of a particular interface 112 are communicated to the interface manager 118 via the controller 114. In various embodiments, such conditions may be provided by a network management system (NMS), service provider, or some other entity operatively connected to the host via one or more of the interfaces 112 / RTI > For example, congestion information associated with each of the networks 120 may be communicated to the controller 114 and / or the interface manager 118 via respective interfaces 112.

Other circumstances include preferences associated with network providers, hot spot identification information identifying " free " hot spots associated with a particular mobile network provider, and the like. For example, if the host 110 is able to access 3G and 802.11 by each interface 112, some hot spots may be free to use or costly, depending on service level agreements, provider mutual agreements, etc. Less can be heard.

Thus, in various embodiments, the control signal propagated by the interface manager 118 to the controller 114 may include a congestion level indicator received via the first interface, a congestion level indicator received via the second interface, A determination that a preferred service is associated with a second interface, a determination that a reduced cost is associated with a second interface, a determination that a performance increase is associated with the second interface , A determination that the preferred network is associated with the second interface, and the like.

In various embodiments, the interface selection conditions may include any of the interfaces 112, such as for retrieving content within the context of a content search session initiated and / or managed by a content retrieval application (CRA) May be used by controller 114 and / or interface manager 118 to make a determination as to whether an interface is to be used by client 116.

It will be appreciated that although two interfaces 112 are shown herein, more than two interfaces 112 may also be used within the context of various embodiments. Each of the interfaces 112 is capable of communicating with the corresponding network 120.

Each of the networks 120 includes one or more access networks, a core network, or the like, sufficient to enable communication between the host 110 and the content source 140. Although each of the networks 120 is shown as being associated with a respective domain name server (DNS) 130, additional domain name servers may be used in the context of any one network 120.

Each of the content sources 140 establishes a session with an interface 142 and generally a client 116 that communicates with each network 120 and interacts with the client 116 and provides the client 116 with content And a content server 144 adapted to provide content to the user. The content server 140 may include any type of content distribution system or content server capable of session-based content distribution and / or streaming.

In one embodiment, the host may be a smart phone or other mobile device configured to communicate with wireless " hot spots " by the second interface 112-2 and wireless mobile networks via the first interface 112-1 .

Specifically, in this embodiment, the first interface 112-1 includes hardware and software necessary to communicate with the first communication network 120-1 (e.g., 3G, 4G, LTE, or other wireless mobile / The second interface 112-2 may be configured to include a second communication network 120-2 (e.g., a wireless " hotspot " type network such as 802.11x, WiMAX, wireless gigabit (E. G., Other similar or fixed wireless networks). ≪ / RTI >

The various functions associated with the host 110, the networks 120, the domain name servers 130 and the content sources 140 will generally be implemented within the context of the host 110, It will be appreciated that the present invention includes computer-based functions implemented in software or a combination of hardware and software. Thus, the host 110 includes general computing elements such as one or more processors, memory elements, input-output circuits, etc., and these elements are omitted in FIG. 1 to enhance clarity. An embodiment of a computing device that provides such elements is described in more detail with respect to FIG.

The various embodiments described herein enable a mobile / multihoming host to change its own interface as well as the content server used by the client session during content retrieval without interfering with the content retrieval session for the client.

In various embodiments, the controller 114 includes software functionality implemented within the software layer underlying the software layer that supports the client. Specifically, the controller function resides in the client application under the TCP / IP stack or on the session layer. The controller function may monitor at least a portion of the traffic through its layer and may recognize or understand at least some of the commands used by the application layer protocol.

Generally speaking, the controller 114 performs four main tasks: (1) monitoring the traffic between the client 116 and the interface 112 to identify the content requested therefrom, Deriving an amount of content; (2) identify the server on the newly selected interface containing the requested content; (3) initiating a transfer connection to the identified server; (4) redirect the portion of the content that has not yet been received by the client to the client.

Specifically, when the interface of the client host is changed, the controller determines the most appropriate server to be used for this content on the new interface. A server providing content via the old interface is denoted as an " old " server, while a server selected to serve content through a new interface is denoted as a " new " It is pointed out that new servers and old servers may be identical to each other depending on the configuration of content provider equipment.

The controller function initiates a transfer connection to the new server and for example sends a copy of the original content retrieval request to the new server.

The controller function also sends, by way of example, the command provided by the application layer protocol to the new server, which instructs the new server to start delivering content according to the specified offset, . ≪ / RTI >

The controller then redirects the data delivered by the new server to the client application and terminates the connection to the old server.

These steps are generally transparent to the client application, thereby facilitating a seamless transition of the retrieved content stream from the first network interface to the second network interface.

Can be derived for the offset by (1) fully characterizing the amount of content received, (2) conforming to the application layer protocol, and therefore understood by the server, and (3) monitoring the received content stream Any expression can be used.

The offset may include a number representing the number of octets of content received, which may include a list of identifiers of the received data objects, wherein the objects are in a standardized format (e.g., XML, html, etc.) Lt; / RTI > The offset may represent other metrics such as the time interval associated with a received video stream or portions thereof, a frame count, a time interval associated with a program clock reference (PCR), and the like.

Figures 2-3 illustrate high level block diagrams of host devices suitable for use in the communication system of Figure 1; Specifically, FIGS. 2-3 illustrate hosts 110 operating in a manner similar to the host 110 described above with respect to FIG.

2, a session layer implementation is provided using a library function such that the functions of the controller 114 are implemented in a library of functions that are called or accessed via the client 116. Moreover, the kernel space may include a first TCP / IP stack 113-1 associated with the first interface 112-1 and a second TCP / IP stack 113-2 called or accessed by the controller 114 .

Advantageously, this implementation allows existing applications on existing multi-homing or mobile hosts to upgrade the library functions to include the functionality of controller 114 and interface manager 118 to support the functionality of the various embodiments described herein Provides a mechanism that can be upgraded. Unfortunately, for those applications that bypass library functions by directly accessing kernel space functions, it may not be possible to implement some of the controller functions associated with various embodiments.

3, a transport layer implementation is provided by including controller 114 and interface manager 118 in kernel space and additionally integrating controller 114 with TCP / IP stacks 113.

Advantageously, this implementation is commonplace applications where existing applications on existing multi-homing or mobile hosts do not use libraries, and application programming interfaces (APIs) associated with library functions, etc. are described herein It provides a mechanism that will still work in accordance with various embodiments, since kernel space functions can not be easily bypassed by applications, such as user space functions such as library functions.

4 illustrates a protocol diagram illustrating a methodology in accordance with one embodiment. 4 illustrates method 400, where information at each of up to 411 (and optionally more) steps 401, 402, etc. is conveyed between the various functional elements described above with respect to FIG. 1, So that various embodiments can be described.

In step 401, the client 116 accesses the first interface 112-1 to retrieve the IP address for the first content server 140-1 from the domain name server (DNS) 130-1. (DNS) 130-1 that is associated with the first network 120-1 via the first network 120-1 (also denoted here as IF1). During this step, the controller 114 intercepts the DNS request and caches a uniform resource identifier (URI) associated with the DNS request. It will be appreciated by those skilled in the art that this process is not necessary in the context of an HTTP environment.

At step 402, the DNS server 130-1 propagates the DNS response back to the client 116. [ During this phase, the controller 114 intercepts the response from the DNS server 130-1 and caches the IP addresses with the URI of the request. It will be appreciated by those skilled in the art that this process is not necessary in the context of an HTTP environment.

In step 403, the client 116 initiates a transmission session via the first interface 112-1 using the IP addresses of the first content server 140-1 and transmits a content retrieval request. The controller 114 intercepts the setup request, identifies the URI of the content based on the remote IP address of the connection (not required for HTTP), caches the content request message sent by the client, Start monitoring.

In step 404, the first content server 140-1 sends a response packet to the client 116 that includes a response header, and potentially a first portion of the content data. The controller intercepts this packet and responds and begins tracking the content data that is sent to the client.

In step 405, the first content server 140-1 continues to send a stream of packets containing additional portions of the requested content data to the client. The controller intercepts these packets and continues to track portions of the content being sent to the client.

In step 406, the interface manager 118 sends a trigger to the controller 114, illustratively, in the IC signal path. The trigger indicates that the controller should switch from the first interface 112-1 to the second step 112-2. In response to this trigger, the controller 114 sends a copy of the cached DNS request (or other indicator of the URI associated with the initial content request) to the second network 120-2 via the second interface 112-2, .

Alternatively, the controller 116 generates its own DNS request that includes the URI that it retrieved from the client's initial content request message. Other modifications are also contemplated by the inventors.

In step 407, the second DNS server 130-2 receives the DNS request received in step 406 by providing a set of IP addresses for the servers in the second network 120-2 that can provide the desired content Reply. The controller 114 selects an IP address shown in this embodiment by referring to the second content server 140-2 in Fig. 4 from this set in one embodiment.

In step 408, the controller 114 terminates the transmission connection between the first interface 112-1 and the first content server 140-1 via the TCP RST, for example. Moreover, the controller 114 determines the total amount of content that the client has received over the original transport connection.

In step 409, the controller 114 establishes a new transport connection through the second interface 112-2 using the IP address associated with the second content server 140-2. In addition, the controller 114 sends a copy of the content retrieval request as well as the offset in a content retrieval request over this new transport connection, which is already retrieved via the old transport connection through the first interface 112-1 Lt; / RTI >

In step 410, the second content server 140-2 sends a response packet to the controller 114, which includes a response header, and possibly a first portion of the content data starting at the offset. The controller 114 removes the response header and sends any received post-offset data portions to the client 116. The controller 114 also continues to track the content data being transmitted to the client. It is noted that the corresponding response headers are removed by the controller 114 because they are not expected by the client at this time since the client is not aware of the operation of the controller 114 and in particular the content request made by the controller 114. [

At step 411, the second content server 140-2 continues to transmit to client 116 a stream of packets containing additional portions of the requested content data. Controller 114 continues to intercept these packets and keep track of the content portions that are transmitted to the client.

Figure 5 shows a flow diagram illustrating a methodology in accordance with one embodiment. The methodology discussed herein with respect to FIG. 5 generally considers HTTP to be used as an application layer protocol and to use the HTTP GET method to request content. As discussed elsewhere herein, various other protocols as well as protocols on various different software layers may be implemented.

Referring to steps 510 and 511, the controller monitors the fetching method calls associated with the application layer protocol it supports. To implement the controller on the transport layer using TCP or MPTCP, the controller analyzes the first outgoing data packet after a SYN / ACK handshake initiated by the client. In the case of SCTP, the first outgoing data packet after the INIT handshake should be analyzed. In the case of session layer implementations, the first data packet must be analyzed after a CONNECT () call.

Referring to steps 515 and 516, the controller identifies the URI or URL corresponding to the fetch method call. This URI or URL is cached with the IP address of the server used to retrieve the content. In one embodiment, this can be accomplished by caching the URI / URL of the DNS request with the IP addresses included in the DNS response and by monitoring the DNS request / response handshakes initiated by the host. Based on this cached data and the destination address of the fetch method call, the corresponding URI / URL of the method call can be found. In the case where HTTP is used as the application layer protocol, the URI / URL can be derived from the HTTP header contained in the GET call, and the proxy can represent the content server when the HTTP proxy is configured for the interface.

Referring to step 520 and box 521, the controller may optionally stop monitoring if mobile / multi-homing support is not required for the application client and is not allowed for some reason. Specifically, if a content search session has been identified through these steps, the controller can further determine whether this application layer session requires support for mobility / multi-homing. This determination may involve external criteria as well as other criteria such as multiple and any type of interfaces supported by the host. Within the context of the following controller functions, a content retrieval session is assumed to require such mobility / multi-homing support.

Referring to steps 525 and 526, the controller caches session connection identifiers or transmission connection identifiers. These identifiers are used by the controller to deliver content data portions that arrive at future connections that were directed to the client application and initiated by the controller. In the case of a controller function on the session layer, such an identifier may consist of a process ID and a socket descriptor used by the application. For controller functionality on the transparent layer, it may be a pointer to a corresponding protocol control block in the kernel.

Referring to step 530 and box 531, the controller caches the information contained in the method-invoke call sent by the client application to the content retrieval server. If HTTP is an application layer protocol, this information refers to the HTTP request header of the HTTP GET call.

Referring to step 535 and box 536, the controller monitors and analyzes all data sent by the content server in response to the client's method call. The controller determines the amount of content that has been received. In this process, the controller may have to ignore the signaling information provided by the application layer protocol, such as HTTP response headers.

In one embodiment, the content is specified in units of octets or bits. In another embodiment, the content is represented by a list of object identifiers. In another embodiment, the content is specified in terms of a plurality of frames or axis units to be received, such as for a video stream and / or an audio stream, and in another embodiment, (Such as those computed using fractions (code timestamps (DTS), presentation timestamps (PTS), program clock references (PCRs), etc.) And the time interval it takes to complete the process.

Referring to step 540, the controller waits for a control signal from the interface manager to indicate that the interface used for content retrieval is to be changed. Until such time as a control signal is received, the controller continues to monitor and analyze content portions received via the first interface 112-1 from the first content server 140-1.

Referring to steps 545 and 546, after receiving the interface change addictive control signal, the controller identifies the appropriate server for content delivery on the new interface. For this purpose, the controller may initiate a DNS request on a new interface that includes a URI that is mapped to an initial method call by the client application. If the DNS response does not include the IP address of the old content server, it may be desirable to use the new content server. If HTTP is used as the application layer protocol and the HTTP proxy is used on the old interface, it may be desirable to use the new content server for the new interface. When the new interface is configured with an HTTP proxy, the HTTP proxy itself can take the functionality of the content server to the client. Next, we refer to the "old server" and "new server" for each old and new interfaces. The old and new servers may be the same, different, and / or referred to as proxy servers.

Referring to step 550 and box 551, the controller terminates the old transfer connection to the old server. If the host only supports one interface at a time, this step is performed prior to identifying the appropriate server to deliver the content on the new interface. If a controller is implemented on the transport layer and TCP is used as the transport protocol, the controller can send RST commands to terminate the connection. To do this, the controller needs to know the transport connection identifier. If the controller is implemented on the session layer, the controller can terminate the connection via the CLOSE () call. To do this, the controller needs to know the socket descriptor and eventually the process identifier.

Referring to step 555, the controller establishes a new transport connection via a new interface with the new server. In embodiments where the transport layer has a controller function, it may be useful to use the same protocol control block. However, it must undergo a connection setup signaling handshake with the new server through the new interface. This ensures that additional content data delivered by the new content server can be transferred to the same client application. In embodiments where the controller is at the session layer, portions of the content data received from the new content server are forwarded to the same socket descriptor on the same application layer process.

Referring to step 560 and box 561, the controller sends the cached method call to the new server on the new transport connection. The controller inserts instructions that include an offset that causes the content server to skip delivering the already received amount of content data. This command is specific to the application layer protocol. In the case of HTTP, the RANGE command, which should be inserted in the HTTP request header, can be used with the positive octets of the already received content.

Referring to step 565, the controller sends all content received on the new connection to the client application. To this end, the controller uses the session connection or transport connection identifier that it has cached for this content retrieval session. On the new connection, the counting of the pieces of content data passing continues to allow additional connection movement events to be performed, and in various embodiments the operation at step 565 is similar to that described above with respect to step 535 and box 536. [

Figure 6 shows a high-level block diagram of a computer suitable for use in performing the functions described herein.

6, the computer 600 may include a processor element 602 (e.g., a central processing unit (CPU) and / or other suitable processor (s)), a memory 604 (E.g., random access memory (RAM), read only memory (ROM), etc.), cooperating modules / processes 605 and various input / output devices 606 (E.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, etc.), an input device, ).

It should be noted that the functions shown and described herein may be implemented in software and / or hardware, for example, using a general purpose computer, one or more application specific integrated circuits (ASICs), and / or any other hardware equivalent. In one embodiment, collaboration process 605 may be loaded into memory 604 and executed by processor 602 to implement the functions discussed herein. Thus, collaboration process 605 (including associated data structures) may be stored in a computer-readable storage medium, such as a RAM memory, magnetic or optical drive or diskette.

It will be appreciated that the computer 600 shown in FIG. 6 provides general purpose architectures and functions suitable for implementing the functional elements described herein and / or some of the functional elements described herein. For example, computer 600 may provide general architectures and functions suitable for implementing one or more of host 110, content servers 140, domain name servers 130, and / or portions thereof do.

It is contemplated that some of the steps discussed herein with software methods may be implemented in hardware, for example, as circuit elements that cooperate with a processor executing various method steps. Some of the functions / elements described herein may be implemented as a computer program product in which the methods and / or techniques described herein may be invoked by adapting the operation of the computer as it is being processed by the computer ) Or otherwise provided. The instructions for invoking methods of the present invention may be stored on a fixed or removable medium and / or may be transmitted via a data stream in a broadcast or other signal bearing medium and / Lt; / RTI >

Various embodiments provide significant benefits. In particular, systems, devices and methodologies based on various embodiments may be integrated directly into feature sets of so-called smartphones. Such integration may be achieved through a combination of raw hardware / software feature sets and mobile phone manufacturers (e.g., Apple, Motorola, HTC, Samsung, Research In Motion, LG, Google, Microsoft, etc.).

The features integrated according to various embodiments provide an efficient mechanism for performing the various functions described herein and provide product differentiation to various hardware and software vendors.

The various embodiments described herein may be applied to many different network scenarios where Wi-Fi is added (e.g., Wi-Fi is added), where (1) multi-homing has become a ubiquitous feature on smart phones, 3G / 4G), (3) no special network side equipment is required, and (4) no upgrade to the server is required. The present invention therefore adds value to the phone or mobile OS without relying on any third party investment.

Advantageously, the various embodiments illustratively enable mobility or interface movement across the networks or across the access providers for HTTP based content retrieval applications. These applications represent a large number of mobile Internet traffic.

Various embodiments may provide these features in a manner that is transparent to the applications, such that it may be possible for a legacy application or the like to subsequently affect the features. Various embodiments also provide these peters in a manner transparent to access providers, so that no special network-side equipment, such as mobile anchors, is required.

Moreover, remote content servers do not require any protocol upgrades unless the application layer protocol includes an offset description in the content request message. This condition is satisfied for HTTP and similar protocols.

Moreover, the content server may also be changed during mobility / interface-migration, which makes it possible to use an optimal server for each network selected. The feature also enables operation when there are proxies present in some networks, e.g., corporate networks. Thus, in various embodiments, session mobility between a corporate network and a mobile network operator's network is supported.

While various embodiments incorporating the teachings of the present invention have been shown and described in detail herein, those skilled in the art will readily envision many other varied embodiments that still incorporate these teachings.

Claims (10)

A method for moving a content search session associated with a content retrieval application at a host from a first server through a first interface to a second server via a second interface,
Establishing a transfer connection with the second server using the second interface;
Transmitting a content request message to the second server via the second interface, the content request message including an identifier associated with the content to be searched and an indication of content portions received by the content search application;
Analyzing a content bearing data stream received via the second interface to identify additional content portions received by the content retrieval application;
And transmitting, to the content retrieval application, identified content portions that have not been received by the content retrieval application
Way.
The method according to claim 1,
Further comprising inhibiting delivery of content received via the first interface
Way.
The method according to claim 1,
The method of claim 1, further comprising: caching content request messages transmitted by the content retrieval application, wherein the content identifier in the content request message transmitted to the second server via the second interface comprises a cached content request message Derived from
Way.
The method of claim 3,
Further comprising: caching a representation of content portions delivered to the content retrieval application, wherein an indication of the content portions received by the content retrieval application is derived from a cached content sub-
Way.
The method according to claim 1,
Wherein the transfer connection with the second server comprises a congestion level indicator received via the first interface, a congestion level indicator received via the second interface, a determination that the preferred service provider is associated with the second interface, A determination that a preferred server is associated with the second interface, a determination that a reduced cost is associated with the second interface, a determination that a performance increase is associated with the second interface, and a determination that the preferred network is associated with the second interface Lt; RTI ID = 0.0 > and / or < / RTI >
Way.
The method according to claim 1,
Wherein the indication of the content portions received by the content search application is based on an octet count,
The content request message includes an HTTP GET message,
Wherein the indication of the content portions received by the content retrieval application is based on an octet count and the octet count is included as a RANGE entry in the HTTP GET message
Way.
The method according to claim 1,
Wherein the DNS location service is used to identify the second server and the method comprises the steps of providing a DNS with a uniform resource identifier (URI) or a uniform resource locator (URL) associated with the second server Sending a request to the DNS location service
Way.
The method according to claim 1,
TCP is used as a transport mechanism and further data transfer by the first server is suppressed by sending a TCP RST message over the first interface
Way.
An apparatus for moving a content search session associated with a content retrieval application at a host from a first server through a first interface to a second server via a second interface,
A processor,
The processor comprising:
Establishing a transfer connection with the second server using the second interface,
Transmitting a content request message to the second server via the second interface, the content request message including an identifier associated with the content to be searched and an indication of content portions received by the content search application;
Analyzing the content-containing data stream received via the second interface to identify additional content portions received by the content search application,
To the content retrieval application, to transmit identified content portions that have not been received by the content retrieval application
Device.
A computer readable storage medium storing instructions that, when executed by a processor, causes a computer readable storage medium to perform a method of moving a content search session associated with a content retrieval application at a host from a first server via a first interface to a second server via a second interface, As a possible medium,
Establishing a transfer connection with the second server using the second interface;
Transmitting a content request message to the second server via the second interface, the content request message including an identifier associated with the content to be searched and an indication of content portions received by the content search application;
Analyzing the content-containing data stream received via the second interface to identify additional content portions received by the content search application;
And transmitting, to the content retrieval application, identified content portions that have not been received by the content retrieval application
Computer readable medium.

Images