HK1145758A - Handoff at an ad-hoc mobile service provider - Google Patents

Description

Handover at an ad hoc mobile service provider

Cross Reference to Related Applications

This application is based on 35U.S.C. § 119 a provisional application No.60/956,658 entitled "Method for a heterologous wire Ad Hoc Mobile Service Provider" filed on 8/17.2007 and a provisional application 60/980,557 entitled "Handoff Inad Hoc Mobile Broadband Network" filed on 10/17.2007.

Technical Field

The present disclosure relates generally to telecommunications and more specifically to handover in an ad hoc mobile broadband network.

Background

Wireless telecommunication systems are widely deployed to provide various services to consumers, such as telephony, data, video, audio, messaging, broadcast, and so on. These systems continue to evolve as market forces drive wireless communications to new heights. Today, wireless networks provide broadband internet access to mobile users locally, nationally, or even worldwide. Such networks are sometimes referred to as Wireless Wide Area Networks (WWANs). WWAN operators typically provide their subscribers with a wireless access plan, e.g., a monthly flat-rate subscription plan.

Accessing the WWAN from all mobile devices may not be feasible. Some mobile devices may not have a WWAN radio. Other mobile devices with WWAN radios may not have a valid subscription plan. Ad hoc networks allow mobile devices to dynamically connect over a wireless interface using protocols such as WLAN, bluetooth, UWB, or other protocols. There is a need in the art for a method that allows a user of a mobile device without WWAN access to dynamically subscribe to wireless access services provided by a user of a WWAN-capable mobile device, wherein the subscription is made using wireless ad hoc networking between the mobile devices belonging to both users.

Disclosure of Invention

In one aspect disclosed herein, an ad hoc service provider includes a processing system configured to: in support of pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider, the processing system is further configured to allow the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

In one aspect disclosed herein, a method for receiving a handoff at an ad hoc service provider comprises: supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

In one aspect disclosed herein, an ad hoc service provider comprises: means for supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and means for allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

In one aspect disclosed herein, a machine-readable medium comprises instructions executable by a processing system in a mobile server provider, the instructions comprising: code for supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and code for allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

It is to be understood that other aspects disclosed herein will become readily apparent to those skilled in the art from the following detailed description, wherein various aspects of the ad hoc mobile broadband network are shown and described by way of illustration. As will be recognized, the aspects disclosed herein can be implemented in other different configurations and its numerous details can be modified in numerous other aspects. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

Drawings

Fig. 1 is a simplified block diagram illustrating an example of a telecommunications system.

Fig. 2 is a simplified block diagram illustrating an example of a handover in a telecommunication system.

Fig. 3 is a call flow diagram illustrating an example of a pre-authentication procedure for handover.

Fig. 4 is a simplified block diagram illustrating an example of the functionality of an ad hoc service provider.

Fig. 5 is a simplified block diagram illustrating an example of a hardware configuration for a processing system in an ad hoc service provider.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various aspects of an ad hoc mobile broadband network and is not intended to represent the only configurations that may be used to implement aspects encompassed by the claims. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject matter disclosed herein. However, it will be apparent to one of ordinary skill in the art that the various embodiments of the ad hoc mobile broadband network may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the various concepts presented throughout this disclosure.

Fig. 1 is a simplified block diagram illustrating an example of a telecommunications system. The telecommunications system 100 is shown with multiple WWANs for providing broadband access to the network 102 for mobile users. Network 102 may be a packet-based network, such as the Internet, or some other suitable network. For clarity of presentation, two WWANs 104 are shown with backhaul connections to the internet 102. Each WWAN104 may be implemented with a plurality of fixed-location base stations (not shown) dispersed throughout a geographic area. The geographical area can generally be subdivided into smaller areas called cells. Each base station may be configured to serve all mobile users in its respective cell. A base station controller (not shown) may be used to manage and coordinate the base stations in the WWAN104 and support the backhaul connection to the internet 102.

Each WWAN104 may support radio communication with mobile users using one of many different wireless access protocols. For example, one of the WWANs 104 may support evolution-data optimized (EV-DO) while another WWAN104 may support Ultra Mobile Broadband (UMB). EV-DO and UMB are air interface standards promulgated by the third generation partnership project 2(3GPP2) as part of the CDMA2000 family of standards and applying multiple access techniques such as Code Division Multiple Access (CDMA) to provide broadband internet access to mobile users. Alternatively, one of the WWANs 104 may support Long Term Evolution (LTE), which is a project within 3GPP2 that improves the Universal Mobile Telecommunications System (UMTS) mobile phone standard primarily based on a wideband CDMA (W-CDMA) air interface. One of the WWANs 104 may also support the WiMAX standard developed by the WiMAX forum. The actual wireless access protocol employed by the WWAN for any particular telecommunications system will depend on the particular application and the overall design constraints imposed on the system. The various techniques presented throughout this disclosure are equally applicable to any combination of heterogeneous or homogeneous WWANs, regardless of the wireless access protocol used.

Each WWAN104 has multiple mobile subscribers. Each user may have a mobile node 106 that is able to access the internet 102 directly through the WWAN 104. In the telecommunication system shown in FIG. 1, the mobile nodes 106 access the WWAN104 using EV-DO, UMB, or LTE wireless access protocols; in actual implementations, however, these mobile nodes 106 may be configured to support any wireless access protocol.

