Intermediate functional device and method

A wireless intermediate functional device (IFD) for wireless communication between reduced functional devices in a star topology network having a central coordinator capable of operating as a network access device (NAD), and with fully functional devices in a mesh topology network also capable of operating as a NAD is described. The IFD is a wireless system that executes IEEE 802.15.4 standard compliant operations and operates as an intermediary between non-compatible devices. Various communication and protocol handshaking and management is facilitated by the IFD, allowing end devices in heterogeneous networks to communicate.

BACKGROUND

This disclosure relates generally to the field of communication systems. More particularly, this disclosure relates to an intermediate system for bridging communication between heterogeneous networks.

SUMMARY

In one aspect of the disclosed embodiments, a wireless intermediate functional device (IFD) for wireless communication with reduced functional devices (RFDs) in a star topology network having a central coordinator capable of operating as a network access device (NAD), and with fully functional devices (FFDs) in a mesh topology network also capable of operating as a NAD, comprising: a processor with memory; a radio frequency transceiver front end communicating with the processor; an antenna coupled to the front end; and a power source providing power to the processor and front end; wherein the processor contains computer instructions for executing IEEE 802.15.4 standard compliant operations; discovering a Network Access Device Announcement (NADA) from a NAD; determining whether the NAD is from a star or mesh network; establishing communication with a designated RFD; and forwarding the NADA to the designated RFD.

In another aspect of the disclosed embodiments, a method for wireless communication between RFDs in a star topology network having a central coordinator capable of operating as a NAD, and with FFDs in a mesh topology network also capable of operating as a NAD, is provided, comprising: providing an IFD comprising: a processor with memory; a radio frequency transceiver front end communicating with the processor; an antenna coupled to the front end; and a power source providing power to the processor and front end; into the star topology and mesh topology networks; executing IEEE 802.15.4 standard compliant operations; discovering a NADA from a NAD via the IFD; determining whether the NAD is from a star or mesh network via the IFD; establishing communication with a designated RFD via the IFD; and forwarding the NADA to the designated RFD.

DETAILED DESCRIPTION

The evolution of local network communication systems has primarily been developed for “computer” specific applications, while non-computer related networks have been relegated to develop their own application specific standards. A consequence of these separate paths is that different communication systems for different platforms have developed, to where there is no easy way to make these heterogeneous systems and their respective devices communicate with each other. Efforts have been expended by the various communities to bring harmony to the communication world, however, such efforts have not been fully integrated into non-computer based networks, or there are still areas of incompatibility.

One attempt to bring some level of harmony is found in the Institute of Electrical and Electronics Engineers (IEEE) Standard 802.15.4, (incorporated herein by reference in its entirety). This standard defines the Physical (Phy) and Medium Access Control (MAC) sub-layer specifications for low data rate wireless personal area network (LR-WPAN) connectivity for fixed, portable and moving devices with low battery consumption requirements, generally operating in wireless (also known as, Radio Frequency (RF)) ranges up to ˜100 meters. These systems can be used for setting up inexpensive wireless networks that can be used for industrial control, embedded sensing, medical data collection, building and home automation, and so forth. This standard supports LR-WPANs that may operate in either of two topologies: star topology and peer-to-peer topology (sometimes referred to as “mesh” topology).

As shown in the related art diagram ofFIG. 1A, a star topology communication is established between multiple end devices2and a single central controller4called the Personal Area Network (PAN) coordinator. End devices2typically are battery-powered, conduct some associated application(s), and are either the initiation or termination point of network communications. The PAN coordinator4is usually mains-powered, may also run an application(s), initiates, terminates and routes communications around the network, and acts as the primary controller of the PAN. All communications in a star network are conducted as a single hop between the end device2and the PAN coordinator4. In most embodiments, the star network, either via the PAN coordinator4or end device2can communicate to an external communication device/system6, via fixed or wireless channel8. Typically, such communication is dependent on the particular capabilities of the external system6and channel8. For example, the external communication system6may be a facsimile device.

