US20090047964A1 - Handoff in ad-hoc mobile broadband networks - Google Patents

Abstract

A server is configured to maintain a session with a mobile client through a first mobile service provider. The server is further configured to pre-authenticate a second mobile service provider for handoff. The server is also configured to enable the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.

Description

CROSS-REFERENCE TO RELATED APPLICATION
• The present application for patent claims priority under 35 U.S.C. §119 to Provisional Application No. 60/956,658 entitled, “Method For A Heterogeneous Wireless Ad Hoc Mobile Service Provider,” filed Aug. 17, 2007 and Provisional Application No. 60/980,557 entitled, “Handoff In Ad-Hoc Mobile Broadband Exchange,” filed Oct. 17, 2007.
BACKGROUND
• 1. Field
• The present disclosure relates generally to telecommunications, and more specifically to handoff in an ad-hoc mobile broadband network.
• 2. Background
• Wireless telecommunication systems are widely deployed to provide various services to consumers, such as telephony, data, video, audio, messaging, broadcasts, etc. These systems continue to evolve as market forces drive wireless telecommunications to new heights. Today, wireless networks are providing broadband Internet access to mobile subscribers over a regional, a nationwide, or even a global region. Such networks are sometimes referred to as Wireless Wide Area Networks (WWANs). WWAN operators generally offer wireless access plans to their subscribers such as subscription plans at a monthly fixed rate.
• Accessing WWANs from all mobile devices may not be possible. Some mobile devices may not have a WWAN radio. Other mobile devices with a WWAN radio may not have a subscription plan enabled. Ad-hoc networking allows mobile devices to dynamically connect over wireless interfaces using protocols such as WLAN, Bluetooth, UWB or other protocols. There is a need in the art for a methodology to allow a user of a mobile device without WWAN access to dynamically subscribe to wireless access service provided by a user with a WWAN-capable mobile device using wireless ad-hoc networking between the mobile devices belong to the two users.
SUMMARY
• In one aspect of the disclosure, a server includes a processing system configured to maintain a session with a mobile client through a first mobile service provider. The processing system is further configured to authenticate a second mobile service provider for handoff. The processing system is also configured to enable the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.
• In another aspect of the disclosure, a server includes means for maintaining a session with a mobile client through a first mobile service provider, means for pre-authenticating a second mobile service provider for handoff, and means for enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.
• In a further aspect of the disclosure, a method of providing service from a server includes maintaining a session with a mobile client through a first mobile service provider. The method further includes pre-authenticating a second mobile service provider for handoff, and enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.
• Inside yet a further aspect of the disclosure, machine-readable medium includes instructions executable by a processing system in a server. The instructions include code for maintaining a session with a mobile client through a first mobile service provider. The instructions further include code for pre-authenticating a second mobile service provider for handoff, and enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.
• It is understood that other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein various embodiments of the invention are shown and described by way of illustration. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modification in various other respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
BRIEF DESCRIPTION OF THE 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 handoff in a telecommunications system.
• FIG. 3 is a call flow diagram illustrating an example of a pre-authentication process for handoff.
• FIG. 4 is a simplified block diagram illustrating an example of a hardware configuration for a server.
• FIG. 5 is a simplified block diagram illustrating an example of a hardware configuration for a processing system in a server.
• FIG. 6 is a simplified block diagram illustrating an example of the functionality of a mobile service provider.
DETAILED DESCRIPTION
• The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations of the present invention and is not intended to represent the only configurations in which the present invention may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention 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 concepts of the present invention.
• FIG. 1 is a simplified block diagram illustrating an example of a telecommunications system. Thetelecommunications system100 is shown with multiple WWANs that provide broadband access to anetwork102 for mobile subscribers. Thenetwork102 may be a packet-based network such as the Internet or some other suitable network. For clarity of presentation, two WWANs104 are shown with a backhaul connection to the Internet102. Each WWAN104 may be implemented with multiple fixed-site base stations (not shown) dispersed throughout a geographic region. The geographic region may be generally subdivided into smaller regions known as cells. Each base station may be configured to serve all mobile subscribers within 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 Internet102.
• Each WWAN104 may use one of many different wireless access protocols to support radio communications with mobile subscribers. By way of example, one WWAN104 may support Evolution-Data Optimized (EV-DO), while the other WWAN104 may support Ultra Mobile Broadband (UMB). EV-DO and UMB are air interface standards promulgated by the 3rd Generation Partnership Project 2 (3GPP2) as part of the CDMA2000 family of standards and employs multiple access techniques such as Code Division Multiple Access (CDMA) to provide broadband Internet access to mobile subscribers. Alternatively, one of WWAN104 may support Long Term Evolution (LTE), which is a project within the 3GPP2 to improve the Universal Mobile Telecommunications System (UMTS) mobile phone standard based primarily on a Wideband CDMA (W-CDMA) air interface. One of WWAN104 may also support the WiMAX standard being developed by the WiMAX forum. The actual wireless access protocol employed by a WWAN for any particular telecommunications system will depend on the specific 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 protocols utilized.
• Each WWAN104 has a number of mobile subscribers. Each subscriber may have amobile node106 capable of accessing the Internet102 directly through the WWAN104. In the telecommunications system shown inFIG. 1, thesemobile nodes106 access the WWAN104 using an EV-DO, UMB or LTE wireless access protocol; however, in actual implementations, thesemobile nodes106 may be configured to support any wireless access protocol.
• One or more of thesemobile nodes106 may be configured to create in its vicinity an ad-hoc network based on the same or different wireless access protocol used to access the WWAN104. By way of example, amobile node106 may support a UMB wireless access protocol with a WWAN, while providing an IEEE 802.11 access point formobile nodes108 that cannot directly access a WWAN. IEEE 802.11 denotes a set of Wireless Local Access Network (WLAN) standards developed by the IEEE 802.11 committee for short-range communications (e.g., tens of meters to a few hundred meters). Although IEEE 802.11 is a common WLAN wireless access protocol, other suitable protocols may be used.
• Amobile node106 that may be used to provide an access point for anothermobile node108 will be referred to herein as a “mobile service provider.” Amobile node108 that may use an access point of amobile service provider106 will be referred to herein as a “mobile client.” A mobile node, whether amobile service provider106 or amobile client108, may be a laptop computer, a mobile telephone, a personal digital assistant (PDA), a mobile digital audio player, a mobile game console, a digital camera, a digital camcorder, 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.
• Themobile service provider106 may extend its wireless broadband Internet access service tomobile clients108 that would otherwise not have Internet access. Aserver110 may be used as an “exchange” to enablemobile clients108 to purchase unused bandwidth frommobile service providers106 to access, for example, theInternet102 acrossWWANs104.
• Amobile service provider106, aserver110, and one or moremobile clients108 may establish a network that is an ad-hoc heterogeneous wireless network. By way of example, a heterogeneous wireless network may include at least two types of wireless networks (e.g., a WWAN and a WLAN). By way of example, an ad-hoc network may be a network whose specific configuration may change from time to time or from the formation of one network to the next. The network configuration is not pre-planned prior to establishing the network. Examples of configurations for an ad-hoc network may include a configuration as to which members are to be in the network (e.g., which mobile service provider, which server, and/or which mobile client(s) are to be included in a network), a configuration as to the geographic locations of a mobile service provider and mobile client(s), and a configuration as to when and how long a network is to be established.
• In one example of an exchange,mobile clients108 register with theserver110. Once registered, amobile client108 may search for availablemobile service providers106 when Internet access is desired. When themobile client108 detects the presence of one or moremobile service providers106, it may select amobile service provider106 to initiate a session with based on various parameters such as bandwidth, Quality of Service (QoS) and cost. Another parameter that may be used by themobile client108 to select amobile service provider106 is availability in terms of time. By way of example, a mobile subscriber in an airport may turn on his mobile node (e.g., a laptop computer or a mobile telephone) and use it as amobile service provider108 for 30 minutes as he awaits his flight. Amobile client108 requiring access to theInternet102 for 45 minutes may choose not to select thismobile service provider106 even if themobile service provider108 can provide adequate bandwidth with good QoS. Anothermobile client108, however, requiring Internet access for 15 minutes, may select thismobile service provider106 because of its bandwidth and QoS. In any event, once amobile client108 selects amobile service provider106, a session may be established based on the parameters negotiated be the two (e.g., bandwidth, QoS, duration of the session, etc.). A link encryption key may be established between themobile client108 and themobile service provider106 during the establishment of the session. A Secured Socket Layer Virtual Private Network (SSL VPN) session may be established between themobile client108 and theserver110. The transport layer ports may be kept in the open and not encrypted to provide visibility for the network address translation functionality at themobile service provider106. In this example, all Internet traffic is routed through theserver110 via a client-server tunnel112 to provide security.
• In some telecommunication systems, once amobile client108 has gained access to theInternet102, it listens for othermobile service providers106 and measures the signal strength of themobile service providers106 it can hear. Themobile client108 uses these measurements to create an active list. The active list is a list ofmobile service providers106 that can provide service to themobile client108. Themobile client108 will continue to measure the signal strength of othermobile service providers106 and may add or removemobile service providers106 from the active list as the configuration of the ad-hoc network changes.
• One function of the active set is to allow themobile client108 to quickly switch betweenmobile service providers106 while maintaining the current session with theserver110. Themobile client108 may consider a handoff to anothermobile service provider106 based on any number of factors. These factors may include, by way of example, the inability of themobile service provider106 to provide the bandwidth or QoS negotiated at the beginning of the session. Alternatively, themobile service provider106 may not be able to provide Internet access to themobile client108 for the entire duration of the session. It would not be uncommon for a mobile subscriber on amobile service provider106 that negotiates a 30 minute session with amobile client108 to leave the vicinity 15 minutes into the session for whatever reason. In that event, themobile client108 would need to select a new mobile service provider from the active list for handoff. Theserver110 uses the active list to pre-authenticate other mobile service providers for handoff during the session between themobile client108 and the currentmobile service provider106. By pre-authenticating themobile service provider106 in the active list before themobile service provider106 currently serving themobile client108 goes down, the time required to handoff themobile client108 can be reduced.
• The term “pre-authenticating” as used herein means authenticating a targetmobile service106 provider for handoff prior to receiving a message from themobile service provider106 currently serving themobile client108 relating to the unavailability of the currentmobile service provider106. The message may provide notification to theserver110 that the currentmobile service provider106 has gone down and a hard handoff must be performed to anothermobile service provider106 if the session between themobile client108 and theserver110 is to be maintained. Alternatively, the message may provide notification to theserver110 that the currentmobile service provider106 will be going down shortly, or that it can no longer provide themobile client108 with the service agreed upon (e.g., QoS, bandwidth, etc.). This provides theserver110 with the option of enabling a soft handoff of themobile client108 to anothermobile service provider106.
• Pre-authentication includes provisioning, prior to handoff, a potentialnew service provider106 and amobile client108 with encryption/decryption keys that may be needed for communication between the potentialnew service provider106 and themobile client108.
• Pre-authentication also includes provisioning, prior to handoff, thecurrent service provider106 and thenew service provider106 with encryption/decryption keys that may be needed for communication between thecurrent service provider106 and thenew service provider106.
• Pre-authentication also includes authorization of communication between the potentialnew service provider106 and thecurrent service provider106. It also includes authorization of communication between the potentialnew service provider106 and themobile client108.
• FIG. 2 is a simplified block diagram illustrating an example of a handoff in a telecommunications system. In this example, themobile client108 is being handed off from a currentmobile service provider106₁to atarget service provider106₂. Apersistent tunnel112 between the twomobile service providers106₁,106₂is used to maintain the mobile client's session with theserver110 during handoff. Data packets received by the currentmobile service provider106₁during handoff may be forwarded to the targetmobile service provider106₂through thetunnel112. Alternatively, or in addition to, the data packets received by thecurrent service provider106₁may be forwarded to the targetmobile service provider106₂directly over awireless link114 between the two as shown inFIG. 2, or through another mobile service provider (not shown).
• Themobile client108 may have an IPv4, IPv6, or other suitable address that is used by theserver110 to maintain the session. The address may be provided to themobile client108 by theserver110 or one of themobile service providers106 in the telecommunications network100 (seeFIG. 1). Alternatively, the address may be stored on themobile client108. In at least one configuration, the address may be a MobileIP address.
• The tunneling anchor is shown inFIG. 2 as a server. However, the tunneling anchor may be any suitable entity or distributed across multiple entities in thetelecommunications system100. The tunneling anchor may be coupled to theInternet102 as shown inFIG. 2 or located elsewhere. By way of example, the tunneling anchor may be located anywhere on theInternet102 or within the network operator's infrastructure. Those skilled in the art will be readily able to determine the optimal implementation of the tunneling anchor for any particular application based on the performance requirements, the overall design constraints imposed on the system, and/or other relevant factors.
• FIG. 3 is a call flow diagram illustrating an example of the authentication process for handoff. For clarity of presentation, various signaling for themobile service providers106 andclients108 to authenticate theserver110 and register with theserver110 will be omitted.
• Instep302, a connection may be initiated by amobile service provider106₁with theserver110 when themobile service provider106₁is mobile and desires to provide service. Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS) may be used for Authentication, Authorization and Accounting (AAA) and secure session establishment for this connection. Instep304, a connection may be initiated by amobile client108 with the mobile service provider106₁(hereinafter referred to as the “current mobile service provider”) when themobile client108 requires Internet access. EAP-TTLS may also be used for AAA and secure session establishment. In particular, themobile service provider106₁sends the mobile client's credentials to theserver110 for EAP-AAA authentication. The EAP-TTLS authentication response from theserver110 is then used to generate a master shared key. Subsequently, a link encryption key may be established between the currentmobile service provider106₁and themobile client108. A SSL VPN session may then be established, instep306, between themobile client108 and theserver110.
• It should be noted that information flow may be encrypted using encryption/decryption keys between any pair of nodes (where the nodes comprise theserver110, thecurrent service provider106₁, thetarget service provider106₂, and the mobile client108). Such encryption/decryption keys can be set up in the system when nodes in the system connect with the server. Typically symmetric key cryptography such as using AES may be used for such encryption or decryption for message-flow between any pair of nodes in the system.
• Instep308, themobile client108 provides the active list to theserver110. Alternatively, themobile client108 can send a report identifying mobile service providers that it can hear accompanied by data indicating the signal strength measurements for each. Theserver110 may use the report to generate the active list at its end.
• Theserver110 pre-authenticates one or more of the mobile service providers in the active list. During pre-authentication of atarget service provider106₂with aclient108, theserver110 provisions the target-service provider106₂with an encryption/decryption key for communication with theclient108. The server may additionally provision thetarget service provider106₂with an encryption/decryption key for communication with thecurrent service provider106₁. Theserver110 also provisions theclient108 with the encryption/decryption key to communicate with thetarget service provider106₂. Thecurrent service provider106₁can be provisioned by theserver110, either at the time of a handoff or anytime earlier, with the encryption/decryption key to communicate with thetarget service provider106₂. The exact number of mobile service providers in the active list that are pre-authenticated may depend on the admission control policies implemented by theserver110. By way of example, theserver110 may limit the number of mobile service providers at a given location if it determines that additional mobile service providers will adversely affect performance in the WWAN. Additional constraints may be imposed by the WWAN operators that may not want its mobile subscribers to provide service in a given geographic location depending on various network constraints. In any event, theserver110 pre-authenticates one or more mobile service providers by providing each of them with a key to encrypt the data link between themobile client108 and the newmobile service provider106 following handoff. InFIG. 3, theserver110 is shown, instep310, providing the key to one mobile service provider106₂(hereinafter referred to as the target mobile service provider). Instep312, theserver110 also provides the key to themobile client108 through the VPN tunnel.
• Instep314, themobile client108 sends a message to the currentmobile service provider106 requesting a handoff to an alternate service provider. Step314 is optional and is indicated by a dotted line from the client to the mobile service provider.
• Instep316, the currentmobile service provider106, sends a message to theserver110 requesting a handoff. Such a message is tagged with an identifier that indicates that the handoff was initiated by themobile client108, or that it was initiated by the currentmobile service provider106₁. The message may be created at the currentmobile service provider106₁as a consequence of the current mobile service provider's unavailability to continue to provide service to the mobile client. Alternatively, the message could have been created at the mobile client (step314), which needs to be sent by the currentmobile service provider106, to theserver110. For a handoff that is initiated directly by the server,step316 is optional. For a handoff that is initiated by themobile client108, or by themobile service provider106₁, instep318, theserver110 responds to step316 by sending a message back to currentmobile service provider106₁authorizing handoff. Alternatively, step318 could be a message from the server initiating a handoff, in the absence of amessage316 from the currentmobile service provider106₁. The message sent to the currentmobile service provider106₁may identify the targetmobile service provider106₂for handoff, or alternatively, allow themobile client108 to make the decision. In the latter case, the user on themobile client108 selects a target mobile service provider for handoff in accordance with any admission control policy constraints imposed by theserver110. Theserver110 may also provide themobile client108 with a quality metric for each mobile service provider available to the mobile client. This quality metric may be used to assist the user on amobile client108 to select a new mobile service provider for handoff. In the example shown inFIG. 3, themobile client108 selects the targetmobile service provider106₂for handoff.
• Instep320, the server may optionally send a message regarding the handoff to one or moretarget service providers106₂. Instep322, the handoff message received from theserver110 is sent by thecurrent service provider106, to themobile client108.
• In step324, themobile client108 establishes a connection with the targetmobile service provider106₂by sending a message encrypted with a key. Since the targetmobile service provider106₂received the same key during the pre-authentication process, it can decrypt the message and establish a session with themobile client108 to complete the handoff. The targetmobile service provider106₂may also send a message back to theserver110, in step326, to signify that the handoff has been successfully completed.
• Packets that have left themobile client108 may be in transit to the currentmobile service provider106₁, or could be at the currentmobile service provider106₁. These packets need to continue to be supported by the currentmobile service provider106₁. Other packets that have left themobile client108 may be in transit to theserver110, or may be waiting atserver110 for further processing, or may be in transit to their final destination beyond the tunneling server. Future packets that leave themobile client108 are sent to the targetmobile service provider106₂after handoff. Packets that are destined to themobile client108 may be waiting at the server. Such packets are sent to the targetmobile service provider106₂after handoff. Other packets destined for themobile client108 may be in transit to the currentmobile service provider106₁, or may be waiting at the currentmobile service provider106₁, or may be in transit from the current service provider to themobile client108, and the currentmobile service provider106₁needs to continue to support such packets to be delivered to themobile client108. The delivery of such packets can be done over a wireless link or a multi-hop wireless path between the currentmobile service provider106₁and the targetmobile service provider106₂. Alternatively, such packets can be delivered by the currentmobile service provider106₁to theserver110, which then sends them through the targetmobile service provider106₂. Messages between the currentmobile service provider106₁and the targetmobile service provider106₂may be exchanged either through theserver110, or over a wireless link or multi-hop wireless path between the service providers.
• FIG. 4 illustrates an example of a hardware implementation for a server. Theserver110 may be a centralized server or a distributed server. A centralized server may be a dedicated server or integrated into another network-related entity, such as a desktop or laptop computer, mainframe, or other suitable entity. A distributed server may be distributed across multiple servers and/or one or more network-related entities, such as a desktop or laptop computer, mainframe, or some other suitable entity. In at least one configuration, the server may be integrated, either in whole or part, into one or more mobile service providers.
• Theserver110 is shown with anetwork interface402, which may support a wired and/or wireless connection to theInternet102. Thenetwork interface402 may be used to implement the physical layer by providing the means to transmit and receive data in accordance with the physical and electrical specifications required to interface to the transmission medium. Thenetwork402 may also be configured to implement the lower portion of the data link layer by managing access to the transmission medium.
• Theserver110 is also shown with aprocessing system404 that provides various functions, including session management for mobile service providers and clients, pre-authentication of mobile service providers targeted for handoff, handoff of mobile clients from one mobile service providers to another, and data tunneling for mobile clients. Theprocessing system404 is shown separate from thenetwork interface402, however, as those skilled in the art will readily appreciate, thenetwork interface402, or any portion thereof, may be integrated into theprocessing system404.
• FIG. 5 illustrates an example of a hardware implementation for a processing system in a server. In this example, theprocessing system404 may be implemented with a bus architecture represented generally bybus502. Thebus502 may include any number of interconnecting buses and bridges depending on the specific application of theprocessing system404 and the overall design constraints. The bus links together various circuits including aprocessor504 and machine-readable media506. Thebus502 may also link various other circuits such as timing sources, peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further. Anetwork adapter508 provides an interface between the network interface402 (seeFIG. 4) and thebus502.
• Theprocessor504 is responsible for managing the bus and general processing, including the execution of software stored on the machine-readable media506. Theprocessor504 may be implemented with one or more general-purpose and/or special-purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuitry that can execute software. Software shall be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Machine-readable media may include, by way of 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, magnetic disks, optical disks, hard drives, or any other suitable storage medium, or any combination thereof.
• In the hardware implementation illustrated inFIG. 5, the machine-readable media506 is shown as part of theprocessing system404 separate from theprocessor504. However, as those skilled in the art will readily appreciate, the machine-readable media506, or any portion thereof, may be external to theprocessing system404. By way of example, the machine-readable media506 may include a transmission line, a carrier wave modulated by data, and/or a computer product separate from the server, all which may be accessed by theprocessor504 through thenetwork adapter508. Alternatively, or in addition to, the machinereadable media506, or any portion thereof, may be integrated into theprocessor504, such as the case may be with cache and/or general register files.
• Theprocessing system404 may be configured as a general-purpose processing system with one or more microprocessors providing the processor functionality and external memory providing at least a portion of the machine-readable media506, all linked together with other supporting circuitry through an external bus architecture. Alternatively, theprocessing system404 may be implemented with an ASIC (Application Specific Integrated Circuit) with theprocessor504, thenetwork adapter508, supporting circuitry (not shown), and at least a portion of the machine-readable media506 integrated into a single chip, or with one or more FPGAs (Field Programmable Gate Array), PLDs (Programmable Logic Device), controllers, state machines, gated logic, discrete hardware components, or any other suitable circuitry, or any combination of circuits that can perform the various functionality described throughout this disclosure. Those skilled in the art will recognize how best to implement the described functionality for theprocessing system404 depending on the particular application and the overall design constraints imposed on the overall system.
• The machine-readable media506 is shown with a number of software modules. The software modules include aprotocol stack module509, apre-authentication module510, asession manager module512, atunneling module514, and ahandoff module516. These software modules include instruction sets that when executed by theprocessor504 cause theprocessing system402 to carry out the process steps as shown and described inFIGS. 1-3. Each software module may reside in a single storage device or distributed across multiple memory devices. By way of example, a software module may be loaded into RAM from a hard drive when a triggering event occurs (e.g., a mobile node decides to become a mobile service provider). During execution of the software module, theprocessor504 may load some of the instructions into cache to increase access speed. One or more cache lines may then be loaded into a general register file for execution by theprocessor504. When referring to the functionality of a software module below, it will be understood that such functionality is implemented by theprocessor504 when executing instructions from that software module.
• Theprotocol stack module509 may be used to implement the protocol architecture, or any portion thereof, for the server. In the implementation described thus far, theprotocol stack module509 is responsible for implementing several protocol layers running on top of the data link layer implemented by the network interface402 (seeFIG. 4). By way of example, theprotocol stack module509 may be used to implement the upper portion of the data link layer by providing flow control, acknowledgement, and error recovery. Theprotocol stack module509 may also be used to implement the network layer by managing source to destination data packet transfer, as well as the transport layer by providing transparent transfer of data between end users. Although described as part of the processing system, theprotocol stack module509, or any portion thereof, may be implemented by thenetwork interface402.
• Thesession manager module512 may be used by the server to maintain sessions with the mobile service providers and clients.
• Thepre-authentication module510 may be used to pre-authenticate mobile service providers for handoff. Thepre-authentication module510 may receive from a mobile client a list of mobile service providers in the coverage region for the mobile client and use the list to identify the mobile service provider for pre-authentication.
• Thehandoff module516 may be used to enable the handoff of a mobile client between mobile service providers while thesession manager module512 maintains the session with the mobile client. Thehandoff module516 may enable handoff by authenticating the mobile client for the target service provider prior to handoff and provisioning the target service provider and the mobile client with a key to support an encrypted link between the two following handoff. The handoff may be enabled in response to various messages, including by way of example, a message indicating that the mobile client has selected the target service provider, a message indicating the unavailability of the service provider currently serving the mobile client, or a request from the mobile client for a handoff. The handoff may be a hard or soft handoff. When the handoff is complete, an indication may be received by thehandoff module516. Thehandoff module516 may further provide a method for forwarding packets received by the current service provider to the target service provider following handoff through a tunnel between the server and the target service provider, a wireless link, another mobile service provider, or by some other suitable means.
• Thetunneling module514 may be used by the server to maintain tunnels with mobile service providers and clients. Thetunneling module514 may also be used to maintain a tunnel with a mobile client during handoff from a current mobile service provider to a target service provider. In the disclosed configuration, the tunneling is performed by a module in the server. However, in other configurations, the tunneling of data between the Internet and the nodes (i.e., mobile service providers and clients) may be located elsewhere in the network.
• FIG. 6 is a simplified block diagram illustrating an example of the functionality of a mobile service provider. Themobile service provider106 has the ability to bridge wireless links over homogeneous or heterogeneous wireless access protocols. This may be achieved with a WWAN network adapter602 that supports a wireless access protocol for a WWAN to theInternet102, and aWLAN network adapter604 that provides a wireless access point formobile clients108. By way of example, the WWAN network adapter602 may include a transceiver function that supports EV-DO for Internet access through a WWAN, and theWLAN network adapter604 may include a transceiver function that provides an 802.11 access point formobile clients108. Eachnetwork adapter602,604 may be configured to implement the physical layer by demodulating wireless signals and performing other radio frequency (RF) front end processing. Eachnetwork adapter602,604 may also be configured to implement the data link layer by managing the transfer of data across the physical layer.
• Themobile service provider106 is shown with a filtered interconnection andsession monitoring module606. Themodule606 provides filtered processing of content frommobile clients108 so that the interconnection between the ad-hoc wireless links to the WWAN network interface602 is provided only tomobile clients108 authenticated and permitted by the server to use the WWAN network. Themodule606 also maintains tunneled connectivity between the server and the authenticatedmobile clients108.
• Themobile service provider106 also includes aservice provider application608 that (1) enables themodule606 to provide ad-hoc services tomobile clients108, and (2) supports WWAN or Internet access to a mobile subscriber or user of themobile service provider106. The latter function is supported by auser interface612 that communicates with the WWAN network adapter602 through themodule606 under control of theservice provider application608. Theuser interface612 may include a keypad, display, speaker, microphone, joystick, and/or any other combination user interface devices that enable a mobile subscriber or user to access theWWAN104 or the Internet102 (seeFIG. 1).
• As discussed above, theservice provider application608 also enables themodule606 to provide ad-hoc services tomobile clients108. Theservice provider application608 maintains a session with theserver110 to exchange custom messages with the server. In addition, theservice provider application608 also maintains a separate session with eachmobile client108 for exchanging custom messages between theservice provider application608 and themobile client108. Theservice provider application608 provides information on authenticated and permitted clients to the filtered interconnection andsession monitoring module606. The filtered interconnection andsession monitoring module608 allows content flow for only authenticated and permittedmobile clients108. The filtered interconnection andsession monitoring module606 also optionally monitors information regarding content flow related tomobile clients108 such as the amount of content outbound from the mobile clients and inbound to the mobile clients, and regarding WWAN and WLAN network resource utilization and available bandwidths on the wireless channels. The filtered interconnection andsession monitoring module606 can additionally and optionally provide such information to theservice provider application608. Theservice provider application608 can optionally act on such information and take appropriate actions such as determining whether to continue maintaining connectivity with themobile clients108 and with the server, or whether to continue to provide service. It should be noted that the functions described inmodules606 and608 can be implemented in any given platform in one or multiple sets of modules that coordinate to provide such functionality at themobile service provider106.
• When themobile service provider106 decides to provide these services, theservice provider application608 sends a request to theserver110 for approval. Theservice provider application608 requests authentication by theserver110 and approval from theserver110 to provide service to one or moremobile clients108. Theserver110 may authenticate themobile service provider106 and then determine whether it will grant the mobile service provider's request. As discussed earlier, the request may be denied if the number of mobile service providers in the same geographic location is too great or if the WWAN operator has imposed certain constraints on themobile service provider106.
• Once themobile service provider106 is authenticated, theservice provider application608 may advertise an ad-hoc WLAN Service Set Identifier (SSID). Interestedmobile clients108 may associate with the SSID to access themobile service provider106. Theservice provider application608 may then authenticate themobile clients108 with theserver110 and then configure the filtered interconnection andsession monitoring module606 to connect themobile clients108 to the server. During the authentication of amobile client108, theservice provider application608 may use an unsecured wireless link.
• Theservice provider application608 may optionally choose to move amobile client108 to a new SSID with a secure link once themobile client108 is authenticated. In such situations, theservice provider application608 may distribute the time it spends in each SSID depending on the load that it has to support for existing sessions withmobile clients108.
• Theservice provider application608 may also be able to determine whether it can support amobile client108 before allowing themobile client108 to access a network. Resource intelligence that estimates the drain on the battery power and other processing resources that would occur by accepting amobile client108 may assist in determining whether theservice provider application608 should consider supporting a newmobile client108 or accepting a handoff of thatmobile client108 from anothermobile service provider106.
• Theservice provider application608 may admitmobile clients108 and provide them with a certain QoS guarantee, such as an expected average bandwidth during a session. Average throughputs provided to eachmobile client108 over a time window may be monitored. Theservice provider application608 may monitor the throughputs for all flows going through it to ensure that resource utilization by themobile clients108 is below a certain threshold, and that it is meeting the QoS requirement that it has agreed to provide to themobile clients108 during the establishment of the session.
• Theservice provider application608 may also provide a certain level of security to the wireless access point by routing content through the filtered interconnection andsession monitoring module606 without being able to decipher the content. Similarly, theservice provider application608 may be configured to ensure content routed between the user interface610 and theWWAN104 via themodule606 cannot be deciphered bymobile clients108. Theservice provider application608 may use any suitable encryption technology to implement this functionality.
• Theservice provider application608 may also maintain a time period for amobile client108 to access a network. The time period may be agreed upon between theservice provider application608 and themobile client108 during the initiation of the session. If theservice provider application608 determines that it is unable to provide themobile client108 with access to the network for the agreed upon time period, then it may notify both the server and themobile client108 regarding its unavailability. This may occur due to energy constraints (e.g., a low battery), or other unforeseen events. The server may then consider a handoff of the mobile client to another mobile service provider, if there is such a mobile service provider in the vicinity of themobile client108. Theservice provider application608 may support the handoff of themobile client108.
• Theservice provider application608 may also dedicate processing resources to maintain a wireless link or limited session withmobile clients108 served by other mobile service providers. This may facilitate the handoff ofmobile clients108 to themobile service provider106.
• Theservice provider application608 may manage themobile client108 generally, and the session specifically, through theuser interface612. Alternatively, theservice provider application608 may support a seamless operation mode with processing resources being dedicated to servicingmobile clients108. In this way, themobile client108 is managed in a way that is transparent to the mobile subscriber. The seamless operation mode may be desired where the mobile subscriber does not want to be managingmobile clients108, but would like to continue generating revenue by sharing bandwidth withmobile clients108.
• Turning now to the mobile client, a TLS session may be used by themobile client108 to register with theserver110. Once registered, themobile client108 may search for availablemobile service providers106. When themobile client108 detects the presence of one or moremobile service providers106, it may initiate a session using EAP-TTLS with amobile service provider106 based on parameters such as the available bandwidth that themobile service provider106 can support, the QoS metric of themobile service provider106, and the cost of the service advertised. As described earlier, a link encryption key may be established between themobile client108 and themobile service provider106 during the establishment of the session. An SSL VPN session may be established between themobile client108 and theserver110 so that all traffic between the two is encrypted. The transport layer ports may be kept in the open and not encrypted to provide visibility for the network address translation functionality at themobile service provider106.
• The handoff of themobile client108 may be performed in a variety of ways. In one configuration, themobile client108 may maintain a limited session with multiplemobile service providers106, while using onemobile service provider106 to access the Internet. As described earlier, this approach may facilitate the handoff process. In an alternative configuration, themobile client108 may consider a handoff only when necessary. In this configuration, themobile client108 may maintain an active list ofmobile service providers106 in its vicinity for handoff. Themobile client108 may select amobile service provider106 for handoff from the active list when the currentmobile service provider106 needs to discontinue its service. When handoff is not possible, amobile client108 may need to reconnect through a differentmobile service provider106 to access the Internet. Persistence of the tunnel between the mobile client and the server can enable a soft handoff of a mobile client from one service provider to another service provider.
• If the bandwidth needs of amobile client108 are greater than the capabilities of the availablemobile service providers106, then themobile client108 may access multiplemobile service providers106 simultaneously. Amobile client108 with multiple transceivers could potentially access multiplemobile service providers106 simultaneously using a different transceiver for eachmobile service provider106. If the same wireless access protocol can be used to access multiplemobile service providers106, then different channels may be used. If themobile client108 has only one transceiver available, then it may distribute the time that it spends accessing eachmobile service provider106.
• Those of skill in the art would 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 understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. 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 aspects shown herein, but is 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” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) 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. No claim element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”

