WO2025014997A1

WO2025014997A1 - Network performance detection

Info

Publication number: WO2025014997A1
Application number: PCT/US2024/037301
Authority: WO
Inventors: James Paul Hartman
Original assignee: Landis+Gyr Technology, Inc.
Priority date: 2023-07-12
Filing date: 2024-07-10
Publication date: 2025-01-16

Abstract

A method of determining network performance of metering devices in communication with a root node (200), comprising exchanging messages (300) between the root node (200) and the metering devices; storing (302), in a live log memory (210), log entries indicative of the messages exchanged; continuously copying (306) the log entries to a back-up log memory (212), when the log entries stored in the live log memory reach a storage threshold; deleting (308) the log entries stored in the live log memory (210) once they have been copied to the back-up log memory (212); continuously determining, using the log entries stored in the back-up log memory (212), a frequency of messages exchanged; continuously storing, in a performance summary memory (214), data indicative of the determined frequency of messages exchanged and using that data to determine whether one or more of the metering devices are experiencing network performance issues.

Description

NETWORK PERFORMANCE DETECTION

Technical field

The invention relates to a method of determining network performance of one or more metering devices in data communication with a root node.

Background

Modern utility metering systems may typically comprise a plurality of utility metering devices, such as electric, gas or water utility meters, that measure consumption of a respective utility, and transmit consumption data, status data and/or other data to a headend system via a network. The data may be used for billing, maintenance and other purposes.

Figure 1 shows a network topography of a typical utility metering system 100. The utility metering system 100 comprises a headend system 102, a backhaul network 104 and a plurality of root nodes (also referred to as collectors) 106a-n. Communication between the headend system 102 and the plurality of root nodes 106a-n may be facilitated by the backhaul network 104. The backhaul network 104 may be a wired network (e.g. Ethernet or fibre optic cable) and/or a wireless network (e.g. a cellular network).

Each root node 106a-n may be configured for data communication with one or more nodes (also referred to as endpoints) to perform operations such as managing the nodes, collecting data from the nodes, and transmitting data received from the nodes to the headend system 102. The nodes may comprise the utility metering devices. In the particular example shown in Figure 1 , the root node 106a is in data communication with the nodes 108a-n, the root node 106b is in data communication with the nodes 110a-n and the root node 106n is in data communication with the nodes 112a-n. One or more of the nodes may be considered a parent node, and the other nodes may communicate with the root nodes 106a-n via the parent nodes. In the particular example of Figure 1 , nodes 108a, 110a and 112a are parent nodes. The root nodes 106a-n may aggregate the data received from the respective nodes 108a-n, 110a-n and 112a-n and transmit the data to the headend system 102. Each root node 106a-n may be a personal area network (PAN) coordinator, a gateway, or any other device capable of communicating with the headend system 102.

The headend system 102 functions as a central processing system that receives data from the root nodes 106a-n. The headend system 104, or another system associated with the utility company, can process or analyse the collected data for various purposes, such as billing, performance analysis, or troubleshooting.

In addition to receiving utility metering data from respective nodes 108a-n, 110a-n, 112a-n, each root node 106a-n may receive messages from the nodes 108a-n, 110a-n, 112a-n. Typically, log entries indicative of the received messages may be continuously logged to a live log file/memory of the respective root nodes 106a-n, and when the live log file reaches a threshold memory size (e.g. 5MB), the log “rolls”. That is, the data logged in the live log file/memory is copied to a back-up log file/memory and subsequently received data is logged in the live log file/memory.

The root nodes 106a-n are typically configured to continuously log data, and at least some of that data may be used to determine whether a particular node is experiencing network performance issues. In busy networks however, the live log file/memory may roll as frequently as every 4 minutes. In such networks, there would therefore only be approximately 8 minutes worth of log entry data accessible at any one time (that is, 4 minutes in the live log file/memory and 4 minutes in the back-up log file/memory). In many cases, this would not be enough data in order to identify if a network performance issue is being experienced by a node 108a-n, 110a-n, 112a-n and/or what is causing the network performance issue.

Since storage is typically limited at the root nodes 106a-n, it is also undesirable to simply save all of the log entries logged by the respective root nodes 106a-n in a local root node memory. Furthermore, it would be inefficient and expensive to continuously transmit, for example, 5MB of data every 4 minutes (as in the above-mentioned example) from the root nodes 106a-n and to the headend system 102 via the backhaul network 104, especially in instances where the backhaul network is a cellular network.

There exists a need to provide an improved method of determining network performance issues in utility meters. Summary

According to the invention in a first aspect, there is provided a method of determining network performance of one or more metering devices in data communication with a root node, the one or more metering devices configured to measure consumption of a utility, the method comprising: exchanging messages between the root node and the one or more metering devices, wherein exchanging messages comprises the transmission of messages from the root node and to the one or more metering devices and the receipt of messages by the root node and from the one or more metering devices; storing, in a live log memory of the root node, log entries indicative of the messages exchanged between the root node and the one or more metering devices; continuously copying the log entries stored in the live log memory to a back-up log memory of the root node, when the log entries stored in the live log memory reach a storage threshold, wherein any previously stored log entries in the back-up log memory are overwritten by the copying; deleting the log entries stored in the live log memory once they have been copied to the back-up log memory; continuously determining, using the log entries stored in the back-up log memory, after the log entries have been copied to the back-up log memory and before the log entries in the back-up log memory are overwritten, a frequency of messages exchanged between the root node and the one or more metering devices; continuously storing, in a performance summary memory of the root node, data indicative of the determined frequency of messages exchanged between the root node and the one or more metering devices; and based on the data indicative of the frequency of messages, determining whether one or more of the metering devices are experiencing network performance issues.

