DETAILED DESCRIPTION OF THE INVENTION

[0064] FIG. 1 illustrates the basic components and operation of an exemplary, overall communication system 100. A Base Station 101 of a cellular system covers a cell 111 having a relatively large coverage area 111. (The Base Station 101 is shown off-center in its coverage area 111, and the coverage area 111 is shown as elliptical rather than circular, for illustrative clarity.) Base Stations 107, 108 and 109 of a WPBX system cover cells 102, 103 and 104, respectively, each having relatively smaller coverage areas. (The Base Stations 107, 108 and 109 are shown off-center in their respective coverage areas 102, 103 and 104, for illustrative clarity.) Sometimes, these smaller cells 102, 103 and 104 are referred to as “microcells”, or “picocells”, or “minicells”.

[0065] A mobile handset 110 can communicate with the cellular Base Station 101 via a communication link 105 and, when it is in the coverage area of the WPBX, it also can use short-range communication link 106, to communicate with one of its Base Stations 107, 108 and 109. In this manner, a standard cellular handset 110, that is enhanced (additionally equipped) with a short-range communication link (e.g. Bluetooth wireless technology) can connect with the WPBX system whenever it is in range of one of the WPBX Base Stations 107, 108 and 109.

[0066] The WPBX system can also operate when there is no cellular coverage at all. And the handset 110 can be an ordinary cordless telephone handset. Therefore, the cellular Base Station 101 shown in FIG. 1 is optional, insofar as the WPBX system of the present invention is involved. In the main hereinafter, a handset which is an otherwise ordinary cordless telephone handset, equipped with a short-range communication link (e.g. Bluetooth wireless link) will be used to describe the invention.

[0067] In an office environment, a WPBX system improves availability of employees, who carry mobile handsets, and therefore reduces operational cost and increases productivity. In the home environment, a WPBX system enables the use of the standard cellular handsets instead of special cordless phones.

[0068] In the present invention, when the handset is the same as the cellular handset, the cost of equipment is lower then the cost of a standard WPBX which requires dedicated handsets. Since the WPBX handles calls between handsets connected to it, the communication charges are lower then when standard cellular communication is used for all the calls.

[0069] The handset 110 may indicate to the user that more then one service is available. The user decides which service to use (Cellular or WPBX). The ability to choose between services is a well-known feature in many mobile phones.

[0070] It should be understood that the handset 110 is merely an example of a “mobile unit” which can be any of a number of telephony, voice, computing or data devices which communicate via Base Stations, as described in greater detail hereinbelow. As used herein, “Mobile Units” are devices communicating wirelessly with (also referred to as “connected to”) Base Stations.

[0071] As illustrated in FIG. 1 (and ignoring the cellular Base Station 101 and link 105) the handset 110 is currently communicating with (connected to) the Base Station 108. The Base Stations 107 and 109 are each referred to as “neighboring” Base Stations since they are each adjacent to the Base Station 108 that the handset is currently connected to. The present invention deals largely with how communication with a Mobile Unit such as a handset is handed off (or passed off) from a one Base Station to another (neighboring) Base Station when the handset moves from one minicell to another minicell.

[0072] FIG. 2 illustrates the main components and architecture of a WPBX system 200 suitable for use as the WPBX system of FIG. 1. The architecture of a WPBX system generally resembles the architecture of a cellular system. However, as described in greater detail hereinbelow, the function that each component performs is different, since the current invention deals with short-range communication with mobile units that have no built-in support for handoff.

[0073] The WPBX 200 comprises a plurality (three shown) of Base Stations 123, 124, 125. A handset 121 communicates via a short-range communication link 122 (e.g. Bluetooth wireless link) with Base Station #1 123. Base Station #2 124 and Base Station #3 125 are ready to receive the call should handset 121 move into their coverage area. At the same time, the other Base Stations may participate in calls with other handsets. For example, Base Station #2 124 communicates via a short-range communication link 134 (e.g. Bluetooth wireless link) with a handset 133. The handsets 121 and 133 may communicate with each other via the WPBX (as opposed to directly with one another), as described in greater detail hereinbelow.

[0074] Communication links 126, 127, 128 connect the Base Stations 123, 124, 125 with one another, as illustrated. These communications links transfer data between the Base Stations 123, 124, 125, including voice communication, data communication, connection status information and synchronization information, as described in greater detail hereinbelow, and may be RF links or land lines (e.g., copper wires, optical fibers, etc.).

[0075] Communication links 130, 131, 132 connect the Base Stations 123, 124, 125, respectively, with a Central Switch (hereinafter “Switch”) 129. These communication links enable the Switch 129 to control the operation of the Base Stations and to participate in the higher levels of the communication protocols, as described in greater detail hereinbelow, and may be RF links or land lines.

[0076] FIG. 3A illustrates the addition of a Gateway 135 to the WPBX system 200 of FIG. 2. The Gateway 135 connects the Switch 129 to a Public Switched Telephone Network (PSTN) 136. This enables the WPBX system 200 to receive incoming calls from and to send outgoing calls to other telecommunication systems (not shown) which are connected to the PSTN. The Gateway 135 may be implemented in any suitable manner, such as in hardware and/or software.