One or more of these mobile nodes 106 may be configured to create an ad hoc network in its vicinity based on a wireless access protocol that is the same as or different from the wireless access protocol used to access the WWAN 104. For example, the mobile node 106 may support a UMB wireless access protocol with a WWAN while providing an IEEE 802.11 access point for mobile nodes 108 that cannot directly access the WWAN. IEEE 802.11 represents a set of Wireless Local Access Network (WLAN) standards developed by the IEEE 802.11 association for short-range communications (e.g., tens to hundreds of meters). Although IEEE 802.11 is a public WLAN wireless access protocol, other suitable protocols may be used.

A mobile node 106 that may be used to provide an access point for another mobile node 108 will be referred to herein as an "ad hoc service provider". Mobile nodes 108 that may use the access points of ad hoc service providers 106 will be referred to herein as "mobile clients". The mobile node, whether an ad hoc service provider 106 or a mobile client 108, may be a laptop, a mobile phone, a Personal Digital Assistant (PDA), a mobile digital audio player, a mobile gaming device, a digital camera, a digital video camera, a mobile audio device, a mobile video device, a mobile multimedia device, or any other device capable of supporting at least one wireless access protocol.

Ad hoc service provider 106 may extend its wireless broadband internet access service to mobile client 108, otherwise mobile client 108 would not have internet access. The server 110 may be used as a "switch" to allow the mobile client 108 to purchase unused bandwidth from the ad hoc service provider 106 to access the internet 102, for example, through the WWAN 104.

The ad hoc service provider 106, the server 110, and the one or more mobile clients 108 may establish a network that is an ad hoc heterogeneous wireless network. By way of example, the heterogeneous wireless networks may include at least two types of wireless networks (e.g., WWAN and WLAN). For example, an ad hoc network may be one whose particular configuration may change over time or as one network forms to the next. The network configuration is not planned in advance before the network is established. Examples of the configuration of an ad hoc network may include configurations about which members of the network will be (e.g., which ad hoc service provider, which server, and/or which mobile client will be included in the network), configurations about the geographic locations of the ad hoc service provider and the mobile client, and configurations about when and for how long the network is to be established.

In one example of a switch, mobile client 108 registers with server 110. After registration, the mobile client 108 may search for available ad hoc service providers 106 when internet access is required. When the mobile client 108 detects the presence of one or more ad hoc service providers 106, it may select one ad hoc service provider 106 to initiate a session with based on various parameters, such as bandwidth, quality of service (QoS), and price. Another parameter that the mobile client 108 may use to select an ad hoc service provider 106 is availability over time. For example, a mobile user at an airport may turn on his mobile node (e.g., a laptop or mobile phone) and wait for up to 30 minutes while waiting for an airplane as an ad hoc service provider 106. A mobile client 108 that needs to access the internet 102 for up to 45 minutes may choose not to pick up the ad hoc service provider 106 even though the ad hoc service provider 106 may provide sufficient bandwidth with good QoS. Another mobile client 108 that requires up to 15 minutes of internet access may select the ad hoc service provider 106 due to the bandwidth and QoS of the ad hoc service provider 106. In any case, after the mobile client 108 selects the ad hoc service provider 106, a session may be established based on parameters negotiated between the two (e.g., bandwidth, QoS, session duration, etc.). A link encryption key may be established between the ad hoc service provider 106 and the mobile client 108 during the establishment of the session. A secure socket layer virtual private network (SSL VPN) session may be established between the mobile client 108 and the server 110. The transport layer port may remain open and unencrypted to provide visibility for the network address translation function at the ad hoc service provider 106. In this example, all internet traffic is routed through the server 110 via the client-server tunnel 112 to provide security.

In some telecommunication systems, after a mobile client 108 accesses the internet 102, it listens to other ad hoc service providers 106 and measures the signal strength of the ad hoc service providers 106 it listens to. The mobile client 108 uses these measurements to create a valid list. The active list is a list of ad hoc service providers 106 that may provide services to the mobile client 108. The mobile client 108 will continue to measure the signal strength of other ad hoc service providers 106 and may add or delete ad hoc service providers 106 from the active list as the configuration of the ad hoc network changes.

One function of the active set is to allow the mobile client 108 to quickly switch between ad hoc service providers 106 while maintaining a current session with the server 110. The mobile client 108 may consider switching to another ad hoc service provider 106 based on any number of factors. These factors may include, for example, the inability of the ad hoc service provider 106 to provide the bandwidth or QoS negotiated at the start of the session. Alternatively, the ad hoc service provider may not be able to provide internet access to the mobile client 108 for the entire duration of the session. It is often seen that a mobile user on an ad hoc service provider 106 who has negotiated a 30 minute session with a mobile client 108 may only leave approximately 15 minutes for the session for various reasons. In this case, the mobile client 108 would need to select a new ad hoc service provider from the active list to hand off. During a session between the mobile client 108 and the current ad hoc service provider 106, the server 110 uses the active list to pre-authenticate other ad hoc service providers for handoff. The time required to handoff the mobile client 108 may be reduced by pre-authenticating the ad hoc service providers 106 in the active list before the ad hoc service provider 106 currently servicing the mobile client 108 is interrupted.

