Source: http://www.google.com/patents/US8164479?ie=ISO-8859-1&dq=5,266,072
Timestamp: 2014-03-14 23:54:12
Document Index: 501745320

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 2004', 'Application No. 2004']

Patent US8164479 - Data communication protocol in an automatic meter reading system - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsAutomatic meter reading (AMR) systems and methods in which readers communicate with endpoints interfaced to utility meters. In operation, the reader and the endpoint communicate with one another via radio frequency (RF) communication according to a communication protocol. Aspects of the invention are...http://www.google.com/patents/US8164479?utm_source=gb-gplus-sharePatent US8164479 - Data communication protocol in an automatic meter reading systemAdvanced Patent SearchPublication numberUS8164479 B2Publication typeGrantApplication numberUS 11/981,775Publication dateApr 24, 2012Filing dateOct 31, 2007Priority dateSep 5, 2003Also published asCA2479977A1, CA2479977C, EP1512946A2, EP1512946A3, US7336200, US7479895, US20050068193, US20060202856, US20080129537, US20120176253Publication number11981775, 981775, US 8164479 B2, US 8164479B2, US-B2-8164479, US8164479 B2, US8164479B2InventorsChristopher L. Osterloh, Christopher NagyOriginal AssigneeItron, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (10), Non-Patent Citations (7), Classifications (21), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetData communication protocol in an automatic meter reading systemUS 8164479 B2Abstract Automatic meter reading (AMR) systems and methods in which readers communicate with endpoints interfaced to utility meters. In operation, the reader and the endpoint communicate with one another via radio frequency (RF) communication according to a communication protocol. Aspects of the invention are directed to packetization, command and control, and messaging arrangements.
an endpoint interfaced to a utility meter;
wherein in operation, said reader transmits a command and control frame to said endpoint via radio frequency (RF) communication, wherein the command and control frame includes:
a system ID that indicates a specific AMR system with which said endpoint is associated;
a frame ID that indicates a position in a wake-up sequence of said reader; and
a cell ID that indicates at least one subset of said specific AMR system.
2. The AMR system of claim 1, wherein said command and control frame issues commands to said endpoint.
3. The AMR system of claim 1, wherein said command and control frame realigns a real-time clock within said endpoint.
4. The AMR system of claim 1, wherein said command and control frame includes a command set field.
5. The AMR system of claim 4, wherein said command set includes universal commands and type specific commands.
6. The AMR system of claim 1, wherein said command and control frame includes a command body, wherein said command body provides at least one command selected from the group consisting of:
reporting a status of said endpoint;
changing a system number of said endpoint;
changing a group number of said endpoint;
changing a system slot number of said endpoint;
changing a cell ID of said endpoint;
providing a reporting slot number to said endpoint;
requesting resending of identified packets of data from said endpoint;
setting a bubble-up channel of said endpoint;
configuration a transmission power of said endpoint; and
setting a channel frequency of said endpoint.
7. The AMR system of claim 1, wherein said command and control frame includes a command body, wherein said command body provides at least one command selected from the group consisting of:
requesting a report of consumption data from said endpoint;
requesting a report of time of use data from said endpoint;
requesting a report of logged data from said endpoint;
requesting a report of tamper data from said endpoint;
setting a configuration flag within said endpoint;
initializing consumption within said endpoint;
request a report of an event summary from said endpoint;
performing an endpoint diagnostic check; and
requesting a report of memory content of said endpoint.
8. The AMR system of claim 1, wherein said command and control frame includes a plurality of fields, and wherein said plurality of fields are selected from: a frame ID field, a cell ID, a real-time clock field, a command flag field, a slot offset field, an unsolicited message field, an endpoint ID field, a security field, a command set field, a command body field, or a response frequency field.
9. The AMR system of claim 1, wherein said command and control frame designates a response frequency for said endpoint.
10. The AMR system of claim 1, wherein said command and control frame comprises a one-way programming frame or a two-way command and control frame.
11. The AMR system of claim 1, wherein said command and control frame provides a test command to said endpoint.
12. The system of claim 1, wherein said command and control frame issues a command selected from a command set having a plurality of different commands, and wherein the system is adapted to support a plurality of different command sets.
13. The system of claim 12, wherein a command set is divided into a plurality of groups including a universal group applicable to all endpoint types, and a type specific group applicable corresponding types of endpoint devices.
14. The system of claim 1, wherein the command and control frame includes:
a system identification field;
a frame identification field;
a cell identification field;
a plurality of coordinated universal time (UTC) fields;
a plurality of command flags fields;
a slot offset field that defines the number of slots between packets in multi-packet messages;
at least one field that defines a first unsolicited message;
a plurality of fields that provide at least one endpoint ID of at least one endpoint with which that the reader is to communicate;
at least one security field;
a command set field;
a plurality of command and command body fields;
at least one field that provide a response frequency for at least one endpoint;
a field that indicates a length of extended control frame; and
at least one cyclical redundancy check field.
15. The system of claim 14, wherein at least one of the plurality of the command flag fields includes:
a first three bits that define a slot length;
a fourth bit that is a forward error correction bit;
a fifth bit that provides a slot mode;
a sixth bit that defines a data type; and
a seventh bit and an eighth bit that are a command target bits.
16. The system of claim 14, wherein at least one of the plurality of command flag fields comprises:
a first four bits;
a fifth bit and a sixth bit that define an encoder number; and
a seventh bit and an eighth bit that define a transmit mode.
17. The system of claim 14, wherein the plurality of command and command body fields provide at least one indication selected from the group consisting of: reporting a status, changing a system number to a new system number, changing a group number to a new group number, changing a system slot number to a new system slot number, changing a cell identification to a new cell identification, reporting slot numbers, resending identified packets of data, setting a receiver bubble-up period, setting a bubble-up channel, setting a bubble-up time, configuring a transmission power, setting a channel frequency, reporting consumption data, reporting time of use data, reporting logged data, reporting temperature, reporting tamper data, setting configuration flags, initializing consumption, reporting an event summary, performing an endpoint diagnostic check, reporting memory contents, or any combination thereof.
18. The system of claim 1, wherein the system ID, the frame ID, and the cell ID are utilized to determine cell reuse. Description
CLAIM TO PRIORITY The present Application is a Divisional of U.S. patent application Ser. No. 10/915,706, filed Aug. 10, 2004, now U.S. Pat. No. 7,336,200 and entitled �DATA COMMUNICATION PROTOCOL IN AN AUTOMATIC METER READING SYSTEM,� which claims priority to U.S. Provisional Patent Application No. 60/500,550, filed on Sep. 5, 2003, and entitled, �DATA COMMUNICATION PROTOCOL IN AN AUTOMATIC METER READING SYSTEM,� each of which is incorporated by reference herein in its entirety.
RELATED APPLICATIONS This application is related to commonly assigned U.S. Provisional Application No. 60/500,507, filed on Sep. 5, 2003, entitled, �SYSTEM AND METHOD FOR DETECTION OF SPECIFIC ON-AIR DATA RATE,� U.S. Provisional Application No. 60/500,515, filed Sep. 5, 2003, entitled, �SYSTEM AND METHOD FOR MOBILE DEMAND RESET,� U.S. Provisional Application No. 60/500,504, filed Sep. 5, 2003, entitled, �SYSTEM AND METHOD FOR OPTIMIZING CONTIGUOUS CHANNEL OPERATION WITH CELLULAR REUSE,� U.S. Provisional Application No. 60/500,479, filed Sep. 5, 2003, entitled, �SYNCHRONOUS DATA RECOVERY SYSTEM,� U.S. Provisional Application No. 60/500,550, filed Sep. 5, 2003, entitled, �DATA COMMUNICATION PROTOCOL IN AN AUTOMATIC METER READING SYSTEM,� U.S. patent application Ser. No. 10/655,760, filed on Sep. 5, 2003, entitled, �SYNCHRONIZING AND CONTROLLING SOFTWARE DOWNLOADS, SUCH AS FOR COMPONENTS OF A UTILITY METER-READING SYSTEM,� and U.S. patent application Ser. No. 10/655,759, filed on Sep. 5, 2003, entitled, �FIELD DATA COLLECTION AND PROCESSING SYSTEM, SUCH AS FOR ELECTRIC, GAS, AND WATER UTILITY DATA,� each of which is incorporated by reference herein in its entirety.
FIELD OF THE INVENTION The present invention relates to automatic meter reading systems and, more particularly, to the communication protocol used for communications between endpoints and readers of the automatic meter reading system.
BACKGROUND OF THE INVENTION Current automatic meter reading (AMR) systems are significantly limited in the information that can be obtained from the meter. Generally the AMR system comprises a reader and an endpoint that is interfaced to a meter. In a typical system, the endpoint obtains the consumption reading from the meter and then bubbles up every few seconds to send that consumption reading, via RF signal, to the reader. Alternatively, the endpoint receives a wake-up tone from the reader that prompts the endpoint to send the consumption reading to the reader.
As such, there is a need for an AMR system that enables the user of the system to have more access to and more control over the information that the meter and endpoint can provide.
SUMMARY OF THE INVENTION One aspect of the invention is directed to an automatic meter reading (AMR) system that includes a reader and an endpoint interfaced to a utility meter. In operation, the reader and the endpoint communicate with one another via radio frequency (RF) communication according to a communication protocol. The communication protocol includes a transport layer that provides slot assignments, timing, and packetization for all data transferred between the reader and the endpoint. The packetization defines packets to include the following fields: a preamble field; a preface following the preamble field that includes at least a message type field; an endpoint type field following the message type field; a message field following the endpoint type field; and a validation field.
In an AMR system comprising a reader and an endpoint interfaced to a utility meter according to another aspect of the invention, in operation, the reader transmits a command and control frame to the endpoint via radio frequency (RF) communication. The command and control frame includes a system ID that indicates a specific AMR system with which the endpoint is associated; a frame ID that indicates a position in a wake-up sequence of the reader; and a cell ID that indicates at least one subset of the specific AMR system.
In a further aspect of the invention, a RF communication sent by an AMR system reader to an endpoint occurs through the use of at least one packet that includes a message type field and a message field. The message type field indicates a command type of a first command to be carried out that is selected from a predetermined set of commands. The message field indicates specific data associated with the first command.
According to another aspect of the invention, in an AMR system comprising a reader and an endpoint interfaced to a utility meter, the endpoint and reader communicate with one another via a RF communication. The RF communication occurs through the use of at least one packet that includes a message type field and a message content field that is distinct from the message type field. The message type field indicates a message type indicator of a first message to be conveyed that is selected from a predetermined set of messages, and wherein the message content field indicates specific data associated with the first message.
Another aspect of the invention is directed to a method of communicating between the endpoint and the reader. At least one of the reader and the endpoint transmits a packetized RF communication that includes a first packet. In the first packet, a message type field and a message content field that is distinct from the message type field are provided. In the message type field, a message type is indicated for a first message to be conveyed that is selected from a predetermined set of messages. In the message content field, specific data associated with the first message is indicated.
BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 depicts a radio-based automatic meter reading system that utilizes the data communication protocol of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention is a data communication protocol for automatic meter reading (AMR) systems. The protocol is designed to be flexible and expandable enabling both one-way and two-way meter reading in both fixed and mobile meter reading systems.
In an AMR system 100, as depicted in FIG. 1, that is utilized with the present invention, the components generally include a plurality of telemetry 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. The system further includes a plurality of endpoints 108, wherein each corresponds and interfaces to a meter. Each of the endpoints 108 preferably incorporates a radio receiver/transmitter, e.g., the Itron, Inc. ERT. The system additionally includes one or more readers 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 head-end, host processor 118. The host processor incorporates software that manages the collection of metering data and facilitates the transfer of that data to a utility or supplier billing system 120.
The AMR system 100 and the data protocol is usable in both one-way meter reading and in two-way meter reading. The one-way meter reading system enables the reader to listen to messages sent asynchronously from the endpoint while the two-way meter reading system enables the reader to communicate with and command the endpoint while also enabling the endpoint to respond to the reader.
II.A. System Protocol�Physical Layer
II.B. System Protocol�Data Link Layer
TABLE 1 PN Sequences Sequence Inverted Number Usage Sequence = 0 Sequence = 1 0 Factory Default 0000000010 1111111101 1 Electric Devices 0000000110 1111111001 2 Electric Devices 0000001010 1111110101 3 Electric Devices 0000001110 1111110001 4 Electric Devices 0000011010 1111100101 5 Electric Devices 0000010110 1111101001 6 Electric Devices 0000111010 1111000101 7 Battery Devices 0000101110 1111010001 8 Battery Devices 0001110110 1110001001 9 Battery Devices 0001101110 1110010001 10 Battery Devices 0000011110 1111100001 11 Battery Devices 0001011110 1110100001 12 Battery Devices 0001111010 1110000101 All inbound packet transmissions are preceded by a 24-bit or 25 bit preamble and appended with a 16-bit CRC code, which is inclusive of all header information, but not the preamble, length, or length_bar bytes. The CRC polynomial is 0x1021. The CRC initialization value is 0x0000. CRC processing is performed most significant byte (MSB) first, and the final checksum is not inverted.
II.C. System Protocol�Network Layer
II.D. System Protocol�Transport Layer
The transport layer is used to solve problems like reliability (�did the data reach the destination?�) and ensure that data arrives in the correct order. This layer manages the end-to-end control (for example, determining whether all packets have arrived) and error-checking. It ensures complete data transfer. In the present data communication protocol, slotting control is handled in the transport layer. This includes slot assignments, timing, and any necessary packetization. FIG. 7 details the packet structure. The message, message type, and flags are received from the presentation layer, and broken into appropriately sized packets. Each packet is prefaced with the endpoint ID, flags, message type, endpoint type, and packet length. The packet length reflects the number of bytes in the message itself, exclusive of header information. In the case where more than 254 bytes are required in a packet, the value of the length field is set to 0xFF, and the actual length of the message structure is placed in bytes 14 (high byte) and 15 (low byte), with the message bytes to follow. All packets must have a whole number of bytes in the message.
Some endpoints in the system have the option of sending out an infrequent (several times a day) fixed format message at a higher power level, for use in 1-way fixed network applications. The message has its own structure, as defined in FIG. 8. The custom packet is then BCH (255, 139, 15) encoded, prior to transmission. The encoding polynomial is 0x4614071320601755615707227302474535674458. For multi-encoder endpoints this packet is generated and sent for each individual encoder. The flags for the high power pulse data packet structure are configured as shown in Table 4 below. The first four bits are reserved while the fifth and sixth bits provide the encoder number, wherein 00=encoder 0, 01=encoder 1, 10=encoder 2, and 11=encoder 3. The seventh bit comprises the relay bit, wherein 0=message from originating endpoint and 1=message via relay. The eighth bit comprises the error code indicating that a critical endpoint error has occurred.
TABLE 4 Flags R R R R ENC ENC RLY ERR MSB LSB The endpoints may also be set to send out any preprogrammed message type in place of the fixed format message described above.
II.E. System Protocol�Session Layer
II.E.i. System Protocol�Session Layer/Two-Way Command and Control
The command and control frame is used to issue command to two-way endpoints either individually or in groups. It also serves to realign the endpoint real-time clock. FIG. 9A diagrams the two-way communication command and control frame. As shown, the command and control frame transmission is preceded by a 24-bit preamble, as indicated by the three �P� fields within the frame. The first 16 bits are preferably an alternating pattern, AAAAh, and are used for clock recovery. The last 8 bits are used for frame and timing synchronization.
Field �0� of the command and control frame comprises the system identification (ID). Each system is issued an 8-bit ID value, which is stored in the endpoint, to distinguish different systems within geographic proximity. The endpoints are designed to respond to commands from their own system or to commands that address them specifically by ID number, proper security password, and have a 0x00 in field �0�. The system ID functions nearly identically to the cell ID, described below. However, the system ID is universal, while the cell ID is local, i.e., a single system will have multiple cells each having the same system ID but a different cell ID.
Field �1� of the command control frame comprises the frame ID. Each reader within the system is assigned a frame ID to use based on its position in the wake-up sequence. The position in the wakeup sequence is directly related to the frequency reuse pattern that is used in a given system. Table 1, described earlier, correlates the frame ID to the channel, which is correlated to the cell reuse ratio.
Field �2� of the command and control frame comprises the cell ID. Each cell is issued an 8-bit ID value, which is stored in the endpoint, to distinguish different systems within geographic proximity.
Fields �3� through �6� of the command and control frame is the RTC, which is defined as UTC time (coordinated universal time), which is a 32-bit value representing the number of seconds since midnight (00:00:00) on Jan. 1, 1970 GMT.
Field �7� is the command flags 1 field, wherein the first three bits define a slot length according to Table 5.
TABLE 5 Slot Lengths Value of Length Bits Nominal Length in Ticks* Nominal Length in ms 000 819 24.99390 001 1638 49.98779 010 3277 100.00610 011 6553 199.98169 100 9830 299.98780 101 16384 500.00000 110 32768 1000.00000 111 163840 5000.00000 *Defined as ticks of an ideal 32,768 Hz clock. The fourth bit is the forward error correction bit, wherein 0=no forward correction error and 1=forward error correct all responses. The fifth bit provides the slot mode, wherein 0=respond to command in pseudo-random slot (Slotted Aloha) and 1=respond to command in the defined slot. The sixth bit of field �7� defines the data type, wherein 0=NRZ response from endpoint and 1=Manchester encoded from the endpoint. The seventh and eighth bits of field �7� comprise the command target, wherein 00=the entire cell, 01=the group defined in EPID_HI (field �12�), 10=the group defined in EPID_LO (field �15�), and 11=the endpoint defined by EPID (including HI/LO), fields �12� through �15�. It should be noted that in single endpoint communications the command target (TGT) is set to 11 and the endpoint responds immediately after command processing with a minimum of 25 milliseconds between this frame and the endpoint response.
Field �8� of the command and control frame is the command flags 2 field, wherein the first four bits are reserved. The fifth and sixth bits defined the encoder number, wherein 00=Encoder 0, 01=Encoder 1, 10=Encoder 2, and 11=Encoder 3. The final seventh and eighth bits define the transmit mode, wherein 00=transmit mode 1, e.g., mobile response required, 01=transmit mode 2, e.g., fixed network response required, and 10/11 are reserved. Also see section V below.
Field �9� of the command and control frame comprises the slot offset. Slot offset defines the number of slots between packets in multi-packet messages. For example, if the endpoint has an initial slot number of 50, and the slot offset is 120, a three-packet message would be transmitted in slots 50, 170, and 290.
Fields �10� and �11� of the command and control frame define the first unsolicited message. Specifically, they define the slot number where the unsolicited messages (UMs) are to begin. Any UMs generated during the cell read would be reported in a pseudo-randomly selected slot after the slot defined here. If the value of this field is 0x0000, no UMs are sent from the endpoint.
Fields �12� through �15� of the command and control frame provide the endpoint IDs for those endpoints that the reader is desiring to communicate with.
Fields �16� and �17� are the security fields and are described further in relation to the presentation layer.
Field �18�, defines the command set. The commands are divided into two groups: (1) universal and (2) type-specific. Universal commands are numbered 0-63 and are applicable to all the system endpoints. Type specific commands are numbered 64-255 and vary depending on the lower nibble of the command set field in accordance with Table 6 below.
Utility Metering Endpoints
0011-1110
15 1111
<<Reserved Engineering Use Only>>
Fields �19� through �21� of the command and control frame define the command and command body. Specifically, the eight command bits of field �19� indicate the command type, wherein the numbers 0-63 are universal commands and 64-255 are the type specific commands. Fields �20� and �21� provide sixteen bits wherein any data needed to carry out the command type is provided. The tables in FIGS. 10 and 11 indicate the command types and command bodies that are possible with the system of the present invention. Referring to the universal commands (FIG. 10), it can be seen that the present system is capable of but not limited to: (1) reporting a status; (2) changing a system number to a new system number; (3) changing a group number to a new group number; (4) changing a system slot number to a new system slot number; (5) changing the cell ID to a new cell ID; (6) reporting slot numbers; (7) resending identified packets of data; (8) setting the receiver bubble-up period; (9) setting the bubble-up channel; (10) setting the bubble-up time; (11) configuring the transmission power; (12) setting the channel frequency; etc.
Fields �22� and �23� of the command and control frame designate the response frequency for the endpoint. The response frequency is configured as 16 bit flags, identifying valid response frequencies for the endpoint. For example, if the response frequency has a value of 0x00C1 (bits, 7, 6, and 0 are set), the endpoint may respond on channel, 7, channel 6, or channel 0.
Field �24� is reserved for later use.
Field �25� indicates the length of the extended control frame in bytes. A value of 0 indicates that no extended frame is present.
Fields �26� and �27� of the command and control frame provides the cyclic redundancy check (CRC). Specifically, fields �26� and �27� provide a 16-bit CRC. The CRC is preferably a polynomial defined as 0x1021. The CRC initialization value is 0x0000. CRC processing is performed most significant bit (MSB) first, and the final checksum is not inverted.
II.E.ii. System Protocol�Session Layer/One-Way Command and Control
TABLE 7 Command Flags TXM TXM DLG FEC MDE MDE R R MSB LSB II.E.iii. System Protocol�Session Layer/Special Commands�Channel Frequency
TABLE 8 Command Body/Channel Frequency CHN CHN CHN CHN FRQ FRQ FRQ FRQ FRQ FRQ FRQ FRQ FRQ FRQ FRQ FRQ MSB LSB Individual frequencies are programmed into the endpoint by selecting the channel being programmed (1-15) with the top nibble, and the frequency number in the lower 12 bits. Endpoint channel 0 is preferably the manufacturing default frequency, and may not be edited. Endpoint channel 15 is the receiver frequency. It is initialized to the same frequency as channel 0 at manufacture, and is preferably programmed prior to or at installation. The endpoint channel uses are defined in Table 9 below:
Endpoint Channel
Factory Default. This channel is not reprogrammable.
General use Tx/Rx (Transmission/Reception)
General use Tx/Rx
Default UM Channel (unsolicited message)
Default Rx Channel
TABLE 11 Flags R R R TxB UMC FN FEC MMI The flag mask field determines which flags are to be modified by this command. A �1� in any bit position means the associated value in the flags field should be modified. For example, A value of 0x17 (bits 4, 2, 1 and 0 are high) means that the values in the Flags field, bits 4, 2, 1, and 0 must be written to the associated flags in the endpoint. With regard to the flags field of Table 7, the first three bits are reserved for future growth while the fourth bit, TxB, determines if the endpoint is in transmit bubble up mode, the fifth bit, UMC, defines the unsolicited message channel, i.e., UMC=0 then transmit UMs on Channel 14, and UMC=1 then transmit UMs on channel 15. The sixth bit of the flags field defines the fixed network mode, wherein 0=this endpoint operates in Mobile/Handheld mode only and 1=this endpoint operates in mobile/handheld/fixed network mode. The seventh bit of the flags field defines the forward error correction, wherein 0=no forward error correction applied to the high power pulse and 1=forward error correction is applied to the high power pulse. The eighth bit of the flags field defines the multiple message integration, wherein 0=no multiple message integration applied to high power pulse and I=multiple message integration applied to high power pulse.
II.E.iv. System Protocol�Session Layer/Special Commands�Test Commands
II.E.v. System Protocol�Session Layer/Special Commands�Extension Commands
Commands 48, 49, 50 and 51 of the data communication protocol are implemented as extensions to the command and control frame. The extension commands immediately follow the command and control frame in the same transmit session. Command 48 is the multiple ungrouped endpoint command. In the case where the system needs to command a group of specific endpoints and vector them to specific slots, command 48 is issued. The central radio then issues commands to these endpoints, as shown in FIG. 12. This command can be used to address a maximum of 16 distinct endpoints. The packet length reflects the number of endpoints addressed by the message. Note that the command 48 may not be used for any command that requires the security password. The structure of command 48 provides for an 8-byte preamble having the value of 0xAAAA AAAA AAAA AA96, the length, the endpoint IDs, and the command bodies for each of the endpoints and a response byte for each of the endpoints. The response byte is diagrammed in Table 12 below:
TABLE 12 Response Byte R R R R CHN CHN CHN CHN MSB LSB The response byte reserves the first four bits and utilizes the last four bits to define the response frequency nibble. Specifically, the four bit flags define which of the pre-programmed channels the endpoint may respond on. If CHN=0000, then use the response frequency byte from the original command and control frame. The structure of the command 48 also includes the CRC as described earlier.
Command 49, i.e., the vector and listen frame, is issued in the instance where the central radio or reader need to download an arbitrary block of data to the endpoint. The endpoint, upon receiving this command receives a data frame, as defined in FIG. 13. This command is valid only when the endpoints are individually addressed (i.e., TGT=11). The data is endpoint-type specific. Note that the vector and listen frame has an 8-byte preamble with a value of 0xAAAA AAAA AAAA AA96. Further, note that the packet length reflects the number of bytes in the message itself, exclusive of header information, and that the CRCs computed over all bytes in the message body.
II.F. System Protocol�Presentation Layer
II.G. System Protocol�Application Layer
To alleviate cell-to-cell interference in a system with a single control channel the readers must be synchronized in time so that the control frames, which are described in further detail below, do not overlap. The addition of �dead time� in between sequential control frames allow for the receivers to be quasi-synchronized instead of in perfect lock step. In the preferred embodiment, quasi-synchronized means that the receivers are within 0.5 seconds of each other, which can easily by achieved via protocols such as NTP (network time protocol). Other quasi-synchronization times may be used without departing from the spirit or scope of the invention. As such, a GPS or other high accuracy time base is not required within the readers.
Cell Reuse Ratio
Channel to Frame ID mapping
Channel 1 = Frame ID 0
When operating in the mobile or hand-held mode, the 2.5 seconds of �dead time� does not apply. Rather slot �0� occurs at the end of the command and control frame plus 25 milliseconds. Note, that due to time required to read the attached meter and/or bring the charge pump to full operation the endpoint may or may not respond in slot �0� even if told to respond immediately.
In order to optimize the batter efficiency, range, and overall system robustness for endpoints that must operate in both a mobile and fixed network scenario without reprogramming, the following methodology is preferably used. The outbound transmission from the reader includes a flag that states the response mode of the endpoint. When the response mode flag is set to �mobile� the endpoint responds at a lower power (e.g., +14 dBm) and in a dynamically randomized slot determined as described above. When the endpoint sees the �fixed network� flag set it responds in its assigned slot at high power (e.g., +30 dBm). The advantage provided by this scenario is that in the mobile case the reader is not burdened with slot dynamic allocation of multiple, which can be computationally intensive and consume additional air time to successfully communicate to all the in-range endpoints. It also allows the endpoint to conserver power and reduce interference. This leads to the ability to transmit more data with less retries. In the fixed network case, the high power mode enables the system to get maximum range from the device (reducing infrastructure costs) while interference is mitigated by assigned slots. The slots are efficiently assigned in the fixed network case because of the pseudo-static nature of the system. Note that prior art systems enabled only static programming of the endpoint to operate in one mode or the other. As such, the previous methodology did not allow for mixed mode operation without reprogramming the endpoint. Thus, the present invention presents the combination of low power operation and dynamic slot assignment for mobile operation with the high power slotted operation for the fixed network all controlled by a flag in the outbound wakeup data. Refer to field �8,� bits 7 and 8, of the command & control frame that define the transmit/response mode.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6181257Aug 31, 1998Jan 30, 2001Kemp-Meek Manufacturing, Inc.Universal utility usage data gathering systemUS6538577 *Sep 5, 1997Mar 25, 2003Silver Springs Networks, Inc.Electronic electric meter for networked meter readingUS7277027 *Sep 26, 2003Oct 2, 2007Silver Spring Networks, Inc.Electronic electric meter for networked meter readingUS20030122686 *Dec 13, 2002Jul 3, 2003Silver Spring Networks, Inc.Electronic electric meter for networked meter readingUS20070120705 *Nov 17, 2006May 31, 2007Silverspring NetworksMethod And System for Providing A Network Protocol For Utility ServicesJP2000298746A Title not availableJP2001086254A Title not availableJP2001224082A Title not availableJP2002092774A Title not availableJPH10188190A Title not available* Cited by examinerNon-Patent CitationsReference1English translation of face/abstract of JP 10-188190.2English translation of face/abstract of JP 2000-298746.3English translation of face/abstract of JP 2001-086254.4English translation of face/abstract of JP 2001-224082.5English translation of face/abstract of JP 2002-092774.6English translation of Office Action issued in Japanese Patent Application No. 2004-254164 dispatched Mar. 2, 2010.7Office Action issued in Japanese Patent Application No. 2004-254164 dispatched Mar. 2, 2010.Classifications U.S. Classification340/870.02, 709/230, 370/328, 702/62, 324/76.11, 340/870.03, 340/870.11, 370/464International ClassificationG01D4/00, H04B7/24, G01K1/02, G08C19/16, H04Q7/38Cooperative ClassificationY04S20/325, G01K1/024, G01K1/026, Y02B90/243, G01D4/006European ClassificationG01K1/02C, G01D4/00R2, G01K1/02DLegal EventsDateCodeEventDescriptionAug 16, 2011ASAssignmentEffective date: 20110805Free format text: SECURITY AGREEMENT;ASSIGNOR:ITRON, INC.;REEL/FRAME:026761/0069Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, WASHINGTONRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google