[0077] As used herein, a “Gateway” is a logical or physical connection between two different communication networks. The term implies a need for conversion of some aspect of the information or communication in order to operate, as contrasted with a “port” which implies a point not requiring significant conversion of the message or information. Gateways are well known.

[0078] FIG. 3B illustrates the addition of a Gateway 137 to the WPBX system 200 of FIG. 2. The Gateway 137 connects the Switch 129 to a standard Private Branch Exchange (PBX) 138. This enables the WPBX system 200 to receive incoming calls from and to send outgoing calls to standard telephone sets 139 connected to the PBX 138. As illustrated, the PBX 138 is interfaced with the PSTN 136. Thus, the WPBX system 200 can also communicate with other telecommunication systems (not shown) which are connected to the PSTN.

[0079] Having dedicated connections for all the Base Stations 123, 124, 125 and the Switch 129, such as illustrated in FIG. 2, hereinabove, is generally not cost-effective. Rather, when real time interaction or synchronization is not required, a shared local network, for example a local area network such as the IEEE 802.2 Ethernet, can connect these units in a cost-effective manner.

[0080] FIG. 4 illustrates a plurality (three shown) of Base Stations 123, 124 and 125 (compare FIG. 2) connected via a communications link which is a Local Area Network (LAN) 140 which handles the transfer of information between the Base Stations 123, 124, and 125, the Switch 129 and, in this example, the Gateway 135 to the PSTN 136. Using a standard local area network (LAN) as the communication backbone allows simple integration with other telephony application servers (not shown), such as IVR (interactive voice response), voice loggers, voice mail and billing systems. The LAN 140 can be either wired, or wireless.

[0081] FIGS. 2, 3A, 3B and 4 therefore illustrate, in a general manner, a number of ways in which the main components of a WPBX can be connected with one another, and interfaced with other communications systems (PSTN, PBX, etc.)

[0082] For office WPBX applications the Switch 129 may be a standard computer that has the processing power required for handling the switching of hundreds of calls simultaneously. It should support operation in a multi-server environment. This can be achieved with standard server hardware. For home WPBX applications, the Switch 129 may be a part of one Base Station, or a part of several Base Stations.

Call Setup Procedures

[0083] FIGS. 5, 6 and 7 illustrate call setup procedures for a single call at an “originating” Base Station (e.g., 123), at a “receiving” Base Station (e.g., 124), and at the Switch (e.g., 129), respectively. Call setup between the handset (e.g., 121) and the Base Station it is connected to (e.g., 123) is suitably performed according to standard telephony protocols, for example ITU-T Q.931. A similar protocol is a part of the Bluetooth protocol stack. However, the present invention is not limited to a specific protocol for call setup.

[0084] FIG. 5 illustrates a call setup procedure performed by an originating Base Station (e.g. 123) when a handset (e.g., 121) that is connected to it, tries to initiate a call. As shown in the step 151, the handset that is originating the call sends a destination number (DN). In a next step 152, the originating Base Station (e.g., 123) checks whether the destination handset (e.g., 133) is in its “Base Station Connection Table”—in other words, whether the destination handset is in the originating Base Station's coverage area. If not (step 152, “N”), in a step 160 the destination number (DN) is sent via the communications link (e.g., LAN 140) to the central WPBX Switch (e.g., 129). The originating Base Station then sets a timeout (step 161), and waits for a reply from the Switch. The timeout set in the step 161 is suitably on the order of up to 5 seconds. Next, it is determined in a step 162 whether there is a timeout.

[0085] If there is a timeout (step 162, “Y”), the Base Station sends a busy indication (suitably a tone) to the originating handset (step 177), and the Switch is updated about the failure of the call (step 178). If, there is not a timeout (step 162, “N”), the originating Base Station receives (from the Switch) the address of a destination Base Station (step 163). The originating Base Station then calls the destination Base Station (step 164), and it also calls all the neighbors (neighboring Base Stations) of the destination Base Station (step 180). Then the originating Base Station sets a timeout (step 165) and waits for a reply from the called Base Station (and its neighbors). Calling more then one destination Base Station is preferred in order to overcome uncertainties during handoff. The timeout set in the step 165 is suitably on the order of up to 5 seconds. Next, it is determined in a step 166 whether there is a timeout.

[0086] If there is a timeout (step 166, “Y”), the Base Station sends a busy tone to the originating handset (step 177), and the Switch is updated about the failure of the call (step 178). If, there is not a timeout (step 166, “N”), and a reply from the destination Base Station is received, the originating Base Station checks if the call is connected (step 167), and then connects the originating handset (step 168), and updates the Switch about the success of the call (step 169).