The term "pre-authentication" is used herein to mean authenticating a target ad hoc service provider 106 for handover before receiving a message from an ad hoc service provider currently serving a mobile client 108 regarding the unavailability of the current ad hoc service provider 106. The message may provide notification to the server 110 that the current ad hoc service provider 106 has been interrupted and that a hard handoff to another ad hoc service provider 106 must be performed if the session between the mobile client 108 and the server 110 is to be maintained. Alternatively, the message may provide notification to the server 110 that the current ad hoc service provider 106 will soon be down or that it is no longer able to provide the negotiated service (e.g., QoS, bandwidth, etc.) to the mobile client 108. This provides the server 110 with an option to allow the mobile client 108 to soft handoff to another ad hoc service provider 106.

Pre-authentication includes providing encryption/decryption keys to potential new ad hoc service providers 106 and mobile clients 108 prior to handoff, which may be required for communications between the potential new ad hoc service providers 106 and mobile clients 108.

Pre-authentication also includes providing encryption/decryption keys to the current ad hoc service provider 106 and the new ad hoc service provider 106 prior to handoff, which may be required for communication between the current ad hoc service provider 106 and the new ad hoc service provider 106.

The pre-verification also includes authorization for communication between the potential new ad hoc service provider 106 and the current ad hoc service provider 106. It also includes authorization for communication between the potential new ad hoc service provider 106 and the mobile client 108.

Fig. 2 is a simplified block diagram illustrating an example of a handover in a telecommunication system. In this example, the mobile client 108 is from the current ad hoc service provider 106₁Switch to target service provider 106₂. Using two ad hoc service providers 106 during handoff₁、106₂A persistent tunnel 112 between to maintain a session of the mobile client with the server 110. May be provided by the current ad hoc service provider 106 during handoff₁The received data packet is forwarded to the target ad hoc service provider 106 via the tunnel 112₂. Alternatively or additionally, the current ad hoc service provider 106 may be used₁The received data packet is forwarded to the target ad hoc service provider 106 either directly over the wireless link 114 between the two shown in fig. 2 or through another ad hoc service provider (not shown)₂。

The mobile client 108 may have an IPv4, IPv6, or other suitable address that the server 110 uses to maintain the session. The address may be provided to the mobile client 108 by the server 110 or one of the ad hoc service providers 106 in the telecommunications network 100 (see fig. 1). Alternatively, the address may be stored on the mobile client 108. In at least one configuration, the address may be a mobile IP address.

The tunneling anchor is shown as a server in fig. 2. The tunneling anchor point may be any suitable entity or distributed among multiple entities in the telecommunications system 100. The tunneling anchor point may be coupled to the internet 102 as shown in fig. 2 or located elsewhere. By way of example, the tunneling anchor point may be located anywhere in the internet 102, or in the network operator's infrastructure. One of ordinary skill in the art will readily determine the best implementation of a tunneling anchor for any particular application based on performance requirements, overall design constraints imposed on the system, and/or other relevant factors.

Fig. 3 is a call flow diagram illustrating an example of an authentication procedure for handover. For clarity of illustration, various signaling for the ad hoc service provider 106 and the mobile client 108 to authenticate the server 110 and register with the server 110 will be omitted.

In step 302, when the ad hoc service provider 106 is present₁When mobile and wishes to provide services, ad hoc service provider 106₁A connection with the server 110 may be initiated. Extended authentication protocol-tunneling layer security (EAP-TTLS) may be used for authentication, authorization and accounting (AAA) and secure session establishment for the connection. At step 304, when the mobile client 108 requires internet access, the mobile client 108 may initiate communication with the ad hoc service provider 106₁(hereinafter referred to as "current ad hoc service provider"). EAP-TTLS may also be used for AAA and secure session establishment. In particular, the ad hoc service provider 106₁The mobile client's credentials are sent to the server 110 for EAP-AAA authentication. The EAP-TTLS authentication response from server 110 is then used to generate the master shared key. Next, the current ad hoc service provider 106 may be present₁A link encryption key is established with the mobile client 108. An SSL VPN session may then be established between the mobile client 108 and the server 110 at step 306.

It should be noted that any pair of nodes (where the nodes include the server 110, the current service provider 106) may be used₁Target service provider 106₂And mobile client 108) to encrypt the information stream. The encryption/decryption key may be established in the system when a node in the system connects with the server. A typical symmetric key encryption technique, such as that using AES, may be used for such encryption and decryption of message streams between any pair of nodes in the system.

In step 308, the mobile client 108 provides the active list to the server 110. Alternatively, the mobile client 108 may send a report for determining the ad hoc service providers that it may hear, as well as data indicating the signal strength measurements of each ad hoc service provider, and any other service parameters it may infer about the service provider. The server 110 may use the report to generate a valid list on the server side.

Server 110 pre-authenticates one or more ad hoc service providers in the active list. At the target service provider 106₂During pre-authentication with client 108, server 110 provides target service provider 106 with₂Provides encryption/decryption keys for communication with the client 108. The server may also provide the target service provider 106 with the server₂Provide for interaction with the current service provider 106₁Encryption/decryption keys for the communication. The server 110 may also provide the client 108 with a service provider 106 for interaction with the target service provider₂Encryption/decryption keys for the communication. The current service provider 106 may be handed off by the server 110 or at any earlier time₁Providing for interaction with a target service provider 106₂Encryption/decryption keys for the communication. The exact number of pre-authenticated ad-hoc service providers in the active list depends on the admission control policy implemented by the server 110. For example, if the server 110 determines that additional ad hoc service providers will adversely affect performance in the WWAN, it may limit the number of ad hoc service providers at a given location. A WWAN operator that does not want its mobile subscribers to provide service within a given geographic location may depend on various networksConstraints to impose additional constraints. In any case, the server 110 pre-authenticates the one or more ad hoc service providers by providing each of the one or more ad hoc service providers with a key for encrypting the data link between the mobile client 108 and the new ad hoc service provider 106 after the handoff. In FIG. 3, server 110 is shown as providing to an ad hoc service provider 106 at step 310₂The key is provided (hereinafter referred to as the target ad hoc service provider). The server 110 also provides the key to the mobile client 108 at step 312.

