US20100135219A1 - Personal area network with automatic attachment and detachment - Google Patents

Abstract

A network (100) includes a hub device (110) and at least one unattached peripheral device (120). The unattached peripheral device (120) transmits an attach request to the hub device (110) with a selected address, receives a new address from the hub device to identify the unattached peripheral device (120), and communicates with the hub device (110) using the new address.

Description

RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 10/894,406 filed on Jul. 19, 2004, which is a continuation of U.S. patent application Ser. No. 09/535,591 filed on Mar. 27, 2000, now U.S. Pat. No. 6,804,232, which is related to U.S. patent application No. 09/536,191 filed on Mar. 27, 2000, all of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION
• A. Field of the Invention
• The present invention relates to a data network and, more particularly, to a star data network that facilitates bidirectional wireless data communications between a main processor unit and a varying number of peripheral units as they become located within the proximity of the processor unit.
• B. Description of Related Art
• Over the last decade, the size and power consumption of digital electronic devices has been progressively reduced. For example, personal computers have evolved from lap tops and notebooks into hand-held or belt-carriable devices commonly referred to as personal digital assistants (PDAs). One area of carriable devices that has remained troublesome, however, is the coupling of peripheral devices or sensors to the main processing unit of the PDA. Generally, such coupling is performed through the use of connecting cables. The connecting cables restrict the handling of a peripheral in such a manner as to lose many of the advantages inherent in the PDA's small size and light weight. For a sensor, for example, that occasionally comes into contact with the PDA, the use of cables is particularly undesirable.
• While some conventional systems have proposed linking a keyboard or a mouse to a main processing unit using infrared or radio frequency (RF) communications, such systems have typically been limited to a single peripheral unit with a dedicated channel of low capacity.
• Based on the foregoing, it is desirable to develop a low power data network that provides highly reliable bidirectional data communication between a host or server processor unit and a varying number of peripheral units and/or sensors while avoiding interference from nearby similar systems.
SUMMARY OF THE INVENTION
• Systems and methods consistent with the present invention address this need by providing a wireless personal area network that permits a host unit to communicate with peripheral units with minimal interference from neighboring systems.
• A system consistent with the present invention includes a hub device and at least one unattached peripheral device. The unattached peripheral device transmits an attach request to the hub device with a selected address, receives a new address from the hub device to identify the unattached peripheral device, and communicates with the hub device using the new address.
• In another implementation consistent with the present invention, a method for attaching an unattached peripheral device to a network having a hub device connected to multiple peripheral devices, includes receiving an attach request from the unattached peripheral device, the attach request identifying the unattached peripheral device to the hub device; generating a new address to identify the unattached peripheral device in response to the received attach request; sending the new address to the unattached peripheral device; and sending a confirmation message to the unattached peripheral device using the new address to attach the unattached peripheral device.
• In yet another implementation consistent with the present invention, a method for attaching an unattached peripheral device to a network having a hub device connected to a set of peripheral devices, includes transmitting an attach request with a selected address to the hub device; receiving a new address from the hub device to identify the unattached peripheral device; and attaching to the network using the new address.
BRIEF DESCRIPTION OF THE DRAWINGS
• The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, explain the invention. In the drawings:
• FIG. 1 is a diagram of a personal area network (PAN) in which systems and methods consistent with the present invention may be implemented;
• FIG. 2 is a simplified block diagram of the Hub ofFIG. 1;
• FIG. 3 is a simplified block diagram of a PEA ofFIG. 1;
• FIG. 4 is a block diagram of a software architecture of a Hub or PEA in an implementation consistent with the present invention;
• FIG. 5 is an exemplary diagram of communication processing by the layers of the software architecture ofFIG. 4;
• FIG. 6 is an exemplary diagram of a data block architecture within the DCL of the Hub and PEA in an implementation consistent with the present invention;
• FIG. 7A is a detailed diagram of an exemplary stream usage plan in an implementation consistent with the present invention;
• FIG. 7B is a detailed diagram of an exemplary stream usage assignment in an implementation consistent with the present invention;
• FIG. 8 is an exemplary diagram of a time division multiple access (TDMA) frame structure in an implementation consistent with the present invention;
• FIG. 9A is a detailed diagram of activity within the Hub and PEA according to a TDMA plan consistent with the present invention;
• FIG. 9B is a flowchart of the Hub activity ofFIG. 9A;
• FIG. 9C is a flowchart of the PEA activity ofFIG. 9A;
• FIGS. 10A and 10B are high-level diagrams of states that the Hub and PEA traverse during a data transfer in an implementation consistent with the present invention;
• FIGS. 11 and 12 are flowcharts of Hub and PEA attachment processing, respectively, consistent with the present invention; and
• FIG. 13 is a flowchart of PEA detachment and reattachment processing consistent with the present invention.
DETAILED DESCRIPTION
• The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.
• Systems and methods consistent with the present invention provide a wireless personal area network that permits a host device to communicate with a varying number of peripheral devices with minimal interference from neighboring networks. The host device uses tokens to manage all of the communication in the network, and automatic attachment and detachment mechanisms to communicate with the peripheral devices.
Network Overview
• A Personal Area Network (PAN) is a local network that interconnects computers with devices (e.g., peripherals, sensors, actuators) within their immediate proximity. These devices may be located nearby and may frequently or occasionally come within range and go out of range of the computer. Some devices may be embedded within an infrastructure (e.g., a building or vehicle) so that they can become part of a PAN as needed.
• A PAN, in an implementation consistent with the present invention, has low power consumption and small size, supports wireless communication without line-of-sight limitations, supports communication among networks of multiple devices (over 100 devices), and tolerates interference from other PAN systems operating within the vicinity. A PAN can also be easily integrated into a broad range of simple and complex devices, is low in cost, and is capable of being used worldwide.
• FIG. 1 is a diagram of aPAN100 consistent with the present invention. The PAN100 includes asingle Hub device110 surrounded by multiple Personal Electronic Accessory (PEA)devices120 configured in a star topology. Other topologies may also be possible. Each device is identified by a Media Access (MAC) address.
• TheHub110 orchestrates all communication in thePAN100, which consists of communication between theHub110 and one or more PEA(s)120. TheHub110 manages the timing of the network, allocates available bandwidth among the currently attachedPEAs120 participating in thePAN100, and supports the attachment, detachment, and reattachment ofPEAs120 to and from thePAN100.
• TheHub110 may be a stationary device or may reside in some sort of wearable computer, such as a simple pager-like device, that may move from peripheral to peripheral. TheHub110 could, however, include other devices.
• ThePEAs120 may vary dramatically in terms of their complexity. A very simple PEA might include a movement sensor having an accelerometer, an 8-bit microcontroller, and a PAN interface. An intermediate PEA might include a bar code scanner and its microcontroller. More complex PEAs might include PDAs, cellular telephones, or even desktop PCs and workstations. The PEAs may include stationary devices located near the Hub and/or portable devices that move to and away from the Hub.
• TheHub110 andPEAs120 communicate using multiplexed communication over a predefined set of streams. Logically, a stream is a one-way communications link between onePEA120 and itsHub110. Each stream has a predetermined size and direction. TheHub110 uses stream numbers to identify communication channels for specific functions (e.g., data and control).
• TheHub110 uses MAC addresses to identify itself and thePEAs120. TheHub110 uses its own MAC address to broadcast to allPEAs120. TheHub110 might also use MAC addresses to identify virtual PEAs within any onephysical PEA120. TheHub110 combines a MAC address and a stream number into a token, which it broadcasts to thePEAs120 to control communication through thenetwork100. ThePEA120 responds to theHub110 if it identifies its own MAC address or the Hub MAC address in the token and if the stream number in the token is active for the MAC address of thePEA120.
Exemplary Hub Device
• FIG. 2 is a simplified block diagram of theHub110 ofFIG. 1. TheHub110 may be a battery-powered device that includesHub host210,digital control logic220, radio frequency (RF)transceiver230, and anantenna240.
• Hub host210 may include anything from a simple microcontroller to a high performance microprocessor. The digital control logic (DCL)220 may include a controller that maintains timing and coordinates the operations of theHub host210 and theRF transceiver230. TheDCL220 is specifically designed to minimize power consumption, cost, and size of theHub110. Its design centers around a time-division multiple access (TDMA)-based network access protocol that exploits the short range nature of thePAN100. TheHub host210 causes theDCL220 to initialize thenetwork100, send tokens and messages, and receive messages. Responses from theDCL220 feed incoming messages to theHub host210.
• TheRF transceiver230 includes a conventional RF transceiver that transmits and receives information via theantenna240. TheRF transceiver230 may alternatively include separate transmitter and receiver devices controlled by theDCL220. Theantenna240 includes a conventional antenna for transmitting and receiving information over the network.
• WhileFIG. 2 shows theexemplary Hub110 as consisting of three separate elements, these elements may be physically implemented in one or more integrated circuits. For example, theHub host210 and theDCL220, theDCL220 and theRF transceiver230, or theHub host210, theDCL220, and theRF transceiver230 may be implemented as a single integrated circuit or separate integrated circuits. Moreover, one skilled in the art will recognize that theHub110 may include additional elements that aid in the sending, receiving, and processing of data.
Exemplary PEA Device
• FIG. 3 is a simplified block diagram of thePEA120. ThePEA120 may be a battery-powered device that includes aPEA host310,DCL320,RF transceiver330, and anantenna340. ThePEA host310 may include a sensor that responds to information from a user, an actuator that provides output to the user, a combination of a sensor and an actuator, or more complex circuitry, as described above.
• TheDCL320 may include a controller that coordinates the operations of thePEA host310 and theRF transceiver330. TheDCL320 sequences the operations necessary in establishing synchronization with theHub110, in data communications, in coupling received information from theRF transceiver330 to thePEA host310, and in transmitting data from thePEA host310 back to theHub110 through theRF transceiver330.
• TheRF transceiver330 includes a conventional RF transceiver that transmits and receives information via theantenna340. TheRF transceiver330 may alternatively include separate transmitter and receiver devices controlled by theDCL320. Theantenna340 includes a conventional antenna for transmitting and receiving information over the network.
• WhileFIG. 3 shows theexemplary PEA120 as consisting of three separate elements, these elements may be physically implemented in one or more integrated circuits. For example, thePEA host310 and theDCL320, theDCL320 and theRF transceiver330, or thePEA host310, theDCL320, and theRF transceiver330 may be implemented as a single integrated circuit or separate integrated circuits. Moreover, one skilled in the art will recognize that thePEA120 may include additional elements that aid in the sending, receiving, and processing of data.
Exemplary Software Architecture
• FIG. 4 is an exemplary diagram of asoftware architecture400 of theHub110 in an implementation consistent with the present invention. Thesoftware architecture400 in thePEA120 has a similar structure. Thesoftware architecture400 includes several distinct layers, each designed to serve a specific purpose, including: (1)application410, (2) link layer control (LLC)420, (3) network interface (NI)430, (4) link layer transport (LLT)440, (5) link layer driver (LLD)450, and (6)DCL hardware460. The layers have application programming interfaces (APIs) to facilitate communication with lower layers. TheLLD450 is the lowest layer of software. Each layer may communicate with the next higher layer via procedural upcalls that the higher layer registers with the lower layer.
• Theapplication410 may include any application executing on theHub110, such as a communication routine. TheLLC420 performs several miscellaneous tasks, such as initialization, attachment support, bandwidth control, and token planning. TheLLC420 orchestrates device initialization, including the initialization of the other layers in thesoftware architecture400, upon power-up.
• TheLLC420 provides attachment support by providing attachment opportunities for unattached PEAs to attach to theHub110 so that they can communicate, providing MAC address assignment, and initializing anNI430 and the layers below it for communication with aPEA120. TheLLC420 provides bandwidth control through token planning. Through the use of tokens, theLLC420 allocates bandwidth to permit onePEA120 at a time to communicate with theHub110.
• TheNI430 acts on its own behalf, or for anapplication410 layer above it, to deliver data to theLLT440 beneath it. TheLLT440 provides an ordered, reliable “snippet” (i.e., a data block) delivery service for theNI430 through the use of encoding (e.g., 16-64 bytes of data plus a cyclic redundancy check (CRC)) and snippet retransmission. TheLLT440 accepts snippets, in order, from theNI430 and delivers them using encoded status blocks (e.g., up to 2 bytes of status information translated through Forward Error Correction (FEC) into 6 bytes) for acknowledgments (ACKs).
• TheLLD450 is the lowest level of software in thesoftware architecture400. TheLLD450 interacts with theDCL hardware460. TheLLD450 initializes and updates data transfers via theDCL hardware460 as it delivers and receives data blocks for theLLT440, and processes hardware interrupts. TheDCL hardware460 is the hardware driven by theLLD450.
• FIG. 5 is an exemplary diagram of communication processing by the layers of thesoftware architecture400 ofFIG. 4. InFIG. 5, the exemplary communications involve the transmission of a snippet from one node to another. This example assumes that the sending node is theHub110 and the receiving node is aPEA120. Processing begins with theNI430 of theHub110 deciding to send one or more bytes (but no more than will fit) in a snippet. TheNI430 exports the semantics that only one transaction is required to transmit these bytes to their destination (denoted by “(1)” in the figure). TheNI430 sends a unique identifier for thedestination PEA120 of the snippet to theLLT440. TheLLT440 maps the PEA identifier to the MAC address assigned to thePEA120 by theHub110.
• TheLLT440 transmits the snippet across the network to the receiving device. To accomplish this, theLLT440 adds header information (to indicate, for example, how many bytes in the snippet are padded bytes) and error checking information to the snippet, and employs reverse-direction status/acknowledgment messages and retransmissions. This is illustrated inFIG. 5 by the bidirectional arrow between theLLT440 layers marked with “(n+m).” The number n of snippet transmissions and the number m of status transmissions in the reverse direction are mostly a function of the amount of noise in the wireless communication, which may be highly variable. TheLLT440 may also encrypt portions or all of the snippet using known encryption technology.
• TheLLT440 uses theLLD450 to provide a basic block and stream-oriented communications service, isolating theDCL460 interface from the potentially complex processing required of theLLT440. TheLLT440 uses multiple stream numbers to differentiate snippet and status blocks so that theLLD450 need not know which blocks contain what kind of content. TheLLD450 reads and writes thehardware DCL460 to trigger the transmission and reception of data blocks. ThePEA LLT440, through thePEA LLD450, instructs thePEA DCL460 which MAC address or addresses to respond to, and which stream numbers to respond to for each MAC address. TheHub LLT440, through theHub LLD450, instructs theHub DCL460 which MAC addresses and stream numbers to combine into tokens and transmit so that thecorrect PEA120 will respond. TheHub DCL460 sends and receives (frequently in a corrupted form) the data blocks across the RF network via the Hub RF transceiver230 (FIG. 2).
• TheHub LLT440 employs FEC for status, checksums and error checking for snippets, and performs retransmission control for both to ensure that each snippet is delivered reliably to its client (e.g., PEA LLT440). ThePEA LLT440 delivers snippets in the same order that they were sent by theHub NI430 to thePEA NI430. ThePEA NI430 takes the one or more bytes sent in the snippets and delivers them in order to the higher-level application410, thereby completing the transmission.
Exemplary DCL Data Block Architecture
• FIG. 6 is an exemplary diagram of adata block architecture600 within the DCL of theHub110 and thePEA120. The data block600 contains aMAC address610 designating a receiving or sendingPEA120, astream number620 for the communication, and adata buffer630 which is full when sending and empty when receiving. As will be described later, theMAC address610 andstream number620 form the contents of a token640. When theLLD450 reads from and writes to thehardware DCL460, theLLD450 communicates theMAC address610 andstream number620 with thedata buffer630. When aPEA120 receives a data block, theDCL460 places theMAC address610 andstream number620 contained in the preceding token640 in the data block600 to keep track of the different data flows.
Exemplary Stream Architecture
• TheLLD450 provides a multi-stream data transfer service for theLLT440. While theLLT440 is concerned with data snippets and status/acknowledgements, theLLD450 is concerned with the size of data blocks and the direction of data transfers to and from theHub110.
• FIG. 7A is a detailed diagram of an exemplarystream usage plan700 in an implementation consistent with the present invention. A single stream usage plan may be predefined and used by theHub110 and allPEAs120. ThePEA120 may have a different set of active streams for each MAC address it supports, and only responds to a token that specifies a MAC address of thePEA120 and a stream that is active for that MAC address. In an implementation consistent with the present invention, everyPEA120 may support one or more active Hub-to-PEA streams associated with the Hub's MAC address.
• Thestream usage plan700 includes several streams710-740, each having a predefined size and data transfer direction. Theplan700 may, of course, have more or fewer entries and may accommodate more than the two data block sizes shown in the figure. In theplan700, streams0-2 (710) are used to transmit the contents of small data blocks from thePEA120 to theHub110. Streams3-7 (720) are used to transmit the contents of larger data blocks from thePEA120 to theHub110. Streams8-10 (730), on the other hand, are used to transmit the contents of small data blocks from theHub110 to thePEA120. Streams11-15 (740) are used to transmit the contents of larger data blocks from theHub110 to thePEA120.
• To avoid collisions, some of the streams are reserved for PEAs desiring to attach to the network and the rest are reserved for PEAs already attached to the network. With such an arrangement, aPEA120 knows whether and what type of communication is scheduled by theHub110 based on a combination of theMAC address610 and thestream number620.
• FIG. 7B is a detailed diagram of an exemplary stream usage assignment by theLLT440 in an implementation consistent with the present invention. TheLLT440 assigns different streams to different communication purposes, reserving the streams with small block size for status, and using the streams with larger block size for snippets. For example, theLLT440 may use four streams (4-7 and12-15) for the transmission of snippets in each direction, two for odd parity snippets and two for even parity snippets. In other implementations consistent with the present invention, theLLT440 uses different numbers of streams of each parity and direction.
• The use of more than one stream for the same snippet allows a snippet to be sent in more than one form. For example, theLLT440 may send a snippet in its actual form through one stream and in a form with bytes complemented and in reverse order through the other stream. The alternating use of different transformations of a snippet more evenly distributes transmission errors among the bits of the snippet as they are received, and hence facilitates the reconstruction of a snippet from multiple corrupted received versions. The receiver always knows which form of the snippet was transmitted based on its stream number.
• TheLLT440 partitions the streams into two disjoint subsets, one for use withHub110 assigned MAC addresses750 and the other for use with attaching PEAs' self-selected MAC addresses (AMACs)760. Both theLLT440 and theLLD450 know the size and direction of each stream, but theLLT450 is responsible for determining how the streams are used, how MAC numbers are assigned and used, and assuring that no twoPEAs120 respond to the same token (containing a MAC address and stream number) transmitted by theHub110. One exception to this includes the Hub's use of its MAC address to broadcast its heartbeat770 (described below) to allPEAs120.
Exemplary Communication
• FIG. 8 is an exemplary diagram of aTDMA frame structure800 of a TDMA plan consistent with the present invention. TheTDMA frame800 starts with abeacon810, and then alternatestoken broadcasts820 and data transfers830. TheHub110 broadcasts thebeacon810 at the start of eachTDMA frame800. ThePEAs120 use thebeacon810, which may contain a unique identifier of theHub110, to synchronize to theHub110.
• Each token640 (FIG. 6) transmitted by theHub110 in atoken broadcast820 includes a MAC address610 (FIG. 6) and astream number620 for thedata buffer630 transfer that follows. TheMAC address610 andstream number620 in the token640 to_gether specify aparticular PEA120 to transmit or receive data, or, in the case of the Hub'sMAC address610, specify no, many, or all PEAs to receive data from the Hub110 (depending on the stream number). Thestream number620 in the token640 indicates the direction of the data transfer830 (Hub110 toPEA120 orPEA120 to Hub110), the number of bytes to be transferred, and the data source (for the sender) and the appropriate empty data block (for the receiver).
• The TDMA plan controls the maximum number of bytes that can be sent in adata transfer830. Not all of the permitted bytes need to be used in thedata transfer830, however, so theHub110 may schedule a status block in the initial segment of a TDMA time interval that is large enough to send a snippet. TheHub110 andPEA120 treat any left over bytes as no-ops to mark time. AnyPEA120 not involved in the data transfer uses all of the data transfer830 bytes to mark time while waiting for thenext token640. ThePEA120 may also power down non-essential circuitry at this time to reduce power consumption.
• FIG. 9A is an exemplary diagram of communication processing for transmitting a single data block from theHub110 to aPEA120 according to the TDMA plan ofFIG. 8.FIGS. 9B and 9C are flowcharts of theHub110 andPEA120 activities, respectively, ofFIG. 9A. The reference numbers inFIG. 9A correspond to the flowchart steps ofFIGS. 9B and 9C.
• With regard to the Hub activity, theHub110 responds to a token command in the TDMA plan [step911] (FIG. 9B) by determining the location of the next data block600 to send or receive [step912]. TheHub110 reads the block'sMAC address610 and stream number620 [step913] and generates a token640 from the MAC address and stream number using FEC [step914]. TheHub110 then waits for the time for sending a token640 in the TDMA plan (i.e., atoken broadcast820 inFIG. 8) [step915] and broadcasts the token640 to the PEAs120 [step916]. If thestream number620 in the token640 is zero (i.e., a NO-DATA-TRANSFER token), noPEA120 will respond and theHub110 waits for the next token command in the TDMA plan [step911].
• If thestream number620 is non-zero, however, theHub110 determines the size and direction of the data transmission from thestream number620 and waits for the time for sending the data in the TDMA plan (i.e., a data transfer830) [step917]. Later, when instructed to do so by the TDMA plan (i.e., after thePEA120 identified by theMAC address610 has had enough time to prepare), theHub110 transmits the contents of the data buffer630 [step918]. TheHub110 then prepares for the next token command in the TDMA plan [step919].
• With regard to the PEA activity, thePEA120 reaches a token command in the TDMA plan [step921] (FIG. 9C). ThePEA120 then listens for the forward error-correctedtoken640, having aMAC address610 andstream number620, transmitted by the Hub110 [step922]. ThePEA120 decodes the MAC address from the forward error-corrected token [step923] and, if it is not the PEA's120 MAC address, sleeps through thenext data transfer830 in the TDMA plan [step924]. Otherwise, thePEA120 also decodes thestream number620 from the token640.
• AllPEAs120 listen for the Hub heartbeat that theHub110 broadcasts with a token containing the Hub'sMAC address610 and theheartbeat stream770. During attachment (described in more detail below), thePEA120 may have two additional active MAC addresses610, the one it selected for attachment and the one theHub110 assigned to thePEA120. The streams are partitioned between these three classes of MAC addresses610, so thePEA120 may occasionally find that the token640 contains aMAC address610 that thePEA120 supports, but that thestream number620 in the token640 is not one that thePEA120 supports for thisMAC address610. In this case, thePEA120 sleeps through thenext data transfer830 in the TDMA plan [step924].
• Since thePEA120 supports more than oneMAC address610, thePEA120 uses theMAC address610 and thestream number620 to identify a suitable empty data block [step925]. ThePEA120 writes theMAC address610 andstream number620 it received in the token640 from theHub110 into the data block [step926]. ThePEA120 then determines the size and direction of the data transmission from thestream number620 and waits for the transmission of the data buffer630 contents from theHub110 during thenext data transfer830 in the TDMA plan [step927]. ThePEA120 stores the data in the data block [step928], and then prepares for the next token command in the TDMA plan [step929].
• FIGS. 9A-9C illustrate communication of a data block from theHub110 to aPEA120. When thePEA120 transfers a data block to theHub110, similar steps occur except that theHub110 first determines the next data block to receive (with itsMAC address610 and stream number620) and the transmission of the data buffer630 contents occurs in the opposite direction. TheHub110 needs to arrange in advance for receiving data fromPEAs120 by populating theMAC address610 andstream number620 into data blocks with empty data buffers630, because theHub110 generates the tokens for receiving data as well as for transmitting data.
• FIGS. 10A and 10B are high-level diagrams of the states that theHub110 andPEA120 LLT440 (FIG. 4) go through during a data transfer in an implementation consistent with the present invention.FIG. 10A illustrates states of a Hub-to-PEA transfer andFIG. 10B illustrates states of a PEA-to-Hub transfer.
• During the Hub-to-PEA transfer (FIG. 10A), theHub110 cycles through four states: fill, send even parity, fill, and send odd parity. The fill states indicate when the NI430 (FIG. 4) may fill a data snippet. The even and odd send states indicate when theHub110 sends even numbered and odd numbered snippets to thePEA120. ThePEA120 cycles through two states: want even and want odd. The two states indicate the PEA's120 desire for data, with ‘want even’ indicating that the last snippet successfully received had odd parity. ThePEA120 communicates its current state to theHub110 via its status messages (i.e., the state changes serve as ACKs). TheHub110 waits for a state change in thePEA120 before it transitions to its next fill state.
• During the PEA-to-Hub transfer (FIG. 10B), theHub110 cycles through six states: wait/listen for PEA-ready-to-send-even status, read even, send ACK and listen for status, wait/listen for PEA-ready-to-send-odd status, read odd, and send ACK and listen for status. According to this transfer, thePEA120 cannot transmit data until theHub110 requests data, which it will only do if it sees from the PEA's status that thePEA120 has the next data block ready.
• The four listen for status states schedule when theHub110 asks to receive a status message from thePEA120. The two ‘send ACK and listen for status’ states occur after successful receipt of a data block by theHub110, and in these two states theHub110 schedules both the sending of Hub status to thePEA120 and receipt of the PEA status. The PEA status informs theHub110 when thePEA120 has successfully received theHub110 status and has transitioned to the next ‘fill’ state.
• Once thePEA120 has prepared its next snippet, it changes its status to ‘have even’ or ‘have odd’ as appropriate. When theHub110 detects that thePEA120 has advanced to the fill state or to ‘have even/odd,’ it stops scheduling the sending of Hub status (ACK) to thePEA120. If theHub110 detects that thePEA120 is in the ‘fill’ state, it transitions to the following ‘listen for status’ state. If thePEA120 has already prepared a new snippet for transmission by the time theHub110 learns that its ACK was understood by thePEA120, theHub110 skips the ‘listen for status’ state and moves immediately to the next appropriate ‘read even/odd’ state. In this state, theHub110 receives the snippet from thePEA120.
• ThePEA120 cycles through four states: fill, have even, fill, and have odd (i.e., the same four states theHub110 cycles through when sending snippets). The fill states indicate when the NI430 (FIG. 4) can fill a data snippet. During the fill states, thePEA110 sets its status to ‘have nothing to send.’ ThePEA120 does not transition its status to ‘have even’ or ‘have odd’ until the next snippet is filled and ready to send to theHub110. These two status states indicate the parity of the snippet that thePEA120 is ready to send to theHub110. When theHub110 receives a status of ‘have even’ or ‘have odd’ and the last snippet it successfully received had the opposite parity, it schedules the receipt of data, which it thereafter acknowledges with a change of status that it sends to thePEA120.
Exemplary Attachment Processing
• TheHub110 communicates with only attachedPEAs120 that have an assignedMAC address610. An unattached PEA can attach to theHub110 when theHub110 gives it an opportunity to do so. Periodically, theHub110 schedules attachment opportunities for unattached PEAs that wish to attach to theHub110, using a small set of attach MAC (AMAC) addresses and a small set of streams dedicated to this purpose.
• After selecting one of the designated AMAC addresses610 at random to identify itself and preparing to send a small, possibly forward error-corrected, “attach-interest” message and a longer, possibly checksummed, “attach-request” message using this AMAC and the proper attachstream numbers620, thePEA120 waits for theHub110 to successfully read the attach-interest and then the attach-request messages. Reading of a valid attach-interest message by theHub110 causes theHub110 believe that there is aPEA120 ready to send the longer (and hence more likely corrupted) attach-request.
• Once a valid attach-interest is received, theHub110 schedules frequent receipt of the attach-request until it determines the contents of the attach-request, either by receiving the block intact with a valid checksum or by reconstructing the sent attach-request from two or more received instances of the sent attach-request. TheHub110 then assigns a MAC address to thePEA120, sending the address to thePEA120 using its AMAC address.
• TheHub110 confirms receipt of the MAC address by scheduling the reading of a small, possibly forward error-corrected, attach-confirmation from thePEA120 at itsnew MAC address610. TheHub110 follows this by sending a small, possibly forward error-corrected, confirmation to thePEA120 at its MAC address so that thePEA120 knows it is attached. ThePEA120 returns a final small, possibly forward error-corrected, confirmation acknowledgement to theHub110 so that theHub110, which is in control of all scheduled activity, has full knowledge of the state of thePEA120. This MAC address remains assigned to thatPEA120 for the duration of the time that thePEA120 is attached.
• FIGS. 11 and 12 are flowcharts of Hub and PEA attachment processing, respectively, consistent with the present invention. When theHub110 establishes the network, its logic initializes the attachment process and, as long as theHub110 continues to function, periodically performs attachment processing. TheHub110 periodically broadcasts heartbeats containing a Hub identifier (selecting a new heartbeat identifier value each time it reboots) and an indicator of the range of AMACs that can be selected from for the following attach opportunity [step1110] (FIG. 11). TheHub110 schedules an attach-interest via a token that schedules a small PEA-to-Hub transmission for each of the designated AMACs, so unattached PEAs may request attachment.
• Each attachingPEA120 selects a new AMAC at random from the indicated range when it hears the heartbeat. Because theHub110 may receive a garbled transmission whenever more than onePEA120 transmits, theHub110 occasionally indicates a large AMAC range (especially after rebooting) so that at least one of a number ofPEAs120 may select aunique AMAC610 and become attached. When noPEAs120 have attached for some period of time, however, theHub110 may select a small range ofAMACs610 to reduce attachment overhead, assuming thatPEAs120 will arrive in its vicinity in at most small groups. TheHub110 then listens for a valid attach-interest from an unattached PEA [step1120]. The attach-interest is a PEA-to-Hub message having theAMAC address610 selected by theunattached PEA120.
• Upon receiving a valid attach interest, theHub110 schedules a PEA-to-Hub attach-request token with the PEA'sAMAC610 and reads the PEA's attach-request [step1130]. Due to the low-power wireless environment of thePAN100, the attach-request transmission may take more than one attempt and hence may require scheduling the PEA-to-Hub attach-request token more than once. When theHub110 successfully receives the attach-request from the PEA, it assigns a MAC address to the PEA [step1140]. In some cases, theHub110 chooses the MAC address from the set of AMAC addresses.
• TheHub110 sends thenew MAC address610 in an attach-assignment message to the now-identifiedPEA120, still using the PEA'sAMAC address610 and astream number620 reserved for this purpose. TheHub110 schedules and listens for an attach-confirmation response from thePEA120 using the newly assigned MAC address610 [step1150].
• Upon receiving the confirmation from thePEA120, theHub110 sends its own confirmation, acknowledging that thePEA120 has switched to its new MAC, to thePEA120 and waits for a final acknowledgment from the PEA120 [step1160]. TheHub110 continues to send the confirmation until it receives the acknowledgment from thePEA120 or until it times out. In each of the steps above, theHub110 counts the number of attempts it makes to send or receive, and aborts the attachment effort if a predefined maximum number of attempts is exceeded. Upon receiving the final acknowledgment, theHub110 stops sending its attach confirmation, informs its NI430 (FIG. 4) that thePEA120 is attached, and begins exchanging both data and keep-alive messages (described below) with thePEA120.
• When anunattached PEA120 enters the network, its LLC420 (FIG. 4) instructs itsLLT440 to initialize attachment. Unlike theHub110, thePEA120 waits to be polled. ThePEA120 instructs itsDCL460 to activate and associate the heartbeat stream770 (FIG. 7B) with the Hub's MAC address and waits for the heartbeat broadcast from the Hub110 [step1210] (FIG. 12). ThePEA120 then selects a random AMAC address from the range indicated in the heartbeat to identify itself to the Hub110 [step1220]. ThePEA120 instructs itsDCL460 to send an attach-interest and an attach-request data block to theHub110, and activate and associate the streams with its AMAC address [step1230]. ThePEA120 tells its driver to activate and respond to the selected AMAC address for the attach-assignment stream.
• Theunattached PEA120 then waits for an attach-assignment with an assigned MAC address from the Hub110 [step1240]. Upon receiving the attach-assignment, thePEA120 finds its Hub-assigned MAC address and tells its driver to use this MAC address to send an attach-confirmation to theHub110 to acknowledge receipt of its new MAC address [step1250], activate all attached-PEA streams for its new MAC address, and deactivate the streams associated with its AMAC address.
• ThePEA120 waits for an attach confirmation from theHub110 using the new MAC address [step1260] and, upon receiving it, sends a final acknowledgment to the Hub110 [step1270]. ThePEA120 then tells itsNI430 that it is attached.
• ThePEA120, if it hears another heartbeat from theHub110 before it completes attachment, discards any prior communication and begins its attachment processing over again with a new AMAC.
Exemplary Detachment and Reattachment Processing
• TheHub110 periodically informs all attachedPEAs120 that they are attached by sending them ‘keep-alive’ messages. TheHub110 may send the messages at least as often as it transmits heartbeats. TheHub110 may send individual small, possibly forward error-corrected, keep-alive messages to each attachedPEA120 whenfew PEAs120 are attached, or may send larger, possibly forward error-corrected, keep-alive messages to groups ofPEAs120.
• Whenever theHub110 schedules tokens for PEA-to-Hub communications, it sets a counter to zero. The counter resets to zero each time theHub110 successfully receives a block (either uncorrupted or reconstructed) from thePEA120, and increments for unreadable blocks. If the counter exceeds a predefined threshold, theHub110 automatically detaches thePEA120 without any negotiation with thePEA120. After this happens, theHub110 no longer schedules data or status transfers to or from thePEA120, and no longer sends it any keep-alive messages.
• FIG. 13 is a flowchart of PEA detachment and reattachment processing consistent with the present invention. Each attachedPEA120 listens for Hub heartbeat and keep-alive messages [step1310]. When thePEA120 first attaches, and after receiving each keep-alive message, it resets its heartbeat counter to zero [step1320]. Each time thePEA120 hears a heartbeat, it increments the heartbeat counter [step1330]. If the heartbeat counter exceeds a predefined threshold, thePEA120 automatically assumes that theHub110 has detached it from the network100 [step1340]. After this happens, thePEA120 attempts to reattach to the Hub110 [step1350], using attachment processing similar to that described with respect toFIGS. 11 and 12.
• If theHub110 had not actually detached thePEA120, then the attempt to reattach causes theHub110 to detach thePEA120 so that the attempt to reattach can succeed. When thePEA120 is out of range of theHub110, it may not hear from theHub110 and, therefore, does not change state or increment its heartbeat counter. ThePEA120 has no way to determine whether theHub110 has detached it or how long theHub110 might wait before detaching it. When thePEA120 comes back into range of theHub110 and hears the Hub heartbeat (and keep-alive if sent), thePEA120 then determines whether it is attached and attempts to reattach if necessary.
CONCLUSION
• Systems and methods consistent with the present invention provide a wireless personal area network that permit a host device to communicate with a varying number of peripheral devices with minimal power and minimal interference from neighboring networks by using a customized TDMA protocol. The host device uses tokens to facilitate the transmission of data blocks through the network.
• The foregoing description of exemplary embodiments of the present invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The scope of the invention is defined by the claims and their equivalents.