The data indicative of the determined frequency may comprise the number of messages exchanged between the root node and the one or more metering devices and the time period over which the messages were exchanged.

Optionally, determining whether one or more of the metering devices are experiencing network performance issues comprises comparing the data indicative of the frequency of messages exchanged between the root node and the one or more metering devices to a predicted message threshold indicative of a frequency of messages expected to be exchanged between the root node and the one or more metering devices; and determining that a network performance issue exists if the frequency of messages exchanged between the root node and the one or more metering devices falls outside of the predicted message threshold.

Optionally, the method further comprises transmitting, by a transmitter of the root node and to an external device, an alert indicating that there is a network performance issue if it is determined that a network performance issue exists.

Optionally, the performance summary memory comprises, for each of the one or more metering devices, a performance profile comprising an indication of the frequency of messages exchanged between a respective metering device and the root node.

Optionally, the method further comprises for each metering device, comparing the frequency of messages exchanged between the respective metering device and the root node to a respective predicted message threshold indicating the frequency of messages expected to be exchanged between the respective metering device and the root node, and for each metering device, determining that a network performance issue exists if the frequency of messages exchanged between the respective metering device and the root node falls outside of the respective predicted message threshold.

Optionally, the messages comprise a message type of one or more of: a network maintenance message, an authentication message and an application message.

Optionally, the method further comprises extracting a subset of the log entries stored within the back-up log memory according to parameters contained in a configuration file; and storing the subset of log entries in a performance data memory of the root node.

Optionally, the log entries are extracted from the back-up log memory and stored in the performance data memory in dependence on a determination that a network performance issue exists.

Optionally, the method further comprises transmitting the extracted subset of log entries to an external device.

Optionally, extracting the subset of log entries comprises searching the back-up log memory for log entries associated with messages of at least one message type, the at least one message type defined by the configuration file; and extracting, from the backup log memory, one or more log entries associated with the at least one message type.

Optionally, the method further comprises extracting, a predetermined number of log entries from the back-up log memory logged before and/or after the one or more log entries associated with the at least one message type, the predetermined number of log entries defined by the configuration file; and storing, within the performance data memory, the predetermined number of log entries.

Optionally, the predetermined number of log entries comprise log entries comprising a timestamp immediately before and/or after the timestamp of the extracted one or more log entries associated with the at least one message type.

Optionally, the configuration file defines a search string indicating the one or more message types to be extracted.

Optionally, the search string identifies a specific one of the one or more metering devices, such that the one or more message types to be extracted relate to messages received from the specific one of the one or more metering devices.

Optionally, the method further comprises updating the configuration file to define a different subset of log entries to be extracted from the back-up log memory; and applying the updated configuration file to the root node such that the different subset of log entries are extracted from the back-up log memory.

Optionally, the method further comprises storing, in the performance data memory, the different extracted subset of log entries, and transmitting the extracted subset of log entries to an external device.

Brief description of the drawings

Figure 1 shows a network topography of a typical utility metering system;

Figure 2 shows a schematic view of an exemplary root node;

Figure 3 shows a flowchart outlining an exemplary method of determining network performance of one or more metering devices associated with a root node;

Figure 4 shows a schematic view of an exemplary performance summary memory; and Figure 5 shows a flowchart outlining an exemplary method of extracting a subset of log entries from a back-up log memory.

Detailed description

Generally disclosed herein is a method of extracting data, indicative of network performance, from a live log memory and/or back-up log memory of a root node (or collector), before the data is overwritten or deleted, for use in determining whether one or more associated metering devices, which are in communication with the root node, are experiencing network performance issues.

In exemplary methods, log entries are continuously stored in the live log memory of the root node. The log entries are typically indicative of messages received by the root node from each of the metering devices associated therewith and/or indicative of messages transmitted from the root node and to each of the metering devices. The log entries may comprise one or more of: an indication of the type and/or sub-type of message received/transmitted, the time that the message was received/transmitted, an indication of which metering device the message was received from/transmitted to, and an indication of the contents of the message. Log entries may further indicate whether the message is informational, or if the message indicates a warning or an error condition. Log entries may further comprise an indication of the code path followed as messages are processed after receipt and before transmission.

When the data stored in the live log memory reaches a storage threshold, it “rolls” and the log entries stored in the live log memory are copied to the back-up log memory, and deleted from the live log memory so that subsequently received data can be stored within the live log memory. Any log entries stored within the back-up log memory prior to the copying are overwritten by the log entries being copied to the back-up log memory. As such, the log entries stored within the live log and back-up log memories are only available for a finite period of time.

In exemplary methods, a frequency of the data, or messages, exchanged between the root node and the one or more associated metering devices is determined based on the log entries stored within the back-up log memory. This determination may continuously occur each time the log entries are copied to the back-up log memory from the live log memory and before the log entries in the back-up log memory are overwritten. In exemplary methods, data indicative of the frequency of data, or messages, exchanged between the root node and the one or more metering devices is continuously stored within a performance summary memory of the root node.