A related art peer-to-peer topology is shown inFIG. 1B, where wireless end devices3communicate directly with each other as long as they are in range. Peer-to-peer topology allows for complex network formations that can be ad-hoc, self-organizing and self-healing. This topology allows communications to occur using multiple hops to route messages from any device3to any other device3on the network. And, in most systems, the peer-to-peer network can communicate to an external communication device/system5, via wired or wireless channel7, using any one of the end devices3. These multiple hopping functions are not detailed by the IEEE 802.15.4 standard described above, but network formation can be added at higher layers by commercial products. One such approach is found in U.S. Pat. No. 7,139,239, titled “Self-healing control network for building automation systems,” by Norman R. McFarland, the contents of which are expressly incorporated by reference herein.

As is apparent, a primary hardware distinction between the end devices3of the peer-to-peer network and the end devices2used in star topologies, is that the peer-to-peer end devices3are usually configured with more advanced communication controlling and processing capabilities, allowing them to act as a controller or PAN coordinator, in some instances. Consequently, the end devices2used in star topologies are often referred to as RFDs.

RFDs conserve power by eliminating all internal coordinator functions and rely on an external coordinator4to manage the PAN. RFDs by design know the address of the PAN coordinator4in advance of data exchange. As alluded above, end devices3in peer-to-peer networks are more autonomous, often referred to as FFDs and provide their own coordinator functions managing the PAN in concert with all other FFDs in their operational range. FFDs identify themselves when accessing or establishing a network and exchange coordinator functions as necessary. RFDs used in star topologies and FFDs for peer-to-peer topologies cannot be intermingled and cannot function properly with each other, due to their hardware incompatibilities.

Pursuant to the Department of Homeland Security's (DHS) decision to adopt the IEEE Standard 802.15.4 standard to provide communications for monitoring the security of cargo conveyances moving in and out of U.S. shipping ports, a need has arisen for the ability to co-mingle end devices operating in star and peer-to-peer topologies. The initial implementation of these Conveyance Security Device (CSD) systems is stated to be accomplished by employing star topology at a limited number fixed reader points. As such, all end devices for communications that are placed on conveyances (containers) will be RFDs and the mains-powered readers will act as PAN coordinators.

Eventually, to facilitate continuous monitoring of containers in shipping yards (for both commercial and security purposes), DHS has stated an intent to migrate to an Advanced Container Security Device (ACSD) system that can employ peer-to-peer communications while using the existing reader (PAN coordinator) infrastructure. However, during the transition period, ACSD and CSD systems employing both topologies will need to be co-mingled in the commercial shipping environment.

In order to facilitate the interoperability of ACSD and CSD systems during this transition period, a bridging IFD is needed to allow self-organized, ad-hoc communications between RFDs and FFDs, operating in mixed topologies. As of yet, no such hardware device or system for accomplishing star-mesh communication is available, wherein aspects of such a needed hardware device/system, in the form of an IFD are described below. In concert with a hardware device such as the IFD described herein, communication and protocol interoperability within these heterogeneous nodes are addressed by detailing various exemplary processes for managing connection and message transfer between devices.

While the IFD's role is initially described in the context of facilitating the interoperability of ACSD and CSD systems, the adoption of the IEEE 802.15.4 standard can give rise to many other possible applications. For example, the ZigBee® Alliance is a consortium developed to facilitate and support numerous applications based on the IEEE 802.15.4 standard, such as for home automation and home security networks, medical monitoring sensor networks, environmental sensor networks, games and consumer electronics networks. Accordingly, the exemplary IFD described herein can be used as a transition device for any of the aforementioned types of networks, as well as other applicable networks, when there is a need to utilize both RFD and FFD types of end devices in the same network.

FIG. 2is an illustration20of a system level implementation of an exemplary IFD11, comprising a low-powered digital radio system that is IEEE Standard 802.15.4 compliant. The exemplary IFD11contains an antenna13, with an on-board microprocessor/RF unit15with Firmware17and Software19, that facilitates communication protocol procedures according to IEEE 802.15.4. The exemplary IFD11can be a fixed system (base station) or a portable system, being handheld or carried, depending on the form factor used and can be designed for a communication range of up to approximately 100 meters.