At step 314, the mobile client 108 sends a message to the current ad hoc service provider 106 requesting a handoff to an alternate service provider. Step 314 is optional and is indicated by a dashed line from the client to the ad hoc service provider.

At step 316, the current ad hoc service provider 106₁A message for requesting handover is sent to the server 110. The message is tagged with an identifier indicating that the handoff was initiated by the mobile client 108 or by the current ad hoc service provider 106₁And (4) initiating. May be present at the ad hoc service provider 106₁The message is created because the current ad hoc service provider cannot continue to provide service to the mobile client. Alternatively, the message may be created at the mobile client (step 314) and need to be provided by the current ad hoc service provider 106₁To the server 110. Step 316 is optional for a handover directly initiated by the server. For a mobile client 108 or ad hoc service provider 106₁Initiated handoff, server 110 responds to step 316 to the current ad hoc service provider 106 at step 318₁A message for authorizing the handover is sent back. Alternatively, there is no current ad hoc service provider 106 from₁In the case of message 316, step 318 may be a message from the server to initiate the handover. To the current ad hoc service provider 106₁The transmitted message may determine the target ad hoc service for handoverProvider 106₂Or alternatively allow mobile client 108 to decide. In the latter case, the user on mobile client 108 selects the target ad hoc service provider for handover according to any admission control policy constraints imposed by server 110. Server 110 also provides mobile client 108 with a quality metric for each ad hoc service provider available to the mobile client. The quality metric may be used to assist a user on the mobile client 108 in selecting a new ad hoc service provider for handover. In the example shown in fig. 3, the mobile client 108 selects the target ad hoc service provider 106 for handover₂。

At step 320, the server may optionally send a message regarding delivery to one or more target service providers 106₂The handover message of (1). At step 322, by the current service provider 106₁The handover message received from the server 110 is sent to the mobile client 108.

At step 324, the mobile client 108 establishes an association with the target ad hoc service provider 106 by sending a message encrypted with a key₂The connection of (2). Since the target ad hoc service provider 106₂The same key is received during the pre-authentication process so it can decrypt the message and establish a session with the mobile client 108 to complete the handoff. At step 326, the target ad hoc service provider 106₂A message may also be sent back to the server 110 to indicate that the handover has been successfully completed.

Packets that have left the mobile client 108 may be arriving at the current ad hoc service provider 106₁En route, or possibly at the current ad hoc service provider 106₁In (1). These packets require the current ad hoc service provider 106₁Is continuously supported. Other packets that have left mobile client 108 may be en route to server 110 or waiting for further processing at server 110, or may be en route to their final destination outside of the tunneling server. After the handoff, packets will be sent in the future away from the mobile client 108To the target ad hoc service provider 106₂. Packets destined for mobile client 108 may be waiting at the server. The packet is sent to the target ad hoc service provider 106 after the handoff₂. Other packets destined for the mobile client 108 may be arriving at the current ad hoc service provider 106₁Or may be currently on the way of the ad hoc service provider 106₁Waiting, or may be en route from the current service provider to the mobile client 108, and the current ad hoc service provider 106₁The delivery of the packet to the mobile client 108 needs to be continuously supported. The packet may be delivered at the current ad hoc service provider 106₁With the target ad hoc service provider 106₂Over a wireless link or over a multi-hop wireless path. Alternatively, it may be provided by the current ad hoc service provider 106₁The packet is passed to the server 110, and the server 110 then passes the target ad hoc service provider 106₂To transmit them. Current ad hoc service providers 106₁With the target ad hoc service provider 106₂May be exchanged through the server 110 or over a wireless link or multi-hop wireless path between the two service providers.

Fig. 4 is a simplified block diagram illustrating an example of the functionality of an ad hoc service provider. Ad hoc service providers 106 have the ability to enable interconnection between wireless links based on homogeneous or heterogeneous wireless access protocols. This may be accomplished with a WWAN network interface 402 and a WLAN network interface 404, where the WWAN network interface 402 supports a wireless access protocol for a WWAN to the internet 102 and the WLAN network interface 404 provides a wireless access point for the mobile client 108. By way of example, the WWAN network interface 402 may include transceiver functionality that supports EV-DO for internet access through a WWAN, and the WLAN network interface 404 may include transceiver functionality that provides an 802.11 access point for the mobile client 108. More generally, each of the WWAN network interface 402 and WLAN network interface 404 may be configured to implement the physical layer by providing a module for transmitting raw data bits according to the physical and electrical specifications required for the interface to the respective transmission medium. Each of the WWAN network interface 402 and the WLAN network interface 404 may also be configured to implement a lower portion of the data link layer by managing access to the respective transmission medium.

The ad hoc service provider 106 is shown with a filtering interconnection and session monitoring module 406. The module 406 provides filtering for content from the mobile clients 108 so that the interconnection between the ad hoc wireless link to WWAN network interface 402 is provided only to mobile clients 108 that have been server verified and allowed to use the WWAN network. The module 406 also maintains a tunneled connection between the server and the authenticated mobile client 108.