In exemplary arrangements, the performance summary memory comprises a performance profile for each of the one or more associated metering devices. Each performance profile comprises the number of messages received by the respective metering device from the root node, and the number of messages transmitted by the respective metering device to the root node, and an indication of the relevant time period that the performance profile spans (i.e. the time period for which the number of messages received and/or transmitted has been monitored). The number of messages received and/or transmitted indicated within each performance profile may be compared to a predicted messages threshold. An alert indicating network performance issues are being experienced may be generated if the number of messages received and/or transmitted by one or more of the associated metering devices falls outside of the predicted messages threshold.

The performance summary memory is not subject to the same rolling process described above, and therefore data stored within the performance summary memory is not overwritten. Since the performance summary memory only comprises an indication of a number or frequency of messages exchanged between the root node and each of the one or more associated metering devices, and the relevant time period over which the message exchanges indicated within the performance profiles has taken place for each of the one or more associated metering devices, only a small amount of additional storage space is required at each root node.

An exemplary root node (or collector) 200 is shown in Figure 2. The root node 200 may be in data communication with one or more associated metering devices and/or a headend system 102, as described above in respect of Figure 1 .

The root node 200 may comprise a receiver 202 and/or a transmitter 204. The receiver 202 and/or the transmitter 204 may be in data communication with other entities and/or functions in a telecommunications network, such as user equipment, servers/hubs, nodes such as metering devices and the headend system, etc., and are configured to transmit and receive data accordingly. The root node 200 may further comprise a memory 206 and a processor 208. The root node 200 may comprise a live log memory 210, a back-up log memory 212, a performance summary memory 214 and a performance data memory 215. The memories may comprise non-volatile memories and/or a volatile memories. The memory 206 may have a computer program 216 stored therein. The computer program 216 may comprise instructions for performing the methods disclosed herein. The computer program 216 may be loaded in the memory 206 from a non-transitory computer readable medium 218, on which the computer program is stored.

The root node 200 may further comprise a controller 220, a storage threshold monitor 222, a log entry copier 224, a message frequency determiner 226, a network performance issue detector 228 and a log entry extractor 230. The processor 208 is configured by the computer program 216 to perform one or more of the functions of the controller 220, the storage threshold monitor 222, the message frequency determiner 224, the message frequency determiner 226, the network performance issue detector 228 and the log entry extractor 230.

Each of the receiver 202, transmitter 204, memory 206, processor 208, live log memory 210, back-up log memory 212, performance summary memory 214, performance data memory 215, controller 220, storage threshold monitor 222, log entry copier 224, message frequency determiner 226, network performance issue detector 228, log entry extractor 230 may be in data communication with the other components 202, 204, 206, 208, 210, 212, 214, 215, 220, 222, 224, 226, 228, 230 of the root node 200. The root node 200 can be implemented as a combination of computer hardware and software. The memory 206 stores the various programs/executable files that are implemented by a processor 208, and also provides a storage unit for any required data.

As mentioned above, in use, the root node 200 may be in data communication with one or more nodes comprising metering devices, which may be installed at customer sites and configured to measure a utility consumed by an end user (for example power, water or gas). As used herein, the term "root node" refers to a device used to route messages within a utility metering system, as well as between the utility metering system and other networks/systems. For example, the root node 200 may route messages within a wireless mesh network that includes a number of nodes comprising metering devices and a headend system (which may form a separate network to the mesh network including the metering devices), as shown in Figure 1. The utility metering system may comprise a plurality of root nodes 200, where each root node establishes a personal area network (PAN). The various PANs collectively make up the utility metering system. A metering device may be referred to as "associated" with a given root node 200 when the metering device is part of the PAN of the root node 200.

The root node 200 exchanges messages with one or more associated metering devices. That is, the root node 200 receives messages from the associated metering devices, and may also transmit messages to the associated metering devices. As will be appreciated, the root node 200 may receive many different messages, commands, and/or other data from associated metering devices, and may itself transmit many different messages, commands and/or other data to the associated metering devices and/or the headend system. The inventors have realised that the messages exchanged between the root node 200 and the associated metering devices may be used to determine whether the one or more associated metering devices are experiencing network performance issues. In particular, the inventors have realised that a frequency of the messages exchanged between the root node 200 and the associated metering devices may be used to determine network performance issues.

Messages exchanged between the root node 200 and the associated one or more metering devices may comprise one or more of: authentication messages, network maintenance messages and application messages.

Authentication messages comprise messages exchanged between the root node 200, and the associated metering devices and/or the headend system relating to the network authentication of a particular metering device. That is, relating to the process of determining whether the particular metering device is authorised to join the utility metering system network. Authentication messages may comprise PANA (Protocol for Carrying Authentication for Network Access) messages, for example. If a metering device attempting to join the network cannot be authenticated, then access to the network is denied, indicating a potential issue with the metering device and/or the system (or else an attempt to join the network by an unauthorised device).

Network maintenance messages may comprise message exchanges between the root node 200, and the associated metering devices and/or the headend system relating to the network and/or network conditions during operation of the one or more associated metering devices. Network maintenance messages may be scheduled or unscheduled. Network maintenance messages may comprise one or more of Registration/Response messages, DAO/DAO-ACK messages and ICMP messages.

Response messages comprise registration information indicating when and how the associated metering device should transmit and/or receive certain messages. Response messages are sent from the root node 200 to the associated metering device (either directly or via other associated metering devices) once authentication of the associated metering device is successfully completed and the associated metering device has been authorised to join the utility metering system network.

