Explicit packet content identification for utility equipment

By encoding the device type and unique network ID in the broadcast message header of the utility system, the device can quickly determine whether the message is related, thereby reducing the reception mode time, solving the problem of shortening the device life, and achieving optimization of energy consumption.

CN119836800APending Publication Date: 2025-04-15ACLARA TECHNOLOGIES LLC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380057964.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-06-06
Filing Date
2023-06-05
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

In utility systems, devices need to be in reception mode for a long time when receiving broadcast messages, resulting in additional energy consumption, thereby shortening the life of the device.

Method used

By encoding the device type and unique network ID in the header of the broadcast message, the device allows the device to quickly determine whether the message is related to itself, thereby reducing unnecessary reception mode time.

Benefits of technology

Effectively extend the life of the device, especially the battery life, and reduce the frequency of equipment replacement caused by excessive energy consumption.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119836800A_ABST
    Figure CN119836800A_ABST
Patent Text Reader

Abstract

A utility device within a utility system and including a power source, a communication interface, and one or more electronic processors. The processor is configured to periodically transition from a standby mode to a receive mode and monitor broadcast messages while in the receive mode. The electronic processor is further configured to receive the broadcast message through the communication module while in a receive mode, and analyze a header of the received broadcast message to determine whether any data packets within the received broadcast message are related. Data packets within the broadcast message are determined to be relevant based on whether the received broadcast message includes one or more data packets within one or more information areas associated with a device type of the utility device. The electronic processor is further configured to resume operation in the standby mode in response to determining that the received broadcast message is irrelevant.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present disclosure relate to efficiently routing messages to various devices within a network, such as a utility network system. Background Art

[0002] Connected or smart utility meters and / or sensors are becoming increasingly common in utility systems, such as gas, electricity, water, and the like. These connected sensors allow data to be provided directly to a central utility system for processing, billing, maintenance, and the like. Many of these devices rely on battery (or other energy storage device) power to operate. Typically, these devices may have to be replaced in their entirety when the power source is unable to provide sufficient power to the device (i.e., when the battery is depleted). Much of the energy consumed by these connected devices may be related to monitoring and receiving messages (such as messages transmitted by the utility system). This is particularly true in the case where the utility system uses broadcast messaging. The use of broadcast messaging may require the device to actively monitor for the entire duration of the transmitted broadcast message, where one or more messages within the broadcast are directed to the device. This results in additional energy consumption because the device is required to be in receive mode for an extended period of time. Summary of the invention

[0003] Concepts described herein provide systems and methods for reducing unnecessary operation of a device in a receive mode by encoding broadcast messages with header information that allows the device to quickly determine whether a broadcast message is relevant to the device. The encoded broadcast messages typically utilize characteristics of the utility device type (e.g., whether the device is a battery-powered device or a mains-powered device) and other parameters, such as a unique network ID of the device within the system. By reducing the time that a device is unnecessarily in a receive mode, the life of the device (e.g., battery life) can be extended.

[0004] In one embodiment, a utility device within a utility system according to some embodiments and including a power source, a communication interface, and one or more electronic processors is described. The processor is configured to periodically switch from a standby mode to a receive mode and monitor broadcast messages while in the receive mode. The electronic processor is also configured to receive broadcast messages through a communication module while in the receive mode and analyze a header of the received broadcast message to determine whether any data packets within the received broadcast message are relevant. Data packets within the broadcast message are determined to be relevant based on whether the received broadcast message includes one or more data packets within one or more information areas associated with a device type of the utility device. The electronic processor is also configured to resume operation in the standby mode in response to determining that the received broadcast message is not relevant.

[0005] In one aspect, the one or more electronic processors are further configured to process the broadcast message in response to determining that the broadcast message includes one or more related data packets.

[0006] In another aspect, the header includes one or more indications of which of the one or more information areas contains one or more data packets associated with a device type of the utility device.

[0007] In another aspect, the one or more information regions include at least one selected from the group consisting of a broadcast information region, a constrained device information region, a shared device information region, and an unconstrained device information region.

[0008] In another aspect, an information region is associated with a particular device type of one or more utility devices within a utility system.

[0009] In another aspect, the utility device is one of a constrained device and an unconstrained device.

[0010] In another aspect, the constrained device has a limited power source.

[0011] In another aspect, the limited power source is a battery.

[0012] In another embodiment, a process for generating a broadcast message within a utility network according to some embodiments is described. The process includes generating a broadcast message that includes one or more data packets associated with one or more utility devices; and generating a header for the generated broadcast message. The generated header includes data indicating the applicability of the included one or more data packets to the one or more utility devices. The process also includes transmitting the generated message.

[0013] In one aspect, the data includes an indication that one or more data packets within the generated broadcast message are intended for a group of devices within the utility network.

[0014] In another aspect, the data includes an indication that one or more data packets within the generated broadcast message are intended for constrained devices or unconstrained devices.

[0015] In another aspect, the constrained device is a battery powered device.

[0016] In another aspect, the generated broadcast message includes a plurality of information regions, wherein the information regions include at least one selected from the group consisting of a public control region, a broadcast information region, a restricted device information region, a shared information region, and an unrestricted device information region.

[0017] In another aspect, the common control region includes a header.