The ad hoc service provider 106 also includes a service provider application 408 that (1) allows the module 406 to provide ad hoc services to the mobile client 108 and (2) supports WWAN or internet access to mobile users or subscribers of the ad hoc service provider 106. The latter functionality is supported through a user interface 412, which user interface 412 communicates with the WWAN interface 402 under control of the service provider application 408 through module 406.

As discussed above, the service provider application 408 allows the module 406 to provide ad hoc services to the mobile client 108. The service provider application 408 maintains a session with the server to exchange customized messages with the server. In addition, the service provider application 408 also maintains a separate session with each mobile client 108 for the exchange of custom messages between the service provider application 408 and that mobile client 108. The service provider application 408 provides information about authenticated and licensed clients to the filtered interconnection and session monitoring module 406. The filtering interconnection and session monitoring module 406 only allows content flow for authenticated and allowed mobile clients 108. The filtered interconnection and session monitoring module 406 also optionally monitors information about the content flow associated with the mobile client 108, such as the amount of content sent out from and to the mobile client, as well as information about WWAN and WLAN network resource utilization and available bandwidth on the wireless channel. The filtered interconnection and session monitoring module 406 may additionally and optionally provide this information to the service provider application 408. The service provider application 408 may optionally process the information and take appropriate action, such as determining whether to continue to maintain a connection with the mobile client 108 and with the server, or whether to continue to provide service. It should be noted that the various functions described in modules 406 and 408 may be implemented in any given platform in one or more sets of modules that cooperate to provide these functions at the ad hoc service provider 106.

When the ad hoc service provider 106 decides to provide these services, the service provider application 408 sends a request to the server for approval. The service provider application 408 requests authentication by the server and approval from the server to provide service to one or more mobile clients 108. The server may authenticate the ad hoc service provider 106 and then determine whether it approves the ad hoc service provider's request. As previously described, the request may be rejected if the number of ad hoc service providers within the same geographic area is too large or if the WWAN operator imposes certain constraints on the ad hoc service provider 106.

After authenticating the ad hoc service provider 106, the service provider application 408 may advertise an ad hoc WLAN Service Set Identifier (SSID). Interested mobile clients 108 may associate with the SSID to access the ad hoc service provider 106. The service provider application 408 may then authenticate the mobile client 108 with the server and then configure the filtered interconnection and session monitoring module 406 to connect the mobile client 108 to the server. During authentication of the mobile client 108, the service provider application 408 may use an unsecured wireless link.

After authenticating the mobile client 108, the service provider application 408 may optionally choose to move the mobile client 108 to a new SSID with a secure link. In this case, the service provider application 408 may allocate the time spent in each SSID according to the load that needs to be supported for the existing session with the mobile client 108.

The service provider application 408 can also determine whether it can support the mobile client 108 before allowing the mobile client 108 access to the network. Resource intelligence can be used to estimate the depletion of battery power and other processing resources that may result from accepting a mobile client 108 and can help determine whether a service provider application 408 should consider supporting a new mobile client 108 or accepting a handoff of the mobile client 108 from another ad hoc service provider.

The service provider application 408 may admit mobile clients 108 and provide them with certain QoS guarantees, such as average bandwidth expected during a session. The average throughput provided to each mobile client 108 over a time window may be monitored. The service provider application 408 may monitor the throughput of all flows that flow through it to ensure that the resource utilization of the mobile client 108 is below a certain threshold and that it meets the QoS requirements that it agrees to provide to the mobile client 108 during the establishment of the session.

The service provider application 408 may also provide a particular level of security to the wireless access point by routing the content through the filtering interconnect and session monitoring module 406 without being able to decipher the content. Similarly, the service provider application 408 may be configured to ensure that content routed between the user interface 410 and the WWAN104 via the module 406 is not deciphered by the mobile client 108. The service provider application 408 may use any suitable encryption technique to implement this functionality.

The service provider application 408 may also maintain a period of time for the mobile client 108 to access the network. The time period may be agreed upon between the service provider application 408 and the mobile client 108 during session initiation. If the service provider application 408 determines that it cannot provide access to the network to the mobile client 108 within the agreed-upon period of time, it may notify the server and the mobile client 108 of its invalidity. This may occur due to energy constraints (e.g., low battery) or other unforeseen events. The server may then consider handing off the mobile client to another ad hoc service provider as long as such ad hoc service provider exists in the vicinity of the mobile client 108. The service provider application 408 may support this handoff of the mobile client 108.

The service provider application 408 may also contribute processing resources to maintain wireless links or restricted sessions with mobile clients 108 served by other ad hoc service providers. This may facilitate handoff of the mobile client 108 to the ad hoc service provider 106.

The service provider application 408 may manage the mobile client 108 as a whole and the session in particular, through the user interface 412. Alternatively, the service provider application 408 may support a seamless mode of operation with processing resources that are dedicated to serving the mobile client 108. In this way, the mobile client 108 is managed in a manner that is transparent to the mobile user. This seamless mode of operation is desirable when a mobile user does not want to manage the mobile client 108 but wants to continue to generate revenue by sharing bandwidth with the mobile client 108.