Registration messages indicate that the associated metering device has achieved time synchronisation with the network. Registration messages may be sent from each associated metering device to the root node 200 when the respective associated metering device joins the network. Registration messages may further be sent thereafter when the associated metering device re-joins the network (for example, if the associated metering device loses time synchronisation and therefore has to re-join the network).

DAO messages are sent by an associated metering device and to the root node 200 and indicate selected parent(s) of the associated metering device. Each associated metering device may have one or more parents, which may be other nodes or devices in the network, which define the messaging route between the associated metering device and the root node 200. That is, the messaging route between the associated metering device and the root node 200 may be via one or more parent nodes/devices (in Figure 1 , the nodes 108a, 110a and 112a are parent nodes, for example). Each associated metering device may be configured to send a scheduled DAO message to the root node 200. The regularly scheduled DAO messages may be used as a “check in” of the associated metering device. Unscheduled DAO messages may also be sent by the associated metering device if a parent change is required, which may be necessary as network conditions vary.

DAO-ACK messages are transmitted from the root node 200 and to the associated metering device to confirm receipt of the DAO message at the root node 200. ICMP (Internet Control Message Protocol) messages are received by the root node 200 in response to errors in IP operations. For example, in response to errors in routing, address resolution, destination reachability etc.

Application messages relate to metering device performance and/or connectivity. Application messages may comprise APP-US messages, APP-DS messages and PING messages.

APP-US (Upstream) messages may comprise consumption data (such as daily meter readings), load profile data, log data etc. That is, metering device data received by the root node 200 from “downstream” devices, such as the associated metering devices.

APP-DS (Downstream) messages are messages that may be exchanged between the root node 200 and the associated metering devices for collecting data that is missing from the APP-US messages. For example, any APP-US data that was not received by the root node 200 as a result of varying network performance.

PING messages are user-initiated messages for checking the connectivity of one or more associated metering devices.

The inventors have appreciated that when the metering devices are functioning correctly within the utility metering system network (that is, not experiencing network issues), a predicted number and/or a predicted frequency of authentication messages, network maintenance messages and/or application messages will be exchanged between the root node 200 and each associated metering device.

For example, as discussed above, associated metering devices may transmit regular, scheduled DAO messages to the root node 200 during operation. If the scheduled number of DAO messages are not received from an associated metering device, or they are being received at an unexpected frequency, this may be indicative of that particular associated metering device experiencing a network issue. Similarly, if a high number of authentication messages are received by the root node 200 from an associated metering device, this may suggest that the associated metering device is having issues connecting to the network or that there may be a system configuration issue relating to the associated metering device. A method of determining network performance of one or more metering devices associated with a root node (or collector) 200 is described below with reference to Figure 3.

300: In use, the root node 200 is in data communication with one or more associated metering devices and the headend system 102, as described above.

Throughout operation of the root node 200 and the one or more metering devices associated with the root node 200, the receiver 202 of the root node 200 receives messages from the one or more associated metering devices and/or from the headend system 102. Furthermore, the transmitter 204 of the root node 200 may transmit messages to one or more of the associated metering devices and/or to the headend system 102. In other words, the root node 200 exchanges messages with each of the one or more metering devices.

These messages may, for example, facilitate registration of the one or more metering devices to the network of the utility metering system 100, facilitate transfer of data between the one or more metering devices and the headend system 102, and/or facilitate other operational events concerning the metering devices and/or the headend system 102. The skilled person will appreciate that these are examples only, and that messages may perform alternative or additional functions.

At least some of the messages exchanged between the root node 200 and the one or more metering devices may comprise authentication messages, network maintenance messages and/or application messages, as described above. The skilled person will appreciate that in some arrangements, other types of messages may be transmitted by and/or received by the root node 200 during operation of the root node 200.

302: The receipt and/or transmission of messages by the root node 200, from/to the one or more metering devices, and/or events resulting from the receipt or transmission of the messages, are logged in the live log memory 210 of the root node 200. Logging the receipt and/or transmission of messages, and/or logging events, comprises generating and storing, in the live log memory 210 of the root node 200, one or more log entries associated with the message/event.

The log entries may comprise a timestamp. The timestamp may comprise a time and/or date of receipt or transmission of the message, or a time and/or date of occurrence of the event. The log entries may also comprise identification data. The identification data may indicate which of the associated metering devices the messages have been transmitted to and/or received from (or if the messages have been transmitted to or received from the headend system 102). The log entries may comprise an indication of the message or event type, for example whether the message is an authentication message, a network maintenance message and/or an application message, or another message type. Optionally, the log entries may comprise an indication of a message sub-type, for example, whether the message is 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. The log entries may additionally or alternatively comprise an indication of the contents of the message, for example, an indication of whether a process has been successful or unsuccessful, or whether a message is informational.

Exemplary methods comprise continuously logging receipt and/or transmission of messages to the live log memory 210 of the root node 200. That is, continuously generating and storing log entries indicative of the receipt and/or transmission of the messages. : 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 within the live log memory 210 exceeds a storage threshold. For the purpose of this example, the storage threshold comprises 5MB, however the skilled person will appreciate that the storage threshold may comprise substantially any value depending on, for example, the memory availability of the root node 200, or other required performance parameters.

If the storage threshold monitor 222 determines that the data stored within the live log memory 210 of the root node 200 does not exceed the storage threshold, no action is taken and log entries to continue to be generated and stored in the live log memory 210, as outlined in steps 300-302.