Claims (21)

1. In a personal area network having at least one peripheral device not communicably attached to the network and a hub device connected to the network, a method for attaching the peripheral device to the network, comprising:

transmitting, by the peripheral device, an attachment request to attach to the network with a selected address;

receiving the attachment request by the hub device;

generating a new address for the peripheral device in response to the received attachment request;

sending the new address from the hub device to the peripheral device using the selected address;

further communicating between the hub device and the peripheral device using the new address; and

broadcasting, by the hub device, a heartbeat signal to begin an attach cycle.

2. The method ofclaim 1, further comprising:

abandoning a current attach attempt by the peripheral device upon receipt of the heartbeat signal prior to receiving the new address from the hub device, and

beginning a new attempt to attach to the network.

3. The method ofclaim 1, further comprising:

broadcasting, by the hub device, a range of available addresses.

4. The method ofclaim 3, further comprising:

selecting, by the peripheral device, an address from the range of available addresses to identify the peripheral device to the hub device in the attachment request.

5. The method ofclaim 4, further comprising:

listening, by the hub device, for an address in the range of available addresses, for a signal from an unattached peripheral device.

6. The method ofclaim 1, further comprising:

attaching the peripheral device to the network using the new address.

7. The method ofclaim 1, wherein the network further includes at least one other peripheral device communicably coupled to the hub device; and