Claims (66)

1. A server, comprising:

a processing system configured to maintain a session with a mobile client through a first mobile service provider, the processing system being further configured to pre-authenticate a second mobile service provider for handoff, and wherein the processing system is further configured to enable the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.

2. The server ofclaim 1 wherein the processing system is further configured to authenticate the mobile client for the second service provider prior to the handoff of the mobile client to the second service provider.

3. The server ofclaim 1 wherein the processing system is further configured to provision the second service provider and the mobile client with a key to support an encrypted link between the mobile client and the second mobile service provider following the handoff.

4. The server ofclaim 1 wherein the processing system is further configured to receive from the mobile client a list of mobile service providers in the coverage region for the mobile client, the processing system being further configured to use the list to identify the second mobile service provider for pre-authentication.

5. The server ofclaim 1 wherein the processing system is further configured to enable the handoff in response to a message indicating that the mobile client has selected the second mobile service provider for the handoff.

6. The server ofclaim 1 wherein the processing system is further configured to enable the handoff in response to a message relating to the unavailability of the first mobile service provider.

7. The server ofclaim 1 wherein the processing system is further configured to enable the handoff in response to a message relating to a request from the mobile client for a handoff from the first mobile service provider to the second mobile service provider.

8. The server ofclaim 1 wherein the processing system is further configured to initiate the handoff of the mobile client from the first mobile service provider to the second mobile service provider.