In at least one configuration of an ad hoc service provider, a processing system may be used to implement the filtering interconnection and session monitoring module 406, the service provider application 408, and the service provider user interface 412. The WWAN interface 402 and the WLAN interface 404 may be separate from the processing system as shown in fig. 4 or, alternatively, may be partially or entirely integrated into the processing system.

Fig. 5 is a simplified diagram illustrating an example of a hardware implementation of a processing system in a service provider. In this example, the processing system 500 is shown with a bus architecture, represented generally by the bus 502. The bus 502 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 500 and the overall design constraints. The bus links together various circuits including the processor 504, the machine-readable medium 506, and the service provider user interface 510. The bus 502 may also link various other circuits such as timing resources, peripherals, voltage regulators, power management circuits, and the like, which are also well known in the art, and therefore, will not be described any further. A network adapter 508 provides an interface between the WWAN and WLAN network interfaces 402,404 (see fig. 4) and the bus 502.

The processor 504 is responsible for managing the bus and general processing, including the execution of software stored on the machine-readable medium 506. Processor 504 may be implemented with one or more general and/or special purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits that can execute software. Software should be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The machine-readable medium may include, for example, RAM (random access memory), flash memory, ROM (read only memory), PROM (programmable read only memory), EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), registers, a magnetic disk, an optical disk, a hard disk drive, or any other suitable storage medium or any combination thereof.

In the hardware implementation shown in fig. 5, the machine-readable medium 506 is shown as being part of the processing system 500 separate from the processor 504. One of ordinary skill in the art will readily appreciate that the machine-readable medium 506, or any portion thereof, may be external to the processing system 500. By way of example, the machine-readable medium 506 may include a transmission line, a carrier waveform modulated with data, and/or a computer product separate from the ad hoc service provider, which the processor 504 may access through the network interface 508. Alternatively or in addition, the machine-readable medium 506, or any portion thereof, may be integrated into the processor 504, such as with a cache memory and/or a general register file.

The processing system 500 may be configured as a general purpose processing system having one or more microprocessors providing processor functionality and an external memory providing at least a portion of the machine readable medium 506 linked together with other supporting circuitry through an external bus architecture. Alternatively, the processing system 500 may be implemented with an ASIC (application specific integrated circuit) having at least a portion of the processor 504, the network interface 508, the service provider user interface 510, support circuits (not shown), and the machine readable medium 506 integrated into a single chip, or with an FPGA (field programmable gate array), a PLD (programmable logic device), a controller, a state machine, gated logic, discrete hardware components, or any other suitable circuit or combination of circuits that may perform the various functions described throughout this disclosure. Those of ordinary skill in the art will recognize how best to implement the described functionality of the processing system 500 depending on the particular application and the overall design constraints imposed on the overall system.

The machine-readable medium 506 is shown with a number of software modules. The software modules include instructions that, when executed by the processor 504, cause the processing system to perform various functions. Each software module may be located in a single storage device or distributed across multiple storage devices. For example, a software module may be loaded into RAM from a hardware driver when a triggering event occurs. During execution of the software modules, the processor 504 may load some of the instructions into cache memory to increase access speed. One or more cache lines may then be loaded into the general register file for execution by processor 504. When referring to the functionality of a software module below, it is understood that the functionality is implemented by the processor 504 executing instructions from the software module.

The protocol stack module 511 may be used to implement the protocol architecture for the ad hoc service provider or any portion thereof. In the presently described implementation, the protocol stack module 511 is responsible for implementing several protocol layers that run above the data link layer implemented by the WWAN network interface 402 and the WLAN network interface 404 (see fig. 4). For example, the protocol stack module 511 may be used to implement the upper portion of the data link layer by providing flow control, acknowledgement, and error recovery. The protocol stack module 511 may also be used to implement the network layer by managing the transfer of packet data from source to destination, and the transport layer by providing transparent transfer of data between end users. Although described as part of a processing system, the protocol stack module 511, or any portion thereof, may be implemented by the WWAN network adapter 402 and the WLAN network adapter 404.

The machine-readable medium 506 is also shown with a filtering interconnection and session monitoring module 512 and a service provider application 514. These software modules, when executed by the processor 504, cause the processing system to perform the process steps shown and described above in connection with the ad hoc service provider in fig. 1-4.

The user interface 510 may include any other combination of keypad, display, speaker, microphone, joystick, and/or user interface devices that allow a mobile user or user to access the WWAN or the wireless network 102.

Turning now to the mobile client, the mobile client 108 may use the TLS session to register with the server 110. After registration, the mobile client 108 may search for available ad hoc service providers 106. When the mobile client 108 detects the presence of one or more ad hoc service providers 106, it may initiate a session with the ad hoc service provider 106 using EAP-TTLS based on parameters such as available bandwidth that the ad hoc service provider 106 may support, QoS metrics of the ad hoc service provider 106, and prices of advertised services. As previously described, a link encryption key may be established between the mobile client 108 and the ad hoc service provider 106 during session establishment. An SSLVPN session may be established between the mobile client 108 and the server 110 so that all traffic between the two may be encrypted. The transport layer port may remain open and unencrypted to provide visibility for the network address translation function at the ad hoc service provider 106.