wherein the method further comprises:

determining, by the hub device, whether a transmission from the other peripheral device was successful; and

detaching the other peripheral device when the transmission fails to be successful in a predetermined number of attempts.

8. The method ofclaim 1, wherein the network further includes at least one other peripheral device communicably coupled to the hub device; and

wherein the method further comprises:

transmitting, by the hub device, a heartbeat signal to each of the other peripheral devices; and

periodically transmitting, by the hub device, a keep-alive signal to each of the other peripheral devices.

9. The method ofclaim 8, further comprising:

receiving the heartbeat signal at the other peripheral devices;

receiving the keep-alive signal at the other peripheral devices; and

detaching from the network when a predetermined number of heartbeat signals has been received prior to the keep-alive signal.

10. The method ofclaim 1, wherein the network further includes at least one other peripheral device communicably coupled to the hub device; and

wherein the method further comprises:

receiving, by the hub device, an attach request from one of the other peripheral devices, and

detaching the other peripheral device in response to receipt of the attach request from the other peripheral device.

11. A hub device in a network having a plurality of attached peripheral devices and an unattached peripheral device, comprising:

a memory having instructions for:

broadcasting a range of available addresses,

generating a new address to identify the unattached peripheral device in response to receipt of an attach request from the unattached peripheral device, the attach request identifying the unattached peripheral device to the hub device,

