MXPA06004524A - Handoff between a wireless local area network and a cellular communication system - Google Patents

Abstract

Handoff between a wireless LAN and a cellular communication system is provided. A system is designed to provide nomadic cellular services including voice over I.E.E.E. 802.11. An 802.11 network is used as long as the voice quality is likely to be acceptable. Voice quality is measured and maintained to be at an acceptable level. If voice quality degrades below an acceptable level the design allows seamless call hand-off between the 802.11 and a CDMA 1xRTT network, for example.

Description

TRANSFER BETWEEN A WIRELESS LOCAL AREA NETWORK AND A CELLULAR COMMUNICATION SYSTEM FIELD OF THE INVENTION The present invention generally relates to wireless communications. More particularly, the invention relates to the transfer between a relatively fixed wireless system and a cellular communication system.

BACKGROUND OF THE INVENTION Table 1 summarizes the acronyms and abbreviations, TABLE 1 Acronyms and abbreviations AP Access Point BS CDMA Base Station Code Division Multiple Access ESN Electronic Serial Number EVRC Enhanced Variable Rate Encoder / Decoder FA External Agent FFS for Additional GPS Survey Global Positioning System HLR Local Location Record HW 1ETF hardware Internet Engineering Task Force IMSI International Mobile Subscriber Identity IOS IP Interoperability Specification LAN Internet Protocol Local Area Network MAC Media Access Control MAD Mobile Address Message MGW Media Gateway MIB Management Information Base MIN Mobile Identification Number MIP Mobile Internet Protocol MO Mobile Originated MS Mobile Station MSC Mobile Switching Center MT Mobile Terminated NGLAN Next Generation LAN OAM Management of Operation Management OAM &P Management and Provisioning Management OCS Operation Obiwan Cellular Server PPP Point-to-Point Protocol QoS Quality of Service RFC Request for Comments RLP Radio Link Protocol SGW SNMP Signaling Gate Simple Network Management Protocol SS Supplementary Service SS7 Signaling System # 7 SW Software TBD To Be Performed TCP Transport Control Protocol UDP VoIP User Datagram Protocol Voice over IP VOPS Optimized Voice Power WAN Wide Area Network WSS Soft Wireless Switch BRIEF DESCRIPTION OF THE FIGURES Figure 1 is an architecture of the general system according to a modality; Figure 2 shows a trajectory of Signaling and a Protocol Stack according to a modality; Figure 3 shows a Voice Trajectory and a Protocol Stack according to a modality; Figure 4 shows a flowchart of the operations involved in the inter-AP transfer according to a modality; Figure 5 shows a transfer execution procedure according to a modality; Figure 6 shows a sequence of events for the transfer procedure; Figure 7 shows the protocol stack in the wireless terminal before transfer according to a modality; and Figure 8 shows the protocol stack in the wireless terminal after the transfer according to a modality.

DETAILED DESCRIPTION OF THE INVENTION In one modality, the transfer between a wireless LAN and a cellular communication system is provided. In one modality, a system is designed to provide nomadic cellular services including voice over I.E.E.E. 802.11. An 802.11 network is used as long as the quality of the voice is acceptable. The quality of the voice is measured and maintained so that it is at an acceptable level. In one embodiment, if the voice quality degrades below an acceptable level, the design allows for seamless call transfer between 802.11 and a CDMA IxRTT network, for example. The system integrates the user experience so that the user is not aware most of the time of the underlying transport used to support cellular services. One of the value-added is to ensure that the user interface (Ul) used by the user remains unchanged when the user moves from a WAN to the LAN. The key cellular features supported include, but are not limited to: Voice services using Enhanced Variable Rate Encoder / Decoder (EVRC) (MO and MT) SMS (MO and MT) Cellular Supplementary Services (CDMA type) Inactive transfer between two interfaces of air Transfer of perfect calls of 802.11 and a network CDMA lxRTT. The Obiwan Cellular Server (OCS) is a special type of BSC that supports the Standard Interoperability Specifications (IOS) interfaces 4.2 Al and A2, for example. The OCS server is deployed in the operator's network and provides support for a client in a wireless unit to provide cellular services.

A wireless unit may also be referred to as a subscriber station, subscriber unit, mobile station, mobile, remote station, remote terminal, access terminal, user terminal, user agent, or user equipment. A subscriber station can be a cell phone, a cordless phone, a Session Initiation Protocol phone (SIP), a wireless local loop (WLL) station, a personal digital assistant (PDA), a handheld device that has wireless connection capability, and another processing device connected to a wireless modem.