[0087] If, in the step 163 the address of a destination Base Station is not received (N), it is determined (step 170) whether the destination of the call is the Switch itself. If so (step 170, “Y”), a procedure similar to that for sending a call to another Base Station is implemented, except that the call is sent to the Switch (step 171) and not to another Base Station. Then the originating Base Station sets a timeout (step 172) and waits for the Switch to reply (step 173). The timeout is suitably on the order of up to 5 seconds. Next, it is determined in the step 173 whether there is a timeout.

[0088] If there is a timeout (step 173, “Y”), the Base Station sends a busy tone to the originating handset (step 177), and the Switch is updated about the failure of the call (step 178). If the Switch responds that the call is connected, there is not a timeout (step 173, “N”), and the originating Base Station connects the handset (step 175), and updates the Switch (step 176) about the status of the call.

[0089] If it is determined that the destination handset is in the originating Base Station's coverage area (step 152, “Y”), and a busy signal is not returned (step 153, “N”), the originating Base Station then attempts (step 154) to connect the call to the destination handset, and also to all the neighboring Base Stations (step 181). Again, the calling of neighboring Base Stations is preferred in order to overcome uncertainties, such as the handset moving, during the call setup. Then the originating Base Station performs a procedure similar to that described hereinabove of setting a timeout (step 155), waiting for the Switch to reply (step 156), connecting (step 158) or disconnecting (step 177) the call, and updating the Switch (steps 159 or 178).

[0090] In summary, the call setup procedure performed by an originating Base Station (e.g., 123) is that, first, the originating Base Station determines whether a call request from an originating handset (e.g., 121) is:

[0091] a. to a DN in the originating Base Station's coverage area (e.g., step 152), in which case the originating Base Station attempts (step 181) to also connect the call to its neighboring Base Stations; or

[0092] b. to a DN in another Base Station's coverage area (e.g., step 164), in which case the originating Base Station attempts (step 180) to also connect the call to Base Stations which are neighbors of the destination Base Station; or

[0093] c. to a DN outside of the WPBX coverage area and is to be routed through a Gateway (see FIG. 7) associated with the Switch (steps 170, 171).

[0094] In each case, the originating Base Station then:

[0095] d. sets a timeout (steps 155, 165, 172);

[0096] e. waits for the Switch to reply (steps 156, 166, 173) that the call is connected (steps 157, 167, 174)

[0097] f. connects the originating handset (steps 158, 168, 175);

[0098] g. updates the Switch (steps 159, 169, 176) about the status of the call; and

[0099] h. waits (step 179) for a new event (a new call setup).

[0100] FIG. 6 illustrates the call setup procedure performed at a destination Base Station (e.g., 124) which is receiving a call, whether it be from another Base Station or from the Switch. When the destination Base Station receives a request (step 201) to connect a call to a handset (e.g., 133) which is reportedly within its coverage area, it first checks (step 202) whether the handset is already communicating with (connected to) it. If the handset is already connected to the Base Station (step 202, “Y”), the Base Station tries to connect the call to the handset. A timeout is set (step 203), again on the order of up to 5 seconds, and the Base Station waits (step 204).

[0101] If a time-out occurs (step 204, “Y”), or if a timeout does not occur (step 204, “N”) but the call was unable to connect (step 205, “N”), the destination Base Station returns an indication (step 208) of call setup failure (“unable to connect”) to the originating Base Station (or to the Switch, as the case may be). If, however, the connection succeeds (step 205, “Y”) the Base Station returns an indication (step 206) of successful call setup (“call connected”) to the originating Base Station. In either case (call connected, unable to connect), the destination Base Station sends similar indications (steps 211, 212, respectively) to all the neighboring Base Stations of the originating Base Station Again, sending the reply to the neighboring Base Stations is to overcome uncertainties during handoff. In both cases the Switch is updated at steps 207 and 209, respectively. Finally the Base Station waits (step 210) for a new event (a new call setup).

[0102] FIG. 7 illustrates the call setup procedure performed at the Switch (e.g., 129). The Switch handles two types of messages, one is a request to establish a new call, and the other is an update to the status of the call. In a step 231, it is determined whether the request is for a new call (step 231, “Y”) or a request to update a call (step 231, “N”).

[0103] If the arriving message is a request to update a call (step 231, “N”), an update of the “Calls Table” is generally required (step 254, “Y”). The Switch checks if it receives indication that the call is connected (step 255). If the call is connected, (step 255, “Y”), the status of the call is updated in the Calls Table (step 256). Otherwise (step 255, “N”), the call is removed from the Calls Table (step 257).

[0104] If the arriving message is a request to initiate a new call (step 231, “Y”), the Switch checks if the call is intended to a handset connected to the WPBX (step 232). This is done by checking its “Connections Table”. If the call is intended to connect to outside the WPBX (e.g., via the PSTN 136), the Switch checks (step 233) if the destination number (DN) is a legal (valid) number. If the DN is a valid number (step 233, “Y”), in a step 234 the Switch transfers the call to the Gateway (e.g., 135), sets a timeout (step 235) and waits (step 236). If not (step 233, “N”), the program exits.

