WO2008086231A2 - Utility data collection and reconfigurations in a utility metering system - Google Patents

Abstract

A one-and two-way wireless data collection system for a utility metering environment includes multiple endpoints with wireless transceivers, and a collector with transceiver for communicating with the endpoints.

Description

UTILITY DATA COLLECTION AND RECONFIGURATIONS IN A UTILITY METERING SYSTEM

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to United States Provisional Patent Application No. 60/883,490, filed January 4, 2007, entitled "Mobile Demand Reset," which is herein incorporated by reference, in its entirety, including appendices.

BACKGROUND

Five to ten percent of electric utility meters are installed on what are known as C&l (Commercial and Industrial) accounts, which often have large-scale power needs. The utility meters installed on such C&l accounts are typically more sophisticated than the basic residential watt-hour meter. For example, these meters may measure more parameters than simple watt-hour consumption, including time of use (TOU) and demand values that represent the highest, or peak, power demand over a unit of time. Typically, such demand data is accumulated over a billing cycle that is approximately one month in length. Accordingly, as part of collecting consumption, demand, and TOU data, it is desirable for a utility to be able to reset a meter (particularly the demand value) after information collection takes place, which typically occurs once every billing cycle.

In many of today's systems, the demand value at a meter is reset by: physically depressing a switch button on the meter, initiating a reset function from a handheld or laptop computer via a serial optical probe and serial data connection, or using an automatic timer or calendar feature that is programmed into the meter. In such systems, recognition of the reset event is not provided proof-positive to the meter reader and inference rules must be applied. This impacts the business rules of many utilities and is not desirable. In addition, some of these approaches disconnect the demand reset from the meter read and results in a mismatch of timestamps that is not favored by utilities. Other systems may allow a demand reset command to be sent to a meter/endpoint device (e.g., via a radio transmission) but do not provide any confirmation that the command was received and executed, resulting in erroneous readings and, ultimately, an unreliable system. Some of the possible undesirable scenarios that might occur in such systems include the following: (a) a data collector sends multiple demand reset requests (in order to ensure that reset occurs) and peak demand is inadvertently reset more than once during a short time period, which causes the loss of peak demand information between readings; (b) a demand reading transmission from meter/endpoint to collector fails and the meter reader receives incomplete data or no data at all, requiring repeated transmission attempts, which is highly inefficient. In a mobile collection or reading environment, such inefficiency can be compounded by further retransmissions to subsequent end points due to the short time the mobile is in optimal range of the end point.

Readings of peak demand information, consumption information, TOU information, and/or other meter-related data are typically made over a serial data connection from a handheld or laptop computer with an attached serial optical probe, which queries various data storage components (e.g., ANSI C 12.19 registers) in the meter to obtain and calculate the desired readings for the utility. Such readings may also be made via radio transmission sent from a meter/endpoint and collected by some type of radio enabled collector system/device. However, there is often the concern that such transmissions may be at least partially unsuccessful and may need to be repeated.

The need exists for a system that overcomes the above problems, as well as one that provides additional benefits. Overall, the examples herein of some prior or related systems and their associated limitations are intended to be illustrative and not exclusive. Other limitations of existing or prior systems will become apparent to those of skill in the art upon reading the following Detailed Description.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic diagram of a mobile collection system showing a mobile collector and multiple meters/endpoints having both one-way and two-way wireless connectivity. Figure 2A is a block diagram showing an example of a mobile collector and a two-way meter/endpoint, which employ aspects of the invention.

Figure 2B is a block diagram showing a more detailed view of the data storage at the meter/endpoint shown in Figure 2A.

Figures 3A and 3B show a sample implementation using a RF to Net or "RF2Net" protocol.

Figure 4 is a message exchange diagram showing an exchange of message between a mobile collector and two end points EP1 and EP2.

Figure 5 is a block diagram of the software layers.

Figure 6 is a state diagram with messaging showing Idle, Synchronized and Non Synchronized Modes.

Note: the headings provided herein are for convenience and do not necessarily affect the scope or interpretation of the invention.

DETAILED DESCRIPTION

Various examples of the invention will now be described. The following description provides specific details for a thorough understanding and enabling description of these examples. One skilled in the art will understand, however, that the invention may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description.

The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the invention. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

Representative System

Figures 1 , 2A, 2B and the following discussion provide a brief, general description of a suitable environment in which aspects of the invention can be implemented. Although not required, aspects and embodiments of the invention will be described in the general context of radio communications and/or computer- executable instructions, such as routines executed by a general-purpose computer, e.g., a server or personal computer. Those skilled in the relevant art will appreciate that the invention can be practiced with other system configurations, including Internet appliances, hand-held devices, wearable computers, cellular or mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers and the like. Aspects of the invention can be embodied in a special purpose computer or data processor or by using other circuitry that is specifically programmed, configured or constructed to perform one or more of the activities explained in detail below. Indeed, the term "computer", as used generally herein, refers to any of the above devices, as well as any data processor or any device capable of communicating with a network, including consumer electronic goods such as game devices, cameras, or other electronic devices having a processor and other components, e.g., network communication circuitry.

The invention can also be practiced in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network ("LAN"), Wide Area Network ("WAN") or the Internet. In a distributed computing environment, program modules or sub-routines may be located in both local and remote memory storage devices. Aspects of the invention described below may be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips (e.g., EEPROM chips), as well as distributed electronically over the Internet or over other networks (including wireless networks). Those skilled in the relevant art will recognize that portions of the invention may reside on a server computer, while corresponding portions reside on a client computer. Data structures and transmission of data particular to aspects of the invention are also encompassed within the scope of the invention.

More specifically, Figures 1 and 2A show aspects of a sample utility data collection environment 100 in which a collection system/device 110 can be used to collect utility data (e.g., consumption data, time of use (TOU) data, peak demand data, etc.) from one or more remotely located meters/endpoints 120 using radio- based mobile/remote techniques. (The terms "meter" and "endpoint" are generally used interchangeably herein, as are the terms "collection system", "collector", "reader" and "drive-by unit".) In the case where the one or more of the meters/endpoints 120 is associated with a C&l account, the system of Figures 1 and 2A allows a demand reset function to be initiated via radio, for example, while the collection system/device 110 is collecting reads (e.g., from other meters on a meter route). In general, however, while performing the meter reading route, the collection system/device 110 may coordinate the reading of one-way meters with the two-way demand reset meters seamlessly to maintain the high read reliability the utility has come to expect from reading just one-way meters.

While a vehicle based collection system 110 is illustrated in Figure 1 , various types of reader devices may be used (either alone or in combination) to implement the collection system/device 110. These include but are not limited to a handheld mobile reader, a fixed remote reader, etc.

As illustrated in Figure 2A, a representative meter/endpoint 120 of the collection environment 100 includes a data storage component 202, a timer and/or clock 203 (optional), a radio module 204, basic circuitry 205, and an antenna 206. In addition to allowing the meter 120 to track time-of-use data related to consumption of the utility, the timer and/or clock 203 may allow the meter 120 to perform functions such as setting a demand reset hold-off. The basic circuitry 205 within the meter 120 may be analog and/or digital circuitry that allows the meter/endpoint to perform functions such as switching from a bubble-up (one-way) mode of communication to a two-way mode of communication, preparing/formatting packets of requested data to send out to the collection system/device 110, clearing, setting, and resetting registers of the data storage component 202 as appropriate (e.g., satisfying a demand reset request), setting and operating timers (e.g., performing a time sync operation, setting a demand reset hold-off timer, etc.), interfacing with the radio module 204, etc. The complexity of the circuitry 205 within respective meters 120 of the utility data collection environment 100 may vary based on the type of account (e.g., residential versus commercial) and other factors (e.g., one-way only or two-way, etc.).

The collection system/device 110 comprises at least one computer 208 having one or more processors, a GPS module, and at least one radio receiver/transceiver 212 that communicate with the meters 120 via an antenna 214 using one-way and/or two way radio communications. Various radio communication/modulation schemes may be used to facilitate RF communications between the meters 120 and the collection system/device 110. These may include a single channel high speed FM link, on-off key (OOK) transmissions (which may improve uplink performance for long packets of data), frequency-shift keying (FSK), or other high speed radio links. Note that a GPS module is not required, but any other device or method may be employed. For example, any source of precision time in the reader for resetting clocks in the meters may be employed; GPS is just one suitable method of implementation.

The computer 208 of the collection system/device may have mapping and/or meter reading software installed upon it, as well as an associated operating system. The collection system 110 (e.g., via its computer 208 or other features) may allow for user interaction via one or more input/output devices (e.g., screen, keyboard, touch pad, mouse/pointing device, microphone, joystick, pen, game pad, scanner, digital camera, video camera, printer, plotter, speakers, tactile or olfactory output devices, etc.). The collection system 110 (e.g., via its computer 208 or other features) may optionally be coupled to external systems/computers via a network connection, wireless transceiver, etc. Accordingly the computer 208 may include features such as a connection port to a network such as a local area network (LAN), wide area network (WAN) or the Internet.

Figure 2B shows a more detailed view of the data storage component 202 of the system. The data storage 202 component may include any type of computer- readable media that can store data accessible by the computer 100, such as magnetic hard and floppy disk drives, optical disk drives, magnetic cassettes, tape drives, flash memory cards, digital video disks (DVDs), Bernoulli cartridges, RAMS, ROMs, smart cards, etc. The data storage component 202 may be configured, for example, as multiple registers, or in other storage configurations. In the illustrated embodiment, the data storage component 202 is configured using a first storage subcomponent 222 for storing demand information for a current time period (e.g., the time period beginning immediately following the most recently executed demand reset) and a second storage subcomponent 224 for storing demand information for one or more previous periods (e.g., a time period ending immediately before the most recently executed demand reset, and possibly previous time periods). In addition, the data storage component 202 includes a TOU storage subcomponent 226 to store time of use data and one or more additional storage subcomponents 228 to store consumption data. The data storage component thus may store multiple pieces of data, any of which may be provided to the collection system. Thus, the meter/endpoint may transmit for storage at the collection system 110 previous demand alone, and/or other data, such as previous TOU, etc.

The arrangement of the storage component 202 and subcomponents 222, 224, 226 and 228 of Figure 2B is intended to illustrate, generally, the types of information stored at the meter/endpoint 120. Certainly, the technology described herein may be implemented using other data storage configurations including storage configurations that comply with industry standards, such as the ANSI C 12.19 standard for TOU and Demand meters, which is a standard commonly used in the United States. The C 12.19 Demand Reset/TOU register typically stores various reading-related parameters in sets of registers. The radio module in the meter takes the desired readings from these sets of registers and packetizes them for transmission to the reader/collector. The register may also contain serial interfaces to connect to external computers as well as the radio module. The C 12.19 Demand Reset/TOU register typically includes a battery-backed clock for maintaining time which is used to capture time-related meter readings. The register can also maintain a calendar that is used to close out demand periods by performing a demand reset based on a schedule in the calendar. Since the serial data rate to most TOU registers is quite slow, and multiple registers may need to be manipulated mathematically to obtain the desired reading, the radio may periodically download this information from the register and cache it, so that the two-way radio transaction will be faster. Communication Flows

The sample system described above with respect to Figures 1 and 2A and 2B may use a two-way protocol (e.g., the RF2Net Protocol) to implement its demand read and/or reset functionality. Of course, other messages or protocols may be employed, such as a combination of standard length consumption messages, variable length messages, and of forth, which provide a migration path from traditional equipment and protocols, and/or for optionally employing Bluetooth, Zigbee or WIFI protocols modified for vehicular operation. Traditionally these commercially available protocols may not be viable for fast moving mobile operation due to excessive acquisition time, signaling performance in a fading environment and typical RF power limitations. However, any wireless protocol may be employed with aspects of the systems described herein.

A successful read and demand reset communication flow begins with a bubble-up or one-way message transmitted from an endpoint, which is intended for receipt by the reader and which can contain minimum necessary information typically needed for a meter reading function. The information may include endpoint Identification number, tamper flag information, consumption information and check sum or other validation data. The start of two-way communications between the endpoint and the reader next begins, where the reader sends a packet containing a data request alone or with a demand reset command. In response to successfully receiving the communication, the endpoint send out a demand read packet containing peak demand information and performs a demand reset. Thereafter, it is assumed that the two-point communication session is completed successfully, and accordingly, the endpoint reinstates a standard bubble-up interval.

The end point/meter meter may include a hold-off timer started shortly following receipt, from the reader, of a packet containing, for example, a demand reset command. If the packet containing the requested demand information is lost or otherwise not received by reader, then the setting of the hold-off timer prevents a subsequently received demand reset command from being executed at the endpoint while the hold-off timer is still running. For example, after realizing that it has yet to receive the requested demand data, the reader (which, in the case of a mobile collection system, may still be performing a driving route around the area of the endpoint) may send a duplicate demand reset communication under the assumption that the first demand reset packet was not received at the endpoint. If it were not for the setting of the hold-off timer, the endpoint would perform a second demand reset, even though it had just performed a demand reset just seconds (or minutes) before. Undesirably, these back to back demand resets if left to occur, may result in the creation of a very short demand interval that is inconsistent with the regular billing cycle period. Thus, the demand reset hold-off timer functionality prevents the creation of an inadvertent, short demand interval, and therefore preserves the integrity of the system.

An example of a suitable demand reset hold-off period might be 24 hours so that the likelihood of the reader resetting the meter more than once while driving a route for the day will be eliminated. While the hold-off timer is described in this example, the system may implement other timer related processes, such as time- stamping transactions and comparing them to one or more time stamps of the last transaction and the meter's clock to determine whether a message was received within or outside of a hold-off period. In some embodiments, the hold-off can be programmed over-the-air (OTA) from the collector where adjustments are required after the meter has been deployed (with no special trip or programmer required). Of course, the system may employ other types of OTA programming, such as correcting the meter's clock, changing TOU schedules, configuration programming of register(s), changing data stored or associated with other registers, etc. In addition to setting the hold-off timer, the meter/endpoint may flag if there was any subsequent unexecuted resets so that follow-up action may be taken if necessary. For example, the flagging of such an event and a related indication sent to the driver or operator of the reader/collector may indicate the need for a drive or walk by in case that problem exists.

In addition to the various aspects of the system that are described herein, the system may optionally or alternatively include other aspects that allow for the successful transmission of demand or other data and/or successful demand reset or other reconfiguration. For example, in some embodiments, the data from multiple registers in the meter may be structured in sub-packets with individual error detection and acknowledgements (ACK mapping) to minimize the amount of data required to be retransmitted if a packet collision occurs. Likewise, in some embodiments, diversity reception may be used to improve reception during RF fading conditions to minimize retransmissions. In the case of electric meters (which do not have the battery constraints of gas and water meters) the meter's receiver might be turned on multiple times or continuously between the meter's bubble-up transmissions to increase the availability of the meter to do two-way communications. In some embodiments, non-ISM band radio frequencies may be utilized for downlink communications (from the collector to the meter). The use of another non ISM-frequency may help to minimize lost reception time due to in-band transmission from the collector. This could facilitate performing additional communication sessions (e.g., using the ANSI C 12.19 communication standard) to interrogate additional registers to meet special reading or programming needs without special visits to the meter, although it might require the reader to stop briefly to perform the longer set of transactions. In such a case, the system may provide some sort of indication to the operator/user of the reader/collector.