[0018] In another embodiment, a process for analyzing broadcast messages at a utility device according to some embodiments is described. The process includes periodically switching from a first mode to a second mode; and receiving a broadcast message through a communication module while operating in the second mode. The process also includes analyzing a header of a received broadcast message to determine whether the received broadcast message includes one or more data packets within one or more information areas associated with a device type of the utility device. The process also includes determining whether the received broadcast message is a related message in response to determining that the received broadcast message includes one or more data packets within one or more information areas associated with a device type of the utility device; and processing the received broadcast message in response to determining that the received broadcast message is a related broadcast message.

[0019] In one aspect, the first mode is a standby mode and the second mode is a receive mode.

[0020] In another aspect, the process further includes resuming operation in the first mode in response to determining that the received broadcast message is not a relevant broadcast message.

[0021] In another aspect, the header includes one or more indications of which of the one or more information areas contains a data packet associated with a device type of the utility device.

[0022] In another aspect, the information area includes at least one selected from the group consisting of a broadcast information area, a restricted device information area, a shared device information area, and a restricted device information area.

[0023] In another aspect, the constrained device is a battery powered device. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings, together with the following detailed description, are incorporated into and form a part of the specification and are used to further illustrate embodiments of the concepts of the claims and to explain the various principles and advantages of those embodiments, wherein like reference numerals refer to the same or functionally similar elements throughout the individual views.

[0025] Figure 1 is a diagram of a general utility network according to some embodiments.

[0026] Figure 2 is a block diagram of a utility device according to some embodiments.

[0027] Figure 3 is a flow chart illustrating a process for adding a utility device to a utility network according to some embodiments.

[0028] Figure 4 is a flow chart illustrating a process for generating a broadcast message for a utility network according to some embodiments.

[0029] Figure 5 is an example broadcast message format according to some embodiments.

[0030] Figure 6 is a representation of a broadcast message including associated utilities according to some embodiments.

[0031] Figure 7 is a minimum range exclusion zone according to some embodiments Figure 6 Representation of a broadcast message.

[0032] Figure 8 According to some embodiments, there is an external exclusion zone Figure 6 Representation of a broadcast message.

[0033] Fig. 9 According to some embodiments, there is an internal exclusion zone Figure 6 Representation of a broadcast message.

[0034] Fig.10 is a periodic exclusion zone according to some embodiments Figure 6 Representation of a broadcast message.

[0035] Fig.11 is a combination of exclusion zone types according to some embodiments Figure 6 Representation of a broadcast message.

[0036] Fig.12 is a flow chart illustrating a process for processing a received broadcast message according to some embodiments.

[0037] Those skilled in the art will appreciate that the elements in the drawings are shown for simplicity and clarity and are not necessarily drawn to scale. For example, the size of some elements in the drawings may be exaggerated relative to other elements to help improve the understanding of the embodiments of the present disclosure.

[0038] In the drawings, apparatus and method components are represented by conventional symbols where appropriate, and only those specific details relevant to understanding the embodiments of the disclosure are shown so as not to obscure the disclosure with details that would be apparent to one of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0039] Before explaining any embodiment of the present disclosure in detail, it should be understood that the present disclosure is not limited in its application to the construction details and arrangement of components set forth in the following description or shown in the accompanying drawings. The present disclosure is capable of other embodiments and can be practiced or carried out in various ways.

[0040] One or more embodiments are described and illustrated in the following description and accompanying drawings. These embodiments are not limited to the specific details provided herein and may be modified in various ways. In addition, there may be other embodiments not described herein. In addition, the functions described herein as being performed by one component may be performed by multiple components in a distributed manner. Similarly, the functions performed by multiple components may be merged and performed by a single component. Similarly, the components described as performing specific functions may also perform additional functions not described herein. For example, a device or structure that is "configured" in a certain way is configured at least in that way, but may also be configured in an unlisted manner. In addition, some embodiments described herein may include one or more electronic processors configured to perform the described functions by executing instructions stored in a non-transitory computer-readable medium. Similarly, the embodiments described herein may be implemented as non-transitory computer-readable media storing instructions executable by one or more electronic processors to perform the described functions. As used herein, "non-transitory computer-readable media" includes all computer-readable media, but does not include temporary propagation signals. Therefore, non-transitory computer-readable media may include, for example, hard disks, CD-ROMs, optical storage devices, magnetic storage devices, ROM (read-only memory), RAM (random access memory), register memory, processor cache, or any combination thereof.

[0041] In addition, the wording and terminology used herein are for descriptive purposes and should not be considered as limiting. For example, the use of "including", "containing", "comprising", "having" and its variants herein is meant to cover the items listed hereafter and their equivalents and additional items. The terms "connect" and "couple" are widely used and cover direct and indirect connections and couplings. In addition, "connect" and "couple" are not limited to physical or mechanical connections or couplings, and may include electrical connections or couplings, whether direct or indirect. In addition, electronic communications and notifications may be performed using wired connections, wireless connections, or a combination thereof, and may be transmitted directly or through one or more intermediary devices on various types of networks, communication channels, and connections. In addition, relational terms such as first and second, top and bottom, etc. may be used herein only to distinguish one entity or action from another entity and action, without necessarily requiring or implying any actual such relationship or order between such entities or actions.