Architecture Figure 1 shows an architecture of the general system according to a modality. Figure 1 presents a general perspective on a CDMA-WLAN reciprocal action architecture, which allows provisioning of the public WLAN access service for subscribers of the CDMA system. These enabling features include the reuse of CDMA subscription, system selection, simple authentication mechanism, call routing and access to the service, as well as the payment to the end user. The reciprocal action functionalities are achieved without establishing any specific requirements for the WLAN access systems, but they are based on the existing functionality available in a typical WLAN access network based on the IEEE 802.11 standard, and on the introduction of the OCS, which It acts as a gateway between the standard WLAN system and the CDMA network. The OCS is responsible for transferring protocols between SIP and IOS. This works as a SIP Server for the wireless unit and as a CDMA BSC for the MSC. A SIP Registrar is used to register users in the SIP / WLAN domain. The SIP Registrar maintains the transfer between IMSI / ESN and the IP address for each user in the SIP / WLAN domain. The media gate (MGW) and the signaling gate (SGW) are controlled by the OCS and are used to establish communication with the MSC using A1 / SS7 / T1 / E1 for signal sending and on A2 / T1 / E1 for transfer voice. The Signaling Door performs transfers between SIGTRAN (IP) and SS7, and the Media Gate includes vocoders, and makes transfers between EVRC / RTP and PCM / T1 / E1. The network includes an MSC (Soft Switching) to provide services to wireless terminals in SIP / WLAN mode. This MSC supports the standard IOS Al and A2 interfaces with respect to the OCS / MGW. This MCS is also connected to an IS-41 network for transfers to the CDMA radio network.

Figure 2 shows a Signaling Path 200 and Protocol Stack 201 according to one embodiment. Figure 2 shows how the OCS 202 (with the SGW) 204 performs transfers between the IOS / IP protocols 206 and I0S / SS7 208. The OCS 202 communicates with the wireless device 210, with a SIP / UDP protocol / IP, and with the MSC (SS) 212 using the IOS / SS7 protocol. The wireless device 210 is coupled to a WLAN AP 212 using an 802.11 protocol 214. The WLAN AP 212 is coupled to an IP network 216. The IP network 216 is coupled to the OCS 202 using SIP 218. The MSC (SS) 212 is coupled to a CDMA network 220 using CDMA 222. The CDMA network 222 is coupled to an HLR 224 and an SMSC 226. The signaling path shows SIP 230, IOS 232, and CDMA 234. The protocol stacks shown include the wireless terminal 236, the WLAN AP 238, the OCS 240, the SGW 242, the MSC 244, and the CDMA network element 246. The wireless terminal protocol stack 236 includes SIP 248, UDP 250, IP 252, and 802.11 254. The stack of WLAN AP protocol 238 includes 802.11 256 and 802.3 258. The OCS 240 protocol stack includes SIP 260, UDP 262, IP 264, and 802.3 266, IOS 268, SIGTRAN 270, IP 272, and 802.3 274. The protocol stack of the SGW 242 includes SIGTRAN 276, IP 278, 802.3 280, SS7 282 and Tl / El 284. The protocol stack of the MSC 244 includes IOS 28 6, SS7 288, Tl / El 290, CDMA 292, SS7 294, Tl / El 296. The protocol stack of the CDMA 246 network element includes CDMA 297, SS7 298, and Tl / El 299. Figure 3 shows a Voice Trajectory 300 and a Protocol Stack 301 according to one modality. Figure 3 shows how the MGW 304 is used to perform transfers between EVRC and PCM protocols. The wireless terminal exchanges voice packets with the MGW 304 using the EVRS / RTP / UDP / IP protocol, while the MGW 304 exchanges voice frames with the MSC 306 (or PSTN 308) using the PCM / E1 / T1 protocol. The signaling path 300 shows the wireless terminal 310 coupled to the AP WLAN 312 using 802.11 314. The WLAN AP 312 is coupled to the IP 316 network. The IP 316 network is coupled to S / MGW 304 using VoIP 318. S / MGW 304 is coupled to the MSC (SS) 306 using PCM / T1 (A2) 320. The signaling path 300 shows VoIP 322 and PCM / TI 324. The 301 protocol stacks shown include the 324 wireless terminal, the WLAN 326 AP, the MGW 328, the MSC 330, and the PSTN 332. The protocol stack of the 324 wireless terminal includes EVRC 334, RTP 336, UDP 338, IP 340, and 802.11 342. The protocol stack of the WLAN AP 326 includes 802.11 344 and 802.3 346. The protocol stack of the MGW 328 includes EVERC 348, RTP 350, UDP 360, IP 362, 802.3 364, PCM 366, and Tl / El 368. The protocol stack of the MSC 330 includes PCM 370 and Tl / El 372 The protocol stack of the PSTN includes PCM 374 and Tl / El 376.

Subscription Management First, the cellular subscription will be used for the management of services. This implies that ESN and cellular IMSI will be used together with AKEY. A terminal with Obiwan capability, when operating in the WLAN environment, will use SIP for call processing signaling. This will open a tunnel for cellular subscription using SIP signaling infrastructure. The OCS will store the mapping between the Internet address (TCP / IP address and port or UDP / IP address and port) and the cellular subscription in persistent redundant storage.