The IFD11can be either mains14or battery12powered. Other forms of power can be utilized, non-limiting examples being solar, chemical, and so forth. The exemplary IFD11can be designed to be an autonomous unit (wireless) that can be located in and around an area where a mixed population of IEEE 802.15.4 compliant devices are operating. For example, communication with RFDs within a star network22and FFDs within a peer-to-peer network24are shown inFIG. 2. The IFD11may also communicate with other IFDs11b, and also with server(s) located in a cloud26or separately dedicated28.

As with any modern wireless device, the exemplary IFD11may include complimentary subsystems (not shown) that allow for wireless media not defined in IEEE Standard 802.15.4, such as those supporting cellular or satellite communications, as well as Global Positioning System (GPS) capabilities, for example.

The exemplary IFD11may use any method of network discovery provided by the IEEE 802.15.4 standard to alert, address and exchange data/control frames with RFDs operating within a star-topology mode. The IFD11should also be capable of listening for discovery requests (a non-limiting example being a beacon request) or discovery data-frame broadcasts from end devices operating in the peer-to-peer topology mode; and to set up both ad-hoc and permanent networks to pass data frames both to and from FFDs. Using a combination of firmware and software19, the exemplary IFD11should be autonomously capable of determining which type of end device it is currently communicating with, by analyzing a combination of information in the broadcast frame headers or content. The IFD11is also capable of functioning as a PAN coordinator and has the functionality to conduct data exchanges on all channels specified in the IEEE 802.15.4 specification. Aspects of such implementations are described below.

FIG. 3is an illustration of a hardware block configuration that may be utilized in an exemplary IFD30. A single antenna design is depicted inFIG. 3, with a power source31, memory32, antenna33, RF transceiver front end34, microprocessor35with input/output36to process all the collected data, and IEEE 805.15.4 module37. The module37can be formed from a System-in-a-Package (SiP) or comprised of a number of integrated circuits enclosed in a single package or module. The form may be that of a set of vertically stacked silicon chips. The module37constituted by the SiP performs most of the IEEE 805.15.4 functions of the IFD30. The IFD30also contains of a programmable integrated circuit device, such as a Field Programmable Gate Array (FPGA)38. The FPGA38is a semiconductor device containing programmable logic components also referred to as logic blocks with programmable interconnections that can route logical decisions in many different directions. Logic blocks can be programmed to perform simple logical decisions such as logic gates or very complex functions such as decoders and mathematical functions. Logic blocks may also include memory elements. According to capabilities and design preference, the FPGA38and the microprocessor35may be configured as a single unit, as well as with the memory32. Therefore, the microprocessor35may comprise the FPGA38, SiP37and memory32into a single die. Additionally, the microprocessor35may operate as the RF front end34controller.

The microprocessor35, memory32, FPGA38, or SiP37individually or in combination, contain executable instructions (e.g., code) for facilitating communication between devices within a star topology and mesh topology network, in accordance with (some) procedures dictated by IEEE 805.15.4, as further detailed below.

FIG. 4is an illustration of another hardware block configuration in an exemplary IFD40, for multiple frequency/mode operation. The exemplary IFD40is comprised of a power source41, memory device42, two antennas43aand43b, RF transceiver front end44, microprocessor45with I/O46to process all the collected data, two IEEE 805.15.4 SiP devices47aand47b, and two FPGAs48aand48b. The exemplary IFD40is similar in capabilities to the exemplary IFD30ofFIG. 3, with the added capability to process multiple (e.g., two or more) frequencies/modes from different IFDs or different topologies. Accordingly, modifications as discussed in reference to the embodiment ofFIG. 3may be equally applicable to the embodiment ofFIG. 4.