306: If the storage threshold monitor 222 determines that the data, comprising the log entries, stored within the live log memory 210 of the root node 200 exceeds the storage threshold, the controller 220 controls the log entry copier 224 to copy the data stored within the live log memory 210 to the back-up log memory 212.

If the back-up log memory 212 comprises previous data stored therein, for example previous data that was copied from the live log memory 210 and to the back-up log memory 212, the previous data is overwritten in favour of the data being copied to the back-up log memory 212.

308: Once the data stored within the live log memory 210 has been copied to the back-up log memory 212, the data stored within the live log memory 210 is deleted.

The process outlined in steps 300 to 306 then continuously repeats. That is, the further receipt and/or transmission of messages by the root node 200, following the deletion of the data stored within the live log memory 210, is continuously logged to the live log memory 210 until the storage threshold is reached, at which point the further data stored within the live log memory 210 is copied over to the back-up log memory 212 and deleted from the live log memory 210.

310: Following the copying of the data, comprising the log entries, from the live log memory 210 to the back-up log memory 212, the controller 220 controls the message frequency determiner 226 to determine, based on the log entries stored within the back-up log memory 212, a number of messages exchanged between the root node 200 and at least one of the one or more metering devices. The message frequency determiner 226 may also determine a time period over which the messages were exchanged. The time period may be determined based on the timestamps contained in the log entries stored within the back-up log memory 212. The message frequency determiner 226 may determine the number of messages exchanged between each of the one or more metering devices and the root node 200. For example, the message frequency determiner 226 may determine a first number of messages exchanged between a first metering device and the root node 200, and a second number of messages exchanged between a second metering device and the root node 200 etc. The number of messages exchanged between each of the one or more metering devices and the root node 200 may be determined based on the identification data contained in the log entries stored within the back-up log memory 212. As mentioned above, the identification data indicates which of the metering devices the messages have been transmitted to and/or received from.

In exemplary methods, the message frequency determiner 226 determines the number of each type of message exchanged between each metering device and the root node 200. For example, the message frequency determiner 226 may determine, for each metering device, one or more of: the number of network maintenance messages exchanged between the respective metering device and the root node 200, the number of authentication messages exchanged between the respective metering device and the root node 200, and the number of application messages exchanged between the respective metering device and the root node 200. The message frequency determiner 226 may determine the number of exchanged messages of each message type based on the log entries stored within the back-up log memory 212, which as outlined above, comprise an indication of the message type.

The message frequency determiner 226 may alternatively and/or additionally determine the number of each sub-type of message exchanged between each metering device and the root node 200. That is, for each metering device, the message frequency determiner 226 may determine the number of exchanged messages of one or more of the following message sub-types: PANA messages, Registration/Response messages, DAO/DAO-ACK messages, ICMP messages, APP-US messages, APP-DS messages or PING messages. The message frequency determiner 226 may determine the number of exchanged messages of each message sub-type based on the log entries stored within the back-up log memory 212, which as outlined above, comprise an indication of the message sub-type. The controller 220 may control the message frequency determiner 226 to determine the number of messages exchanged between the root node 200 and the one or more metering devices substantially immediately after the data comprising the log entries has been copied to the back-up log memory 212. In alternative methods, the controller 220 may control the message frequency determiner 226 to determine the number of messages exchanged between the root node 200 and the one or more metering devices within a predefined time period following the copying of the log entries stored within the live log memory 210 to the back-up log memory 212. The predefined time period may be based on a determined quickest time that the storage threshold of the live log memory 210 may be reached. The determined quickest time may be based on historical data, for example, previous times taken for the live log memory 210 to reach the storage threshold, or the quickest time may be predicted based on expected message traffic, or data from similar systems. Determining the number of messages exchanged between the root node 200 and the one or more metering devices immediately after the log entries have been copied to the back-up log memory 212 from the live log memory 210, or else within the predefined time period, ensures that the determination is made before the data within the backup log memory 212 is overwritten by further data being copied over from the live log memory 210. : The determined number of messages exchanged between the root node 200 and the one or more metering devices is continuously stored within the performance summary memory 214 of the root node 200. Additionally, the determined time period over which the messages were exchanged is continuously stored within the performance summary memory 214.

The performance summary memory 214 is not subject to the same rolling process as the live log memory 210 and the back-up log memory 212, and as such the data stored within the performance data memory 214 is not automatically overwritten or deleted.

In exemplary arrangements, the performance summary memory 214 comprises a performance profile for each of the one or more metering devices. This is shown schematically in Figure 4. Each performance profile 402a, 402b, 402n may comprise an indication of the number of messages of each type and/or sub-type exchanged between the respective metering device and the root node 200. For example, in Figure 4, the performance profile 402a relates to metering device 1 , and indicates that 0 messages of type/sub-type 1 have been exchanged between metering device 1 and the root node 200; that 16 messages of type/sub-type 2 have been exchanged between metering device 1 and the root node 200, and that 10 messages of type/sub-type n have been exchanged between metering device 1 and the root node 200. Similar performance profiles 402b and 402n are shown for metering device 2 and metering device n respectively. The skilled person will appreciate that Figure 4 is exemplary only, and in practice substantially any number of performance profiles may be stored within the performance summary memory 214 (in dependence on the number of metering devices communicating with the root node 200), and that substantially any number of message types/sub-types may be stored within each performance profile.