In addition to the hold-off timer, or as an alternative to it, the meter may transmit its data, the collector tells the meter it has received the data, and then an acknowledgement (Awk) is provided to confirm a reset is now possible because the meter knows that the collector has received the data. Alternatively or additionally, the system may exchange sequence counters (or the meter may provide a sequence known to the collector) for the reset, where the collector knows a previous sequence counter (e.g. last month's counter value) when it arrives at the meter so that it and/or the meter can compare the new sequence number to the one that was established during last month's visit.

Figures 3A and 3B show scenarios under an "RF2Net" protocol. With this implementation, a multiplicity of electric meters with data storage, such as ANSI C12-19 registers, store reading data and contain a clock to maintain time and a radio system to communicate with collectors are employed, as is a radio-based mobile collection system that consists of a computer, GPS, mapping and meter reading software and radio receivers and transceivers that communicate with the meters. The RF2Net protocol shown in this example implementation supports both mesh networking (Synchronized mode) and mobile (Non-synchronized mode.). Under this embodiment, the radio based mobile collection system waits for a beacon from the meter/endpoint, which is sent every 2 seconds. Once the beacon is received, the mobile collection system sends a beacon on the same frequency (the non-synchronized endpoint listens for 2 seconds on the same channel as the previously sent beacon). The endpoint synchronizes itself to the mobile collection systems. Then two-way communications transpire as shown in Figures 3A and 3B.

FCC regulations may require that the channel must be change every 400 ms maximum. If there are retries of two-way communications due to collisions or other problems, multiple channels may be used because a 400ms time limit may otherwise be exceeded. In the case of a collision or other problem, the message is repeated once on the same channel, and if no answer, a second time, on an alternate channel. This avoids the problem of the mobile collector not knowing if the endpoint has switched off channel or not.

For the MAC layer, exchanged messages are seen as aata messages; requests (Request Monthly Data for example) are contained in the body of the frame (and more particularly in the C12.22 protocol of the API layer). So each message contains an FCS field (forward error correction (FEC) and cyclic redundancy check (CRC)). But the header does not contain the same information as in the network mode. For example, a bit at the beginning of the MAC header may identify a Drive- By Mode frame.

Messages from the drive-by unit/collector to meters should be acknowledged, so that the collector can manage retransmissions. To save time, acknowledgement information may be included in the header of the next message from the meter. In the case where it is not included, a simple ACK message is sent after a timeout. If the collector does not receive the ACK (included or in a message) after the timeout, it repeats the message. In the other side, the collector does not acknowledge messages from the meter.

Drive-By Mode Process

After the collector receives a beacon, it transmits a message to the meter that contains:

The channel that the endpoint has to switch to. The request contained in the body of the frame, which is passed from the MAC up to the API to decode.

Once the endpoint receives a valid message from the collector, it sets a timer after when it will return in the non-synchronized mode, it asks a Physical layer to change frequency according a channel number indicated by the collector, it sets a timer to send a MAC ACK to the collector, and it gives the message to the API layer (via an LLC layer).

A few milliseconds later, the API layer (via the LLC) will normally ask the MAC layer to send the response. The MAC layer will send the acknowledgment of the previous message in the header of the response.

If an Ack timer ends before response from the API layer, an ACK will be sent alone.

If messages are lost due to collisions, the endpoint has nothing to do: It is the collector that will proceed to retry.

If there is no message from the collector for a few seconds, the Drive-By timer ends and the meter returns in non-synchronized mode. See Figure 4.

The collector or MC (mobile collector) will read orphans of the network, that is to say non-synchronized endpoints. The collector or MC is already used for the reading of R300 meters, manufactured by Itron, Inc. of Spokane, WA, and has to keep this functionality. Moreover the drive by unit has the possibility to read endpoints, which are already synchronized with the network and without disturbing it.

- R300 meters randomly send their data every 4 seconds on a random channel. The collector catches their data during driving (since the collector is often installed in a van or other vehicle). If a meter hasn't been read on the way by the van, adaptive software modifies the roadmap of the employee to pass again near the unread meter.

- Non-Synchronized 2-way meters: these endpoints cannot establish a link (or not all the time) with the endpoint and data cannot be collected. The only way to reach them is to go near them with the collector. Two types of operation must be done: • Once a month: the collector, without parking, has to read the monthly data of the unit, resynchronize its clock and reset the maximum demand value. The same actions are done every month.

• Occasionally: the collector downloads to the meter a more important quantity of data, like tariff grids or firmware updates. This exchange of data can be diverse and in the two directions (DB- >EP, EP->DB).

- Synchronized 2-way meters: if these endpoints are already in the network, every kind of operations can already be managed from the concentrator.

I. Drive By unit

The collector is a powerful vehicle-installed device already used in the field for reading residential meters. For the moment, the device is only a receiver that collects 1-way meter data. The system has been designed for collecting data at a speed of 45 miles/hour, i.e. 20meters/s. As meters transmit periodically (e.g. every (4+Δt) seconds) on a random channel, the receiver is sophisticated. The receiver receives the entire ISM band, detects energy of the transmitted preambles, isolates them and can receive simultaneously up to 8 messages on different channels. A transmitter section includes a half-duplex architecture, which means that when the collector transmits, it cannot receive anything. So when the drive-by unit transmits messages to the 2-way meters, it can't receive the R300 data. The less the collector transmits, the less the R300 data collection will be disturbed.

II. Process

Transmission from the collector has to be reduced to a minimum. It is hard to manage full communications with endpoints with a half-duplex architecture and in a small time (20 m/s). Moreover most of communications will happen occasionally.

2 coexisting processes are proposed:

- For monthly operations on non-synchronized meters, a simple process based on requests and answers during the R300 data collection (without parking). - For occasionally operations on both non-synchronized and synchronized meters, a Park & Wait mode, where the collector emulates the behavior of a regular endpoint. a. Park & Wait Mode

The Park & Wait mode is used to do some occasional operations on both non-synchronized meters and synchronized meters. The drive by unit may park near the meter and emulate a regular meter. During this mode collection of R300 meters may not be possible.

- If the meter is still synchronized with the network, the drive-by awaits an endpoint beacon or another type of messages. If there is no traffic, the maximum time to wait is a beacon periodicity (not fixed, between 30s and 2 minutes). It has almost 100% chance to catch it, because the drive-by can listen on all channels simultaneously. Then the drive-by unit synchronizes itself on the network (time slot, channels sequence, etc.), and sends what it wants to the endpoint, as a regular endpoint. This process takes up to a few minutes.

- If the meter is not synchronized (orphans), it is almost the same. The collector awaits a beacon, which is sent every 2 seconds. Once the beacon received, the collector sends a beacon in the adequate frequency (the non-synchronized endpoint listens while 2 seconds on the same channel than the previous sent beacon). The endpoint believes that it has received a message from a synchronized endpoint, and synchronizes itself on the drive-by. Then all communications are possible.

To sum up, to communicate with:

- A synchronized endpoint, the drive-by unit emulates an endpoint with a lower level.

- A non-synchronized endpoint, the drive-by unit emulates a concentrator.

If other endpoints try to synchronize with the drive-by unit, the drive-by has the possibility to refuse the synchronization. Note that while the R300 meter is used as an example, other meters may of course be used. b. Non-Synchronized Data Collection

A task of the collector remains to read monthly data and to reset/adjust some values of non-synchronized endpoints (orphans). These operations are repetitive and can be done while collecting R300 meters. A polling mechanism is used, where the master is the collector, and the non-synchronized meters are the slaves. A non- synchronized endpoint sends a short message (beacon) about every 2 seconds on a random channel and between transmissions, it listens on the same channel as the previous transmissions. So the collector has just to send some specific requests once it receives the endpoint's beacon. In the drive-by request, the drive-by unit indicates to the endpoint on which channel it has to switch to send responses and listen to next requests. The endpoint answers immediately, without attending to repetitions, collisions and so on. The collector will manage repetitions. Once the collector has finished with one endpoint, it polls another.

The two operations, which are normally done, read monthly data and reset maximum demand, take less than 200 ms per endpoint (monthly data=255 bytes with headers, transmissions @19.2kbps). While requesting an endpoint, during reception phases, the drive-by unit can go on listening to R300 messages and other beacons. But with this process it can read only one 2-way meter at once. It has been establish that the collector is in the range of an endpoint for 20 seconds (RF range=200m, 20m/s), in average. So the drive-by unit can read up to (20s)/(0.2s)=100 orphans (if no collisions) in the same cluster. It can be assumed that for a cluster of this size, a concentrator should have been installed, and a fixed network established.

FCC regulations require that the channel must change every 400 ms maximum. If there are repetitions due to collisions, this time can be easily exceed, thus the use of only one channel. The problem is if a collision occurs, the collector won't know if the endpoint has switched channels or not. This issue is solved by repeating the message once on the same channel, and if no answer, the second time, on the asked channel (there are only two choices).

For MAC layer the exchanging messages are seen as Data message, the requests (Request Monthly Data for example) are contained in the body of the frame (and more particularly in the C12.22 protocol of the API layer). So each message contains a FCS field (FEC+CRC). But as the header doesn't contain the same information as in the network mode, a bit at the beginning of the MAC header identify the Drive-By Mode frame.

Messages from drive-by unit to non-synchronized meters have to be acknowledged, so that the drive-by unit can manage repetitions. To save time, acknowledgement information is included in the header of the next message from the meter. In the case there is not, a simple ACK message is sent after a timeout. If the drive-by unit doesn't receive the ACK (included or not in another message) after the timeout, it repeats the message. In the other side, the drive-by doesn't acknowledge messages from the meter.

The MAC header for these operations has been reduced to decrease transmit time of the collector, and less affect the R300 data collection.

For a cluster of 10 orphans (it is assumed that for more, a concentrator has been installed):

With headers, transmitted requests of the drive-by size of about 60 bytes each one, and there are two requests by endpoints. Assuming two tries per endpoint, it gives:

DataRate = RequestSize * NbOβtequests * NbOjTries * EndpointRate = 60 * 2 * 2 * 0.5 = 120Bytes I

At 19.2 kbps, the transmit duty cycle of the drive-by is:

It has been computed that the redundancy of received R300 messages is 2 times. The probability of missing R300 messages while collecting this cluster of RF2Net orphans is:

Probability = 0.05² = 0.25% The probability is low, but exists in what can be considered a worst case. But the collector can manage and correct this situation by providing an indication to the driver for passing near the unread meters a second time.

Figure 4 shows message exchange between a mobile collector and two end points EP1 and EP2. III. Drive-By MAC Header

Table 1 : Drive-By MAC Frame

Revision:

It indicates the version of the protocol.

D-By:

This bit indicates if it is a Run (set) MAC header or a Mesh MAC Header (clear).

Frame Type:

This bit indicates the type of the frame.

Table 2: MAC Frame Type

ACK Message only contains acknowledgment information of the latest received frame. Only the meter sends this message, and in the case it has no Data to send. - Data messages are messages that concern upper layers, e.g., in the drive-by mode, almost every message. Ack information is contained in Data message from the meter.

ID:

This field is 4 bytes long. It is the ID of the non-synchronized meter that communicates with the collector.

Frame ID:

If the frame is from D-B to meter, the field is equal to the frame number that is acknowledged. Else if the frame is from meter to D-B, this field is equal to the MAC frame number.

Channel:

For the drive unit, this field is used to command the next channel that the destination endpoint must use.

For the endpoint, this field indicates which channel it is using.

CRC:

These 4 bytes are allocated for a CRC-32 value to check the integrity of the MAC header. This header is important because it contains synchronization information.

IV. Drive-By Mode Process

See Figures 5 and 6. The Drive-By mode is used to proceed simple actions on meters that cannot be connected to the network (orphans).

If the endpoint is in Non Synchronized Mode or in Synchronized Mode, it directly goes into drive-by mode when identifying drive-by frames. Messages received by the endpoint contain:

- The channel that the endpoint has to switch to.

- The drive-by request contained in the body of the frame, only the API layer is able to decode it. From the MAC point of view, this message is seen as a classic Data message

Once the endpoint receives a valid message from the Collector, it sets a timer after when it will return to non-synchronized mode, it asks the Physical layer to change frequency according the channel number indicated by the Drive-By, it sets a timer to send a MAC ACK to the Drive-By, and gives the message to the API layer, via the LLC layer.

A few ms later, the API layer (via the LLC) will normally ask the MAC layer to send the response. The MAC layer will send acknowledgment of the previous message in the header of the response.

If the Ack timer ends before response from the API layer, the Ack will be sent alone.

If messages are lost due to collisions, the endpoint has nothing to do: It is the Collector that will proceed to the repetition.

If there is no messages from the Drive-By for a few seconds, the Drive-By timer ends and the meter returns to non-synchronized mode.

Details on System Components and Functionality

VERSATILE RADIO PACKETING FOR AUTOMATIC METER READING SYSTEMS

Fig. 1A is a diagram illustrating an example of a conventional ERT-based AMR system arrangement.

Fig. 1 B is a diagram illustrating the components of a conventional ERT device.

Fig. 2 is a diagram illustrating various types of conventional ERT-based AMR system receiver devices.

Fig. 3 is a diagram illustrating a versatile radio packet according to one aspect of the invention.

Figs. 4A-4N illustrate various examples of messages that can be carried by the versatile radio packet of Fig. 3.

Fig. 5 is a flow diagram illustrating an example process of receiving a versatile radio packet such as the versatile radio packet of Fig. 3.

Fig. 6 is a diagram illustrating a set of basic elements and processes of a mobile AMR system incorporating aspects of the invention to facilitate filtering based on message type. Fig. 7 illustrates a host processor 16 bit type mask according to one embodiment.

Fig. 8 illustrates a simplified flow diagram of a type filter according to one embodiment.

Fig. 9 illustrates an example process of an automatic service scheduling system utilizing message type filtering in accordance with an embodiment of the invention.

Fig. 1A is a diagram illustrating a portion of a typical automatic meter reading (AMR) system. As shown, automatic/remote AMR system 10 is adapted for use with a plurality of remotely located consumption sensing instruments such as meters 12A-12C. Meters 12A-12C sense or monitor a physical parameter, such as a quantity of a given commodity (e.g. electrical power, gas, water) used by a residential or business customer. The meters 12A-12C are also capable of sensing critical events, such as unauthorized tampering, certain malfunctions, and power outages (in the case where the meters 12A-12C sense are sensing electric power consumption).

Associated with and operatively coupled to each meter 12A-12C is an endpoint 14A-14C (generally referred to as endpoint 14). Endpoints 14A-14C all function in a similar manner, and are typically identical to facilitate high volume, low cost construction. In one embodiment, endpoints 14 are each an ERT-type device that is capable of operating with existing ERT-based AMR systems. Each endpoint 14 has a meter interface and a radio transmitter, and includes an antenna 16A-16C, coupled respectively to the associated radio transmitter, for transmitting and optionally receiving radio frequency (RF) signals as well as a processor, including a random access memory (RAM), a non-volatile memory such as an EEPROM, and a simple power supply.

FIG. 1 B illustrates in greater detail one embodiment of an endpoint 14. Endpoint 14 interfaces with a utility meter 12, receives consumption and other relevant data from utility meter 12, and communicates the data to AMR system 40. Endpoint 14 includes an interface system 42, which operatively couples to utility meter 12 via coupling 44. In one embodiment, coupling 44 includes electrical and mechanical components for making a physical and electrical connection between utility meter 12 and endpoint 14. For example, coupling 44 can include an encoder that converts the utility meter 12 measurement into a digital representation that is readable by a processor 46. Interface system 42 is interfaced with processor 46 via interface 48. In one embodiment, interface 48 includes a portion of a data bus and of an address bus.

In this example embodiment, processor 46 executes instructions that control the operation of endpoint 14. In one embodiment, processor 46 includes a microprocessor-type system that has memory, an instruction processing core, and input/output circuits. Processor 46 interfaces with radio 50, which is then coupled to an antenna 52. In one embodiment, radio 50 is a transceiver; in another embodiment, radio 50 is a receiver only. In operation, interface hardware 42 forwards and converts utility meter data for further processing by processor 46. Processor 46 processes and stores the data at least temporarily, converts at least a portion of the utility meter or related data into packets, and instructs transceiver 50 to communicate to AMR system 40 at appropriate times. Consumption data, as well as other account information such as identification data identifying utility meter 12 from which the consumption data was sensed, is encoded for transmission (i.e. packetized) in an RF endpoint signal by processor 46 when endpoint 14 is externally activated by AMR system 40 (e.g. polled) or self-activated (e.g. one-way bubble-up operation).

In one exemplary embodiment, endpoint 14 operates in a low-power standby mode during a majority (>50%) of the time. While in the standby mode, interface system 42, processor 46, and transceiver 50 are effectively shut down to reduce power consumption. Timer 56 operates to periodically wake up the shut-down systems so that they enter into an active operating mode. In one embodiment, timer 56 is an independent circuit that is interfaced with processor 46. In another embodiment, timer 56 is implemented as a watchdog timer in a microcontroller that is a part of processor 46. In either embodiment, one feature of timer 56 is that timer 56 consumes relatively little energy for operating. Also, upon expiration of a settable time duration set into timer 56, timer 56 provides a signal that initiates bringing online the systems that are in standby mode. According to one exemplary embodiment, endpoint 14 includes a power supply 58. In one embodiment, power supply 58 includes one or more batteries. Power supply 58 provides conditioned power to interface system 42, processor 46, and transceiver 50 via a switchable power bus 60. Power supply 58 provides conditioned power to timer 56 via a power line 62. Timer 56 provides a control signal to power supply 58 that causes power supply 58 to apply power to power bus 60. Processor 46 provides a control signal to power supply 58 that causes power supply 58 to remove power from power bus 60. In operation, beginning in a standby mode, timer 56 has been configured with a set time duration by processor 46 via a setup signal. Timer 56 monitors the passing of the time duration and, at the expiration of the time duration, timer 56 provides a signal to power supply 58 to energize power bus 60. Once power is applied via power bus 60 to processor 46, interface system 42, and transceiver 50, processor 46 begins executing a program that gathers data from utility meter 12 via interface system 42, and momentarily activates transceiver 50. Once the data gathering program is complete, processor 46 sets a time duration into timer 56 and initiates the clock while generating a timing, and generates a control signal to power down the systems that have been powered via power bus 60.

Referring again to Fig. 1A, Any of endpoints 14A-14C can be integral with their corresponding utility meter 12A-12C. In the case of electrical meters, the power supplies may not include battery-supplied backup power. Endpoints 14A-14C accumulate and digitally store consumption data and critical events sensed by meters 12A-12C, respectively. Basic endpoint devices maintain a running counter that represents the amount of consumption of the metered utility, or commodity. More advanced endpoints maintain consumption information as a function of time, such as over configured time intervals t_Δ. The t_Δ intervals are typically selected to be rather short, for example, 1.5, 2.5 or 5.0 minutes. This manner of data logging enables time of use and demand metering, as well as facilitating a way for utility providers to recognize the occurrence of supply problems such as outages.

AMR system 10 also includes a reader 18. Fig. 2 illustrates various types of reader devices, including field programmer 18A, handheld mobile reader 18B, fixed reader 18C, and vehicle-based mobile reader 18D. Referring again for Fig. 1 , an example reader 18 includes transmitter activator 20, and a receiver that includes radio receiver circuit 22, decoder 23, controller 24, and data processor 26. Transmitter activator 20 transmits RF activation signals to endpoints 14A-14C via antenna 30, while RF endpoint signals from endpoints 14A-14C are received by radio receiver circuit through antenna 32. One-and-a-half-way endpoints operate in a low-power receive mode that listens for activation signals from the AMR system. The one-and-a-half-way endpoints respond to the activation signals by entering a high-power active operating mode transmitting their consumption and related information. Other types of endpoints are one-way (transmit only) devices, and bubble up to simply transmit their consumption and related information on an internal schedule, without regard to any activation or polling signals.

For communicating with one-and-a-half-way endpoint devices, transmitter activator 20 of reader 18 generates a polling or activation signal which is transmitted through antenna 30. All endpoints 14A-14C within range of transmitter activator 30 will respond upon receipt of the activation signal through their antennas 16A-16C. Once activated, endpoints 14A-14C produce and transmit their RF endpoint signals which includes the consumption and identification data.

Whereas endpoints traditionally used in the field transmitted only one or two pre-configured messages with consumption and related information, according to one embodiment of the present invention, an endpoint 14 can respond to different polling prompts or instructions from AMR system 40 by transmitting correspondingly different information to satisfy the requests.

Each transmitted endpoint radio packet is received by radio receiver circuit 22, and the data contained therein is decoded by decoder 23 to convert the received data into a form readable by data processor 26. This data is then further processed and stored by data processor 26 under the control of controller 24. Based on the type of receiver device 18, the consumption, identification, account information, and other consumption and related information is transferred to a utility billing system 36. This transfer can take place very soon after receipt of the endpoint packet (such as where the receiver device 18 operates as a repeater), or later (such as where the reader 18 operates as a data collection and storage device). The endpoint consumption and related information is packaged in a radio packet for transmission. Presently, interrogator/receiver units, such as interrogator reader 18, can recognize SCM and IDM packets. Table 1 below describes the structure a typical SCM packet used for communicating a single consumption reading and some associated data. Twenty four bits are available to represent a small amount of consumption data (such as the most recent consumption count). One example of an endpoint packet used by conventional ERT devices is described in detail in U.S. Pat. No. 4,799,059, which is incorporated by reference herein in its entirety.

Table 1 : SCM Packet Format

Table 2 below describes the structure of a typical IDM packet for transmitting interval consumption data. Four bytes are reserved for the most recent consumption count, and 53 bytes are used for representing differential consumption values for 47 intervals (each represented by a 9-bit field).

Table 2: IDM Packet Format

The IDM packet format shown in Table 2 is specifically suited for reporting current consumption and interval consumption information and other ERT status information. However, the IDM packet structure is fairly rigid in terms of adaptability for carrying other types of information about the ERT. An example of the use of the IDM packet format is described in detail in U.S. Pat. No. 5,918,380, which is incorporated by reference herein in its entirety. Versatile Packet

Fig. 3 is a diagram illustrating a versatile packet 100 according to one embodiment of the present invention. The first portion of versatile packet 100 resembles a corresponding portion of the IDM packet described above, which enables receivers capable of detecting the IDM packet to also detect versatile packet 100. Taken together fields 102, 104, 106, and 108 constitute the preamble portion of versatile packet 100, which is part of the data link layer responsible for providing essential information to the receiver for identifying the packet transmission, recognizing the application layer fields, and detecting and correcting any bit errors.

Field 102 of versatile packet 100 contains an alternating bit sequence of 0x55, which function as a training synchronization sequence needed by certain legacy receivers. Field 104 is a frame synchronization sequence having a value of 0x16A3. The frame synchronization sequence of field 104 (and, for some receivers, the training sequence of field 102) are used by receivers to detect the transmission of versatile packet 100.

Field 106 contains a packet type identifier having a value of 0x1 D. Packet identifier field 106 is primarily useful for distinguishing versatile packet 100, from a regular IDM packet. It may be possible for certain radios to utilize the packet identifier field is used together with the frame synchronization pattern for correlation. To substantially maintain this field's usefulness for correlation, the value of 0x1 D is nearly the same as the packet identifier field of the IDM packet (having a value of 0x1 C), the difference being that the least significant bit is a 1 instead of a 0. Therefore, 7 out of 8 bits in packet identifier field 106 are useful for correlation. Comparing fields 102, 104, and 106 to the corresponding fields of a regular IDM packet, the 31-bit sequence 0101010100010110101000110001110 is present at or near the beginning of each packet.

Packet length field 108 of versatile packet 100 contains a value representing the remaining length of versatile packet 100. As described below, versatile packet 100 can have a widely varying length. Packet length field 108 is used by the receiver to recognize the end of the incoming packet. In one embodiment, length field 108 is used by the receiver to determine the length of a variable length field within packet 100. In a related embodiment, the packet length field 108 is used in conjunction with message type identifier field 110 (described in greater detail below) to determine the length and sub-fields within variable length message field 116 (also described in greater detail below). In one embodiment, the first byte of two-byte packet length field 108 includes a value representing the remaining length of the packet (i.e. the combined length of fields 110, 112, 114, 116, 118, and 120), and the second byte has a Hamming code corresponding to the value of the first byte. The Hamming code can be used for error detection or correction of the first byte's value.

Unlike the packet length field of the conventional IDM message described above, which contains a value representing the total packet length, packet length field 108 can be used by a variety of ERT-based AMR system receivers for determining the end of the packet transmission by virtue of its remaining length representation. Certain AMR system receivers utilize a portion of the repeating training synchronization sequence 0x5 for detecting an IDM packet transmission, while others do not use any portion of the training sequence, and instead utilize only the frame synchronization sequence 0x16A3. Other receivers may utilize only a least-significant portion of the frame synchronization sequence (or, more generally, a substantial portion of the frame synchronization sequence) for detecting (e.g., correlating on) an incoming IDM packet. Regardless of how much of the preamble needs to be received before detecting the presence of versatile packet 100, receivers can readily determine the remaining length of a detected incoming packet by reading the packet length field 108.

Fields 110, 112, 114, 116, and 118 are application layer fields, which include the information-bearing message that is the subject of the communication, as well as identifying information about the originating endpoint of the message. In one embodiment, the packet is organized into a message type identifier field 110 and a message value field 116. Message type identifier field 110, also referred to as the message number field, contains a byte representing the type of message being communicated in association with the data in message value field 116. Message value field 116 can have any suitable length, and can be further organized into message sub-fields. The data processor at the receiving end, such as data processor 26, utilizes message type identifier field 110 identify the structure of the message value field 116. Figs. 4A-4N illustrate various example embodiments of different message types. For each message type of in Figs. 4A-4N, there is a different corresponding message type identifier to be transmitted in field 110 of versatile packet 100. The information depicted for each message type represents the contents of message value field 116 corresponding to the message type identifier in field 110. In each of Figs. 4A-4N, a 2-column table represents the message value field structure of the message type depicted. Table rows represents bytes in the messages. The left- hand column of each table indicates the byte position (starting at 0), and the right- hand column describes the information represented by the corresponding byte position. Each byte position can be a complete sub-field, or a portion of a sub-field within the message body.

Fig. 4A depicts a simple 5-byte consumption message that includes four bytes of consumption information in the consumption sub-field (byte positions 1-4). Fig. 4B depicts an 11-byte consumption and tamper information message that includes consumption information, together with tamper flag states and last good read time sub-fields.

Fig. 4C illustrates an example message structure for communicating interval data. The intervals represent differential data (i.e., the change in consumption count over each time interval). The consumption corresponding to the time intervals is presented backwards in time such that IntervaM at byte position 10 represents the most recent interval.

Figs. 4D-4F illustrate examples of message types in which the length is dependent upon a configuration. Fig. 4D depicts an example message for reporting time-of-use information used, for example, in time-of-use based billing. The length L of the time-of use message depends on the configuration of the time-of-use report format at the endpoint. Fig. 4E illustrates an example message for reporting consumption data from endpoints having multiple encoders. The length L of the multiple endpoint consumption message of Fig. 4E depends on the number of encoders associated with the endpoint. Fig. 4F illustrates an example of a multiple daily read message that reports the change in consumption over a 24-hour (or other defined) interval. The length L of this message depends on the endpoint multiple daily reading configuration. Fig. 4G illustrates an example of a message originated by an intermediate node in the AMR system, such as a repeater. The message depicted in Fig. 4G includes consumption-related data, including interval data. Also, the message of Fig. 4G includes specific message sub-fields fields for other useful information about the AMR system performance, such as received signal strength (RSSI) information related to the transmission received by the repeater from the endpoint (bytes 85-86), and tick counter information (bytes 87-88) representing the time delay (e.g., in milliseconds) due to latency in the repeater. The Hop Count byte (byte position 84) is used by the repeater to manage multi-link hopping.

Figs. 4H-4M illustrate examples of short messages for use in communicating alarm information. The short message format permits the alarm information to be communicated utilizing a small amount of energy for transmitting the message. The message depicted in Fig. 4H is for use by an endpoint to indicate to the AMR system that a service outage (such as an electrical power outage, for example, has occurred). The message of Fig. 4H is one byte long, and contains a value representing a counter that is incremented in response to a detection of a power outage event. In the case of an endpoint, the endpoint can utilize any suitable mechanism for detecting the outage event, such as a line monitoring circuit interfaced with the endpoint's controller. When the endpoint detects a voltage drop below a predetermined threshold, a missing AC cycle, or some other supply anomaly, the endpoint recognizes an outage condition, increments the outage counter, and transmits a versatile packet 100 with the power outage message type ID (e.g., 0x50) in message type identifier field 110 and the outage count in the message value field 116.

Fig. 4I illustrates an example of a power restoration message for transmission by an electrical endpoint in response to a detection of a restoration of power previously lost. The first byte position (byte 0) contains a count value corresponding to the most recent power outage count (which was previously transmitted in the message of Fig. 4H). The second byte position (byte 1) is a restoration count that provides information that can be used to calculate the duration of the outage. In one embodiment, the time count represents a time duration between the time of the detection of the most recent restoration and the time of the transmission of the power restoration message. The time count can represent elapsed seconds, minutes, hours, or other predefined unit of time.

With the assumption that an outage message is transmitted very shortly after a detection of the outage condition, the AMR system can recognize an approximate time of the outage based on the time of receipt of an outage message such as the outage message depicted in Fig. 4H.

The messages depicted in Figs. 4J and 4K are examples of an outage notification message, and a restoration message, respectively, for transmission to the AMR system by an intermediate AMR node such as a repeater. These messages are used to relay outage and restoration events, as detected by a device (such as an ERT or other intermediate node) other than the node originating the message. The repeated outage notification message of Fig. 4 J includes the outage count byte (in byte position 5), as received from the endpoint that detected the outage. The repeated outage notification message also includes information about the endpoint, such as meter type (byte 0) and endpoint serial number (bytes 1-4), and information useful for coordination of information in the AMR system, such as hop count (byte 6) and tick counter (bytes 7-8). The repeated restoration message of Fig. 4K has all of the fields as in the outage notification message of Fig. 4J and, in addition, includes a restoration time count byte (byte position 6) that is similar to the restoration count byte described above with reference to Fig. 4I.

Figs. 4L and 4M illustrate examples of outage and restoration messages, respectively, representing these events as detected by the repeater. The message examples depicted in Figs. 4L and 4M have similar corresponding fields as the messages of Figs. 4H and 4I and, in addition, include hop count and tick counter fields. The identification of the message originating device is present in serial number field 114 of versatile packet 100.

Fig. 4N illustrates an example of a received signal strength report message, as originated by an intermediate AMR system device such as a repeater. The signal strength, as measured at the repeater is encoded at byte positions 6 and 7. Byte positions 0, and 1-4 respectively contain endpoint type and endpoint serial number information about the endpoint that transmitted the message from which the received signal strength was measured. Hop count information is included in byte position 5.

Referring again to Fig. 3, the message of versatile radio packet 100 optionally includes a message CRC field 118 that can be any suitable length. The message type identifier in field 110 represents whether, and what type of, message CRC field is included in the versatile packet 100. In one embodiment, the message CRC field has a cyclical redundancy check (CRC) code for the message value field 116, as represented at 122 in Fig. 3. Packet CRC field 120 contains a CRC code for fields 106, 108, 110, 112, 114, 116, and 118 of packet 100, as represented at 124 in Fig. 3. Message CRC field 118 and packet CRC field 120 are utilized by a receiver of packet 100 for verifying or, to the extent possible, fixing the integrity or validity of the data received in the corresponding fields.

Receiving and Processing a Versatile Packet

Fig. 5 is a flow diagram illustrating an example process 500 of receiving a transmission of versatile packet 100. Process 500 can be carried out by a specially- configured reader device (such as, for example, reader 18 with special instructions for carrying out process 500 executing on controller 24). In an AMR system. The specially-configured reader can be a final destination node in an AMR system, such as the head end, or an intermediate receiver, such as a repeater or a mobile reading device or field programmer. At step 502, the communication channel is monitored by a radio receiver circuit. In one embodiment, a correlator circuit is used to detect at least the frame synchronization pattern 0x16A3 of field 104. In a related embodiment, the training synchronization pattern 0x55 is also utilized in the correlation. The data immediately following the frame synchronization field 104 is the packet type ID field 106. In a related embodiment, at least a portion of packet type ID field 106 (such as several of the most significant bits) is also used for correlation.

As indicated at 504, if the correlation pattern is detected, the receiver circuit synchronizes its local clock to the incoming bit rate and begins buffering the incoming data at 506. Otherwise, the receiver continues monitoring the channel at step 502. At step 508, the packet type ID in field 106 is read by the receiver, and compared against known values. A value of 0x1 D indicates that the radio packet is a versatile radio packet 100. As indicated at steps 510 and 512, if the packet type ID is other than 0x1 D, then the packet type ID field 106 is compared against other known packet types, if any. At step 514, length field 108 is processed. In one embodiment, processing of length field 108 includes computing the Hamming check of the remaining packet length value. As described above, the incoming data is buffered at least until the end of the packet, as represented by length field 108.

At step 516, the receiver reads packet CRC field 120, and performs a cyclical redundancy check (CRC) of fields 106, 108, 110, 112, 114, 116, and 118 based on the CRC value in field 120. As indicated at step 518, if the result of the CRC is not a valid packet, the buffered data believed to be the packet is disregarded or discarded at step 520, and the channel monitoring of step 502 is resumed. Otherwise, if the CRC resulted in a valid packet, the receiver can continue processing the packet.

For packets that have message CRC field 118, optionally, the receiver can perform a CRC on the message field, as indicated at step 522. If the message is not valid and cannot be corrected, further processing and/or transmission can be avoided. Accordingly, at step 524, for invalid messages, the data is disregarded at step 520. For valid messages, processing can continue.

Preferential Treatment of Messages

In one embodiment, certain AMR receiving devices can give priority to certain types of messages, such as alarm messages. In intermediate AMR devices such as repeaters and CCUs, received messages can be enqueued for further transmission. Similarly, at the head end, received messages can be stored in memory in a certain order prior to processing. Typically, messages are processed or transmitted in order of their arrival. However, the ordering can be varied to improve overall system performance. Steps 526, 528, 530, 532, and 534 depict an example process portion in which different message types are given different priority. At step 526, the message type identifier field 110 is read, and at step 528 the receiver determines whether the message type is urgent. If it is not urgent, the packet is handled normally (as indicated at step 530) such as, for example, being placed at the bottom of a queue. For urgent messages, as indicated at step 534, each corresponding packet is handled with priority, such as, for example, being placed at the top of the queue. Eventually, the packet is processed (i.e. at the head end) or re-transmitted (i.e. by a repeater device) at step 536. At the head end, the endpoint information of fields 112 and 114 is extracted and associated with the message type identifier and message value. At a repeater, the application layer fields or the entire packet can be re-packaged in a new packet and transmitted to the next hop. Processing of the various fields of versatile packet 100 generally takes place at the application layer of the AMR receiver devices or head end, and generally involves decoding the individual fields and sub-fields, and applying sets of logical rules in response to the information content of each field.

Message Type Filtering

Exemplary methods and apparatus are described below for filtering out specific message types and reducing the data flow to a host processor in an AMR system with multi-channel readers that generate large amounts of data when reading large populations of endpoints. Disclosed methods eliminate unwanted data traffic and increase system performance. Presented methods can also allow identification of malfunctioning meter units in preparation for their repair or replacement.

Fig. 6 illustrates an example set of elements and processes of an example mobile AMR system using 1.5-way communications. As illustrated in Fig. 6, a passing data-collecting vehicle 602 first sends a wake-up signal 604 to each endpoint, such as endpoint 606. Upon the receipt of the wake-up call 604, each endpoint transmits the required information 608, which is subsequently received by a DCU 610 (Data Collection Unit) reader of the passing vehicle 602. Afterward, the received endpoint signal goes through several signal-processing steps and the embedded data is retrieved from it. Finally, the retrieved data may be uploaded from the DCU 610 to a main system or computer 612 in a central location for billing and other purposes.

Data flow to the host processor may be reduced by filtering out specific message types transferred from endpoints to DCUs. While Multi-channel DCUs generate large amounts of data when reading large populations of endpoints, discriminating data by selecting the message type allows the host processor to receive data of desired type(s) and to reduce the amount of data transferred from the DCUs to the host. These advantages may also be availed of in the fixed AMR systems described above, and in 1-way or 2-way systems.

Currently, systems using channelized receivers have to increase the communications channel speed to the host so that the data can get through. This solution has practical limitations, one of which is that the standard PCs can handle a maximum of 115200 baud.

In an embodiment of the invention the host processor can request from the DCUs certain message types such as a type-2 gas ERT, or a type-5 electric ERT. In another embodiment multiple types of endpoints can be selected by the host processor. Today, ERT SCMs, for example, each have 16 different message types, as denoted by a four bit field in the SCM. In these embodiments the host processor passes a bit mask consisting of 16 bits. Each bit location corresponds to an endpoint type. For example, location 1 is type-1 , location 2 is type-2, and so on. If a bit is set, then the reader will only pass the endpoint type associated with that bit(s).

Fig. 7 illustrates an example type mask in which two types, 3 and 5, are identified. The top row of the table in Fig. 7 merely indicates the bit position number of each of the mask bits. The desired bits, or the masked bits, may be identified by a 0 or a 1 and the rest of the bits will be identified by their complements, 1 or 0, respectively. In this Figure a "1" identifies a desired bit.

For customers that want to read only one type of endpoint, like water customers, the host processor may only enable, for example, bit 3 for water endpoints. Therefore, only water endpoint data will be sent to the meter reading application program. By reducing the data flow in such manner, the burden on the communications channel is greatly reduced. Hence, a low cost system using a slower handheld computer can be used for mobile meter readings without missing desired endpoint data as a result of other endpoint traffic in the area.

In another embodiment, type filtering capability may be utilized for problem identification as well. For example, when an endpoint encounters a problem or failure, it changes its type to type-15. If a water customer wants to identify all of her/his water endpoints and any failed, type-15, endpoints, the mask will be set to accept these two types. Once the type-15 endpoints are found, the ID of the endpoint will be matched to an address and the malfunctioning endpoint can be replaced. In this case any failed endpoint will be identified, regardless of whether it is a water, a gas, or an electric endpoint. In other embodiments specific type numbers may be designated for a failed water endpoint, a failed gas endpoint, or a failed electric endpoint, etc. In another embodiment a reader may be directed to check at least one other specific information of a message once the message is initially screened by its type.

In some cases an endpoint may be configured to transmit multiple type numbers. In such cases more than one type may also be identified by the mask for discriminating an endpoint. If multiple types are identified by a mask, then some directives, such as a Boolean function, may also be handed to the reader by the host processor, which specifies to the reader how to use the mask information for sifting the endpoints. For example if an endpoint transmits one type number to specify the utility type and another type number to specify malfunctioning, then a mask can set two bits, one for water and one for malfunctioning, and a Boolean function can direct the reader to either pass the data for all malfunctioning water endpoints or all water endpoints and all malfunctioning endpoints. Or, for example, a mask can be set along with a Boolean relation to identify the data for all the gas endpoints and only the malfunctioning water endpoints, etc. In yet another embodiment an "OR," an "AND," or any other Boolean relation may be designated as a default directive.

Fig. 8 illustrates a simple filtering process, performed for example by a dedicated processor, or an auxiliary computer, in which at step 810 an endpoint message is received by the reader. At step 812, the message type is compared with the allowed types indicated by the mask or the type number(s) received from the host processor. At step 814 a decision is made based on the matching result of step 812, and the message is either sent to the host processor (step 816) or the message is ignored (step 818). Mask information and/or directive functions may be stored in the DCU processor and be referred to by the host processor or be sent to the DCU processor when needed and be stored thereafter for processing purposes. Type filtering reduces the processing demands placed on a processor running the meter reading application, which is not limited to SCM messages. As the number of message types increases such as with the use of versatile message packet 100, for example, the type filter can also be used to distinguish packet types. For instance, if there is a need to look for a versatile packet (e.g., type-25), then the filter can be set for type-25 packets only to be passed to the application. Messages of variable lengths may also be handled by the disclosed embodiments of this invention. As described above, variable length messages in some embodiments, have special fields with information about their lengths. In embodiments handling such cases, instead of a bit mask, the type number or numbers can be passed to the radio when the number of bits in a bit mask is large.

In another embodiment, a customer service system employs the information obtained using type filtering to automatically schedule service and repair of customer equipment, such as meters and endpoints. In this system, specific message types that indicate a need for repair or attention are routed to one or more system modules that perform service scheduling. Filtered messages that indicate some required services may be transmitted from a reader directly to a service scheduling module; to a service scheduling module through the host processor; to both the service scheduling module and to the host processor; or to the service scheduling module through any other route. In other embodiments the filtered message that indicates service necessity may not itself be sent to the service scheduling module; rather, a corresponding service-request message may be sent instead.

Fig. 9 illustrates an example process of an automatic service scheduling system utilizing message type filtering in accordance with an embodiment of the invention. As depicted in Fig. 9, at step 910, the host computer determines whether the received message necessitates service scheduling, and accordingly, at step 912, may send a service scheduling message to the service scheduling module(s). However, if the received message does not necessitate service scheduling, at step 914 the host computer may perform other processes on the message.

In yet another embodiment, the reader or the host processor may be configured to further sift the service-required messages and only relay some of those messages to the service scheduling module(s). In an alternative embodiment, the service scheduling module(s) may dictate to the reader or to the host processor how to further sift the service-required messages and to only pass specific messages to the service scheduling module(s).

F

RF METER READING SYSTEM

FIG. 1 depicts a radio-based automatic meter reading system that utilizes the data communication protocol according aspects of the present invention.

FIG. 2 is a flow diagram illustrating an AMR system communication session between an endpoint and a reader according to one embodiment of the invention.

FIGs. 3A and 3B illustrate examples of messages that can be communicated in one-way communications and two-way communications modes according to various embodiments.

FIG. 4 is a decision tree diagram illustrating examples of the response by an endpoint to the initiation of two-way communications by a reader.

FIG. 5 is a block diagram illustrating a portion of the components of an AMR system reader according to one embodiment of the invention.

FIG. 6 is a timing diagram illustrating two-way communications between a reader and a plurality of endpoints during four consecutive blocks of time I-IV according to one example embodiment.

FIGs. 7A and 7B are flow diagrams illustrating an example communication sequence involving a reader, an endpoint, and a repeater according to one aspect of the invention.

FIGs. 8A and 8B are diagrams illustrating examples of data structures for storing consumption values in endpoints according to one aspect of the invention.

FIG. 9 is a circuit diagram illustrating an example embodiment of a switched capacitor arrangement for temporarily boosting the available power for powering the transmitter circuit during data transmissions.

The automatic meter reading (AMR) systems and methods of the present invention facilitate meter reading utilizing one-way and two-way communication with utility meter endpoint devices while at the same time providing an operating regime that conserves energy for long battery life and utilizes the available airwaves for AMR communications efficiently. Embodiments of the invention are applicable in AMR systems employing handheld and/or vehicle-based mobile readers, fixed readers, and combinations thereof. Moreover, embodiments of the invention facilitate smooth transition from mobile AMR systems to fixed systems, and provide for automatic AMR system performance monitoring and automatic adaptability to maintain or improve performance.

In an automatic meter reading (AMR) system 100 of the present invention, as depicted in Fig. 1 , the components generally include a plurality of utility or commodity consumption measuring devices including, but not limited to, electric meters 102, gas meters 104 and water meters 106. Each of the meters may be either electrically or battery powered, or both. AMR system 100 further includes a plurality of endpoints 108, wherein each corresponds to a meter. Endpoints 108 can be integrated into their corresponding meters, or can be separate devices communicatively interfaced with their corresponding meters. Each of the endpoints 108 includes a radio receiver/transmitter such as, for example, the Itron, Inc. ERT.

System 100 further includes one or more readers 109 that may be fixed or mobile. Fig. 1 depicts: (1) a mobile hand-held reader 110, such as that used in the Itron Off-site meter reading system; (2) a mobile vehicle-equipped reader 112, such as that used in the Itron Mobile AMR system; (3) a fixed radio communication network 114, such as the Itron Fixed Network AMR system that utilizes the additional components of cell central control units (CCUs) and network control nodes (NCNs); and (4) a fixed micro-network system, such as the Itron MicroNetwork AMR system that utilizes both radio communication through concentrators and telephone communications through PSTN. Of course, other types of readers may be used without departing from the spirit or scope of the invention.

Further included in AMR system 100 is a system head-end, or host processor 118. Host processor 118 incorporates software that manages the collection of metering data and facilitates the transfer of that data to a utility or supplier billing system 120.

Automatic meter reading system 100 enables meter reading and two-way communications, including and command and control, between readers and endpoint devices, while maintaining backwards compatibility with existing ERT- based AMR infrastructure. In the two-way communications regime of system 100, a number of advantages are achieved by synchronizing reader 109 to endpoint 108, as opposed to the conventional method of synchronizing the endpoint to the reader. Conventional two-way meter reading systems synchronize by having each endpoint listen for an initiation of communication by a reader, such as a reader- originated wakeup tone or command and control packet. Communication proceeds following the endpoint's reception of such initiating communication. In this type of arrangement, the endpoints must be on, and operating in a listening mode, for communications to be initiated. When an endpoint operates in a listening mode, but communications with the endpoint is not called for, the endpoint's operation results in a waste of energy, shortening the life of the endpoint if the endpoint is battery- powered. If a reader attempts to communicate with an endpoint when the endpoint is not in its listening mode, no such communication takes place, and the communication attempt results in a needless channel utilization, which, in turn, prevents the reader from communicating at least on that channel during the communication attempt. Additionally, the failed communication attempt clutters the channel, potentially causing collisions or interference with other AMR communications.

AMR communications overview

FIG. 2 is a flow diagram illustrating an AMR system communication session 200 between endpoint 108 and reader 109 according to one embodiment of the invention. In contrast to the conventional two-way AMR systems described immediately above, endpoint 108 initiates each communication session and, within the communication session, reader 109 can selectively initiate two-way communications with endpoint 108. In one embodiment of system 100, each of the endpoints 108 operates in a low-power standby, or sleep, mode for a majority of the time, as indicated at step 202. While in this mode, some endpoints 108 may gather consumption information from their corresponding utility meters. Reader 109 normally operates in receive mode 204, in which it listens for transmissions from endpoint devices. As indicated at process flow 205, reader 109 remains in receive mode in the absence of communications activity.

In response to a specific event (such as, for example, the passage of a certain amount of time), endpoint 108 enters an active operating mode, or "bubbles up" and transmits an initial message, which is a relatively short message, such as burst of data, as indicated at step 206. By virtue of its short duration, the initial message requires a relatively small amount of energy to be transmitted by the endpoint. The initial message includes at least a unique identifier of the endpoint, and any necessary overhead bits that identify the initial message as a transmission from an endpoint device to enable its reception by an AMR system receiver. In one example embodiment, the initial message includes a synchronization pattern (such as a string of alternating bits), a preamble that is recognizable by a reader as indicating the presence of an AMR message, and an identification of the particular endpoint. In another embodiment, the initial message can include additional information, such as, for example, consumption information.

In a related embodiment, the initial message is a 96-bit standard consumption message (SCM) that is presently utilized in ltron Inc.'s ERT-based AMR systems. An example of a SCM format is illustrated in FIG. 3A. e.g., 21-bit preamble field followed by 2 ID bits, 1 spare bit, 2 physical tamper bits, 4 endpoint type bits, 2 encoder tamper bits, 24 consumption data bits, 24 ID bits, 16 CRC checksum bits (this can also be found in U.S. Patent No. 4,799,059, which describes the ERT packet in detail). In related embodiments, the initial message is a variation of the SCM packet, such as having one or more additional fields, having fewer fields, or having differently-defined fields. In embodiments where the initial message is shorter than a SCM (such as omitting any consumption information), further 2-way communication with the endpoints is needed to obtain the consumption information; however, greater overall efficiency in communication and energy consumption may be realized with such an arrangement.

An AMR system in which endpoint devices wake from a standby mode to transmit a SCM is consistent with operation of present-day one-way ERT-based AMR systems. In this type of embodiment of system 100, endpoint 108 can work as a one-way endpoint with these existing systems without the need for upgrades or reconfiguration of the readers and other AMR system infrastructure. Additionally, embodiments of readers according to the present invention can work conventional endpoint devices already deployed without any upgrades to the conventional endpoint devices.

After transmitting the initial message, endpoint 108 may sleep in a standby state for some specified amount of time, as indicated at step 208. In one example embodiment, the time of this delay is preset to about 1 second. In other embodiments, there may be no such delay; or the delay may be dynamically adjusted by the endpoint or configuration commands via the AMR system. Following the delay of step 208, endpoint 108 listens for a response from reader 109 for a predetermined duration of time, as indicated at step 210. Listening step 210 facilitates two-way communication between the endpoint and AMR system reader. As described below, if reader 109 is within communications range of endpoint 108 and needs to communicate with endpoint 108 following reception of the initial message, reader 109 transmits to endpoint 108 during the endpoint's listen period. If no two-way communication is initiated, communication does not take place and endpoint 108 returns to its bobble-up mode, as indicated at step 211. In an embodiment that utilizes frequency hopping for communications with endpoints, the next bubble-up event will involve the endpoint transmitting on a different channel.

In one embodiment, the listening duration is about 2 milliseconds. In various other embodiments, this listening time can be adjusted to any suitable duration to facilitate the desired operation and performance of system 100. In addition, the listening activity 210 of the endpoint can take place at the same frequency, or channel, on which the initial message was transmitted, or can take place at a different frequency that is predetermined, or formulaically derived based on specific conditions.

Prior to engaging in any two-way communications, at step 212, reader 109 receives the initial message transmitted by endpoint 108 at step 206. Reader 109 then processes the initial message at step 214. In one embodiment, processing the initial message includes decoding and parsing the initial message, reading certain fields or information carried by the initial message, and determining whether, and how, to respond to receipt of the message. As indicated at decision 216, the response can include initiating a follow-up communication (i.e. in two-way communications mode). The decision for whether to initiate further communication can be based on a variety of circumstances such as, for example, the content of the initial message received in step 212, system configuration instructions sent from the head end or host processor 118, the time of day or day of the billing cycle, the amount of time since the last successful consumption reading received from the particular endpoint 108, and the like.

At step 218, reader 109 transmits the follow-up communication as needed. In one embodiment, the follow-up communication is an instruction, such as, for example, a command requesting certain additional information from endpoint 108. In this scenario, according to one example embodiment, reader 109 reads the endpoint ID in step 214 when processing the initial message and, based thereupon, reader 109 decides whether to request the follow-up communication with that endpoint.

In a successful communication, step 218 occurs during the time that endpoint 108 is in its receive mode according to step 210. In one embodiment, reader 109 is synchronized with endpoint 108 (i.e., configured to automatically account for the time delay of step 208) to ensure that the follow-up communication transmitted in step 218 can be received. At step 220, endpoint 108 receives the follow-up communication from reader 109. Endpoint 108 then processes the communication at step 222, and initiates carrying out any instructions contained therein. If no further communication is called for, endpoint 108 returns to its standby mode of step 202. If the instructions received from reader 109 require a communicative response, endpoint 108 may sleep for a specified time duration at step 224, and then transmit the requested message at step 226, to be received by reader 109 at step 228.

According to various embodiments, the requested message is to be transmitted by endpoint 108 at a specific channel or frequency that is known by the reader. In one such example embodiment, the requested message is transmitted at step 226 on the same channel as the original initial message of step 206. In another example embodiment, the channel for transmitting the requested message is the same channel on which the instruction was received at step 220. In other embodiments, the transmission channel for the requested channel can be different.

The amount of information that is exchanged in the follow-up communication may be substantially greater than the amount of information transmitted by endpoint 108 in the initial message. For example, reader 109 may request a large amount of consumption data or status information from endpoint 108. In response to this type of request, endpoint 108 may transmit a 92-byte interval data message (IDM), a variable-length message packet on the order of 15-150 bytes, or can include a much longer composite message distributed over a plurality of separate packets. FIG. 3B illustrates a versatile message packet format that supports message typing and variable length messaging. The versatile message format depicted in FIG. 3B can accommodate a variety of different messages including, but not limited to, consumption data (including interval data), status information, alerts and alarm information, communications acknowledgements, information relating to endpoint or communications performance, and the like.

In one embodiment, the requested message can be implicitly requested incident to command and control. For example, endpoint 108 can be preprogrammed to respond to certain received command and control packets with an acknowledgement-type communication. In this example, the purpose of the command and control packet from the reader may not be to obtain data from the endpoint. Instead, the responsive communication from the endpoint serves to verify that the command and control instruction was received correctly and carried out by the endpoint.

Following transmission by endpoint 108 of the requested message at step 226, endpoint 108 sleeps for a delay period of step 208, and returns to its receive mode at step 210 to await any further instructions from reader 109. In one embodiment, endpoint 108 is pre-programmed with a specific default delay period for step 208. In a related embodiment, the requesting message from reader 109 sent at step 218 specifies a particular delay period that overrides the default delay. Reader 109 processes the received requested message at step 230, and determines if any further two-way communications are needed at step 216. If an additional instruction is to be sent to endpoint 108, the sequence described above is continued beginning at step 218.

By synchronizing the reader to the endpoint in communication session 200, the transmissions of the two-way communications are more likely to be successfully received. The two-way communications can be coordinated such that the receiver knows in advance at what time, and on what frequency, to listen for the endpoint's follow-up transmission. Additionally, the endpoint can be configured by the reader to listen during a certain time, or to transmit during a certain time known by the reader. As a result, fewer communications attempts are needed to deliver the messages having relatively large payloads (requiring more energy to transmit or receive). This permits operating the endpoint so that its power consumption is minimized. Fewer communication attempts saves energy, and results in a clearer channel, which reduces the chance of collisions with other data packets transmitted by other endpoints or AMR system devices. This, in turn, reduces the need for communications retries, keeping the channel clear and conserving energy at the endpoints.

Endpoint side communications activity

FIG. 4 is a decision tree diagram illustrating examples of the response of endpoint 108 to the initiation of two-way communications by reader 109. At step 402, the instruction transmitted by reader 209 that initiates the two-way communications (such as the instruction transmitted at step 218 in FIG. 2) is decoded. Three examples of possible instructions are illustrated: (a) the instruction may be a request for the endpoint 108 to transmit certain data (and, optionally, that the transmission be carried out in a certain specified manner); (b) the instruction may be a configuration or programming command to adjust some operating parameter of endpoint 108; or (c) the instruction may be a command to cause endpoint 108 to enter a specific mode of operation notwithstanding (i.e., overriding) the endpoint's default operating program.

In case (a) where the instruction is a request for data, endpoint 108 responds at step 404 by transmitting the requested data as instructed. At step 406, endpoint 108 listens for further instructions for a predetermined time duration. If no further instructions are received, normal bubble-up operation is resumed as indicated at step 408. In case (b), endpoint 108 may receive configuration instructions to update operating parameters. Endpoint 108 responds by updating the operating parameters at step 410 as instructed. At step 412, endpoint 108 transmits a message to reader 109 confirming the successful updating, and enters into a listening mode at step 414 to await possible further instructions. After the listening period, endpoint 108 returns to normal bubble-up operation at step 416. In case (c), endpoint 108 may receive an instruction to sleep for a specified duration of time. In response, at step 418, endpoint 108 enters a low-power sleep mode for the specified time. The time duration may be specified in various ways, as will be understood by persons of ordinary skill in the relevant art. For example, the sleep duration may be specified in terms of a real time duration, or a time of day as measured, for example, by a real time clock on board endpoint 108. Alternatively, the sleep duration may be specified in terms of a count value to be traversed by a counter on board endpoint 108 that runs while the endpoint is in its sleep mode. Following expiration of the time duration, endpoint 108 returns to its normal bubble- up operation as indicated at step 420.

In a related embodiments, reader 109 uses the follow-up communication to instruct endpoint 108 to operate in a certain fashion, or to adjust one or more configurable parameters of endpoint 108. For example, reader 109 can command endpoint 108 to enter a low-power standby mode for a certain time; or to preferentially utilize certain channels for future communications. In another related embodiment, a request for a further communication by reader 109 can include instructions on when, and how, to transmit the requested message in two-way mode. For example, referring again to FIG. 2, in step 218, reader 109 can specify the amount of time delay for step 224, and can specify the channel on which to transmit the requested message at step 226. In embodiments wherein endpoint 108 and reader 109 are synchronized in time and in frequency for communications, the follow-on communications have an increased probability of being successful, thereby reducing the likelihood of having to retry the communication. As will be discussed below, other aspects of the invention provide further techniques for improving the probability of successful communication.

Reader side communication activity

FIG. 5 is a diagram illustrating reader 500, which is an example embodiment of reader 109. Reader 500 includes a radio circuit 502. Radio circuit 502 is a half duplex or full duplex type radio that can transmit and receive. In one embodiment, radio circuit 502 can selectively transmit or receive signals using different modulation techniques. For example, radio circuit 502 can transmit and receive using amplitude modulation (AM) techniques, such as on-off keying (OOK), as well as using frequency modulation (FM) techniques, such as frequency shift keying (FSK), for example. In one embodiment, radio circuit 502 is capable of receiving multiple channels simultaneously. For example, radio circuit 502 can utilize a broadband front end section that amplifies substantially the entire communications band. The broadband front end feeds a digital signal processor (DSP) circuit that is programmed to discriminate between individual channels using digital techniques. As will be appreciated by persons skilled in the relevant arts, this DSP-based channelization may be accomplished by a variety of known techniques. For example, the DSP may utilize a plurality of digital filters tuned to each channel. In another example, the DSP may implement a Fourier transform algorithm, such as fast Fourier transform (FFT) to represent the communication band in the frequency domain as a plurality of frequency bins, wherein each channel corresponds to at least one of the bins. The changing energy content of each channel as a function of time is indicative of received signaling on that channel. The receiver tracks the activity on each channel virtually simultaneously to detect the presence of, and recover, endpoint-originated transmissions. Radios of this type have been commercialized in the AMR field by ltron Inc., of Spokane, Washington, USA.

Processor 504 is a controller circuit such as, for example, a microcontroller, that coordinates the overall operation of reader 500. Processor 504 is interfaced with radio 502 via address/data bus or other suitable communicative coupling. Processor 504 is also interfaced with program memory space 506, which stores the main operating instructions of reader 500; configurable parameters memory space 508, which stores various adjustable settings; and with general memory space 510, which can store a variety of different data items during operation of radio 500.

Database 512, also interfaced with controller 504, stores data related to the reading and configuration of endpoints that can communicate with reader 500. The endpoint data stored in database 512 can include a list of endpoints to which reader 500 is assigned, and endpoint-specific information corresponding to each of those endpoints. Examples of such endpoint-specific information includes reading schedule(s) for when to obtain certain information from each individual endpoint, configuration and instruction information for adjusting operating parameters and establishing certain operating modes at certain times, respectively, for selected endpoints; the time of, or since, the last successful communication with each endpoint; received signal strength indication (RSSI) information corresponding to each endpoint; and the like.

When reader 500 receives an initial message from an endpoint, reader 500 decodes the initial message to determine the transmitting endpoint's unique ID. Reader 500 then looks in database 512 for a record matching the ID of the received initial message. If such a match is found, reader 500 will track the time and channel at which the initial message was received. This time and frequency tracking can include updating database 512 or general memory 510 according to the tracked time and frequency. In a related embodiment, reader 500 tracks the time elapsed since the receipt of the initial message. The elapsed time is used to synchronize a follow- up transmission to the endpoint's listen window during which the endpoint is receptive to instructions via two-way communications. For example, in the case where the endpoint sleeps for one second following transmission of its initial message and prior to activating its receiver, reader 500 would respond with a follow- up communication after the passage of one second, as measured by a timer on board reader 500.

During the passage of time following receipt of an initial message and before transmitting the follow-up communication, reader 500 continues operating its radio 502 to receive other transmissions from other endpoints in its communication range. Each received communication is tracked in time and frequency. In one embodiment, reader 500 implements a message transmission schedule (e.g., in database 512, or in general memory 510). The message transmission schedule represents the times at which follow-up communications to each endpoint are to take place. The message transmission schedule can also include information indicating which message to transmit to each corresponding endpoint. In one example embodiment, the message transmission schedule is implemented as a queue having time- stamped endpoint IDs. In another embodiment, the message transmission schedule is a queue of complete messages to be transmitted, each message corresponding to a time value. The time stamping or time value used to synchronize each follow-up communication with the receiving endpoint's reception window can be referenced to the reader's real time clock, or to a counter value representing the delay time duration between the reception of the initial message from the corresponding endpoint and the planned time for transmission of the follow-up communication to that endpoint.

In a related embodiment, the reader will not request a responsive message from an endpoint if the response channel has already been allocated. The missed endpoint ID can be kept in a priority list and it will have priority in the transmission schedule the next time an initial message is received from that endpoint.

In another embodiment, if the requested message was received by a reader from an endpoint, but the endpoint's message had errors, the reader could either wait until the next bubbled-up initial message or transmit a second request in the two-way sequence after the previous request. This transmit request in the ongoing sequence can continue so long as the applicable regulations governing channel use are complied with. For example, the "time on channel" rule set by the FCC limits the time of an endpoint/reader communication session to 400 ms in any 20-second time period for each endpoint.

In one embodiment, reader 500 reserves time slots for receiving requested messages from endpoints. Endpoints are instructed to schedule their requested message transmissions such that the transmissions occur during a reserved time slot. Reader 500 disables its transmitter from transmitting in the communications band during the reserved time slots. In an example embodiment where all endpoint devices are configured to sleep for the same predefined time duration between the initial message transmission and the receiver operation, the reserved time slots for receiving long messages occur periodically according to the predefined time duration. In one such embodiment, the delay time between initial message transmission and listen mode for endpoints is one second. In this case, the reserved time slots at receiver 500 can be at the beginning of each 1 -second block of time. The duration of each reserved time slot can account for the length of time needed to transmit the longest possible requested message, plus some buffer time to improve tolerance of timekeeping resolution errors between receiver 500 and any of the endpoints.

In a related embodiment, for each block of time, a plurality of time slots for receiving requested messages is reserved. Certain reserved time slots may be assigned to requested messages to be received on certain channels, while other reserved time slots may be assigned to different channels. As an example of this embodiment, for each periodic block of time, a first reserved time slot may be assigned to even-numbered channels, and a second reserved time slot may be assigned to odd-numbered channels. This arrangement ensures that requested endpoint transmissions are not received simultaneously on adjacent channels, thereby improving channel selectivity, improving the tolerance of receiver 500 to frequency drift of endpoint devices, reducing the likelihood of inter-channel interference, and, ultimately, improving the likelihood that the requested messages are received successfully. In a variation of this embodiment, there may be three separate reserved time slots assigned respectively to every third consecutive channel.

FIG. 6 is a timing diagram illustrating two-way communications between reader 500 and a plurality of endpoints during four consecutive blocks of time I-IV. The arrows represent message transmissions between the reader and the endpoints; and the direction of each arrow indicates the direction of transmission (whether from reader 500 to the endpoints, or vice-versa). In time block I, initial messages a, b, c, and d are transmitted by four respective endpoint devices. Messages corresponding to reference letters that are underlined in FIG. 6 correspond to messages that are transmitted on even-numbered channels. For instance, initial messages a and d are on odd-numbered channels; whereas initial messages b and c are on even channels.

In time block II, the reader responds with commands requesting messages in the next interval. The responses directed individually to each of the four endpoints are indicated at a^, b', c', and cT, respectively. In this example, every endpoint operates with the same time delay, one second, for example, between initial message transmission and listen mode. Therefore, each of the reader's responses §1, b', c', and cf , is sent with the same time delay, e.g., one second, after the corresponding initial message was received. Also, during time block Il other endpoint devices transmit their respective initial messages e, f, g, and h. The reader continues to monitor the communications band when it's not transmitting and picks up initial messages e, f, g_., and h. In this example, there are two reserved time slots near the beginning of each time block for receiving requested messages. Each of responses a^, b', c', and cT instruct the respective endpoint to transmit its requested message such that the requested message is received during the appropriate reserved time slot. Requested messages A and D are transmitted on their respective even channels in the first reserved time slot, requested messages B and C are transmitted on their respective odd channels in the second reserved time slot. In a variation of this embodiment, any of responses a^, b', c', or cT can instruct the respective endpoint to transmit its requested message on a specified channel or at a specified reserved (or unreserved) time slot.

In time block III, the reader responds to initial messages e, g, and h (not f) with commands e^, ς£, and JV requesting data. Also, the reader responds to requested message B by requesting further data, as indicated at b". Additionally, during time block Ht, the reader receives initial messages i, j, k, and I. Requested messages E, G, H are transmitted by their respective endpoints on even channels in the first reserved time slot in time block IV. Requested message B is transmitted in the second reserved time slot on its odd channel. If the reader requires additional operations from any endpoint, it will transmit the request according to the endpoint's configured time delay following the previous reader request.

In another embodiment, the reader instructs multiple endpoints to transmit their requested messages at the same time, but on different channels, without having any of the channels reserved in advance. In this embodiment, the reader dynamically coordinates the channel assignments and scheduling in real time.

Two-Way Command and Control Functions

Table 1 below presents various examples of programming commands. Table 2 presents various examples of data requests.

Table 1

Program Commands

Set time / synchronize RTC

Schedule Audit Mode/ GDT Mode

Table 2

These examples of two-way commands and data requests facilitate a number of techniques for improving AMR system performance, such as endpoint battery life, probability of successful data communications, ease of installation/upgradeability, migration from handheld mobile to vehicle-mounted mobile to fixed networks, obtaining a wide variety of interval consumption data from endpoint devices with minimal communications overhead, enabling special operating modes for facilitating system audits and daily take measurements, and the like.

Adjusting operating mode for endpoints

In one embodiment, readers can selectively place individual endpoints in certain operating modes. One example of such an instruction is the sleep command described above. In this mode, the endpoint sleeps for a p reconfigured, instructed, or otherwise predetermined duration of time, then returns to its normal bubble-up operation. The sleep mode is useful for systems where further reads from the endpoint are not needed for some time after a successful communication. This may be especially useful in mobile readers. After collecting the needed data from each endpoint, that endpoint can be instructed to sleep. When this command is applied to every read endpoint, the result is a "trail of silence" behind the mobile reader. Endpoints that have been read no longer bubble up, which clears the communication band of unneeded transmissions that might otherwise cause data collisions, necessitating re-tries and further cluttering the air waves. Since the likelihood of data collisions is reduced, the sleep command can enable the use of longer messages for transferring more consumption intervals and other additional information. The time duration of the sleep mode can be configured to ensure that the reader is well out of communications range of the sleeping endpoint before it self-awakens by returning to its normal bubble-up mode.

In a fixed network embodiment, sleep mode may be employed to reduce the density of bubbling-up endpoints. For example, in a neighborhood having endpoints A, B, C, D, E, and F, in close proximity to one another, the group of endpoints A, C, and E can be alternately operated in their normal bubble-up mode with respect to the group of B, D, and F. This technique reduces the chance of message collisions. Another benefit of the sleep mode is that it conserves battery life for internally- powered endpoint devices. For endpoint devices on a strict reading schedule, if supplementary reads are not needed between scheduled reads, the endpoint may be instructed to sleep until the next scheduled reading window.

Another example of a configurable temporary operating mode is a mode of increased endpoint activity. For example, in mobile network systems, a utility provider may desire to conduct follow-up reads to collect additional information from certain endpoints following a general reading pass of a particular neighborhood. In such a system, endpoint devices may be configured to increase their bubble-up rate or their transmission power in a certain time window to increase the probability that a possible follow-on read attempt will be successful. In situations where follow-on reads are likely to occur in a time window beginning after a certain period, such as after several hours, and ending at the end of the next business day, the increased activity mode may be scheduled to begin and end to coincide with the time window. If reads are unlikely to take place in the time period after the last read and before the start of the time window for taking follow-on reads, endpoints may be commanded to sleep until the start of the increased bubble-up activity. At the conclusion of the follow-on read window, the endpoints automatically return to their default bubble-up mode.

Another use of increased bubble-up activity is in facilitating day take, which is a reading taken by an endpoint at a specific time of day - for instance, the consumption reading taken at 9:00 AM. Gas utilities often use gas day take across a system to monitor daily usage of gas in their system. Typical requirements are to read all of the GDT meters is a system within a few seconds to a minute of the specified hour and then take no longer than 1 hour to deliver the reading to the utility.

The two-way communications of the present invention enable programming the GDT time in the endpoint, and synchronizing the endpoint's real time clock to the network or UTC time. In one embodiment, when the GDT time occurs in the endpoint a reading is taken and then stored in the endpoint. This GDT reading is then transmitted in a bubble up fashion for 15 transmissions, at the standard bubble up rate the endpoint was previously running on, to permit multiple transmissions for good read reliability performance. Unlike usual bubble-up operation, which may involve the endpoint transmitting a new measurement from one bubble-up event to the next, the GDT mode in one embodiment repeatedly transmits the GDT value at every bubble-up event occurring while the endpoint is in GDT mode.

After the 15 transmissions, the endpoint will then return to its normal bubble- up mode. When the endpoint transmits the GDT to the fixed network reader the GDT consumption is transmitted along with the current time of the endpoint given in the time since midnight. If the time is out of specification for getting GDT then the endpoint will be sent a new time from the fixed network reader.

A further example of operating mode adjustment that is afforded by the two- way communications aspect of the invention is adjusting operating parameters to facilitate migrating the AMR system from one reader type to another. Endpoints can be configured to bubble up slower in a fixed network installation than in a mobile system. Additionally, the transmission power may be set higher in a fixed network when the bubble-up rate is slower.

Channel utilization is governed by different regulations throughout the world. Each utility provider system can set and modify endpoint behavior for migrating their AMR systems to comply with the regulations applicable to it. In one example embodiment, the two-way communications are used to selectively reconfigure endpoint devices to operate under FCC Part 15.247 rules, or under 15.249 rules based on the desired level of performance, the length of messages being transmitted, the measured communication performance (e.g., RSSI) associated with communication with certain endpoints, the measured channel conditions (e.g., noise floor or interfering signals), and the like.

In one example embodiment, endpoints may be programmed to bubble at a slow rate of one a minute until a monthly read time. Then, the endpoints would bubble up faster for a few days or until they are read. At that time, the endpoints would be set to bubble slowly again. This approach keeps endpoints available for unscheduled reads and, at the same time, conserves battery power and channel clarity.

Coordination of communication channels

As described above, the two-way exchange between reader and endpoint can take place on the channel of the original initial message transmission, or can utilize different channels. In embodiments in which different channels are used for a particular two-way communication sequence, a variety of approaches may be utilized for coordinating the channel hopping. For example, the listening channel can be algorithmically determined in some fashion, defined according to a specified channel hopping sequence known by both the endpoint and reader, or based on a predefined logical relationship to certain circumstances. This can provide some degree of security from eavesdropping by an unauthorized receiver that does not know the hopping sequence. In a related embodiment, the listening channel can be derived based on the value of a certain data field of the most recently transmitted message (e.g., step 206 or step 218 of FIG. 2) according to a known derivation algorithm.

In one example embodiment, the endpoint controls the channel hopping sequence. For example, each transmission by the endpoint, such the initial message or requested message, can include a field indicating the frequency the endpoint's receiver will be listening to. In a related embodiment, each transmission (whether from an endpoint or from a reader) will indicate the channel on which to transmit a responsive message. In another embodiment, the reader takes control of the channel selection when it initiates two-way communications. For example, the reader can specify the frequency on which the endpoint should transmit each of its messages.

In embodiments where the reader controls channel selection, the reader can coordinate the activity of different endpoints to manage the utilization of the communication band. This degree of control can be used advantageously to avoid collisions. In one example embodiment, in a mobile system, a reader uses two-way communications to transfer a channel hopping schedule to each endpoint. Each endpoint's channel hopping schedule can be unique to that endpoint, and can be designed to make certain that endpoints that are located within a reader's communication range operate at different frequencies.

In one embodiment, the reader is adapted to detect whether the frequency of the endpoint's transmission has drifted from the center frequency of the channel on which the endpoint is transmitting. For example, in a software-based radio such as the example embodiments described above, the receiver's radio can recognize if the energy of a received signal is appearing simultaneously in adjacent frequency bins. This suggests that the endpoint's transmission is not centered at the channel's frequency. In a subsequent message to the endpoint, the reader can include a command to the endpoint to correct its channel definitions.

In another type of embodiment, other techniques of spectrum spreading may be utilized such as, for example, fast frequency hopping (i.e., changing frequencies at a rate that is faster than the data rate), or direct sequence spread spectrum (DSSS) techniques. Persons of ordinary skill in the relevant art

Alarm/Error handling and Call back conditions

In one embodiment, an endpoint can include certain alarm or error flags in its initial message. The reader examines each initial message for the presence of such flags and, if any alarm or error conditions are present, the reader can respond in some special manner. For example, the reader may request the endpoint to return the settings of certain configuration parameters, or may command the endpoint to return the contents of a specific memory space and registers. As another example, the reader may treat certain error or alarm flags received from endpoints as call back conditions under which to communicate the presence of the alarm or error to the head end at the earliest opportunity.

If the endpoint 108 is on a meter, such as a gas meter, and all that is required are simple, once-a-day consumption reads, then the endpoint 108 transmission packet may also confirm the data and may bubble less often to conserve the battery. The packet can include a cyclical redundancy check (CRC). Once the transmission packet is received by the reader 109, and if the reader 109 wants more information such as obtaining tamper data, or to perform various functions such as resetting a register, setting timing, or adjusting frequency, the reader 109 is able to carry on a two-way interchange by transmitting the request when the given endpoint 108 is listening.

Information gathering and decisions based on channel conditions

According to one aspect of the invention, readers or endpoints measure and indicate the received signal strength (RSSI) for received transmissions. In one such embodiment, a receiver measures the RSSI for each received initial message. If the RSSI is below a certain predefined threshold, achieving a successful 2-way communication may be less likely than desired, resulting in retries, waste of energy in battery-powered endpoints, and channel clutter. The receiver can determine, based on the RSSI of a received initial message, whether to initiate two-way communications with that endpoint. By selectively communicating only with endpoints that appear to be communicating well, overall system performance can be improved, and wasteful failed transmissions can be substantially reduced.

Conversely, if a first communication from a an endpoint is received with a particularly good RSSI (e.g., better than the average RSSI value associated with the endpoint), the reader can request more data than it normally would. For example, the reader may request more interval data with a higher granularity (e.g., 80 10- minute intervals as opposed to 40 20-minute intervals). More generally, the extent of two-way communications may be dynamically selected by the reader based on the RSSI values of the transmissions from the endpoint.

In a mobile collection embodiment, a reader can compare an RSSI value associated with the most recently received initial message from a certain endpoint with that of the previous initial message from the same endpoint. As the reader approaches the endpoint, the RSSI value is expected to increase. Using this information, the reader may predict if an endpoint's RSSI is likely to improve in soon- to-be-received initial messages. The reader may thus elect to wait until a later time to initiate two-way communications with that endpoint. In a related embodiment, the reader can identify a "best available" initial message from an endpoint which is sending initial messages having lower than desired RSSI values. For example, consider initial messages received from such an endpoint having the following RSSI values under the desired minimum threshold of 0 dB: -12 dB, -6dB, -3 dB, -4 dB. Based on these values, future initial messages are not likely to be significantly better than the most recent value of -4 dB. Therefore, the endpoint may elect to initiate the two-way communication with this endpoint following receipt of the next initial message from the endpoint.

In a related embodiment, the reader maintains records of past RSSI measurements for each endpoint, or passes on the RSSI information to the head end for maintenance of this information. Certain RSSI trends may prompt the AMR system to adjust the way information is collected from certain endpoints. For example, in mobile systems, the route of the mobile reader may be adjusted, or an endpoint may be re-assigned to a different data collection route or reader. In a fixed system, a repeater may be placed to improve communications with certain endpoints in certain areas.

In one embodiment, fixed readers collect record of every endpoint that is in range, together with the RSSI values associated with each of those endpoints, and provide this list to the head end. Certain endpoints may be within communications range of more than one receiver. The head end can determine which of these endpoints transmits to which reader with the best RSSI, and, for each endpoint, instruct the best reader to add that endpoint to its list of endpoint with which to initiate two-way communications. For readers that receive initial messages from certain endpoints at a lower RSSI than received by other readers at higher RSSI, these readers can be instructed to disregard initial messages from those endpoints. In a related embodiment, readers can communicate with one another to arbitrate which endpoints are to be associated with which receiver based on the RSSI values.

In one embodiment, if an endpoint's RSSI value is lower than desired, that endpoint may be instructed or programmed to increase its transmission power for the two-way communication, or to bubble up more frequently. In such cases, the utility provider may be advised by the AMR system to add additional battery capacity to the endpoint to support the higher levels of activity, thereby preserving the desired useful life of the endpoint. In a related embodiment, if an endpoint's RSSI value is significantly higher than needed for reliable communications, that endpoint may be instructed to reduce its transmission power. In another related embodiment, endpoints maintain records of RSSI values of received reader-originated transmissions. Readers may instruct endpoints during the two-way communications to transfer their maintained RSSI values. This information can be passed to the head end for system performance analysis. Certain decisions based on this information can also be made by the readers. For example, in one embodiment, a reader may determine whether or not to transmit lengthy configuration information to an endpoint that is receiving a relatively weak reader messages.

Besides measuring RSSI values, readers or endpoints can measure channel clarity, and make certain decisions based on this information. In one example embodiment, a reader takes measurements of the noise floor of different channels during times of idle communications. In fixed networks, such information may be used to characterize the communication band as a function of time of day. If certain times of the day routinely exhibit reduced channel clarity on certain channels, the reader may adjust its operation to avoid communications on those channels. The reader may disregard initial messages occurring on unclear channels, or the reader may attempt to instruct endpoints using the two-way communications to preferentially utilize clearer channels. In mobile networks, readers may characterize channel clarity as a function of time of day and of geographic location. Such information may be used to adjust the reader's operation similarly to the examples described above. In addition the reader's route may be adjusted to avoid certain dead spots, for example.

In a related embodiment, the reader measures channel clarity during the time duration following receipt of an initial message from an endpoint and the reader's communicative response thereto. If a channel is less clear than a predetermined threshold, the endpoint may be instructed to change channels, or to re-initiate communications at its next bubble-up event on a different channel before requesting long message transmissions from the endpoint.

In another embodiment, the endpoints can measure channel clarity by listening on the next channel prior to initiating communications with an initial message transmission. If that channel is noisy, the endpoint may decide to avoid transmitting its initial message on that frequency. The endpoint may then switch to a new channel, and repeat the clarity measurement prior to initiating communications. Endpoints may log measured channel clarity as a function of time, and pass this information to the reader using the two-way communications when so requested.

Repeaters

Referring again to FIG. 1 , a repeater 122 may be used in the system 100 and, if so, in one embodiment, the repeater 122 can function much like an endpoint. For example, repeater 122 may operate in a low-power standby, or sleep, mode for a majority of the time, and may bubble up with an initial message directed to the main reader 109 similarly to the way an endpoint 108 operates. After the initial message transmitted by repeater 122 is acquired by the main reader 109, reader 109 may instruct repeater 122 to transmit a list of endpoints within it communication range. The repeater follows this instruction by enabling its receiver for some predetermined period of time, and logging the endpoint IDs of endpoints transmitting initial messages that are received by repeater 122.

Subsequently, repeater 122 bubbles up to initiate a communication with reader 109. Reader 109 initiates two-way communication with reader 122 similarly to the procedure described above with reference to FIG. 2. In two-way communications mode, repeater 122 sends the IDs of the detected endpoints to reader 109. Reader 109 determines which of these endpoints the repeater 122 should track.

Repeater 122 may also monitor and record RSSI information similarly to the techniques described above. The RSSI information can be used by either the repeater, the reader, or the head end to instruct the repeater 122 and/or the reader 109 how to operate with respect to each of the endpoints.

Reader 109 communicates a command to repeater 122 to instruct repeater 122 to collect data from those endpoints. The repeater 122 then synchronizes itself to those endpoints 108. When the reader 109 desires a reading, it passes a command to the repeater 122 to collect reads. The repeater 122 passes this command to the endpoints 108. Once all of the reads are collected, the repeater 122 passes them up to the reader 109. In another configuration, the reader 109 passes an endpoint ID list and a reading schedule to the repeater 122. Repeater 122 communicates with the endpoints on the list, and logs their consumption and related data in a database. When asked for end point reads, the repeater 122 sends the most recent readings from its database for each endpoint. This method has the latency of the bubble time interval of the endpoint 108 plus the reading cycle of the repeater 122.

In one type of embodiment, the repeater 122 is battery powered. A repeater 122 of this type can sleep when it is not required to get data from the endpoints 108. Repeater 122 can wake at predetermined intervals to bubble up to reader 109 and to listen for its endpoints 108. If a short latency is required, the repeater 122 can operate a timer to synchronize to the scheduled bubble-up times of endpoints 108. If latency is not an issue, the repeater 122 is able to turn on its receiver once an hour, for example, for a time duration long enough to read its endpoints 108, (e.g., 20 seconds for endpoints bubbling up more rapidly).

FIGs. 7A and 7B are process flow diagrams illustrating an example operating sequence 700 involving a reader 109, a repeater 122, and an endpoint 108. Referring to FIG. 7A, repeater 122 operates in a low-power sleep mode until the next bubble up event, as indicated at step 702. At step 706, repeater 122 transmits an initial message that includes its unique identification (from which reader 109 can determine that the transmission is from a repeater, rather than from an endpoint). Reader 109 operates at steps 204-205 212, 214, and 216 to receive and process the repeater's initial message, and to determine whether to initiate 2-way communications with repeater 122 as described above with reference to FIG. 2. Repeater 122 and reader 109 observe the time delay of step 708, during which time repeater 122 may operate in its sleep mode. At step 710, repeater 122 enters a receive mode, and at step 718, reader 109 transmits an instruction to repeater 122, which is received at step 720. If it is not received, repeater 122 returns to its default bubble up mode of operation, as indicated at step 711. At step 722, repeater begins carrying out the instruction, after which the repeater may return to its default operating mode, as indicated at step 723. If the instruction included a request for information transmission, repeater 122 observes time delay 724, after which it transmits the requested message at step 726. Reader 109 receives the requested message from repeater 122 at step 728, and processes the same at step 730.

FIG. 7B illustrates an example sequence 750 that follows initiation of instruction processing step 722. Sequence 750 involves operating repeater 122 to communicate with an endpoint 108. In a practical implementation of this example, repeater 122 would likely communicate with a plurality of endpoints 108 in the same manner. At step 754, repeater 122 enters into its receive mode to listen for any endpoint initial message transmissions. Unlike reader 109, which operates its receiver circuit most of the time, repeater 122 may remain in its receive mode for a limited time, as represented at step 755. Endpoint 108 operates substantially as described above with reference to FIG. 2.

At step 762, the initial message from endpoint 108 is received by repeater 122. The message is processed at step 764. This may include comparing the endpoint's ID against the repeater's list of endpoints with which to communicate. Repeater 122 determines if further communication is called for at step 766. Repeater 122 may forward the information contained in the endpoint's initial message and not require additional information from endpoint 108. In other situations, repeater 122 may simply log the endpoint's ID as part of assessing the endpoints in its communication range. As described above, repeater 122 may require further instructions from reader 109 to track this particular endpoint 108. Assuming such communication is needed, repeater observes time delay 208. Unlike reader 109, repeater 122 may sleep during time delay 208. Repeater 122 may also communicate with other endpoints 108 or with one or more readers 109 during this time.

At step 768, repeater 122 transmits an instruction to endpoint 108. The instruction can initiate 2-way communications, configure endpoint 108, or command endpoint 108 to enter a specified operating mode, such as sleep mode, for example. Repeater 122 then observes time delay 224, during which it may sleep or communicate with other endpoints or readers. Repeater 122 enables its receive mode 754 in time to receive, at step 778, the endpoint's requested message transmitted at step 226. At step 780, repeater 122 processes the requested message. In one example embodiment, the processing step 780 includes parsing and placing the information of interest contained in the received requested message from endpoint 108 into a queue or into a composite message for transmission to reader 109.

The performance of the repeater 122 does not have to equal that the main reader 109 in terms of receiver sensitivity and transmit power. Rather, the repeater 122 can be used primarily as a hole filler or AMR system range extender. Repeaters can also be utilized to improve AMR system communication traffic management. For example, repeaters can be assigned to groups of endpoints, and their communication times can be scheduled to utilize the airwaves efficiently and avoid collisions from excessive transmissions.

A significant benefit of the repeater is that it is low cost, easy to place, and provides desirable battery operation. Battery operation permits functionality during power outages, and substantially reduces the cost of installing the repeater. Additionally, battery operation facilitates placement of the repeater in locations where mains or other external sources of power (e.g., sunlight) are unavailable. In one embodiment, a repeater has the same hardware platform as an endpoint. For battery-powered repeaters, additional or larger batteries than those present in typical endpoint devices may be installed to facilitate longer life between service calls.

Interval Data Logging

According to another aspect of the invention, an endpoint stores a large quantity of consumption measurements in its memory. This storage space can store many more intervals than can be transmitted in a typical interval message packet. For example, in one embodiment, the endpoint stores 40 days of hourly consumption data. The intervals associated with this data are can be tracked by a real time clock (RTC) of the endpoint. The RTC can be synchronized periodically by the readers using the two-way communications protocol described above.

In one embodiment, as depicted in FIG. 8A, the interval data is stored in a data structure that is an array with 40 rows (days) and 24 columns (hours). In another embodiment, as illustrated in FIG. 8B, the array can have three or more dimensions. Referring to the example of FIG. 8B, the array arranges interval reads taken every minute, together with hourly data, and daily data. The column indicated at 852 represents daily reads, taken on the second hour and at the third minute. The column or row indicated at 854 contains minute-by-minute reads taken on day 5, hour 2. The column or row indicated at 856 contains hourly reads on day 2, taken at minute 2.

More generally, this aspect of the invention structures the consumption data in tiers of time granularity. At the finest granularity, every item of meter data is present. For example, if consumption readings are obtained every 10 seconds instead of hourly, the finest level of granularity would be 10 seconds. At the next tier of time granularity, only one or more subsets of the full set of meter data is included. For example, if readings are taken every minute, and if the utility provider wishes to obtain hourly reads and weekly reads, then hours and weeks can be included as separate dimensions in the data structure.

Each cell in the array can contain the total (absolute) consumption measured when the value was stored in that cell, or can contain a delta value relative to an adjacent cell or to a reference value.

When the endpoint is operating, it will sequence through each cell of the finest time granularity, then the next finest, and so on, filling in the consumption or delta value in the corresponding cell. This process continues to the last row of the array. When the array is full, the cells can be populated starting at the opposite coordinate (i.e., it will wrap around and start over)

Since the endpoint has knowledge of time, it can be configured to always sample its finest granularity interval data at the same instant. For example, in the case of hourly reads, the endpoint can store the interval information as it existed at the top of each hour.

Referring to the example of FIG. 8A, when a reader requests a set of daily reads, such as for move-in/move-out, the endpoint will return the most recently completed column from the array. This will return an array holding the consumption values for the last interval and 39 deltas for the previous days.

A dump of the entire interval array is possible as a series of commands under FCC Part 15.249 rules. To conduct a "Dump AH" a programmer is utilized, and the programmer will accomplish this task at 0 dBm on the programming frequency. The programmer can perform a series of 24 Interval requests to get the 24 sets of hourly interval readings that constitutes a dump of all intervals.

By structuring the collected data at the endpoint in this manner, requests by the reader or repeater for certain intervals to be returned by the endpoint can be communicated simply. For example, a request for interval data can specify which row or column (or plane, etc.) is desired. Additionally, in situations where large amounts of interval data are being transferred, and an error is detected, a follow-up communication by a reader can request specific intervals that were lost in the failed portion of the earlier communication without having to re-transmit the entire set of interval data.

In a related embodiment, a reader can utilize two-way communications to reconfigure the time granularity definitions in the endpoint. In another related embodiment, an endpoint may be configured to transmit interval data at a different data rate. For example, in a mobile system where a reader is in communications range with each endpoint for a limited amount of time, the data rate for larger interval data messages may be set to a higher value to enable more data to be communicated during the available window.

Example Implementation

The following describes a specific implementation of the RF Based Meter Reading System described in the paragraphs immediately above. In this embodiment, communication occurs in the 900 MHz ISM band. It could however be implemented at different frequencies without departing from the spirit or scope of the invention. On off keying (OOK) and frequency shift keying (FSK) modulation are utilized.

Initially, an endpoint, such as endpoint 108 (FIG. 1) bubbles up to transmit a SCM. Immediately after transmitting an SCM the endpoint 108 goes into receive mode. The SCM that is transmitted is sent using OOK or FSK. OOK can be used for backwards compatibility with existing readers, and for power savings (since approximately 14 of the bits require zero energy to transmit). FSK can provide improved performance. When the endpoint 108 goes into receive mode it utilizes an FSK receiver. The SCM is modified by appending the channel that the receiver will listen on. In addition, other information may be appended such as tamper flags requesting an immediate call back from the reader 109. When the reader 109 receives the SCM, if it requires more information from the endpoint 108, it will carry on a two-way FM session with the module. The SCM will bubble up from the endpoint 108 on fixed intervals. It will also be transmitting at 1 mW (i.e., 0 dBm) to be compatible with the existing endpoints 108 already deployed and operating under FCC 15.249 rules. Since the SCM synchronizes the endpoint 108 to the reader 109, any two-way FM transmissions that follow can utilize higher power transmissions and operate under FCC 15.247 rules. If the SCM is transmitted at a controlled frequency, with little drift, then the receiver trying to read it can be a narrow band receiver. By using a narrow band receiver, the receiver sensitivity can by increased by over 5 dB, over existing reading devices that employ wideband receivers of around 250 kHz. These endpoints would be backward compatible into existing ERT-based AMR systems.

In one embodiment, advanced readers 109 employ a DSP radio enabling the receive bandwidth to be set by DSP firmware. This arrangement enables reading previously-existing legacy endpoints 108 with reduced sensitivity. The system at this level can be used primarily by a mobile meter reading system that utilizes readers such as handheld readers and vehicle-mounted readers. The bubble rate is set to maximize battery life and to provide the desired level of system performance. Since it is a two-way system, the reader 109 is able to tell the endpoint 108 to bubble at a much slower rate until the next read time. This saves battery life but still leaves the endpoint 108 available for reads.

As the deployment is migrated from a mobile meter reading system to a fixed network meter reading system, the endpoints 108 can be programmed to transmit the data at a much slower rate. In an example of a fixed network situation, only the ID is transmitted to reduce transmission time. If the data rate is reduced to 1200 baud about 10 dB of gain can be realized. Since the transmission time will be longer, the bubble rate can be reduced to maintain battery life. A system running in this mode is able to use fewer readers that are placed in the field. The two-way FM link can still be used; however, higher transmission power may be needed to match the AM performance in either mode (fast or slow data rate). If a channelized receiver is used it is possible to transmit the SCM at a higher power, e.g., +10 dBm, and comply with FCC 15.247 rules on the AM bubble up.

Further development of this system includes having the endpoint 108 operate under 15.247 rules FM two-way all the time. This system would be most appropriate for electrical meters that are line-powered. The electrical meters can transmit as often as they want and leave their receivers on to keep synchronization with a fixed network radio.

In order to get better coverage over a deployed metering system, a repeater 122 can be implemented. This repeater 122 is used mainly as a hole filler. The repeater 122 is not intended to have the same receiver sensitivity and, as a result, it can use lower cost and lower power components. It is possible to have the repeater 122 run off of lithium batteries at relatively low cost. The repeater 122 can bubble up just like an endpoint. Once it is acquired by the reader 109, it is told to go into a listen mode to find all of the endpoints 108 in its area. The repeater 122 then transmits the IDs of the endpoints 108 within its communication to the reader. The reader 109 compares the list to the endpoints 108 that the reader 109 can communicate with. The reader 109 then instructs the repeater 122 to listen only to the endpoints 108 that the reader 109 cannot communicate with reliably. The repeater 122 tracks the endpoints 108 by turning on its receiver at the time the endpoint 108 is due to bubble up.

In the case of monthly reads, the repeater 122 can stay asleep for most of the month and then turn on and acquire its endpoints 108 near the reading time. In general, if the reader 109 wants a reading from an endpoint 108 under a repeater 122, the reader 109 tells the repeater 122 on the two-way FM link. This happens after the repeater 122 bubbles up its ID. The repeater 122 then waits for the endpoint 108 to bubble up and either uses the SCM data or requests additional data. Once the data is obtained the repeater 122 sends it up to the reader 109. It may be sent as soon as it is acquired or it may synchronize with the next bubble up. To minimize the number of channels the repeater 122 or reader 109 look for the endpoint 108 on, a select number of channels can be used for bubbling up. These channels can be distributed across the ISM band. This arrangement works under the FCC § 15.249 rules.

Quantitative Improvement

The quantitative improvement provided by the specific implementation described above can be better understood when described in contrast to the ltron meter reading technology of today. The ltron meter reading technology of today operates under FCC 15.249 rules. The endpoint 108 transmits at 1 mW (i.e., 0 dBm) output power and its receiver has a sensitivity of around -90 dBm. This receiver operates in the MAS band, which requires an FCC license. The readers 109 for this system generally fall into two categories: (1) A mobile reader such as a van that has a receiver sensitivity of -113 dBm and a wake-up transmitter output power of around +38 dBm; and (2) Other Readers, e.g., handhelds and fixed networks, having a receiver sensitivity of around -108 dBM and a wake-up transmitter power of +23 dBm and +30 dBm, respectively. The RF link in today's encoder/receiver/transmitter (ERT) system is:

Van to ERT = 123 dB Reader to ERT = 108 d B

ERT to Van = 113 ERT to Reader = 108 dB

Aspects of the present invention, at a first level, address a mobile meter reading system. Specifically, this aspect provides backward compatibility and provides for future migration. Embodiments of the present invention operate to limit the amount of frequency drift from the endpoint 108 so that a receiver with a narrower bandwidth can be used. Using a frequency locked RF chip such as the Bluechip BCC918 and configuring it to transmit OOK at low power provides a frequency stable endpoint. This then enables the use of a narrowband receiver and increases receiver sensitivity. If the bandwidth is reduced from 256 kHz to 50 kHz then around a 7 dB sensitivity improvement can be realized. The frequency stable endpoint 108 can bubble up an SCM transmission, thereby removing the need for a wake-up transmitter. This transmission can have, for example, an output of 0 dBm that is compliant with FCC § 15.249 rules just like the ltron ERT of today. If the endpoint 108 is deployed in an existing system, an existing reader 109 can read it with the same performance as the existing system. If it is in a new deployment then a new reader can read it with a 7dB improvement in the link. The new reader 109 can read existing ERTs as well. If a DSP channelized receiver is employed then the receiver can decode on a narrow channel for new endpoints 108 or it can average channels together to get the required bandwidth to read old endpoints 108. When reading old endpoints 108 the system performance is that of an old system, i.e., 7 dB less link than a new one. The RF link in the system of according to this embodiment (for mobile systems) is:

ERT to reader = 116 dBM (based on new CCU4 receiver sensitivity of -109 dBm)

The SCM that is transmitted can include information appended to the end of the message. This does not interfere with the ability of an old reader to decode the message and it does provide additional information for the mobile meter reading system. Additional information can include a channel number for the reader 109 to call back on as well as priority flags that may indicate a power failure, for instance, requiring an immediate callback from the reader 109. After the endpoint 108 sends the SCM packet, it either listens on the same channel on which it transmitted the SCM, or notifies the reader of the channel number on which that it will be listening as part of the SCM packet, for example. The endpoint 108 then goes into receive mode and listens on that channel for a short period of time, e.g., 5 to 10 milliseconds. The receipt of the SCM synchronizes the reader 109 to the endpoint 108 (in time and in frequency) so the reader 109 knows when and where to locate the endpoint 108. If the reader 109 requires more information such as ID or response to a power fail it can initiate two-way communications on the channel that the endpoint 108 will be listening on as described above.

The two-way communications between the reader and the endpoint are frequency modulated (e.g., FSK) and at a higher power. Since both ends are synchronized the two-way communications can take place under the FCC 15.247 rules. Using the example of a bluechip RF part, the endpoint 108 has a receiver sensitivity of -105 dBm at 9600 baud (19.2k Manchester encoded). The receiver's transmit power is +10 dBm. If the reader 109 has a transmit power of +10 dBm and a receiver sensitivity of -105 dBm then it would match the performance of the AM SCM link. The RF FM two-way link in the system of this embodiment (for mobile systems) is:

ERT to reader = 115 dB

Reader to ERT = 115 dB

One example of a SCM message format is as depicted below:

At a second level, embodiments of the present invention are applicable to fixed meter reading networks. When the AMR system is sufficiently saturated with endpoints that the utility provider wants to move to a fixed network solution, the endpoints already deployed in the mobile system can be reconfigured to operate in a somewhat different regime. In one example, the system remains a bubble up system but it bubbles up at a slower rate. The data rate is also reduced to 1200 or 2400 baud. In this mode, the endpoint 108 can bubble up only its ID to reduce transmit time. Alternatively, the endpoint can transmit an SCM or SCM-like packet.

At the slower data rate, a processing gain of about 10 dB can be realized at the receiver. This gives the receiver an effective sensitivity of about -126 dBm. A slower data rate can be used for the two-way exchange as well, improving the receiver sensitivity. Since this is a fixed network, the endpoints are always in range of the reader, so there is no time window in which communication must be completed. By utilizing a quality low noise amplifier (LNA) that is commercially available in the reader's receiver, and cutting the data rate in half, a 5 dB gain in reader sensitivity on the FM link can be obtained. This provides a sensitivity of -110 dBm in the FM receiver.

The endpoint receiver gains around 3 dB in sensitivity from a slower data rate. The reader 109 can transmit at 18 dBm on the FM link. If a Bluechip ASIC is used, a power amplifier can be included to increase its output from 10 dBm to 16 dBm. This gives a balanced link for both the AM bubble up and the FM two-way links. The fixed network RF links of the present invention are as follows:

AM Endpoint to reader = 126 dB FM endpoint to reader = 126 dB FM reader to endpoint = 126 dB

Repeaters

The issue of holes in the reading area of a fixed network is of real concern. As such, a repeater 122 can be used to relay information from an endpoint 108 to the reader 109. The repeater 122 does not have the same performance as the main reader 109 because it is mounted closer to the endpoint 108 and is much lower in cost than the reader 109. Further, the repeater 122 can be battery-powered so that connecting to the mains is not a concern. The repeater 122 can use an RSSI type decoder for decoding AM signals from an endpoint 108 and has a sensitivity of -106 dBm. In one embodiment, the repeater 122 bubbles up its ID just like an endpoint.

When a reader 109 acquires the repeater 122, the reader 109 instructs the repeater to enter a listen mode to find all of the endpoints 108 within communication range. This leaves the repeater 122 receiver on for many tens of seconds while it locates the IDs of endpoints 108 bubbling up in its vicinity. The repeater 122 then sends this information up to the reader 109. The reader 109 will determine which of the endpoints 108 it cannot communicate with and instruct the repeater 122 to listen to only those endpoints. In an alternative embodiment, this selection may happen further up the chain at the head end to arbitrate between system cells and determine which repeater 122 will be assigned which endpoint. When it is time to read the endpoints 108, the reader instructs the repeater 122 to get a reading when the repeater 122 bubbles up its ID. The repeater 122 then collects the reading from the endpoints 108 and passes them up to the reader 109. This may cause latency in the system.

One example technique to reduce this latency is for the reader 109 to transmit a reading schedule to repeater 122. This enables repeater 122 to perform the reading of its assigned endpoints 108 automatically. Repeater can send its collected endpoint data to the reader 109 during the next bubble up period. To conserve power, the repeater 122 synchronizes its receiver time to the anticipated transmit time of endpoints 108 in its domain; the repeater 122 sleeps between reads. For the endpoints 108 and the repeaters 122, if the reading schedule is regular, e.g., daily reads, then the endpoints 108 are instructed to bubble up at a slower rate for 23 out of 24 hours. The endpoints 108 and repeaters 109 then increase their bubble rate as the read time gets near. Once the reading is obtained the endpoints 108 and repeater 122 bubble slowly again. While bubbling up at a slower rate permits unscheduled reads to take place, it may take longer to get them.

Battery life

The following description provides an analysis of estimated battery life that may be attainable in endpoints operating according to aspects of the invention. In this embodiment, an endpoint uses a 3.6 V lithium ion A cell battery having a capacity of approximately 3.3 A-H.

The average current from the battery during transmission is about 96.5 mA in 24 dBm mode, or about 22mA in 10 dBm mode. The duration of the SCM transmission is 5.86 ms. This would give 347.4 mW in 24 dBm mode and 79.2 mW in 10 dBm mode. Multiplying these values by 5.86 ms produces 2 mW-seconds for 24 dBm and 464.1 uW-seconds in 10 dBm.

The processor draws slightly less than 2 micro amps when the endpoint is in its sleep state. The receiver circuit draws about 15.2 mA for 2 ms during the listening time windows, or 109.6 uW-seconds.

All of these values averaged over the bubble up period work out to an average current draw of about 14uA, which can be sustained for 20 years on the A cell. This estimate includes taking into account empirically observed non-linearities in the battery drain based on load conditions.

IDM messages, or requested messages having longer packets can have variable length. A typical IDM response is expected to be about 120 bits at 16384 bits/sec, or 7.3 mS. In this embodiment, IDM messages are sent at about 24 dBm, or 347.4 mW. IDM transmissions occur only when asked, which is generally on the order of once per month, so they represent a negligible impact to the overall battery life, when endpoints are operated as such.

Extending transmission duration

Conventionally, the transmitter circuit includes a power regulator that must receive a supply voltage in excess of a certain threshold. One challenge with long transmissions is their high power draw can load the supply, causing a dip in supply voltage, thereby shutting down the power regulator. While conventional approaches to mitigate this effect, such as placing capacitors across the power supply, are well known, these approaches provide only limited advantage due to size and cost constraints associated with using large capacitors.

FIG. 9 is a circuit diagram illustrating an example embodiment of a switched capacitor arrangement for temporarily boosting the available power for powering the transmitter circuit during data transmissions. This voltage boost permits the power regulator to operate above its threshold voltage for a longer time, thereby enabling longer transmissions. In normal low power mode switches SW1 and SW2 are closed and SW3 is open. These switches may be implemented with transistors, transmission gates, relays, or the like. In this configuration the output voltage is 3.6 volts. With the capacitors C1 and C2 connected in a parallel configuration the current drawn from the module is shared by both capacitors. The parallel bulk capacitance is sufficient for operating an endpoint and producing short high powered transmissions. When a high voltage level is required, such as for transmitting longer high powered data messages, switches SW1 and SW2 open and SW3 closes. This provides 7.2 volts at the output. This higher voltage can be used to provide improved overhead for the transmitter. Advantageously, because the capacitors are already charged there is no charging latency to produce the higher voltage virtually immediately. When the high power mode is no longer needed the capacitors are switched back to a parallel configuration. The capacitors are then recharged in parallel. . There is latency in recharging the capacitors but it is much smaller than the bubble up times required by the AMR.

Resistor R1 is shown to represent the series resistance of the battery. Additionally, R1 could be used to limit the charge current of the capacitors, minimizing the current drain and therefore voltage sag on the battery. Capacitors C1 and C2 are sized so that when they are connected in series they provide enough capacitance for the high powered message transmission. Low Cost Mobile Daily Interval Meter Reading System

The mobile daily interval reading system according to embodiments of the present invention utilizes the concepts described above but further expands on the earlier discussion by applying additional techniques for collecting daily interval data.

The mobile daily interval reading system works as described herein below. If an endpoint 108 is deigned to transmit at a higher power, e.g., +10 dBm, and the receiver has a sensitivity of -114 dBm, a one-mile range can be achieved in a mobile environment. If the endpoint 108 is a bubble-up endpoint 108 that transmits every ten seconds and the reader 109 travels at 30 miles per hour the reader 109 is in range for approximately 100 seconds. The endpoint 108 can be configured to transmit either in AM or FM and send an initial message such as the Standard Consumption Message (SCM) that the ltron ERTs send today. It can also have an FM receiver with a sensitivity of around -109 dBm for low data rate messages. After the endpoint 108 transmits its consumption data it listens on the same channel it transmitted on. If this is used in an electric meter the endpoint 108 can leave its receiver on as long as it is not transmitting.

As described above, this system can be modified to improve field service life in battery-powered products. When the reader 109 receives a message from the endpoint 108 it can take a measurement of the signal strength (RSSI) and determine if the endpoint 108 is in range or the channel is clear enough for subsequent transmissions. If the RSSI value is below a threshold, or if the channel is not clear the reader 109 does not reply and the endpoint 108 retransmits its SCM ten seconds later on another channel as part of its normal bubble-up operation.

When the RSSI is strong enough and the channel appears to be clear, the reader 109 transmits a command to the endpoint 108 to send some number of intervals and on what channel or channels. The reader 109 transmits this request at +10 dBm, or could go to +20 dBM if needed. This complies with the 15.247 rules because the endpoint receiver would be tracking the transmitter of the reader 109. Actually, the transmitter of the reader 109 is tracking the endpoint receiver since the reply is on the same channel that the endpoint transmitted on. It is possible for the endpoint to skip a pre-defined number of channels up or down from its last transmission just to keep the band randomized, but this is not required. The endpoint 108 can send data to the reader 109 at a higher data rate than the SCM transmission, e.g., 20k bits per second. If the endpoint 108 is in an electric meter it can save 15 minute interval data in 2 bytes (16 bits) of memory. There are 96, 15 minute intervals in a 24 hour period. If the endpoint 108 transmits 35 days worth of intervals, that amounts to 3360 intervals, or 53,7690 bits. Allowing for some overhead, that number can be rounded to 60,000 bits. At 20,000 bits per seconds (BPS) the endpoint 108 can transmit 35 days of 15 minute interval data in 3 seconds. If the data rate is increased to 32,768 BPS the transmission time is 1.83 seconds for 35 days worth of data. A data rate of 32,768 BPS should cost about 3 dB in receiver sensitivity. However, with 110 seconds in range and only 1.83 seconds to send the data there is some sensitivity, and therefore range, to give up. The FCC rules for 15.247 specify that at the higher power a transmission can only last 0.4 seconds in a 10 second period on any one channel. The endpoint 108 can hop between channels to send all of the data. To send 35 days worth of data the endpoint 108 would hop over 5 to 6 channels depending on packet overhead. If a transmission is lost due to a hop to a noisy channel the endpoint 108 can be instructed to resend only that block on another channel.

Once all of the data is transmitted the endpoint 108 is instructed to reset any registers that need to be reset and then told to go to sleep for a specified period of time, e.g., 10 minutes, to keep the band clear of unneeded bubble-up transmissions. A system such as this can utilize a limited number of commands to the endpoint 108 to keep the system simple. The commands can include:

Send X number of past intervals

Send block X on channel X

Reset registers, the endpoint may reply with an ACK

Send time of use (TOU) data

Sleep for X time

Additional commands may be added without departing from the spirit or scope of the invention. This system approach is possible because of the more than 16 MHz of bandwidth available in the ISM band. A alternative of the present system is to have the reader 109 tabulate all of the endpoints 108 that bubble in a 5 second interval. The endpoints 108 would leave their receivers on long enough to wait for the response. The reader 109 would then request data, from all of the endpoints 108 with which it communicated, on frequencies spread through the ISM band. This approach is desirable because when the reader is transmitting it cannot receive. Using a DSP based multichannel receiver multiple transmissions can be received simultaneously. Not only can interval packets be received but the multichannel receiver can continue to listen for new candidates bubbling up. It can also read and decode legacy ERTs during this time

By collecting 15 minute interval data for 35 days, a utility is allowed not only to do monthly reads but to obtain profiling data for distribution optimization as well. Move in, move out could be billed to the nearest 15 minute interval. The reading performance of this system is similar to, or better than, that of the mobile collector. It allows basic SCM type reads or higher functionality reads from the same installed base. If the reader does not want the additional data it does not request it.

L

Conclusion

In general, the detailed description of embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times.

Aspects of the invention may be stored or distributed on computer-readable media, including magnetically or optically readable computer discs, hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media. Indeed, computer implemented instructions, data structures, screen displays, and other data under aspects of the invention may be distributed over the Internet or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or they may be provided on any analog or digital network (packet switched, circuit switched, or other scheme). Those skilled in the relevant art will recognize that portions of the invention reside on a server computer, while corresponding portions reside on a client computer such as a mobile or portable device, and thus, while certain hardware platforms are described herein, aspects of the invention are equally applicable to nodes on a network.

The teachings of the invention provided herein can be applied to other systems, not necessarily the system described herein. The elements and acts of the various embodiments described herein can be combined to provide further embodiments. Any patents, applications and other references, including any that may be listed in accompanying filing papers, are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide yet further embodiments of the invention.

These and other changes can be made to the invention in light of the above Detailed Description. While the above description details certain embodiments of the invention and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. Details of the invention may vary considerably in its implementation details, while still being encompassed by the invention disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the invention encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the invention.

While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as a means-plus-function claim under 35 U. S. C sec. 112, sixth paragraph, other aspects may likewise be embodied as a means-plus-function claim, or in other forms, such as being embodied in a computer-readable medium. (Any claims intended to be treated under 35 U. S. C. §112, fl6 will begin with the words "means for".) Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.

Claims

CLAIMSI/We claim:

1. A utility meter endpoint for use in an encoder-receiver-transmitter (ERT)- compatible automatic meter reading (AMR) system, comprising: a utility meter interface that receives utility meter information from a utility meter; a radio that communicates with the AMR system; a processor operatively coupled with the utility meter interface and with the radio, wherein the processor converts the utility meter information into packets for transmission by the radio, wherein the packets include a first type of packet that has: a packet preamble portion that has a frame synchronization bit sequence, a packet type identifier field, and a packet length field, wherein the frame synchronization bit sequence is recognizable by an AMR system receiver that detects a preamble having a value of 0x16A3; a packet body portion that includes at least an endpoint serial number field and a message; and a packet validation portion; wherein the packet body portion has a length that is variable by the processor and the packet length field is set by the processor to represent the length.

2. The utility meter endpoint of claim 1 , wherein the frame synchronization bit sequence has a bit sequence consisting of 0x16A3.

3. The utility meter endpoint of claim 1 , wherein the packet preamble portion is preceded by a training sequence having a repeating bit pattern of 01.

4. The utility meter endpoint of claim 1 , wherein the message includes a message type identifier field and a message value field.

5. The utility meter endpoint of claim 4, wherein the message type identifier field consists of an outage notification code and the message value field includes an outage event counter value.

6. The utility meter endpoint of claim 5, wherein the outage notification code is a byte selected from the group consisting of: 0x50, 0x52, and 0x54.

7. The utility meter endpoint of claim 4, wherein the message type identifier field consists of a restoration code and the message value field includes an outage event counter value.

8. The utility meter endpoint of claim 7, wherein the outage event counter value includes a value representing an elapsed time.

9. The utility meter endpoint of claim 7, wherein the restoration code is a byte selected from the group consisting of: 0x51 , 0x53, and 0x55.

10. The utility meter endpoint of claim 1 , wherein the packet type identifier field consists of the bit pattern 0x1 D.

11. The utility meter endpoint of claim 1 , wherein the packet validation portion includes a packet cyclical redundancy check (CRC).

12. The utility meter endpoint of claim 1 , wherein the message includes a message cyclical redundancy check (CRC) field that validates contents of the message value field.

13. The utility meter endpoint of claim 1 , wherein the packet length field includes a value that represents a length of a remaining portion of the first type of packet that follows the packet length field.

14. The utility meter endpoint of claim 1 , wherein the message value field includes at least one originating device sub-field that represents an identification of a device that originated at least a portion of the message.

15. In an encoder-receiver-transmitter (ERT)-based automatic meter reading (AMR) system that utilizes interval daily messaging (IDM) wherein IDM packets have a frame synchronization sequence field of 0x16A3, followed by a packet type ID field, a method of configuring the AMR system to enable receiving a versatile message packet, the method comprising: configuring a reader to respond to a packet type ID that corresponds to a versatile message packet such that the reader processes a length field that follows the packet ID field to determine a remaining length of the versatile message packet.

16. The method of claim 15, wherein the step of configuring the reader includes: reading a message type identifier field that follows the length field; reading an encoder-receiver-transmitter (ERT) ID field that follows the message type

ID field; reading a serial number field that follows the ERT ID field; and reading a message value field having a length corresponding to the determined length of the versatile message packet.

17. The method of claim 15, wherein the step of configuring the reader includes: associating a first message type identifier with a first message priority level and a second message type identifier with a second priority level that is different from the first priority level; and responding to the packet type ID that corresponds to a versatile message packet such that the reader: reads a message type identifier field that follows the length field; and compares a value of the message type identifier field with at least one of the first message type identifier and the second message type identifier to determine a priority level at which to process the versatile message packet.

18. A method of data discrimination in a utility meter reading system having a plurality of utility meter endpoints, each endpoint wirelessly transmitting utility meter data to at least one reader to be relayed to a processing center, the method comprising: receiving, by a reader, data from an endpoint, wherein the data includes at least one type indicator; receiving, by the reader, type-discriminating information that is indicative of a type of data to be relayed to the processing center; identifying, by the reader, a first item of utility meter data to be relayed to the processing center based on the type-discriminating information; and relaying, by the reader, the first item of utility meter data to the processing center.

19. The method of claim 18, wherein the step of receiving the type-discriminating information includes receiving a type-discriminating mask, and wherein the step of identifying the first item of utility meter data includes applying the type-discriminating mask to the data from the endpoint.

20. The method of claim 18, further comprising the step of transmitting the type- discriminating information by the processing center.

21. The method of claim 18, wherein the step of identifying the first item of utility meter data includes comparing a message type indication from the type- discriminating information with a message type indication of the first item of utility meter data.

22. The method of claim 18, further comprising: transmitting, by a first endpoint of the utility meter reading system, utility meter data having multiple type-indicators; and managing, by the reader, the multiple type indicators, based on at least one management scheme selected from the group consisting of: receiving, from a remote source, a logical function indicative of how to apply the type-discriminating information to multiple type-indicators; and applying a predetermined default logical function that defines how the type- discriminating information is to be applied to multiple type-indicators in an absence of an overriding logical function.

23. An automatic meter reading (AMR) system reader that receives utility consumption information from a plurality of utility meter endpoints via an AMR communication channel, wherein the utility consumption information includes a plurality of data types, the reader being configured to relay certain data items from the utility consumption information to a processing center, the reader comprising: a radio circuit coupled to the communication channel; and a controller coupled to the radio circuit, wherein the controller is programmed to cause the reader to: receive type-discriminating information, wherein the type-discriminating information is indicative of a type of data to be relayed to the processing center; identify a first item of utility meter data to be relayed to the processing center based on the type-discriminating information; and relay the first item of utility meter data to the processing center.

24. The AMR system reader of claim 23, wherein the type-discriminating information includes a bit mask.

25. The AMR system reader of claim 23, wherein the controller is programmed to not relay certain items of utility meter data based on the type-discriminating information.

26. The AMR system reader of claim 23, wherein the controller is programmed to manage multiple type indicators in the utility consumption information based on at least one management scheme that is selected from the group consisting of: (a) being pre-configured in the controller, or (b) being received from a remote source, or both (a) and (b).

27. In an automatic meter reading (AMR) system that includes a reader and a plurality of endpoints adapted to conduct radio frequency (RF) communication with the reader, a method of establishing communication between one of the endpoints and the reader, the method comprising the steps of: operating the endpoint in a low-power mode for a majority of the time, wherein the endpoint does not communicate with the AMR system; operating the endpoint to momentarily exit the low-power mode and to transmit an initial message that includes an identification of the endpoint; following a the step of operating the endpoint to transmit the initial message, operating the endpoint to momentarily enter into a receive mode to await any further instruction from the reader.

28. The method of claim 27, wherein the step of operating the endpoint to momentarily enter into a receive mode is initiated following a predetermined time delay.

29. The method of claim 27, wherein the step of operating the endpoint to transmit the initial message includes transmitting an initial message that comprises a standard consumption message (SCM).

30. The method of claim 27, further comprising the step of: in an absence of any of said further instruction from the reader during the receive mode, operating the endpoint to return to the low-power mode; and in response to receiving a further instruction by the endpoint during the receive mode, wherein the further instruction instructs the endpoint to transmit a requested message, operating the endpoint to: transmit the requested message; and enter into the receive mode to await any further instruction from the reader.

31. The method of claim 27, wherein the step of operating the endpoint to transmit the initial message includes transmitting the initial message using on-off keying (OOK) modulation.

32. The method of claim 27, wherein the step of operating the endpoint to enter into the receive mode includes operating a frequency shift keying (FSK) receiver.

33. The method of claim 27, further comprising the steps of: operating the reader to receive the initial message; and in response to receiving the initial message, operating the reader to transmit an instruction to the endpoint while the endpoint is operating in the receive mode.

34. The method of claim 33, wherein the step of operating the reader to transmit the instruction includes commanding the endpoint to change an operating parameter or a configuration setting.

35. In an automatic meter reading (AMR) system that includes a reader and a plurality of endpoints adapted to conduct radio frequency (RF) communication with the reader, a method of conducting communication between one of the endpoints and the reader, the method comprising: operating the endpoint to enter into a receive mode and into a transmit mode based on a time schedule followed by the endpoint; transmitting an instruction to the endpoint by the reader such that transmission of the instruction is synchronized to the time schedule followed by the endpoint.

36. The method of claim 35, wherein the step of operating the endpoint includes initiating a communication session with the reader by transmitting an initial message.

37. The method of claim 35, further comprising the step of: initiating a communication session between the endpoint and the reader; and deciding, by the reader, whether or not to continue the communication session.

38. The method of claim 35, further comprising the step of: operating the endpoint in a low-power mode when the endpoint is not otherwise operating in the receive mode or in the transmit mode.

39. The method of claim 35, wherein the step of transmitting the instruction to the endpoint includes transmitting an instruction selected from the group consisting of: a sleep command, a command requesting a message from the endpoint, and a command to adjust an operating characteristic of the endpoint, or a command achieving any combination thereof.

40. The method of claim 35, further comprising: receiving the instruction by the endpoint; processing the instruction by the endpoint; and in response to the processing step, activating the receive mode of the endpoint for a predetermined duration of time.

41. In an automatic meter reading (AMR) system that includes a reader and a plurality of endpoints adapted to conduct radio frequency (RF) communication with the reader, a method of conducting communication between one of the endpoints and the reader, the method comprising: initiating a communication session by the endpoint, including transmitting an initial message as part of a bubble-up event; receiving the initial message by the reader; and initiating two-way communication by the reader in response to the initial message, wherein the two-way communication is part of the communication session initiated by the endpoint.

42. The method of claim 41 , further comprising the step of concluding the communication session by the reader, including foregoing instructing the endpoint to transmit a subsequent message.

43. The method of claim 41 , further comprising the step of concluding the communication session by the reader, including instructing the endpoint to operate in a sleep mode.

44. The method of claim 41 , further comprising the step of operating the reader to instruct the endpoint to transmit a requested message as part of the two-way communication.

45. The method of claim 41 , further comprising the step of operating the endpoint in a receive mode in response to occurrence of any of the following conditions: initiation of the communication session; initiation of the two-way communication; or receipt of an instruction from the reader, wherein the instruction does not instruct the endpoint to enter a low-power sleep state.

46. In an automatic meter reading (AMR) system that includes a reader and a plurality of endpoints, each of the plurality of endpoints adapted to conduct radio frequency (RF) communication with the reader, a method of conducting communications, the method comprising the steps of: initiating, by the plurality of endpoints, a communication session with the reader via an initial one-way communication; and selectively initiating, by the reader, two-way communication with individual ones of the plurality of endpoints in response to receipt of an initial one-way communication from each of those endpoints.

47. The method of claim 46, further comprising the step of automatically synchronizing communication activity of the reader in time with communication activity of each of the individual ones of the plurality of endpoints with which the reader selectively communicates in two-way mode.

48. The method of claim 47, further comprising the step of automatically synchronizing communication activity of the reader in channel hopping to match a channel hopping sequence of the communication activity of each of the individual ones of the plurality of endpoints with which the reader selectively communicates in two-way mode.

49. The method of claim 46, further comprising the step of operating each of the plurality of endpoints in a sleep mode for a majority of the time.

50. The method of claim 46, wherein for each endpoint, the step of initiating, the communication session with the reader includes transmitting a radio packet comprising essentially an identification of the endpoint.

51. The method of claim 46, wherein the step of initiating, the communication session with the reader includes transmitting a standard consumption message (SCM).

52. The method of claim 46, for each endpoint, further comprising the step of indicating a next subsequent channel on which that endpoint will be listening in the initial one-way communication of each endpoint.

53. The method of claim 46, further comprising the step of normally operating each endpoint in a receive mode during a time window that begins sometime after each message transmission receivable by the reader; and operating the reader to selectively transmit an instruction to each endpoint in response to receiving a message transmission from that endpoint, wherein the instruction is transmitted such that it can be received during a corresponding time window.

54. The method of claim 53, wherein the step of operating the reader to selectively transmit the instruction includes transmitting an instruction of a type selected from the group consisting of: a sleep command, a command requesting a message from the endpoint, and a command to adjust an operating characteristic of the endpoint, or a command achieving any combination thereof.

55. The method of claim 53, wherein the step of operating the reader to selectively transmit the instruction includes transmitting an instruction that includes a command requesting a set of consumption information from the endpoint; and operating the endpoint to respond to the command by transmitting a long message that includes the requested consumption information.

56. The method of claim 46, further comprising the step of maintaining a database by the reader, the database including of endpoint-specific information associated with each of the plurality of endpoints.

57. The method of claim 46, further comprising the step of simultaneously receiving two-way communications from endpoints transmitting on different channels.

58. The method of claim 57, further comprising reserving certain time slots in which the reader receives messages sent by endpoints during the two-way communication.

59. The method of claim 58, further comprising the step of instructing individual endpoints to schedule message transmissions such that messages from endpoints that are transmitted on adjacent channels are transmitted for reception by the reader at different reserved time slots.

60. An automatic meter reading system, comprising: at least one reader; and a plurality of utility meter endpoints, wherein each of said plurality of endpoints is configured to transmit an initial message via an AM transmission mode to initiate communication with said reader and to enters into a two-way, FM/AM receive/transmit mode upon completion of transmission of said initial message, wherein said reader is configured to receive said initial message from an endpoint and communicate additional information with said endpoint via said two-way communication mode.

61. The system of claim 60, wherein said initial message includes a standard consumption message (SCM).

62. The system of claim 60, wherein said reader configures a bubble-up rate for an endpoint via said two-way communication mode.

63. The system of claim 62, wherein said reader directs said endpoint to slow said bubble-up rate after said reader has obtained consumption information from said endpoint.

64. The system of claim 60, further comprising a repeater, wherein said repeater provides intermediate communication between said reader and said plurality of endpoints, and wherein said repeater communicates using both said AM communication mode and said two-way mode.

65. The system of claim 60, wherein said system is of a type selected from the group consisting of: a fixed network system, a mobile system, or a combination thereof.

66. A method for transmitting data in a utility meter reading system having at least a reader and an endpoint, the method comprising: transmitting a standard consumption message (SCM) via an AM transmission mode by said endpoint; switching said endpoint into a two-way, FM receive/transmit mode following the step of transmitting said SCM; receiving said SCM with said reader; in response to receiving said SCM, selectively requesting additional information from said endpoint by said reader via said two-way FM receive/transmit mode between said reader and said endpoint.

67. The method of claim 66, further comprising the step of directing a bubble-up rate for said step of transmitting said SCM by said endpoint by using said reader via said two-way FM receive/transmit mode.

68. The method of claim 67, wherein said step of directing comprises directing said bubble rate to slow after said reader has read said SCM from said endpoint.

69. The method of claim 66, further comprising providing intermediary communication between said endpoint and said reader via a repeater, wherein said repeater communicates in both said AM transmission mode and said two-way FM receive/transmit mode.

70. A mobile daily interval meter reading system, comprising: an endpoint, wherein said endpoint is capable of transmitting in either oneway or two-way RF communication mode, wherein said endpoint saves a plurality of intervals of utility meter data, and wherein said endpoint normally operates in a bubble-up mode using said one-way RF communication mode; a reader, wherein said reader listens for said endpoint in said bubble-up mode, and upon detecting said endpoint in said bubble-up mode said reader utilizes said two-way RF communication mode to transmit a command to said endpoint to send a specified number of intervals in response.

71. The system of claim 70, wherein said reader is configured to selectively transmit additional commands to said endpoint, wherein said additional commands are selected from: a command to reset registers, a command to send time of use data, and a command to instruct said endpoint to sleep for a predetermined amount of time.

72. An automatic meter reading (AMR) system, comprising: a reader; and a plurality of endpoints, wherein each of the plurality of endpoints is adapted to conduct radio frequency (RF) communication with the reader; wherein each of the plurality of endpoints initiates a communication session with the reader as part of a bubble-up operating mode by transmitting a one-way communication; and wherein each of the plurality of endpoints is configurable to schedule a time window during which that endpoint operates at a special bubble-up rate that is different from a default bubble-up rate of the endpoint.

73. In an automatic meter reading (AMR) system comprising a reader and a plurality of endpoints, each of the endpoints adapted to conduct radio frequency (RF) communication with the reader on a bubble-up basis, a method of migrating from a primarily mobile network to a fixed network AMR system, the method comprising: initiating two-way communication between the reader a first endpoint; and during the two-way communication, instructing the first endpoint to slow a default bubble-up rate.

74. The method of claim 73, further comprising the step of: during the two-way communication, instructing the first endpoint to increase transmission power level.

75. The method of claim 73, further comprising the step of: during the two-way communication, instructing the first endpoint to respond to a specified reading time by temporarily increasing a bubble-up rate.

76. In an automatic meter reading (AMR) system comprising a reader and a plurality of endpoints, each of the endpoints adapted to conduct radio frequency (RF) communication with the reader on a bubble-up basis, a method of improving communication reliability, the method comprising: receiving, by the reader, a first message transmitted by a first endpoint at a first frequency; determining, by the reader, whether the first frequency is suitably centered within a predefined communication channel associated with the first message; initiating two-way communication between the reader the first endpoint; during the two-way communication, sending an instruction to the endpoint from the reader, wherein the instruction specifies a frequency correction for the endpoint to implement.

77. In an automatic meter reading (AMR) system comprising at least one reader and a plurality of endpoints, each of the endpoints adapted to conduct radio frequency (RF) communication with one of the at least one reader on a bubble-up basis in a one-way mode, and in a selectively-initiated two-way mode, a method of assessing or predicting communication reliability, the method comprising: receiving a message transmitted between a first reader and a first endpoint; measuring a received signal strength indication (RSSI) of the message; and making a decision affecting future communication between the first reader and the first endpoint based on the measured RSSI.

78. The method of claim 77, wherein the step of receiving the message includes either receiving the message from the first endpoint by the first reader, or receiving the message from the first reader by the first endpoint.

79. The method of claim 77, wherein the step of receiving the message includes receiving the message in the one-way mode or in the two-way mode.

80. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes foregoing initiating or continuing two-way communications.

81. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes adjusting an instruction specifying a request for certain data to be transmitted in the two-way mode.

82. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes transmitting a command in two-way mode to change channels.

83. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes changing a mobile collection route or schedule.

84. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes assigning the first endpoint to a second, different, reader.

85. The method of claim 77, wherein the step of making the decision affecting future communication between the first reader and the first endpoint includes instructing the first endpoint to increase transmission power level.

86. The method of claim 77, further comprising the steps of: logging RSSI values associated with certain communications; and analyzing the logged RSSI values to identify a potential trend or characteristic of a communication arrangement between the first reader and the first endpoint.

87. In an automatic meter reading (AMR) system comprising at least one reader and a plurality of endpoints, each of the endpoints adapted to conduct radio frequency (RF) communication with one of the at least one reader on a bubble-up basis in a one-way mode, and in a selectively-initiated two-way mode, a method of assessing or predicting communication reliability, the method comprising: measuring channel clarity; and making a decision affecting future communication between a first reader and a first endpoint based on the measured channel clarity.

88. An automatic meter reading (AMR) system, comprising: a reader; a repeater; and a plurality of endpoints; wherein each of the plurality of endpoints is capable of conducting radio frequency (RF) communication with the reader and with the repeater; wherein the repeater is adapted to conduct RF communication with the selected ones of the plurality of endpoints and with the reader; wherein each of the plurality of endpoints initiates a communication session with the reader or the repeater via an initial one-way communication; wherein the reader and the repeater selectively initiate two-way communication with individual ones of the plurality of endpoints in response to receipt of an initial one-way communication from each of those endpoints; wherein the repeater initiates a communication session with the reader via an initial one-way repeater message; and wherein the reader selectively initiates two-way communication with the repeater in response to receipt of the repeater message.

89. The AMR system of claim 88, wherein the repeater is battery-powered.

90. The AMR system of claim 88, wherein the reader and the repeater each automatically synchronizes communication activity in time with communication activity of each of the individual ones of the plurality of endpoints with which the reader or repeater selectively communicates in two-way mode.

91. The AMR system of claim 90, wherein the reader and the repeater each automatically synchronizes communication activity in channel hopping to match a channel hopping sequence of the communication activity of each of the individual ones of the plurality of endpoints with which the reader or repeater selectively communicates in two-way mode.

92. The AMR system of claim 88, wherein the reader operates in a sleep mode for a majority of the time.

93. The AMR system of claim 88, wherein the initial one-way communication of each endpoint and of the repeater includes a radio packet comprising essentially an identification of that endpoint or repeater.

94. The AMR system of claim 88, wherein the initial one-way communication of each endpoint or reader includes an indication of a next subsequent channel on which that endpoint or repeater will be listening.

95. The AMR system of claim 88, wherein each endpoint is configured to normally operate in a receive mode during a time window that begins sometime after each message transmission receivable by the reader or the repeater; and wherein the repeater is configured to selectively transmit an instruction to each endpoint in response to receiving a message transmission from that endpoint, wherein the instruction is transmitted such that it can be received during a corresponding time window.

96. The AMR system of claim 95, wherein the reader responds to the repeater's initial one-way repeater message by transmitting an instruction receivable by the repeater, wherein the instruction requests that the repeater transmit a list of endpoints within communication range.

97. The AMR system of claim 95, wherein the reader responds to the repeater's initial one-way repeater message by transmitting an instruction receivable by the repeater, wherein the instruction specifies the endpoints with which the repeater should engage in two-way communication.

98. The AMR system of claim 95, wherein the reader responds to the repeater's initial one-way repeater message by transmitting an instruction receivable by the repeater, wherein the instruction requests endpoint consumption data stored in the repeater; and wherein the repeater responds to the command by transmitting a long two- way repeater message that includes the requested endpoint consumption information.

99. The AMR system of claim 88, wherein the reader is adapted to simultaneously receive two-way communications from endpoints and from the repeater transmitting on different channels.

100. In an automatic meter reading (AMR) system, a method of gathering consumption information by an endpoint for facilitating collection of different sets of interval data, the method comprising the steps of: obtaining consumption data at a first time granularity; and storing each obtained item of consumption data in a data structure having multiple tiers of time granularity.

101. The method of claim 100, wherein the step of storing each obtained item of consumption data includes storing the data in a multidimensional table or array, wherein each dimension corresponds to a different time granularity.

102. The method of claim 101 , wherein the step of storing each obtained item in a multidimensional table or array, includes storing consumption values in a days x hours matrix.

103. The method of claim 100, further comprising the step of transmitting an interval data request to the endpoint by a reader in the AMR system, wherein the request specifies coordinates of the data structure under which the desired consumption data is stored.

104. The method of claim 100, wherein the step of storing each obtained item of consumption data includes storing either absolute consumption values, or delta values.

105. A method of operating an endpoint transmitter power supply to facilitate transmitting longer messages, the method comprising the steps of: when the endpoint transmitter is not transmitting, switchably coupling a set of capacitors in parallel and charge the set of capacitors from the endpoint power supply; when the endpoint transmitter needs to transmit a message, switchably couple the set of capacitors in series to boost an output voltage; and utilizing the output voltage to at least partially power the endpoint transmitter.

106. A power conditioning circuit portion of an endpoint, comprising: a battery; a voltage regulator; a set of capacitors; and a switching network; wherein the switching network can arrange the set of capacitors a parallel fashion to charge from an endpoint power source; and wherein the switching network can selectively arrange the set of capacitors in a series fashion to boost a supply voltage to the voltage regulator.