9. The server ofclaim 1 wherein the processing system is further configured to enable the handoff by providing a request to the first mobile service provider to handoff the mobile client, the processing system being further configured to receive from the second mobile service provider an indication when the handoff is complete.

10. The server ofclaim 1 wherein the processing system is further configured to support a tunnel with the mobile client.

11. The server ofclaim 10 wherein the processing system is further to maintain the tunnel with the mobile client during the handoff of the mobile client from the first mobile service provider to the second mobile service provider.

12. The server ofclaim 10 wherein the processing system is further configured to forward at least some packets received by the first mobile service provider from the mobile client through the tunnel to the second mobile service provider.

13. The server ofclaim 1 which the processing system is further configured to support forwarding of at least some packets from the first mobile service provider to the second mobile service provider over a wireless link between the first and second service providers.

14. The server ofclaim 13 wherein the processing system is further configured to support the forwarding of the packets from the first mobile service provider to the second mobile service provider through another mobile service provider.

15. The server ofclaim 1 wherein the processing system is further configured to provide an IPv4 or IPv6 address to the mobile client.

16. The server ofclaim 15 wherein the IPv4 or IPv6 address comprises a MobileIP address.

17. The server ofclaim 1 wherein the handoff comprises a hard handoff.

18. The server ofclaim 1 wherein the handoff comprises a soft handoff.