For example, advances in hardware and radio devices may obviate the need for independent SiPs or independent antennas, etc. That is, based on the design and hardware capabilities chosen, for example, by using multi-frequency/processing RF integrated circuit devices, the exemplary IFD40may be capable of multiple frequencies/modes of operation, whilst only utilizing a single hardware system and/or antenna. Accordingly, modifications, improvements and other changes to the type and number of subsystems may be contemplated without departing from the spirit and scope of this disclosure.

By formulating a hardware implementation of IEEE 802.15.4 into a wireless device, the exemplary IFD provides a bridge between two currently incompatible LR-WPAN topologies for IEEE 802.15.4 compliant systems. The application of IEEE 802.15.4 to inventory tracking has created a unique need for the exemplary embodiments described herein, not previously developed under wireless technologies such as Bluetooth (IEEE 802.15.1) and WiFi (IEEE 802.11.x). While described in the context of the DHS's unique need for cargo security based on the IEEE 802.15.4 standard, the exemplary IFD can be transferred to other routing standards including, but not limited to, IEEE 802.11.x or 802.15.x systems or with perhaps different topologies, but with the same need to allow interoperability of different types of end devices.

Accordingly, other standards may be implemented and other (non-DHS) applications may be contemplated. For example, the IFD system may be applied to home appliances networks, home security networks, medical monitoring sensor networks, environmental sensor networks, consumer electronics networks and toys and games networks, to name a few. Additionally, other types of wireless networks may include static networks used for inventory to verify possession of stored materials such secret documents, weapons, hazardous materials, radioactive materials, etc., that need to be inventoried on a regular basis in which network topology may not change for long periods of time.

The exemplary IFD system can operate at a single frequency or have the ability to operate at different frequencies simultaneously. The antennas utilized by the exemplary IFD can be fixed in length and/or shape or be reconfigurable. The same antenna could be used to operate at different frequencies when reconfigured. Alternatively, more than one antenna can be used, each operating at a different frequency. An additional alternative would be to replace the FPGA with a semi-custom device such as an Application Specific Integrated Circuit (ASIC) or a custom designed integrated circuit device. The ASIC or custom integrated circuit hereby mentioned would be used to run the logic of the exemplary IFD.

IFD Messaging

A successful implementation of the exemplary IFD requires proper message processing. There are three basic types of messages that IFDs must recognize, parse and route, in the context of transmission control protocol/internet protocol (TCP/IP) as described in the followingFIGS. 5-7. The IFD is understood to function as a topology bridge between RFDs and FFDs, where FFDs may be part of a mesh network. As such, the IFD must recognize when NAD coverage exists and whether that coverage is provided by a PAN under a star topology or FFD in a mesh topology. It is understood that in mesh topology, the NAD coverage is provided at the egress node of the mesh network. End-to-end acknowledgements (ACKs) between the Data Centers (DCs) and RFDs are understood to be employed for Command and Status Message exchanges. The connections between the NADs and DCs depicted below is under standard TCP/IP and, as such, is not described in great detail. End-to-end (ACKs) are employed for Command and Status Message exchanges.

FIG. 5is a network discovery ladder diagram depicting the communication connections between the NAD52to the end sensor56(e.g., RFD), via the IFD54mediator. As a prerequisite, data flow is depicted using a Passive Scan network discovery using a NADA from the NAD52. Active scan network discovery is not depicted, as any active scan implemented for mesh routing is assumed to implement clear channel assessment (CCA) in some form, and does not interfere with the passive scan method described herein. All NADs52perform CCA before transmitting a NADA (or any other) data frame. Accordingly, passive network discovery with optimal battery conservation can be achieved.

In discovery, the IFD and sensor (RFD) must listen for NADAs for a specified period of time (e.g., at least 20 milliseconds each second when not in coverage but in many implementations may be as regarded as State Aware and choose to not to respond to every NADA message once coverage is established). Upon discovery, protocols established by TCP/IP can be followed.