The performance profiles may continuously updated, each time the live log memory 210 and back-up log memory 212 roll, to provide a cumulative total of the number of messages exchanged between each metering device and the root node 200. Referring again to the exemplary performance summary memory 214 shown in Figure 4, the next time the live log memory 210 and back-up log memory 212 roll, the message frequency determiner 226 may determine that the metering device 1 has exchanged 2 messages of type/sub- type 1 with the root node 200, 0 messages of type/sub-type 2 and 1 message of type/sub-type 1 . The performance profile 402a associated with metering device

I would therefore be updated to reflect the new cumulative total of 2 exchanged messages of type/sub-type 1 , 16 exchanged messages of type/sub-type 2 and

I I exchanged messages of type/sub-type n.

In exemplary arrangements, an indication of the running time period for which the exchange of messages has been monitored is also stored within the performance summary memory 214. For example, in the exemplary performance summary memory 214 shown in Figure 4, the running time period for which the exchange of messages has been monitored is 48 hours. The running time period may be continuously updated each time the log rolls, using the time period determined in step 310. As such, the frequency of messages exchanged between a respective metering device and the root node 200 may be determined. In the schematic view shown in Figure 4, a single running time period is shown for all of the performance profiles 402a, 402b, 402n. However, the skilled person will appreciate that in alternative arrangements, a running time period for each metering device may be stored within the performance summary memory 214. This will account for different metering devices joining the network at different times, and therefore allow an accurate message frequency to be determined for each metering device. The running time period for each metering device may be determined based on the identification data and timestamp data contained in the log entries stored in the back-up log memory 212. : In exemplary arrangements, the root node 200 comprises a network performance issue detector 228. The network performance issue detector 228 compares the determined number and/or frequency of messages exchanged between the one or more metering devices and the root node 200 to a predicted messages threshold. The predicted messages threshold may define a number of messages expected to be exchanged between the one or more metering devices and the root node 200, within the particular time period. The threshold may comprise a range, or may comprise a specific number and/or frequency of messages.

In exemplary methods, the network performance issue detector 228 may, for each respective metering device, compare the determined number and/or frequency of each type and/or sub-type of message exchanged between the respective metering device and the root node 200 to a respective predicted message threshold. As will be appreciated by the skilled person, different respective predicted message thresholds may be used for each respective metering device, and each message type/sub-type. For example, continuing with the example outlined in Figure 4, the network performance issue detector 228 may, for metering device 1 , compare the determined number of messages exchanged of type/sub-type 1 (i.e. 0 in this example) to a first predicted message threshold; compare the determined number of messages exchanged of type/sub-type 2 (i.e. 16 in this example) to a second predicted message threshold; and compare the determined number of messages exchanged of type/sub-type 3 (i.e. 10 in this example) to a third predicted message threshold. Each of the first, second and third predicted message thresholds may be different. A similar process may be completed for each metering device 2-n.

As outlined above, metering devices may transmit regular, scheduled messages to the root node 200 during operation. The predicted messages thresholds may therefore be determined based on the scheduling (or else, may be manually entered/set to whatever number or range desired).

The skilled person will appreciate that some messages may not be regularly scheduled. In these cases, the predicted messages threshold may be determined based on historical data, for example. Alternatively, the predicted messages threshold may be manually set by a user. The skilled person will appreciate that there are a number of ways that a predicted number and/or frequency of messages may be determined. : The network performance issue detector 228 determines that there is a network performance issue if the determined number and/or frequency of messages falls outside of the predicted messages threshold (that is, is greater than and/or lower than the number and/or frequency of messages specified within the predicted messages threshold).

For example, as outlined above, if a higher than predicted number of authentication messages are received by the root node 200 from one or more associated metering devices within a particular time period, this may suggest that a particular metering device is having issues connecting to the network. Similarly if scheduled messages, such as DAO messages, are not being received in the number, or at the frequency, expected, this may be indicative of a network performance issue, such as difficulty of associated metering devices in maintaining a connection. As a further example, an unexpected frequency of APP-US messages may indicate metering device configuration issues.

In exemplary arrangements, the transmitter 204 of the root node 200 transmits an alert message indicating that there is a network performance issue if the number and/or frequency of messages falls outside of the predicted messages threshold. The alert message may be transmitted to an external device, such as a maintenance or control centre to alert a user/controller to the potential issue and allow user/controller to investigate and fix the network performance problem. The external device may comprise the headend system 102, another device within the utility metering system, or a device owned by the user of the metering device.

In exemplary methods, the alert message may comprise an indication of which metering devices appear to be experiencing a network performance issue, for example, the alert message may comprise metering device identification data. For example, it may be determined that metering devices 1 and n of Figure 4, are experiencing a network performance issue because the determined number of messages of at least one message type/sub-type fall outside of the corresponding predicted message threshold. In this example therefore, the alert message may comprise an indication that metering devices 1 and n appear to be experiencing a network performance issue.

The transmitter 204 of the root node 200 may also transmit data stored within the performance data memory 214 to the external device, comprising the performance profiles for the one or more metering devices in communication with the root node 200. This data may aid the user/controller in identifying the network performance issue.

As will be appreciated, in alternative arrangements, the method outlined above and shown in Figure 4 may be undertaken by a different device to the root node 200. For example, in alternative arrangements, the root node 200 may regularly transmit a copy of the data stored within the performance summary memory 214 to an external device, or else transmit a copy of the data stored within the performance summary memory 214 only in response to a request. The external device may then undertake the method steps 310-316 described above.