19. A server, comprising:

means for maintaining a session with a mobile client through a first mobile service provider;

means for pre-authenticating a second mobile service provider for handoff; and

means for enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.

20. The server ofclaim 19 wherein the means for pre-authenticating the second mobile service provider comprises means for providing the second mobile service provider with a key to support an encrypted link between the mobile client and the second mobile service provider following the handoff.

21. The server ofclaim 20 further comprising means for providing the key to the mobile client.

22. The server ofclaim 19 further comprising means for receiving from the mobile client a list of mobile service providers in the coverage region for the mobile client and means for using the list to identify the second mobile service provider for pre-authentication.

23. The server ofclaim 19 wherein the means for enabling the handoff comprises means for enabling the handoff in response to a message indicating that the mobile client has selected the second mobile service provider for the handoff.

24. The server ofclaim 19 wherein the means for enabling the handoff comprises means for enabling the handoff in response to a message relating to the unavailability of the first mobile service provider.

25. The server ofclaim 19 wherein the means for enabling the handoff comprises means for providing a request to the first mobile service provider to handoff the mobile client and means for receiving from the second mobile service provider an indication when the handoff is complete.

26. The server ofclaim 19 wherein the means for maintaining a session with the mobile client further comprises means for supporting a tunnel with the mobile client.