FIG. 6is a message ladder diagram60between the respective devices. As a prerequisite, network discovery is understood to be complete. All status messages flow from the sensor (e.g., RFD) to the DC, and that all NADs, IFDs and sensors perform clear channel assessment before transmitting. It is also understood that the ladder diagrams described herein are not to time scale, recognizing that the duration of the Device Status message transmission is small compared to the NADA message repetition interval. The MAC Layer ACK frame can be sent within the time duration as specified by IEEE Standard 802.15.4. The message ladder diagram60is based on standard TCP/IP and, as such, is not described in great detail.

FIG. 7is a command message ladder diagram70between the respective devices. As a prerequisite, network discovery is understood to be complete. All command messages flow from the DC to the Sensor (e.g., RFD) and all NADs, IFDs and sensors perform clear channel assessment before transmitting. It is understood that the DC knows which NAD to use based on the Device Status message sent after Network Discovery. Optionally, the DC may use the last known NAD. The command message ladder diagram70is based on standard TCP/IP and, as such, is not described in great detail.

Having laid a foundation for network discovery and messaging utilizing an exemplary IFD, additional details and modifications to the above paradigms and other aspects of communication control are described. For example, the exemplary IFD can selectively scan the RF spectrum for network discovery. The exemplary IFDs do not need to scan all available RF channels.

As shown in the flow chart ofFIG. 8, an exemplary IFD process80can start81and passively scan83using a defined subset of IEEE 802.15.x Standard's RF channels to detect NADAs. A specific subset of channels can be defined. These channels can be selected to co-exist with co-located WiFi networks, if present. The scanned channel(s) can be evaluated for signal strength or another metric85and if a candidate channel(s) among multiple NADs is acceptable or considered “best,” the exemplary process80via the IFD can relay an encrypted data frame message88destined for either its mated end device or a data center that may require retransmissions across LANs and WANs. Upon relay or transmission, the exemplary process80may terminate89. If the candidate channel(s) metric is unsatisfactory, the exemplary process80can rescan either the originally scanned channel(s) or seek other channel(s), whereas the above steps are repeated. Thus, utilizing such an approach, management messages, including spontaneous non-compliant messages can be ignored in total.

As shown inFIG. 9, another aspect of the exemplary IFD91can be devised wherein the IFD91, instead of the end device92, can poll for possible waiting data. The exemplary IFD(s)91can receive the NADs' NADA messages93(as above) during network discovery and, thereafter according to a battery conservation (wake-up) timing choice, illustrated here as via link95. Each NADA93can contain a list of end device identity codes, for devices that have undelivered messages (message waiting) at a NAD97. Multiple NADs may hold the same message, to support end device mobility. The IFD91relays via bi-directional link98this information to its mated end device92which passively detects its (end device) identity in the list in the NADA93. On detecting a message waiting for a given end device92, that end device92transmits a request message to the chosen NAD97to cause the waiting message content to be transmitted via bidirectional link99, which may be sent via bidirectional link99to the IFD91and forwarded to the end device92, or directly sent from the chosen NAD97to the end device92. In this configuration, polling to inquire about waiting messages is eliminated.

In another aspect, transmission time slot requests can be configured. For example, the NADs with NADA message content enable exemplary IFDs to use the IEEE's 802.15.4 Standard's carrier sense multiple access with collision avoidance (CSMA/CA) for medium access rather than time division multiple access (TDMA). Precise message latency management is, thus not required, as is the purpose of TDMA time slots. The numerous undesired management messages for time slot acquisition and renewal of existing systems are, thus eliminated to support, for example, battery powered cargo security applications.

Additionally, the exemplary IFDs can respond to the NADA message of the NADs instead of the IEEE 802.15.4 Standard's beacons, that is, custom beacon message content can be facilitated. For example, CSMA/CA coordinated NADA messages can be used as described above. The NADA messages can be ordinary user data messages. Commonly available commercial products need not expect beacon payload content be present. Therefore, no alteration of the IEEE 802.15.4 Standards-compliant commercial products' firmware is needed in this configuration. This eliminates the risks and warranty or life cycle support issues arising from altered commercial products used as an element of a larger device. In this implementation, network existence broadcast messages can be achieved without frame collisions.