Transfer management Transfer is defined for both active and inactive modes. The challenge is to make designs for all the various ways in which the 802.11 AP is deployed and maintain performance as used by the client in these 802.11 networks. The four types of transfer include: Transfer between-AP within a WLAN network (idle or talk mode) Transfer from WLAN to CDMA (idle or talk mode) Transfer from CDMA to WLAN (inactive mode only) Transfer between-BS within of a CDMA network (idle or talk mode) All four transfer types are supported in the idle mode, and all types of transfer, except CDMA to WLAN transfer, are supported in the talk mode.

Transfer between-AP The transfer between-AP occurs when the wireless terminal moves from the coverage area of one AP to the coverage area of another AP. The three stages involved in the transfer between-AP are: Activation of transfer: this will occur when the quality of the link between the wireless terminal and the OCS is not convenient. It can be seen that an activation does not always result in a transfer, the result of the transfer depends on the state of the search. Also, activation may result in a transfer to a CDMA network, rather than an inter-AP transfer. Search: the wireless terminal will search for new AP, and will select the AP with the strongest signal strength. The transfer will start if this AP is better than the current AP for more than one hysteresis level. (This is to avoid a ping-pong effect). It can be seen that part of the search stage can occur before the activation of the transfer, through the construction of a list of candidate APs (in cooperation with a database in the OCS). Termination: the wireless terminal establishes a connection with the new AP. This includes 802.11 authentication, 802.11 association and higher layer functions. Figure 4 shows a flow diagram of the operations involved in the inter-AP transfer according to a modality. In step 402, join the new AP. A list of candidate APs is obtained from the OCS and the AP. In step 404, the wireless terminal is in talk mode. A scan is performed to update the list of candidate APs. The CDMA and 802.11 link quality is monitored. In step 406 with a CMDDA transfer activation, a test is performed to determine if a CDMA signal is above a first threshold and if CDMA transfer is allowed. If the test fails, then the control flow proceeds to step 408. If the test is successful, then the control flow proceeds to step 410. In step 408 a test is performed to determine whether an AP of better vertical alignment 1 is better than a second threshold, transfer between-AP is allowed, and the number of attempts between-AP is less than one third of the threshold. If the test is successful, the control flow proceeds to step 412, otherwise the control flow proceeds to step 414. In step 412, a transfer to the AP of best vertical alignment is attempted 1. If the transfer has success, then the control flow proceeds to step 402. If the transfer fails, then the AP is removed from the list in step 416 and the control flow proceeds to step 408. In step 414 a test is performed for determine if a CDMA signal is above a fourth threshold and CDMA transfer is allowed. If the test is successful, then the control flow proceeds to step 410. If the test fails, then the control flow proceeds to step 418.

In step 410 a transfer to CDMA is attempted. If the transfer succeeds, then the wireless terminal operates in the CDMA mode in step 420. If the transfer fails, the CDMA transfer is configured so that it is not authorized in a local database in step 422 and the control flow proceeds to step 408. In step 418 a test is performed to determine if the AP of best vertical alignment 2 is better than a fifth threshold, the transfer between-AP is allowed, and the number of attempts between-AP is less than a sixth threshold. If the test succeeds, then the control flow proceeds to step 424, otherwise the control flow proceeds to step 426. In step 426 a full scan of the 802.11 and CDMA links is performed. The CDMA transfer is configured to be allowed and the number of attempts between-AP is set to zero. The control flow continues with step 408. In step 424 a transfer to an AP of better vertical alignment 2 is attempted. If the transfer succeeds, then the control flow proceeds to step 402. If the transfer fails, then the control flow continues with step 426. In step 426 the AP is removed from the list and the control flow proceeds to step 408.

The transfer between-AP is controlled by mobile as in the 802.11 systems (as opposed to the mobile-assisted transfer that is commonly used in cellular transfers). One step in the transfer is the generation of a transfer activation that essentially says that the quality of the current link is inconvenient. Based on the transfer activation, the transfer is made to a CDMA network or another AP. The realization of the transfer depends on a list of candidate APs which is maintained in the wireless terminal. The final step in the transfer is the realization of the transfer, which involves the establishment of a new voice path, and the termination of the old voice path.

Activation of transfer The generation of a transfer activation is regulated by different mechanisms depending on the fact if the wireless terminal is in idle mode or to speak.

Transfer activation in talk mode The two types of transfer activations can be generated in the WLAN talk mode, the inter-AP transfer activation, and the WLAN to CDMA transfer activation. An inter-AP transfer trigger is generated when the link quality of the current AP degrades, and there is reason to believe that moving to a different AP will improve performance. The communication link comprises the wireless-AP terminal link, and the AP-OCS link. In case the AP-wireless terminal link is degraded, the transfer to a different AP may result in a better link. However, the AP-OCS link probably has to be shared among all the APs in a network, and the degradation of the AP-OCS link can only be remedied by the transfer to a CDMA network. A WLAN to CDMA transfer activation is generated when the AP-OCS link is degraded, while an inter-AP transfer activation is generated when the wireless AP-terminal link is degraded.

