Network performance detection
The method enhances network performance detection in utility metering systems by storing and analyzing message frequency data in a performance summary memory, addressing storage limitations and cost inefficiencies in existing systems.
Patent Information
- Application Number
- JP2026501299
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-07-12
- Filing Date
- 2024-07-10
- Publication Date
- 2026-08-26
AI Technical Summary
Existing utility metering systems face challenges in determining network performance issues due to limited storage capacity and inefficient data transmission, especially in congested networks, which results in insufficient data for identifying network problems and high costs in cellular networks.
A method involving message exchange between root nodes and metering devices, with log entries stored in live and backup memories, followed by copying to a performance summary memory for continuous frequency determination and problem detection, using predicted thresholds to identify network performance issues.
This method allows for efficient storage and analysis of network performance data, minimizing storage requirements and costs while effectively identifying network problems in metering devices.
Smart Images
Figure 2026528882000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a method for determining the network performance of one or more metering devices that perform data communication with a root node.
Background Art
[0002] In recent years, utility metering systems generally include a plurality of metering devices that measure the consumption of utilities such as electricity, gas, and water. These metering devices transmit consumption data, status data, and other data of their respective utilities to a head-end system via a network. These data are used for billing, maintenance, and other purposes.
[0003] FIG. 1 shows the network topology of a typical utility metering system 100. The utility metering system 100 includes a head-end system 102, a backhaul network 104, and a plurality of root nodes (also called collectors) 106a to 106n. Communication between the head-end system 102 and the plurality of root nodes 106a to 106n is realized by the backhaul network 104. The backhaul network 104 may be a wired network (e.g., Ethernet or optical fiber cable) or a wireless network (e.g., cellular network).
[0004] Each root node 106a-106n is configured to communicate data with one or more nodes (also called endpoints) and performs operations such as node management, data collection from nodes, and transmission of data received from nodes to the headend system 102. These nodes may include utility metering devices. In the example in Figure 1, root node 106a communicates data with nodes 108a-108n, root node 106b communicates with nodes 110a-110n, and root node 106n communicates with nodes 112a-112n. One or more nodes may be considered parent nodes, and other nodes may communicate with root nodes 106a-106n via these parent nodes. In the example in Figure 1, nodes 108a, 110a, and 112a are parent nodes. The root nodes 106a-106n aggregate the data received from their respective nodes 108a-108n, 110a-110n, and 112a-112n and transmit it to the headend system 102. Each root node 106a-106n may also be a personal area network (PAN) coordinator, gateway, or other device capable of communicating with the headend system 102.
[0005] The headend system 102 functions as a central processing system that receives data from root nodes 106a to 106n. The headend system 102, or another system associated with the utility company, can process or analyze the collected data for purposes such as billing, performance analysis, and troubleshooting.
[0006] Each root node 106a-106n not only receives utility metric data from its corresponding nodes 108a-108n, 110a-110n, and 112a-112n, but may also receive messages from these nodes. Typically, log entries indicating received messages are continuously recorded in the live log file / memory of each root node 106a-106n, and the log "rolls" when the live log file reaches a predetermined memory size (e.g., 5MB). That is, the data recorded in the live log file / memory is copied to a backup log file / memory, and any subsequently received data is recorded in the live log file / memory.
[0007] Root nodes 106a-106n are typically configured to continuously log data, and at least some of this data is used to determine whether a particular node is experiencing network performance issues. However, in congested networks, the live log file / memory may roll every four minutes. In such networks, the log entry data accessible at any given time is only about eight minutes (four minutes of live log + four minutes of backup log). Therefore, in many cases, this is not enough data to determine whether nodes 108a-108n, 110a-110n, and 112a-112n are experiencing network performance issues, or to identify the cause of those issues.
[0008] Furthermore, since the storage capacity of root nodes 106a-106n is generally limited, it is undesirable to store all log entries logged by each root node in the local root node memory. Also, continuously sending 5MB of data every 4 minutes from root nodes 106a-106n to the headend system 102 via the backhaul network 104 (as in the example above) is inefficient and costly, especially if the backhaul network is a cellular network.
[0009] Therefore, there is a need for a more appropriate method to determine network performance issues in utility meters. [Overview of the project]
[0010] A first aspect of the present invention provides a method for determining network performance when data is communicated between a root node and one or more metering devices configured to measure utility consumption. The method includes the following steps: an exchange step of exchanging messages between the root node and the one or more metering devices, wherein the exchange of messages includes sending messages from the root node to the one or more metering devices and receiving messages from the one or more metering devices to the root node; storing log entries in the live log memory of the root node indicating the messages exchanged between the root node and the one or more metering devices; a copying step of sequentially copying the log entries stored in the live log memory to the backup log memory of the root node when the number of log entries stored in the live log memory reaches a predetermined storage threshold, wherein log entries previously stored in the backup log memory are overwritten by the copy; and deleting the log entries stored in the live log memory after the log entries have been copied to the backup log memory. A step of continuously determining the frequency of messages exchanged between the root node and the one or more metering devices using the log entries stored in the backup log memory after the log entries have been copied to the backup log memory and before the log entries in the backup log memory are overwritten. A step of continuously storing data indicating the determined frequency of messages exchanged between the root node and the one or more metering devices in the root node's performance summary memory. And a step of determining whether one or more of the one or more metering devices are experiencing network performance problems based on the data indicating the frequency of messages.
[0011] The data indicating the determined message frequency may include the number of messages exchanged between the root node and the one or more metering devices and the period during which those messages were exchanged.
[0012] Optionally, the step of determining whether one or more of the one or more metering devices are experiencing network performance problems may include comparing data indicating the frequency of messages exchanged between the root node and the one or more metering devices with a predicted message threshold indicating the frequency of messages expected to be exchanged between the root node and the one or more metering devices, and determining that a network performance problem exists if the frequency of messages exchanged between the root node and the one or more metering devices is outside the range of the predicted message threshold.
[0013] The system may optionally further include the step of having the root node's transmitting unit send an alert to an external device indicating a network performance problem if it is determined that a network performance problem exists.
[0014] Optionally, the performance summary memory may include a performance profile for each of the one or more metering devices indicating the frequency of messages exchanged between the metering device and the root node.
[0015] Optionally, the method may further include the step of comparing the frequency of messages exchanged between each metering device and the root node with a predicted message threshold indicating the frequency of messages expected to be exchanged between the metering device and the root node, and determining that a network performance problem exists if the frequency of messages exchanged between each metering device and the root node falls outside the range of the predicted message threshold.
[0016] Optionally, the message may include one or more message types, such as network maintenance messages, authentication messages, and application messages.
[0017] Optionally, the method may further include the steps of extracting a subset of log entries stored in the backup log memory according to parameters contained in a configuration file, and storing the subset of log entries in the performance data memory of the root node.
[0018] Optionally, if it is determined that a network performance problem exists, log entries may be extracted from the backup log memory and stored in the performance data memory.
[0019] Optionally, the process may further include the step of sending a subset of the extracted log entries to an external device.
[0020] Optionally, the step of extracting a subset of log entries may include the steps of searching the backup log memory for log entries related to at least one message type defined by the configuration file, and extracting one or more log entries related to that message type from the backup log memory.
[0021] Optionally, the method may further include the step of extracting a predetermined number of log entries recorded before and / or after one or more log entries associated with at least one message type from the backup log memory and storing them in the performance data memory. The predetermined number may be defined by the configuration file.
[0022] Optionally, the predetermined number of log entries may include log entries that include timestamps immediately preceding and / or immediately following the timestamp of an extracted log entry associated with at least one message type.
[0023] Optionally, the configuration file may define a search string that indicates one or more message types to be extracted.
[0024] Optionally, the search string may identify a particular one of the one or more metering devices such that the message type to be extracted is related to messages received from the particular metering device.
[0025] Optionally, the method may further include updating the configuration file to define different subsets of log entries to be extracted from the backup log memory, and applying the updated configuration file to the root node to extract the different subsets of log entries from the backup log memory.
[0026] Optionally, the method may further include storing the different extracted subsets of log entries in the performance data memory and transmitting the subsets of log entries to an external device.
Brief Description of the Drawings
[0027] [Figure 1] FIG. 1 shows the network topology of a typical utility metering system. [Figure 2] FIG. 2 shows a schematic diagram of an exemplary root node. [Figure 3] FIG. 3 is a flowchart showing an exemplary method for determining the network performance of one or more metering devices associated with a root node. [Figure 4] FIG. 4 shows a schematic diagram of an exemplary performance summary memory. [Figure 5] FIG. 5 is a flowchart showing an exemplary method for extracting a subset of log entries from a backup log memory.
Modes for Carrying Out the Invention
[0028] This specification outlines a method for extracting network performance data from the live log memory and / or backup log memory of a root node (or collector) before the data is overwritten or deleted, and for using this data to determine whether one or more metric devices communicating with the root node are experiencing network performance problems.
[0029] In an exemplary manner, log entries are stored sequentially in the root node's live log memory. Log entries typically indicate messages received by the root node from each associated metering device, or messages sent from the root node to each metering device. A log entry may include one or more of the following: the type and / or subtype of the received / sent message, the time the message was received / sent, the identification information of the metering device that received / sent the message, and part or all of the message content. Furthermore, a log entry may include information indicating whether the message is for informational purposes or indicates a warning or error condition. A log entry may also include information indicating the code path followed when the message was processed after it was received and before it was sent.
[0030] When the data stored in live log memory reaches a predetermined storage threshold, the log "rolls," and the log entries stored in live log memory are copied to backup log memory and then deleted from live log memory. This allows subsequent received data to be stored in live log memory. Log entries that were stored in backup log memory before the copy are overwritten by the copied log entries. Therefore, log entries stored in live log memory and backup log memory are only available for a finite period of time.
[0031] In the exemplary method, the frequency of data or messages exchanged between the root node and one or more associated metric devices is determined based on log entries stored in backup log memory. This determination may be performed sequentially each time a log entry is copied from live log memory to backup log memory, and before any log entries in backup log memory are overwritten. In the exemplary method, data indicating the frequency of data or messages exchanged between the root node and one or more metric devices is stored sequentially in the root node's performance summary memory.
[0032] In an exemplary configuration, the performance summary memory includes a performance profile for each of the one or more associated metric devices. Each performance profile shows the number of messages the metric device received from the root node, the number of messages the metric device sent to the root node, and the relevant period covered by the performance profile (i.e., the period during which the number of received and / or sent messages was monitored). The number of received and / or sent messages shown in each performance profile may be compared to a predicted message threshold. If the number of received and / or sent messages for one or more associated metric devices falls outside the range of the predicted message threshold, an alert may be generated indicating that a network performance problem is occurring.
[0033] Since the performance summary memory is not subject to the same role processing described above, the data stored in the performance summary memory is not overwritten. The performance summary memory stores only the number or frequency of messages exchanged between the root node and each of the one or more associated metric devices, and the duration of those message exchanges as shown in the performance profile for each metric device; therefore, the additional storage capacity required for each root node is minimal.
[0034] Figure 2 shows an exemplary root node (or collector) 200. The root node 200 can communicate data with one or more associated weighing devices and / or headend systems 102, as described in Figure 1.
[0035] The root node 200 may include a receiving unit 202 and / or a transmitting unit 204. The receiving unit 202 and / or the transmitting unit 204 are configured to communicate with and transmit data to other entities and / or functions in the communication network, such as user equipment, servers / hubs, weighing devices, and headend systems.
[0036] The root node 200 may further include memory 206 and a processor 208. The root node 200 may also include live log memory 210, backup log memory 212, performance summary memory 214, and performance data memory 215. These memories may include non-volatile memory and / or volatile memory. Memory 206 may store a computer program 216. The computer program 216 may include instructions for performing the methods disclosed herein. The computer program 216 may be stored in a non-temporary computer-readable medium 218 and loaded from there into memory 206.
[0037] The root node 200 may further include a controller 220, a storage threshold monitor 222, a log entry copy unit 224, a message frequency determination unit 226, a network performance problem detection unit 228, and a log entry extraction unit 230. The processor 208 is configured by a computer program 216 to execute one or more functions of the controller 220, the storage threshold monitor 222, the log entry copy unit 224, the message frequency determination unit 226, the network performance problem detection unit 228, and the log entry extraction unit 230.
[0038] Each component of the receiving unit 202, transmitting unit 204, memory 206, processor 208, live log memory 210, backup log memory 212, performance summary memory 214, performance data memory 215, controller 220, storage threshold monitor 222, log entry copy unit 224, message frequency determination unit 226, network performance problem detection unit 228, and log entry extraction unit 230 may communicate data with other components 202, 204, 206, 208, 210, 212, 214, 215, 220, 222, 224, 226, 228, and 230 of the root node 200. The root node 200 may be implemented as a combination of computer hardware and software. Memory 206 stores various programs / executable files executed by the processor 208 and also functions as a storage area for necessary data.
[0039] As described above, during use, the root node 200 can communicate data with one or more nodes, including metering devices. These metering devices are installed at the customer's facility and configured to measure utilities (e.g., electricity, water, gas) consumed by end users. In this specification, “root node” refers to a device for routing messages within a utility metering system, as well as a device for routing messages between the utility metering system and other networks / systems. For example, the root node 200 may route messages within a wireless mesh network including multiple nodes, including metering devices, and a headend system, as shown in Figure 1. (Here, the headend system may form a separate network from the wireless network including the metering devices.) The utility metering system may include multiple root nodes 200, each root node forming a personal area network (PAN). Multiple PANs collectively constitute the utility metering system. A metering device is referred to as a metering device “associated” with a particular root node 200 if it belongs to the PAN of that root node 200.
[0040] The root node 200 exchanges messages with one or more associated metering devices. That is, the root node 200 can receive messages from and send messages to associated metering devices. As can be understood, the root node 200 can receive a wide variety of messages, commands, and other data from associated metering devices, and can also send a wide variety of messages, commands, and other data to associated metering devices and / or headend systems. The inventors have found that messages exchanged between the root node 200 and associated metering devices can be used to determine whether the metering device is experiencing network performance problems. In particular, they have found that the frequency of messages exchanged between the root node 200 and associated metering devices can be used to determine network performance problems.
[0041] Messages exchanged between the root node 200 and one or more associated metering devices may include one or more of the following: authentication messages, network maintenance messages, and application messages.
[0042] Authentication messages are network authentication messages that determine whether a particular weighing device is authorized to join the utility weighing system network, and are exchanged between the root node 200 and the weighing devices and / or headend systems associated with it. Authentication messages may include, for example, PANA (Protocol Carrying Authentication for Network Access) messages. If a weighing device attempting to join the network is not authenticated, access to the network is denied, indicating a potential problem (or an attempt to join by an unauthorized device) on the part of the weighing device and / or system.
[0043] Network maintenance messages are exchanged between the root node 200 and the associated metering devices and / or headend systems and relate to the operational network state of the network and / or associated metering devices. Network maintenance messages may be scheduled or unscheduled. Network maintenance messages may include one or more Registration / Response messages, DAO / DAO-ACK messages, and ICMP messages.
[0044] The Response message contains registration information indicating when and how the associated weighing device should send and / or receive a specific message. The Response message is sent from the root node 200 to the associated weighing device (either directly or via other associated weighing devices) after the associated weighing device has been successfully authenticated and authorized to participate in the utility weighing system network.
[0045] The Registration message indicates that the associated weighing device has achieved time synchronization with the network. The Registration message is sent from each associated weighing device to the root node 200 when it joins the network. It is also sent when the associated weighing device rejoins the network (for example, when the associated weighing device loses time synchronization and needs to rejoin the network).
[0046] DAO messages are sent from the associated weighing device to the root node 200, indicating the parent node selected by that weighing device. Each associated weighing device can have one or more other nodes or devices in the network as parents, and these parent nodes define the message route between the weighing device and the root node 200. That is, the message route between the associated weighing device and the root node 200 is formed through one or more parent nodes / devices (in Figure 1, nodes 108a, 110a, and 112a are examples of parent nodes). Each associated weighing device may be configured to send scheduled DAO messages to the root node 200. Periodically sent DAO messages can be used as a "check-in" for the associated weighing device. In addition, if a change in the parent node is required due to a change in network conditions, the associated weighing device may also send an unscheduled DAO message.
[0047] The DAO-ACK message is sent from root node 200 to the associated weighing device to confirm that the DAO message was received at root node 200.
[0048] ICMP (Internet Control Message Protocol) messages are messages received by the root node 200 in response to errors in IP operations. For example, they are received in response to routing errors, address resolution errors, and unreachable destinations.
[0049] Application messages relate to the performance and / or connectivity of the weighing device. Application messages may include APP-US messages, APP-DS messages, and PING messages.
[0050] APP-US (upstream) messages may include consumption data (e.g., daily meter reading data), load profile data, log data, etc. In other words, APP-US messages are metering device data received by the root node 200 from "downstream" devices such as associated metering devices.
[0051] APP-DS (downstream) messages are exchanged between the root node 200 and a metering device associated with it to collect missing data when there are omissions in the APP-US message. For example, they are used to supplement APP-US data that the root node 200 could not receive due to fluctuations in network performance.
[0052] A PING message is a message issued by a user to confirm the connectivity of one or more associated weighing devices.
[0053] The inventors found that when weighing devices are functioning correctly within a utility weighing system network (i.e., not experiencing network problems), the number and / or frequency of authentication messages, network maintenance messages, and / or application messages exchanged between the root node 200 and each associated weighing device is predictable.
[0054] For example, as described above, the associated weighing device sends periodic scheduled DAO messages to the root node 200 during operation. If the number of scheduled DAO messages is not received from a particular weighing device, or if they are received at an unexpected frequency, that weighing device may be experiencing a network problem. Similarly, if the root node 200 receives a large number of authentication messages from a particular weighing device, that weighing device may be experiencing network connectivity issues or there may be a problem with the system configuration associated with that weighing device.
[0055] The following describes how to determine the network performance of one or more metering devices associated with the root node (or collector) 200, with reference to Figure 3.
[0056] Step 300:
[0057] During use, the root node 200 communicates data with one or more associated weighing devices and headend systems 102, as described above.
[0058] While the root node 200 and one or more associated weighing devices are operating, the receiving unit 202 of the root node 200 receives messages from the associated weighing devices and / or the headend system 102. The transmitting unit 204 of the root node 200 may also send messages to the associated weighing devices and / or the headend system 102. In other words, the root node 200 exchanges messages with one or more weighing devices.
[0059] These messages may, for example, assist in registering one or more weighing devices to the network of the utility weighing system 100, assist in data transfer between weighing devices and the headend system 102, or assist in other operational events relating to the weighing devices and / or the headend system 102. These are just examples, and those skilled in the art will understand that messages may perform other or additional functions.
[0060] As described above, at least some of the messages exchanged between the root node 200 and one or more metering devices may include authentication messages, network maintenance messages, and / or application messages. A person skilled in the art will understand that, depending on the configuration, the root node 200 may also send and receive other types of messages during its operation.
[0061] Step 302:
[0062] Messages received and / or sent by the root node 200 to one or more weighing devices, and events resulting from the receipt or transmission of messages, are logged in the root node 200's live log memory 210.
[0063] Receiving and / or sending a message, or logging an event, includes generating one or more log entries related to the message / event and storing them in the live log memory 210 of the root node 200.
[0064] Log entries may include a timestamp. The timestamp may include the time and / or date of receipt or transmission of the message, or the time and / or date of the event. Log entries may include identification data. The identification data indicates which associated weighing device the message was received from or sent to (or sent to and received from) the headend system 102. Log entries may include information indicating the type of message or event, i.e., an authentication message, a network maintenance message, an application message, or another message type. Furthermore, log entries may include information indicating the subtype of the message, e.g., a PANA message, a Registration / Response message, a DAO / DAO-ACK message, an ICMP message, an APP-US message, an APP-DS message, or a PING message. Log entries may also include information indicating part or all of the message content, e.g., whether processing was successful or not, or whether the message is for informational purposes.
[0065] In an exemplary method, message reception and / or transmission are continuously logged in the live log memory 210 of the root node 200. That is, log entries indicating message reception and / or transmission are continuously generated and stored.
[0066] Step 304:
[0067] The live log memory 210 of the root node 200 is continuously monitored by the storage threshold monitor 222 to determine whether the data stored in the live log memory 210 exceeds the storage threshold. In this example, the storage threshold is set to 5MB, but those skilled in the art will understand that the storage threshold can be set to any value depending on the memory capacity of the root node 200 and other performance requirements.
[0068] If the storage threshold monitor 222 determines that the data stored in the live log memory 210 of the root node 200 does not exceed the storage threshold, no special processing is performed, and the generation of log entries and storage in the live log memory 210 continues as described in steps 300 to 302.
[0069] Step 306:
[0070] If the storage threshold monitor 222 determines that the data, including log entries, stored in the live log memory 210 exceeds the storage threshold, the controller 220 controls the log entry copy unit 224 to copy the data stored in the live log memory 210 to the backup log memory 212.
[0071] If backup log memory 212 contains previous data, such as data previously copied from live log memory 210, that previous data will be overwritten by the data being copied this time.
[0072] Step 308:
[0073] When data stored in the live log memory 210 is copied to the backup log memory 212, the data stored in the live log memory 210 is deleted.
[0074] Subsequently, the processes described in steps 300 to 306 are repeated continuously. That is, after the data in the live log memory 210 is deleted, the reception and / or transmission of messages by the root node 200 are continuously logged again in the live log memory 210, and when the storage threshold is reached, the data is copied to the backup log memory 212 and deleted from the live log memory 210.
[0075] Step 310:
[0076] After data containing log entries is copied from the live log memory 210 to the backup log memory 212, the controller 220 controls the message frequency determination unit 226 to determine the number of messages exchanged between the root node 200 and one or more metering devices based on the log entries stored in the backup log memory 212. The message frequency determination unit 226 may also determine the period over which messages were exchanged. This period is determined based on the timestamps included in the log entries stored in the backup log memory 212.
[0077] The message frequency determination unit 226 may determine the number of messages exchanged between each of the one or more metering devices and the root node 200. For example, it can individually determine the number of first messages exchanged between the first metering device and the root node 200, the number of second messages exchanged between the second metering device and the root node 200, and so on. The number of messages with each metering device is determined based on identification data contained in the log entries stored in the backup log memory 212. The identification data indicates which metering device received the message or which metering device sent the message.
[0078] In an exemplary method, the message frequency determination unit 226 determines the number of messages of each message type exchanged between each metering device and the root node 200. For example, for each metering device, it may determine one or more of the following: the number of network maintenance messages exchanged between the metering device and the root node 200, the number of authentication messages exchanged between the metering device and the root node 200, and the number of application messages exchanged between the metering device and the root node 200. The message frequency determination unit 226 determines the number of messages of each message type exchanged based on the message type information contained in the log entries stored in the backup log memory 212.
[0079] Furthermore, the message frequency determination unit 226 may determine the number of messages of each message subtype exchanged between each metering device and the root node 200. That is, for each metering device, it may determine the number of messages of one or more subtypes from among PANA messages, Registration / Response messages, DAO / DAO-ACK messages, ICMP messages, APP-US messages, APP-DS messages, or PING messages. The number of messages exchanged for each message subtype is determined based on the message subtype information contained in the log entries stored in the backup log memory 212.
[0080] The controller 220 may have the message frequency determination unit 266 determine the number of messages exchanged between the root node 200 and one or more metering devices immediately after the data containing log entries has been copied to the backup log memory 212. Alternatively, the controller 220 may control the message frequency determination unit 226 to determine the number of messages exchanged between the root node 200 and one or more metering devices within a predetermined time after the log entries stored in the live log memory 210 have been copied to the backup log memory 212. This predetermined time may be set based on the shortest time it takes for the live log memory 210 to reach a storage threshold. The shortest time may be based, for example, on historical data up to the point when the live log memory 210 reaches a storage threshold, or it may be estimated based on predicted message traffic or data from similar systems. By determining the number of messages exchanged between the root node 200 and one or more metering devices immediately after log entries are copied from the live log memory 210 to the backup log memory 212, or within a predetermined time, the number of messages can be reliably determined before the data in the backup log memory 212 is overwritten by new data copied from the live log memory 210.
[0081] Step 312:
[0082] The value determined to be the number of messages exchanged between the root node 200 and one or more metering devices is continuously stored in the performance summary memory 214 of the root node 200. Time information determined to be the period during which messages were exchanged is also continuously stored in the performance summary memory 214.
[0083] The performance summary memory 214 is not subject to role processing like the live log memory 210 or the backup log memory 212, and therefore the data stored in the performance summary memory 214 is not automatically overwritten or deleted.
[0084] In the exemplary configuration, the performance summary memory 214 contains performance profiles corresponding to each of one or more metric devices. A schematic of this is shown in Figure 4.
[0085] Each performance profile 402a, 402b, and 402n may include information indicating the number of messages of each message type and / or subtype exchanged between the metering device and the root node 200. For example, performance profile 402a shown in Figure 4 corresponds to metering device 1 and indicates that 0 messages of type / subtype 1, 16 messages of type / subtype 2, and 10 messages of type / subtype n were exchanged between metering device 1 and the root node 200. Similarly, performance profiles 402b and 402n corresponding to metering devices 2 and n are shown. Those skilled in the art will understand that Figure 4 is merely illustrative and that in practice any number of performance profiles (depending on the number of metering devices communicating with the root node 200) can be stored in the performance summary memory 214, and that the number of message types / subtypes that can be stored in each performance profile is also arbitrary.
[0086] The performance profile is updated each time the live log memory 210 and backup log memory 212 roll, and the cumulative number of messages exchanged between each metering device and the root node 200 is maintained. Returning to the example performance summary memory 214 shown in Figure 4, when the live log memory 210 and backup log memory 212 roll again, the message frequency determination unit 226 may determine that metering device 1 exchanged 2 messages of type / subtype 1, 0 messages of type / subtype 2, and 1 message of type / subtype n with the root node 200. The performance profile 402a associated with metering device 1 is updated so that the cumulative values show 2 exchanged messages of type / subtype 1, 16 exchanged messages of type / subtype 2, and 11 exchanged messages of type / subtype n.
[0087] In the exemplary configuration, the total time message exchange is monitored (running time) is also stored in the performance summary memory 214. For example, in the exemplary performance summary memory 214 shown in Figure 4, the running time message exchange is monitored is 48 hours. The running time is continuously updated each time the log rolls using the time determined in step 310. This allows for the determination of the frequency of messages exchanged between each metering device and the root node 200. In Figure 4, a single running time is shown for all performance profiles 402a, 402b, and 402n, but in an alternative configuration, individual running times may be stored in the performance summary memory 214 for each metering device. This allows for the accurate determination of message frequency for each metering device, even if different metering devices join the network at different times. The running time for each metering device may be determined based on identification data and timestamp data contained in the log entries stored in the backup log memory 212.
[0088] Step 314:
[0089] In an exemplary configuration, the root node 200 includes a network performance problem detection unit 228. The network performance problem detection unit 228 compares the number and / or frequency of messages to be exchanged between one or more metering devices and the root node 200 with a predicted message threshold. The predicted message threshold defines the number of messages that are predicted to be exchanged between one or more metering devices and the root node 200 within a specific period, and may be a range, a specific numerical value, or a frequency.
[0090] In an exemplary method, the network performance problem detection unit 228 compares, for each metering device, the number and / or frequency of messages of each message type and / or subtype exchanged and determined between the metering device and the root node 200, with the corresponding predicted message threshold. Those skilled in the art will understand that different predicted message thresholds can be set for each metering device and for each message type / subtype. For example, based on the example in Figure 4, the network performance problem detection unit 228 compares, for metering device 1, the number of determined messages of type / subtype 1 (0 in this example) with a first predicted message threshold, the number of determined messages of type / subtype 2 (16 in this example) with a second predicted message threshold, and the number of determined messages of type / subtype n (10 in this example) with a third predicted message threshold. The first, second, and third predicted message thresholds may be different from each other. Similar processing is performed for metering devices 2 to n.
[0091] As mentioned above, the metering device may periodically send scheduled messages to the root node 200 while in operation. Therefore, the predictive message threshold can be determined based on its scheduling (or it can be manually entered and set as an arbitrary number or range).
[0092] Those skilled in the art will understand that some messages may not be regularly scheduled. In such cases, the predicted message threshold can be determined, for example, based on historical data, or it can be manually set by the user. Those skilled in the art will understand that there are multiple ways to determine the predicted number and frequency of messages.
[0093] Step 316:
[0094] The network performance problem detection unit 228 determines that a network performance problem exists when it determines that the number and / or frequency of messages determined is outside the range of the predicted message threshold (i.e., it is greater than or less than the number and / or frequency of messages specified within the predicted message threshold).
[0095] For example, as mentioned above, if more authentication messages than expected are sent from a particular metering device to root node 200 within a specific period, that metering device may be experiencing network connectivity issues. Similarly, if scheduled messages such as DAO messages are not received in the expected number or frequency, it may indicate network performance problems, such as the metering device having difficulty maintaining connectivity. Furthermore, an unexpected frequency of APP-US messages may indicate a problem with the metering device's configuration.
[0096] In an exemplary configuration, the transmitter 204 of the root node 200 sends an alert message indicating a network performance problem to an external device if the number and / or frequency of messages falls outside the range of a predicted message threshold. The external device may be a maintenance center or control center, which notifies the user or administrator of the potential problem and enables investigation and remediation. The external device may be the headend system 102, other devices within the utility metering system, or a device owned by the user of the metering device.
[0097] In an exemplary manner, the alert message may include information indicating which metering devices may be experiencing network performance issues, such as metering device identification data. For example, metering devices 1 and n shown in Figure 4 may be determined to be experiencing network performance issues because the number of determined messages of at least one message type / subtype is outside the range of the corresponding predicted message threshold. In this example, the alert message would include a statement indicating that metering devices 1 and n may be experiencing network performance issues.
[0098] Furthermore, the transmitter 204 of the root node 200 may transmit data stored in the performance summary memory 214, i.e., the performance profiles of one or more metric devices communicating with the root node 200, to an external device. This data is useful for users or administrators in identifying network performance problems.
[0099] As those skilled in the art will understand, in an alternative configuration, the method shown in Figure 4 and described above may be performed by a device other than the root node 200. For example, in an alternative configuration, the root node 200 may periodically send a copy of the data stored in the performance summary memory 214 to an external device, or only when requested. The external device can then perform the processes described in steps 310 to 316 above.
[0100] In an exemplary configuration, if a network performance problem is detected in one of the metric devices associated with the root node 200, additional data regarding messages exchanged between that metric device and the root node 200 may be useful or necessary for the user or administrator to identify and / or remediate the problem.
[0101] The following describes how to obtain additional data to identify network performance issues related to one or more metric devices associated with the root node (or collector) 200, with reference to Figure 5. The method steps shown in Figure 5 may be performed following the method shown in Figure 3.
[0102] Step 500:
[0103] The root node 200 receives an input indicating that additional data is needed regarding messages exchanged between one or more weighing devices and the root node 200.
[0104] This input may also be a request received by the root node 200's receiver 202 from an external device. The external device may be the headend system 102, another device within the utility weighing system, or a device owned by the user of the weighing device.
[0105] Alternatively, based on the network performance problem detection unit 228 determining that a network performance problem exists with respect to one or more metering devices, a request for additional data related to message exchange may be automatically initiated.
[0106] Step 502:
[0107] In response to the input, the controller 220 controls the log entry extraction unit 230 to extract a subset of log entries from the backup log memory 212 according to user-defined parameters. User-defined parameters may be defined by a configuration file. A configuration file, in this context, defines parameters, options, settings, or preferences that apply to the operating system or device (in this example, the root node 200).
[0108] The configuration file may specify, for example, the message types to be extracted from the backup log memory 212. In an exemplary manner, the configuration file may specify that log entries related to message types useful for estimating network performance be extracted. In particular, the configuration file may specify that log entries related to one or more message types, such as authentication messages and network maintenance messages, be extracted. The configuration file may also specify the message subtypes to be extracted. Message subtypes may include PANA messages, Registration / Response messages, DAO / DAO-ACK messages, ICMP messages, APP-US messages, APP-DS messages, and PING messages.
[0109] An exemplary method may further include the step of extracting a predetermined number of log entries from backup log memory that are recorded before or after one or more log entries related to one or more message types defined by a configuration file. For example, if the configuration file specifies that log entries related to network maintenance messages should be extracted, it may also specify that five log entries recorded immediately before and / or immediately after the network maintenance message should be extracted. The log entry extraction unit 230 determines which log entries were recorded immediately before and / or immediately after based on the timestamp of the log entries.
[0110] Those skilled in the art will understand that the number of log entries before and after the message type to be extracted can be arbitrarily set, and that the number "5" is merely an example. Furthermore, extracting log entries immediately before and / or immediately after the log entry of interest has the advantage of obtaining contextual data useful for analyzing network performance problems.
[0111] The configuration file may include one or more message types and / or subtypes to be extracted, and, if necessary, a search string indicating whether or not to extract the log entries immediately preceding and / or immediately following the log entries related to those one or more message types or subtypes. Those skilled in the art will be familiar with the search string, and a detailed explanation is omitted.
[0112] Furthermore, those skilled in the art will understand that different extraction parameters may be defined within the configuration file. For example, the configuration file may specify that all log entries related to a particular weighing device should be extracted from the backup log memory 212.
[0113] The configuration file defining the extraction parameters may be edited or updated at any time, allowing different data to be extracted from the backup log memory 212 when the process shown in Figure 5 is executed. This makes it possible to adjust the extracted data to suit a specific problem and obtain additional information related to that problem.
[0114] Step 504:
[0115] A subset of log entries extracted from the backup log memory 212 is stored in the performance data memory 215 of the root node 200.
[0116] The performance data memory 215 is not subject to the same roll processing as the live log memory 210 and backup log memory 212, and therefore the data stored in the performance data memory 215 is not automatically overwritten or deleted.
[0117] Therefore, there is an advantage in that log entries related to the identification of network performance problems are retained and can be used for analysis. This allows for the use of data tailored to specific purposes over a longer period than would be possible if only the data stored in the live log memory 210 and backup log memory 212 were used.
[0118] The processes described in steps 502 and 504 may be executed sequentially each time the live log memory 210 and the backup log memory 212 roll. That is, each time the log rolls, the log entry extraction unit 230 extracts a subset of log entries and stores them in the performance data memory 215.
[0119] Step 506:
[0120] The transmission unit 204 of the root node 200 may send a copy of the data stored in the performance data memory 215 to an external device so that a user or administrator can analyze it. As described above, the external device may be the headend system 102, another device in the utility weighing system, or a device owned by the user of the weighing device.
[0121] In an exemplary manner, the transmitter 204 may periodically transmit copies of the data stored in the performance data memory 215. Alternatively, the transmitter 204 may transmit copies of the data stored in the performance data memory 215 only in response to a request from an external device. Yet another method is for the transmitter 204 to transmit the data in the performance data memory 215 after a predetermined period of time has elapsed. For example, if a user or administrator requires 24 hours' worth of data, the controller 220 can have the transmitter 204 transmit a copy of the performance data memory 215 after 24 hours have elapsed.
[0122] Step 508:
[0123] The controller 220 may stop the log entry extraction unit 230 from extracting a subset of log entries in response to a command received by the root node 200 (for example, a command from an external device) or after a predetermined period of time has elapsed. After receiving a command or after a predetermined period of time has elapsed, the log entries stored in the performance data memory 215 may be deleted.
[0124] The controller 220 may have the transmission unit 204 send a copy of the log entry stored in the performance data memory 215 to an external device before the log entry is deleted.
[0125] In this way, by extracting and storing a subset of log entries for a finite period, it is possible to provide users or administrators with data useful for identifying network performance problems without continuously requiring large-capacity storage from the root node 200, nor without continuously sending high-cost data from the root node 200 to external devices.
[0126] A subset of log entries stored in the performance data memory 215 is used by the user or administrator to identify network performance problems. Those skilled in the art will understand that the process shown in Figure 5 and described above can be repeated as many times as necessary, using the same or different extraction parameters defined in the configuration file, and over different time periods, thereby obtaining relevant data for identifying network performance problems.
[0127] The method described above provides a means to efficiently acquire the relevant data necessary to identify network performance problems in a utility metering system without disrupting network operation, using memory efficiency.
[0128] Those skilled in the art will understand that various modifications are possible to the embodiments described above, and these modifications do not depart from the scope of the present invention. The term "exemplary" means "one example." This does not mean that an embodiment described as exemplary is superior to other embodiments.
[0129] The method of the present invention may be configured as a computer program. The computer program may be recorded on a computer-readable medium. The computer program may be a computer program product. The computer program product may include a non-temporary computer-usable storage medium. The computer program product may embody computer-readable program code configured to perform the method on the medium. The computer program product may be configured to cause at least one processor to perform all or part of the method.
[0130] The various methods and apparatus described herein are explained with reference to block diagrams or flowcharts of computer implementation methods, apparatus (systems and / or devices), and / or computer program products. Each block in a block diagram and / or flowchart, or any combination thereof, may be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions are provided to a processor of a general-purpose computer circuit, a dedicated computer circuit, or other programmable data processing circuit, and are executed by the processor to control transistors, values stored in memory locations, and other hardware components necessary to implement the functions / operations shown in the block diagrams and / or flowcharts, thereby forming means (functions) and / or structures.
[0131] Computer program instructions may be stored on a computer-readable medium that causes a computer or other programmable data processing device to function in a specific way. The instructions stored on the medium then generate a product that implements the functions / operations shown in block diagrams and / or flowcharts.
[0132] Tangible, non-temporary, computer-readable media may include electronic, magnetic, optical, electromagnetic, or semiconductor data storage systems, apparatus, or devices. More specific examples include portable diskettes, RAM circuits, ROM circuits, EPROM / flash memory circuits, portable CD-ROMs, and portable DVD / Blu-ray players.
[0133] Computer program instructions are loaded into a computer or other programmable data processing device, and by causing the device to execute a series of operational steps, they generate a computer implementation process and provide steps to implement the functions / operations shown in block diagrams and / or flowcharts.
[0134] Therefore, the present invention can be implemented as hardware and / or software (firmware, resident software, microcode, etc.). These may be collectively referred to as "circuits," "modules," etc.
[0135] Furthermore, in alternative implementations, the functions / operations shown in the flowchart may be executed in a different order than those shown. For example, two consecutively shown blocks may actually be executed simultaneously or in reverse order. Also, the function of one block may be split into multiple blocks, or the functions of multiple blocks may be merged. In addition, blocks not shown may be added.
Claims
1. A method for determining network performance when performing data communication between one or more metering devices configured to measure utility consumption and a root node, A step of exchanging messages between the root node and the one or more weighing devices, wherein the exchange of messages includes sending a message from the root node to the one or more weighing devices and receiving a message from the one or more weighing devices by the root node. The steps include storing log entries in the live log memory of the root node that indicate messages exchanged between the root node and the one or more metering devices, Steps include: when the number of log entries stored in the live log memory reaches a storage threshold, the log entries are successively copied to the backup log memory of the root node, wherein the log entries previously stored in the backup log memory are overwritten by the copy; The steps include: deleting the log entries stored in the live log memory after the log entries have been copied to the backup log memory; After the log entries are copied to the backup log memory, and before the log entries in the backup log memory are overwritten, the log entries stored in the backup log memory are used to continuously determine the frequency of messages exchanged between the root node and the one or more metering devices. The steps include: continuously storing data in the root node's performance summary memory indicating the frequency at which messages exchanged between the root node and the one or more metering devices are determined; and A step of determining whether one or more of the one or more measuring devices are experiencing network performance problems based on data indicating the frequency of the aforementioned messages. Methods that include...
2. The step of determining whether one or more of the aforementioned measuring devices are experiencing network performance problems is: The steps include comparing data indicating the frequency of messages exchanged between the root node and the one or more metering devices with a predicted message threshold indicating the frequency of messages expected to be exchanged between the root node and the one or more metering devices, and The step of determining that a network performance problem exists when the frequency of messages exchanged between the root node and the one or more metering devices is outside the range of the predicted message threshold. including, The method according to claim 1.
3. The further step includes, if it is determined that a network performance problem exists, sending an alert to an external device via the root node's transmission unit indicating that a network performance problem exists. The method according to claim 2.
4. The performance summary memory includes, for each of the one or more metering devices, a performance profile indicating the frequency of messages exchanged between the metering device and the root node. The method according to any one of claims 1 to 3.
5. For each metering device, the steps include comparing the frequency of messages exchanged between the metering device and the root node with a predicted message threshold indicating the frequency of messages expected to be exchanged between the metering device and the root node, and For each metering device, the step of determining whether a network performance problem exists if the frequency of the messages exchanged between the metering device and the root node is outside the range of the predicted message threshold. This also includes, The method according to claim 4.
6. The aforementioned message includes one or more message types, such as network maintenance messages, authentication messages, and application messages. The method according to any one of claims 1 to 5.
7. The steps include: extracting a subset of the log entries stored in the backup log memory according to the parameters contained in the configuration file; and The steps include storing the subset of the log entries in the performance data memory of the root node. This also includes, The method according to any one of claims 1 to 6.
8. In response to determining that a network performance problem exists, the log entries are extracted from the backup log memory and stored in the performance data memory. The method according to claim 7, which is directly or indirectly dependent on claim 2.
9. The step of sending the subset of extracted log entries to an external device The method according to claim 7 or 8, further comprising:
10. The step of extracting the subset of the log entries is: The steps include: searching the backup log memory for log entries related to messages of at least one message type defined by the configuration file, and The steps include extracting one or more log entries from the backup log memory that relate to at least one message type, and including, The method according to any one of claims 7 to 9, which is directly or indirectly dependent on claim 6.
11. A step of extracting a predetermined number of log entries from the backup log memory that are recorded before and / or after one or more log entries related to at least one message type, wherein the predetermined number is defined by the configuration file, and The steps include storing the predetermined number of log entries in the performance data memory and The method according to claim 10, further comprising:
12. The predetermined number of log entries includes log entries that include timestamps immediately preceding and / or immediately following the timestamp of the extracted log entry related to at least one message type. The method according to claim 11.
13. The aforementioned configuration file defines a search string that indicates one or more message types to be extracted. The method according to any one of claims 10 to 12.
14. The search string identifies a specific one of the one or more weighing devices, and the extracted message type is related to a message received from that specific weighing device. The method according to claim 13.
15. The steps include updating the configuration file to define a different subset of log entries extracted from the backup log memory, and The steps include applying the updated configuration file to the root node and extracting the different subsets of log entries from the backup log memory. This also includes, The method according to any one of claims 7 to 14.
16. The steps further include storing the different extracted subset of log entries in the performance data memory and sending the subset of log entries to an external device. The method according to claim 15.