The handoff of the mobile client 108 may be performed in various ways. In one configuration, the mobile client 108 may maintain restricted sessions with multiple ad hoc service providers 106 while using one ad hoc service provider 106 to access the internet. As previously mentioned, this approach may facilitate the handover procedure. In an alternative configuration, the mobile client 108 may only consider handover when necessary. In this configuration, the mobile client 108 may maintain a valid list of ad hoc service providers 106 in its vicinity for use in handoff. When the current ad hoc service provider 106 needs to stop its service, the mobile client 108 may select one ad hoc service provider 106 from the active list to handoff. When handoff is not feasible, the mobile client 108 may need to reconnect through another different ad hoc service provider 106 to access the internet. The persistence of the tunnel between the mobile client and the server may allow the mobile client to soft handoff from one service provider to another.

If the bandwidth requirements of the mobile client 108 are greater than the capabilities of the available ad hoc service providers 106, the mobile client 108 may access multiple ad hoc service providers 106 simultaneously. A mobile client 108 with multiple transceivers may potentially access multiple ad hoc service providers 106 simultaneously, using a different transceiver for each ad hoc service provider 106. Different channels may be used if multiple ad hoc service providers 106 may be accessed using the same wireless access protocol. If the mobile client 108 has only one transceiver available, it may allocate the time it takes to access each ad hoc service provider 106.

Those of ordinary skill in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application.

It is to be understood that the specific order or hierarchy of steps in the processes disclosed is merely an example of exemplary approaches. It should be understood that the specific order or hierarchy of steps in the processes may be rearranged based on design preferences. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the versions shown herein, but are to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" but rather "one or more" unless specifically so stated. The term "some" means one or more unless otherwise specified. Pronouns in the male (e.g., his) include female and neutral (e.g., her or it) and vice versa. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. Elements in the claims cannot be construed with the provisions of chapter six of 35u.s.c. § 112 unless the element is explicitly recited with the phrase "module for … …", or in the case of method claims the element is recited with the phrase "step for … …".

Claims (64)

1. An ad hoc service provider, comprising:

a processing system configured to: supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider;

the processing system is further configured to: allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

2. The ad hoc service provider of claim 1, wherein the processing system is further configured to: pre-authentication is supported by receiving a key from the server to support an encrypted link between the ad hoc service provider and the mobile client.

3. The ad hoc service provider of claim 2, wherein the processing system is further configured to: establishing a connection with the mobile client to receive the handoff in response to a message from the mobile client encrypted with the key.

4. The ad hoc service provider of claim 1, wherein the processing system is further configured to: pre-authentication is supported by receiving authorization from the server to communicate with the mobile client.

5. The ad hoc service provider of claim 1, wherein the processing system is further configured to: supporting pre-authentication by receiving a key from the server to support an encrypted link between the ad hoc service provider and the another ad hoc service provider.

6. The ad hoc service provider of claim 1, wherein the processing system is further configured to: supporting pre-authentication by receiving authorization from the server to communicate with the other ad hoc service provider.

7. The ad hoc service provider of claim 1, wherein the processing system is further configured to: allowing the mobile client to maintain a session with the server while receiving the handoff by supporting a tunnel with the other ad hoc service provider.

8. The ad hoc service provider of claim 7, wherein the processing system is further configured to: receiving at least some packets received by the other ad hoc service provider from the mobile client via the tunnel.

9. The ad hoc service provider of claim 1, wherein the processing system is further configured to: receiving at least some packets from the other ad hoc service provider over a wireless link while receiving the handover.

10. The ad hoc service provider of claim 9, wherein the processing system is further configured to: receiving one or more of the at least some packets from the another ad hoc service provider via yet another ad hoc service provider.

11. The ad hoc service provider of claim 1, wherein the processing system is further configured to: providing the mobile client with an IPv4 or IPv6 address.

12. The ad hoc service provider of claim 11, wherein the IPv4 or IPv6 address comprises a mobile IP address.

13. The ad hoc service provider of claim 1, wherein the processing system is further configured to: receiving a message from the server to receive the handoff of the mobile client from the other ad hoc service provider.

14. The ad hoc service provider of claim 1, wherein the processing system is further configured to: hard handoffs are supported.

15. The ad hoc service provider of claim 1, wherein the processing system is further configured to: soft handover is supported.

16. The ad hoc service provider of claim 1, wherein the processing system is further configured to: sending a message to the server indicating that the handover is complete.

17. A method for receiving a handoff at an ad hoc service provider, comprising:

supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and is

Allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

18. The method of claim 17, wherein the pre-authentication is supported by receiving a key from the server to support an encrypted link between the ad hoc service provider and the mobile client.

19. The method as recited in claim 18, further comprising: establishing a connection with the mobile client to receive the handoff in response to a message from the mobile client encrypted with the key.

20. The method of claim 17, wherein the pre-authentication is supported by receiving authorization from the server to communicate with the mobile client.

21. The method of claim 17, wherein the pre-authentication is supported by receiving a key from the server to support an encrypted link between the ad hoc service provider and the another ad hoc service provider.

22. The method of claim 17, wherein the pre-authentication is supported by receiving authorization from the server to communicate with the other ad hoc service provider.

23. The method of claim 17, wherein the mobile client is allowed to maintain a session with the server while receiving the handoff by supporting a tunnel with the other ad hoc service provider.

24. The method of claim 23, further comprising: receiving at least some packets received by the other ad hoc service provider from the mobile client via the tunnel.

25. The method of claim 17, further configured to: receiving at least some packets from the other ad hoc service provider over a wireless link while receiving the handover.

26. The method of claim 25, wherein one or more of the at least some packets received from the another ad hoc service provider are received via yet another ad hoc service provider.