Inter-AP transfer activation In particular, an inter-AP transfer activation is generated when any of these conditions is met. The maximum count of retries for the upstream transmission is reached. The data rate reaches the minimum value allowed (1 Mbps). The data rate changes are according to the following mechanism. A downward velocity change occurs when a frame is retransmitted three times and a request to send / clear to send (RTS / CTS) is used to send the last two transmissions. A client that transmits less than the default speed will increase the speed of data back to the next higher speed after a short time interval if the transmissions are successful. Downstream traffic (originating from the current AP) is greater than a threshold and any of the following conditions are met. The buffer memory of the downstream vocoder is empty by more than Transfer_Vacia__MemoryIntermedia_Umbral. The upstream buffer contains more than packets of Transmission_Internal_Memory_Umbral. A full upstream buffer indicates that the packets are not being received successfully by the other party. The objective here (in case 3) is to distinguish between the degradation of traffic quality due to the formation of queues in the AP and that caused by the main structure of the Internet. If voice packets are received erratically (case a), or sent erratically (case c) while the traffic is occupied by other packets, the probable cause is heavy traffic in the current AP. This situation can be corrected by moving to a different AP.

Activation of WLAN to CDMA transfer A transfer activation from WLAN to CDMA originates in the following cases. When 3a or 3b is met, even if the downstream traffic is below a threshold (the case where erratic downstream traffic is caused by the delay in the main structure of the Internet). When the RTT between the wireless terminal and the OCS exceeds a value determined by three consecutive measurements. The RTT is measured by special packages of RTT__Request and RTT_Recognition that are exchanged between the wireless terminal and the OCS periodically. As shown in Figure 4, the transfer from WLAN to CDMA can also be carried out if inter-AP transfer fails (even when a transfer activation from WLAN to CDMA is not generated).

Activation of transfer in inactive mode A transfer pre-activation is generated in inactive mode when any of the following three conditions is met. Maximum Retry Count for Keep Alives (keep alive is an extension for HTTP that allows continuous connections): When the transmission of a keep alive packet requires more than a certain number of retransmissions, or takes more than a certain amount of time. Keep Alive Delay: When the response of a keep alive packet is not received within a certain delay period (say 300 ms). Signal Intensity: The intensity of the received beacon signal or keep alive responses falls below a certain threshold. Once the pre-activation of the transfer is general, the wireless terminal exits the 802.11 power-saving mode, and attempts to send the keep alive packets in normal operation mode. If the keep alive responses are delayed or have a low signal strength, the wireless terminal generates a transfer activation.

Maintaining a list of candidate APs Once a transfer activation is generated, the transfer execution function is used. This function requires as an argument a list of candidate APs. In current 802.11 solutions, a scan is performed after the transfer activation is generated, and the scan results are used to build a list of candidate APs. However, for Obiwan in speech mode, scanning after a transfer activation may result in a delay and degradation in voice quality. This section describes some techniques for optimizing the scan function for a wireless terminal in talk mode by collecting information about the transfer candidate APs before a transfer activation is generated. It can be seen that, regardless of the information collected before the transfer activation, the wireless terminal always sends a test to the target AP before associating with it. The objective of the optimization of the scan is to maintain a list of candidates in the wireless terminal, so that the test response to the first AP in the list is successful with high probability.

List of candidate APs A wireless terminal in WLAN talk mode or inactive WLAN mode maintains a list of candidate APs to support the transfer. In one modality, this list includes the following entries for each candidate AP Y. AP MAC address and SSID (network identification) of AP and Intensity of the last signal reported from AP And Metrics related to inter-AP transfer Reliability of transfer between-AP (vertical alignment 1 to 4) Number of transfers in mode to speak successful to AP Y Number of transfers in mode to talk unsuccessful to AP Y Number of transfers in mode inactive successful (but slow) to AP Y Number of transfers in inactive mode successful (and fast) to AP Y Number of transfers between unsuccessful modes to AP Y Call quality history (scale 0 to 7) IP Domain Configuration security (can take any of the following values) Open (without security) WEP required (key in OCS) WEP required (key in wireless terminal, but not available for OCS) EAP required (key in OCS) EAP required (key in wireless terminal , but not in OCS) Security and reliability of the transfer Reliability metrics are interpreted in the following way (subject to security settings). Level 1: not reliable, Obiwan service not available, never try association with AP. Level 2: marginal. There is no transfer between-AP in talk mode. Only transfer between-AP in idle mode when CDMA is not available. Level 3: moderately reliable. Transfer between-AP in talk mode only when CDMA is not available. Transfer between-AP in inactive mode regardless of the CDMA signal level. Level 4: highly reliable. Transfers between-AP in speech mode and inactive even if the signal CDMA is available. The ordering of the candidate list is based on the vertical transfer alignment and the reported signal strength. First classify the candidates of level 4 according to a signal strength, and then the transfer candidates of level 3 according to a signal strength, and so on. For some deployments, the OCS database may not have the security key that allows the wireless terminal to transfer to the candidate AP. If the AP requires a security key that is not available in either the OCS or the wireless terminal, the wireless terminal transfers the reliability of the AP transfer to level 2.