sending the new address to the unattached peripheral device using the selected address,

receiving confirmation from the unattached peripheral device using the new address, and

sending a confirmation message to the unattached peripheral device using the new address; and

a processor that executes the instructions in the memory.

12. The hub device ofclaim 11, wherein the memory further includes instructions for:

broadcasting a heartbeat signal to begin an attach cycle.

13. The hub device ofclaim 12, wherein the instructions for broadcasting include:

broadcasting a new range of available addresses with each heartbeat signal.

14. The hub device ofclaim 11, wherein the memory further includes instructions for:

listening, for each of the addresses in the range of available addresses, for a signal from the unattached peripheral device.

15. The hub device ofclaim 11, wherein the memory further includes instructions for:

determining whether a transmission from one of the attached peripheral devices was successful, and

detaching the attached peripheral device when the transmission fails to be successful in a predetermined number of attempts.

16. A method for attaching an unattached peripheral device to a network having a hub device connected to a set of peripheral devices, the method, performed by the hub device, comprising:

receiving an attach request from the unattached peripheral device, the attach request identifying the unattached peripheral device to the hub device;

generating a new address to identify the unattached peripheral device in response to the received attach request;

sending the new address to the unattached peripheral device; and

sending a confirmation message to the unattached peripheral device using the new address to attach the unattached peripheral device.