The exemplary IFDs can also be implemented so that network existence broadcast messages are supplied with system security. The IEEE 802.15.4 Standard addresses only layer2encryption with a shared key mechanism. As illustrated inFIG. 10, the NAD devices102and overall end to end system design enables end to end encrypted messages to be relayed by the IFDs104to end devices106and the destination data center (not shown), using encryption (for example, layer3encryption), independent of all types and sorts of transport networks in the LAN/WAN paths. The exemplary IFD supports the NAD's NADA message content that includes a code to indicate which undisclosed encryption key is required for communicating with the data center affiliated with a given NAD. This enables a key unique to each end device106mated to the IFD104so that compromise of an encryption key does not affect other end devices' security.

Another feature of the exemplary IFD system is that each NAD's NADA message can contain a definition of the time until the next (future) NADA will be transmitted. IFDs can use this information to select a power conservation cycle time. Thus, the interval may vary from site to site and may vary in time, according to needs such as optimizing battery power consumption strategies, but with interoperability among products and suppliers that use different strategies.

FIG. 11is a flow chart illustrating an exemplary process110for message exchange and pairing with the exemplary IFD. Prior to initiation of the exemplary process110, the exemplary IFD is provided with the MAC Address of one or more sensors acting as end devices (for example, RFDs in a star topology). This exemplary pairing may be hard-coded into the IFD firmware or programmable via the user interface.

The exemplary process110begins with initialization111, where the IFD establishes the network discovery parameters and mesh network egress path. Next, channel selection112is performed. The IFD may automatically cycle through all the channels (16 channels are defined in the IEEE 802.15.4 standard) or restrict itself to one or more channels with a hierarchy defined by the particulars defined by a designated mesh routing implementation. After channel selection112, the exemplary process110proceeds to network discovery113, where the IFD conducts network discovery as defined by routing implementation requirements per IEEE 802.15.4. After network discovery113, the IFD proceeds to listen for a request/response114. Upon reception of a compliant response (per initialization parameters), an interrupt115will occur where the request is granted. If no compliant response is received, the exemplary process110cycles back to listening stage114.

Upon granting the request, a response decision116is made, determining whether the request is for a new node requesting joining117or if the request is for control/data information transfer118. If the requesting entity is a new node117, then the exemplary process110proceeds to assign a PAN ID123to the new node. The process for joining the node PAN IDs to current PAN IDs already joined is defined in a mesh routing implementation and/or under the IEEE 802.15.4 standard. Subsequent to the assignment of the PAN ID123, any further communication from this joined node is understood to be for control/data information transfer. Therefore, the exemplary process110forwards the communication to the control/data information transfer module118.

From the control/data information transfer module118, a function decision119is made regarding whether to forward the communication (e.g., message) to forwarding module120for forwarding to an egress path to mesh devices (as determined through network discovery113module). If there is no egress path readily available (e.g., timeout, out-of-range, etc.), the function decision module119stores the communication/message121until an egress path is available. When the egress path becomes available, the exemplary process110proceeds to forward the stored message121to the forwarding120module. After forwarding has been accomplished, the exemplary process110returns to listen for the next request/response114. The exemplary process110loops until an internal or external command to abort/exit the process is executed (not shown).

In view of the above examples, an exemplary IFD can be devised to provide communication between star and mesh topologies, utilizing IEEE 802.15.4 and TCP/IP protocols, thereby enabling communication and tracking capabilities previously unknown in the art. Accordingly, an efficient and effective means for communicating between non-compatible, pre-defined topologies can be realized. While the above FIGS. detail various aspects of the exemplary systems and methods, it is understood that one of ordinary skill in the art may make modifications and changes to the various elements and features, without departing from the spirit and scope herein. For example, advances in integrated circuit device design may enable the described SiP hardware to be implemented on the FPGA hardware. Similarly, the antenna switches maybe optional, the antennas being frequency sensitive, and so forth.

Accordingly, it is understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.