Maintenance of the OCS database The OCS database starts the list of candidate APs. The OCS database contains an entry of the following form for each AP. The entries include a list of neighboring AP addresses and some of their properties such as the last reported signal strength, call quality history, and security settings, for example.

TABLE 2 Registration of Database The entries in the transfer column Between-AP are described below: Reliability of transfer between-AP (vertical alignment 1 to 4) Number of transfers in mode to speak successful to AP Y Number of transfers in mode to speak unsuccessful to AP Y Number of transfers in inactive mode successful (but slow) to AP Y Number of transfers in inactive mode Successful (and fast) to AP Y Number of transfers between unsuccessful modes to AP and The reliability of the transfer between-AP in the OCS database may be different from the reliability in the candidate list of wireless terminals (due to security settings). The entry for the row corresponding to the own ID is constructed in the following way. The number of transfers of different types is simply the sum of the lower rows, while the vertical alignment is the minimum of the vertical alignments of all the APs in the record. The entries in the list of neighboring APs for AP X are updated based on the measurement made when the wireless terminal is in talk mode WLAN or idle WLAN mode, and is associated with AP X. The database of the AP OCS is updated each time the wireless terminal communicates one of the following events to the OCS. It can be seen that in the case of hot connections, this communication may occur minutes or even hours after the event occurred. The following OCS database events occur to support the transfer. These events are in addition to the events defined elsewhere in this document. Record creation: every time a wireless terminal is associated with an AP, it communicates with the OCS. If there is no entry corresponding to AP X, the OCS database creates a new entry. This entry starts as: CDMA_Transference_Confiability = 3 Between-AP_Transference_Confiability = 3 General Service Quality = 4 If there is a record in the OCS database, the OCS sends the input to the wireless terminal, where it is used to form the list of AP candidates. Add new neighbor to record AP: Each time a wireless terminal detects (during a scan) an AP that is not in the list provided by the OCS, the latter requests the OCS to add a new row in the entry for AP X. The call quality and IP domain rows of the entry are filled by searching the AP for the Y database in the OCS database, if the AP Y does not is in the database of the OCS, these are configured to default values Call_Quality_Initial and 0.0.0 respectively. The SSID and channel entries are filled using the research response sent by AP Y. The security configurations of the new AP are sent according to their SSID. Transfer reliability entries start depending on the SSID of the new AP. If the new AP has the same SSID as AP X, its transfer reliability is set to. If this new AP has a different SSID, its transfer reliability is set to 3. Transfer in successful talk mode to AP Y: Check the transfer history entries for the row corresponding to AP Y. Increase transfer reliability by 1 Transfer in successful inactive mode to AP Y: Review transfer history entries for the row corresponding to AP Y. There can be two types of successful transfers inactive, fast and slow. Quick: If the number of fast transfers in idle mode crosses a divisible number between two, the reliability of the transfer increases by one. Slow: If the number of slow transfers in idle mode crosses a divisible number between five, it increases the reliability of the transfer by one, but does not increase beyond 3. Transfer in mode to talk unsuccessfully to AP Y: Review the entries of the transfer history for the row corresponding to AP Y. If the number of unsuccessful talk mode transfers crosses a divisible number between two, reduce the reliability of the transfer by one. Transfer inactive mode without success to AP Y: Review the transfer history entries for the row corresponding to AP Y. If the number of transfers in inactive unsuccessful mode crosses a divisible number among four, reduce the reliability of the transfer by one. Successful transfer to a CDMA network: Review the CDMA transfer history, and increase the reliability of the CDMA transfer by one. Unsuccessful transfer to a CDMA network: Review the CDMA transfer history, and reduce the reliability of the CDMA transfer by one.

Basic points of the 802.11 scan The 802.11 standard defines a scanning mechanism to conduct a search for candidate APs for transfer. For each channel that is to be scanned, the wireless terminal performs the following operations: Move the transceiver to the desired frequency (assume a delay of 1 ms). Set the backspace window to a duration of Research Delay (100 μs typically), and the NAV vector to zero. The normal DCF operation begins. If the channel is not free during the Research Delay, configure NAV according to the current transmission. Transmits the research package (package duration approximately 250 μs). Wait for the response of the research package (delay observed approximately 1 ms). Research packages can be of two types: broadcast or unicast. A broadcast investigation has destination address ff: ff: ff: ff: ff: ff, and any AP can respond. A unicast investigation has a specific destination address, and only the AP with the destination address of the research package responds to a unicast investigation.

