U.S. patent application number 15/263289 was filed with the patent office on 2017-03-09 for personal area network apparatus.
The applicant listed for this patent is Azure Networks, LLC. Invention is credited to Robert J Donaghey.
Application Number | 20170070846 15/263289 |
Document ID | / |
Family ID | 33098369 |
Filed Date | 2017-03-09 |
United States Patent
Application |
20170070846 |
Kind Code |
A1 |
Donaghey; Robert J |
March 9, 2017 |
PERSONAL AREA NETWORK APPARATUS
Abstract
A portable endpoint device comprises a first virtual device and
a second virtual device integrated in a same single unit and
configured such that the first virtual device and the second
virtual device are configured to allow communication therewith as
virtually different physical devices despite being integrated in
the same single unit. In operation, the device is configured to
receive a first signal from another endpoint device to indicate the
availability of the another endpoint device for attachment; send,
to the another endpoint device a second signal utilizing first
scheduling-related information, the second signal including a first
one of a plurality of identifiers for unique identification in
association with the portable endpoint device; receive, from the
another endpoint device a third signal that is sent in response to
the second signal; and receive, from the another endpoint device
data utilizing a second one of the identifiers for identification
in association with the portable endpoint device.
Inventors: |
Donaghey; Robert J;
(Lexington, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Azure Networks, LLC |
Longview |
TX |
US |
|
|
Family ID: |
33098369 |
Appl. No.: |
15/263289 |
Filed: |
September 12, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14252687 |
Apr 14, 2014 |
9445260 |
|
|
15263289 |
|
|
|
|
13754807 |
Jan 30, 2013 |
8700815 |
|
|
14252687 |
|
|
|
|
13430650 |
Mar 26, 2012 |
8675590 |
|
|
13754807 |
|
|
|
|
12699846 |
Feb 3, 2010 |
8149829 |
|
|
13430650 |
|
|
|
|
11728246 |
Mar 23, 2007 |
7756129 |
|
|
12699846 |
|
|
|
|
10894406 |
Jul 19, 2004 |
7218633 |
|
|
11728246 |
|
|
|
|
09535591 |
Mar 27, 2000 |
6804232 |
|
|
10894406 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W 60/00 20130101;
H04W 8/245 20130101; H04L 67/02 20130101; H04L 51/08 20130101; H04L
51/00 20130101; H04L 61/2038 20130101; Y02D 10/151 20180101; H04W
76/10 20180201; H04L 12/66 20130101; H04L 29/12254 20130101; H04L
61/2069 20130101; H04W 84/12 20130101; H04W 76/00 20130101; H04W
4/80 20180201; Y02D 10/00 20180101; G06F 13/10 20130101; G06F 13/38
20130101; H04W 48/16 20130101; H04B 7/2612 20130101; Y02D 10/14
20180101 |
International
Class: |
H04W 4/00 20060101
H04W004/00; H04W 76/02 20060101 H04W076/02; H04W 48/16 20060101
H04W048/16 |
Claims
1. A portable endpoint device for use on a network, comprising: a
first virtual device and a second virtual device integrated in a
same single unit and configured such that the first virtual device
and the second virtual device are configured to allow communication
therewith as virtually different physical devices despite being
integrated in the same single unit; circuitry; and a transceiver in
communication with the circuitry, the portable endpoint device
configured to cause the transceiver to: receive, directly
endpoint-to-endpoint over a shared wireless area communication
medium without passing through any intermediate node such that no
wireless routing occurs therebetween over the shared wireless area
communication medium, a first signal from another endpoint device
without being wirelessly routed therethrough to indicate the
availability of the another endpoint device for attachment over the
shared wireless area communication medium, the first signal
including a unique device identifier of the another endpoint
device; send, to the another endpoint device directly
endpoint-to-endpoint over the shared wireless area communication
medium without passing through any intermediate node such that no
wireless routing occurs therebetween over the shared wireless area
communication medium, a second signal utilizing first
scheduling-related information, the second signal including a first
one of a plurality of identifiers for unique identification in
association with the portable endpoint device; receive, from the
another endpoint device directly endpoint-to-endpoint over the
shared wireless area communication medium without passing through
any intermediate node such that no wireless routing occurs
therebetween over the shared wireless area communication medium, a
third signal that is sent in response to the second signal, the
third signal including the first one of the identifiers for unique
identification in association with the portable endpoint device;
and receive, from the another endpoint device directly
endpoint-to-endpoint over the shared wireless area communication
medium utilizing at least one channel different from at least one
pre-data transfer channel without passing through any intermediate
node such that no wireless routing occurs therebetween over the
shared wireless area communication medium, data utilizing a second
one of the identifiers for identification in association with the
portable endpoint device, for data transfer in connection with a
group owned by the another endpoint device and including at least
the portable endpoint device and the another endpoint device.
2. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first one of
the identifiers includes a first one of a plurality of addresses
operable for being utilized for a first instance of the attachment
utilizing the at least one pre-data transfer channel on a local
area wireless network, wherein the portable endpoint device is
further configured such that the second one of the identifiers
includes a second one of the addresses operable for being utilized
for the data transfer utilizing the at least one channel on the
local area wireless network.
3. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that the first one of
the addresses and the second one of the addresses are of the same
length.
4. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that the first one of
the addresses and the second one of the addresses have the same
address format.
5. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that the first one of
the addresses and the second one of the addresses are of the same
size.
6. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that at least a portion
of the first one of the addresses and at least a portion of the
second one of the addresses are the same.
7. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that at least a portion
of the first one of the addresses and at least a portion of the
second one of the addresses have the same value.
8. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that the first one of
the addresses and the second one of the addresses are MAC
Addresses.
9. The portable endpoint device according to claim 2, wherein the
portable endpoint device is configured such that the first one of
the addresses includes a MAC Address.
10. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device and the second virtual device are each operable for
communicating over the shared wireless area communication
medium.
11. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device and the second virtual device are each operable for only
short range communications over the shared wireless area
communication medium.
12. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device and the second virtual device are each operable for
communicating on at least one local area wireless network.
13. The portable endpoint device according to claim 12, wherein the
portable endpoint device is configured such that the at least one
local area wireless network includes at least one personal area
wireless network.
14. The portable endpoint device according to claim 1, wherein the
portable endpoint device includes a personal electronic
accessory.
15. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device and the second virtual device are each operable for
communicating on at least one short range wireless network.
16. The portable endpoint device according to claim 15, wherein the
portable endpoint device is configured such that the at least one
short range wireless network includes at least one personal area
wireless network.
17. The portable endpoint device according to claim 1, wherein the
portable endpoint device is a phone or a computer.
18. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device and the second virtual device are each operable for only
short range wireless communication.
19. The portable endpoint device according to claim 1, wherein the
portable endpoint device is configured such that the first virtual
device is configured for serving as a first type of device and the
second virtual device is configured for serving as a second type of
device.
Description
RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 14/252,687, filed on Apr. 14, 2014, which is a
continuation of U.S. patent application Ser. No. 13/754,807, filed
on Jan. 30, 2012, now U.S. Pat. No. 8,700,815, which is a
continuation of U.S. patent application Ser. No. 13/430,650 filed
on Mar. 26, 2012, now U.S. Pat. No. 8,675,590, which is a
continuation of U.S. patent application Ser. No. 12/699,846 filed
on Feb. 3, 2010, now U.S. Pat. No. 8,149,829, which is a
continuation of U.S. patent application Ser. No. 11/728,246 filed
on Mar. 23, 2007, now U.S. Pat. No. 7,756,129, which is a
continuation of U.S. patent application Ser. No. 10/894,406 filed
on Jul. 19, 2004, now U.S. Pat. No. 7,218,633, 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 Ser. No. 09/536,191 filed on Mar. 27, 2000,
all of which are incorporated herein by reference in their entirety
for all purposes.
BACKGROUND AND FIELD OF THE INVENTION
[0002] A. Field of the Invention
[0003] The present invention relates to network protocols and, more
particularly, to attachment protocols for use in a network.
[0004] 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 laptops 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.
[0005] 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.
[0006] 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
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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
[0011] 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:
[0012] FIG. 1 is a diagram of a personal area network (PAN) in
which systems and methods consistent with the present invention may
be implemented;
[0013] FIG. 2 is a simplified block diagram of the Hub of FIG.
1;
[0014] FIG. 3 is a simplified block diagram of a PEA of FIG. 1;
[0015] FIG. 4 is a block diagram of a software architecture of a
Hub or PEA in an implementation consistent with the present
invention;
[0016] FIG. 5 is an exemplary diagram of communication processing
by the layers of the software architecture of FIG. 4;
[0017] 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;
[0018] FIG. 7A is a detailed diagram of an exemplary stream usage
plan in an implementation consistent with the present
invention;
[0019] FIG. 7B is a detailed diagram of an exemplary stream usage
assignment in an implementation consistent with the present
invention;
[0020] FIG. 8 is an exemplary diagram of a time division multiple
access (TDMA) frame structure in an implementation consistent with
the present invention;
[0021] FIG. 9A is a detailed diagram of activity within the Hub and
PEA according to a TDMA plan consistent with the present
invention;
[0022] FIG. 9B is a flowchart of the Hub activity of FIG. 9A;
[0023] FIG. 9C is a flowchart of the PEA activity of FIG. 9A;
[0024] 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;
[0025] FIGS. 11 and 12 are flowcharts of Hub and PEA attachment
processing, respectively, consistent with the present invention;
and
[0026] FIG. 13 is a flowchart of PEA detachment and reattachment
processing consistent with the present invention.
DETAILED DESCRIPTION
[0027] 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.
[0028] 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
[0029] 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.
[0030] 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.
[0031] FIG. 1 is a diagram of a PAN 100 consistent with the present
invention. The PAN 100 includes a single Hub device 110 surrounded
by multiple Personal Electronic Accessory (PEA) devices 120
configured in a star topology. Other topologies may also be
possible. Each device is identified by a Media Access (MAC)
address.
[0032] The Hub 110 orchestrates all communication in the PAN 100,
which consists of communication between the Hub 110 and one or more
PEA(s) 120. The Hub 110 manages the timing of the network,
allocates available bandwidth among the currently attached PEAs 120
participating in the PAN 100, and supports the attachment,
detachment, and reattachment of PEAs 120 to and from the PAN
100.
[0033] The Hub 110 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. The Hub 110 could, however,
include other devices.
[0034] The PEAs 120 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.
[0035] The Hub 110 and PEAs 120 communicate using multiplexed
communication over a predefined set of streams. Logically, a stream
is a one-way communications link between one PEA 120 and its Hub
110. Each stream has a predetermined size and direction. The Hub
110 uses stream numbers to identify communication channels for
specific functions (e.g., data and control).
[0036] The Hub 110 uses MAC addresses to identify itself and the
PEAs 120. The Hub 110 uses its own MAC address to broadcast to all
PEAs 120. The Hub 110 might also use MAC addresses to identify
virtual PEAs within any one physical PEA 120. The Hub 110 combines
a MAC address and a stream number into a token, which it broadcasts
to the PEAs 120 to control communication through the network 100.
The PEA 120 responds to the Hub 110 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 the PEA
120.
Exemplary Hub Device
[0037] FIG. 2 is a simplified block diagram of the Hub 110 of FIG.
1. The Hub 110 may be a battery-powered device that includes Hub
host 210, digital control logic 220, radio frequency (RF)
transceiver 230, and an antenna 240.
[0038] Hub host 210 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 the Hub host 210 and the
RF transceiver 230. The DCL 220 is specifically designed to
minimize power consumption, cost, and size of the Hub 110. Its
design centers around a time-division multiple access (TDMA)-based
network access protocol that exploits the short range nature of the
PAN 100. The Hub host 210 causes the DCL 220 to initialize the
network 100, send tokens and messages, and receive messages.
Responses from the DCL 220 feed incoming messages to the Hub host
210.
[0039] The RF transceiver 230 includes a conventional RF
transceiver that transmits and receives information via the antenna
240. The RF transceiver 230 may alternatively include separate
transmitter and receiver devices controlled by the DCL 220. The
antenna 240 includes a conventional antenna for transmitting and
receiving information over the network.
[0040] While FIG. 2 shows the exemplary Hub 110 as consisting of
three separate elements, these elements may be physically
implemented in one or more integrated circuits. For example, the
Hub host 210 and the DCL 220, the DCL 220 and the RF transceiver
230, or the Hub host 210, the DCL 220, and the RF transceiver 230
may be implemented as a single integrated circuit or separate
integrated circuits. Moreover, one skilled in the art will
recognize that the Hub 110 may include additional elements that aid
in the sending, receiving, and processing of data.
Exemplary PEA Device
[0041] FIG. 3 is a simplified block diagram of the PEA 120. The PEA
120 may be a battery-powered device that includes a PEA host 310,
DCL 320, RF transceiver 330, and an antenna 340. The PEA host 310
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.
[0042] The DCL 320 may include a controller that coordinates the
operations of the PEA host 310 and the RF transceiver 330. The DCL
320 sequences the operations necessary in establishing
synchronization with the Hub 110, in data communications, in
coupling received information from the RF transceiver 330 to the
PEA host 310, and in transmitting data from the PEA host 310 back
to the Hub 110 through the RF transceiver 330.
[0043] The RF transceiver 330 includes a conventional RF
transceiver that transmits and receives information via the antenna
340. The RF transceiver 330 may alternatively include separate
transmitter and receiver devices controlled by the DCL 320. The
antenna 340 includes a conventional antenna for transmitting and
receiving information over the network.
[0044] While FIG. 3 shows the exemplary PEA 120 as consisting of
three separate elements, these elements may be physically
implemented in one or more integrated circuits. For example, the
PEA host 310 and the DCL 320, the DCL 320 and the RF transceiver
330, or the PEA host 310, the DCL 320, and the RF transceiver 330
may be implemented as a single integrated circuit or separate
integrated circuits. Moreover, one skilled in the art will
recognize that the PEA 120 may include additional elements that aid
in the sending, receiving, and processing of data.
Exemplary Software Architecture
[0045] FIG. 4 is an exemplary diagram of a software architecture
400 of the Hub 110 in an implementation consistent with the present
invention. The software architecture 400 in the PEA 120 has a
similar structure. The software architecture 400 includes several
distinct layers, each designed to serve a specific purpose,
including: (1) application 410, (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 hardware 460. The
layers have application programming interfaces (APIs) to facilitate
communication with lower layers. The LLD 450 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.
[0046] The application 410 may include any application executing on
the Hub 110, such as a communication routine. The LLC 420 performs
several miscellaneous tasks, such as initialization, attachment
support, bandwidth control, and token planning. The LLC 420
orchestrates device initialization, including the initialization of
the other layers in the software architecture 400, upon
power-up.
[0047] The LLC 420 provides attachment support by providing
attachment opportunities for unattached PEAs to attach to the Hub
110 so that they can communicate, providing MAC address assignment,
and initializing an NI 430 and the layers below it for
communication with a PEA 120. The LLC 420 provides bandwidth
control through token planning. Through the use of tokens, the LLC
420 allocates bandwidth to permit one PEA 120 at a time to
communicate with the Hub 110.
[0048] The NI 430 acts on its own behalf, or for an application 410
layer above it, to deliver data to the LLT 440 beneath it. The LLT
440 provides an ordered, reliable "snippet" (i.e., a data block)
delivery service for the NI 430 through the use of encoding (e.g.,
16-64 bytes of data plus a cyclic redundancy check (CRC)) and
snippet retransmission. The LLT 440 accepts snippets, in order,
from the NI 430 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).
[0049] The LLD 450 is the lowest level of software in the software
architecture 400. The LLD 450 interacts with the DCL hardware 460.
The LLD 450 initializes and updates data transfers via the DCL
hardware 460 as it delivers and receives data blocks for the LLT
440, and processes hardware interrupts. The DCL hardware 460 is the
hardware driven by the LLD 450.
[0050] FIG. 5 is an exemplary diagram of communication processing
by the layers of the software architecture 400 of FIG. 4. In FIG.
5, the exemplary communications involve the transmission of a
snippet from one node to another. This example assumes that the
sending node is the Hub 110 and the receiving node is a PEA 120.
Processing begins with the NI 430 of the Hub 110 deciding to send
one or more bytes (but no more than will fit) in a snippet. The NI
430 exports the semantics that only one transaction is required to
transmit these bytes to their destination (denoted by "(1)" in the
figure). The NI 430 sends a unique identifier for the destination
PEA 120 of the snippet to the LLT 440. The LLT 440 maps the PEA
identifier to the MAC address assigned to the PEA 120 by the Hub
110.
[0051] The LLT 440 transmits the snippet across the network to the
receiving device. To accomplish this, the LLT 440 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 in FIG. 5 by the
bidirectional arrow between the LLT 440 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. The LLT 440 may also encrypt portions or all of the
snippet using known encryption technology.
[0052] The LLT 440 uses the LLD 450 to provide a basic block and
stream-oriented communications service, isolating the DCL 460
interface from the potentially complex processing required of the
LLT 440. The LLT 440 uses multiple stream numbers to differentiate
snippet and status blocks so that the LLD 450 need not know which
blocks contain what kind of content. The LLD 450 reads and writes
the hardware DCL 460 to trigger the transmission and reception of
data blocks. The PEA LLT 440, through the PEA LLD 450, instructs
the PEA DCL 460 which MAC address or addresses to respond to, and
which stream numbers to respond to for each MAC address. The Hub
LLT 440, through the Hub LLD 450, instructs the Hub DCL 460 which
MAC addresses and stream numbers to combine into tokens and
transmit so that the correct PEA 120 will respond. The Hub DCL 460
sends and receives (frequently in a corrupted form) the data blocks
across the RF network via the Hub RF transceiver 230 (FIG. 2).
[0053] The Hub LLT 440 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 LLT 440). The PEA LLT 440 delivers snippets in the same
order that they were sent by the Hub NI 430 to the PEA NI 430. The
PEA NI 430 takes the one or more bytes sent in the snippets and
delivers them in order to the higher-level application 410, thereby
completing the transmission.
Exemplary DCL Data Block Architecture
[0054] FIG. 6 is an exemplary diagram of a data block architecture
600 within the DCL of the Hub 110 and the PEA 120. The data block
600 contains a MAC address 610 designating a receiving or sending
PEA 120, a stream number 620 for the communication, and a data
buffer 630 which is full when sending and empty when receiving. As
will be described later, the MAC address 610 and stream number 620
form the contents of a token 640. When the LLD 450 reads from and
writes to the hardware DCL 460, the LLD 450 communicates the MAC
address 610 and stream number 620 with the data buffer 630. When a
PEA 120 receives a data block, the DCL 460 places the MAC address
610 and stream number 620 contained in the preceding token 640 in
the data block 600 to keep track of the different data flows.
Exemplary Stream Architecture
[0055] The LLD 450 provides a multi-stream data transfer service
for the LLT 440. While the LLT 440 is concerned with data snippets
and status/acknowledgements, the LLD 450 is concerned with the size
of data blocks and the direction of data transfers to and from the
Hub 110.
[0056] FIG. 7A is a detailed diagram of an exemplary stream usage
plan 700 in an implementation consistent with the present
invention. A single stream usage plan may be predefined and used by
the Hub 110 and all PEAs 120. The PEA 120 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 the PEA 120 and
a stream that is active for that MAC address. In an implementation
consistent with the present invention, every PEA 120 may support
one or more active Hub-to-PEA streams associated with the Hub's MAC
address.
[0057] The stream usage plan 700 includes several streams 710-740,
each having a predefined size and data transfer direction. The plan
700 may, of course, have more or fewer entries and may accommodate
more than the two data block sizes shown in the figure. In the plan
700, streams 0-2 (710) are used to transmit the contents of small
data blocks from the PEA 120 to the Hub 110. Streams 3-7 (720) are
used to transmit the contents of larger data blocks from the PEA
120 to the Hub 110. Streams 8-10 (730), on the other hand, are used
to transmit the contents of small data blocks from the Hub 110 to
the PEA 120. Streams 11-15 (740) are used to transmit the contents
of larger data blocks from the Hub 110 to the PEA 120.
[0058] 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,
a PEA 120 knows whether and what type of communication is scheduled
by the Hub 110 based on a combination of the MAC address 610 and
the stream number 620.
[0059] FIG. 7B is a detailed diagram of an exemplary stream usage
assignment by the LLT 440 in an implementation consistent with the
present invention. The LLT 440 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, the LLT 440 may use four streams (4-7
and 12-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, the LLT 440
uses different numbers of streams of each parity and direction.
[0060] The use of more than one stream for the same snippet allows
a snippet to be sent in more than one form. For example, the LLT
440 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.
[0061] The LLT 440 partitions the streams into two disjoint
subsets, one for use with Hub 110 assigned MAC addresses 750 and
the other for use with attaching PEAs' self-selected MAC addresses
(AMACs) 760. Both the LLT 440 and the LLD 450 know the size and
direction of each stream, but the LLT 450 is responsible for
determining how the streams are used, how MAC numbers are assigned
and used, and assuring that no two PEAs 120 respond to the same
token (containing a MAC address and stream number) transmitted by
the Hub 110. One exception to this includes the Hub's use of its
MAC address to broadcast its heartbeat 770 (described below) to all
PEAs 120.
Exemplary Communication
[0062] FIG. 8 is an exemplary diagram of a TDMA frame structure 800
of a TDMA plan consistent with the present invention. The TDMA
frame 800 starts with a beacon 810, and then alternates token
broadcasts 820 and data transfers 830. The Hub 110 broadcasts the
beacon 810 at the start of each TDMA frame 800. The PEAs 120 use
the beacon 810, which may contain a unique identifier of the Hub
110, to synchronize to the Hub 110.
[0063] Each token 640 (FIG. 6) transmitted by the Hub 110 in a
token broadcast 820 includes a MAC address 610 (FIG. 6) and a
stream number 620 for the data buffer 630 transfer that follows.
The MAC address 610 and stream number 620 in the token 640 together
specify a particular PEA 120 to transmit or receive data, or, in
the case of the Hub's MAC address 610, specify no, many, or all
PEAs to receive data from the Hub 110 (depending on the stream
number). The stream number 620 in the token 640 indicates the
direction of the data transfer 830 (Hub 110 to PEA 120 or PEA 120
to Hub 110), the number of bytes to be transferred, and the data
source (for the sender) and the appropriate empty data block (for
the receiver).
[0064] The TDMA plan controls the maximum number of bytes that can
be sent in a data transfer 830. Not all of the permitted bytes need
to be used in the data transfer 830, however, so the Hub 110 may
schedule a status block in the initial segment of a TDMA time
interval that is large enough to send a snippet. The Hub 110 and
PEA 120 treat any left over bytes as no-ops to mark time. Any PEA
120 not involved in the data transfer uses all of the data transfer
830 bytes to mark time while waiting for the next token 640. The
PEA 120 may also power down non-essential circuitry at this time to
reduce power consumption.
[0065] FIG. 9A is an exemplary diagram of communication processing
for transmitting a single data block from the Hub 110 to a PEA 120
according to the TDMA plan of FIG. 8. FIGS. 9B and 9C are
flowcharts of the Hub 110 and PEA 120 activities, respectively, of
FIG. 9A. The reference numbers in FIG. 9A correspond to the
flowchart steps of FIGS. 9B and 9C.
[0066] With regard to the Hub activity, the Hub 110 responds to a
token command in the TDMA plan [step 911] (FIG. 9B) by determining
the location of the next data block 600 to send or receive [step
912]. The Hub 110 reads the block's MAC address 610 and stream
number 620 [step 913] and generates a token 640 from the MAC
address and stream number using FEC [step 914]. The Hub 110 then
waits for the time for sending a token 640 in the TDMA plan (i.e.,
a token broadcast 820 in FIG. 8) [step 915] and broadcasts the
token 640 to the PEAs 120 [step 916]. If the stream number 620 in
the token 640 is zero (i.e., a NO-DATA-TRANSFER token), no PEA 120
will respond and the Hub 110 waits for the next token command in
the TDMA plan [step 911].
[0067] If the stream number 620 is non-zero, however, the Hub 110
determines the size and direction of the data transmission from the
stream number 620 and waits for the time for sending the data in
the TDMA plan (i.e., a data transfer 830) [step 917]. Later, when
instructed to do so by the TDMA plan (i.e., after the PEA 120
identified by the MAC address 610 has had enough time to prepare),
the Hub 110 transmits the contents of the data buffer 630 [step
918]. The Hub 110 then prepares for the next token command in the
TDMA plan [step 919].
[0068] With regard to the PEA activity, the PEA 120 reaches a token
command in the TDMA plan [step 921] (FIG. 9C). The PEA 120 then
listens for the forward error-corrected token 640, having a MAC
address 610 and stream number 620, transmitted by the Hub 110 [step
922]. The PEA 120 decodes the MAC address from the forward
error-corrected token [step 923] and, if it is not the PEA's 120
MAC address, sleeps through the next data transfer 830 in the TDMA
plan [step 924]. Otherwise, the PEA 120 also decodes the stream
number 620 from the token 640.
[0069] All PEAs 120 listen for the Hub heartbeat that the Hub 110
broadcasts with a token containing the Hub's MAC address 610 and
the heartbeat stream 770. During attachment (described in more
detail below), the PEA 120 may have two additional active MAC
addresses 610, the one it selected for attachment and the one the
Hub 110 assigned to the PEA 120. The streams are partitioned
between these three classes of MAC addresses 610, so the PEA 120
may occasionally find that the token 640 contains a MAC address 610
that the PEA 120 supports, but that the stream number 620 in the
token 640 is not one that the PEA 120 supports for this MAC address
610. In this case, the PEA 120 sleeps through the next data
transfer 830 in the TDMA plan [step 924].
[0070] Since the PEA 120 supports more than one MAC address 610,
the PEA 120 uses the MAC address 610 and the stream number 620 to
identify a suitable empty data block [step 925]. The PEA 120 writes
the MAC address 610 and stream number 620 it received in the token
640 from the Hub 110 into the data block [step 926]. The PEA 120
then determines the size and direction of the data transmission
from the stream number 620 and waits for the transmission of the
data buffer 630 contents from the Hub 110 during the next data
transfer 830 in the TDMA plan [step 927]. The PEA 120 stores the
data in the data block [step 928], and then prepares for the next
token command in the TDMA plan [step 929].
[0071] FIGS. 9A-9C illustrate communication of a data block from
the Hub 110 to a PEA 120. When the PEA 120 transfers a data block
to the Hub 110, similar steps occur except that the Hub 110 first
determines the next data block to receive (with its MAC address 610
and stream number 620) and the transmission of the data buffer 630
contents occurs in the opposite direction. The Hub 110 needs to
arrange in advance for receiving data from PEAs 120 by populating
the MAC address 610 and stream number 620 into data blocks with
empty data buffers 630, because the Hub 110 generates the tokens
for receiving data as well as for transmitting data.
[0072] FIGS. 10A and 10B are high-level diagrams of the states that
the Hub 110 and PEA 120 LLT 440 (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 and
FIG. 10B illustrates states of a PEA-to-Hub transfer.
[0073] During the Hub-to-PEA transfer (FIG. 10A), the Hub 110
cycles through four states: fill, send even parity, fill, and send
odd parity. The fill states indicate when the NI 430 (FIG. 4) may
fill a data snippet. The even and odd send states indicate when the
Hub 110 sends even numbered and odd numbered snippets to the PEA
120. The PEA 120 cycles through two states: want even and want odd.
The two states indicate the PEA's 120 desire for data, with `want
even` indicating that the last snippet successfully received had
odd parity. The PEA 120 communicates its current state to the Hub
110 via its status messages (i.e., the state changes serve as
ACKs). The Hub 110 waits for a state change in the PEA 120 before
it transitions to its next fill state.
[0074] During the PEA-to-Hub transfer (FIG. 10B), the Hub 110
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, the PEA 120 cannot transmit
data until the Hub 110 requests data, which it will only do if it
sees from the PEA's status that the PEA 120 has the next data block
ready.
[0075] The four listen for status states schedule when the Hub 110
asks to receive a status message from the PEA 120. The two `send
ACK and listen for status` states occur after successful receipt of
a data block by the Hub 110, and in these two states the Hub 110
schedules both the sending of Hub status to the PEA 120 and receipt
of the PEA status. The PEA status informs the Hub 110 when the PEA
120 has successfully received the Hub 110 status and has
transitioned to the next `fill` state.
[0076] Once the PEA 120 has prepared its next snippet, it changes
its status to `have even` or `have odd` as appropriate. When the
Hub 110 detects that the PEA 120 has advanced to the fill state or
to `have even/odd,` it stops scheduling the sending of Hub status
(ACK) to the PEA 120. If the Hub 110 detects that the PEA 120 is in
the `fill` state, it transitions to the following `listen for
status` state. If the PEA 120 has already prepared a new snippet
for transmission by the time the Hub 110 learns that its ACK was
understood by the PEA 120, the Hub 110 skips the `listen for
status` state and moves immediately to the next appropriate `read
even/odd` state. In this state, the Hub 110 receives the snippet
from the PEA 120.
[0077] The PEA 120 cycles through four states: fill, have even,
fill, and have odd (i.e., the same four states the Hub 110 cycles
through when sending snippets). The fill states indicate when the
NI 430 (FIG. 4) can fill a data snippet. During the fill states,
the PEA 110 sets its status to `have nothing to send.` The PEA 120
does not transition its status to `have even` or `have odd` until
the next snippet is filled and ready to send to the Hub 110. These
two status states indicate the parity of the snippet that the PEA
120 is ready to send to the Hub 110. When the Hub 110 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 the PEA 120.
Exemplary Attachment Processing
[0078] The Hub 110 communicates with only attached PEAs 120 that
have an assigned MAC address 610. An unattached PEA can attach to
the Hub 110 when the Hub 110 gives it an opportunity to do so.
Periodically, the Hub 110 schedules attachment opportunities for
unattached PEAs that wish to attach to the Hub 110, using a small
set of attach MAC (AMAC) addresses and a small set of streams
dedicated to this purpose.
[0079] After selecting one of the designated AMAC addresses 610 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 attach stream numbers 620, the PEA 120 waits for the Hub
110 to successfully read the attach-interest and then the
attach-request messages. Reading of a valid attach-interest message
by the Hub 110 causes the Hub 110 believe that there is a PEA 120
ready to send the longer (and hence more likely corrupted)
attach-request.
[0080] Once a valid attach-interest is received, the Hub 110
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. The Hub 110 then assigns a MAC address to the PEA
120, sending the address to the PEA 120 using its AMAC address.
[0081] The Hub 110 confirms receipt of the MAC address by
scheduling the reading of a small, possibly forward
error-corrected, attach-confirmation from the PEA 120 at its new
MAC address 610. The Hub 110 follows this by sending a small,
possibly forward error-corrected, confirmation to the PEA 120 at
its MAC address so that the PEA 120 knows it is attached. The PEA
120 returns a final small, possibly forward error-corrected,
confirmation acknowledgement to the Hub 110 so that the Hub 110,
which is in control of all scheduled activity, has full knowledge
of the state of the PEA 120. This MAC address remains assigned to
that PEA 120 for the duration of the time that the PEA 120 is
attached.
[0082] FIGS. 11 and 12 are flowcharts of Hub and PEA attachment
processing, respectively, consistent with the present invention.
When the Hub 110 establishes the network, its logic initializes the
attachment process and, as long as the Hub 110 continues to
function, periodically performs attachment processing. The Hub 110
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 [step 1110](FIG. 11). The Hub
110 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.
[0083] Each attaching PEA 120 selects a new AMAC at random from the
indicated range when it hears the heartbeat. Because the Hub 110
may receive a garbled transmission whenever more than one PEA 120
transmits, the Hub 110 occasionally indicates a large AMAC range
(especially after rebooting) so that at least one of a number of
PEAs 120 may select a unique AMAC 610 and become attached. When no
PEAs 120 have attached for some period of time, however, the Hub
110 may select a small range of AMACs 610 to reduce attachment
overhead, assuming that PEAs 120 will arrive in its vicinity in at
most small groups. The Hub 110 then listens for a valid
attach-interest from an unattached PEA [step 1120]. The
attach-interest is a PEA-to-Hub message having the AMAC address 610
selected by the unattached PEA 120.
[0084] Upon receiving a valid attach interest, the Hub 110
schedules a PEA-to-Hub attach-request token with the PEA's AMAC 610
and reads the PEA's attach-request [step 1130]. Due to the
low-power wireless environment of the PAN 100, 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
the Hub 110 successfully receives the attach-request from the PEA,
it assigns a MAC address to the PEA [step 1140]. In some cases, the
Hub 110 chooses the MAC address from the set of AMAC addresses.
[0085] The Hub 110 sends the new MAC address 610 in an
attach-assignment message to the now-identified PEA 120, still
using the PEA's AMAC address 610 and a stream number 620 reserved
for this purpose. The Hub 110 schedules and listens for an
attach-confirmation response from the PEA 120 using the newly
assigned MAC address 610 [step 1150].
[0086] Upon receiving the confirmation from the PEA 120, the Hub
110 sends its own confirmation, acknowledging that the PEA 120 has
switched to its new MAC, to the PEA 120 and waits for a final
acknowledgment from the PEA 120 [step 1160]. The Hub 110 continues
to send the confirmation until it receives the acknowledgment from
the PEA 120 or until it times out. In each of the steps above, the
Hub 110 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, the
Hub 110 stops sending its attach confirmation, informs its NI 430
(FIG. 4) that the PEA 120 is attached, and begins exchanging both
data and keep-alive messages (described below) with the PEA
120.
[0087] When an unattached PEA 120 enters the network, its LLC 420
(FIG. 4) instructs its LLT 440 to initialize attachment. Unlike the
Hub 110, the PEA 120 waits to be polled. The PEA 120 instructs its
DCL 460 to activate and associate the heartbeat stream 770 (FIG.
7B) with the Hub's MAC address and waits for the heartbeat
broadcast from the Hub 110 [step 1210] (FIG. 12). The PEA 120 then
selects a random AMAC address from the range indicated in the
heartbeat to identify itself to the Hub 110 [step 1220]. The PEA
120 instructs its DCL 460 to send an attach-interest and an
attach-request data block to the Hub 110, and activate and
associate the streams with its AMAC address [step 1230]. The PEA
120 tells its driver to activate and respond to the selected AMAC
address for the attach-assignment stream.
[0088] The unattached PEA 120 then waits for an attach-assignment
with an assigned MAC address from the Hub 110 [step 1240]. Upon
receiving the attach-assignment, the PEA 120 finds its Hub-assigned
MAC address and tells its driver to use this MAC address to send an
attach-confirmation to the Hub 110 to acknowledge receipt of its
new MAC address [step 1250], activate all attached-PEA streams for
its new MAC address, and deactivate the streams associated with its
AMAC address.
[0089] The PEA 120 waits for an attach confirmation from the Hub
110 using the new MAC address [step 1260] and, upon receiving it,
sends a final acknowledgment to the Hub 110 [step 1270]. The PEA
120 then tells its NI 430 that it is attached.
[0090] The PEA 120, if it hears another heartbeat from the Hub 110
before it completes attachment, discards any prior communication
and begins its attachment processing over again with a new
AMAC.
Exemplary Detachment and Reattachment Processing
[0091] The Hub 110 periodically informs all attached PEAs 120 that
they are attached by sending them `keep-alive` messages. The Hub
110 may send the messages at least as often as it transmits
heartbeats. The Hub 110 may send individual small, possibly forward
error-corrected, keep-alive messages to each attached PEA 120 when
few PEAs 120 are attached, or may send larger, possibly forward
error-corrected, keep-alive messages to groups of PEAs 120.
[0092] Whenever the Hub 110 schedules tokens for PEA-to-Hub
communications, it sets a counter to zero. The counter resets to
zero each time the Hub 110 successfully receives a block (either
uncorrupted or reconstructed) from the PEA 120, and increments for
unreadable blocks. If the counter exceeds a predefined threshold,
the Hub 110 automatically detaches the PEA 120 without any
negotiation with the PEA 120. After this happens, the Hub 110 no
longer schedules data or status transfers to or from the PEA 120,
and no longer sends it any keep-alive messages.
[0093] FIG. 13 is a flowchart of PEA detachment and reattachment
processing consistent with the present invention. Each attached PEA
120 listens for Hub heartbeat and keep-alive messages [step 1310].
When the PEA 120 first attaches, and after receiving each
keep-alive message, it resets its heartbeat counter to zero [step
1320]. Each time the PEA 120 hears a heartbeat, it increments the
heartbeat counter [step 1330]. If the heartbeat counter exceeds a
predefined threshold, the PEA 120 automatically assumes that the
Hub 110 has detached it from the network 100 [step 1340]. After
this happens, the PEA 120 attempts to reattach to the Hub 110 [step
1350], using attachment processing similar to that described with
respect to FIGS. 11 and 12.
[0094] If the Hub 110 had not actually detached the PEA 120, then
the attempt to reattach causes the Hub 110 to detach the PEA 120 so
that the attempt to reattach can succeed. When the PEA 120 is out
of range of the Hub 110, it may not hear from the Hub 110 and,
therefore, does not change state or increment its heartbeat
counter. The PEA 120 has no way to determine whether the Hub 110
has detached it or how long the Hub 110 might wait before detaching
it. When the PEA 120 comes back into range of the Hub 110 and hears
the Hub heartbeat (and keep-alive if sent), the PEA 120 then
determines whether it is attached and attempts to reattach if
necessary.
CONCLUSION
[0095] 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.
[0096] 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.
* * * * *