[0042] Figure 1A general utility network 100 is shown according to some embodiments. The network 100 may include a utility system 102. The utility system 102 may be associated with a particular utility (e.g., electricity, gas, water, etc.), a particular region, a particular customer, and / or a combination thereof. In other examples, the utility system 102 may be any type of utility system configured to control or manage one or more aspects of a utility network (such as the utility network 100). In one example, the utility system 102 may be or include a server or cloud-based system that allows the utility to monitor and / or control various aspects of the associated utility network 100. The utility network 100 may also include a plurality of utility devices 104a-104f. The utility devices may include meters, sensor modules, communication devices, and the like. For example, the utility devices 104a-104f may include various sensor modules, such as voltage sensors, current sensors, methane sensors, humidity sensors, flow sensors, liquid level sensors, gas concentration sensors, tension sensors, position sensors, temperature sensors, wind sensors, arc sensors, and / or any other sensors used within a utility system. The utility devices 104a-f may be configured to sense one or more parameters associated with a utility system, such as gas (e.g., methane), humidity, temperature, current, voltage, arc, water or other liquid level, gas pressure, and / or other parameters associated with a given utility system.

[0043] like Figure 1 As shown, utility devices 104a-f are generally configured to communicate with utility system 102. One or more of utility devices 104a-f may communicate with utility system 102 using wireless communication protocols such as Bluetooth, Wi-Fi, RF, LoRA, Wi-Max, proprietary RF communication protocols such as Aclara RF from Aclara Technologies, LLC, and / or other applicable wireless communication protocols to communicate data between one or more utility devices 104a-f and utility system 102. In some examples, one or more of utility devices may communicate with utility system 102 using wired communication protocols such as Ethernet, Firewire, USB, RS-232, or other applicable wired communication protocols.

[0044] In general, the utility system 102 may broadcast one or more messages to communicate with the utility devices 104a-f. The broadcasted message may include multiple data packets for one or more of the utility devices 104a-f. However, the broadcasted message may not include data packets for some of the utility devices 104a-f. For example, the broadcast message may include data packets for the utility devices 104a-104d without including any data packets associated with the utility devices 104d-104f. The data packets may include instructions for one or more of the utility devices 104a-f, such as changing the configuration of the corresponding utility devices 104a-f, providing / transmitting data (e.g., sensor data) to the utility system 102, or other instructions as required by a given application. The systems and processes described herein are configured to allow the utility devices 104a-f to efficiently determine whether the broadcast message includes one or more data packets associated with a particular utility device 104a-f.

[0045] Figure 2 1 is a block diagram of a utility device 150 according to some embodiments. The utility device 150 may be similar to the one described above with respect to Figure 1 Utility devices 104a-f are described herein and should be understood to be interchangeable herein. Each utility device 150 may include an environmentally sealed housing (not shown). Such a housing may be made of any suitable material, including materials used for components used in external locations, such as external utility systems (meters, power lines, substations, etc.).

[0046] The utility device 150 may include one or more sensors 152. The sensors 152 may include gas detection sensors, gas concentration sensors, pressure sensors, voltage sensors, current sensors, temperature sensors, light sensors, corrosion detection sensors, chemical presence sensors, flow sensors, tilt sensors, vibration sensors, acceleration sensors, velocity sensors, volume sensors, pH sensors, conductivity sensors, oxidation sensors, chlorine sensors, chlorophyll sensors, algae sensors, humidity sensors, resistance sensors, inductance sensors, liquid level sensors, sound / acoustic sensors, proximity sensors, and / or other sensors as required for a given application. In one embodiment, the sensor 152 may be any sensor used in a gas, water, wastewater, or power utility space. The utility device 150 may also include a user interface 154. The user interface 154 may include one or more inputs to allow a user (such as a technician) to control, modify, or otherwise provide instructions to the utility device 150, as described in more detail below. In some examples, user interface 154 may also include a display to provide a visual indication of one or more parameters of utility device 150, such as communication status, sensor readings, configuration data, and / or other information as applicable to a given application. In some embodiments, the display may be used as an input device and an output device, such as where the display is a touch screen device. Utility device 150 may also include a location sensor 156 (e.g., GPS, Glonass). Location sensor 156 may provide a location of utility device 150.

[0047] like Figure 2 As shown, utility device 150 also includes electronic processor 158, memory 160, power source 162, and communication interface 164. Sensor 152 and position sensor 156 are configured to provide one or more sensed values ​​to electronic processor 158. User interface 154 may provide input to electronic processor 158 and receive output from electronic processor 158.

[0048] The memory 160 may include a read only memory (ROM), a random access memory (RAM), other non-transitory computer readable media, or a combination thereof. The electronic processor 158 is configured to communicate with the memory 160 to store data and retrieve stored data. The electronic processor 158 is configured to receive instructions and data from the memory 160 and execute various instructions, processes, applications, etc., among other things. In particular, the electronic processor 158 executes instructions stored in the memory 160 to perform one or more of the processes described herein.

[0049] In one embodiment, the power source 162 is configured to provide power to various components of the utility device 150. In some embodiments, the utility device 150 receives external power, and the power source 162 converts and distributes the external power to various components of the utility device 150. Utility devices 150 that are capable of or configured to receive power from an external power source (e.g., mains power) are referred to as unconstrained devices. In some examples, the power source 162 includes a battery (e.g., lithium-ion, lithium iron phosphate, nickel-cadmium, etc.). In some instances, the battery may be the sole power source, or may be configured to provide backup power when external power is unavailable. In the case where the power source 162 is a battery (or other energy storage device) and is the sole power source (or used in conjunction with non-mains power, such as solar power), the utility device 150 is referred to as a constrained device.

