Patent Application
20080069065
An exemplary form of the present invention will now be described by way of example only and with reference to the accompanying drawings, in which:
The current invention provides for a method of seamlessly roaming between multiple wireless local area networks (WLANs) using a single wireless network interface adaptor. In the specification the terms wireless network interface adapter, network adaptor, Wi-Fi adaptor and the like refer to a card or built-in hardware used to connect a computer or handheld device to a network, either wired or wireless as the context requires.
The invention will be described as practiced in a portable device that allows wireless connection to an internet based IP telephony service. Such a device may be a wireless IP phone that allows connection to the internet without a computer, or soft-phone software operating on a wireless portable computer or other device such as a PDA. IP telephony services use real-time internet protocols such as RTP to transmit audio or other multimedia content in discrete packets between users of IP phones or soft-phones in different locations or from an internet based IP phones or soft-phone to a phone connected to a public switched telephone network through a gateway. Those skilled in the art will appreciate that aspects of the invention may be practiced with other devices or computer systems that need to connect quasi-simultaneously to multiple WLANs or to roam between WLANs while maintaining a real-time connection to another device or computer in another part of the network or via the internet.
The exemplary embodiment of the invention is also described as practiced in a wireless environment based on the IEEE 802.11 standard, common referred to as a wireless fidelity or Wi-Fi network, and uses functionality provided for in that standard. This is not however intended to limit the scope of use or functionality of the invention. There are many other wireless networking standards such as Bluetooth, Wireless 1394, Hiperlan, Hiperlan/2, HomeRF, OpenAir and others. The skilled artisan will also appreciate that similar functionality may be available now or in the future or can otherwise be implemented in other current or future wireless networking standards. It is envisaged, for example, that as the popularity of Voice over Internet Protocol (VoIP) multimedia communication services increases wireless networking standards may be modified or developed to cater specifically for real-time communication system roaming requirements.
The exemplary embodiment of the invention uses the Session Initiation Protocol (SIP) Real-time Transport Protocol (RTP) for VoIP and also uses functionality provided for in that standard. This is also not intended to limit the scope of use or functionality of the invention. Similar functionality is also available in the Media Gateway Control Protocol (H.323) and other real-time IP standards. Again, it is envisaged that as the popularity of VoIP multimedia communications increases other real-time protocols may become available in which the invention can be practiced.
In the described exemplary embodiment of the invention functionality and procedures from IEEE 802.11 and SIPs are discussed and used. It is understood that these are well established public standards and full knowledge, functionality and use of the methods provided for within these standards is within the purview of those skilled in the art. A detailed description of any IEEE 802.11 and SIP methods is not necessary and not given.
In the exemplary environment of
The IEEE 802.11 standard covers only a single WLAN network. It violates the IEEE standard for one client (e.g. IP phone 100) associated with two APs belonging to the same network because, for example, it would be unclear whether a packet from the network targeted at the client should go through the first AP or the second AP. APs 111 and 112 of the exemplary environment belong to the same network and so IP phone 100 cannot simultaneously associated with both APs 111 and 112 for seamless roaming according to the current invention. Therefore, the next step 210 and is to check all APs in the roaming list to determine whether they belong to the same WLAN as the currently associated AP. One way to do this is to use IEEE 802.11i pre-authentication in which the IP-phone 100 sends a pre-authentication request through the currently associated AP 111 to each AP in the roaming list (in the present case is AP 112 and AP 121). Only APs belonging to the same network or subnet, in this case AP 112, will hear the pre-authentication request and respond. If no response is received to the pre-authentication request then it is assumed that the AP is on a different network or subnet and is it ok to roam to it. More generally, determining whether an APs in the roaming list can be done using any general packet sent to that AP as long as the packet has (1) as its immediate destination the currently associated AP, (2) as its final destination the AP in the roaming list being checked and (3) that the AP being checked will give some response back through the currently associated AP to the IP-phone 100.
The inventors do not believe that it violates the IEEE standard to simultaneously associate with two APs on a different subnet of the same network. For example, a one AP may be on a first subnet 10.1.2.xxx and a second AP may be on a second subnet 10.8.132.xxx or the same network. Routing between these two subnets takes place at the layer 3 router level instead of a layer 2 switch level and so conceptually two subnets can be considered as two independent networks under IEEE 802.11. For the purpose of the current explanation though it is assumed that APs 111 and 112 are within the same subnet.
The decision of which AP to roam to can be based on fixed or adaptive criteria such as signal strength of the APs, the rate of change of signal strength (which is an indicator of speed of movement of the IP phone 100), a list of preferred APs/WLANs (e.g. BSSID or ESSID) stored with the IP phone memory or the amount of traffic on the AP or WLAN. In the exemplary embodiment the decision is based on highest signal strength with a threshold value of −80 dbm, with APs with the same network or subnet as the current AP have preference. Thus, in the present case if AP 112, which is on the same WLAN, has a signal strength greater than −80 dBm it will have roaming preference. In this case simultaneous association with APs 111 and 112 would violate IEEE 802.11, but is also unnecessary. The IEEE 802.11i standard provides for hand-off between APs belonging to the same Extended Service Set Identifier (ESSID) and the same subnets. Using these protocols IP phone 100 simply hand-off communication to AP 112 once pre-authentication is complete (step 215). Pre-authentication may be done in step 210 when checking if the AP is on the same WLAN or subnet. Because pre-authentication with AP 112 is achieved while connected with AP 111 real-time data transfer is not materially affected by the hand off.
For the purpose of describing the seamless roaming of the current invention it is assumed that the signal strength of AP 111 and AP 112 are both below −80 dBm and so roaming must occur between AP 111 and AP 121, which are on different WLANs. During this roaming process, as will become apparent later, the IP phone 100 will have the original AP 111 periodically buffer the real-time protocol (RTP) data packets containing, amongst other things, call audio content. To accommodate the delay in packet delivery without detection by the user the first roaming step 220 is to dynamically increase the size of the playback jitter buffer to its maximum value and to marginally slow down audio playback by an amount that is generally undetectable in normal listening. This allows the phone 100 to buffer additional audio information for playback when RTP packets are being buffered by an AP and not received.
Turning to step 230, the invention then provides for the creation of virtual network interfaces in the phone for simultaneous association with current AP 111 and target AP 121. The current invention uses a variation on the method proposed by Chandra et al described earlier. Chandra et al use virtual drivers inserted in to network stack to simulate multiple network interfaces. However, each switch between networks is accompanied by transmission and reception of Authentication/Association Request and Responses. Therefore, the system proposed by Chandra et al is not a simultaneous association with multiple APs. Furthermore, the inventors tested a large number of APs and discovered that most clear out packets previously buffered for a wireless node upon receipt of an Authentication/Association Request from that node. Buffering of packets at the AP is used by the current invention and so Authentication/Association Requests cannot not be used when switching back and forth between APs in the current invention.
Referring briefly to
Having established multiple network interfaces we move to the next steps 240-270 which are to associate with the new AP 121, authenticate with any security system, e.g. WPA etc, implemented in the AP, get an IP address for the interface and trigger STUN or TURN server requests to obtain a public IP address for network address translation (NAT) or router traversal if required. These steps are well known in the art and details need not be given.
In step 280 the invention provides for the IP phone 100 to initiate a redirect of the RTP packet stream to its new IP address on second WLAN 120. In the exemplified embodiment this is done by sending a SIP re-INVITE message. The SIP protocol allows an INVITE to be sent during a current call stream to modify the dialog and parameters of the stream. An INVITE request sent within an existing call is known as a re-INVITE. After a re-INVITE is received by the other party's UA and acknowledgements dealt with further RTP packets will be sent to the new IP address contained in the re-INVITE message. When the RTP packets are received through the new virtual network interface step 290 is to disassociate with the old AP 111 and delete its virtual network interface. The final step 231 provided by the invention is to marginally speed up audio playback by an amount that is generally undetectable in normal listening. This will empty the jitter buffer which can then be reduced to it nominal operating size.
The basic data packet flow in the above method is schematically illustrated in
Certain aspects of the invention will now be described in more detail. The essence of the following discussion is to provide criteria for seamlessly roaming between two APs and/or WLANs. Two measurements can be used as indicators of how seamless roaming is. These are the number of RTP packets dropped during the procedure and the mount of jitter delay induced by the procedure. Target values established by the inventors are a maximum of 1 to 2 packets dropped and 60 ms to 120 ms jitter delay.
Auto-scanning utilities and methods provided with most wireless network interface adaptors are not intended to solve the seamless roaming problem, but rather are intended to scan and roam a mobile device from one AP to another AP with the simple aim of maintaining a TCP connection. Real-time communications are not considered. Depending on the configuration as specified by IEEE 802.11 the delay of the scanning method can range from 500 ms up to 3 to 5 seconds. The delay results form several factors including the association and authentication procedure for each AP which is usually around 3 ms to 5 ms, the preparation time before each probe which may be up to 200 ms and the accumulated time for each channel probed. For example, if the probe delay is 50 ms, the preparation time is 100 ms both before and after all eleven channels are probed then the delay will be 100+(50×11)+5+100=755 ms. This would result in an unacceptable large jitter buffer or number of dropped packets and possibly a detectable break in the audio playback.
One method of scanning for available wireless networks is to intersperse a series of short discrete probes between periods of data transmission. This scheme is illustrated in
Referring to
Actual communication with the network interface adapter 440 is still achieved by the proprietary driver 430 provided by the device manufacturer. The proprietary driver 430 acts as a slave to the virtual drivers 410, 420. The virtual drivers 410, 420 maintain AP and WLAN connection parameters such as BSSID, ESSID, channel, WEP key, WPA key, WPA information element, IP address etc for each virtual network interface 441442. These connection parameters are switched to the proprietary driver 430 so that its connection parameters match that of the currently active virtual network interface. No Authentication/Association Request and Responses are sent when switching between APs/WLANs.
The virtual wireless LAN drivers 410, 420 are also responsible for buffering packets sent by the UA and other applications over a virtual network interface that is not active. When the network interface becomes active the buffered packets will be sent first. Buffering of incoming packets for a non-active network interface is done at the AP. This is achieved using the IEEE 802.11 standard Power-save Mode which instructs APs to buffer packets for the wireless device. IEEE 802.11 Power-save Mode is turned on, all outgoing transmitted packets will have a flag indicating that the phone 100 network adapter is sleeping. If no data packets are sent by the UA or other phone applications the virtual driver will send a null-packet so that the AP knows that the phone 100 will be sleeping. Of course, the phone 100 will not be sleeping, but will be connected with the other associated AP. The invention maintains real-time data transfer for the telephone call by dynamically switching between network interfaces based on the number of buffered outgoing packets to be sent as well as using the Power-save Mode Poll (PS-Poll) function in IEEE 802.11.
Connection with AP 111 must be re-established periodically in order to refill the jitter buffer and maintain the seamless and undetectable nature of the roam. The AP 111 will periodically send a beacon to the phone on network interface 441 indicating that packets are being buffered for delivery to it. One option in the roaming scheme is to periodically switch between network interfaces 442 and 441 to listen for beacons from AP 111. However, because the phone is in a call with the other party 150 we know that packets are being buffered at the AP 111. Therefore, we can choose a simple connection swapping scheme to periodically send PS-Poll messages to the AP 111 to have the buffered messages forwarded without waiting for its beacon. Even if the AP has not buffer any packets for delivery sending a PS-Poll message does not violate the IEEE 802.11 standard.
In alternative embodiments, instead of using the PS-Poll message the IP phone 100 can send a message to the AP indicating that it has turned-off Power-save Mode. All queued packets will be sent by the AP. In another alternative embodiment the Power-save Mode scheme in the new IEEE 802.11e standard is used. The IEEE 802.11e standard defines a set of Quality of Service enhancements for LAN applications that are useful in delay-sensitive applications such as VoIP and Streaming Multimedia. The Power-save Mode scheme in the IEEE 802.11e standard is conceptually similar to that described but uses different packets to retrieve the data and should be more efficient.
The phone 100 switches between network interfaces periodically to the original interfaces 441 and sends a PS-Poll message 610, 611, 612. Before switching the phone 100 sends a Power-save Mode message to AP 121 to have packets buffered at that AP. The phone will remain on the original interface 441 for a period of time for buffered packets to be delivered and to send queued outgoing packets. It is envisaged that traffic on the new interface 442 will be lighter that on the original interface 441. The phone will switch between interfaces as many time as is needed to complete the roaming of the call, which may include communication 630 with a STUN or TURN server for NAT traversal. Finally, once the re-INVITE sequence 350-352 has been completed and RTP packets 353-354 are delivered to the new network interface 442 the original network interface 441 can be deactivated 360.
Of importance to seamless roaming is choosing the time period between switching of interfaces 441442 for continuing the call on the original interface 441 while establishing the connection and call on the new interface 442. One method is just to select a fixed time period of, say, 10 ms or 20 ms for switching between interfaces. However, this does not take into account the amount of traffic on each interface and a better method is to configure the switching time to be weighted between the two network interfaces 442 and 441 based on traffic. As indicated, typically there will be more traffic on the original interface 441 which is handling the VoIP call and less traffic on the new interface 441. One weighting scheme therefore is to apply a heavier weighting to the original interface 441 handling the VoIP call. This can be termed the primary interface and allocated 100 ms of active time in each switching cycle. The phone need only remain on the new, or secondary, interface for a short period, say, 10 ms and can then switch back to the primary interface for another 100 ms. The phone will continue this 100 ms/10 ms switching cycle until the RTP stream is being delivered to the new interface 442. However, a better scheme still and the one used in the preferred embodiment of the invention, is to dynamically allocate switching time based on pending outgoing traffic on either network interface 441442.
Referring to
Based on
One problem not addressed yet is firewalls. If the phones 100150 are in private subnets the are probably behind a firewall or NAT server. For a standard stateless SIP proxy server a STUN or TURN server can be used to tackle the NAT problem.
Another solution is to use a Back-to-Back User Agent (B2BUA) for NAT traversal. A B2BUA receives and processes INVITE messages as a User Agent Server (UAS) as well as acts as a User Agent Client (UAC) to determine how the request should be answered and how to initiate the outbound call. Most SIP service providers use a B2BUA instead of statefull or stateless SIP proxy server. Unlike a SIP proxy server the B2BUA maintains complete call state and participates in all call requests.
It should be appreciated that modifications and alternations obvious to those skilled in the art are not to be considered as beyond the scope of the present invention. For example, those skilled in the art will recognise that other methods of establishing multiple wireless network connections using a single wireless interface adapter have been proposed and may find application in the invention.