27. The method of claim 17, further comprising: providing the mobile client with an IPv4 or IPv6 address.

28. The method of claim 27, wherein the IPv4 or IPv6 address includes a mobile IP address.

29. The method of claim 17, further comprising: receiving a message from the server to receive the handoff of the mobile client from the other ad hoc service provider.

30. The method of claim 17, wherein the handover comprises a hard handover.

31. The method of claim 17, wherein the handover comprises a soft handover.

32. The method of claim 17, further comprising: sending a message to the server indicating that the handover is complete.

33. An ad hoc service provider, comprising:

means for supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and

means for allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

34. The ad hoc service provider of claim 33, wherein the means for supporting pre-authentication comprises: means for receiving a key from the server to support an encrypted link between the ad hoc service provider and the mobile client.

35. The ad hoc service provider of claim 34, further comprising: means for establishing a connection with the mobile client to receive the handoff in response to a message from the mobile client encrypted with the key.

36. The ad hoc service provider of claim 33, wherein the means for supporting pre-authentication comprises: means for receiving authorization from the server to communicate with the mobile client.

37. The ad hoc service provider of claim 33, wherein the means for supporting pre-authentication comprises: means for receiving a key from the server to support an encrypted link between the ad hoc service provider and the another ad hoc service provider.

38. The ad hoc service provider of claim 33, wherein the means for supporting pre-authentication comprises: means for receiving authorization from the server to communicate with the other ad hoc service provider.

39. The ad hoc service provider of claim 33, wherein the means for allowing the mobile client to maintain a session with the server while receiving the handoff comprises: means for supporting a tunnel with the another ad hoc service provider.

40. The ad hoc service provider of claim 39, further comprising: means for receiving at least some packets received by the other ad hoc service provider from the mobile client via the tunnel.

41. The ad hoc service provider of claim 33, further comprising: means for receiving at least some packets from the other ad hoc service provider over a wireless link while receiving the handover.

42. The ad hoc service provider of claim 41, wherein the means for receiving at least some packets is configured to: receiving, via yet another ad hoc service provider, one or more of the at least some packets received from the another ad hoc service provider.

43. The ad hoc service provider of claim 33, further comprising: means for providing the IPv4 or IPv6 address to the mobile client.

44. The ad hoc service provider of claim 43, wherein the IPv4 or IPv6 address comprises a Mobile IP address.

45. The ad hoc service provider of claim 33, further comprising: means for receiving a message from the server to receive the handoff of the mobile client from the other ad hoc service provider.

46. The ad hoc service provider of claim 33, further comprising: means for receiving a hard handoff.

47. The ad hoc service provider of claim 33, further comprising: means for receiving a soft handoff.

48. The ad hoc service provider of claim 33, further comprising: means for sending a message to the server indicating that the handover is complete.

49. A machine-readable medium comprising instructions executable by a processing system in a mobile server provider, the instructions comprising:

code for supporting pre-authentication with a server in order to receive a handoff of a mobile client from another ad hoc service provider; and

code for allowing the mobile client to maintain a session with the server while receiving the handoff from the other ad hoc service provider.

50. The machine-readable medium of claim 49, wherein the code for supporting pre-authentication comprises: code for receiving a key from the server to support an encrypted link between the ad hoc service provider and the mobile client.

51. The machine-readable medium of claim 50, wherein the instructions further comprise: code for establishing a connection with the mobile client to receive the handoff in response to a message from the mobile client encrypted with the key.

52. The machine-readable medium of claim 49, wherein the code for supporting pre-authentication comprises: code for receiving authorization from the server to communicate with the mobile client.

53. The machine-readable medium of claim 49, wherein the code for supporting pre-authentication comprises: code for receiving a key from the server to support an encrypted link between the ad hoc service provider and the another ad hoc service provider.

54. The machine-readable medium of claim 49, wherein the code for supporting pre-authentication comprises: code for receiving authorization from the server to communicate with the other ad hoc service provider.

55. The machine-readable medium of claim 49, wherein the code for allowing the mobile client to maintain a session with the server while receiving the handoff comprises: code for supporting a tunnel with the another ad hoc service provider.

56. The machine-readable medium of claim 55, wherein the instructions further comprise: code for receiving at least some packets received by the other ad hoc service provider from the mobile client via the tunnel.

57. The machine-readable medium of claim 49, wherein the instructions further comprise: code for receiving at least some packets from the other ad hoc service provider over a wireless link concurrently with receiving the handover.

58. The machine-readable medium of claim 57, wherein the code for receiving at least some packets is configured to: receiving, via yet another ad hoc service provider, one or more of the at least some packets received from the another ad hoc service provider.

59. The machine-readable medium of claim 49, wherein the instructions further comprise: code for providing an IPv4 or IPv6 address to the mobile client.

60. The machine-readable medium of claim 59, wherein the IPv4 or IPv6 address includes a Mobile IP address.

61. The machine-readable medium of claim 49, wherein the instructions further comprise: code for receiving a message from the server to receive the handoff of the mobile client from the other ad hoc service provider.

62. The machine-readable medium of claim 49, wherein the instructions further comprise: code for receiving a hard handoff.

63. The machine-readable medium of claim 49, wherein the instructions further comprise: code for receiving a soft handoff.

64. The machine-readable medium of claim 49, wherein the instructions further comprise: code for sending a message to the server indicating that the handover is complete.