[0105] If the connection via the Gateway succeeds (step 236, “N”), it is whether the call is connected determined (step 237). If the call is connected, (step 237, “Y”), the Switch requests from the originating Base Station to transfer the call to the Switch(step 238), and waits for connection with originating Base Station (steps 239, 240). If connection succeeds, and the call is connected (step 242, “Y”), the call is added to the “Calls Table” (step 243), and the call is routed to the Gateway (step 244). If connection fails (step 240, “Y”; or step 242, “N”), the connection with the Gateway is disconnected (step 241).

[0106] If the call destination is one of the Base Stations (step 259), its source may be another Base Station (step 249), or the Gateway (step 245). If the source is another Base Station, the Switch send to the originating Base Station the address of the destination Base Station, and adds the call to the “Calls Table”. If the call arrived from the Gateway the Switch tries to connect the call to the destination Base Station (step 245). If is succeeds the call is added to the “Calls Table” (step 252), the call is transferred to the destination (step 253). If it fails the connection with the Gateway is disconnected.

[0107] The procedure described in FIG. 7 is also applicable to the case when more than one Gateway connects to the WPBX to the PSTN—for example, in a case where two branch offices share a single WPBX, and each has its own independent connection to the PSTN. The main difference would be that when the Switch handles an outgoing call, it will determine to which Gateway to send the call. This can either be done randomly, or can be pre-determined. The handling of the incoming calls would proceed as set forth above in FIG. 7.

[0108] FIGS. 5, 6 and 7 have illustrated a call setup procedure for the handling of a single call. When either the Base Stations or the Switch need to handle more then one call, several instances of these procedures can be run in parallel. For that purpose, both Base Station software and Switch software are preferably based on a real time operating system that supports multi-tasking. For each new call, a new task will be created, and the task will perform the procedures described in FIGS. 5, 6 and 7. The task will be closed when the procedure is completed.

[0109] In systems with a very large number of Base Stations, due to limited processing power of each Switch, it may be preferable to divide the Switch into two or more units. Dividing the Switch into several units can also improve the reliability of the WPBX, by eliminating the possibility of having a single point of failure shutting down the entire system.

[0110] FIG. 22 illustrates the division of the Base Stations, into two groups; a first group (Group A) 1050 comprising a plurality (four shown) of Base Stations 1050a , 1050b , 1050c and 1050d ; and a second group (Group B) 1051 comprising a plurality (four shown) of Base Stations 1051a , 1051b , 1051c , 1051d . The Base Stations of Group A are connected to a first Switch (Switch A) 1052, and the Base Stations of Group B are connected to a second Switch (Switch B) 1053. The Base Stations and the Switches function according to the procedures described in FIGS. 5, 6 and 7. All the Switches mirror all the status tables of the other Switches, i.e. by having copies of each other's “Calls Table” and “Connections Table”. When a Switch updates one of its status tables, it sends the information to all the other Switches, and they update their tables accordingly. In order for this process to be reliable, the other Switches will send an indication that the message was received. If the originating Switch does not receive such a reply within T₁ milliseconds, it will retransmit the message. The retransmission will be repeated up to P times. For example T₁ shall be equal to 100, and P shall be equal to 5.

[0111] It is within the scope of the invention that more than two Switches, and corresponding more than two groups of Base Stations can be employed. As described hereinabove, all of the Switches would mirror and update each other's status tables. The description of two Switches 1052 and 1053 is intended to be exemplary rather than limiting.

Calls Table

[0112] The Switch (129) maintains the “Calls Table”, which contains the status and information about all the active calls being handled by the WPBX. The “Calls Table” comprises the following information:

[0113] 1) Each active call has a unique “Call Identification number”.

[0114] 2) The origin of the call, which can be either “Internal” or “External”.

[0115] 3) The destination of the call, which can be either “Internal” or “External”.

[0116] 4) “Calling Number Identification (CNID)”, the number of the calling party, if available.

[0117] 5) Destination Number (DN), the number of the answering party if available.

[0118] 6) “Originating Base Station Identification” for calls from internal origin

[0119] 7) “Destination Base Station Identification” for calls with internal destination,

[0120] 8) Status of call—initiated, connected, disconnected.

[0121] 9) Additional information for billing, performance analysis, such as call starts time, number of handoffs, time since last handoff, etc.

[0122] The “Originating Base Station Identification” and the “Destination Base Station Identification” are updated when a handset moves from one Base Station to another. The Switch updates these fields when it determines that the handoff should occur. During handoff, for a short time, there may be uncertainty about the validity of these fields. The Base Stations compensate for the uncertainty by “multicasting” the call setup messages to a group of Base Stations, as described hereinabove with respect to FIGS. 5 and 6 (see, e.g., steps 180, 181, 211, 212).