Candidate AP list continuously updated To provide a fast transfer, a continuous active scan is supported while in talk mode according to a modality. When continuous updates are used, each Scan Interval seconds (you can say, 1 second), a wireless terminal in talk mode scans a channel. If possible, the scan operation begins immediately after a packet has been received downstream (to prevent a downstream packet from being lost while the wireless terminal is scanning another channel). The results of the exploration are used to elaborate a list of transfer candidates which will be used in case the link with the current AP is degraded. In one modality, the update of the list of transfer candidates and channel exploration follows these rules: The list of transfer candidates is classified based on the entries for each candidate. Therefore, the list of transfer candidates can be classified in part based on the history of call quality, for example. Every second (2nd) investigation is sent in the AP channel at the top of the list of transfer candidates. Another cycle of research through all channels contained in the list of transfer candidates. After each Scan_Other_Channels seconds, the wireless terminal scans (subject to rule 2) the channels not contained in the list of transfer candidates. Each research response is used to update the list of transfer candidates (in particular the intensity field of the last observed signal). If a new AP is detected during a scan, the OCS database is notified. In experimental results it has been discovered that a channel scan (research and response operation) requires approximately 2 ms. Assuming that the time it takes to switch channels is 1 ms, a wireless terminal in talk mode can scan a channel and return to the original channel in approximately 4 ms. This time does not include the time it takes for the MAC hardware to change to scan mode. One of the recommendations for an 802.11 chipset is that it allows for quick scanning. The scanning procedure in inactive mode is different. Each Inactive_Mode_Exploration_Interval seconds, the wireless terminal performs a complete scan of the channel. This scan is used to update the OCS database, but the list of candidate APs should not be used in idle mode. Rather, a full channel scan is performed before the transfer.

Transfer execution Transfer execution in talk mode: the list of candidate APs is classified based on the entries for each candidate. If the signal strength of the AP at the top of the list is sufficient, the transfer to the AP at the top of the list is attempted. If the transfer fails, the wireless terminal tries to link to the next AP in the candidate list, and continues this procedure until a timer expires, or until a maximum number of transfer attempts has been made. See figure 4 for details. Execution of transfer in inactive mode: The wireless terminal leaves the 802.11 power saving mode, and scans all valid channels for the operating regulatory domain to prepare a list of candidate APs, and classifies the list according to the rules provided in 0. If the transfer fails, the wireless terminal tries to link to the next AP in the candidate list, and continues this procedure until a timer expires, or until a maximum number of transfer attempts have been made. The wireless terminal sends a keep alive at the end of each transfer. This keep alive includes the time used for the completion of the transfer, and is used by the OCS to update its database. After the transfer is complete (successful exchange of messages with the OCS), the wireless terminal returns to 802.11 power saving mode. The exact mechanism for the transfer depends on the level of security executed in a WLAN deployment.

Transfer without security First consider the simplest case, where configurations without security or simply configurations with WEP security are used. For these simple cases, the transfer procedure includes the following steps: Send an authentication request, obtain an authentication response. This is the stage where the WEP key is used, if assigned. A wireless terminal obtains the WEP key from the OCS database or a local database at the wireless terminal. Send an association request, get an association response. Use the inter-AP protocol to inform the former AP of the removal of the wireless terminal from its list. Use SNAP to report the change in the subnet of the AP to send packets for wireless terminal to the new AP.

Transfer safely Security is executed using the standard 802. 1x that specifies the EAP operation (extended authentication protocol) over 802 networks. 802.11 to Ix transfer in Voice Mode An active state transfer includes a transfer from 802.11 mode of operation to the original lxRTT mode.

Deciding between transfers between-AP and CDMA When the current AP has a low signal strength, you need to decide whether the transfer will be to a CDMA or WLAN network. For example, in a local WLAN (only with an AP), the transfer attempt to an alternate AP will result in an additional delay, and the transfer to a CDMA network is attempted as soon as the WLAN link degrades according to a modality. On the other hand, in a business deployment, there is a likelihood that there will be many APs and the transfer to an alternate AP should be attempted before the transfer to a CDMA network is attempted. In case the scan performed during the call (or before the call began) indicates that other APs are not available, the decision between WLAN and CDMA is clear, and the transfer must be made to CDMA. However, when other APs are present, it is necessary to decide whether the transfer will be made to WLAN or CDMA. This decision is important because: The transfer to WLAN maximizes the use of free spectrum. Transfer to WLAN can cause a delay to be exceeded if a new IP address needs to be obtained or if the WLAN deployment results in an excessive delay. The OCS database helps the wireless terminal to decide if the transfer should be to WLAN or CDMA. Details of this decision procedure are provided in the flow diagram in Figure 4. Attempt is made to transfer from WLAN to CDMA in talk mode if there is an activation to transfer from WLAN to CDMA, or if there is no level 4 reliability AP with a signal strength above a threshold.

Basic points of the WLAN to CDMA transfer Before the transfer, the user terminal uses a SIP over IP on the 802.11 protocol stack in the signaling plane, as well as a VoIP stack in the traffic plane. After the transfer procedure is completed, the user terminal uses an original signaling protocol stack IS-2000 IxRTT in the signaling plane, as well as an original IS-2000 IxRTT voice processing in the traffic plane. The objective CDMA BTS, the objective CDMA BSC and the MSC IS-41 objective are standard components. The interaction of the OCS with the MSC IS-41 during the transfer procedure complies with the IS-41 and IOS specifications. The development is only allowed and required in the OCS and in the user terminal. During a voice call in 802.11 operation mode, the wireless terminal should monitor both networks (802.11, CDMA). If the 802.11 reception power falls below a certain threshold, the wireless terminal should report the reception power of both networks to the OCS. The OCS must then resort to the inter-system transfer procedure for CDMA. Therefore, this transfer procedure is assisted by mobile. As part of this procedure, the OCS should forward the Transfer Command that is received from the MSC IS-41 to the user terminal. The user terminal must then end its operation in 802.11 operation mode, switch to lxRTT mode, start its CDMA protocol stack to Active mode and execute the standard CDMA transfer sequence together with the target base station.