In exemplary arrangements, if a network performance issue is detected relating to one of the metering devices associated with the root node 200, additional data relating to the exchange of messages between the metering device and the root node 200 may be beneficial or required by the user/controller in order to identify and/or fix the network performance issue. A method of obtaining additional data for identifying a network performance issue relating to one or more metering devices associated with a root node (or collector) 200 is described below with reference to Figure 5. The method steps outlined below, and shown in Figure 5, may follow the method outlined in Figure 3.

500: The root node 200 receives an input indicating that further data relating to the exchange of messages between at least one of the one or more metering devices and the root node 200 is required.

The input may comprise a request received by the receiver 202 of the root node 200 and from an external device, such as the headend system 102, another device within the utility metering system, or a device owned by the user of the metering device.

Alternatively, a request for further data relating to the exchange of messages may be initiated automatically based on a determination, by the network performance issue detector 228, that there is a network performance issue relating to one or more of the metering devices.

502: In response to the input, the controller 220 controls the log entry extractor 230 to extract a subset of log entries from the back-up log memory 212 according to user-defined parameters. The user-defined parameters may be defined in a configuration file. A configuration file, as described herein, defines one or more of parameters, options, settings and preferences that should be applied to an operating system or device (in this case, the root node 200).

The configuration file may, for example, specify a message type to be extracted from the back-up log memory 212. In exemplary methods, the configuration file may specify that any log entries associated with message types from which network performance may be deduced should be extracted from the back-up log memory 212. In particular, the configuration file may specify that log entries associated with one or more of the following message types should be extracted: authentication messages, network maintenance messages. The configuration file may specify that a message sub-type should be extracted. Message sub-types may include: PANA messages, Registration/Response messages, DAO/DAO-ACK messages and ICMP messages, APP-US messages, APP-DS messages and PING messages.

Exemplary methods may further comprise extracting a predetermined number of log entries from the back-up log memory logged before and/or after the one or more log entries associated with the one or more message types defined by the configuration file. For example, the configuration file may define that any log entries associated with network maintenance messages should be extracted, and for example, the five log entries logged immediately before the respective network maintenance messages and/or immediately after the respective network maintenance messages. The log entry extractor 230 may determine which log entries logged immediately before the respective network maintenance messages and/or immediately after the respective network maintenance messages to extract based on the timestamp of the log entries.

The skilled person will appreciate that substantially any number of log entries before and/or after the log entries associated with the message type to be extracted may be defined, and the extraction of “five” log entries is exemplary only. Advantageously, by extracting log entries immediately before and/or after the log entries of interest, contextual data is extracted that may be beneficial in analysing network performance issues.

The configuration file may comprise a search string indicating the one or more message types and/or sub-types, and optionally whether log entries logged immediately before and/or after the log entries associated with the one or more message types or sub-types, to be extracted. The skilled person will be familiar with search strings and further detail is not provided here.

The skilled person will further appreciate that different extraction parameters may be defined within the configuration file. For example, the configuration file may define that all log entries associated with a particular associated metering device should be extracted from the back-up log memory 212.

The configuration file defining the extraction parameters may be continuously edited/updated such that when the process outlined in Figure 5 occurs, different data is extracted from the back-up log member 212. This may allow the data extracted to be tailored to a specific problem and allow further information relating to that specific problem to be obtained. : The subset of log entries extracted from the back-up log memory 212 are stored in the performance data memory 215 of the root node 200.

The performance data memory 215 is not subject to the same rolling process as the live log memory 210 and the back-up log memory 212, and as such the data stored within the performance data memory 215 is not automatically overwritten or deleted.

Advantageously therefore, the relevant log entries for identifying the network performance issues, are retained for analysis. As such, specifically targeted data covering a greater span of time than would be available simply using the data stored within the live log memory 210 and the back-up log memory 212 is available for analysis.

The steps outlined in 502 and 504 may occur continuously, each time the live log memory 210 and the back-up log memory 212 roll. That is, each time the live log memory 210 and the back-up log memory 212 roll, the log entry extractor 230 may extract the subset of log entries and store the subset of log entries in the performance data memory 215. : The transmitter 204 of the root node 200 may transmit a copy of the data stored within the performance data memory 215 to an external device for analysis by a user/controller. As mentioned above, the external device may comprise the headend system 102, another device within the utility metering system, or a device owned by the user of the metering device.

In exemplary methods, the transmitter 204 may regularly transmit a copy of the data stored within the performance data memory 215. In alternative methods, the transmitter 204 may only transmit a copy of the data stored within the performance data memory 232 in response to a request, for example, received from the external device. In further alternative methods, the transmitter 204 may additionally or alternatively transmit a copy of the data stored within the performance data memory 215 on expiry of a predetermined time period. For example, the user/controller may desire data over a 24 hour period, and the controller 220 may control the transmitter 204 to transmit a copy of the performance data memory 215 once on expiry of 24 hours.

508: The controller 220 may control the log entry extractor 230 to stop extracting the subset of log entries in response to a command received by the root node 200 (e.g. from the external device), or on expiry of a predetermined time period. In response to the command, or on expiry of the predetermined time period, the log entries stored within the performance data memory 215 may be deleted.

The controller 220 may control the transmitter 204 to transmit a copy of the data stored within the performance data memory 215 to the external device before the log entries stored within the performance data memory 215 are deleted.

Advantageously, by only extracting and storing the subset of log entries for a finite period of time, data that is useful in identifying the network performance issue is made available to a user/controller without continuously requiring large amounts of storage space at the root node 200, and without continuously requiring expensive transmission of data from the root node 200 and to the external device.