27. The server ofclaim 26 wherein the means for supporting the tunnel is configured to maintain the tunnel with the mobile client during the handoff of the mobile client from the first mobile service provider to the second mobile service provider.

28. The server ofclaim 26 further comprising means for forwarding at least some packets received by the first mobile service provider from the mobile client through the tunnel to the second mobile service provider.

29. The server ofclaim 19 means for maintaining a session with the mobile client further comprises means for supporting forwarding of at least some packets from the first mobile service provider to the second mobile service provider over a wireless link between the first and second service providers.

30. The server ofclaim 29 wherein the means for supporting the forwarding of packets is configured to support the forwarding of the packets from the first mobile service provider to the second mobile service provider through another mobile service provider.

31. The server ofclaim 19 further comprising means for providing an IPv4 or IPv6 address to the mobile client.

32. The server ofclaim 31 wherein the IPv4 or IPv6 address comprises a MobileIP address.

33. The server ofclaim 19 wherein the handoff comprises a hard handoff.

34. The server ofclaim 19 wherein the handoff comprises a soft handoff.

35. A method of providing service from a server, comprising:

maintaining a session with a mobile client through a first mobile service provider;

pre-authenticating second mobile service provider for handoff; and

enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.

36. The method ofclaim 35 wherein the second mobile service provider is pre-authenticated by providing the second mobile service provider with a key to support an encrypted link between the mobile client and the second mobile service provider following the handoff.