Transfer activation The transfer of WLAN to CDMA can occur in two cases: when there is an activation for WLAN transfer to CDMA, or when the transfer between-AP fails, resulting in a transfer request to a CDMA network (see details in Figure 4). Activation to transfer WLAN to CDMA is generated when any of the following conditions is met. No packet is received in the downlink for Transfer_TimeMuerto_Umbral. The fraction of the missing packets in the downstream exceeds Transfer_Packet Loss _Umbral. The user terminal will use wired microprogramming and RF chain separately for each mode of operation (802.11, CDMA). During an 802.11 call, the user terminal should periodically monitor both the 802.11 network and the CDMA network, using the separate hardware. The wireless terminal should try to acquire the Pilot Channel of a CDMA system. After the first Pilot channel acquisition, the wireless terminal should also acquire the associated Synchronization and Location channels, to obtain timing information, SID and NID pair, Neighbor List message and the BID_ID for the CDMA system. Subsequently, the wireless terminal should remain in a small space of the CDMA Inactive state with the zero Slot Cycle index and execute transfers in idle mode to neighboring cells when necessary. The wireless terminal should maintain a list of the 4 highest intensity Pilot channels received and their associated PN compensation, receive power and ID_BASE. The OCS may reside at a location distant from the target CDMA cell for transfer. As a result and unlike the source CDMA, the OCS can not determine the unique identification of the target CDMA cell, based solely on PN compensation. Therefore, the wireless terminal should acquire the location channel of the target cell and obtain the BASE_ID from the System Parameters message. To reuse standard CDMA execution and design, the wireless terminal should remain in the space of the inactive state mentioned above. This can cause a small waste of battery consumption, but simplifies execution significantly. The user terminal should also monitor the reception power and speed of the 802.11 mode. In case the reception power of the 802.11 network falls below a predetermined threshold, the user terminal should send a PSMM signaling message to the OCS, to report the power received from both networks. The PSMM signaling message should contain the SID and NID of the CDMA system, the BASE_ID for the reported cells and their reception power. Based on this measurement report, the OCS can resort to a transfer procedure between systems to CDMA.

Transfer execution If the OCS determines to resort to the inter-system transfer procedure for CDMA, the system executes the procedure shown in Figure 5. In step 501, the wireless terminal has detected that the reception power of the 802.11 system drops by below a predetermined threshold. As a result, the wireless terminal sends a power measurement report signaling message to the OCS, tunneled over the 802.11 network. This message contains the measurement of the reception power of both 802.11 and CDMA networks. In step 502, based on a wireless terminal report that it has crossed a specified network threshold for signal strength, the OCS recommends a transfer through different systems to a CDMA network. The OCS sends a Required IOS Transfer message to the MSC IS-41 to find an objective with available resources. In step 503, the target MSC IS-41 sends a Transfer Request message to the target BSS IOS, requesting BSS to prepare the resources for the next transfer. In step 504, the target BSS determines that the appropriate resources are available and begins to transmit NULL forward traffic data. In step 505, the target BSS sends a Transfer Request Acknowledgment message to the MSC. In step 506, the MSC prepares to change from the OCS to the target BSS and sends a Transfer Command to the OCS to transmit the information from the target BSS. In step 507, the OCS sends a Universal Transfer Address Message to the wireless terminal and may request an acknowledgment. These messages are tunneled over the 802.11 network.

In step 508, the wireless terminal returns an acknowledgment to the OCS to confirm receipt of the Universal Transfer Address Message. In step 509, the OCS sends a Start Transfer message to the MSC to notify it that the MS has received instructions to move to the target BSS. In step 510, the wireless terminal is tuned to CDMA mode and initiates its protocol stack to the Active call state. The wireless terminal then tunes to its assigned traffic channel and begins transmitting NULL traffic data in reverse. The start of the protocol stack in the wireless terminal is described in more detail below. In step 511, the wireless terminal sends a Transfer Termination Message to the target BSS. In step 512, the target BSS sends the BSS Recognition Order to the wireless terminal on the air interface. In step 513, the target BSS sends a Full Transfer message to the MSC to notify it that the wireless terminal has successfully completed the transfer through different systems. In step 514, the MSC sends a Clear Command to the OCS. In step 515, the OCS sends a Clear Complete message to the MSC to notify it that the clearance has been made. The general sequence of events for the transfer procedure is shown in Figure 6.

