Patent Application
20130281022
The applications identified above in the section entitled “Cross Reference to Related Applications” are hereby incorporated by reference in their entirety. The following applications and Appendices are also hereby incorporated by reference in their entirety.
1. Technical Field
The present invention relates generally to wireless communication systems; and more specifically, to low power wireless networks that include a plurality of wireless devices, such wireless devices used in data collection applications, parcel delivery applications, and such other applications that require wireless communication between a plurality of portable devices.
2. Related Art
Wireless networks are well known in the art. Wireless networks are typically implemented in conjunction with an infrastructure network wherein a plurality of base stations (access points) allow wireless devices to communicate with the infrastructure network. The base stations provide wireless communications within respective cells and are typically spaced throughout a premises or area to provide wireless communications throughout the premises or area. Within the premises or area, wireless devices may communicate with devices connected to the infrastructure network. Further, the base stations and the infrastructure network facilitate communications between wireless devices operating within the premises or area.
Within the wireless networks, portable wireless devices communicate with the base stations. For example, in a data gathering application within a premises, a wireless data terminal communicates with one or more of the base stations when requiring communication with devices connected to the infrastructure network. Further, the wireless data terminal may communicate with other wireless devices connected to the wireless network via one or more base stations. However, such communications require relatively high power transmissions. Thus, because the portable data terminal is battery powered, the high power transmissions may significantly reduce battery life.
Wireless communications are generally managed according to an operating protocol. Most of these operating protocols require ongoing wireless activity. Such ongoing wireless activity, even merely to receive transmissions, further shortens battery life in battery powered portable devices, reducing the duration within which the devices may operate or requiring more frequent recharging or battery substitution.
Additional concerns in wireless communication relate to synchronization of radio timing. Such synchronization becomes especially critical in the management of wireless communications wherein scheduling future coordinated activities proves important to carry out operations or power saving strategies. Wireless devices typically provide their own timing mechanisms; however, it is common for the timing mechanisms to vary in their operations from device to device so that they fail to provide an accurate reference for synchronization.
Thus, there exists a need in the art for improved wireless communications, particularly with portable devices that operate with battery power. Further, there exists a need in the art for wireless communications which provide stable synchronization of wireless transmissions but also allow portable devices to conserve battery power while operating according to established protocols.
These and other objects of the present invention are achieved in a low power wireless communication (personal LAN) system constructed according to the present invention. The personal LAN includes a plurality of wireless devices with each wireless device including a radio transceiver. The radio transceiver may take the form of an insertable card that fits within a slot in the wireless device. In operation, the plurality of wireless devices establish a wireless network. In the wireless network, at least two of the plurality of wireless devices share beaconing responsibilities to coordinate operation of the wireless network.
In the personal LAN, the beacons are provided on a periodic basis with at least two of the plurality of wireless devices sharing beaconing responsibilities. The beaconing responsibilities may be shared on a round robin basis or may be shared according to the operating characteristics of the wireless devices with some wireless devices assuming greater beaconing responsibilities than other of the wireless devices.
The plurality of wireless devices may include a primary beaconing wireless device. In such case, other wireless devices of the plurality of wireless devices coordinate their wireless communications to beacons provided by the primary beaconing wireless device. Further, the other wireless devices may coordinate low power operations to beacons provided by the primary beaconing wireless device. In this fashion, the other wireless devices may enter low power operations for multiple beacon cycles of beacons provided by the primary beaconing wireless device. The other wireless devices may also coordinate lower power operations based upon the contents of beacons received from the primary beaconing wireless device. The other wireless devices may also adjust timing parameters based on actual measurements so that they wake up appropriately from low power operations to receive the beacons from the primary beaconing wireless device.
The primary beaconing wireless device may also coordinate communications among the plurality of wireless devices. Alternately, the other wireless devices may coordinate their own communications but with reference to the beacons of the primary to beaconing device. Further, beaconing responsibilities may be coordinated to satisfy wireless device limitations. For example, should one of the wireless devices face an operating condition which prevents it from providing beacons, its beaconing responsibilities may be passed to other of the wireless devices.
At least one of the wireless devices may also communicate with an infrastructure network at a relatively higher power level. In this fashion, at least one wireless device may communicate with another wireless network via the infrastructure network.
In another embodiment of the personal LAN, one of the plurality of wireless devices may separate from the wireless network to become a separated wireless device. In such case, at least one of the wireless devices attempts to reestablish communications with the separated wireless device. Further, the separated wireless device may also attempt to reestablish communication with the wireless network. Such operations are accomplished with predetermined operations that are initiated upon sensing the separation.
In attempting to rejoin the wireless network, the separated wireless device may camp on a predefined channel, waiting for a beacon signal from at least one of the plurality of wireless devices with the separated wireless device rejoining the wireless network in response to receipt of the beacon signal. In another operation, the separated wireless device may scan a plurality of predetermined control channels for a beacon signal and may rejoin the wireless network in response to receipt of the beacon signal.
Should the separated wireless network device fail to rejoin the wireless network, it may selectively join another wireless network. Alternatively, the separated wireless network device may establish wireless communication with an infrastructure network.
In still another embodiment of the personal LAN, at least two of the wireless devices may separate from the wireless network to form an alternate wireless network separate from the wireless network. In such case, the at least two wireless devices of the alternate network may rejoin the wireless network after the separation. For example, the at least two wireless devices may form the alternate network when they are physically separated from the other wireless devices and rejoin the wireless network when in proximity to wireless devices of the wireless network.
When separated, at least one of the plurality of wireless devices not in the alternate wireless network may transmit beacon signals intended for the at least two wireless devices forming the alternate wireless network. These beacons signals may be transmitted on at least one control channel. In transmitting these beacon signals, the plurality of wireless devices may establish a beaconing pattern to coordinate operation of the wireless network prior to separation of the at least two wireless devices. After separation, the at least two wireless devices of the alternate wireless network may then continue transmission of the beaconing pattern. Then, the at least two wireless devices may recognize the wireless network based upon identification of the beaconing pattern.
In a further embodiment of the personal LAN, each wireless device includes a radio transceiver capable of transmitting at both a higher power level and at a lower power level. In the embodiment, the plurality of wireless devices establish a wireless network when proximate to one another and operating at the lower power level. Further, after establishment of the wireless network, the plurality of wireless devices communicate within the wireless network at the higher power level.
In the personal LAN, the plurality of wireless devices establish the wireless network when in a first proximity to one another. Further, the plurality of wireless devices communicate within the wireless network when in a second proximity to one another, wherein the first proximity is less than the second proximity. One of the plurality of wireless devices separates from the wireless network when it moves outside of the second proximity.
Further, in the embodiment, at least one of the wireless devices may also communicate with an infrastructure network. Such communications with the infrastructure network occur at a power level greater than the higher power level.
The present invention also includes a method of establishing a wireless network. The method includes selecting at least two wireless devices from a plurality of wireless devices, each capable of participation within the wireless network in a higher power mode, placing the at least two wireless devices in close proximity to one another, the at least two wireless devices interacting in a lower power mode to establish the wireless network, and returning to the higher power mode for wireless network communications.
Moreover, other aspects of the present invention will become apparent with further reference to the drawings and specification which follow.
A better understanding of the present invention can be obtained when the following detailed description in conjunction with the following drawings, in which:
More specifically, a hand held device 105, a data collection device 107, a printer 109, and a personal digital assistant (PDA) 111 participate in distributed beaconing. The beacons that are transmitted by the devices 105, 107, 109, and 111 are primarily used for synchronization and identification purposes. Typically, one network device transmits a sequence of beacons while the other network devices synchronize to selectively receive the beacons. In the period between any two consecutive beacons, the network devices 105, 107, 109 and 111 selectively transmit and receive information from each other.
The wireless personal LAN 100 might support a small number of devices, e.g., (up to 10). A user selects a set of devices to be part of the personal wireless LAN 100 and initiates an automatic configuration process whereby the devices communicate with each other to establish the personal LAN. Alternately, the user establishes the personal wireless LAN 100 by collecting the desired devices and requesting the formation of the personal wireless LAN 100 via one of the devices such as the data collection device 107. The data collection device 107, through wireless interaction with the collected devices, delivers a list of candidate devices to the user for selection. Thereafter, through the data collection device 107, or through other initiating device, the personal wireless LAN 100 is formed. Alternatively, the personal wireless LAN 100 may be established using search and rescue operations as further described below.
In many environments, the selection of a set of devices is made from a great number of available devices. To prevent unselected devices from complicating or confusing network formation, the devices are all placed in very close proximity before initiating formation. Communication regarding formation takes place at very low power, avoiding unintentional participation by the unselected devices.
Specifically, in one embodiment of the personal LAN initialization activity, one of the devices in the personal LAN 100, such as the data collection device 107, sends an “initiate frame” to establish a personal LAN at a very low power level, perhaps reaching receivers no more that a few feet away. This frame is always broadcast, and it includes a type field indicating the type of network being created, and a network identification to identify the personal LAN being created. Devices receiving this frame will determine whether they want to join the personal LAN being initiated and request to join by sending an “attach request frame.” The attach request frame is broadcast using the network identification, and includes the address of the sending device. After receiving attach request frames from the other devices, the data collection device 107 sends an “attach response frame” (indicating acceptability of a device) to the devices that are to be included, the personal LAN 100.
The personal wireless LAN 100 operates in the vicinity of a high density of overlapping networks. For example, in one embodiment 15 to 20 personal wireless LANs can simultaneously independently operate within a 300 foot area. The personal LAN can also operate in the vicinity of an infrastructure network that is typically used in a warehouse or a factory as part of the work environment.
Although in one embodiment only a single network device, such as a data collection device 107, is responsible for transmitting beacons, in other embodiments, more than one network device selectively participates in distributed beaconing. Likewise, although beaconing intervals are rather fixed (i.e., of a predetermined duration), such intervals may vary depending on the intended functionality expected during each specific interval.
When more than one network device participates in distributed beaconing, they transmit beacons in either a predetermined order or in a dynamically determined order. Again, not all the network devices need to participate in such beaconing. Some of the network devices 105, 107, 109 and 111 may choose not to participate in beaconing depending upon their status, and the power levels of their batteries, etc.
In cooperation, the beacon signal protocol established allows each of the devices 105, 107, 109 and 111 within the wireless personal LAN 100 to enter power-saving sleep modes without compromising wireless personal LAN structure or communications. The protocol also supports beacon hand-off and backup beacon functionality to support separation of a personal wireless LAN 100 into two or more subnetworks as well as the automatic reformation thereof back into a single personal LAN.
Typically, one of the beaconing devices is considered to be the network coordinator and is responsible for rescuing lost devices and allowing other devices to join the network. For example, the printer 109 can be designated as the network coordinator and made responsible for network management, network membership changes and rescue missions. Although the network coordinator may typically be the beaconing device, any non-beaconing device may take on such responsibilities as network coordinator.
In some embodiments, the network controller hands off the responsibility for rescuing lost devices to one or more of the other devices of the network. In this way, the network controller is able to perform other network management responsibilities while the one or more of the other devices assume the burden of search and rescue operations. This also proves advantageous when the network management responsibilities otherwise conflict with the search and rescue operations, and when the network management burden on the network controller is already significant.
The beacons are typically frames that include information about network time, dwell time and next beacon time. With such information a device may schedule its receiver to wake to receive a subsequent beacon and then enter a low power “sleep” mode until the time arises. In addition, beacons may also include a count of the number of beacons that have been sent or other time stamp indication. This allows a radio to occasionally take snapshots of its own clock and then at some larger number of beacons intervals later, sample the beacon count again and determine the radio's relative accuracy versus the underlying clock employed for beaconing. This allows for periodic adjustments of all network device (“radio”) clocks to that of the beaconing device.
The personal wireless LAN 100 employs frequency hopping spread spectrum transmissions. Alternately, direct sequence or hybrid spread spectrum techniques could be employed. Like wise, other transmission technologies might be employed. With frequency hopping, the available frequency band is divided into a number of channels and the transmission hop from channel to channel occurs in a specified sequence.
A few of the channels are designated as control channels, and are used for coordinating search and rescue operations of lost roaming devices, in addition to the selective transmission of control signals. The hop sequences will visit these channels more frequently. Several channels are also used to prevent a single point of failure based on interference on a single channel. In such environments, the beacons may also include hop information indicating how much time is remaining in the current dwell, the current channel, the hop table in use and the table entry.
The personal wireless LAN 100 is a low power network with a small range that makes it possible for some of the roaming devices to get out of the range of the network. When this happens, the personal wireless LAN 100 initiates search and rescue missions. In one embodiment of the search and rescue mechanism, one of the beaconing devices in the personal wireless LAN 100, the printer 109, for example, or any other device having the role of network coordinator, generates “identity” frames to provide an opportunity to the roaming devices to confirm their connectivity. Devices that receive the identity frames communicate with the network coordinator to confirm their continued participation in the personal LAN 100. For devices that do not respond to the identity frames and are determined to be “lost,” a search and rescue mission is initiated for a specified number of beacons. After this period, the network coordinator will wait for an indication of no activity involving it, and then tune to each of a plurality of control channels in succession and transmit beacon frames. Lost devices will tune to at least one of the control channels, and when they receive a beacon, they will resync to the information in the beacon and thus be recovered. Such search and rescue operations may also be employed to establish the wireless personal LAN 100 when proximal formation operations (as described above) are not desired.
The beacons are sent at fixed intervals of time. Alternately they may be sent at variable intervals. When the beacons are sent at variable intervals, they can be sent at predetermined intervals of time or at intervals specified dynamically in preceding beacons. A device that has not seen beacons in a given cycle will scan the designated control channels, waiting for beacons. Once it sees a beacon, it resynchronizes (resync's).
Devices join the personal wireless LAN 100 by sending requests to the network coordinator to join that network. The network coordinator can accept or reject the device that wants to join the network. A network device that finds itself isolated due to roaming can choose to join another network in its proximity.
In one exemplary embodiment, a single network device, such as the hand held device 105, transmits beacons at fixed beaconing intervals. The other devices 107, 109 and 111 using their synchronized radios, receive the beacons from the hand held device 105. In particular, the data collection device 107, the printer 109 and the PDA 111 use the occurrence of the beacon and the information contained therein to synchronize their clocks and to coordinate their communication with other devices. The hand held device 105 transmits a beacon and each personal LAN device stays awake for a period called the “awake time window” to receive communication from other of the personal LAN devices 107, 109 and 111. Communication is typically scheduled during the awake time window for the time period available thereafter. An exception might be small data packets of duration not justifying scheduling overhead. If no communication involving a network device is anticipated, after the awake time window lapses, the device may choose to sleep for the rest of the current beacon cycle.
The hand held device 105, as the network coordinator, periodically requests that all the other devices in the personal LAN 100 confirm their presence. It may also periodically offer other devices in the proximity of the personal LAN 100 an opportunity to join the personal LAN 100.
If the traffic on the personal LAN 100 is low, the devices on the personal LAN 100 sleep most of the time. They need to be awake to receive beacons to synchronize their clocks and during the awake time window any need to receive or to request an opportunity to send. The devices 107, 109 and 111 can choose to sleep for multiple beacon cycles and wake up for the “nth” beacon. The network coordinator 105 is typically made aware of such multiple cycle sleep modes by the devices 107, 109 and 111. All communications with a sleeping device is coordinated by the network coordinator and scheduled for the beacon cycle for which the individual device is expected to be awake.
If the battery of a device, such as the PDA 111, is replaced, the PDA 111 re-acquires the network. The personal LAN itself does not determine that the device is missing for the duration of the PDA's 111 resync time. This period can be quite long. To facilitate the recovery of such devices, the hop sequences of the frequency hopping spread spectrum protocol incorporates the control channels in the sequence more frequently than other channels. Thus a device that is lost can wait on a control channel for beacons. If the lost device is the network coordinator (the station that normally transmits beacons), then after a short number of missing beacons, another device, the data collection device 107 for example, will send backup beacons. Thus, even the lost network coordinator will be able to recover the network.
In another embodiment, the hand held device 105 acting as a network coordinator sends beacons and also forwards messages received from one device addressed to another. More specifically, if any of the devices 107, 109 and 111 need to communicate information to any other device in the wireless personal LAN 100, the originating device sends the information, along with the address of the designated recipient, to the network coordinator 105. The network coordinator 105 subsequently transfers the received information to the recipient device. Such information can be sent by the sending device to the network coordinator 105 during a designated slot in a beacon cycle or during a contention period following the beacon, when the hand held device 105 is awake to receive communication from the other devices. In this embodiment, the network coordinator 105 stores messages from the other devices and forwards them to the recipient devices subsequently. Devices that do not have to communicate can sleep immediately after a beacon. Devices that have to communicate with the network coordinator do so during the awake time window after a beacon when the network coordinator 105 listens to traffic on the personal LAN 100.
In another exemplary embodiment, the network devices 105, 107, 109 and 111 transmit their beacons employing a round-robin ordering strategy. In such a distributed beaconing environment, the hand-held device 105 first transmits its beacon, followed later by beacons from the data collection device 107, the printer 109, and the PDA 111. When one of the devices, such as the data collection device 107, decides to halt beacon transmissions, the other network devices 105, 109, and 111 continue transmitting their beacons in round-robin order. Alternately, other round robin strategies for beaconing involving multiple inclusions of specific devices within the round robin order may be employed. In this embodiment, all the devices on the personal LAN 100 stay awake for a “awake time window” that follows a beacon, during which they communicate with the beaconing device or with each other.
In a different round robin embodiment, one of the devices, such as the hand held device 105, acts as the network coordinator and broadcasts beacons that are used as the master beacon or a primary beacon. The beacons transmitted by the other devices 107, 109 and 111 are considered to be secondary beacons. The primary beacon is used for clock synchronization by all the devices on the personal LAN 100. The secondary beacons are used to identify the presence of the associated device. The loss of a secondary beacon could indicate the loss of its associated device and trigger a rescue attempt by the network coordinator 105.
Devices that participate in beacon transmissions may suspend their own beacon transmissions for several reasons. If the battery power of the data collection device 107 participating in distributed beaconing goes below a threshold level, the data collection device 107 may selectively decide to temporarily suspend transmission of its beacons. When this occurs, the other devices 105, 109 and 111 recognize the suspension of beacon transmissions by the data collection device 107. In response, the other three network devices 105, 109 and 111 continue beaconing in round-robin order. Alternately, one of the other network devices 105, 109 or 111 transmits beacons in the place of the data collection device 107.
Each of the network devices 105, 107, 109 and 111 includes a clock. For example the hand held device 105 includes a clock 113 that it uses for several purposes including scheduling communications and for sleeping multiple beacons. The devices 105, 107, 109 and 111 also include a radio card, such as the radio card 117, for communicating with each other. In most devices, a radio card operates in coordination with a microprocessor or an onboard computer (not shown). In some devices, such as “dumb” devices (such as a printer or the like), the radio operates independently of the microprocessor or host computer, and provides a wireless communication link for the dumb device. A dumb device is that which is typically designed for, or currently programmed for, wired link communications and that is generally unaware of a radio installation.
When the personal LAN separates into two different LANs, the beacon order of both LANs may be unaltered. If the clocks in each device are not synchronized with each other, it will be difficult for the devices to receive beacons. The beacons are therefore used to synchronize the clocks. Specifically, one of the beaconing devices, called the network coordinator, is considered to be the primary beaconer and its beacons are used by the other devices to calculate the difference between their clocks and the clock of the network coordinator. By determining this clock difference, each device is able to wake up just before the next beacon. The differences in the clocks can be more accurately calculated if they are measured over a large number of beacons. Therefore, each device on the personal LAN takes a snapshot of its clock periodically, and after some large number of beacons, determines its clock's relative accuracy versus the network clock transmitted by the network coordinator. This enables each device to determine the difference between its clock and the network clock more accurately.
Knowing the corrections to be made to its own clock for synchronization with the network clock enables the network devices on the personal LAN to sleep through multiple beacon cycles and still be able to wakeup in time for a subsequent beacon. Again, each device can save power by minimizing the wakeup window required to receive a beacon. This is achieved by initially selecting a wakeup window wide enough to receive the first few beacons, and gradually tightening the wakeup window so that the wakeup window starts almost exactly in synchronization with a beacon.
In establishing and maintaining communication with the infrastructure network 200, the personal LAN 203 may designate one or more of the devices 205, 207, 209 and 211 within the personal LAN 203 as an interface to the infrastructure network 200 depending upon data transmission requirements, power consumption and communication protocol constraints. In this fashion, communication between devices within the personal LAN 203 may be had without routing communications through the infrastructure network. Such operations proves advantageous in reducing network traffic on the infrastructure network 200 and allowing the devices within the personal LAN 203 to operate at a low transmitted power when communicating within the personal LAN 203. Further, such operation allows the devices 205, 207, 209, and 211 within the personal LAN 203 to communicate when outside the range of the infrastructure network 200.
Alternately, one or more devices that are part of the wireless personal LAN 203 acts as an access point to the infrastructure network 200. For example, the base station 227, while participating in the infrastructure network 200, may also participate in the personal LAN 203. It can communicate with another base station 225 and the host computer 223. It can also communicate with the hand held device 205, the data collection device 207, the printer 209 and the PDA 211 over the low powered personal LAN 203. Thus, while being part of the low powered wireless personal LAN 203, the base station 227 also participates in the high powered infrastructure network 200. The base stations 227 and 225 each may establish a respective personal LAN or communication cell. The base station 227 plays the role of a wireless access point. It may participate with a multi-hop wireless network that includes the other base station 225.
To initiate the personal LAN 203, the base station 227 or one of the devices assembled together for the personal LAN, such as the hand held device 205, transmits an initiate command. The initiate command would include the network id to use for the network, the data rate, the type of network, the power level to be used, the information being sent to potential joiners, and the length of the information being sent. In an exemplary initiate command, the type of the network could be specified as a personal LAN or as infrastructure network, the data rate could be specified as 250 Kbps or 1000 kbps, and the power level could be specified as one of 3 for full power, 2 for −20 db, 1 for −40 db, or 0 for −60 db. To establish a personal LAN, the data rate would be specified as 1000 kbps, the type of the network would be a personal LAN, and the power level could be set to the lowest power level. In the case of distributed beaconing personal LANs, the initiate command includes solicitation of information on a device's ability to beacon.
The device sending the initiate command, the base station 227 or the hand held device 205, then waits for the attach requests from the other devices in its proximity. The devices that receive the initiate command may choose to reply using an attach request. The attach request would include an address of the requesting device, the type of the remote device that identifies one of several possible radio modules, the information that the remote devices needs to pass to the initiating device, and the length of that information. In the distributed beaconing situation, an attach request also includes information on the device's ability to participate in distributed beaconing. The initiating device, such as the hand held device 205, then sends a join response to indicate acceptability of a remote device in the personal LAN that is being initiated. The join response includes the address of the remote device and a status field indicating acceptance or rejection. In the distributed beaconing situation, the join response also includes information on the device's role in distributed beaconing.
Subsequently, once the base station 227 or the hand held device 205 has determined that all required devices have joined the personal LAN being initiated, a start network command is sent. The start network command includes the dwell time of network in network ticks, where one tick is approximately 30.5 microseconds for an exemplary embodiment. It also includes a device resync time, which is the number of beacon intervals between attempts to recover missing devices from the network, the beacon interval in terms of frequency hops, the number of devices likely to transmit in any dwell interval, and a mode indicating the type of network—personal LAN or infrastructure. The start network command is also used to restore old networks.
The devices receiving the start network command from the base station 227 or the hand held device 205 send a start network response that includes information on the success or failure in starting the new network. For old networks being reinitiated, the start network response indicates the success or failure in reinitiating an old personal LAN or infrastructure network.
In operation, after initialization of the personal LAN's 203 operation, each of the devices 205, 207, 209, and 211 communicates with each other within the personal LAN 203 via low power communication. When communication is not required by a particular device, the radio modules enter a low power or “sleep mode” to conserve battery power. During such sleep modes, other circuitry within the device may also be powered down.
The infrastructure network 300 may depend on a base station, such as the base stations 313, for distributing messages to and from a host computer to the personal LANs. It may also depend on a base station to distribute messages within the infrastructure network from one base station in the network to another. No physical addresses are assumed in either case and a flexible host interface is provided in each network device, such as in devices 305, 307, 311, 309, to allow connection to a variety of base stations.
The base station 313, being part of the infrastructure network 300, provides data transfer between the wired physical medium and wireless devices, and may also provide a wireless link between wired Ethernet segments. Specifically, the base station 313 acts as a wired bridge access point that attaches to the infrastructure network through a communication link, such as an Ethernet link, and has bridging enabled. It converts wireless personal LAN frames from the personal LAN 303 to Ethernet frames, and Ethernet frames to wireless personal LAN frames. It also forwards wireless personal LAN frames to wireless personal LAN devices. Although, the base station 313 is shown wired to the infrastructure network 300, it may employ a high power wireless means to communicate with the infrastructure network 300. The base station 313 may participate with the personal LAN 303 as an infrastructure device, or may be part of the personal LAN 303 itself.
The data collection device 317, and the hand held device 319 are not part of any personal LAN. They communicate with a base station 321 that is part of the infrastructure network 300. The communication between the base station 321 and the devices 319 and 317 may employ low power wireless communications or high power communications depending upon the individual devices, the data rate, the traffic, and the protocols.
During the beaconing duration, beaconing information may be transmitted by a beaconing station on the personal LAN, and received by all the other devices on the personal LAN.
At a minimum, a beacon gets to coordinate communication activity. It used to synchronize operation and may contain information such as pending message lists, scheduling information or other network related indicia. Devices that are in a multiple cycle sleep mode may sleep through multiple intervening beacons. The beacon transmission cycle 407 is the duration between two consecutive beacons. The devices listening for the beacon stay awake for the beacon in a window called the wakeup window 411. Following the beaconing duration 409, an awake time window may be optionally invoked for some beaconing protocols during which the network coordinator or the beaconing device listens to network traffic and communicates with the other devices.
The beacon transmission cycle 407 may or may not be predetermined. It may also vary with the data rate, the traffic and the protocol. If it is predetermined, the devices in the personal LAN know when the next beacon is likely to occur. If it is not predetermined, then a given beacon identifies the time of occurrence of the next beacon. The beacon can be a frame that includes a network time stamp which is a timestamp of the beacon in network ticks of 30.5 microseconds, a next beacon time in terms of hops, a next beacon type, a beacon interval in units of hop dwells and a beacon count modulo 65536. The network time stamp is used to synchronize receiver's clocks. The beacon frame also includes a request for poll window time in network ticks to allow devices to indicate their need to communicate with the beaconing device or network coordinator, a device resync time that indicates the number of beacons that can be missed before entering resync mode, and a next hop time. The next hop time indicates the time left in the current dwell from start of the beacon frame.
Additionally, the beacon frame includes the dwell time in network ticks, the hop sequence being used the frequency hop based communications protocol, the current hop index, and a channel number indicating the actual channel that the beacon is transmitted on. The actual channel number is helpful to the receiving device because of the possibility of hearing adjacent channels.
In an exemplary beacon frame, the type of beacon can be 0 for normal beacon from network initiator, 1 for reset beacon from a network coordinator indicating need to resynchronize, 2 for backup beacon that is generated by a station other then the network coordinator. The type 2 also indicates that the beacons from the network coordinator have recently occurred and will occur later in the beacon sequence. For distributed beaconing, the next beacon type information may be accompanied by information on the next beaconing device indicating the device that would beacon next. This would facilitate dynamic reconfiguration of the personal LAN while providing for the dynamic determination of the next beaconing device depending on the data rate, the protocols, the power levels and the status of the devices.
In another embodiment, the PDA 111 does not send beacons, and sleeps for multiple beacon cycles only to wake up to receive the beacon 513 sent by the hand held device 105. In such an embodiment, the hand held device 105 would be considered as the network coordinator, and the other non-beaconing devices would coordinate their sleep and wakeup schedules with the network coordinator.
The devices in the personal LAN 600 are typically worn using appropriate attachments by a worker working in a warehouse or by a delivery person working in and out of a truck. Most of the devices in such work environments are portable, such as the devices 605, 607, 609 and 611, and some of these devices are not carried on the person of the worker when they are not needed. The personal LAN 600 is therefore dynamically configurable, and can identify the presence or absence of the devices in the personal LAN. The operation of the personal LAN 600 is continued and not disrupted despite the lack of participation or absence of some of the devices 605, 607, 609 and 611.
The network coordinator 605 assesses all devices in the network by monitoring the request for poll activity from the other devices and its own traffic to other stations. It can therefore determine which devices on the personal LAN 600 have recently been connected. By monitoring the secondary beaconing activity it can also ascertain which devices are still connected. For those stations without recent demonstration of connectivity, the network coordinator 605 generates identify frames. The lack of an appropriate response to the identify frames by devices that show no sign of activity will cause the network coordinator 605 to initiate a recovery mode or search and rescue operation.
For example, during the operation of the personal LAN 600, when the devices 609 and 611 are separated from the other two devices, the network coordinator 605 and the data collection 607 fail to receive the beacons from the printer 609 and the PDA 611. The network coordinator 605 then initiates a recovery mode or search and rescue operation for a number of beacons that was initially specified by the lost devices. After the requested number of beacons has passed, the network coordinator 605 will wait for an indication of no activity involving the lost devices 609 and 611, and then tune to each of the control channels in succession and transmit beacon frames.
The lost devices, the printer 609 and the PDA 611, are expected to wait on one of the control channels. When they receive the beacon, they proceed to resync to the information in the beacon and thus are recovered. If the printer 609 and the PDA 611 are separated and are out of the range of the personal LAN 600, they will not receive beacons from the network coordinator 605 and the data collection device 607. They progress very slowly through the control channels, waiting for beacons. However, the printer 609 and the PDA 611 continue to transmit their beacons, and continue to receive each others beacons. When they fail to see any beacons from the network coordinator 605 for a predetermined number of beacon transmission cycles, the printer 609 and the PDA 611 communicate with each other to identify a replacement for the network coordinator. For example, the printer 609 and the PDA 611 may elect the printer 609 to become the network coordinator and establish the personal LAN 613 for their continued operation.
In the meanwhile, the hand held device 605 abandons an unsuccessful search and rescue attempt for the devices that a number of beacon cycles. The hand held device then reconfigures the personal LAN 600 into the personal LAN 615 with itself as the network coordinator. When the devices 609 and 611 constituting the personal LAN 613 later come closer in proximity to the personal LAN 615, they may selectively rejoin the personal LAN 615 at the discretion of the network coordinator 605.
Devices that are separated or “lost” from the personal LAN 600 may rejoin the personal LAN 600 when they return to the proximity of the personal LAN 600. This is accomplished when these “lost” devices send a join request that includes the type of network the device wants to join, the number of beacons after missing which the device generates network beacons, the number networks and the network addresses of networks that the device is willing to join. The lost devices then await a join network response from the network coordinator of the personal LAN 600. The lost devices then send network management command to get addresses and types of other stations in the network. They then await the response and save information for use in other data messages subsequently.
The time line 733 corresponds to the activity of the hand held device 105 while the time line 735 corresponds to the activity of the printer 109. The hand held device 105 and the printer 109 wake up periodically for a wakeup window 709 to receive beacons. They also send beacons when it is their turn to transmit beacons.
The hand held device 105, the data collection device 107, and the printer 109 are expected to transmit the beacons 711, 713 and 715 respectively, in that order. However, when the data collection device 107 fails to transmit the beacon 713, the other devices 105, 109, and 111 listening to the beacons identify the source of the missing beacon as the data collection device 107. If the data collection device 107 is the network coordinator, both the beaconing devices 105 and 109 try to replace the missing beacon 719 with their own beacons 723 and 725, respectively. The contention for replacing the missing beacon 719 from the network coordinator 107 is recognized by all the devices on the personal LAN 100, and the contending devices decide to resort to a random back-off period across multiple beacon cycles to resolve the contention. The device that recovers first from the back off period and transmits its beacon as a replacement to the missing beacon is subsequently allowed to replace beacons from the data collection device 107.
If the data collection device 107 that stops sending beacons is not a network coordinator, and the hand held device 105 is the network coordinator, then the network coordinator 105 decides to replace the missing beacon from the data collection device 107 by its own beacon. The printer 109 refrains from transmitting its beacon in contention with the network coordinator 105. If the data collection device 107 decides later on to participate in distributed beaconing, it coordinates its inclusion with the network coordinator 105.
When communication is not required by a particular device, the radio modules enter a low power or “sleep mode” to conserve battery power. During such sleep modes, other circuitry within the device may also be powered down.
The personal LAN 801 may also establish communication with the infrastructure network when required. The infrastructure network may include a wired network having a wired backbone 826 connecting computer devices 828 to a wireless access point 824. The wireless access point 824 may participate with a multi-hop wireless network 822 having a plurality of wireless access devices, each establishing a respective communication cell. The multi-hop wireless network 822 may include, for example, printers 830 and other devices communicating wirelessly.
In establishing and maintaining communication with the infrastructure network, the personal LAN 801 may designate one or more of the devices within the personal LAN 801 as an interface to the infrastructure network depending upon data transmission requirements, power consumption and communication protocol constraints. In this fashion, communication between devices within the personal LAN 801 may be had without routing communications through the infrastructure network. Such operation proves advantageous in reducing network traffic on the infrastructure network and allowing the devices within the personal LAN 801 to operate at a low transmitted power when communicating within the personal LAN 801. Further, such operation allows the devices within the personal LAN 801 to communicate when outside the range of the infrastructure network.
The user 910 establishes the personal LAN 901 by collecting desired devices and requesting formation of the personal LAN 901 via one of the devices such at the terminal 916. The terminal 916 through wireless interaction with the collected devices delivers a list of candidate devices to the user 910 for selection. Thereafter, through the terminal 916, or other initiating device, the personal LAN 901 is formed.
At each distribution site, the personal LAN 901 may then establish communication with the infrastructure network, if necessary, via a relatively higher power wireless access point 936 contained within the delivery van 934. Such information would then be transmitted back to the warehouse 932 for distribution and verification. The access point 936 in the van 934 may participate with the personal LAN 901 as an infrastructure device or may be part of the personal LAN 901 itself.
Referring to
An Infrastructure Network (such as those managing a majority of wireless communication flow a premises) may depend on an access point for distributing messages to and from a host network as well as within the Infrastructure Network (i.e. from one station in the network to another). No physical address is assumed in either case and a flexible host interface is provided to allow connection to a variety of stations. The personal LAN provides a simple modem and an intelligent host interface option, e.g., providing an RS-232 or a serial 3V CMOS physical host interface option, and provides multi-point capability with a throughput of 19200 bps in any environment. The personal LAN also allows a user to select a set of devices and automatically configures itself depending upon the selection.
Each device (or host) that may participate in personal LANs will contain a radio module. The radio and host protocol are implemented by a microprocessor in the radio module. The microprocessor will handle framing for both interfaces (simultaneously) and buffering for several messages. The implementation of the host interface (in smart mode) will provide simple support for the host computer's implementation of its radio driver.
Most devices such as portable computing devices are configured to support both NDIS device drivers and Windows 95™ virtual corn ports. This allows printers to have a “corn” port of their own, and data may be sent to the radio for communication to other radio devices via a stream of bytes. An NDIS interface would allow standard higher level protocols to utilize the radio if this was desirable. Other devices will need to implement proprietary device drivers communicating to the radio using the 3V CMOS serial interface which may be connected to an RS-232 interface adapter. In the implementation a simple “C” language API may be used as a device driver.
In particular, the physical interface to the host device is one of the following: a 3V CMOS serial interface and with an adapter, an RS-232 interface. The type of control information sent over the interface, framing characteristics and data rates are programmable. Table 1 describes the 3V CMOS serial interface signals.
For RS-232, a secondary PC board connected to the 3V CMOS interface will provide RS-232 signal levels for all the serial interface lines (except Reset). Upon reset, the data rate will be 19200. A smart interface command can change the rate to one of 19200-115200. The asynchronous framing will be 8 bit, no parity and 1 stop bit. The least significant bit of each byte of data is sent first, after the start bit.
Two types of host control interfaces are provided. A dumb interface is used by devices that are pre-programmed and cannot directly control the radio device. In this case, a very simple hardware controlled modem device is emulated. A Lock command is included in the radio protocol so that one station using a smart host interface can dedicate for its use another station (such as a printer with a dumb interface), and thus prevent interleaved data or other such problems. This is a higher layer problem, but is included in the radio protocol to support devices using the dumb interface.
A smart interface is used when the host device is able to actively manage the radio. Upon reset, the radio assumes a dumb interface. The dumb interface passes just data. Control and selection of dumb devices, if required, is handled by the other end of the radio data link. RTS must be asserted by the “dumb” host. In those cases where the connected host device does not use RTS/CTS signaling, this may be accomplished by connecting the DSR signal from the radio to RTS. While RTS is asserted, the radio cannot power down its end of the host interface and thus will use more power. In cases where the host device can assert RTS and await CTS, the radio will power manage the host interface. While RTS is asserted, data can be sent to the radio. When either RTS is unasserted or a gap in character arrival occurs, the radio will send the data to one of the following destinations, in order of highest to lowest priority:
The smart interface can control operation of the radio such as establishing networks, removing networks, collecting statistics, multi-point transmission, and the management of destination devices with dumb interfaces, etc. The Host establishes this interface by first asserting RTS (this is necessary to allow the radio unit to power up the host interface). It then await CTS from the radio. Next it unasserts RTS and immediately sends the escape sequence DLE (hex 10) followed by ENQ (hex 05). The radio will use this sequence to enter the smart interface mode. The host may then begin a sequence to communicate with the radio.
Once the smart mode has been entered, all further communication is encapsulated in frames as follows.
When the radio has a message to send to the host, it will assert RI. Whenever any message exchange is to occur, the host will assert RTS and await assertion of CTS by the radio. When the radio asserts CTS, it will assert RI. At this time bi-directional exchanges are possible until the host asserts RTS. If this occurs in the middle of a message/frame (either from or to the radio), the message/frame is considered aborted and must be resent. The receiver of a message/frame (other than the acknowledge frame) must acknowledge the message/frame.
The Ctl field is composed of two parts. The low 4 bits are the command and the high 4 bits are used as follows.
Table 4 below defines the commands from the host device to the radio.
Table 5 defines the commands and status messages from the radio to the host.
Each frame transmitted across the interface has a sequence number. A re-transmission of a frame will have the Retry bit set in the Ctl field and the same sequence number as the previous attempt. Ack frames will use the sequence number of the received frame that is being acknowledged. The sequence number is incremented for each unique frame (other than Ack frames) sent across the interface.
The Chk Field is a modulo 8 sum of all bytes in each command or response message including the Length field through the Info field. The receiver of the message will also calculate the checksum and if the calculated field equals the received field, immediately send an Ack frame response.
Both the radio and host will use the following command to pass data messages across the interface. The maximum number of data bytes is indicated in the version and status responses from the radio. The format of the command is as follows.
The Initiate Command is used by the host to Initiate a new Microlink network. Upon receipt of this command, the radio will send Initiate commands on the radio control channels and pass all attach requests (that do not have duplicate source addresses) to the host. The format of the command is as follows:
To establish a PAN, the Data Rate would be 1, the Network Type would be 0 and the Power would be set to 0. An infrastructured network could set the Data Rate to 0 (if greater range is useful. This would be approximately 6 db additional link margin) or to 1, and the Type to 1. For PAN, if Rejoin is set, then the radio will attempt to “discover” the previous instance of the network before it sends the Initiate frame. If the previous network is “discovered”, then after the Initiate response, a Start command must not be sent because the network has already been rejoined. For Infrastructured networks, a Start is not needed as the network will start upon valid receipt of this command.
In response to an initiate network command the Initiate Response is generated.
The Status Request/Response pair is used to get status information from the radio. This includes counters and network information. The format of the Status Request is as follows:
The format of the response is as follows:
The Ack frame is sent by both the radio and host to acknowledge correct reception of a frame across the interface. The sequence number in the frame is copied from the frame being acknowledged. If an Ack is not received within 100 milliseconds, the sender will re-transmit the unacknowledged frame.
After a Initiate Command has been issued, Attach Request messages received by the radio will be sent to the host. This request indicates a remote device that has detected the host's attempt to Initiate a network and has requested to join that network. The host can accept or reject the device with the Join Response Command. The format of this request is as follows:
The Join Response is used to indicate acceptability of a remote device in the network that the host is Initiating. It is formatted as follows:
The Start Network Command is used to start a PAN once the host has determined that all required devices have joined. The Start Network Response is generated by the radio when the network has been successfully initialized (that is all expected devices are now in sync). This may be as a response to the Start Network command or when the Type field had the high bit set in an Initiate command and the previous instance of the network was re-discovered. It has the following format:
The Join Network Command is used to allow the host to join a network. It could be used to join a PAN or an infrastructured network. It is formatted as follows:
If the rejoin bit is set in the Type field, then the radio will attempt to rejoin the previous network. If it is not set or a rejoin attempt fails, the Netlist is used to find an appropriate network to join. If the Type field indicates either data rate is valid, the radio will alternate between the two rates while awaiting either Init or Beacon frames.
The radio uses the Scan Time and Scan Duty Cycle fields to determine how to recover when network connectivity is lost. Scan Time indicates how long to continuously scan when connectivity is first lost. Scan Duty Cycle indicates how to scan after Scan Time elapses. Essentially this allows the radio to power cycle its transceiver to aid in managing battery life.
The Join Network Response indicates to the host that one of the acceptable networks has been joined. It is formatted as follows:
The Device Management Command provides various device management functions. It is valid to send only to “dumb” devices. It is formatted as follows:
The Device Management Response is generated by the radio after an exchange with the remote device. It is formatted as follows:
The Diagnostics command is used to perform diagnostic and service functions on the radio. Its format is defined, but its content are implementation specific.
The Diagnostics Response is generated by the radio as the result of a Diagnostics request. Only some requests may generate a response.
The Set Parms Command is used to set the host interface parameters. It is formatted as follows:
Upon receipt of this command, the radio will change its host interface parameters and then assert RI.
The Data Transmit Status command from the radio is used to indicate result of last data command from the host. A Data Transmit Status will be generated by the radio for every Data request from the host. It is formatted as follows.
The Version Request command is used to request version information from the radio module. There is no data associated with this request.
The Version response is generated by the radio upon receipt of a version request. It is formatted as follows.
The Network Management command is used by the host to manage network operations and by the radio to indicate network management requests from the network.
To initiate a Smart Radio interface, the following steps are performed:
To initiate a PAN network:
To join a network:
To send data:
To transfer network control:
To network initiator rejoining a network:
Temporary Network:
The frequency of the radio is in the 2.4 GHz range, selectable on 1.5 MHz increments from 2401 to 2483 MHz. This will allow for 50 channels. The radio data rates are software controlled and either 1 Mbps or 250 Kbps. The later can be used if greater range is desirable (as in an Infrastructured Network). The bit framing for the radio is Synchronous HDLC using NRZI encoding. An 80 bit preamble of alternating ones and zeros will be sent for each frame.
The radio supports relatively fast switching times between channels to allow FH Spread Spectrum solutions for noise immunity. Suggested worst case switch times are on the order of 500 microseconds. The transmit power should be no more than 0 dbm, and at 5 meters the BER should be no worse than 10−5.
The following elements of the radio protocol are common to personal LAN and to Infrastructured Networks.
General Frame Format
The framing is HDLC so starting and ending flags delimit the frame.
Ctl Field
The low 4 bits is the frame type which is defined below. The high 4 bits have the following usage:
Frame Types are defined below:
Address Fields
The DA and SA fields are each 16 bits. Station Addresses are randomly generated by each station. Any randomization algorithm may be used, but it should be sure to generate different values on subsequent generation attempts. All ones is a broadcast address and should not be generated for use as the station address.
Network Id Field
The Network Id field is passed to the radio from the network initiator. All ones is a broadcast id and is not a valid id for a network but can be used to join any network sending a Initiate.
Sequence Field
This field is composed of two sub-fields. The high 4 bits are the fragment number (when the fragment bit is on in the Ctl field) and the low 12 bits are the sequence number of the frame. This number is changed on every frame sent, unless the frame is a retry (the retry bit is set in the Ctl field). For CLR frames, it is copied from the frame to be acknowledged. In all other frames, the number is incremented for each new frame sent.
Frame Check Sequence (FCS)
The FCS algorithm is CCITT CRC-16 as used by HDLC.
Certain channels, control channels, are set aside to be used specifically for synchronization and re-synchronization. The hop sequences will visit these channels more frequently. Several channels are used to prevent a single point of failure based on interference on a single channel.
The medium access rule used is CSMA/CA, that is carrier sense, multiple access with collision avoidance. All directed frames (except CLRs) require a CLR from the receiver to be transmitted to the sender of the directed frame.
CSMA alone would allow access to the medium as soon as it is sensed to be idle. If multiple devices simultaneously sensed idle and transmitted, there is a “collision” which cannot be detected. To detect these collisions a CLR is expected on all directed frames. This does not “avoid” collision in the first place. To avoid collisions, devices will first sense the medium for a random length of time, and only if the medium is idle for that random time will the device send. Beacon frames sent by the network coordinator will use a random time in the range of 0 to backoff_table[0]/2. All other frames use a range of 0 to backoff_table[0]. This allows beacons a higher priority. Occasionally a collision will still occur. The absence of a CLR will indicate this. It will also sometimes cause delay on sending the frame when there would have been no contention anyway. In any case it will prevent most collisions. Any collision results in a great delay of wasted bandwidth.
Since it is possible (especially in Infrastructured networks) to have hidden stations, a station may receive frames sent only by the recipient of a frame sequence (i.e. POLL and CLR frames) and it may not detect the carrier on the RFP and DATA frames. Frames therefore contain reservation information that indicate to all receiving stations the necessary time duration required for a frame sequence. This allows hidden stations to recognize that the medium is actually busy. Thus such stations will not inadvertently sense the carrier as idle and transmit a frame which interferes with a hidden station's frame. Stations are thus required to process reservation information in all frames having the correct Network Id.
A station that has just awakened from power down mode (i.e., the radio receiver has been off), does not have such an assessment of the medium. If such a device desires to send, and if the network is so configured (indicated by a field in Beacon frames), such devices will set their medium reservation information to protect against the longest possible frame. A valid frame received by such a station will set the reservation time to a known value, potentially shortening this duration.
Except when transmitting a CLR or POLL, the medium is first sensed for a carrier signal as defined above before transmitting a frame. If the medium is busy, then the backoff procedure is initiated.
A backoff value is randomly chosen in the range of 0 to backoff_table[retry]. The retry will initially be zero for a frame. The table, backoff_table, is composed of the following values: {65, 130, 260, 520}. Each entry is in system ticks, where each tick is approximately 30.5 microseconds. The backoff timer runs regardless of the state of the medium. However, when a frame is received, the timer is augmented by the reservation indicated in that frame (based on transmit data rate). The value in the frame is designed to protect that frame and any subsequent frame in the sequence. This results in fairer access to the medium because other stations that attempt to transmit later will not have better access probability due to a station continually timing out its backoff count and picking ever larger times to wait. Once the backoff timer goes to zero, the device will transmit its frame.
When frames are unsuccessfully sent, that is a POLL is not received for an RFP or a CLR is not received for a directed frame, the retry value is incremented and if the maximum number of retries has not been exceeded, the backoff procedure is again executed. The station must only transmit 4 successive times on a channel before awaiting another channel (that is why the table only has four entries). If retries must occur on a subsequent channel, the algorithm is reset. Note that if a CLR was sent but not successfully received, a duplicate frame will be sent, with the retry bit set in the control field and the sequence number the same. This will allow duplicate frames to be ignored by the receiver. Though they may be ignored, the CLR must still be sent.
Once the frame has been successfully sent, the backoff procedure is again initiated with a value randomly chosen in the range of 0 to backoff_table[retry]. The value of retry is then set to 0. This will prevent the station from having a higher access probability than other “backed off” stations.
Because the radio is an inherently poor medium, sending very long frames of data is inappropriate. Thus fragmentation may be required. Host data messages larger than the maximum radio frame size will be split into the appropriate number of fragments (from 1 to 15) and then each fragment will be sent with a separate medium access. A receiver will receive each fragment and assemble them into a single Host data message. The receiver may not have available buffers for fragments and can thus use the POLL frame status field to inform the RFP sender to re-transmit from the first fragment. The receiver of successive fragments will remain awake to receive all the fragments. Thus the transmitter of the fragments need not indicate them in the RFP window. Only unicast data frames can be fragmented.
The following describes the radio frame formats used. The Data frame is used to exchange host data between radios. Its format is as follows.
The CLR frame is used to confirm error free reception of Data, Attach Request, Attach Response and Device Management frames. It has no data field.
The Request For Poll (RFP) frame is used to indicate one of the following:
This frame is usually sent in the RFP window (because the destination station is usually asleep in most cases). If the destination has indicated in a previous data frame that it will remain awake, and a subsequent frame is ready to be sent to that station, the RFP may be sent outside of the RFP window.
If sent in the RFP window, the duration field should only protect the POLL. If sent outside the RFP window, the duration should protect.
The POLL frame is sent in response to a unicast RFP. It indicates that the sender allows the receiver to send a subsequent message. Its format is as follows:
The Beacon frame is used by network coordinator to keep stations in synchronization. Beacon frames are always broadcast on the network. The Beacon format is as follows.
It is most likely that dwell time and beacon interval are the same. There is little value in having beacon intervals longer than the dwell time unless a great deal of interference is suspected. This will allow for better frequency diversity recovery in bad channels.
The Initiate frame is used to establish a network. Devices receiving this will determine if the network parameters are acceptable and request to join by sending a Attach Request Frame. This frame is always broadcast. Its format is as follows.
The Attach Request frame is generated by a station when it receives an Initiate frame from a network that it wishes to join. It is broadcast in response to an Initiate frame (to the network id indicated by that frame). It may be sent as a directed frame to keep network connectivity. Its format is as follows.
The Attach Response frame is used to indicate acceptability of device to network initiator. Its format is as follows.
The Identify frame is used to determine if the destination is still in sync. It has no data field and a CLR is all that is required for confirmation. This frame must be sent in the RFP window as it will take the same amount of time in that window to send the Identify Frame and receive a CLR as to send an RFP and receive a POLL. In the later case, the Identify frame would then need to be sent after the RFP window anyway using even more bandwidth. This frame must be unicast.
The Test Frame is used to test network connectivity. The receiver of such a frame will simply send it back to the sender. A special case exists, where a TEST is received with an all ones Network ID. This is the only case where such a frame is valid. The receiver will send back the frame. The Info field can contain any data.
The Device Management frame is used to acquire/release control of a remote device, usually one having a “dumb” host interface. This is usually best left to a higher layer protocol, but for dumb devices, that is not possible. The format of a request is as follows.
The format of a response is as follows:
The Network Management frame is used to perform special network management operations such as transferring network coordination and network termination. There are request and response frames. The request frame is as follows.
The format of a response is as follows:
Upon successful transfer of the network, the receiving device will begin beaconing and will send a reset beacon. That station also will need to set its identify procedure up to start from its initial state to confirm that all devices remain in synchronization based on the stations clock.
Network Synchronization
The network coordinator will keep the network synchronized by periodically transmitting Beacon frames. These frames include information about network time, dwell time and next beacon time to allow a receiver to set its clock to that in the beacon and then sleep until the next beacon with the receiver off to save power. Since a system clock with an accuracy of greater than 50 parts per million is unreasonable to assume, the beacon also includes a count of beacons that have been sent to allow the receiver to occasionally take snapshots of its own clock and then some large number of beacons intervals later, sample the beacon count again and determine the station clock's relative accuracy versus the network clock. Periodic corrections can then be applied.
The network clock is in 1/32768 seconds or approximately 30.5 microsecond ticks. This allows for a low power requirement to maintain the clock.
The Beacon frame contains hop information, the current physical channel, the hop table in use, the table entry and the dwell interval. The time remaining in the current dwell period is calculated as follows:
(dwell interval)−(current system tick)MOD(dwell interval)
Initial synchronization in Infrastructured networks is accomplished by setting the unsynchronized station's receiver to a control channel and awaiting a beacon with the Infrastructured bit set and a matching Network Id in the beacon frame.
A PAN has two levels of synchronization support. When the number of beacons specified in a stations backup priority (from Join Network Command) are missed, the station will generate backup beacons. It will continue to adjust its clock to what the network coordinator would have as its clock. This allows for PANs to be temporarily split. If the station does not receive a beacon from the network coordinator after the number of beacon intervals specified in the Device Resync Time (from a beacon) have elapsed, then the station is lost, and must enter the recovery procedure.
An infrastructured network does not support splitting. The backup priority field is thus used for detection of sync loss. If backup priority beacon intervals pass without a beacon from the network coordinator, then the station is out of sync and must enter the recovery procedure.
Power Management
In order to reduce power consumption, a station must turn off its radio receiver (and perhaps other hardware). This is known as sleep mode. It may do so under the following conditions:
Following beacons all stations are obliged to be awake for a period of time called an RFP window. During this window, stations that have messages to send will generate Request For Poll (RFP) messages. Any station receiving an RFP must remain awake until it has correctly received the message from the station sending the RFP. The length of the RFP window is indicated in the beacon. The window size is based on the expected number of devices that may transmit (a parameter in the Start Network Command). Because it is likely that more than one device will need to send an RFP in the RFP window, each station will initiate the backoff procedure before sending an RFP. It is assumed that twice this expected number is a good value to use for the upper range in the randomization for the backoff algorithm. It is further assumed that twice this number is a good choice for the maximum allowed RFPs in the window. Once the window time has passed, no further RFPs are allowed to be transmitted.
If the frame sent cannot be successfully delivered in the current hop, another RFP must be sent in the next RFP window.
The window time is based on the Start Network command Transmit Devices field and is calculated as follows:
RFP Window Time=2*Transmit Devices* (Avg Backoff+RX/TX time+RFP message duration time+RX/TX time+POLL message duration time)
RFP message duration=14 bytes*8+80=192 microseconds (approximately)
POLL message duration time=15*8+80=200 microseconds
Avg RFP Backoff time=65*30.5 microseconds/2=990 microseconds
Since some clock jitter is to be expected, a station will actually turn on its receiver about 1 msec early on the expected channel and await the beacon. Since it must then receive a beacon and then wait the RFP window time, the current required to maintain the link can be calculated as follows:
Net Maintenance Current=Receiver Current*(Channel Select time+1 msec+Avg Backoff/2+RX/TX time+Beacon Frame Time+RFP window)/Beacon Interval+sleep current
Beacon Frame Time=31*8+80=328 microseconds (approximately)
As an example of this, assume Receiver Current of 100 mA, a channel select time of 0.5 msec, a beacon interval of one dwell period, a dwell period of 250 msec, a Transmit Devices value of 2 and a sleep current of 2 mA. The Net maintenance current is as follows:
When sending to a station that is assessed as in Awake Mode, an RFP-POLL-DATA-CLR sequence can be sent anytime except in the RFP Window. If during the first dwell time that this is attempted, the message can not be successfully transmitted, then the RFP Window method described above must be used to deliver the message.
Network Re-Synchronization
Since it is possible for a PAN to be divided when the user carries some equipment but not all, it is necessary to provide a mechanism to re-synchronize those devices which have lost synchronization because they no longer see beacons. The network coordinator will assess all devices in the network by using one of two mechanisms.
By monitoring RFP activity and its own traffic to other stations, it can determine which stations have recently been connected.
For those stations without recent demonstration of connectivity (case 1), the network coordinator will generate Identify frames.
For devices determined to be “lost”, a search and rescue mission will be attempted at the rate requested in the Host Interface Start Network command. After the requested number of beacons has passed, the network coordinator will wait for an indication of no activity involving it (again based on RFP frames and its own transmission status), and then tune to each of the control channels in succession and transmit beacon frames.
Lost devices will wait on one of the control channels and when they receive the beacon, they will re-sync to the information in the beacon and thus be recovered. With the periodic adjustment of a station's clock as defined above, a reasonable period will be provided over which synchronization can be maintained. Each beacon advertises the Device Resync Time. Thus a station that has not seen beacons for this period will start progressing very slowly through the control channels, waiting for beacons (as discussed above). Once it sees a beacon it will be back in sync. This progression requires the receiver to be on thus causing a large demand on power. The Join Network Command specifies an initial on time and a subsequent power duty cycle to allow for extended battery life. Once the initial on time passes (during which the station is scanning channels at slow rate), the radio will perform a single scan of the control channels followed by a period during which the receiver is off. This period is a multiple of the time required for a single scan and can be a 50%, 33%, 25% or 20% duty cycle. This will increase the re-acquisition time.
At this same time the station will become receptive to new Initiate frames that match the correct criteria as designated in the Host Interface Join Network Request. If it receives either a Initiate frame or a Beacon Frame, it will proceed accordingly. This will allow devices in a recharge rack overnight to automatically be ready for a new network the following morning. The search and rescue operations may also be employed to establish a PAN. A network may employ either or both search and rescue and proximal formation operations to establish a plurality of PANs.
Infrastructured Network Re-Synchronization
When an station in an infrastructured network looses synchronization (is lost), it will immediately search for a new network matching the parms from the Join Network Command. The station will start progressing very slowly through the control channels, attempting to detect a network matching the specified parameters. This progression requires the receiver to be on thus causing a large demand on power. The Join Network Command specifies an initial on time and a subsequent power duty cycle to allow for extended battery life. Once the initial on time passes (during which the station is scanning channels at a slow rate), the radio will perform a single scan of the control channels followed by a period during which the receiver is off. This period is a multiple of the time required for a single scan and can be a 50%, 33%, 25% or 20% duty cycle. This will increase the time required to find a network.
Reset Network Recovery
If a station is reset (i.e. the battery is replaced), it must re-acquire the network. The network itself cannot determine that the device is missing for the duration of the Device Resync Time. This can be quite long. This is resolved by the hop sequences incorporating the control channels in the sequence more frequently than other channels. Thus a device that is “lost” can tune its receiver to a control channel and await beacons. If the lost device is the network coordinator (the station normally transmitting beacons), then after a short number of missing beacons, another device will send backup beacons. Thus even the “lost” network coordinator will be able to recover the network and resume coordination.
The time to recover is on average as follows:
number of control channels*interval between using control channels/2
Thus if there are four control channels visited every fifth hop and the hop duration is 250 ms, then on average the recovery time is 2.5 s.
This section defines the radio finite state machines and their operation. These FSMs are as follows:
The inputs possible for the FSMs are the host interface commands and radio frames discussed in previous sections and various time-outs. The timers are as follows.
In the following description, unspecified Inputs are assumed to be ignored. Only the first matched Input in a State is executed. A ‘*’ in the State field means this Input results in the same transition for all States. In the Next State column, a number implies a State in the current FSM and a number:name implies a State in the named FSM. A blank Next State field implies that there is no transition. When a transfer to a named FSM occurs, the current FSM is terminated. When frames are specified as Input, they are assumed to be removed from the receive queue.
The Initial FSM is entered upon module reset. The Join Request parms are set to the broadcast network id and a type of PAN and a Data Rate of any rate. The network management FSM, receive FSM and transmit FSM run asynchronously to other FSMs. A queue from receive and to transmit are assumed. There is also a station queue which holds frames from the host to transmit that may have arrived before an RFP window.
It is assumed that Host Data frames, Network Management frames or Device Management frames are preprocessed as follows:
In this FSM, the following abbreviations are used.
The Identify Procedure will check for all stations that this station has not detected traffic from within the Test Alive Count (number of beacons). It will build a list of stations to send Identify messages to and put them on the station queue. If several attempts to Identify a station fail, the SAR (search and rescue) flag is set. Receiving CLR or RFPs from a station will count as detected traffic. Note that after Start Request is received, the Test Alive variable is set to the 1. This will cause the network coordinator to immediately test for stations in the net on the first hop. This will guarantee that all stations in the network are together. Once it is first determined that all devices have synchronized, a Start Network Response is sent to the host.
The AdjustClock procedure will sample beacons over a long time period (on the order of 10 s of seconds) and determine the delta between the network coordinators clock (which is the network clock) and this stations clock. It will adjust the station clock in the absence of beacons.
The ModifyClock procedure will determine if the network clock in this station should be modified based on the calculations of AdjustClock. It also will set SAR if it is determined that sync can no longer be maintained by checking the InSync timer.
This FSM does not illustrate fragmentation. The inputs are either a frame at the head of the transmit queue, the backoff timer or the CLRTimer. For simplification, frames remain at the head of the queue until acted upon by an Action.
Every received frame will set the Reservation Timer by the reservation within it. The reservation is assumed to be from the beginning of the frame. It is possible that this value may be used and then the frame has an invalid FCS. In that case it is optional to honor the reservation value. Only frames with good FCS checks and a Network Id matching the station's network id are processed.
This FSM does not illustrate the usage of fragmentation.
The enclosed Appendix A entitled “Hardware Specification” provides details regarding the functionality and construction of a radio module built in accordance with the present invention. Appendix A is hereby incorporated herein in its entirety and made part of this specification.
Moreover, the scope of the present invention is intended to cover all variations and substitutions which are and which may become apparent from the illustrative embodiments of the present invention that is provided above, and the scope of the invention should be extended to the claimed invention and its equivalents. Finally, it is to be understood that many variations and modifications may be effected without departing from the scope of the present disclosure.
This application is a continuation of application Ser. No. 13/783,199 filed Mar. 1, 2013; the present application and said application Ser. No. 13/783,199 are each a division of application Ser. No. 11/871,553 filed Oct. 12, 2007, which is a continuation of application Ser. No. 09/960,837 filed Sep. 21, 2001, now abandoned, which is a continuation of application Ser. No. 09/127,276 filed Jul. 29, 1998, now abandoned, which claims the benefit under 35 USC 119(e) of U.S. Provisional Application No. 60/093,218 filed Jul. 17, 1998, and U.S. Provisional Application No. 60/080,700 filed Apr. 3, 1998; said application Ser. No. 09/127,276 is a continuation-in-part of PCT International Patent Application PCT/US98/02317 filed Feb. 6, 1998, published as WO 98/35453 on Aug. 13, 1998, and which claims the benefit under 35 USC 119(e) of U.S. Provisional Application No. 60/036,895 filed Feb. 6, 1997, and U.S. Provisional Application No. 60/055,709 filed Aug. 14, 1997.
| Number | Date | Country | |
|---|---|---|---|
| 60093218 | Jul 1998 | US | |
| 60080700 | Apr 1998 | US | |
| 60036895 | Feb 1997 | US | |
| 60055709 | Aug 1997 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11871553 | Oct 2007 | US |
| Child | 13907893 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09960837 | Sep 2001 | US |
| Child | 11871553 | US | |
| Parent | 09127276 | Jul 1998 | US |
| Child | 09960837 | US | |
| Parent | 13783199 | Mar 2013 | US |
| Child | 09127276 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/US1998/002317 | Feb 1998 | US |
| Child | 09127276 | US |