[0050] The communication interface 164 (e.g., a transceiver) allows communication between the electronic processor 158 and one or more external devices (such as the utility system 102). In some embodiments, the communication interface 164 may include separate transmitting and receiving components. In one embodiment, the communication interface 164 includes a wireless transceiver that is configured to encode information received from the electronic processor 158 into a carrier wireless signal and transmit the encoded wireless signal to one or more external devices and / or communication networks, as described above. The communication interface 164 may also be configured to decode information received from one or more external devices and provide the decoded information to the electronic processor 158.

[0051] The communication interface 164 may communicate with devices and / or networks via various communication protocols, such as using a power line network or a wireless network (eg, In one embodiment, the communication interface 164 may communicate using a combination of communication protocols, such as Wi-Fi, Wi-Max, cellular (3G, 4G, 5G, LTE), RF, LoRa, Zigbee, and / or other wireless communication protocols suitable for a given system or installation). In one embodiment, the communication interface 216 may use a proprietary wireless communication protocol, such as Aclara RF from Aclara Technologies, LLC. Additionally, in one embodiment, the communication interface 164 may communicate using a combination of communication protocols, such as those described above. For example, the communication interface 164 may be configured to communicate over a combination of cellular, BLUETOOTH, and powerline networks, thereby allowing the communication interface to communicate with multiple devices, such as the utility system 102 ( Figure 1 However, other combinations of communication protocols may be appropriate for a given application.

[0052] Now go to Figure 3, describes a process 200 for adding a device, such as a utility device 150, to a utility network, such as the utility network 100, according to some embodiments. At process block 202, a network ID is assigned to the utility device 150. In one embodiment, the utility devices 150 within the system may be assigned a unique network ID. In some examples, the unique network ID may be an integer value from 1 to N, where N is the total number of utility devices 150 within the utility network. In other examples, the unique network ID may be an alphanumeric value from 1 to N, where N is the total number of utility devices 150 within the utility network. The unique network ID may be a unique ID that is different from the unique ID assigned to the utility device 150 during manufacturing. By assigning unique network IDs to all utility devices within the utility network 100, the utility system 102 is able to more efficiently direct messages to one or more desired utility devices 150 within the utility network 100 because the unique network IDs assigned to the various utility devices 150 fall within a limited set of values ​​as described above.

[0053] In some examples, the utility system 102 can be configured to automatically generate a unique network ID based on the order in which the utility devices 150 are added to the utility network 100. In other examples, additional intelligence can be used when assigning a unique network ID to the utility device 104. For example, the assigned unique network ID can be based on the type of utility device (e.g., sensor, meter, communication module, etc.) so that the type of device can have a unique network ID that is grouped together. In other examples, the assigned unique network ID can be based on the location of the utility device 104 so that devices within a certain area or location are grouped together. In yet other examples, a unique network ID can be assigned based on the type of utility associated with the utility device 150 (e.g., gas, electricity, water, sewage). It should be understood that a unique network ID can be assigned using one or more of the above factors or other considerations required by a given application. In some examples, one or more multicast IDs can also be assigned to the utility device 150. The multicast ID may be associated with a group of utility devices 150 that are intended to receive the multicast message, including data packets intended for each device having a corresponding multicast ID.

[0054] At process block 204, a device type is assigned to the utility device 150. In some examples, the device type defines whether the device is a constrained device (e.g., battery powered) or an unconstrained device (e.g., mains powered). In other examples, other device characteristics may be assigned at process block 204, such as sensor type, device configuration, system association, etc.

[0055] At process block 206, the utility device 150 is added to the utility network 100. In some examples, the utility device 150 is added to the utility network by storing a unique device ID in the utility system 102 along with other characteristics of the utility device 150, such as device type, location, functionality, and / or other characteristics as required for a given application.

[0056] Now go to Figure 4 , a process 300 for generating a broadcast message according to some embodiments is described. For purposes of this disclosure, the process 300 will be described as being performed by the utility system 102. However, it should be understood that the utility network 100 and / or one or more devices within the network system 102 may perform some or all of the functions described in association with the process 300. As described above, a broadcast message may include multiple unicast messages having data packets for one or more utility devices 150 within the utility network 100. In some examples, the broadcast message may be directed to all utility devices 150 within the utility network 102. However, the broadcast message typically includes unicast messages for a subset of the utility devices 150 within the utility network 100. Therefore, as will be described in more detail below, the broadcast message may be configured to include a header to allow the utility device to efficiently determine whether the broadcast message includes any relevant data packets for the receiving utility device. Although the broadcast message is described above as including one or more unicast messages, it is contemplated that the process 300 is also applicable to generating a broadcast message having a multicast message having data packets intended for a group of utility devices 150. For the multicast message, the multicast ID of the utility device 150 may be used in place of the unique network ID, as described above.

[0057] At process block 302, a transmission message is generated that includes one or more unicast messages intended for one or more utility devices 150 in the utility network 100. Although not described, the transmission message may include one or more multicast messages in addition to or in lieu of the unicast messages. As described above, the unicast message may include a data packet intended for one or more utility devices 150. The generated transmission message may include a header and one or more information areas. Now briefly turning to the Figure 5, shows a transmission message 400 generated according to an example of some embodiments. The generated transmission message 400 includes multiple information regions, such as a common control region (“common control region, CCR”) 402, a broadcast information region (“broadcast information region, BIR”) 404, a constrained device information region (“constrained device information region, CIR”) 406, a shared information region (“sharedinformation region, SIR”) 408 and / or an unconstrained device information region (“unconstrained device information region, UIR”) 410.

[0058] At process block 304, a header is generated based on the generated transmission message. The header may include various information about the generated transmission message, as will be described in more detail below. The header includes data that may allow one or more utility devices 150 receiving the broadcast message to determine whether the broadcast message includes a data packet suitable for receiving the utility device 102. In one embodiment, the header is the CCR 402 described above, and these terms are understood to be used interchangeably herein. The CCR 402 may be generated based on the data contained within the generated transmission message 400. For example, the CCR 402 may include information about whether there is a data packet for a group of devices within the generated transmission message 400. For example, the CCR 402 may indicate whether the associated generated transmission message includes data associated with a broadcast type message, which is intended for all devices receiving the generated transmission message. Other data may include whether the associated generated transmission message includes data associated with a constrained device, which is intended for all devices designated as constrained devices (e.g., battery powered). Other data may include whether the associated generated transmission message includes data associated with a shared device, which is intended for all messages directed to sub-segments of both constrained devices and unconstrained devices. Finally, the header may include data that may include whether the associated generated transmission message includes data associated with an unconstrained device, which is intended for all devices that are designated as unconstrained devices (eg, mains powered).

[0059] The CCR 402 may be of known length and may include an explicit indication of what type of information is contained in the payload of the data packets contained in the generated transmission message. Such explicit indication enables both constrained and unconstrained devices to make real-time decisions about whether to process the data packets within the generated transmission message. Table 1, shown below, provides a first possible configuration of the CCR region.

[0060]

[0061] Table 1 - CCR frame multiplexing control information elements

[0062] As shown in Table 1, CCR 402 may provide an indication of whether the generated transmission message includes a broadcast information packet in BIR 404, a constrained device information packet in CIR 406, a shared information packet in SIR 408, and / or unconstrained device information in UIR 410. The CIR may also include information elements associated with unique network ID-based operations, such as a flag indicating that unique network ID-based operations are required, a unique network ID range, a minimum target unique target ID, a maximum network ID range, and other information as required by a given application. Table 2 shown below provides a second possible configuration of the CCR region.

[0063]

[0064] Table 2 - CCR frame multiplexing control information elements

[0065] As shown in Table 2, CCR 402 may provide an indication of whether a generated transmission message includes a broadcast information packet in BIR 404, a restricted device information packet in CIR 406, a shared information packet in SIR 408, and / or an unrestricted device information packet in UIR 410. CCR 402 may also include information elements associated with one or more exclusion zone rules (described in detail below) and a target unique network ID value. CCR 402 is designed to allow a receiving device to efficiently determine whether a generated transmission message includes any packets associated with a receiving utility device 150, as will be described in more detail below.

[0066] The BIR region 404 may include packets associated with a broadcast type message for all utility devices 150 that are capable of receiving the generated transmission message 400. The CIR 406 may include packets associated with only constrained devices. The SIR 408 may include packets associated with both constrained and unconstrained devices, and the UIR 410 may include packets associated with only unconstrained devices.

[0067] Thus, CCR 402, as described above, provides data to allow the associated utility 150 to determine whether a generated transmission message is relevant. The following figures provide various examples of how a header may organize, group, or otherwise define a portion of a possible unique network address to which a generated transmission message is associated.

[0068] As described above, CCR 402 may include one or more rules for generating exclusion zones for groups of devices, such as constrained devices. This may allow constrained devices to efficiently determine whether a generated transmission message 400 includes a packet directed to an unconstrained device based on their unique network IDs when determining that the generated transmission message 400 includes a packet directed to an unconstrained device. Figure 6 , shows a line diagram representing a generated transmission message 500 directed to a plurality of utility devices, such as utility devices 104a - f , according to some embodiments. Figure 6 A common and known broadcast transmission is shown, where the message is broadcast to all utilities, but directed only to specific utilities. Figure 6 As shown, the generated transmission message is only related to the utility devices 502, 504, 506, and 508. It should be understood that the utility devices 502, 504, 506, and 508 can be similar to the utility devices described herein, including the utility devices 104a-f. Figure 6 As shown, utility device 502 may have the smallest unique network ID, and utility device 504 may have the largest unique network ID (eg, the value closest to N, where N is the total number of utility devices within the utility network).

[0069] exist Figure 6 In the example of , no rules or other data may be provided in the header associated with the generated transmission message 500, such that when the generated transmission message 500 is broadcast, any utility device receiving the generated transmission message 500 will be required to monitor the entirety of the generated transmission message to determine whether any data packets within the generated transmission message are associated with the receiving utility device. This requires the receiving utility device to remain in a monitoring mode for the entire duration of the generated transmission message, which may increase energy consumption of the corresponding utility device.

[0070] Now go to Figure 7 , shows a modified generated transmission message 600 according to some embodiments. The modified generated transmission message 600 includes an inclusion area 602 and an exclusion area 604. Figure 7As shown, the inclusion zone is configured to include all unique network IDs greater than or equal to the unique network ID of the utility device (in this case, utility device 502) with the smallest unique network ID. Thus, the exclusion zone 604 includes all utility devices with unique network IDs less than the unique network ID of utility device 502. The inclusion zone 602 and the exclusion zone 604 may be defined by a header associated with the generated transmission message 600, such as described above. For example, the header may include a unique network ID associated with utility device 502 and one or more rules in the header (such as CCR 402 described above). The rules provide an indication that no data packets within the generated transmission message 600 are for utility devices with unique communication ID values ​​less than the unique communication ID of utility device 502. Thus, by reading the header of the generated transmission message upon receipt, utility devices in the utility network with unique network ID values ​​less than utility device 502 may quickly determine that the generated transmission message 600 is not relevant to them and may resume operation in a sleep or standby mode, as will be described in more detail below.

[0071] Now go to Figure 8 , shows a transmission message 700 generated by an external exclusion zone according to some embodiments. The transmission message 700 generated by the external exclusion zone includes an inclusion zone 702, a first exclusion zone 704, and a second exclusion zone 706. Figure 8As shown, the inclusion zone 702 is configured to include all unique network IDs associated with the utility devices 502, 504, 506, 508 that are intended recipients of the transmission message 700 generated by the external exclusion zone. The first exclusion zone 704 includes all utility devices having a unique network ID less than the utility device with the lowest unique network ID value (such as the utility device 502). The second exclusion zone includes all utility devices having a unique network ID value greater than the utility device with the highest unique network ID value (such as the utility device 508). The inclusion zone 702 and / or the first exclusion zone 704 and the second exclusion zone 706 can be defined by a header associated with the transmission message 700 generated by the external exclusion zone, such as described above. For example, the header can include a unique network ID associated with the utility device 502 and a unique ID associated with the utility device 508, as well as one or more rules or other functions. The rules provided in the header may provide an indication that the transmission message 700 generated by the external exclusion zone does not include packets for utility devices having a unique network ID value lower than the unique network ID associated with utility device 502 and a unique network ID value higher than the unique network ID associated with utility device 508. Thus, by reading the header when receiving the transmission message 700 generated by the external exclusion zone, any utility device in the utility network having a unique network ID value lower than utility device 502 or higher than utility device 508 may determine that the transmission message 700 generated by the external exclusion zone is not relevant and resume operating in a sleep or standby mode, as will be described in more detail below.

[0072] Now go to Fig. 9 , shows a transmission message 800 generated by an internal exclusion zone according to some embodiments. The transmission message 800 generated by the internal exclusion zone includes a first inclusion zone 802, a second inclusion zone 804, and an exclusion zone 806. Fig. 9As shown, the first inclusion zone includes the unique network IDs associated with the utility devices 502, 504, 506, and the second inclusion zone 804 includes the unique network ID associated with the utility device 508, so that all intended recipient utility devices are included in the first inclusion zone 802 or the second inclusion zone 804. The exclusion zone 806 includes all utility devices having a unique network ID value between the unique network ID value of the utility device 506 and the unique network ID value of the utility device 508. The first inclusion zone 802, the second inclusion zone 804, and the exclusion zone 806 can be defined by a header associated with the transmission message 800 generated within the internal exclusion zone, such as described above. For example, the header can include the unique network ID associated with the utility device 506 and the unique network ID associated with the utility device 508. The header can also include one or more rules or other functions. The rules provided in the header may provide an indication to a utility device receiving the internal exclusion zone generated transmission message 800 that a utility device having a unique network ID value between the unique network ID value of utility device 506 and the unique network ID value of utility device 508 may ignore the message because there are no packets intended for utility devices having unique network ID values ​​within that range. Thus, by reading the header when receiving the internal exclusion zone generated transmission message 800, any utility device in the utility network having a unique network ID value between the unique network ID value of utility device 506 and the unique network ID value of utility device 508 may determine that the internal exclusion zone generated transmission message 800 is not relevant and resume operating in a sleep or standby mode, as will be described in more detail below.

[0073] Now go to Fig.10, shows a transmission message 900 for periodic exclusion zone generation according to some embodiments. The transmission message 900 for periodic exclusion zone generation includes a plurality of inclusion zones 902, 904, 906, and 908, and a plurality of exclusion zones 910, 912, 914, 916, and 918. The inclusion zones 902, 904, 906, 908 and / or the exclusion zones 910, 912, 914, 916, 918 may be based on one or more functions, such as a modulo ("mod") function. For example, a mod function such as mod3, mod4, mod5, mod6, mod8, and / or mod16 may be used to define the exclusion zones 910, 912, 914, 916, 918. Although the above functions are described as mod functions, it is contemplated that other functions may also be used. In one embodiment, a utility system (such as utility system 102) that generates a periodic exclusion zone generated transmission message 900 can determine an appropriate periodic function that ensures that all utility devices having data packets within the generated message are outside of the exclusion zones 910, 912, 914, 916, 918.

[0074] The inclusion zones 902, 904, 906, 908 and exclusion zones 910, 912, 914, 916, 918 may be defined by a header associated with the periodic exclusion zone generated transmission message 900, such as described above. For example, the header may include a unique network ID associated with the utility device 502 and a unique network ID associated with the utility device 508. The header may also include one or more rules as described above. The rules provided in the header may provide an indication to a utility device receiving the periodic exclusion zone generated transmission message 900 that a function, such as a mod function based on at least one unique network ID value (such as the unique network ID value associated with the utility device 502), is required to determine which utility devices are intended recipients of the periodic exclusion zone generated transmission message 900. Thus, by reading the header and performing a required function (e.g., a mod function) upon receiving a periodic exclusion zone generated transmission message 900, the receiving utility device can determine whether the periodic exclusion zone generated transmission message 900 is relevant to the receiving utility device (e.g., contains a data packet for the receiving utility device). In response to the receiving utility device determining that the received periodic exclusion zone generated transmission message 900 is not relevant, the receiving utility device can resume operating in a sleep or standby mode, as will be described in more detail below.

[0075] Now go to Fig.11, shows a transmission message 1000 generated by a multi-function exclusion zone according to some embodiments. The transmission message 1000 generated by a multi-function exclusion zone can use various functions to create multiple exclusion zones. For example, the first exclusion zone 1002 can include any utility device having a unique network ID value less than the unique network ID value of the utility device 502. The exclusion zones 1004, 1006 can be based on a periodic function, such as a mod function, and the exclusion zone 1008 can be based on a combination of the periodic functions and is also configured to include all utility devices having a unique network ID value greater than the unique network ID value of the utility device 508.

[0076] Similar to the above, the exclusion zones 1002, 1004, 1006, 1008 may be determined by a receiving device using a header associated with a multi-function exclusion zone generated transmission message 1000. For example, the header may include a unique network ID associated with the utility device 502 and a unique network ID associated with the utility device 508. The header may also include one or more rules as described above. The rules provided in the header may provide an indication to a utility device receiving a multi-function exclusion zone generated transmission message 1000 as to what functions, unique network ID values, etc. are required to determine which utility devices are the intended recipients of the multi-function exclusion zone generated transmission message 1000. Thus, by reading the header and performing the required functions and / or evaluations when receiving a multi-function exclusion zone generated transmission message 1000, the receiving utility device may determine whether the multi-function exclusion zone generated transmission message 1000 is related to the receiving utility device (e.g., contains a data packet for the receiving utility device). In response to the receiving utility device determining that the received multi-function exclusion zone generated transmission message 1000 is not relevant, the receiving utility device may resume operating in a sleep or standby mode, as will be described in greater detail below.

[0077] The above example message types and their respective inclusion / exclusion zones are for exemplary purposes, and it is understood that various other functions may be used to set exclusion zones, such as even / odd unique network ID value rules, multiple range rules, etc. Furthermore, the above functions and rules may be expanded or varied as needed for a given application.

[0078] Now back to Figure 4 At process block 306, the generated transmission message including the generated header is broadcast as a broadcast message at process block 306. The broadcast message may be transmitted using a wireless communication protocol as described above.

[0079] Now go to Fig.12, describes a process 1100 for processing broadcast messages at a utility device (such as utility device 150) according to some embodiments. At process block 1102, utility device 150 operates in a standby mode. In some examples, standby mode can be described as a sleep mode. In standby mode, utility device 150 is generally configured to consume a minimum amount of power. For example, utility device 150, when operating in standby mode, is generally unable to receive communications from other devices (such as utility system 102). At process block 1104, utility device 150 enters a receive mode for receiving communications. In some examples, utility device 150 enters receive mode at set periodic intervals. Example periodic intervals can be 30 second intervals, 30 minute intervals, etc. However, any interval can be used as needed for a given application. In other embodiments, such as where the utility device includes a real-time clock, the utility device 150 may enter the receive mode at certain times of the day, which may allow multiple utility devices 150 to enter the receive mode in synchronization with the utility network 100. When in the receive mode, the utility device 150 is configured to receive messages, such as wireless messages broadcast by the utility system 102. In some examples, the utility device 150 is configured to operate in the receive mode for a predetermined time.

[0080] At process block 1106, the utility device determines whether a broadcast message has been received. In one embodiment, the broadcast message is transmitted by the utility system 102, such as via a wireless communication protocol as described above. In response to determining that no broadcast message has been received, the utility device 150 returns to standby mode at process block 1102. In response to determining that a broadcast message has been received, the utility device 150 analyzes a header of the received broadcast message at process block 1108. In some embodiments, the header may be the CCR 402 described above. The utility device 150 may analyze the header of the received broadcast message to determine whether the broadcast message is related to the utility device 104 (e.g., includes any data packets for the utility device 104). As described above, the header may include various information, such as which data areas (e.g., BIR 404, CIR 406, SIR 408, and / or UIR 410) have associated data packets within the received broadcast message. The utility device 150 may use the header to determine whether any information areas with the data packet are applicable to the utility device 150 .

[0081] At process block 1110, the utility device 150 determines whether any relevant desired information is present within the received broadcast message. For example, the utility device 150, based on the device type (e.g., constrained or unconstrained), may evaluate the header to determine whether any data packets are relevant to the utility device 150. For example, where the utility device 150 is a constrained device, the utility device 150 may determine that no data packets are applicable in response to the header indicating that data packets are present only in the unconstrained data region. Conversely, in response to the header indicating that data packets within the information region of the broadcast message are relevant, such as where data is present in the BIR 404 and / or CIR 406, the utility device 150 may determine that relevant data packets are present within the received broadcast message.

[0082] In response to determining that no relevant data is present in the received broadcast message, the utility device resumes operating in the standby mode at process block 1102. In response to determining that relevant data is present, the utility device processes the data packets in the BIR 404 at process block 1112. The BIR 404 is processed first because it is presented first in the message, as described above. However, other messages may be arranged as needed for a given application, and it is understood that process 1100 may be adjusted accordingly. In response to processing the data packets within the BIR 404, the utility device 150 determines at process block 1114 whether there are any additional relevant data packets in the message (e.g., relevant data in the CIR 406, SIR 408, and / or UIR 410). In response to determining that no additional relevant data packets remain in the received broadcast message, the utility device 150 resumes operating in the standby mode at process block 1102. In response to determining that additional relevant data packets remain in the received broadcast message, the utility device processes the data packets in the CIR 406 at process block 1116 .

[0083] In response to processing the packets in CIR 406, utility device 150 determines at process block 1118 whether there are any additional relevant packets in the received broadcast message (e.g., relevant data in SIR 408 and / or UIR 410). In some examples, utility device 150 may be configured to know whether it is part of any shared group that would require packets in SIR 408. However, in other examples, utility device 150 may be configured such that any indication of packets in SIR 408 requires SIR 408 to be processed for possible relevant data. In response to determining that no additional relevant packets are in the received broadcast message, utility device 150 resumes operating in standby mode at process block 1102. In response to determining that additional relevant packets remain in the received broadcast message, utility device 150 processes SIR 408 at process block 1120. In response to processing SIR 408, utility device 150 determines whether there are any additional relevant data packets in the received broadcast message (e.g., relevant data in SIR 408 and / or UIR 410) at process block 1122. In response to determining that no additional relevant data packets are in the received broadcast message, utility device 150 resumes operating in standby mode at process block 1102. In response to determining that additional relevant data packets remain in the received broadcast message, utility device 150 processes UIR 410 at process block 1124. In response to processing UIR 410, utility device 1102 resumes operating in standby mode at process block 1102.

[0084] Although not described in detail, utility device 150 may use one or more rules in CCR 402 to process the information area and, in particular, the data in CIR 406, as described above.

[0085] In the foregoing description, specific embodiments have been described. However, it will be appreciated by those skilled in the art that various modifications and changes may be made without departing from the scope of the disclosure as set forth in the following claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present teachings.

[0086] Various features and advantages of some embodiments are set forth in the following claims.

Claims

1. A utility device in a utility system, comprising: power supply; Communication interface; and One or more electronic processors, wherein the one or more electronic processors are configured to: Periodically switch from standby mode to receiving mode; monitoring broadcast messages while in said receiving mode; receiving the broadcast message via the communication interface while in the receiving mode; analyzing a header of a received broadcast message to determine whether any packets within the broadcast message are relevant, wherein determining whether packets within the received broadcast message are relevant comprises determining whether the received broadcast message includes one or more packets within one or more information regions associated with a device type of the utility device; and In response to determining that the received broadcast message does not include any relevant data packets, resuming operation in the standby mode.

2. The utility device according to claim 1, wherein: The one or more electronic processors are further configured to process the broadcast message in response to determining that the broadcast message includes one or more related data packets.

3. The utility device according to claim 1, wherein: The header includes one or more indications of which of the one or more information areas contains one or more data packets associated with a device type of the utility device.

4. The utility device according to claim 1, wherein: The one or more information areas include at least one selected from the group consisting of a broadcast information area, a restricted device information area, a shared device information area, and an unrestricted device information area.

5. The utility device according to claim 1, wherein: The information area is associated with a particular device type of one or more utility devices within the utility system.

6. The utility device of claim 1, wherein: The utility device is one of a constrained device and an unconstrained device.

7. The utility device according to claim 6, wherein: The constrained device has a limited power source.

8. The utility device according to claim 7, wherein: The limited power source is a battery.

9. A method for generating a broadcast message within a utility network, comprising: generating a broadcast message, wherein the broadcast message includes one or more data packets associated with one or more utility devices; generating a header for the generated broadcast message, wherein the generated header includes data indicating applicability of the included one or more data packets to the one or more utility devices; and Deliver the generated message.

10. The method according to claim 9, wherein: The data includes an indication that one or more data packets within the generated broadcast message are intended for a group of devices within the utility network.

11. The method according to claim 9, wherein: The data includes an indication that one or more data packets within the generated broadcast message are intended for constrained devices or unconstrained devices.

12. The method according to claim 11, wherein: The constrained device is a battery powered device.

13. The method according to claim 9, wherein: The generated broadcast message includes a plurality of information areas, wherein the plurality of information areas include at least one selected from the group consisting of a public control area, a broadcast information area, a restricted device information area, a shared information area, and an unrestricted device information area.

14. The method according to claim 13, wherein: The common control area includes the header.

15. A method for analyzing a broadcast message at a utility device, comprising: periodically switching from a first mode to a second mode; receiving a broadcast message via the communication module when in the second mode; analyzing a header of a received broadcast message to determine whether the received broadcast message includes one or more data packets within one or more information regions associated with a device type of the utility device; In response to determining that the received broadcast message includes one or more data packets within one or more information areas associated with a device type of the utility device, determining whether the received broadcast message is a relevant message; and In response to determining that the received broadcast message is a related broadcast message, the received broadcast message is processed.

16. The method according to claim 15, wherein: The first mode is a standby mode, and the second mode is a receiving mode.

17. The method according to claim 15, further comprising: Responsive to determining that the received broadcast message is not a relevant broadcast message, resuming operation in the first mode.

18. The method according to claim 15, wherein: The header includes one or more indications of which of the one or more information areas contains a data packet associated with a device type of the utility device.

19. The method according to claim 15, wherein: The information area includes at least one selected from the group consisting of a broadcast information area, a restricted device information area, a shared device information area, and a restricted device information area.

20. The method according to claim 19, wherein: The constrained devices are battery powered devices.