[0123] The procedures described above do not limit the WPBX from handling all unique telephony features that the Gateway and the handsets can support. For example, multiple connections can be created between handsets, and between handsets and the Gateway, when each connection is treated as a separate call. Another example is “Caller ID”, that the Gateway can send to a handset. Another example is a “Hook-Flash” (momentary disconnect) that the handset can pass to the Gateway. The WPBX acts as a transparent relay for all these telephony features.

High-Level and Low-Level Protocols

[0124] In the descriptions set forth hereinabove, it has generally been assumed that:

[0125] 1. Each Base Station knows which handsets are in its coverage range.

[0126] 2. The Switch is aware of the connections of all the Base Stations.

[0127] 3. Connections appear static to users and also to the high-level call setup procedures described above.

[0128] A method to achieve mobility, which fulfills these three assumptions is described in detail, hereinbelow.

[0129] According to the invention, the short-range communication protocol stack is divided into two parts:

[0130] low-level protocols performing real time tasks, and

[0131] high-level protocols that do not have real time requirements.

[0132] For example in the Bluetooth short-range communication protocol stack, the low-level protocols are the radio frequency (RF) transmitter and the base-band controller. The base-band controller performs real time control over the RF, since the Bluetooth protocol utilizes frequency-hopping transmission. The base-band protocol also determines, for each time slot of transmission (i.e. each frequency hop), what information will be transmitted. The base-band protocol also deals with voice coding, error correction, encryption and authentication. For example, higher level protocols of the Bluetooth stack include the “Link Manager” which determines what information will go through the channels created by the “Base-Band”, and determines the state of operation (e.g. Active, Polling, Parked).

[0133] The low-level protocols that require real time capabilities are performed in the Base Station. The higher-level protocols are performed at the Switch. (However, as described hereinbelow, certain high-level protocols can also be performed in the Base Station, even though they do not require real time capabilities.) The Switch handles the routing of data from the higher-level protocols to the lower level protocols. (A call routing task (282) is described in greater detail hereinbelow.) Therefore, the higher-level protocols do not need to “know” in which Base Station the lower level protocol that they are controlling is being performed.

[0134] FIGS. 8A and 8B illustrate an example of a WPBX system 800 with two handsets 121 and 133, two Base Stations 123 and 124, and one Switch 129. In this example, two calls are being handled. Gateways (e.g., 135, 137) are omitted, for illustrative clarity. As mentioned hereinabove (see, e.g., FIG. 22), the Switch can be divided into several units.

[0135] As illustrated in FIG. 8A, the handset 121 is currently communicating with (connected to) the Base Station 123, and the handset 133 is currently communicating with the Base Station 124. An instance 280 of the low-level protocol is running on the Base Station 123, and another instance 281 of the low-level protocol is running on the Base Station 124. Each instance of the low-level protocol supports only one call. In a similar manner, the Switch 129 handles an instance 283 of the high-level protocol for the call with the with the handset 121, and another instance 284 of the high-level protocol for the call with the handset 133. A single call routing task 282 handles the data that is transferred between the instances of the low-level protocols and the high-level protocols to the correct destination.

[0136] As illustrated in FIG. 8A, the call routing task 282 routes data arriving from instance 280 of the low-level protocol to instance 283 of the high-level protocol, and from the instance 281 of the low-level protocol to the instance 284 of the high-level protocol. Since interaction between the high-level-protocol and low-level protocol, is normally relatively rare (e.g. call setup), there are no strict real time requirements from the call routing task. The call routing task 282 is described in greater detail hereinbelow, with respect to FIG. 12.

[0137] As illustrated in FIG. 8B, the handset 133 is shown as having moved to the area covered by the Base Station 123. The Base Station 123 will handle the communication with the handset 133, by creating a copy 281′ of the instance 281 of the low-level protocol, that previously ran on Base Station 124. This allows the handset 133 to continue communication without “knowing” that a changeover of Base Stations has occurred. The call routing task 282 will now route the data arriving from the instance 281′ of the low-level protocol running on Base Station 123 to the instance 284 of the high-level protocol 284 which is running on the Switch 129.

[0138] For each connection of a Base Station with a handset, there is a separate instance of the low-level protocol running at a Base Station connected to the handset, and a corresponding separate instance of the high-level protocol running at the Switch. These instances are created, on an as-needed basis, when a connection is initiated. Preferably, a real time multi-tasking operating system is used in order to allow handling of many instances of the protocols simultaneously in the Base Stations and in the Switch. The procedures that the Switch uses during initiation of a connection and later, during handoff, are discussed in greater detail hereinbelow.

Synchronization of Base Stations During a Handoff

[0139] There follows a description of procedures that are performed during handoff of a call from one Base Station to another Base Station. The Base Station with which a handset is currently connected is termed the “current” Base Station. The Base Station to which a handset is being handed off is termed the “next” Base Station, and is typically a “neighboring” Base Station. Once the handoff has occurred, this neighboring/next Base Station becomes the “current” Base Station and the Base Station from which the handset has moved becomes the “previous” Base Station.

