US20070223497A1 - Low-latency multi-hop ad hoc wireless network - Google Patents
Low-latency multi-hop ad hoc wireless network Download PDFInfo
- Publication number
- US20070223497A1 US20070223497A1 US11/651,224 US65122407A US2007223497A1 US 20070223497 A1 US20070223497 A1 US 20070223497A1 US 65122407 A US65122407 A US 65122407A US 2007223497 A1 US2007223497 A1 US 2007223497A1
- Authority
- US
- United States
- Prior art keywords
- nodes
- node
- network
- communication
- radio
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W92/00—Interfaces specially adapted for wireless communication networks
- H04W92/02—Inter-networking arrangements
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
- G01D9/00—Recording measured values
- G01D9/005—Solid-state data loggers
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
- G01S5/18—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations using ultrasonic, sonic, or infrasonic waves
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
- H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
- H04B7/2662—Arrangements for Wireless System Synchronisation
- H04B7/2671—Arrangements for Wireless Time-Division Multiple Access [TDMA] System Synchronisation
- H04B7/2678—Time synchronisation
- H04B7/2687—Inter base stations synchronisation
- H04B7/269—Master/slave synchronisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L7/00—Arrangements for synchronising receiver with transmitter
- H04L7/04—Speed or phase control by synchronisation signals
- H04L7/041—Speed or phase control by synchronisation signals using special codes as synchronising signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W56/00—Synchronisation arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
Definitions
- the disclosed embodiments relate to robust low delay ad hoc wireless networks.
- a basic assumption of ad hoc wireless networks is that there is no pre-existing network infrastructure. This means that the network nodes must establish communication routes among themselves in order to transfer information through the network.
- Algorithms devised for network self-assembly, clustering, and multi-hop routing include those described by K. Sohrabi, J. Gao, V. Ailawadhi, and G. Pottie in, “A Self-Organizing Sensor Network,” Proc. 37 th Allerton Conf. On Comm., Control, and Computing, Monticello Ill., September 1999. These algorithms can for example enable arbitrarily large networks to self-assemble, and permit multi-hop routing over large geographic areas under varying conditions of node mobility.
- star network configurations In the star network configuration one node of a cluster is designated as the master node, and the other nodes in the cluster are slave nodes that communicate only with the master node.
- Examples of typical protocols supporting the star network configuration include the IEEE 802.11 family of protocols including the 802.11a and 802.11b protocol, Hiperlan, and Bluetooth.
- the 802.11b protocol also includes an “ad hoc” mode, in which there is no single master node, but in which a local network of equal peer nodes is formed; each peer node can communicate directly with all other peer nodes.
- the advantages of the star network protocols include relatively simple network formation, ease of management of channel access, and ease of establishing and maintaining synchronism. Moreover, the low cost of such radios and the ubiquitous software support for them over many computing platforms make them attractive for a wide variety of applications.
- the typical protocols supporting the star network configuration also have a number of problems.
- One problem with the star configuration protocols is that they do not easily support efficient multi-hop communication.
- a protocol is described in which particular nodes of a network belong to multiple clusters of the network and, as such, communicate with multiple cluster heads.
- the radios provide communication with multiple cluster heads by time-sharing communications between the cluster heads. The time-share communication significantly reduces the communication throughput of the network.
- MAC media access control
- star network configurations Yet another problem encountered in star network configurations is that it is difficult to maintain a common timing base (synchronism) across cluster boundaries using the star network protocols. This makes it difficult to automatically establish network position or accurately time-stamp data, as may be important in sensor network applications.
- FIG. 1 is a point-to-multipoint wireless network cluster using a base-remote network configuration including multi-radio network nodes, under an embodiment.
- FIG. 2 is a block diagram of a network including two local network clusters with dual-radio network nodes supporting communication among the clusters, under an embodiment.
- FIG. 3 is a block diagram of a network including three local network clusters with dual-radio nodes supporting communication among the clusters, under an embodiment.
- FIG. 4 is a block diagram of a multi-radio sensor node, under an embodiment.
- FIG. 5 is a block diagram of a multi-radio sensor node, under an alternative embodiment.
- FIG. 6 is a block diagram of the software architecture of a multi-radio sensor node incorporating a language-independent user-space driver interface, under an embodiment.
- FIG. 7 is a block diagram of the user space/kernel space (US/KS) interface of a multi-radio node, under an embodiment.
- US/KS user space/kernel space
- FIG. 8 is a flow diagram of a method of forming a sensor network of an embodiment.
- FIG. 9 is a block diagram of a multi-radio node, under another alternative embodiment.
- FIG. 10 is a block diagram of an IEEE 802.11 access network including the multi-radio nodes of an embodiment.
- a multi-radio network node is provided herein that supports a multi-hop wireless network.
- the multi-radio nodes described below solve the long-standing problem that restricts most commercial spread spectrum modem solutions to local cluster/star networks.
- Each multi-radio network node referred to herein as a multi-radio node, includes two or more commercially available communication radios or modems, and each radio supports communications with separate network clusters.
- the network therefore, includes overlapped clusters in which nodes may belong to as many clusters as they have radios. This enables the use of standard commercial radios while permitting low-latency multi-hop networking, robustness in the form of alternate routing and ease of network reconfiguration, and ease of synchronization among clusters to facilitate position location and accurate time-stamping of sensor data.
- the multi-radio concept also enables the efficient use of radios with custom protocols to achieve the robustness and synchronization advantages.
- FIG. 1 is a point-to-multipoint wireless network cluster 100 using a base-remote network configuration including multi-radio network nodes, under an embodiment.
- the cluster includes a base node 110 and four remote nodes 101 - 104 , all of which include two radios A-J. While the nodes of this example include dual radios, alternative embodiments can include any number of radios.
- the base-remote, or master-slave, configuration provides for communication among the radios A-J of the nodes 101 - 110 by fixing the synchronization mechanism dictated by the base node 110 and all associated remotes 101 - 104 .
- the remote nodes 101 - 104 communicate with one another via the base node 110 .
- radios A-J support communications among the remote nodes 101 - 104 and the base node 110 .
- a communication path between remote node 101 and remote node 102 may include radios E, D, and B, or alternatively E, D, C, and B.
- the multi-radio nodes of an embodiment support communication among numerous clusters by enabling each node to operate on two or more star networks concurrently so that packets can be routed quickly between network clusters.
- the node In order for a node to communicate with any node outside of the cluster of which it is a member, the node synchronizes to a separate communication link with the outside node.
- FIG. 2 is a block diagram of a network 200 including two local network clusters 201 and 202 with dual-radio nodes 210 - 222 supporting communication among the clusters, under an embodiment.
- FIG. 3 is a block diagram of a network 300 including three local network clusters 301 - 303 with dual-radio nodes 311 - 313 and 321 - 325 supporting communication among the clusters 301 - 303 , under an embodiment.
- Local cluster 201 includes nodes 210 - 222
- local cluster 202 includes nodes 210 , 212 , 213 , and 222 .
- node 210 is the base node of local cluster 201
- node 222 is the base node of local cluster 2 .
- Base node 210 communicates with all nodes of local cluster 201 , including nodes 211 - 222 .
- Base node 222 communicates with all nodes of local cluster 202 , including nodes 210 , 212 , and 213 .
- the remote nodes 211 - 213 communicate with one another via the base nodes 210 and 222 .
- radios A-J support communications among the nodes of the local clusters 201 and 202 .
- a communication path between remote nodes 211 and 212 may include radios B, C, and G, or alternatively radios A, C, and H.
- a communication path between remote node 211 and base node 222 may include radios A, C, D, and I, or alternatively radios A, C, D, G, H, and J.
- Base nodes 311 , 312 , and 313 are the base nodes for local clusters 301 - 303 , respectively. Communication among the nodes and clusters is as described above with reference to FIGS. 1 and 2 .
- FIG. 4 is a block diagram of a multi-radio node 400 , under an embodiment.
- This multi-radio node includes dual radio modems 402 like, for example, the WINS NG 2.0 network node available from Sensoria Corporation of San Diego, Calif.
- the multi-radio nodes described herein are not limited to two radios, and alternative embodiments of the nodes can include any number of radio modems.
- each of the radio modems 402 operates with Frequency Hopped Spread Spectrum (FHSS) signaling with transmission rates up to 56 kbps on each channel.
- FHSS Frequency Hopped Spread Spectrum
- the hopping is distributed over 75 channels within the 2.4 gigahertz (GHz) to 2.4835 GHz worldwide ISM band at a hopping rate of once per 14.375 milliseconds (ms) transmitting at 100 mW or 10 mW.
- Communication between base and remotes is synchronized within a time division multiple access (TDMA) cycle within each hop.
- TDMA time division multiple access
- the base transmits first a synchronization signal, then any data in its buffer, followed in TDMA time slots by transmissions from each of the remotes synchronized by that base.
- the number of remotes dictates the time slot assigned to each remote and hence the packet size sent with the transmission set up to operate efficiently with up to 8 remotes.
- a larger number of remotes per base can be used.
- communication efficiency drops as the header size occupies increasingly large portions of each packet. While the base and remote channel is TDMA, from the API perspective the radios appear to communicate in full duplex mode as transmitted and received packets at a single modem are interleaved.
- the multi-radio node 400 of an embodiment includes high performance analog sensor sampling 404 , sensor signal processing 412 , wireless network support, a 32-bit application processor 420 and a Portable Operating System Interface (POSIX)-compliant real-time operating system.
- the node platform architecture includes a Real Time Interface Processor (RTIP) 410 and supports high-speed multi-port sampling integrated with both a high-speed digital signal processor (DSP) 412 and direct digital input/output (I/O) 414 .
- DSP digital signal processor
- I/O direct digital input/output
- the RTIP 410 together with the associated DSPs 412 and control processors 416 are the preprocessor of the node 400 .
- the node 400 also includes a 32-bit Application Processor 420 with numerous memory devices including random access memory (RAM), read-only memory (ROM), and flash memory.
- the Application Processor 420 for example, the Motorola Power PC MPC 823 Rev A supplemented by 16 MB RAM and 8 MB flash memory, supports the QNX Neutrino POSIX-compliant, microkernel real time operating system (RTOS).
- RTOS microkernel real time operating system
- Digital I/O 414 and Global Positioning System (GPS) 430 geolocation capability is provided with an attached active antenna.
- the analog sensor interfaces 404 include two sets of interfaces. One set provides sampling rates from 1-25 kHz at 12-bit resolution, and the second set provides sampling from 1.88 to 101.1 Hz at 16-bit resolution, both with selectable gains. This provides support for a wide range of sensors.
- the sensor front-end high-speed input sample rate is accommodated in a power-efficient approach with a dedicated, programmable DSP 412 , for example the Texas Instruments 5402 .
- This DSP 412 is supplied with an integrated development environment.
- the DSP code may be communicated to the node 400 via a developer port or directly via the wireless network.
- the system also provides wireline interfaces with both 10 Mb ethernet 440 and RS-232 serial port access.
- the multi-radio node 400 includes the software application programming interfaces (APIs), as described below.
- Node development may be conducted through the node ethernet port 440 or an RS-232 diagnostic port.
- the node 400 can mount a file structure on a remote machine, and development and file transfer is facilitated by the nodes capability to run telnet, tftp, and other file transfer protocols.
- Modems appearing and disappearing on the wireless channel of an embodiment are passed through the API as connect or disconnect packets generated by each internal modem when they are no longer synchronized with a specific base node or remote node.
- each packet is sent with an automatic repeat request (ARQ) scheme that initiates retransmission of any lost packets at the physical layer up to 16 times based on a 24-bit checksum.
- ARQ automatic repeat request
- the number of retransmissions is configurable, to modify communication as desired.
- the ARQ is only enabled for point-to-point transmissions. While every transmission from a remote node to the associated base node is point-to-point and hence uses the ARQ if configured, transmissions from a base node to a remote node may be point-to-point (if a specific node is addressed) or broadcast in which no retransmission is implemented.
- a one-byte checksum is also provided at the driver layer to provide error checking in the case of broadcast transmissions.
- RSSI Received Signal Strength Indication
- the radio API provides access to support setting of the operational status of each modem (base or remote, transmit power, network, etc.); however, a default operational status is also provided based on a deterministic node layout.
- This initial network configuration facilitates quick use of the multi-hop nature of the network, while enabling overlay of a large variety of self-assembly, reconfiguration and routing protocols.
- the dual modems of each node 311 - 313 and 321 - 325 provide multiple paths among the nodes. Additionally, by transferring a message between each modem driver on a node the message can be passed over many hops like, for example, passing signals from remote node 321 to base node 313 of the network 300 via a path including base node 311 , base node 312 , and remote node 324 .
- This communication path may use radios A, C, D, F, K, L, and O.
- Independent operation of the dual modems reduce the latency in message passing to that required to route information between each modem driver.
- the header of each packet passed up through the radio API enables directed routing as well as provides for packets to be passed along in a broadcast mode.
- each dual-radio node is operating two independent modems, each node also has two radio frequency (RF) addresses.
- RF radio frequency
- everything is referred to the RF address.
- the RF modem API returns the identities of all radios connected to a selected radio it does not specify at the API level to which node a radio is attached. The node thus provides the capability to pass messages between individual radios to ascertain which nodes they are associated with in order to build node-driven routing tables.
- Networks including multi-radio nodes have a higher capacity for multi-hop transmissions through the network because the multi-radio nodes have the advantage of being able to conduct simultaneous transmissions through multiple channels.
- the multiple radio architecture provides a further advantage of increased robustness to degradations such as jamming because the radios may be tuned to independent channels.
- This architecture also provides a greater number of connection combinations or alternative communication paths between two nodes. Two radios per node is the minimum necessary for low-latency multi-hop communications where conventional MACs are used, but a larger number provides higher inter-cluster capacity.
- FIG. 5 is a block diagram of a multi-radio node 500 , under an alternative embodiment.
- This node 500 includes a Hitachi SH4 core board 502 that includes a preprocessor and processor.
- the core board 502 is coupled among an SH4 peripheral component interconnect (PCI) bus 512 and universal asynchronous receiver/transmitter (UART) serial ports 514 .
- PCI peripheral component interconnect
- UART universal asynchronous receiver/transmitter
- two 2.4 GHz FHSS transceivers 522 are coupled to the UART serial ports 514 along with a GPS receiver 524 , orientation sensor 526 , and SAF sensor 528 .
- Each of two coder/decoders (CODECs) 530 - 532 couple to the PCI bus 512 via a PCI AC97 interface 534 .
- Each coder/decoder (CODEC) 530 - 532 couples to two microphones 540 - 542 and two speakers 550 - 552 , with the combinations being used for acoustic ranging, as described in detail below.
- An Ethernet card 560 couples to the PCI bus 512 for use in test and monitoring.
- This node 500 includes a platform hardware configuration and software architecture that provides for shared resource access management.
- a Framework for User-Space Devices (FUSD) module or redirection module resides in kernel space and receives requests for access to resources from applications in user space.
- the FUSD module routes signals representative of the received requests to a device driver interface in user space.
- Components of the device driver interface include resource management modules and device drivers that correspond to available resources.
- the resource management modules generate queries to the device drivers regarding availability of the requested resources.
- components of the device driver interface Upon receipt of resource status information from the device drivers, components of the device driver interface generate schedules for granting access to the requested resources. Further, the device driver interface components control access to the resources in accordance with the generated schedules including issuing responses to the requesting applications and the device drivers of the requested resources.
- the platform software architecture of the sensor nodes described herein uses the FUSD to program functions as applications together with a special driver or driver interface that acts as a proxy for the application at the device level, as described below and in the Related Applications.
- the FUSD provides access to all drivers and most system resources, and makes use of the security and communications features already built into or onto a standard operating system such as Linux.
- one or more software-exchange mechanisms can be layered on top of the operating system as the mechanisms become available, without the need for any modifications or extensions to the mechanisms in order to enable access to the devices.
- the platform software architecture permits secure distribution of applications and key management software across multiple platforms, enabling convenient upgrades of both hardware and software, management of network access by communications and computer peripherals, and cost-accounted and secure interactions among local networks.
- the software architecture supports personal and handheld computers and their associate network of peripherals, industrial or home automation, security networks, and vehicular systems, for example.
- the FUSD causes the open interface of the sensor node software architecture of an embodiment to appear to the application developer as if increased functionality is provided at the level of the accessed device drivers. This enables access from applications via the standard POSIX virtual file system (VFS). While actually adding the needed functionality within the system kernel (device driver level), the FUSD architecture provides access to the system drivers and resources. In this manner, one or more software-exchange mechanisms can be layered on top of the operating system without the need for any modifications or extensions to these mechanisms to enable access to the devices.
- VFS virtual file system
- the FUSD architecture including a kernel module and a cooperating user-space library, is a Linux framework for proxying device file callbacks into user-space, allowing device files to be implemented by daemons instead of kernel code.
- FUSD devices can look and act just like any other file under /dev implemented by kernel callbacks.
- a user-space device driver can do many of the things that kernel drivers can not, such as perform a long-running computation, block while waiting for an event, or read files from the file system. Unlike kernel drivers, a user-space device driver can use other device drivers—that is, access the network, talk to a serial port, get interactive input from the user, pop-up graphical user interface (GUI) windows, or read from disks, for example. Further, user-space drivers implemented using FUSD can be much easier to debug. Also, it is impossible for user-space drivers to crash the host platform, and they can be killed and restarted without rebooting even if they become corrupted. User-space drivers can also be swapped out, whereas kernel drivers lock physical memory.
- the FUSD drivers are conceptually similar to kernel drivers in that they include a set of callback functions called in response to system calls made on file descriptors by user programs.
- the FUSDs C library provides a device registration function, similar to the kernel's devfs_register_chrdev( ) function, to create new devices.
- the fusd_register( ) function accepts the device name and a structure full of pointers. Those pointers are callback functions which are called in response to certain user system calls, for example, when a process tries to open, close, read from, or write to the device file.
- the callback functions should conform to the standard definitions of POSIX system call behavior. In many ways, the user-space FUSD callback functions are identical to their kernel counterparts.
- the proxying of kernel system calls that makes possible this kind of program is implemented by FUSD, using a combination of a kernel module and cooperating user-space library.
- the kernel module implements a character device, /dev/fusd, which is used as a control channel between the kernel module and the user-space library.
- the fusd_register( ) function uses this channel to send a message to the FUSD kernel module, telling the name of the device the user wants to register.
- the kernel module registers that device with the kernel proper using devfs.
- the devfs and the kernel do not know anything unusual is happening; it appears from their point of view that the registered devices are simply being implemented by the FUSD module.
- the FUSD kernel module callback blocks the calling process, marshals the arguments of the callback into a message and sends it to user-space.
- the FUSD user-space library unmarshals it and calls whatever user-space callback the FUSD driver passed to the fusd_register( ) function.
- the process happens in reverse, wherein the return value and its side-effects are marshaled by the library and sent to the kernel.
- the FUSD kernel module unmarshals this message, matches it up with a corresponding outstanding request, and completes the system call.
- the calling process is completely unaware of this trickery; it simply enters the kernel once, blocks, unblocks, and returns from the system call, just as it would for any other blocking call.
- an application in user space reads from a device driver, but now the VFS calls the FUSD module's read callback.
- the FUSD module or redirection module, resides in kernel space and serves mainly to redirect calls to drivers residing in user space, which may for example be written in C, Java, or other standard programming languages. Further, because the driver resides in user space it has access to all the user-space resources.
- the FUSD module calls the device driver callback, and the response propagates back to the original calling application.
- the semantics of the return variables under the FUSD architecture are exactly the same as if the device driver were in the kernel space. However, now it is possible to include a much broader set of functions in the driver, which can access user-space resources as well as make calls to other drivers within the kernel space.
- FIG. 6 is a block diagram of the software architecture 600 of a node incorporating a language-independent user-space driver interface, also referred to herein as a driver interface, under an embodiment.
- the multi-radio nodes 400 ( FIG. 4 ) and 500 ( FIG. 5 ) each host this architecture 600 .
- Access to a hardware subsystem such as the radio hardware may be provided in one embodiment via a kernel-space serial port driver 610 - 612 on each node.
- Access to this serial port driver 610 - 612 is then provided in user space via FUSD so that at the lowest software layer, the RF modem driver 632 interfaces to each specific radio, and is dependent on the radio used.
- This driver 632 then presents a standard interface so that each higher layer module can operate over alternate radios having a driver in place, allowing only user space software changes to the specific radio driver 632 to use a separate radio over this serial connection.
- Interfacing above the RF modem driver 610 - 612 within the user space 602 of the communication network are stacks 620 - 622 , each of which include three modules 630 - 634 .
- the three modules include, but are not limited to, a heartbeat module 630 or link-monitoring module, an RF module 632 , and a stream/fragmentation module 634 .
- FIG. 7 is a block diagram of the user space/kernel space (US/KS) interface 700 , under an embodiment.
- the multi-radio nodes 400 ( FIG. 4 ) and 500 ( FIG. 5 ) each host this interface 600 .
- Each of the heartbeat module 630 , the RF module 632 , and the stream/fragmentation module 634 include two components, an API 630 A, 632 A, 634 A and a computational component 630 B, 632 B, 634 B, coupled via a FUSD module 702 .
- the API component of each module 630 A, 632 A, 634 A resides in the associated stack 620 and 622 in user space 602 .
- Each API component 630 A, 632 A, 634 A couples to the corresponding computational component 630 B, 632 B, 634 B that also resides in user space 602 via the FUSD module 702 , thereby providing a language independent interface supporting standard POSIX calls just as a kernel-space device file.
- the US/KS interface 700 is expanded by the FUSD module 702 to provide device file access within user space to the serial driver and radio hardware as well as the API components 630 A, 632 A, 634 A and computational components 630 B, 632 B, 634 B of the heartbeat module 630 , RF module 632 , and stream/fragmentation module 634 .
- the components 630 - 634 of each stack couple to a number of other user-space components including, but not limited to, a cluster module 660 or network discovery and self-assembly module, a synchronization module 650 or sync module, a routing module 640 , and an acoustic ranging (AR) module 670 .
- the heartbeat module 630 of each stack couples to the cluster module 660 , the sync module 650 , and the AR module 670 .
- the RF module 632 of each stack couples to the cluster module 660 and the sync module 650 .
- the stream/fragmentation module 634 of each stack couples to the sync module 650 and the routing module 640 .
- the sync module 650 and routing module 640 also couple to the AR module 670 .
- FIG. 8 is a flow diagram of a method of forming a sensor network under and embodiment, as described below.
- the RF modem driver 610 and RF module 632 provide capabilities for multiple upper layer software modules 640 - 670 to send data over the node radios (via user space access through a FUSD device file) and for different systems to configure the radios through the standard API provided by the radio-specific RF driver 632 .
- Radio-specific protocols are built into the RF modem driver 632 in order to provide a radio-independent API 700 to the upper layer software modules 640 - 670 of the node, with general configuration commands abstracted from the radio physical layer connection properties.
- the serial port driver 610 and RF driver 632 are flexible in allowing independent communication to as many radios as are on the node by running multiple versions of the driver for each device file (e.g., a serial port) connected to a modem.
- the RF module API 632 A provides a language-independent API for higher layer software to use supporting standard POSIX-compliant system calls.
- the RF module API 632 A also provides a useful debugging interface through command line-queriable device files reporting radio specific status information.
- the node platform architecture of the embodiments described herein is consistent with the FUSD architecture described in the Related Applications in that multiple users (or multiple software modules) can access, monitor, and write to each software system, through a protected language independent device file. This allows for easy evaluation of module status, or radio status in the case of the radio driver.
- the software operating at the highest layer of the RF modem driver 632 also parses large packets to utilize the maximum amount of data put into each packet as limited by the radio physical layer. This allows higher layer applications to send data as needed without being dependent on characteristics of individual radios.
- the upper layer of the RF modem driver tracks the packet order and monitors the transfer of all message packets, for example the stream/fragmentation module 634 .
- the cluster module 660 operates through the RF module 632 to configure the radios and set up the communication network autonomously.
- the cluster module 660 sets parameters of each RF modem driver 632 to form each local network cluster in order to ensure communication is possible across the network.
- the network nodes may for example operate in a TDMA cycle controlled by a base node, communicating to a number of remotes units.
- the network nodes of various alternative embodiments also support other communication protocols, including but not limited to, frequency division multiple access (FDMA), code division multiple access (CDMA), and orthogonal frequency division multiplexing (OFDM).
- FDMA frequency division multiple access
- CDMA code division multiple access
- OFDM orthogonal frequency division multiplexing
- the cluster module 660 autonomously determines which modem 610 - 612 should act as the cluster synchronizer, based on the modems with which the cluster module 660 can directly communicate. In so doing, the cluster module 660 sets the role of each modem 610 - 612 of a node 400 / 500 by first assigning each modem of a node as a passive listener within each cluster (to determine if another node is synchronizing the network). Then, based on a schedule of which modems can be heard by the listening modems, the cluster module 660 either (1) offers to synchronize each modem with any other modem that the listening modem can hear, or (2) allows the listening modem to be synchronized by a node that the listening modem finds.
- the clustering algorithm of the cluster module 660 listens for a random period of time for other radios before attempting synchronization. The cluster algorithm also cycles between listening and attempting synchronization until each cluster stabilizes. Regarding synchronization, the cluster algorithm uses a minimum of other available nodes to synchronize (minimum number or remotes synchronized by each base with the current radios).
- the heartbeat module 630 actively transmits a heartbeat signal over each connection of the cluster.
- the heartbeat signal transmits periodically, which in an embodiment is every N seconds (where N is easily configurable), plus or minus 30%, where the heartbeat time is randomized between each pulse.
- alternative embodiments may transmit heartbeat signals with a different periodicity and random dither.
- the heartbeat signals or packets are transmitted both ways through the cluster to ensure two-way communication.
- each heartbeat signal Embedded within each heartbeat signal is a bit map that corresponds to the processes operating on each node of a cluster.
- the bit map allows nodes receiving the bit map to determine the operational status of neighboring nodes in addition to the operational status of the RF link.
- the heartbeat module 630 uses the same interface via the RF driver module 632 as any other software module of a node to communicate with the radio 610 (i.e., uses the device driver provided by the RF driver 632 A), so that the heartbeat module 630 is continuously testing the communication channel exactly as seen on the node. This supports troubleshooting where, for example, the modem communicates fine over the air, but the radio firmware or even the radio driver is experiencing problems buffering data prior to sending it resulting in lost data.
- the RF synchronization module 650 Leveraging the heartbeat module 630 is the RF synchronization module 650 , or sync module, which provides microsecond level accuracy between nodes.
- the sync module 650 is built independently of the heartbeat module 630 to easily allow the use of alternate broadcast messages for synchronization, and the integration of alternate synchronization modules.
- the synchronization operates above the heartbeat software but leverages the fact that each heartbeat packet is broadcast from the cluster module 660 and hence received by all the synchronized radios of a cluster at the same time, as described by J. Elson, L. Girod, and D. Estrin in “Fine-Grained Network Time Synchronization using Reference Broadcasts”, submitted to SIGCOMM 2002. Thus each modem that receives the broadcast packet has a consistent time reference with all the other nodes synchronized in the same cluster.
- the base or synchronizing radio does not have a reference time point based on its own broadcast “heartbeat”, but since each node participates in two clusters, it has a reference time from the other cluster in which it participates. Since “heartbeat” packets are sent periodically, each node also conditions for drift in its own clock (based on temperature variations for example) with respect to its neighbors to ensure that once synchronized the nodes stay synchronized for as long as possible, even if no synchronization packets are received for a long period. In addition, with every node participating in two clusters, substantial cluster overlap occurs enabling multiple clusters to be synchronized.
- the nodes 400 / 500 of an embodiment include any number of routing modules 640 .
- the routing modules 640 operate over the clusters assigned by the cluster module 660 and over the links tested by the heartbeat module 630 .
- the nodes 400 / 500 of an embodiment use the AR module 670 to determine their relative locations to other local nodes with which they communicate.
- the AR module 670 determines the range and angle between local clusters of nodes and, from this range and angle data, builds a local coordinate system for these nodes using a multilateration module (not shown).
- Components of the AR module 670 including a merging algorithm that merges multiple local coordinate systems to create a field table.
- the field table includes the coordinates of many nodes. As an example, the field table may include coordinates for approximately fifty nodes, but is not so limited.
- the AR module 670 leverages the inter-cluster synchronization provided by the heartbeat module 630 through its associated FUSD device driver.
- the heartbeat provides synchronization over RF, which can be abstracted beyond the local RF cluster.
- each node can determine the range to other nodes based on a one-way acoustic time of flight.
- Each node that includes a modem operating as an RF base synchronizes all acoustic signaling within a local area. This coordination is abstracted from the topology dictated by the network cluster. Determination of the ranges to a sufficient number of neighbors is considerably enhanced by having clusters with a large degree of overlap, as is made convenient with nodes that employ two or more independent radios or modems.
- the AR modules 670 of an embodiment transmit a different coded acoustic chaotic sequence out of each of four speakers 550 - 552 of the host node 500 .
- the transmission of these acoustic chaotic sequences is scheduled by the base node of each network cluster. As such, each node within a network cluster attempts to get the range and angle to every other node in the cluster.
- the transmitted acoustic chaotic signals are received by the microphones 540 - 542 of each of the nodes that expect a signal, and correlated for each of the expected chaotic sequences.
- the sampled data on each of the four microphones 540 - 542 is also correlated with an alternate chaotic sequence to determine a representative noise level. Then, based on the correlated signal level, a signal-to-noise ratio (SNR) is assigned to each of the sixteen combinations of microphone/speaker pairs.
- SNR signal-to-noise ratio
- the assigned SNRs are used to determine whether or not to use the sampled data, as follows. To begin, signals from the various transmitting speakers are compared, and the speaker associated with the signal having the highest SNR values is chosen as the signal source for use in all processing (giving an indication that this speaker is pointed towards the receiving node). Signals from the four microphones sampling the signal received from the source speaker are then compared (if they have a large enough SNR) in order to provide both a range between nodes and an angle between nodes. The range between nodes is provided in the form of a weighted average, and the angle between nodes is determined from the weighted time of flight differences between each microphone pair.
- the base node of each network cluster collects the range and angle data calculated between each pair of nodes between which it coordinated ranging.
- the base node generates a range table using this range and angle data.
- the range table is then used as input to a local multilateration module to determine a relative coordinate system for the list of nodes in the range table.
- An algorithm of the multilateration module should use a range and angle combination between these groups of nodes that is adequate to provide an initial guess for the location of nodes, from which an iterative least squares approach is used to generate a multilateration table.
- the multilateration data from each base node is intelligently passed to approximately fifty of the nearest neighbor nodes.
- the AR module transmits the multilateration data using the routing module.
- each node Upon receipt of the multilateration data, each node contains a collection of multilateration tables that are merged to provide a field table. Each node independently executes the merging in order to provide a field table having the local node as the table origin. Further, in order to minimize the error nearest each node, the merging is accomplished by starting with the largest multilateration table that contains the local node and then merging in each of the other multilateration tables based on the largest common node set. In this manner the nodes propagate field tables including very accurate node position information throughout their associate network.
- the AR modules 670 update the field table by transmitting updates to the multilateration tables.
- the multilateration update tables are then merged into the field tables of each node.
- These updates include a number of status flags to signify the current state of each node, for example if it has been moved (tampered) but is still participating in the network or if it has disappeared from the network. In this manner the disappearance or appearance of a node from the network is passed via updates to the multilateration table within the network.
- These multilateration table updates also provide a mechanism by which a new node integrates into the network, and provide a soft state approach to system operation by providing information redundantly to each node.
- Coherent data uses timing that is accurate to within a small fraction of one wave oscillation. Achieving such a level of synchronization across RF cluster boundaries would be difficult in the absence of overlapped cluster membership of nodes.
- the overlapped cluster architecture provides not only low-latency connectivity, but also provides for improved robustness, capacity, and power efficiency compared to typical networking schemes.
- the cluster heads may be the only nodes with multiple radios and thus the only nodes capable of inter-cluster communication. This limits the number of routes and, due to propagation losses that are typically on the order of the fourth power of distance for ground-to-ground links, leads to increased power consumption.
- FIG. 9 is a block diagram of a multi-radio node 900 , under another alternative embodiment.
- This node 900 includes a processor motherboard 902 and a network interface 904 .
- the motherboard 902 of an embodiment accepts at least two plug-in Personal Computer Memory Card International Association (PCMCIA) cards 906 and an Ethernet card 908 .
- PCMCIA Personal Computer Memory Card International Association
- the motherboard 902 supports operation as a multi-radio node when configured with an 802.11b radio port in the Ethernet port 908 and two 802.11a radio ports in the PCMCIA ports 906 .
- the processor motherboard 902 includes the power supply, PCMCIA slots and interfaces, SH7751, PCI, Serial SCI and SCIF, JTAG, Memory Bus, RTC, bridge field programmable gate array (FPGA), random access memory (RAM) 16-64M, flash memory 8-32M, control complex programmable logic device (CPLD), PCI to AC-97 Bridge, CODEC, and quad universal asynchronous receiver transmitter (UART).
- the network interface includes a peripheral bus, GM J1850 (audio) bus (vehicle applications), GPS interface, and general purpose input/output (GPIO), but alternative embodiments support numerous different interface options.
- the test expansion board is shown with an Ethernet board, but also supports an IEEE 802.11 radio port. Plug-in PCMCIA cards include IEEE 802.11 radio ports, and a spare, which might be used for Bluetooth.
- the SH7751 is the host for the node software architecture described above.
- the use of multiple additional processors enables many critical real-time management functions to be offloaded from the main processor, allowing determinism without requiring a special operating system.
- RTIP real-time interface processor
- the processor of an embodiment is a Hitachi HD6417751F167, but is not so limited.
- the SH7751 can be programmed via a 14-pin JTAG header on the core board. This header is accessible when the board stack is removed from the nodes enclosure.
- the SH7751 has two native serial ports. The SCI port is used to communicate with the PCI, which controls the power state of the system. This port is used in a SPI mode where the SH7751 acts as a slave.
- the SCIF port on the SH7751 exits the gateway via the main connector at RS232 levels with full flow control.
- the RAM on the board is scalable from 16 megabytes (M) to 64M in 16M increments. This is implemented by chip selection and the choice of the number of chips populated. The chips are populated in pairs. Using two chips that are 16 bits wide allows a 32-bit write which is twice as fast as two 16-bit writes.
- the flash memory on the board is scalable from 8M to 32M in 8M increments. This is implemented by chip selection and the choice of the number of chips populated. The chips are populated in pairs. Using two chips that are 16 bits wide allows a 32-bit write which is twice as fast as two 16-bit writes.
- the FPGA is responsible for aiding the SH7751 in controlling several devices on the core board.
- the address bus, data bus, chip selects, and IRQs of the SH7751 are routed to the FPGA so that they may be decoded before interfacing with other devices.
- the FPGA interfaces with the quad UART, the network interface 904 , and the CODEC and generates GPIOs, which are used for debugging.
- the FPGA can be programmed either through the SH7751 or a 5-pin JTAG header on the core board.
- the node architecture of an embodiment further supports nodes including radios supporting different protocols.
- the use of different protocols on the same platform is found in hierarchical networks, for example, where base nodes have improved power supplies, antenna elevation, or simply more powerful radios.
- the separation of functions among the local networking and the longer range multi-hop network can simplify operations in hierarchical networks.
- FIG. 10 is a block diagram of an IEEE 802.11 access network 1000 application including the multi-radio nodes of an embodiment.
- the installation of an 802.11 access network 1000 in a hospital, airport, mall, or other structures in which stringing new communications cable to the access points is costly and difficult in the absence of the multi-radio nodes.
- use of portable wireless devices alone to actually perform the multi-hop routing is complicated, unreliable (due to their motion), and would demand operating their protocols in an irregular mode.
- the multi-radio nodes of an embodiment facilitate provision of a wireless access network as described below.
- the access network 1000 presents a network access point to the end-user that appears to be the same as that of a wired network.
- the nodes 1011 - 1014 that support this access network 1000 under an alternative embodiment include at least three radios, and more radios can be included to support alternative network configurations.
- the three radios include two 802.11a radios that establish a high-speed low-latency multi-hop backbone.
- the third radio of the node is an 802.11b radio that provides local access for portable electronic devices 1020 - 1034 like laptop computers and other portable devices equipped with wireless capability.
- the network access nodes 1011 - 1014 support the provision of multiple paths 1040 between any given access point 1011 - 1014 and the gateway 1004 to the wired network 1002 , thereby providing reliable network access under failures of any given element.
- the overlapping cluster algorithms described above can then be applied to the formation of the multi-hop access radio wireless backbone.
- Alternative embodiments of the access network 1000 may include nodes 1011 - 1014 with three 802.11a radios, nodes 1011 - 1014 with three 802.11b radios, and/or nodes 1011 - 1014 with various other combinations of 802.111a/802.11b radios. Additionally, alternative embodiments of the access network 1000 may include nodes 1011 - 1014 that support various other communication protocols or wireless local area network (LAN) standards.
- LAN local area network
- the multi-radio node hardware and software described herein and in the Related Applications provides a convenient means of implementing these access networks.
- the capability for local control over resources such as radio ports supports provision of differentiated quality of service and security without the need for large back-end servers in each installation.
- the local control over resources further enables remote upgrade of this software.
- the enterprise-level software provides the capabilities for multiple Internet service providers to be supported, giving economies of scale in the user population.
- the multi-radio nodes of an embodiment are also useful in combination with multi-hop systems known in the art. For example, consider deployment of sensor networks in a security application wherein certain critical locations require coverage by a field of sensors, with a large gap between the critical locations and a command post that receives the sensor information. In this case, there is a need for longer range radios to overcome the gaps in the network. Use of the multi-radio nodes across the gap provides multi-hop coverage over these long-range links while requiring less power than when attempting to bridge the link in one hop. Use of multiple radios for each long-range relay also provides low latency across the link. The overlapping cluster algorithms described above may be used at each level of this network hierarchy.
- the multi-radio nodes described above are not limited to use in local networks of a star architecture, as they may be used with numerous other network protocols to establish both network clusters and/or flat networks. Even with other network protocols, use of the multi-radio nodes enables higher communication throughput (in not having to time share as much on connections) and simplifies synchronization and channel assignment.
- PLDs programmable logic devices
- FPGAs field programmable gate arrays
- PAL programmable array logic
- ASICs application specific integrated circuits
- microcontrollers with memory such as electronically erasable programmable read only memory (EEPROM)
- EEPROM electronically erasable programmable read only memory
- embedded microprocessors firmware, software, etc.
- aspects of the embodiments herein may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types.
- the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.
- MOSFET metal-oxide semiconductor field-effect transistor
- CMOS complementary metal-oxide semiconductor
- ECL emitter-coupled logic
- polymer technologies e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures
- mixed analog and digital etc.
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- This application claims the benefit of U.S. Patent Application Nos. 60/302,795 filed Jul. 3, 2001 and 60/343,312 filed Dec. 21, 2001, both of which are currently pending and incorporated herein by reference in their entirety. This application is related to U.S. patent application Ser. Nos. 09/684,706, 09/684,565, 09/685,020, 09/685,019, 09/684,387, 09/684,490, 09/684,742, 09/680,550, 09/685,018, 09/684,388, 09/684,162, and 09/680,608, all filed Oct. 4, 2000, and 60/311,183 filed Aug. 9, 2001, 60/335,120 filed Oct. 24, 2001, 60/345,198 filed Jan. 2, 2002, 60/366,877 filed Mar. 22, 2002, and the application titled “Open Platform Architecture For Shared Resource Access Management” filed Jun. 28, 2002 (Attorney Docket Number SENS.P034; Application Number to be assigned), all of which are currently pending and incorporated herein by reference in their entirety.
- This invention was made with United States government support under Contract Number DAAE30-00-C-1055 awarded by the Defense Advanced Research Projects Agency (DARPA) Advanced Technology Office (ATO) and Contract Number F30602-99-C-0171 awarded by the DARPA Information Exploitation Office (IXO). The United States government may have certain rights in this invention.
- The disclosed embodiments relate to robust low delay ad hoc wireless networks.
- A basic assumption of ad hoc wireless networks is that there is no pre-existing network infrastructure. This means that the network nodes must establish communication routes among themselves in order to transfer information through the network. Algorithms devised for network self-assembly, clustering, and multi-hop routing include those described by K. Sohrabi, J. Gao, V. Ailawadhi, and G. Pottie in, “A Self-Organizing Sensor Network,” Proc. 37th Allerton Conf. On Comm., Control, and Computing, Monticello Ill., September 1999. These algorithms can for example enable arbitrarily large networks to self-assemble, and permit multi-hop routing over large geographic areas under varying conditions of node mobility.
- However, commercially available communication radios that enable wireless local area networks typically support only star network configurations. In the star network configuration one node of a cluster is designated as the master node, and the other nodes in the cluster are slave nodes that communicate only with the master node. Examples of typical protocols supporting the star network configuration include the IEEE 802.11 family of protocols including the 802.11a and 802.11b protocol, Hiperlan, and Bluetooth. The 802.11b protocol also includes an “ad hoc” mode, in which there is no single master node, but in which a local network of equal peer nodes is formed; each peer node can communicate directly with all other peer nodes. The advantages of the star network protocols include relatively simple network formation, ease of management of channel access, and ease of establishing and maintaining synchronism. Moreover, the low cost of such radios and the ubiquitous software support for them over many computing platforms make them attractive for a wide variety of applications.
- The typical protocols supporting the star network configuration also have a number of problems. One problem with the star configuration protocols is that they do not easily support efficient multi-hop communication. For example, as described in the Related Applications, a protocol is described in which particular nodes of a network belong to multiple clusters of the network and, as such, communicate with multiple cluster heads. Unfortunately, when using a commercial radio that implements a media access control (MAC) protocol which assumes a star topology, the radios provide communication with multiple cluster heads by time-sharing communications between the cluster heads. The time-share communication significantly reduces the communication throughput of the network.
- Furthermore, and even more detrimental, is that each time a node radio switches communication between different cluster heads, the radio encounters a start-up time delay as if it is being newly joined to the network. Consequently, communication delays are very large across multi-hop networks that rely upon MACs supporting a star configuration. This situation is further aggravated when using the 802.11b ad hoc mode because radios that are too far away for reliable communication with network nodes may still interfere with other links of the network, and there is no mechanism within the protocol for resolving these types of conflicts. Thus, formation of a reliable network is problematic.
- Yet another problem encountered in star network configurations is that it is difficult to maintain a common timing base (synchronism) across cluster boundaries using the star network protocols. This makes it difficult to automatically establish network position or accurately time-stamp data, as may be important in sensor network applications.
-
FIG. 1 is a point-to-multipoint wireless network cluster using a base-remote network configuration including multi-radio network nodes, under an embodiment. -
FIG. 2 is a block diagram of a network including two local network clusters with dual-radio network nodes supporting communication among the clusters, under an embodiment. -
FIG. 3 is a block diagram of a network including three local network clusters with dual-radio nodes supporting communication among the clusters, under an embodiment. -
FIG. 4 is a block diagram of a multi-radio sensor node, under an embodiment. -
FIG. 5 is a block diagram of a multi-radio sensor node, under an alternative embodiment. -
FIG. 6 is a block diagram of the software architecture of a multi-radio sensor node incorporating a language-independent user-space driver interface, under an embodiment. -
FIG. 7 is a block diagram of the user space/kernel space (US/KS) interface of a multi-radio node, under an embodiment. -
FIG. 8 is a flow diagram of a method of forming a sensor network of an embodiment. -
FIG. 9 is a block diagram of a multi-radio node, under another alternative embodiment. -
FIG. 10 is a block diagram of an IEEE 802.11 access network including the multi-radio nodes of an embodiment. - In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 400 is first introduced and discussed with respect to
FIG. 4 ). - The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the claimed invention.
- A multi-radio network node is provided herein that supports a multi-hop wireless network. The multi-radio nodes described below solve the long-standing problem that restricts most commercial spread spectrum modem solutions to local cluster/star networks. Each multi-radio network node, referred to herein as a multi-radio node, includes two or more commercially available communication radios or modems, and each radio supports communications with separate network clusters. The network, therefore, includes overlapped clusters in which nodes may belong to as many clusters as they have radios. This enables the use of standard commercial radios while permitting low-latency multi-hop networking, robustness in the form of alternate routing and ease of network reconfiguration, and ease of synchronization among clusters to facilitate position location and accurate time-stamping of sensor data. The multi-radio concept also enables the efficient use of radios with custom protocols to achieve the robustness and synchronization advantages.
-
FIG. 1 is a point-to-multipointwireless network cluster 100 using a base-remote network configuration including multi-radio network nodes, under an embodiment. The cluster includes abase node 110 and four remote nodes 101-104, all of which include two radios A-J. While the nodes of this example include dual radios, alternative embodiments can include any number of radios. The base-remote, or master-slave, configuration provides for communication among the radios A-J of the nodes 101-110 by fixing the synchronization mechanism dictated by thebase node 110 and all associated remotes 101-104. The remote nodes 101-104 communicate with one another via thebase node 110. Any combination of radios A-J support communications among the remote nodes 101-104 and thebase node 110. For example, a communication path betweenremote node 101 andremote node 102 may include radios E, D, and B, or alternatively E, D, C, and B. - The multi-radio nodes of an embodiment support communication among numerous clusters by enabling each node to operate on two or more star networks concurrently so that packets can be routed quickly between network clusters. In order for a node to communicate with any node outside of the cluster of which it is a member, the node synchronizes to a separate communication link with the outside node.
FIG. 2 is a block diagram of anetwork 200 including twolocal network clusters FIG. 3 is a block diagram of anetwork 300 including three local network clusters 301-303 with dual-radio nodes 311-313 and 321-325 supporting communication among the clusters 301-303, under an embodiment. - With reference to
FIG. 2 , twolocal clusters Local cluster 201 includes nodes 210-222, whilelocal cluster 202 includesnodes node 210 is the base node oflocal cluster 201, andnode 222 is the base node oflocal cluster 2.Base node 210 communicates with all nodes oflocal cluster 201, including nodes 211-222.Base node 222 communicates with all nodes oflocal cluster 202, includingnodes base nodes local clusters remote nodes remote node 211 andbase node 222 may include radios A, C, D, and I, or alternatively radios A, C, D, G, H, and J. - With reference to
FIG. 3 , three local clusters 301-303 form the network.Base nodes FIGS. 1 and 2 . - In order to provide low latency packet transmission the multi-radio node of an embodiment provides multi-cluster access using dedicated hardware rather than by expanding the complexity of each individual modem. This provides a robust, scalable extension of the single network cluster architecture (a cluster corresponding to a synchronized channel between nodes) with the flexibility to support a large variety of networking algorithms.
FIG. 4 is a block diagram of a multi-radio node 400, under an embodiment. This multi-radio node includesdual radio modems 402 like, for example, the WINS NG 2.0 network node available from Sensoria Corporation of San Diego, Calif. However, the multi-radio nodes described herein are not limited to two radios, and alternative embodiments of the nodes can include any number of radio modems. - Referring to
FIG. 4 , each of theradio modems 402 operates with Frequency Hopped Spread Spectrum (FHSS) signaling with transmission rates up to 56 kbps on each channel. The hopping is distributed over 75 channels within the 2.4 gigahertz (GHz) to 2.4835 GHz worldwide ISM band at a hopping rate of once per 14.375 milliseconds (ms) transmitting at 100 mW or 10 mW. Communication between base and remotes is synchronized within a time division multiple access (TDMA) cycle within each hop. At the beginning of a hop the base transmits first a synchronization signal, then any data in its buffer, followed in TDMA time slots by transmissions from each of the remotes synchronized by that base. The number of remotes dictates the time slot assigned to each remote and hence the packet size sent with the transmission set up to operate efficiently with up to 8 remotes. A larger number of remotes per base can be used. However, communication efficiency drops as the header size occupies increasingly large portions of each packet. While the base and remote channel is TDMA, from the API perspective the radios appear to communicate in full duplex mode as transmitted and received packets at a single modem are interleaved. - The multi-radio node 400 of an embodiment includes high performance
analog sensor sampling 404,sensor signal processing 412, wireless network support, a 32-bit application processor 420 and a Portable Operating System Interface (POSIX)-compliant real-time operating system. The node platform architecture includes a Real Time Interface Processor (RTIP) 410 and supports high-speed multi-port sampling integrated with both a high-speed digital signal processor (DSP) 412 and direct digital input/output (I/O) 414. TheRTIP 410 together with the associatedDSPs 412 andcontrol processors 416 are the preprocessor of the node 400. - The node 400 also includes a 32-
bit Application Processor 420 with numerous memory devices including random access memory (RAM), read-only memory (ROM), and flash memory. TheApplication Processor 420, for example, the Motorola Power PC MPC 823 Rev A supplemented by 16 MB RAM and 8 MB flash memory, supports the QNX Neutrino POSIX-compliant, microkernel real time operating system (RTOS). Digital I/O 414 and Global Positioning System (GPS) 430 geolocation capability is provided with an attached active antenna. - The
analog sensor interfaces 404 include two sets of interfaces. One set provides sampling rates from 1-25 kHz at 12-bit resolution, and the second set provides sampling from 1.88 to 101.1 Hz at 16-bit resolution, both with selectable gains. This provides support for a wide range of sensors. The sensor front-end high-speed input sample rate is accommodated in a power-efficient approach with a dedicated,programmable DSP 412, for example the Texas Instruments 5402. ThisDSP 412 is supplied with an integrated development environment. The DSP code may be communicated to the node 400 via a developer port or directly via the wireless network. The system also provides wireline interfaces with both 10Mb ethernet 440 and RS-232 serial port access. - The multi-radio node 400 includes the software application programming interfaces (APIs), as described below. Node development may be conducted through the
node ethernet port 440 or an RS-232 diagnostic port. The node 400 can mount a file structure on a remote machine, and development and file transfer is facilitated by the nodes capability to run telnet, tftp, and other file transfer protocols. - When a modem is powered on in operation and assigned to a specific network as a base node it acquires any remote nodes within range that are not already synchronized with another base node on the same channel. Similarly any remote nodes that are powered synchronize with any existing bases on their networks. Once every 256 hops each remote node re-registers with the associated base node, so that if a remote node disappears after registering with the network it will be noticed within approximately 4 seconds. Similarly if a base node disappears after registering with the network, its disappearance is discovered immediately by the associated remote nodes because the base node transmits a synchronization signal each hop. Modems appearing and disappearing on the wireless channel of an embodiment are passed through the API as connect or disconnect packets generated by each internal modem when they are no longer synchronized with a specific base node or remote node.
- Within the modems of an embodiment each packet is sent with an automatic repeat request (ARQ) scheme that initiates retransmission of any lost packets at the physical layer up to 16 times based on a 24-bit checksum. The number of retransmissions is configurable, to modify communication as desired. However, the ARQ is only enabled for point-to-point transmissions. While every transmission from a remote node to the associated base node is point-to-point and hence uses the ARQ if configured, transmissions from a base node to a remote node may be point-to-point (if a specific node is addressed) or broadcast in which no retransmission is implemented. A one-byte checksum is also provided at the driver layer to provide error checking in the case of broadcast transmissions.
- Additional feedback on the channel is provided through the Received Signal Strength Indication (RSSI) option of the radio API. This provides the power level averaged over the last ten frequency hops seen by a remote node. The RSSI value is not defined at a base node because each base node may be communicating with multiple remote nodes, while each remote node only communicates with a single base node. The RSSI value is the ten-hop average of the regular synchronization header transmitted from the base node at the start of each hop. The RSSI value provides a relative reference for that radio and outputs an integer value from 0 to 255.
- The radio API provides access to support setting of the operational status of each modem (base or remote, transmit power, network, etc.); however, a default operational status is also provided based on a deterministic node layout. This initial network configuration facilitates quick use of the multi-hop nature of the network, while enabling overlay of a large variety of self-assembly, reconfiguration and routing protocols.
- Within a dual-radio node of an embodiment two modems operate simultaneously, each on an independent network or cluster. The dual architecture facilitates passing information between clusters and allows messages to be passed between networks. For example, with reference to
FIG. 3 , the dual modems of each node 311-313 and 321-325 provide multiple paths among the nodes. Additionally, by transferring a message between each modem driver on a node the message can be passed over many hops like, for example, passing signals fromremote node 321 tobase node 313 of thenetwork 300 via a path includingbase node 311,base node 312, andremote node 324. This communication path may use radios A, C, D, F, K, L, and O. Independent operation of the dual modems reduce the latency in message passing to that required to route information between each modem driver. The header of each packet passed up through the radio API enables directed routing as well as provides for packets to be passed along in a broadcast mode. - Since each dual-radio node is operating two independent modems, each node also has two radio frequency (RF) addresses. At the RF modem API level everything is referred to the RF address. For example, with reference to
FIG. 3 , rather than labeling the nodes with node numbers 311-313 and 321-325, the associated radios are addressed by the radio addresses A-P. This provides flexibility in building a routing table based on neighboring radio addresses. While the RF modem API returns the identities of all radios connected to a selected radio it does not specify at the API level to which node a radio is attached. The node thus provides the capability to pass messages between individual radios to ascertain which nodes they are associated with in order to build node-driven routing tables. - Networks including multi-radio nodes have a higher capacity for multi-hop transmissions through the network because the multi-radio nodes have the advantage of being able to conduct simultaneous transmissions through multiple channels. The multiple radio architecture provides a further advantage of increased robustness to degradations such as jamming because the radios may be tuned to independent channels. This architecture also provides a greater number of connection combinations or alternative communication paths between two nodes. Two radios per node is the minimum necessary for low-latency multi-hop communications where conventional MACs are used, but a larger number provides higher inter-cluster capacity.
-
FIG. 5 is a block diagram of amulti-radio node 500, under an alternative embodiment. Thisnode 500 includes a HitachiSH4 core board 502 that includes a preprocessor and processor. Thecore board 502 is coupled among an SH4 peripheral component interconnect (PCI) bus 512 and universal asynchronous receiver/transmitter (UART)serial ports 514. In a dual-radio configuration, two 2.4GHz FHSS transceivers 522 are coupled to the UARTserial ports 514 along with aGPS receiver 524,orientation sensor 526, andSAF sensor 528. Each of two coder/decoders (CODECs) 530-532 couple to the PCI bus 512 via aPCI AC97 interface 534. Each coder/decoder (CODEC) 530-532 couples to two microphones 540-542 and two speakers 550-552, with the combinations being used for acoustic ranging, as described in detail below. AnEthernet card 560 couples to the PCI bus 512 for use in test and monitoring. - This
node 500 includes a platform hardware configuration and software architecture that provides for shared resource access management. As further described below, and by W. Merrill, K. Sohrabi, L. Girod, J. Elson, F. Newberg, and W. Kaiser in “Open standard development platforms for distributed sensor networks,” Aerosense Conference, Orlando, Fla., Apr. 5, 2002, and in the Related Applications, a Framework for User-Space Devices (FUSD) module or redirection module resides in kernel space and receives requests for access to resources from applications in user space. The FUSD module routes signals representative of the received requests to a device driver interface in user space. Components of the device driver interface include resource management modules and device drivers that correspond to available resources. The resource management modules generate queries to the device drivers regarding availability of the requested resources. Upon receipt of resource status information from the device drivers, components of the device driver interface generate schedules for granting access to the requested resources. Further, the device driver interface components control access to the resources in accordance with the generated schedules including issuing responses to the requesting applications and the device drivers of the requested resources. - The platform software architecture of the sensor nodes described herein uses the FUSD to program functions as applications together with a special driver or driver interface that acts as a proxy for the application at the device level, as described below and in the Related Applications. In this way the FUSD provides access to all drivers and most system resources, and makes use of the security and communications features already built into or onto a standard operating system such as Linux. In this manner, one or more software-exchange mechanisms can be layered on top of the operating system as the mechanisms become available, without the need for any modifications or extensions to the mechanisms in order to enable access to the devices.
- Moreover, the platform software architecture permits secure distribution of applications and key management software across multiple platforms, enabling convenient upgrades of both hardware and software, management of network access by communications and computer peripherals, and cost-accounted and secure interactions among local networks. For example, the software architecture supports personal and handheld computers and their associate network of peripherals, industrial or home automation, security networks, and vehicular systems, for example.
- The FUSD causes the open interface of the sensor node software architecture of an embodiment to appear to the application developer as if increased functionality is provided at the level of the accessed device drivers. This enables access from applications via the standard POSIX virtual file system (VFS). While actually adding the needed functionality within the system kernel (device driver level), the FUSD architecture provides access to the system drivers and resources. In this manner, one or more software-exchange mechanisms can be layered on top of the operating system without the need for any modifications or extensions to these mechanisms to enable access to the devices.
- In typical device drivers there is a layer of indirection between applications (such as read or write) and devices (such as I/O ports). This layer of indirection is needed because there must be some point of synchronization between processes competing for serial resources. Typically, this is managed with “trusted” (verified, stable) code that runs in kernel space and which has direct access to hardware, memory, and other system resources. Unfortunately, device drivers residing in the kernel cannot access most user-space services such as files, the outside world (e.g., serial ports, network interfaces), or user-space libraries, and are unable to block or run for long periods of time. Moreover, typically it is very difficult to write and debug code that must run in the kernel. The FUSD architecture of an embodiment avoids these difficulties by fusing the kernel and user space.
- The FUSD architecture, including a kernel module and a cooperating user-space library, is a Linux framework for proxying device file callbacks into user-space, allowing device files to be implemented by daemons instead of kernel code. Despite being implemented in user-space, FUSD devices can look and act just like any other file under /dev implemented by kernel callbacks.
- A user-space device driver can do many of the things that kernel drivers can not, such as perform a long-running computation, block while waiting for an event, or read files from the file system. Unlike kernel drivers, a user-space device driver can use other device drivers—that is, access the network, talk to a serial port, get interactive input from the user, pop-up graphical user interface (GUI) windows, or read from disks, for example. Further, user-space drivers implemented using FUSD can be much easier to debug. Also, it is impossible for user-space drivers to crash the host platform, and they can be killed and restarted without rebooting even if they become corrupted. User-space drivers can also be swapped out, whereas kernel drivers lock physical memory.
- The FUSD drivers are conceptually similar to kernel drivers in that they include a set of callback functions called in response to system calls made on file descriptors by user programs. The FUSDs C library provides a device registration function, similar to the kernel's devfs_register_chrdev( ) function, to create new devices. The fusd_register( ) function accepts the device name and a structure full of pointers. Those pointers are callback functions which are called in response to certain user system calls, for example, when a process tries to open, close, read from, or write to the device file. The callback functions should conform to the standard definitions of POSIX system call behavior. In many ways, the user-space FUSD callback functions are identical to their kernel counterparts.
- The proxying of kernel system calls that makes possible this kind of program is implemented by FUSD, using a combination of a kernel module and cooperating user-space library. The kernel module implements a character device, /dev/fusd, which is used as a control channel between the kernel module and the user-space library. The fusd_register( ) function uses this channel to send a message to the FUSD kernel module, telling the name of the device the user wants to register. The kernel module, in turn, registers that device with the kernel proper using devfs. The devfs and the kernel do not know anything unusual is happening; it appears from their point of view that the registered devices are simply being implemented by the FUSD module.
- When the kernel subsequently makes a callback due to a system call (e.g., when the character device file is opened or read), the FUSD kernel module callback blocks the calling process, marshals the arguments of the callback into a message and sends it to user-space. Once there, the FUSD user-space library unmarshals it and calls whatever user-space callback the FUSD driver passed to the fusd_register( ) function.
- When the user-space callback returns a value, the process happens in reverse, wherein the return value and its side-effects are marshaled by the library and sent to the kernel. The FUSD kernel module unmarshals this message, matches it up with a corresponding outstanding request, and completes the system call. The calling process is completely unaware of this trickery; it simply enters the kernel once, blocks, unblocks, and returns from the system call, just as it would for any other blocking call.
- As a general example of a system call within a sensor node platform using the FUSD architecture, an application in user space reads from a device driver, but now the VFS calls the FUSD module's read callback. The FUSD module, or redirection module, resides in kernel space and serves mainly to redirect calls to drivers residing in user space, which may for example be written in C, Java, or other standard programming languages. Further, because the driver resides in user space it has access to all the user-space resources. The FUSD module calls the device driver callback, and the response propagates back to the original calling application. The semantics of the return variables under the FUSD architecture are exactly the same as if the device driver were in the kernel space. However, now it is possible to include a much broader set of functions in the driver, which can access user-space resources as well as make calls to other drivers within the kernel space.
- The FUSD enables convenient control of the radios through a set of management tools residing in user space, which the application developer can access via device drivers for each software module.
FIG. 6 is a block diagram of thesoftware architecture 600 of a node incorporating a language-independent user-space driver interface, also referred to herein as a driver interface, under an embodiment. The multi-radio nodes 400 (FIG. 4 ) and 500 (FIG. 5 ) each host thisarchitecture 600. Access to a hardware subsystem such as the radio hardware may be provided in one embodiment via a kernel-space serial port driver 610-612 on each node. Access to this serial port driver 610-612 is then provided in user space via FUSD so that at the lowest software layer, theRF modem driver 632 interfaces to each specific radio, and is dependent on the radio used. Thisdriver 632 then presents a standard interface so that each higher layer module can operate over alternate radios having a driver in place, allowing only user space software changes to thespecific radio driver 632 to use a separate radio over this serial connection. Interfacing above the RF modem driver 610-612 within theuser space 602 of the communication network are stacks 620-622, each of which include three modules 630-634. The three modules include, but are not limited to, aheartbeat module 630 or link-monitoring module, anRF module 632, and a stream/fragmentation module 634. -
FIG. 7 is a block diagram of the user space/kernel space (US/KS)interface 700, under an embodiment. The multi-radio nodes 400 (FIG. 4 ) and 500 (FIG. 5 ) each host thisinterface 600. Each of theheartbeat module 630, theRF module 632, and the stream/fragmentation module 634 include two components, anAPI computational component FUSD module 702. The API component of eachmodule stack user space 602. EachAPI component computational component user space 602 via theFUSD module 702, thereby providing a language independent interface supporting standard POSIX calls just as a kernel-space device file. Thus, the US/KS interface 700 is expanded by theFUSD module 702 to provide device file access within user space to the serial driver and radio hardware as well as theAPI components computational components heartbeat module 630,RF module 632, and stream/fragmentation module 634. - The components 630-634 of each stack couple to a number of other user-space components including, but not limited to, a
cluster module 660 or network discovery and self-assembly module, asynchronization module 650 or sync module, arouting module 640, and an acoustic ranging (AR)module 670. Theheartbeat module 630 of each stack couples to thecluster module 660, thesync module 650, and theAR module 670. TheRF module 632 of each stack couples to thecluster module 660 and thesync module 650. The stream/fragmentation module 634 of each stack couples to thesync module 650 and therouting module 640. Thesync module 650 androuting module 640 also couple to theAR module 670. Each of these modules is described in further detail below.FIG. 8 is a flow diagram of a method of forming a sensor network under and embodiment, as described below. - Referring to
FIGS. 6 and 7 , theRF modem driver 610 andRF module 632 provide capabilities for multiple upper layer software modules 640-670 to send data over the node radios (via user space access through a FUSD device file) and for different systems to configure the radios through the standard API provided by the radio-specific RF driver 632. Radio-specific protocols are built into theRF modem driver 632 in order to provide a radio-independent API 700 to the upper layer software modules 640-670 of the node, with general configuration commands abstracted from the radio physical layer connection properties. Theserial port driver 610 andRF driver 632 are flexible in allowing independent communication to as many radios as are on the node by running multiple versions of the driver for each device file (e.g., a serial port) connected to a modem. TheRF module API 632A provides a language-independent API for higher layer software to use supporting standard POSIX-compliant system calls. TheRF module API 632A also provides a useful debugging interface through command line-queriable device files reporting radio specific status information. - The node platform architecture of the embodiments described herein is consistent with the FUSD architecture described in the Related Applications in that multiple users (or multiple software modules) can access, monitor, and write to each software system, through a protected language independent device file. This allows for easy evaluation of module status, or radio status in the case of the radio driver.
- In addition to enabling configuration of the radios, software operating at the highest layer of the
RF modem driver 632 also parses large packets to utilize the maximum amount of data put into each packet as limited by the radio physical layer. This allows higher layer applications to send data as needed without being dependent on characteristics of individual radios. Alternatively, in order to ensure that a message including multiple packets gets through, the upper layer of the RF modem driver tracks the packet order and monitors the transfer of all message packets, for example the stream/fragmentation module 634. - Returning to
FIGS. 6 and 7 , thecluster module 660, or network discovery and self-assembly module, operates through theRF module 632 to configure the radios and set up the communication network autonomously. In operation, thecluster module 660 sets parameters of eachRF modem driver 632 to form each local network cluster in order to ensure communication is possible across the network. The network nodes may for example operate in a TDMA cycle controlled by a base node, communicating to a number of remotes units. The network nodes of various alternative embodiments also support other communication protocols, including but not limited to, frequency division multiple access (FDMA), code division multiple access (CDMA), and orthogonal frequency division multiplexing (OFDM). This base/remote command is abstracted by theRF modem driver 632 to the role of one modem providing cluster synchronization while the other modems are adherents to that synchronization. - The
cluster module 660 autonomously determines which modem 610-612 should act as the cluster synchronizer, based on the modems with which thecluster module 660 can directly communicate. In so doing, thecluster module 660 sets the role of each modem 610-612 of a node 400/500 by first assigning each modem of a node as a passive listener within each cluster (to determine if another node is synchronizing the network). Then, based on a schedule of which modems can be heard by the listening modems, thecluster module 660 either (1) offers to synchronize each modem with any other modem that the listening modem can hear, or (2) allows the listening modem to be synchronized by a node that the listening modem finds. The clustering algorithm of thecluster module 660 listens for a random period of time for other radios before attempting synchronization. The cluster algorithm also cycles between listening and attempting synchronization until each cluster stabilizes. Regarding synchronization, the cluster algorithm uses a minimum of other available nodes to synchronize (minimum number or remotes synchronized by each base with the current radios). - Once the
cluster module 660 has assembled the individual clusters, theheartbeat module 630, or radio link-monitoring module, actively transmits a heartbeat signal over each connection of the cluster. The heartbeat signal transmits periodically, which in an embodiment is every N seconds (where N is easily configurable), plus or minus 30%, where the heartbeat time is randomized between each pulse. However, alternative embodiments may transmit heartbeat signals with a different periodicity and random dither. The heartbeat signals or packets are transmitted both ways through the cluster to ensure two-way communication. - Embedded within each heartbeat signal is a bit map that corresponds to the processes operating on each node of a cluster. The bit map allows nodes receiving the bit map to determine the operational status of neighboring nodes in addition to the operational status of the RF link. By actively testing the physical layer link within the
heartbeat module 630, both the over-the-air connectivity and the interface to the radio are tested. For example, theheartbeat module 630 uses the same interface via theRF driver module 632 as any other software module of a node to communicate with the radio 610 (i.e., uses the device driver provided by theRF driver 632A), so that theheartbeat module 630 is continuously testing the communication channel exactly as seen on the node. This supports troubleshooting where, for example, the modem communicates fine over the air, but the radio firmware or even the radio driver is experiencing problems buffering data prior to sending it resulting in lost data. - Leveraging the
heartbeat module 630 is theRF synchronization module 650, or sync module, which provides microsecond level accuracy between nodes. Thesync module 650 is built independently of theheartbeat module 630 to easily allow the use of alternate broadcast messages for synchronization, and the integration of alternate synchronization modules. The synchronization operates above the heartbeat software but leverages the fact that each heartbeat packet is broadcast from thecluster module 660 and hence received by all the synchronized radios of a cluster at the same time, as described by J. Elson, L. Girod, and D. Estrin in “Fine-Grained Network Time Synchronization using Reference Broadcasts”, submitted to SIGCOMM 2002. Thus each modem that receives the broadcast packet has a consistent time reference with all the other nodes synchronized in the same cluster. - The base or synchronizing radio does not have a reference time point based on its own broadcast “heartbeat”, but since each node participates in two clusters, it has a reference time from the other cluster in which it participates. Since “heartbeat” packets are sent periodically, each node also conditions for drift in its own clock (based on temperature variations for example) with respect to its neighbors to ensure that once synchronized the nodes stay synchronized for as long as possible, even if no synchronization packets are received for a long period. In addition, with every node participating in two clusters, substantial cluster overlap occurs enabling multiple clusters to be synchronized.
- The nodes 400/500 of an embodiment include any number of
routing modules 640. Therouting modules 640 operate over the clusters assigned by thecluster module 660 and over the links tested by theheartbeat module 630. - The nodes 400/500 of an embodiment use the
AR module 670 to determine their relative locations to other local nodes with which they communicate. TheAR module 670 determines the range and angle between local clusters of nodes and, from this range and angle data, builds a local coordinate system for these nodes using a multilateration module (not shown). Components of theAR module 670 including a merging algorithm that merges multiple local coordinate systems to create a field table. The field table includes the coordinates of many nodes. As an example, the field table may include coordinates for approximately fifty nodes, but is not so limited. - The
AR module 670 leverages the inter-cluster synchronization provided by theheartbeat module 630 through its associated FUSD device driver. The heartbeat provides synchronization over RF, which can be abstracted beyond the local RF cluster. With this synchronization data each node can determine the range to other nodes based on a one-way acoustic time of flight. Each node that includes a modem operating as an RF base synchronizes all acoustic signaling within a local area. This coordination is abstracted from the topology dictated by the network cluster. Determination of the ranges to a sufficient number of neighbors is considerably enhanced by having clusters with a large degree of overlap, as is made convenient with nodes that employ two or more independent radios or modems. - Referring to
FIG. 5 , theAR modules 670 of an embodiment transmit a different coded acoustic chaotic sequence out of each of four speakers 550-552 of thehost node 500. The transmission of these acoustic chaotic sequences is scheduled by the base node of each network cluster. As such, each node within a network cluster attempts to get the range and angle to every other node in the cluster. - The transmitted acoustic chaotic signals are received by the microphones 540-542 of each of the nodes that expect a signal, and correlated for each of the expected chaotic sequences. In the performance of the correlation, the sampled data on each of the four microphones 540-542 is also correlated with an alternate chaotic sequence to determine a representative noise level. Then, based on the correlated signal level, a signal-to-noise ratio (SNR) is assigned to each of the sixteen combinations of microphone/speaker pairs.
- The assigned SNRs are used to determine whether or not to use the sampled data, as follows. To begin, signals from the various transmitting speakers are compared, and the speaker associated with the signal having the highest SNR values is chosen as the signal source for use in all processing (giving an indication that this speaker is pointed towards the receiving node). Signals from the four microphones sampling the signal received from the source speaker are then compared (if they have a large enough SNR) in order to provide both a range between nodes and an angle between nodes. The range between nodes is provided in the form of a weighted average, and the angle between nodes is determined from the weighted time of flight differences between each microphone pair.
- The base node of each network cluster collects the range and angle data calculated between each pair of nodes between which it coordinated ranging. The base node generates a range table using this range and angle data. The range table is then used as input to a local multilateration module to determine a relative coordinate system for the list of nodes in the range table. An algorithm of the multilateration module should use a range and angle combination between these groups of nodes that is adequate to provide an initial guess for the location of nodes, from which an iterative least squares approach is used to generate a multilateration table.
- In expanding the multilateration table to include location information of the nearest fifty or so neighbor nodes, the multilateration data from each base node is intelligently passed to approximately fifty of the nearest neighbor nodes. The AR module transmits the multilateration data using the routing module.
- Upon receipt of the multilateration data, each node contains a collection of multilateration tables that are merged to provide a field table. Each node independently executes the merging in order to provide a field table having the local node as the table origin. Further, in order to minimize the error nearest each node, the merging is accomplished by starting with the largest multilateration table that contains the local node and then merging in each of the other multilateration tables based on the largest common node set. In this manner the nodes propagate field tables including very accurate node position information throughout their associate network.
- The
AR modules 670 update the field table by transmitting updates to the multilateration tables. The multilateration update tables are then merged into the field tables of each node. These updates include a number of status flags to signify the current state of each node, for example if it has been moved (tampered) but is still participating in the network or if it has disappeared from the network. In this manner the disappearance or appearance of a node from the network is passed via updates to the multilateration table within the network. These multilateration table updates also provide a mechanism by which a new node integrates into the network, and provide a soft state approach to system operation by providing information redundantly to each node. - Note from the above discussion that in the absence of RF synchronization the acoustic ranging would be difficult as the time of flight measurements are subject to unacceptable error. For successful position location many nodes have to determine their relative location. The connectedness of the multilateration tables is greatly improved when nodes may belong to multiple clusters. The multi-radio nodes described herein allow the required level of synchronization to be easily achieved and thus serve more than the single purpose of coordination of communications among nodes of a cluster.
- Similarly, in pursuing applications such as acoustic or seismic beamforming, coherent data is needed as these applications share many of the properties of position location applications. Coherent data uses timing that is accurate to within a small fraction of one wave oscillation. Achieving such a level of synchronization across RF cluster boundaries would be difficult in the absence of overlapped cluster membership of nodes.
- The overlapped cluster architecture provides not only low-latency connectivity, but also provides for improved robustness, capacity, and power efficiency compared to typical networking schemes. For example, in a typical pure hierarchical network configuration the cluster heads may be the only nodes with multiple radios and thus the only nodes capable of inter-cluster communication. This limits the number of routes and, due to propagation losses that are typically on the order of the fourth power of distance for ground-to-ground links, leads to increased power consumption.
- By contrast, where other nodes of the cluster can serve as relays there are more paths available for getting around obstacles (such as structures and surface relief), and each link is shorter thereby reducing the total transmitted power along the path. This architecture also provides the secondary benefit of decreased probability of interception of communications and improved resistance to jamming. Additionally, since two radios are active, overall network capacity is increased.
-
FIG. 9 is a block diagram of a multi-radio node 900, under another alternative embodiment. This node 900 includes aprocessor motherboard 902 and anetwork interface 904. Themotherboard 902 of an embodiment accepts at least two plug-in Personal Computer Memory Card International Association (PCMCIA)cards 906 and anEthernet card 908. Themotherboard 902 supports operation as a multi-radio node when configured with an 802.11b radio port in theEthernet port 908 and two 802.11a radio ports in thePCMCIA ports 906. - The
processor motherboard 902 includes the power supply, PCMCIA slots and interfaces, SH7751, PCI, Serial SCI and SCIF, JTAG, Memory Bus, RTC, bridge field programmable gate array (FPGA), random access memory (RAM) 16-64M, flash memory 8-32M, control complex programmable logic device (CPLD), PCI to AC-97 Bridge, CODEC, and quad universal asynchronous receiver transmitter (UART). The network interface includes a peripheral bus, GM J1850 (audio) bus (vehicle applications), GPS interface, and general purpose input/output (GPIO), but alternative embodiments support numerous different interface options. The test expansion board is shown with an Ethernet board, but also supports an IEEE 802.11 radio port. Plug-in PCMCIA cards include IEEE 802.11 radio ports, and a spare, which might be used for Bluetooth. - With the configuration depicted, the SH7751 is the host for the node software architecture described above. The use of multiple additional processors enables many critical real-time management functions to be offloaded from the main processor, allowing determinism without requiring a special operating system. As described in the Related Applications, with respect to vehicle gateways with both a main processor and logic comprising a real-time interface processor (RTIP), systems with this general architecture enable convenient hosting of applications while also assuring real-time operation.
- The processor of an embodiment is a Hitachi HD6417751F167, but is not so limited. The SH7751 can be programmed via a 14-pin JTAG header on the core board. This header is accessible when the board stack is removed from the nodes enclosure. The SH7751 has two native serial ports. The SCI port is used to communicate with the PCI, which controls the power state of the system. This port is used in a SPI mode where the SH7751 acts as a slave. The SCIF port on the SH7751 exits the gateway via the main connector at RS232 levels with full flow control.
- The RAM on the board is scalable from 16 megabytes (M) to 64M in 16M increments. This is implemented by chip selection and the choice of the number of chips populated. The chips are populated in pairs. Using two chips that are 16 bits wide allows a 32-bit write which is twice as fast as two 16-bit writes.
- The flash memory on the board is scalable from 8M to 32M in 8M increments. This is implemented by chip selection and the choice of the number of chips populated. The chips are populated in pairs. Using two chips that are 16 bits wide allows a 32-bit write which is twice as fast as two 16-bit writes.
- The FPGA is responsible for aiding the SH7751 in controlling several devices on the core board. The address bus, data bus, chip selects, and IRQs of the SH7751 are routed to the FPGA so that they may be decoded before interfacing with other devices. The FPGA interfaces with the quad UART, the
network interface 904, and the CODEC and generates GPIOs, which are used for debugging. The FPGA can be programmed either through the SH7751 or a 5-pin JTAG header on the core board. - The node architecture of an embodiment further supports nodes including radios supporting different protocols. The use of different protocols on the same platform is found in hierarchical networks, for example, where base nodes have improved power supplies, antenna elevation, or simply more powerful radios. The separation of functions among the local networking and the longer range multi-hop network can simplify operations in hierarchical networks.
-
FIG. 10 is a block diagram of an IEEE 802.11access network 1000 application including the multi-radio nodes of an embodiment. The installation of an 802.11access network 1000 in a hospital, airport, mall, or other structures in which stringing new communications cable to the access points is costly and difficult in the absence of the multi-radio nodes. Further, use of portable wireless devices alone to actually perform the multi-hop routing is complicated, unreliable (due to their motion), and would demand operating their protocols in an irregular mode. However, the multi-radio nodes of an embodiment facilitate provision of a wireless access network as described below. - With reference to
FIG. 10 , theaccess network 1000 presents a network access point to the end-user that appears to be the same as that of a wired network. The nodes 1011-1014 that support thisaccess network 1000 under an alternative embodiment include at least three radios, and more radios can be included to support alternative network configurations. The three radios include two 802.11a radios that establish a high-speed low-latency multi-hop backbone. The third radio of the node is an 802.11b radio that provides local access for portable electronic devices 1020-1034 like laptop computers and other portable devices equipped with wireless capability. The network access nodes 1011-1014 support the provision ofmultiple paths 1040 between any given access point 1011-1014 and thegateway 1004 to the wirednetwork 1002, thereby providing reliable network access under failures of any given element. The overlapping cluster algorithms described above can then be applied to the formation of the multi-hop access radio wireless backbone. - Alternative embodiments of the
access network 1000 may include nodes 1011-1014 with three 802.11a radios, nodes 1011-1014 with three 802.11b radios, and/or nodes 1011-1014 with various other combinations of 802.111a/802.11b radios. Additionally, alternative embodiments of theaccess network 1000 may include nodes 1011-1014 that support various other communication protocols or wireless local area network (LAN) standards. - The multi-radio node hardware and software described herein and in the Related Applications provides a convenient means of implementing these access networks. The capability for local control over resources such as radio ports supports provision of differentiated quality of service and security without the need for large back-end servers in each installation. The local control over resources further enables remote upgrade of this software. The enterprise-level software provides the capabilities for multiple Internet service providers to be supported, giving economies of scale in the user population.
- The multi-radio nodes of an embodiment are also useful in combination with multi-hop systems known in the art. For example, consider deployment of sensor networks in a security application wherein certain critical locations require coverage by a field of sensors, with a large gap between the critical locations and a command post that receives the sensor information. In this case, there is a need for longer range radios to overcome the gaps in the network. Use of the multi-radio nodes across the gap provides multi-hop coverage over these long-range links while requiring less power than when attempting to bridge the link in one hop. Use of multiple radios for each long-range relay also provides low latency across the link. The overlapping cluster algorithms described above may be used at each level of this network hierarchy.
- The multi-radio nodes described above are not limited to use in local networks of a star architecture, as they may be used with numerous other network protocols to establish both network clusters and/or flat networks. Even with other network protocols, use of the multi-radio nodes enables higher communication throughput (in not having to time share as much on connections) and simplifies synchronization and channel assignment.
- The use of multiple radios on nodes within a sensor or wireless access network provides for efficient leveraging of single cluster protocols to provide low latency multi-hop networks. Multiple radios also facilitate node self-location and coherent combination of data, while providing a more densely connected and more robust network. Numerous embodiments have been described above, and it will be apparent to those skilled in the art that many more alternative embodiments are possible.
- Aspects of the embodiments described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the embodiments include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the embodiments herein may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.
- Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application.
- The above description of illustrated embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. The teachings of the invention provided herein can be applied to other network systems, not only for the network systems described above.
- The elements and acts of the various embodiments described above can be combined to provide further embodiments. All of the above references and Related Applications are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions and concepts of the various references and applications described above to provide yet further embodiments of the invention.
- These and other changes can be made to the invention in light of the above detailed description. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include all network systems that operate under the claims. Accordingly, the invention is not limited by the disclosure, but instead the scope of the invention is to be determined entirely by the claims.
- While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.
Claims (21)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/651,224 US20070223497A1 (en) | 2001-07-03 | 2007-01-08 | Low-latency multi-hop ad hoc wireless network |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US30279501P | 2001-07-03 | 2001-07-03 | |
US34331201P | 2001-12-21 | 2001-12-21 | |
US10/188,514 US7161926B2 (en) | 2001-07-03 | 2002-07-03 | Low-latency multi-hop ad hoc wireless network |
US11/651,224 US20070223497A1 (en) | 2001-07-03 | 2007-01-08 | Low-latency multi-hop ad hoc wireless network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/188,514 Continuation US7161926B2 (en) | 2001-07-03 | 2002-07-03 | Low-latency multi-hop ad hoc wireless network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070223497A1 true US20070223497A1 (en) | 2007-09-27 |
Family
ID=27392434
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/188,514 Expired - Fee Related US7161926B2 (en) | 2001-07-03 | 2002-07-03 | Low-latency multi-hop ad hoc wireless network |
US11/651,224 Abandoned US20070223497A1 (en) | 2001-07-03 | 2007-01-08 | Low-latency multi-hop ad hoc wireless network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/188,514 Expired - Fee Related US7161926B2 (en) | 2001-07-03 | 2002-07-03 | Low-latency multi-hop ad hoc wireless network |
Country Status (1)
Country | Link |
---|---|
US (2) | US7161926B2 (en) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060062220A1 (en) * | 2004-09-17 | 2006-03-23 | Fujitsu Limited | Radio terminal and ad hoc communication method |
US20080109536A1 (en) * | 2006-11-08 | 2008-05-08 | Electoronics & Telecommunications Research Institute | Method of forming cluster individually by each sensor node over sensor network |
US20080164997A1 (en) * | 2006-05-08 | 2008-07-10 | Toshiyuki Aritsuka | Sensor-net systems and its application systems for locationing |
US20090154395A1 (en) * | 2007-12-17 | 2009-06-18 | Electronics And Telecommunications Research Institute | Wireless sensor network having hierarchical structure and routing method thereof |
US20100148940A1 (en) * | 1999-10-06 | 2010-06-17 | Gelvin David C | Apparatus for internetworked wireless integrated network sensors (wins) |
US20100226342A1 (en) * | 2007-07-30 | 2010-09-09 | Colling Kent D | Distributed Ad Hoc Network Protocol Using Synchronous Shared Beacon Signaling |
US20110130162A1 (en) * | 2009-11-30 | 2011-06-02 | Electronics And Telecommunications Research Institute | Method for cluster based data transmission in wireless sensor networks |
US20130107668A1 (en) * | 2011-10-28 | 2013-05-02 | Raytheon Company | Convoy-based systems and methods for locating an acoustic source |
US8543390B2 (en) * | 2004-10-26 | 2013-09-24 | Qnx Software Systems Limited | Multi-channel periodic signal enhancement system |
AU2014204519B2 (en) * | 2013-07-25 | 2015-08-27 | Honeywell International Inc. | Interference avoidance technique for wireless networks used in critical applications |
US10659300B2 (en) * | 2018-05-05 | 2020-05-19 | Current Lighting Solutions, Llc | Self-forming network commissioning system and method |
US11269700B2 (en) * | 2019-04-23 | 2022-03-08 | Apple Inc. | System call interception for file providers |
US11665658B1 (en) | 2021-04-16 | 2023-05-30 | Rockwell Collins, Inc. | System and method for application of doppler corrections for time synchronized transmitter and receiver |
US11726162B2 (en) | 2021-04-16 | 2023-08-15 | Rockwell Collins, Inc. | System and method for neighbor direction and relative velocity determination via doppler nulling techniques |
US11737121B2 (en) | 2021-08-20 | 2023-08-22 | Rockwell Collins, Inc. | System and method to compile and distribute spatial awareness information for network |
US11977173B2 (en) | 2019-11-27 | 2024-05-07 | Rockwell Collins, Inc. | Spoofing and denial of service detection and protection with doppler nulling (spatial awareness) |
US12050279B2 (en) | 2019-11-27 | 2024-07-30 | Rockwell Collins, Inc. | Doppler nulling spatial awareness (DNSA) solutions for non-terrestrial networks |
Families Citing this family (148)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
US7907941B2 (en) * | 2006-01-01 | 2011-03-15 | Terahop Networks, Inc. | Determining presence of radio frequency communication device |
US7161926B2 (en) * | 2001-07-03 | 2007-01-09 | Sensoria Corporation | Low-latency multi-hop ad hoc wireless network |
US7277414B2 (en) * | 2001-08-03 | 2007-10-02 | Honeywell International Inc. | Energy aware network management |
US7421257B1 (en) | 2001-11-30 | 2008-09-02 | Stragent, Llc | Receiver scheduling in ad hoc wireless networks |
US7305467B2 (en) * | 2002-01-02 | 2007-12-04 | Borgia/Cummins, Llc | Autonomous tracking wireless imaging sensor network including an articulating sensor and automatically organizing network nodes |
US7483403B2 (en) * | 2002-01-10 | 2009-01-27 | Robert Bosch Gmbh | Protocol for reliable, self-organizing, low-power wireless network for security and building automation systems |
US7149196B1 (en) * | 2002-01-11 | 2006-12-12 | Broadcom Corporation | Location tracking in a wireless communication system using power levels of packets received by repeaters |
US7515557B1 (en) * | 2002-01-11 | 2009-04-07 | Broadcom Corporation | Reconfiguration of a communication system |
US6788658B1 (en) * | 2002-01-11 | 2004-09-07 | Airflow Networks | Wireless communication system architecture having split MAC layer |
US7672274B2 (en) * | 2002-01-11 | 2010-03-02 | Broadcom Corporation | Mobility support via routing |
US7876704B1 (en) | 2002-01-11 | 2011-01-25 | Broadcom Corporation | Tunneling protocols for wireless communications |
US7499977B1 (en) * | 2002-01-14 | 2009-03-03 | Cisco Technology, Inc. | Method and system for fault management in a distributed network management station |
EP1483868A1 (en) * | 2002-03-12 | 2004-12-08 | Nokia Corporation | Method and device for wireless network formation |
US7113498B2 (en) | 2002-06-05 | 2006-09-26 | Broadcom Corporation | Virtual switch |
US7042867B2 (en) * | 2002-07-29 | 2006-05-09 | Meshnetworks, Inc. | System and method for determining physical location of a node in a wireless network during an authentication check of the node |
US20040204079A1 (en) * | 2002-09-30 | 2004-10-14 | Compaq Information Technologies Group, L.P. | Dual access wireless LAN system |
US10785316B2 (en) | 2008-11-24 | 2020-09-22 | MeshDynamics | Evolutionary wireless networks |
US8520691B2 (en) * | 2003-05-08 | 2013-08-27 | Mesh Dynamics, Inc. | Persistent mesh for isolated mobile and temporal networking |
US7356032B1 (en) | 2002-11-01 | 2008-04-08 | Bbn Technologies Corp. | System and method for reducing broadcast traffic wireless access-point networks |
US7983239B1 (en) | 2003-01-07 | 2011-07-19 | Raytheon Bbn Technologies Corp. | Systems and methods for constructing a virtual model of a multi-hop, multi-access network |
US7409716B2 (en) * | 2003-02-07 | 2008-08-05 | Lockheed Martin Corporation | System for intrusion detection |
EP1458139A1 (en) * | 2003-03-14 | 2004-09-15 | Mitsubishi Electric Information Technology Centre Europe B.V. | CDMA access method for channel allocation in an ad-hoc wireless network system (WPAN, scatternet) |
US8248968B2 (en) * | 2003-10-03 | 2012-08-21 | Apple Inc. | Method and apparatus for providing mobile inter-mesh communication points in a multi-level wireless mesh network |
JP3838237B2 (en) | 2003-04-30 | 2006-10-25 | ソニー株式会社 | Wireless communication system, transmitting apparatus and receiving apparatus |
US7035757B2 (en) * | 2003-05-09 | 2006-04-25 | Intel Corporation | Three-dimensional position calibration of audio sensors and actuators on a distributed computing platform |
KR100552490B1 (en) * | 2003-06-13 | 2006-02-15 | 삼성전자주식회사 | Coordinator switching method in ad-hoc network environment and communication of using the same |
US7701858B2 (en) * | 2003-07-17 | 2010-04-20 | Sensicast Systems | Method and apparatus for wireless communication in a mesh network |
US7881229B2 (en) * | 2003-08-08 | 2011-02-01 | Raytheon Bbn Technologies Corp. | Systems and methods for forming an adjacency graph for exchanging network routing data |
US20050050196A1 (en) * | 2003-08-25 | 2005-03-03 | Lucent Technologies Inc. | Method and apparatus for managing and graphically representing elements in a network |
US7606927B2 (en) | 2003-08-27 | 2009-10-20 | Bbn Technologies Corp | Systems and methods for forwarding data units in a communications network |
US8166204B2 (en) * | 2003-08-29 | 2012-04-24 | Raytheon Bbn Technologies Corp. | Systems and methods for automatically placing nodes in an ad hoc network |
GB0321041D0 (en) * | 2003-09-09 | 2004-02-04 | Qinetiq Ltd | Sensor apparatus and system |
US20050074025A1 (en) * | 2003-10-02 | 2005-04-07 | Huai-Rong Shao | Media Access Control Protocol for wireless sensor networks |
US7668083B1 (en) | 2003-10-28 | 2010-02-23 | Bbn Technologies Corp. | Systems and methods for forwarding data in a communications network |
US8228759B2 (en) | 2003-11-21 | 2012-07-24 | Fairfield Industries Incorporated | System for transmission of seismic data |
US7738413B2 (en) * | 2003-12-08 | 2010-06-15 | The Regents Of The University Of California | Minimizing power consumption in a wireless system for a sensor networks using time slots for nodes |
US20050200480A1 (en) * | 2003-12-09 | 2005-09-15 | Caras Jay D. | System and method for monitoring the occurrence of situational and environmental events using distributed sensors |
DE10358248B4 (en) * | 2003-12-09 | 2015-03-19 | Volkswagen Ag | Method and apparatus for booting up a node of a communication system |
US7274940B2 (en) * | 2003-12-29 | 2007-09-25 | Motorola, Inc. | Method and system for determining a location of a plurality of units using sub-divided unit groupings |
GB2411545B (en) * | 2004-02-27 | 2007-05-30 | Exenet Ltd | Wireless networks |
US7548758B2 (en) * | 2004-04-02 | 2009-06-16 | Nortel Networks Limited | System and method for peer-to-peer communication in cellular systems |
US7362737B2 (en) * | 2004-04-08 | 2008-04-22 | Tropos Networks, Inc. | Minimization of channel filters within wireless access nodes |
WO2005122508A1 (en) * | 2004-06-10 | 2005-12-22 | University Of Limerick | A network gateway |
US7239626B2 (en) | 2004-06-30 | 2007-07-03 | Sharp Laboratories Of America, Inc. | System clock synchronization in an ad hoc and infrastructure wireless networks |
US7860495B2 (en) * | 2004-08-09 | 2010-12-28 | Siemens Industry Inc. | Wireless building control architecture |
KR100662562B1 (en) * | 2004-08-19 | 2006-12-28 | 삼성전자주식회사 | wireless network system and electronic device |
KR100898681B1 (en) * | 2004-09-07 | 2009-05-22 | 메시네트웍스, 인코포레이티드 | System and method for routing data between different types of nodes in a wireless network |
US7408839B2 (en) * | 2004-09-09 | 2008-08-05 | Siemens Building Technologies, Inc. | Distance measurement for wireless building automation devices |
US20060063523A1 (en) | 2004-09-21 | 2006-03-23 | Mcfarland Norman R | Portable wireless sensor for building control |
US7378980B2 (en) * | 2004-09-29 | 2008-05-27 | Siemens Building Technologies, Inc. | Triangulation of position for automated building control components |
US7382271B2 (en) * | 2004-09-29 | 2008-06-03 | Siemens Building Technologies, Inc. | Automated position detection for wireless building automation devices |
US7304976B2 (en) * | 2004-10-13 | 2007-12-04 | Virginia Tech Intellectual Properties, Inc. | Method and apparatus for control and routing of wireless sensor networks |
EP1803316B1 (en) * | 2004-10-21 | 2015-03-04 | Panasonic Corporation | System and method for relaying in multi-hop cellular networks |
US20060114847A1 (en) * | 2004-12-01 | 2006-06-01 | Rachida Dssouli | User agent and super user agent for cluster-based multi-party conferencing in ad-hoc networks |
US7496059B2 (en) * | 2004-12-09 | 2009-02-24 | Itt Manufacturing Enterprises, Inc. | Energy-efficient medium access control protocol and system for sensor networks |
KR100642722B1 (en) * | 2004-12-18 | 2006-11-10 | 재단법인서울대학교산학협력재단 | Hierarchical cellular network based on multiple access techniques and cellular phone based on multiple access techniques using the same |
FI118291B (en) * | 2004-12-22 | 2007-09-14 | Timo D Haemaelaeinen | Energy efficient wireless sensor network, node devices for the same and method of arranging, the communications in a wireless sensor network |
US7275014B1 (en) | 2005-02-10 | 2007-09-25 | At&T Corporation | Distributed graph layout for sensor node networks |
EP1862037A1 (en) * | 2005-03-11 | 2007-12-05 | Koninklijke Philips Electronics N.V. | Commissioning wireless network devices according to an installation plan |
US7372773B2 (en) * | 2005-04-08 | 2008-05-13 | Honeywell International, Inc. | Method and system of providing clustered networks of bearing-measuring sensors |
US20060264214A1 (en) * | 2005-05-20 | 2006-11-23 | Nextwave Broadband, Inc. | Mode-switching wireless communications equipment |
KR20060124498A (en) * | 2005-05-31 | 2006-12-05 | 삼성전자주식회사 | Method for controlling media access in wireless sensor network |
FR2889385B1 (en) * | 2005-07-28 | 2008-09-26 | Sercel Sa | WIRELESS DATA ACQUISITION NETWORK |
US8035509B2 (en) * | 2005-08-26 | 2011-10-11 | The Invention Science Fund I, Llc | Stimulating a mote network for cues to mote location and layout |
US8018335B2 (en) | 2005-08-26 | 2011-09-13 | The Invention Science Fund I, Llc | Mote device locating using impulse-mote-position-indication |
US8306638B2 (en) | 2005-08-26 | 2012-11-06 | The Invention Science Fund I, Llc | Mote presentation affecting |
US7770071B2 (en) | 2005-10-06 | 2010-08-03 | The Invention Science Fund I, Inc | Mote servicing |
US7906765B2 (en) * | 2005-10-06 | 2011-03-15 | Invention Science Fund I | Mote signal energy aspects |
US7708493B2 (en) | 2005-08-26 | 2010-05-04 | Searete, Llc | Modifiable display marker |
US20070080797A1 (en) * | 2005-10-06 | 2007-04-12 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Maintaining or identifying mote devices |
EP1938483B1 (en) | 2005-09-21 | 2015-07-08 | Intermec IP Corp. | Stochastic communication protocol method and system for radio frequency identification (rfid) tags based on coalition formation, such as for tag-to-tag communication |
US7518499B2 (en) * | 2005-10-12 | 2009-04-14 | Agilent Technologies, Inc. | System and method for autonomous interaction among neighboring sensors in a network of sensors |
US7581142B2 (en) * | 2006-01-03 | 2009-08-25 | Nec Laboratories America, Inc. | Method and system usable in sensor networks for handling memory faults |
CN100438474C (en) * | 2006-01-06 | 2008-11-26 | 中国人民解放军理工大学 | Adaptive dormancy method of network data chain circuit layer of cluster structured radio sensor |
US8120461B2 (en) * | 2006-04-03 | 2012-02-21 | Intermec Ip Corp. | Automatic data collection device, method and article |
CN100396049C (en) * | 2006-05-26 | 2008-06-18 | 北京交通大学 | Cluster chief election method based on node type for ad hoc network |
US7570927B2 (en) * | 2006-06-16 | 2009-08-04 | Motorola, Inc. | Decentralized wireless communication network and method having a plurality of devices |
US9948533B2 (en) | 2006-07-10 | 2018-04-17 | Solarflare Communitations, Inc. | Interrupt management |
US9686117B2 (en) * | 2006-07-10 | 2017-06-20 | Solarflare Communications, Inc. | Chimney onload implementation of network protocol stack |
CN100452742C (en) * | 2006-07-28 | 2009-01-14 | 西安电子科技大学 | Method for multi-address switch-in for moving target detection wireless sensing unit network |
WO2008044193A2 (en) * | 2006-10-12 | 2008-04-17 | Philips Intellectual Property & Standards Gmbh | Method and system for time synchronization in a sensor network |
US8509238B2 (en) * | 2006-11-22 | 2013-08-13 | Nec Corporation | Communication network, information processor and address assigning method |
US7995604B2 (en) * | 2006-12-30 | 2011-08-09 | Broadcom Corporation | Collision avoidance for communications within a device |
KR100888730B1 (en) | 2007-01-12 | 2009-03-17 | 삼성전자주식회사 | Method and apparatus for controlling power in a decode-forward relaying system |
KR101301775B1 (en) | 2007-01-31 | 2013-09-02 | 삼성전자주식회사 | Method for executing distributed verification for measured data in sensor network and system for executing the method |
CN100438450C (en) * | 2007-02-08 | 2008-11-26 | 北京航空航天大学 | Stable energy-saving group maintenance method |
US8213409B2 (en) * | 2007-02-20 | 2012-07-03 | Harris Corporation | System and method for communicating over mesh networks using waveform-enhanced, link-state routing |
CN101184005B (en) * | 2007-03-16 | 2011-01-12 | 中国科学院嘉兴无线传感网工程中心 | Double cluster wireless sensor network based adaptive communication method |
US7948897B2 (en) * | 2007-08-15 | 2011-05-24 | Adc Telecommunications, Inc. | Delay management for distributed communications networks |
US20090054069A1 (en) * | 2007-08-24 | 2009-02-26 | Zeetoo, Inc. | Platform Independent Communication Protocol |
US8077658B2 (en) | 2007-10-01 | 2011-12-13 | Microsoft Corporation | Packet forwarding in multi-radio multi-hop wireless networks |
US8510757B2 (en) * | 2008-01-11 | 2013-08-13 | Google Inc. | Gathering pages allocated to an application to include in checkpoint information |
US8209707B2 (en) * | 2008-01-11 | 2012-06-26 | Google Inc. | Gathering state information for an application and kernel components called by the application |
US20090201840A1 (en) * | 2008-02-08 | 2009-08-13 | Pfeiffer Jr Loren K | Wireless networks using a rooted, directed topology |
US8140016B2 (en) | 2008-03-13 | 2012-03-20 | Sony Ericsson Mobile Communications Ab | Wireless communication terminals and methods using acoustic ranging synchronized to RF communication signals |
WO2009130577A2 (en) * | 2008-04-22 | 2009-10-29 | Robert Bosch Gmbh | Method for reducing latency of wireless data packet delivery |
US8462662B2 (en) * | 2008-05-16 | 2013-06-11 | Google Inc. | Updating node presence based on communication pathway |
US8023443B2 (en) * | 2008-06-03 | 2011-09-20 | Simmonds Precision Products, Inc. | Wireless sensor system |
CN101355390B (en) * | 2008-08-12 | 2011-08-10 | 武汉大学 | Method for collecting virtual cluster of underwater sensor network high time resolution data |
IT1392267B1 (en) * | 2008-10-10 | 2012-02-22 | Univ Degli Studi Udine | WIRELESS TRANSCEIVER PROCEDURE AND ITS EQUIPMENT |
DE102008059879A1 (en) * | 2008-12-01 | 2010-06-10 | Bundesanstalt für Materialforschung und -Prüfung (BAM) | Radio sensor module and system for building monitoring |
US8705523B2 (en) | 2009-02-05 | 2014-04-22 | Google Inc. | Conjoined class-based networking |
US8139504B2 (en) * | 2009-04-07 | 2012-03-20 | Raytheon Bbn Technologies Corp. | System, device, and method for unifying differently-routed networks using virtual topology representations |
US20110051641A1 (en) * | 2009-08-30 | 2011-03-03 | Yang Pan | Low Power Consumption Wireless Sensory and Data Transmission System |
US8331344B2 (en) * | 2009-09-03 | 2012-12-11 | Robert Bosch Gmbh | Learning wireless medium access control for discrete event control systems |
DE102009040382A1 (en) | 2009-09-07 | 2011-03-10 | Schaeffler Technologies Gmbh & Co. Kg | Sensor and sensor network and method for its operation |
DE102009029495A1 (en) * | 2009-09-16 | 2011-03-24 | Endress + Hauser Conducta Gesellschaft für Mess- und Regeltechnik mbH + Co. KG | Transmitter for a multi-sensor system, in particular as field device for process automation technology and method for operating the transmitter |
US8295280B2 (en) * | 2009-12-21 | 2012-10-23 | Manipal Institute Of Technology | Multi-service adaptable routing protocol for wireless sensor networks |
US9497726B2 (en) * | 2010-01-06 | 2016-11-15 | Landis+Gyr Innovations, Inc. | Systems and methods for wireless network routing using radio frequency distance-based virtual node locations |
US8645854B2 (en) * | 2010-01-19 | 2014-02-04 | Verizon Patent And Licensing Inc. | Provisioning workflow management methods and systems |
US8406217B2 (en) | 2010-04-16 | 2013-03-26 | Simmonds Precision Products, Inc. | Synchronizing wireless devices using timestamps and relative clock offsets of the wireless devices |
FI20105658A (en) * | 2010-06-10 | 2011-12-11 | Defendec Inc | Apparatus and method for an ad hoc moving multi-voltage network |
KR101771026B1 (en) * | 2010-08-12 | 2017-08-25 | 삼성전자주식회사 | Method and apparatus for data communication while base station is disrupted troyed in wireless communication system |
KR20120017821A (en) * | 2010-08-20 | 2012-02-29 | 삼성전자주식회사 | Apparatus and method for sharing data in portable terminal |
US8743718B2 (en) | 2011-06-21 | 2014-06-03 | Adc Telecommunications, Inc. | End-to-end delay management for distributed communications networks |
CN102448067A (en) * | 2011-09-30 | 2012-05-09 | 山东大学 | Method for realizing multi-node voice communication in ZigBee network |
US8611877B2 (en) | 2011-10-31 | 2013-12-17 | Blackberry Limited | Automatic management control of external resources |
US9020119B2 (en) | 2011-10-31 | 2015-04-28 | Blackberry Limited | Moderation control method for participants in a heterogeneous conference call |
US8605881B2 (en) | 2011-10-31 | 2013-12-10 | Blackberry Limited | Auto promotion and demotion of conference calls |
US9128786B2 (en) | 2011-11-22 | 2015-09-08 | Futurewei Technologies, Inc. | System and method for implementing shared locks between kernel and user space for synchronize access without using a system call to the kernel |
CN102612077B (en) * | 2012-03-19 | 2014-11-19 | 东南大学 | Medium access control method used for distributed multi-skip underwater acoustic communication network |
US9112790B2 (en) | 2013-06-25 | 2015-08-18 | Google Inc. | Fabric network |
US9450689B2 (en) | 2013-10-07 | 2016-09-20 | Commscope Technologies Llc | Systems and methods for delay management in distributed antenna system with direct digital interface to base station |
CN103905198B (en) * | 2014-03-07 | 2017-02-22 | 宁波大学 | Mobile CA node electing method based on MD5 hash information abstract |
US10445055B2 (en) * | 2014-12-23 | 2019-10-15 | Lg Electronics Inc. | Mobile terminal, audio output device and audio output system comprising same |
US9722640B2 (en) * | 2015-01-06 | 2017-08-01 | Discovery Robotics | Method and system for determining precise robotic position and orientation using near-simultaneous radio frequency measurements |
US10328573B2 (en) | 2015-01-06 | 2019-06-25 | Discovery Robotics | Robotic platform with teach-repeat mode |
US11400595B2 (en) | 2015-01-06 | 2022-08-02 | Nexus Robotics Llc | Robotic platform with area cleaning mode |
US10518407B2 (en) | 2015-01-06 | 2019-12-31 | Discovery Robotics | Apparatus and methods for providing a reconfigurable robotic platform |
US9984686B1 (en) * | 2015-03-17 | 2018-05-29 | Amazon Technologies, Inc. | Mapping device capabilities to a predefined set |
TWI551083B (en) * | 2015-03-18 | 2016-09-21 | 鴻海精密工業股份有限公司 | System and method for building functional group |
CN106161527B (en) * | 2015-04-07 | 2019-08-13 | 富泰华工业(深圳)有限公司 | Function group construction system and method |
US9655135B2 (en) * | 2015-06-04 | 2017-05-16 | Qualcomm Incorporated | Robust systematic multi-user (MU) grouping and scheduling |
US10655951B1 (en) | 2015-06-25 | 2020-05-19 | Amazon Technologies, Inc. | Determining relative positions of user devices |
US10365620B1 (en) | 2015-06-30 | 2019-07-30 | Amazon Technologies, Inc. | Interoperability of secondary-device hubs |
RU2719394C2 (en) | 2015-09-08 | 2020-04-17 | Филипс Лайтинг Холдинг Б.В. | Connection of light devices |
AU2015419335B2 (en) * | 2015-12-31 | 2022-01-27 | Razer (Asia-Pacific) Pte. Ltd. | Methods for controlling a computing device, computer-readable media, and computing devices |
USD869108S1 (en) | 2016-07-14 | 2019-12-03 | Discovery Robotics | Robot comprising a service module |
US9943229B1 (en) | 2016-12-08 | 2018-04-17 | General Electric Copany | Systems and methods for monitoring patient health |
US10412616B1 (en) | 2017-07-11 | 2019-09-10 | Sprint Communications Company, L.P. | Equalized data latency for user applications in a wireless data network |
EP3868058A1 (en) | 2018-10-19 | 2021-08-25 | Carrier Corporation | Energy-balanced and latency-constrained routing methods in wireless network |
WO2020106457A1 (en) | 2018-11-20 | 2020-05-28 | Carrier Corporation | Robust multipath routing methods in wireless network |
CN111220969B (en) * | 2019-10-28 | 2023-06-30 | 浙江优威科技有限公司 | Land networking training and performance testing integrated device of underwater communication sonar |
CN111615166B (en) * | 2020-06-02 | 2022-06-07 | 赣南师范大学 | Unmanned aerial vehicle ad hoc network clustering judgment method for agricultural application |
CN113641749B (en) * | 2021-07-16 | 2024-06-07 | 中国人民解放军国防科技大学 | Population flow network estimation method and system based on bipartite graph |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020196763A1 (en) * | 1999-12-08 | 2002-12-26 | Reynolds Russell R. | Wireless network system software protocol |
US20030133422A1 (en) * | 2002-01-11 | 2003-07-17 | Harry Bims | Mobility support via routing |
US20040264379A1 (en) * | 2000-12-29 | 2004-12-30 | Devabhaktuni Srikrishna | Multi-channel mesh network |
US20060018285A1 (en) * | 2000-12-15 | 2006-01-26 | Polycom, Inc. | System and method for device co-location discrimination |
US7013138B2 (en) * | 1993-12-20 | 2006-03-14 | Broadcom Corporation | Local area network having multiple channel wireless access |
US7161926B2 (en) * | 2001-07-03 | 2007-01-09 | Sensoria Corporation | Low-latency multi-hop ad hoc wireless network |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA1208349A (en) * | 1983-07-05 | 1986-07-22 | James B. Vance | Integrated acoustic network |
US4812820A (en) * | 1985-07-23 | 1989-03-14 | Chatwin Ian Malcolm | Electronic surveillance system and transceiver unit therefor |
US4918690A (en) * | 1987-11-10 | 1990-04-17 | Echelon Systems Corp. | Network and intelligent cell for providing sensing, bidirectional communications and control |
US4951029A (en) * | 1988-02-16 | 1990-08-21 | Interactive Technologies, Inc. | Micro-programmable security system |
US4855713A (en) * | 1988-10-07 | 1989-08-08 | Interactive Technologies, Inc. | Learn mode transmitter |
US5428636A (en) * | 1993-05-03 | 1995-06-27 | Norand Corporation | Radio frequency local area network |
US5247564A (en) * | 1990-10-24 | 1993-09-21 | Gte Mobile Communications Service Corp. | Adaptive vehicle alarm detection and reporting system |
US5241542A (en) * | 1991-08-23 | 1993-08-31 | International Business Machines Corporation | Battery efficient operation of scheduled access protocol |
CA2120520A1 (en) * | 1991-10-01 | 1993-04-15 | Robert C. Meier | A radio frequency local area network |
US5553076A (en) * | 1994-05-02 | 1996-09-03 | Tcsi Corporation | Method and apparatus for a wireless local area network |
US5659195A (en) * | 1995-06-08 | 1997-08-19 | The Regents Of The University Of California | CMOS integrated microsensor with a precision measurement circuit |
US5732074A (en) * | 1996-01-16 | 1998-03-24 | Cellport Labs, Inc. | Mobile portable wireless communication system |
SE521508C2 (en) | 1996-06-20 | 2003-11-04 | Telia Ab | Control and monitoring of electrical components |
US5854994A (en) * | 1996-08-23 | 1998-12-29 | Csi Technology, Inc. | Vibration monitor and transmission system |
US6028857A (en) * | 1997-07-25 | 2000-02-22 | Massachusetts Institute Of Technology | Self-organizing network |
DE19743137A1 (en) | 1997-09-30 | 1999-04-01 | Hansjoerg Klein | Security and warning system for civil and military applications |
US7027416B1 (en) | 1997-10-01 | 2006-04-11 | Honeywell, Inc. | Multi tier wireless communication system |
US6208247B1 (en) * | 1998-08-18 | 2001-03-27 | Rockwell Science Center, Llc | Wireless integrated sensor network using multiple relayed communications |
JP2004500612A (en) | 1999-03-12 | 2004-01-08 | グラビトン・インコーポレイテッド | Systems and methods for network-based sensing and distributed sensors, data and memory management |
-
2002
- 2002-07-03 US US10/188,514 patent/US7161926B2/en not_active Expired - Fee Related
-
2007
- 2007-01-08 US US11/651,224 patent/US20070223497A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7013138B2 (en) * | 1993-12-20 | 2006-03-14 | Broadcom Corporation | Local area network having multiple channel wireless access |
US20020196763A1 (en) * | 1999-12-08 | 2002-12-26 | Reynolds Russell R. | Wireless network system software protocol |
US20060018285A1 (en) * | 2000-12-15 | 2006-01-26 | Polycom, Inc. | System and method for device co-location discrimination |
US20040264379A1 (en) * | 2000-12-29 | 2004-12-30 | Devabhaktuni Srikrishna | Multi-channel mesh network |
US7161926B2 (en) * | 2001-07-03 | 2007-01-09 | Sensoria Corporation | Low-latency multi-hop ad hoc wireless network |
US20030133422A1 (en) * | 2002-01-11 | 2003-07-17 | Harry Bims | Mobility support via routing |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10757000B2 (en) | 1999-10-06 | 2020-08-25 | Behnov GMBH, LLC | Apparatus for internetworked wireless integrated network sensors (WINS) |
US9628365B2 (en) | 1999-10-06 | 2017-04-18 | Benhov Gmbh, Llc | Apparatus for internetworked wireless integrated network sensors (WINS) |
US8836503B2 (en) | 1999-10-06 | 2014-09-16 | Borgia/Cummins, Llc | Apparatus for compact internetworked wireless integrated network sensors (WINS) |
US8832244B2 (en) | 1999-10-06 | 2014-09-09 | Borgia/Cummins, Llc | Apparatus for internetworked wireless integrated network sensors (WINS) |
US20100148940A1 (en) * | 1999-10-06 | 2010-06-17 | Gelvin David C | Apparatus for internetworked wireless integrated network sensors (wins) |
US20100201516A1 (en) * | 1999-10-06 | 2010-08-12 | Gelvin David C | Apparatus for Compact Internetworked Wireless Integrated Network Sensors (WINS) |
US8812654B2 (en) * | 1999-10-06 | 2014-08-19 | Borgia/Cummins, Llc | Method for internetworked hybrid wireless integrated network sensors (WINS) |
US20110035491A1 (en) * | 1999-10-06 | 2011-02-10 | Gelvin David C | Method for Internetworked Hybrid Wireless Integrated Network Sensors (WINS) |
US20060062220A1 (en) * | 2004-09-17 | 2006-03-23 | Fujitsu Limited | Radio terminal and ad hoc communication method |
US7733861B2 (en) * | 2004-09-17 | 2010-06-08 | Fujitsu Limited | Radio terminal and ad hoc communication method |
US8543390B2 (en) * | 2004-10-26 | 2013-09-24 | Qnx Software Systems Limited | Multi-channel periodic signal enhancement system |
US7675410B2 (en) * | 2006-05-08 | 2010-03-09 | Hitachi, Ltd. | Sensor-net systems and its application systems for locationing |
US20080164997A1 (en) * | 2006-05-08 | 2008-07-10 | Toshiyuki Aritsuka | Sensor-net systems and its application systems for locationing |
US20080109536A1 (en) * | 2006-11-08 | 2008-05-08 | Electoronics & Telecommunications Research Institute | Method of forming cluster individually by each sensor node over sensor network |
US8385322B2 (en) * | 2007-07-30 | 2013-02-26 | Innovative Wireless Technologies, Inc. | Distributed ad hoc network protocol using synchronous shared beacon signaling |
US20100226342A1 (en) * | 2007-07-30 | 2010-09-09 | Colling Kent D | Distributed Ad Hoc Network Protocol Using Synchronous Shared Beacon Signaling |
US20090154395A1 (en) * | 2007-12-17 | 2009-06-18 | Electronics And Telecommunications Research Institute | Wireless sensor network having hierarchical structure and routing method thereof |
US8223784B2 (en) * | 2007-12-17 | 2012-07-17 | Electronics And Telecommunications Research Institute | Wireless sensor network having hierarchical structure and routing method thereof |
US20110130162A1 (en) * | 2009-11-30 | 2011-06-02 | Electronics And Telecommunications Research Institute | Method for cluster based data transmission in wireless sensor networks |
US8605694B2 (en) * | 2009-11-30 | 2013-12-10 | Electronics And Telecommunications Research Institute | Method for cluster based data transmission in wireless sensor networks |
US20130107668A1 (en) * | 2011-10-28 | 2013-05-02 | Raytheon Company | Convoy-based systems and methods for locating an acoustic source |
AU2014204519B2 (en) * | 2013-07-25 | 2015-08-27 | Honeywell International Inc. | Interference avoidance technique for wireless networks used in critical applications |
US10659300B2 (en) * | 2018-05-05 | 2020-05-19 | Current Lighting Solutions, Llc | Self-forming network commissioning system and method |
US11269700B2 (en) * | 2019-04-23 | 2022-03-08 | Apple Inc. | System call interception for file providers |
US11977173B2 (en) | 2019-11-27 | 2024-05-07 | Rockwell Collins, Inc. | Spoofing and denial of service detection and protection with doppler nulling (spatial awareness) |
US12050279B2 (en) | 2019-11-27 | 2024-07-30 | Rockwell Collins, Inc. | Doppler nulling spatial awareness (DNSA) solutions for non-terrestrial networks |
US11665658B1 (en) | 2021-04-16 | 2023-05-30 | Rockwell Collins, Inc. | System and method for application of doppler corrections for time synchronized transmitter and receiver |
US11726162B2 (en) | 2021-04-16 | 2023-08-15 | Rockwell Collins, Inc. | System and method for neighbor direction and relative velocity determination via doppler nulling techniques |
US12032081B2 (en) | 2021-04-16 | 2024-07-09 | Rockwell Collins, Inc. | System and method for application of doppler corrections for time synchronized transmitter and receiver |
US11737121B2 (en) | 2021-08-20 | 2023-08-22 | Rockwell Collins, Inc. | System and method to compile and distribute spatial awareness information for network |
Also Published As
Publication number | Publication date |
---|---|
US20030012168A1 (en) | 2003-01-16 |
US7161926B2 (en) | 2007-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7161926B2 (en) | Low-latency multi-hop ad hoc wireless network | |
Culler et al. | A network-centric approach to embedded software for tiny devices | |
CA2183802C (en) | Medium access control and air interface subsystem for an indoor wireless atm network | |
US8515354B2 (en) | Method and apparatus for co-location of two radio frequency devices | |
US6519290B1 (en) | Integrated radio frequency interface | |
US7190686B1 (en) | Self configuring high throughput medium access control for wireless networks | |
US20080175207A1 (en) | Wireless network for personal computer human interface devices | |
JP2004503987A (en) | Bluetooth adapter | |
MXPA06010943A (en) | Routing communications in an ad hoc network. | |
US20190223192A1 (en) | Time slot reassignment mechanism for radio access technology coexistence improvement | |
JP2004502342A (en) | Local data transmission via beacons | |
JP2004503990A (en) | Distributed processing system | |
KR20040077974A (en) | Wireless communications arrangements with synchronized packet transmissions | |
JP2004503991A (en) | Distributed bluetooth communication network | |
WO2012056633A1 (en) | Wireless communication device and wireless communication method | |
Ritter et al. | A highly flexible testbed for studies of ad-hoc network behaviour | |
CN116034593A (en) | Data transmission method and communication device applied to short-distance wireless communication | |
Friday | Infrastructure support for adaptive mobile applications | |
Lin et al. | A new BlueRing scatternet topology for Bluetooth with its formation, routing, and maintenance protocols | |
CN116684216B (en) | Communication method, readable medium and electronic equipment | |
US11496159B2 (en) | Mesh-network multimode system with a software definable radio | |
Cassioli et al. | The Bluetooth technology: state of the art and networking aspects | |
Marczynski et al. | A wireless interconnection network for parallel processing | |
Alizai et al. | TinyWifi: Making network protocol evaluation portable across multiple phy-link layers | |
Castro | Embedded Networking Using Thread: Devices, Operating Systems and Iot Programming |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: TRANZEO WIRELESS TECHNOLOGIES, INC., CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SENSORIA CORPORATION;REEL/FRAME:018961/0204 Effective date: 20070131 Owner name: TRANZEO WIRELESS TECHNOLOGIES, INC., CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SENSORIA CORPORATION;REEL/FRAME:018961/0198 Effective date: 20070131 Owner name: SENSORIA CORPORATION, CALIFORNIA Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:HUMMER WINBLAD VENTURE PARTNERS IV, L.P.;REEL/FRAME:018961/0215 Effective date: 20070131 Owner name: SENSORIA CORPORATION, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:HUMMER WINBLAD VENTURE PARTNERS IV, L.P.;REEL/FRAME:018961/0210 Effective date: 20070131 |
|
AS | Assignment |
Owner name: TORONTO DOMINION BANK, THE, CANADA Free format text: SECURITY AGREEMENT;ASSIGNOR:TRANZEO WIRLESS TECHNOLOGIES INC.;REEL/FRAME:020362/0446 Effective date: 20080111 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: THE TORONTO DOMINION BANK, CANADA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:TRANZEO WIRELESS TECHNOLOGIES INC;REEL/FRAME:025788/0943 Effective date: 20080111 |