37. The method ofclaim 36 further comprising providing the key to the mobile client.

38. The method ofclaim 35 further comprising receiving from the mobile client a list of mobile service providers in the coverage region for the mobile client and using the list to identify the second mobile service provider for pre-authentication.

39. The method ofclaim 35 wherein the handoff is enabled in response to a message indicating that the mobile client has selected the second mobile service provider for the handoff.

40. The method ofclaim 35 wherein the handoff is enabled in response to a message relating to the unavailability of the first mobile service provider.

41. The method ofclaim 35 wherein the handoff is enabled by providing a request to the first mobile service provider to handoff the mobile client and receiving from the second mobile service provider an indication when the handoff is complete.

42. The method ofclaim 35 wherein the session is maintained by supporting a tunnel with the mobile client.

43. The method ofclaim 42 wherein the tunnel with the mobile client is supported during the handoff of the mobile client from the first mobile service provider to the second mobile service provider.

44. The method ofclaim 42 further comprising forwarding at least some packets received by the first mobile service provider from the mobile client through the tunnel to the second mobile service provider.

45. The method ofclaim 35 further comprising supporting forwarding of at least some packets from the first mobile service provider to the second mobile service provider over a wireless link between the first and second service providers.

46. The method ofclaim 45 wherein the forwarding of packets is supported by forwarding the packets from the first mobile service provider to the second mobile service provider through another mobile service provider.