Starting the CDMA Protocol on the user terminal To carry out the transfer, the wireless terminal needs to replace its 802.11 operational protocol stack before the transfer, to CDMA after the transfer. In addition, the CDMA protocol stack needs to be started directly to its Active call status. In original CDMA operations, the CDMA protocol stack transitions from NULL state status to Inactive status and then to Active call status. These state transitions are accompanied by considerable interaction with the network, such as the exchange of signaling messages as well as equivalent state transitions in peer entities in the network. On the contrary, in the 802.11 to CDMA transfer scenario, the CDMA protocol stack is initiated locally in the user terminal, directly in the Active call state. This can be done, for example, through the introduction of a transfer agent in the wireless terminal software, which will perform a set of primitives for the CDMA protocol stack to locally activate the required state transitions. After the CDMA protocol stack enters the Active call state, the transfer agent can deliver the Transfer Command signaling message received from the OCS to the CDMA protocol stack. The CDMA protocol stack can then execute the standard CDMA handover sequence with the target BSS. All the above procedure must be hidden from the user (within reason) and must comply with strict time restrictions. The design approach for the wireless terminal software should use existing AMSS and API features whenever possible and introduce code changes when necessary. Figure 7 shows the protocol stack in the wireless terminal before transfer. Figure 8 shows the protocol stack in the wireless terminal after the transfer.

Transfer from Ix to 802.11 in idle mode only In one mode, the transfer from lx to 802.11 is supported in idle mode only. While in Ix idle mode, the wireless terminal periodically scans for power on all 802.11 channels. If the power of an AP is high, the wireless terminal tries to authenticate itself with that AP. It can use the Ix data channel to communicate with the OCS to obtain the appropriate access keys to the 802.11 network. Once the wireless terminal is associated with the AP, it will register with the network (MSC).

Transfer between-BS in CDMA mode Transfer between-BS in CDMA mode is completely independent of the LAN operation. The present invention provides cellular data and voice over WLAN service. The invention also provides integrated cellular service with NGLAN for billing and distribution. This mitigates the difficult issues of coverage and deployment by providing the appropriate core network integration. Also, the system is backwards compatible with 802.11. Unique number / two networks. The cellular number works in the Ix network or in NGLAN. The central network recognizes whether to deliver the service to Ix or NGLAN. Transfers in idle mode move between networks and the central network delivers them to the mobile. Ix transfers handle active NGLAN support.

Service Integration The cellular service is delivered using an lx system. The NGLAN service is delivered using NGLAN. Both can be monitored simultaneously. The exit service can be configured to use the preferred access. For authentication, AKEY, ESN and IMSI are used. RADIUS is used for data authentication. Billing records are consistent with cellular systems. This system maintains the appearance and feel with the SMSS integration, the supplementary service support, the perfect service availability and simultaneously monitors the Lx and NGLAN networks. The system provides the capability to simultaneously monitor the lx and NGLAN networks. Activation of the transfer and objective selection support help determine if a transfer is necessary. In a preferred embodiment, this occurs in approximately 80 seconds. Additionally, the system determines the goal within approximately 20 milliseconds. The sleeping modes between 802.11 and lx are coordinated and the development support of the central BSC is integrated.

NGLAN transfer- > lx NGLAN starts in the terminal. The message flows are similar to those in CDMA 2000. The messabetween the IP-BSC and the clients are tunneled over the Internet protocol.

Claims (3)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS

1. - A method of transferring a local area network (LAN) to a CDMA network for a wireless terminal, comprising: determining a candidate list of access points (AP) from a plurality of APs; Classify the list of AP candidates, in part, based on the strength of the plurality of AP signal; Selecting an AP from the list of AP candidates, in part, based on the signal strength of the plurality of APs; Determine that a transfer activation has been triggered, in part, based on the quality of a wireless terminal link; and Establish a connection with the selected AP if a transfer activation occurs and if the signal strength of the selected AP is greater than the signal strength of a current AP by a hysteresis level.

2. A wireless terminal, comprising: means for determining a list of candidates for access points (AP) from a plurality of APs; - means for classifying the list of AP candidates, in part, based on the signal intensity of the plurality of APs; means for selecting an AP from the list of AP candidates, in part, based on the signal strength of the plurality of APs; means for determining that a transfer activation has been triggered, in part, based on the quality of a wireless terminal link; and means for establishing a connection with the selected AP if a transfer activation occurs and if the signal strength of the selected AP is greater than the signal strength of a current AP by a hysteresis level.

3. - Computer readable media that incorporate a program of instructions executable by a computer program to execute a method of transferring a local area network (LAN) to a CDMA network for a wireless terminal, comprising: Determine a list of candidates for access points (AP) from a plurality of APs; Classify the list of AP candidates, in part, based on the strength of the plurality of AP signal; Selecting an AP from the list of AP candidates, in part, based on the signal strength of the plurality of APs; Determine that a transfer activation has been triggered, in part, based on the quality of a wireless terminal link; and Establish a connection with the selected AP if a transfer activation occurs and if the signal strength of the selected AP is greater than the signal strength of a current AP by a hysteresis level.