17. The method ofclaim 16, further comprising:

broadcasting a range of available addresses from which the unattached peripheral device selects to use when sending the attach request to the hub device.

18. The method ofclaim 17, further comprising:

listening, for each of the addresses in the range of available addresses, for a signal from the unattached peripheral device;

determining whether a transmission from the unattached peripheral device at one of the addresses was successful; and

discarding an attach attempt by the unattached peripheral device at the one address when the transmission fails to be successful in a predetermined number of attempts.

19. The method ofclaim 16, further comprising:

attaching the unattached peripheral device to the network to create a newly attached peripheral device capable of communicating with the hub device.

20. A computer-readable medium that stores instructions executable by a hub device to cause the hub device to perform a method for attaching an unattached peripheral device to a network, the method comprising:

broadcasting a range of available addresses;

listening, for each of the available addresses, for an attach request from an unattached peripheral device;

generating a new address to identify the unattached peripheral device in response to receipt of the attach request from the unattached peripheral device, the attach request identifying the unattached peripheral device to the hub device;

sending the new address to the unattached peripheral device;

receiving confirmation from the peripheral device using the new address; and

attaching the unattached peripheral device using the new address.

21. An unattached peripheral device in a network having a plurality of peripheral devices connected to a hub device, comprising:

a memory having instructions for:

selecting an address from a range of available addresses broadcast by the hub device to identify the unattached peripheral device to the hub device,

transmitting an attach request with the selected address to the hub device,

receiving a new address from the hub device to identify the unattached peripheral device,

sending a confirmation message with the new address to the hub device, and

attaching to the hub device using the new address; and

a processor that executes the instructions in the memory.

Images