47. The method ofclaim 35 further comprising providing an IPv4 or IPv6 address to the mobile client.

48. The method ofclaim 47 wherein the IPv4 or IPv6 address comprises a MobileIP address.

49. The method ofclaim 35 wherein the handoff comprises a hard handoff.

50. The method ofclaim 35 wherein the handoff comprises a soft handoff.

51. A machine-readable medium comprising instructions executable by a processing system in a server, the instructions comprising code for:

maintaining a session with a mobile client through a first mobile service provider;

pre-authenticating a second mobile service provider for handoff; and

enabling the handoff of the mobile client from the first mobile service provider to the second mobile service provider while maintaining the session with the mobile client.

52. The machine-readable medium ofclaim 51 wherein the code for pre-authenticating the second mobile service provider is configured to provide the second mobile service provider with a key to support an encrypted link between the mobile client and the second mobile service provider following the handoff.

53. The machine-readable medium ofclaim 52 wherein the instructions further comprise code for providing the key to the mobile client.

54. The machine-readable medium ofclaim 51 wherein the instructions further comprise code for receiving from the mobile client a list of mobile service providers in the coverage region for the mobile client and using the list to identify the second mobile service provider for pre-authentication.

55. The machine-readable medium ofclaim 51 wherein the code for enabling the handoff is configured to enable the handoff in response to a message indicating that the mobile client has selected the second mobile service provider for the handoff.