[0140] According to an aspect of the invention, the handsets do not need to be (and preferably are not) specially equipped or enabled to support mobility (i.e. handoff). Therefore, when a handset moves from one Base Station to another, the current and the next Base Stations are responsible for continuing the communication with the handset, preferably with no noticeable interruption in the communication, and the next Base Station to which the handset has moved should transmit substantially exactly as the previous Base Station from which the handset has moved would have transmitted. For purposes of the discussion of this example, it is assumed that it is known from which Base Station the handset has moved and to which Base Station the handset is moving, and that the exact timing of handoff is also known. These issues are discussed in greater detail hereinbelow.

[0141] FIGS. 9A, 9B and 9C illustrate, in a general manner, a handoff taking place between two Base Stations 123, 124 and a single handset 121 of a WPBX.

[0142] FIG. 9A illustrates the handset 121 communicating with (connected to) a Base Station (Base Station #1) 123 via a short-range communication link 122 (e.g. Bluetooth wireless link). The “current” Base Station 123 sends call parameters and rough synchronization information over the LAN 140 to the neighboring Base Stations, a one of which is shown as Base Station #2 124. In this manner, the neighboring Base Stations “know” that they are “candidate” Base Stations for receiving a handoff of the call from the current Base Station. The information which is broadcast by the current Base Station to the candidate next Base Stations includes low-level communications protocol states and parameters, discussed in greater detail hereinbelow. This communication from the Base Station 123 to the Base Stations 124 is indicated by the arrow 141, and the information contained therein is used to achieve rough (coarse) synchronization between the Base Stations. Since this information does not need to be accurate in time, it can be transmitted over the data link (e.g., LAN 140) connecting all of the Base Stations.

[0143] FIG. 9B illustrates a handoff as it is about to take place. Here, the handset 121 is situated in an area covered by both Base Stations 123 and 124. Base Station 124 uses this situation to achieve exact (fine) synchronization with the current Base Station 123. This will enable the next Base Station 124 to transmit, after the handoff, substantially exactly as previous Base Station 123 would have transmitted if the handoff had not occurred. A method for effecting this fine synchronization between neighboring Base Stations is discussed in greater detail hereinbelow.

[0144] An important parameter of synchronization is Time Of Day (TOD), which can be determined with virtually any desired level of precision (e.g., microseconds). As described in greater detail hereinbelow, in order to achieve fine synchronization of TOD, the Base Station 124 that is waiting for the handset 121 may passively monitor the transmissions of either the handset 121, or of the Base Station 123 that is currently connected with the handset. In FIG. 9B, the two possible fine synchronization signals that the candidate next Base Station #2 124 can monitor are shown, a signal 142 originating from the Base Station #1 123, and another signal 143 originating from the handset 121.

[0145] FIG. 9C illustrates that synchronization of the Base Stations 123 and 124 may alternatively be achieved by use of a beacon signal from a beacon transmitter 299 which is within range of current and next Base Stations, in which case precise (fine) synchronization for the low-level protocols can also be achieved. The beacon transmitter 299 transmits a beacon signal 144 to both of the Base Stations 123 and 124 to achieve synchronization of the Base Stations. This method allows for the synchronization of many Base Stations, although only two are illustrated in this figure. In this case, there is no need to transmit synchronization information over the LAN 140. Only call parameters (e.g., low-level protocol) need to be communicated between the current Base Station and the neighboring candidate next Base Stations, as indicated by the arrow 141′.

Bluetooth Short-Range Wireless Communication Protocol

[0146] As discussed hereinabove, a short-range communication protocol with the handset can be divided into lower-level protocols which the Base Stations handle, since they have real time requirements, and higher-level protocols which the Switch handles since they do not require real time requirements. Bluetooth wireless technology is an example of such a short-range communication protocol. In Table 1, a division of the Bluetooth short range wireless protocol into such low-level and high-level protocols is presented. 2

[0147] Table 1 shows the elements of the Bluetooth protocol, generally, as currently implemented. Other profiles may be added in the future (or may have already been added), and it is anticipated that these profiles will be high-level protocols, which do not have strict real time requirements.

[0148] As shown in Table 1, the Link Manager and the Host Controller Interface can be implemented in either the Base Station or in the Switch. Although the Link Manager and Host Controller Interface, do not require real time performance, they may readily be implemented in the base-band controller of the Base-Station. It is within the scope of the invention that any of the high-level protocols can also be implemented in the Base Station as part of the low-level protocol, but then they will take part in the handoff.

[0149] According to the inventive technique of dividing the low-level and high-level protocols, the high-level protocols are “buffered” from the occurrence of handoff by the Base Stations and the routing task that runs on the Switch. Therefore, the present invention allows mobility of any device with Bluetooth wireless technology that supports any of the high-level protocols (e.g. LAN access, WAP, FAX, FTP). The solution for mobility of cordless phones, described hereinabove, is only an example of how the methods can be utilized.

[0150] As described hereinabove with respect to FIGS. 8A and 8B, different instances of the low-level protocols that represent the same connection (e.g., 281, 281′) need to be synchronized. Table 2, presents elements (parameters) of the low-level protocols that the Base Stations will synchronize. For each element, it also shows whether rough or fine synchronization is required. Again, the protocols are described, by way of example, in the context of the Bluetooth short-range communication protocol.

[0151] Rough synchronization may be achieved via the local area network (see, e.g., LAN 140, FIGS. 9A and 9B) connecting the Base Stations. Fine synchronization may be achieved by other methods described in greater detail hereinbelow. 3

[0152] All the parameters listed in Table 2, except for the TOD, can be sent prior to handoff, thorough the local area network (e.g., LAN 140), or any other communication link connecting the Base Stations. As described hereinabove with respect to FIG. 9A, rough (coarse) TOD can also be sent through the LAN.

[0153] If one of the other parts of the Bluetooth protocol stack is also implemented in the Base Station, then it will also take part in the handoff. Synchronizing the instances of the same protocols in different Base Stations is done as described above, by sending internal state parameters via the local area network (LAN 140). For example, by implementing the Link Manager and Host Controller Interface in the Base Station, the internal state parameters of these protocols will be broadcast to the neighboring Base Stations, by the Base Station that is connected to the handset.

Fine Synchronization

[0154] As mentioned hereinabove, in order to achieve fine synchronization of TOD, the Base Station that is waiting for the handset, should passively monitor the transmission of the handset and/or the Base Station that is currently connected with the handset. In FIG. 9B, the two possible signals that the receiving (next) Base Station 124 can monitor are shown, one originating from Base Station 123, and the other originating from the handset 121 which is currently connected to the Base Station 123.

[0155] According to the invention, the next Base Station 124 can be finely synchronized by receiving synchronization signals from the current Base Station 123. Normally, the Base Station 124 does not receive signals from the Base Station 123. Therefore, to facilitate the Base Station 124 receiving synchronization signals from the Base Station 123, Base Station 123 periodically transmits with higher transmission power than during normal transmission. This allows the Base Station 124 to receive transmissions from Base Station 123, without a substantial increase in spectral contamination. The inventive technique is described in the context of frequency-hopping. Frequency-hopping techniques are well known, including techniques that change frequency with each hop.

[0156] FIG. 10 illustrates a technique for controlling the transmission power of a Base Station (e.g., 123) that is currently connected with the handset, for a plurality (series) of successive hops 290. The vertical axis of the graph is the Base Station's transmission power (in arbitrary units), and the horizontal axis is time. T_h is the duration of a hop 290. In this example, the hops 290 all have equal duration. T_p is the time interval between successive hops (or “hop time slot”) and, in this example, the intervals between successive hops are constant (evenly spaced in time). The normal transmission power for each hop 290 is P₀. For example, in a short-range communication system, the normal transmission power P₀ of a Base Station is suitably on the order of a hundreds of milliwatts.

[0157] According to the invention, in order to effect synchronization between a Base Station and its neighboring Base Stations, every Kth hop 290′ is a “synchronization” hop that is transmitted with increased power P₁. P₁ is suitably substantially (e.g., 2-10 times) greater than P₀. In the case that the transmitter changes the transmission frequency in each hop, every Kth (synchronization) hop will also be transmitted at a different frequency.

[0158] Alternatively, it is within the scope of the invention that a variable time interval (T_p) is provided between the synchronization hops 290′ that are transmitted with high power P₁. For example a changing K (that shall be denoted by K(n), i.e. K for hop number ‘n’), can be generated by a pseudo random sequence such as a maximal length shift register sequence. Pseudo random sequences are well known for use in communication systems.

[0159] In the case that a beacon transmitter (e.g., 299) is used (in addition to signals received from the Base Station and handset) to synchronize the Base Stations (see, e.g., FIG. 9C), it can suitably transmit the beacon signal once in K hops, and K can either be constant or it can be changed over time (variable), as described above.

Low-Level Synchronization at the Base Station

[0160] FIG. 11 illustrates major components of a Base Station 1100 waiting for handoff, and a method of accurately synchronizing the TOD at the Base Station to the TOD of the Base Station which the handset is about to leave, including:

[0161] Time Clock 310;

[0162] TOD counter 303;

[0163] Antenna 301;

[0164] Receiver 305;

[0165] Frequency Hopping Generator 304;

[0166] Emulator 307;

[0167] Correlation Detector 308; and

[0168] Adder (ADD) 309;

[0169] all connected as illustrated in the figure and as discussed hereinbelow.

[0170] As described hereinabove with respect to FIG. 9A, a rough TOD from the Base Station currently connected with the handset is available to the (next) Base Station waiting for a handoff on a communication link such as the LAN 140. This rough TOD is provided to the TOD counter 303 (e.g., via an interface to the LAN 140). A Time Clock 310 generates clock signals for incrementing the TOD counter 303. The output of the TOD counter 303 is therefore a rough estimate of the TOD (“TOD Estimate”). There is an uncertainty (margin of error) “Tu” between the rough estimate of TOD and the actual TOD, and which depends on the transmission latencies thorough the LAN 140. “Tu” is readily calculated for a given WPBX system, according to its physical configuration.

[0171] From the rough estimate of the TOD output by the TOD counter and the device address (“Commonly denoted by Media Access Control Address, or MAC address”,), a frequency-hopping list is generated by a frequency-hopping generator 304 and supplied to an emulator 307 which emulates the output of the receiver 305. In a window with size of 2·T_u, a single frequency from the hopping sequence is chosen, and the receiver 305 will wait on this frequency for duration of 2·T_u. Once in a period of 2·T_u, the receiver 305 will switch frequency, in response to a signal generated by the frequency-hopping generator 304. Opening an acquisition window of 2·T_u, ensures that during this time duration the receiver 305 will capture at least one hop. A correlator/detector 308 receives the receiver's output (e.g. a base-band or intermediate frequency signal) and an emulation 307 of the signal that should appear at the receiver's output. The output of the receiver 305 can be emulated, since a rough estimate of the TOD is available, and also from the hopping frequency list, and the receiver frequency list. The emulator 307 continuously checks for a match between receiver frequency and the hopping frequency and, when it finds a match, it reports the frequency and the time (rough TOD) to the correlator/detector 308. By comparing the actual received signal with the emulation that is based on the rough TOD, the correlator 308 computes (and outputs) a fine estimate of the TOD offset (i.e., the error between the TOD estimate and the actual TOD), and provides this to Adder 309, which also receives the rough TOD estimate from the TOD counter 303 and generates a signal (“Fine TOD”) indicative of the actual TOD. Correlator-based time offset measurement is a standard estimation method that is described in many textbooks, and an example of its implementation is described in greater detail hereinbelow.

[0172] Since the Base Station to which the call is to be handed “knows” which call it is going to receive, and it has received the call parameter (via the LAN), and is able to accurately estimate the TOD, it will be able to perform a seamless handoff, transmitting substantially exactly as the Base Station that the handset is about to leave. As mentioned above, an iteration of the low-level protocol (e.g., 281′) can be prepared at the receiving Base Station in anticipation of the handoff.

Call Routing Task (282)

[0173] The higher-level protocols are run at the Switch, and are therefore “ignorant” of the handoff processes. At the Switch the “call routing task” 282 (FIGS. 8A, 8B) isolates the high-level protocols from the changing environment. The “call routing task” 282 maintains the “Connections Table”, which contains information about all the connections between handsets and Base Stations. Maintaining the Connections Table is described in greater detail hereinbelow. The following sections describe an example of how the Connections Table is used by the “call routing task” 282.

[0174] The following information is included in the Connections Table:

[0175] 1) Handset ID

