Patent Application
20140280921
This disclosure generally relates to a device and method for detecting and visualizing a wireless network status in real time.
A building control network for a heating, ventilation, and air conditioning (HVAC) system can include a BACnet using wired and wireless connections, interconnecting multiple BACnet devices (controllers) for controlling various heating, ventilation, and air conditioning devices.
The embodiments disclosed are directed towards a device and method for detecting and visualizing health (e.g., status) of a wireless network and/or network devices connected to the wireless network. Embodiments herein are directed towards detecting the health of the wireless network and/or network devices in real time. Embodiments herein are directed towards displaying a visualization of the wireless network health and/or health of network devices in real time on a computer display (e.g., a workstation, desktop computer, a mobile computer device, etc.). The term “health” is used herein to mean status or condition of a devices and/or a group of devices that are configured to communicate with each other. For example, a health of a device can include a power level of a battery, the device's connectivity condition to other devices in the wireless network, the device's communication link strength to its neighbor devices, etc. For example, a health of a network can include an overall quality of the network topology, redundancy of network connections, etc. The network health information displayed can include, for example, one or more of number of wireless devices, number of low batteries, number of medium batteries, number of good batteries, average transmission time, worst transmission time and address, and number of communication lost devices. The network health information can be accessed via a system controller (SC) and/or a service tool unit (TU).
Referring now to the drawings in which like reference numbers represent corresponding parts throughout.
This disclosure is directed to devices and methods for a method detecting and visualizing a wireless network (e.g., ZigBee) health and/or health of network devices (e.g., wireless connection interface (WCI)) connected to the wireless network. The wireless network health is detected based on one or more link quality indication (LQI) to indicate the strength of the communication link between the network devices. The wireless network health is displayed in a visualization on a computer display in real time or near real time so that the quality of the wireless network communication and health of the network devices can be quickly and easily understood by a user. Some of the embodiments include methods for automatically gathering network information and displaying the network information on a display of a computer, wherein the method includes the computer determining a link quality for one or more nodes connected via the network; the computer analyzing the structure of the network; and the computer displaying the network information on the display of the computer. For example, the computer can display the network information in graphical format using images (e.g., colors, shapes, icons, etc.). For example, the computer can display the network information in text and/or numbers (which can also include various colors, typefaces, fonts, etc.). For example, the computer can display the network information using a combination of graphics, text, and/or numbers.
The wireless network's 10 health information can be gathered by a SC 40 that is connected (via wire or wirelessly) to a coordinator wireless communication interface WCI 41 and WCI 42. The WCI 41 is wirelessly connected to a plurality of network devices 201, 202, 203, 204. The communication speed detected between the WCI 41 and the network device 201 is 20 ms 51. The communication speed detected between the WCI 41 and the network device 202 is 20 ms 52. The communication speed detected between the WCI 41 and the network device 203 is 40 ms 53. The communication speed detected between the WCI 41 and the network device 204 is 50 ms 54. The WCI 42 is wirelessly connected to network device 301. The communication speed detected between the WCI 42 and the network device 301 is 20 ms 61. Further, each of the network devices' 201, 202, 203, 204 battery level can be detected by or reported to the SC 40. Thus, the health information about each of the network devices 201, 202, 203, 204 (e.g., their battery levels) can be visually displayed, as shown by a green bar 211 indicating good battery life for the network device 201, a yellow bar 212 indicating medium (or OK) battery life for the network device 202, a green bar 213 indicating god battery life for network device 203, a red bar 214 indicating poor (or bad) battery life for the network device 204, and a green bar 311 indicating good battery life for device network device 301.
The embodiments herein can detect and/or determine LQI of each network device (e.g., node) in the wireless network. The embodiments are capable or rapidly (e.g., in real time) collect LQIs between the network devices (e.g., nodes) and determine the wireless network's topology (e.g., a snap shot of the network), and/or an overall configuration of the nodes and how the nodes are linked to each other. Based on the LQIs and the network topology, the embodiments herein are directed towards evaluating the wireless network's redundancy. Further, the embodiments herein are directed towards providing a visual display of the network health and other network information to a user. For example, LQI quality can be rated numerically, symbolically, with icons, color, shape or otherwise visually to indicate a gradient or quantized levels of visually representing the quality of the communication link between the nodes (and/or the network). Further, pictograms like arrows between nodes can show asymmetric qualities, which can be further enhanced by use of different colors (e.g., green, yellow, red, etc.) or numerical values to represent quality of the link.
The process of getting the LQI ratings from each node can be done in several ways. In a “ZigBee” standard method, a message is sent to a node requesting its neighbor tables, starting with index “n.” Each response to the message contains two full neighbor table entries, which contains information such as incoming cost, outgoing cost, short addresses, long addresses, age, etc. The querying node then repeats this process, incrementing n by two each time until all table entries are fetched. This process is very slow, and because of the dynamic nature of neighbor tables, this process can fetch a completed table with either missing or duplicated entries (dynamic quality of the table can change between the first and the last read). This method could be made to work, but it would be very slow, and require a lot of extra handling of corner cases and checking of data.
According to an embodiment, a process for retrieving LQI ratings from each node can include requesting neighbor table information from either to a single node or to a larger group of nodes (either broadcast or multicast). When the request is made, the message is processed at the receiving node, which collects basic information for each neighbor table entry in the device in one operation. Then the short address of the neighbor is collected. The incoming cost and the outgoing cost can be collected and/or the LQI for each neighbor can be collected. Only valid entries are retrieved for sending (this is not the case with the ZigBee standard method described above, which can send invalid entries and requires additional processing to weed out (filter) the information based on their status). The resulting message is then sent back to the requester. Upon receipt of the resulting message, the requester should have a complete set of the LQIs from the neighbor table of that device as it existed at the time the target device processed the request. This embodiment of the method is significantly faster than the ZigBee standard method, and the quality of the data is better, because there is no need to look for errors (e.g., missed entries, doubled entries, etc.). Based on the lists of neighbors with LQIs from all the devices in the network, the embodiment can define an undirected graph with nodes corresponding to the network devices and edges between each pair that are neighbors with LQIs in both directions (i.e., LQIs better than some threshold rating). For example, a threshold of 240 (on the LQI scale of 0-255) can be used. As another example, one can decide to include edges where one LQI is above the threshold, especially if the other LQI is above a second threshold. If the resulting graph is not connected (e.g., the LQI is too bad), then the redundancy level is zero. Otherwise, the embodiment can determine a minimal set of nodes that can be removed such that the remaining graph is disconnected. That minimal number of nodes is the redundancy level. Generally, the higher the minimal set of nodes, the better the network health (because a chance that the network can fragment is low). Most data can be communicated to or from the coordinator device. The process includes looking for a minimal set of other nodes for removal, and search for sets smaller than some limit. Searching up to three devices to remove can be done because redundancy levels four or greater are all more than sufficient. This saves time compared to searching for larger sets to remove in a large, highly redundant network.
The term “redundancy” is related to “vertex-connectivity” of the graph (visual representation of the network topology), and a minimal set of nodes to remove is a minimal “vertex cut” or “separating set.” According to Menger's Theorem, the vertex-connectivity is also the minimal number of independent paths from one node to another. Redundant good paths are alternate routes available for the mesh network to use. High redundancy therefore contributes to high reliability.
Accordingly, the process according to an embodiment includes:
Collection of the LQI responses can be done before the source routes. The responses from all the nodes have the side effect of ensuring that the source routes are up to date, and it is better to read the source routes after any updates than to possibly read some out-of-date routes.
Accordingly, the process according to another embodiment includes:
Sending the request as a broadcast increases the speed and can obtain the neighbor information from all devices at nearly a single point in time (as fast as the broadcast can propagate). A delay in the responses can be added (random, or based on short address, or whatever) so that responses would not be lost due to network congestion (e.g., when there are too many devices in the network). LQI for outgoing and incoming can be ranked in hexadecimal, with a range from 0 to ff, or a range of color codes.
In
In
In
Each of the user interfaces 14, 16, 18 includes another group 400 of selectable security measures, wherein the encryption key can be selected to be on 401 or off 402.
With regard to the foregoing description, it is to be understood that changes may be made in detail without departing from the scope of the present invention. It is intended that the specification and depicted embodiment to be considered exemplary only, with a true scope and spirit of the invention being indicated by the broad meaning of the claims.
| Number | Date | Country | |
|---|---|---|---|
| 61799252 | Mar 2013 | US |