56. The machine-readable medium ofclaim 51 wherein the code for enabling the handoff is configured to enable the handoff in response to a message relating to the unavailability of the first mobile service provider.

57. The machine-readable medium ofclaim 51 wherein the code for enabling the handoff is configured to provide a request to the first mobile service provider to handoff the mobile client and receive from the second mobile service provider an indication when the handoff is complete.

58. The machine-readable medium ofclaim 51 wherein the code for maintaining a session with the mobile client is configured to support a tunnel with the mobile client.

59. The machine-readable medium ofclaim 58 wherein the code for maintaining a session is further configured to maintain the tunnel with the mobile client during the handoff of the mobile client from the first mobile service provider to the second mobile service provider.

60. The machine-readable medium ofclaim 58 wherein the instructions further comprise code for forwarding at least some packets received by the first mobile service provider from the mobile client through the tunnel to the second mobile service provider.

61. The machine-readable medium ofclaim 51 wherein the instructions further comprise code for supporting forwarding of at least some packets from the first mobile service provider to the second mobile service provider over a wireless link between the first and second service providers.

62. The machine-readable medium ofclaim 61 wherein the code for supporting forwarding of packets is configured to support the forwarding of the packets from the first mobile service provider through the second mobile service provider through another mobile service provider.

63. The machine-readable medium ofclaim 51 wherein the instructions further comprise code for providing an IPv4 or IPv6 address to the mobile client.

64. The machine-readable medium ofclaim 63 wherein the IPv4 or IPv6 address comprises a MobileIP address.

65. The machine-readable medium ofclaim 51 wherein the handoff comprises a hard handoff.

66. The machine-readable medium ofclaim 51 wherein the handoff comprises a soft handoff.

Images