[0176] 2) Current Base Station ID

[0177] 3) Handle (of instance) of high-level protocols

[0178] 4) Handle (of instance) of low-level protocols

[0179] 5) Number of candidate Base Stations for handoff

[0180] 6) List of candidate Base Stations for handoff

[0181] 7) List of Handoff status for each candidate Base Station (i.e., Idle/Started)

[0182] The messages that the high-level protocol (that runs on the Switch) and the low-level protocol (that runs on the Base Station), send each other have the following format:

[0183] 1) Message Header

[0184] Origin:

[0185] from low-level protocol

[0186] from high-level protocol

[0187] Handset ID

[0188] Base Station ID

[0189] Low-Level Protocol Handle in the Base Station (number of instance of low-level protocol)

[0190] High-Level Protocol Handle in the Switch, (number of instance of high-level protocol)

[0191] HEC (header error correction)

[0192] 2) Message Data

[0193] 3) CRC (Cyclic Redundancy Check)

[0194] FIG. 12 illustrates a method of implementing the “call routing task” 282 which was mentioned hereinabove with respect to FIG. 9A. The “call routing task” 282 is performed in the Switch 129.

[0195] In a first step 351, the call routing task 282 waits for a message from one of the high-level protocol instances running on the Switch 129 or from one of the low-level protocol instances running on the Base Stations (e.g., 123). Then, in a step 352, it is determined where the call came from.

[0196] If the message arrived from one of the Base Stations (step 352, “Y”), the call parameters are compared with the Connections Table (step 353) and the message is sent (step 354) to the instance of the high-level protocol running on the Switch (129).

[0197] If the message arrived from the Switch (step 352, “N”) the ID of the sending low-level protocol instance is located (step 353) in the “Connections Table”, and the message is sent (step 354) to an instance of a corresponding high-level protocol. If the message arrived from one of the high-level protocols (step 352, “N”), it is determined (step 360) whether a handoff has begun (is in progress). If a handoff is not in progress (step 360, “N”), the call parameters are compared with the Connections Table (step 358) and the message is sent to the Base Station on which the destination low-level protocol instance is running (step 359). If a handoff is in progress (step 360, “Y”) the call parameters are compared with the Connections Table (step 355) and the message is sent to the Base Station on which the destination low-level protocol instance is runnin