The subset of log entries stored within the performance data memory 215 may then be used by the user/controller to identify the network performance issue. The skilled person will appreciate that the process outlined in Figure 5 and described above may be repeated as many times as needed, with the same and/or different extraction parameters as defined in the configuration file, and over different time periods, in order to obtain relevant data for identifying the network performance issue.

The above-described methods provide a memory-efficient way of obtaining relevant data to allow network performance issues, in a utility metering system, to be identified without disrupting network operations

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the invention. The word “exemplary” is used herein to mean “an example”. Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

A computer program may be configured to provide any of the above described methods. The computer program may be provided on a computer readable medium. The computer program may be a computer program product. The product may comprise a non-transitory computer usable storage medium. The computer program product may have computer-readable program code embodied in the medium configured to perform the method. The computer program product may be configured to cause at least one processor to perform some or all of the method.

Various methods and apparatus are described herein with reference to block diagrams or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

Computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.

A tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD- ROM), and a portable digital video disc read-only memory (DVD/Blu-ray).

The computer program instructions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, the invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated.

Claims

CLAIMS:

1 . A method of determining network performance of one or more metering devices in data communication with a root node, the one or more metering devices configured to measure consumption of a utility, the method comprising: exchanging messages between the root node and the one or more metering devices, wherein exchanging messages comprises the transmission of messages from the root node and to the one or more metering devices and the receipt of messages by the root node and from the one or more metering devices; storing, in a live log memory of the root node, log entries indicative of the messages exchanged between the root node and the one or more metering devices; continuously copying the log entries stored in the live log memory to a back-up log memory of the root node, when the log entries stored in the live log memory reach a storage threshold, wherein any previously stored log entries in the back-up log memory are overwritten by the copying; deleting the log entries stored in the live log memory once they have been copied to the back-up log memory; continuously determining, using the log entries stored in the back-up log memory, after the log entries have been copied to the back-up log memory and before the log entries in the back-up log memory are overwritten, a frequency of messages exchanged between the root node and the one or more metering devices; continuously storing, in a performance summary memory of the root node, data indicative of the determined frequency of messages exchanged between the root node and the one or more metering devices; and based on the data indicative of the frequency of messages, determining whether one or more of the metering devices are experiencing network performance issues.

2. A method according to claim 1 , wherein determining whether one or more of the metering devices are experiencing network performance issues comprises: comparing the data indicative of the frequency of messages exchanged between the root node and the one or more metering devices to a predicted message threshold indicative of a frequency of messages expected to be exchanged between the root node and the one or more metering devices; and determining that a network performance issue exists if the frequency of messages exchanged between the root node and the one or more metering devices falls outside of the predicted message threshold.

3. A method according to claim 2, further comprising: transmitting, by a transmitter of the root node and to an external device, an alert indicating that there is a network performance issue if it is determined that a network performance issue exists.

4. A method according to any preceding claim, wherein the performance summary memory comprises, for each of the one or more metering devices, a performance profile comprising an indication of the frequency of messages exchanged between a respective metering device and the root node.

5. A method according to claim 4, further comprising: for each metering device, comparing the frequency of messages exchanged between the respective metering device and the root node to a respective predicted message threshold indicating the frequency of messages expected to be exchanged between the respective metering device and the root node, and for each metering device, determining that a network performance issue exists if the frequency of messages exchanged between the respective metering device and the root node falls outside of the respective predicted message threshold.

6. A method according to any preceding claim, wherein the messages comprise a message type of one or more of: a network maintenance message, an authentication message and an application message.

7. A method according to any preceding claim, further comprising: extracting a subset of the log entries stored within the back-up log memory according to parameters contained in a configuration file; and storing the subset of log entries in a performance data memory of the root node.

8. A method according to claim 7, when dependent directly or indirectly on claim 2, wherein the log entries are extracted from the back-up log memory and stored in the performance data memory in dependence on a determination that a network performance issue exists.

9. A method according to claim 7 or 8, further comprising transmitting the extracted subset of log entries to an external device.

10. A method according to any of claims 7 to 9, when dependent directly or indirectly on claim 6, wherein extracting the subset of log entries comprises: searching the back-up log memory for log entries associated with messages of at least one message type, the at least one message type defined by the configuration file; and extracting, from the back-up log memory, one or more log entries associated with the at least one message type.

11. A method according to claim 10, further comprising: extracting, a predetermined number of log entries from the back-up log memory logged before and/or after the one or more log entries associated with the at least one message type, the predetermined number of log entries defined by the configuration file; and storing, within the performance data memory, the predetermined number of log entries.

12. A method according to claim 11 , wherein the predetermined number of log entries comprise log entries comprising a timestamp immediately before and/or after the timestamp of the extracted one or more log entries associated with the at least one message type.

13. A method according to any of claims 10 to 12, wherein the configuration file defines a search string indicating the one or more message types to be extracted.

14. A method according to claim 13, wherein the search string identifies a specific one of the one or more metering devices, such that the one or more message types to be extracted relate to messages received from the specific one of the one or more metering devices.

15. A method according to any of claims 7 to 14, further comprising: updating the configuration file to define a different subset of log entries to be extracted from the back-up log memory; and applying the updated configuration file to the root node such that the different subset of log entries are extracted from the back-up log memory.

16. A method according to claim 15, further comprising storing, in the performance data memory, the different extracted subset of log entries, and transmitting the extracted subset of log entries to an external device.