US20140028446A1 - Method and Apparatus for Tunneling Information in RFID Communications - Google Patents
Method and Apparatus for Tunneling Information in RFID Communications Download PDFInfo
- Publication number
- US20140028446A1 US20140028446A1 US14/045,120 US201314045120A US2014028446A1 US 20140028446 A1 US20140028446 A1 US 20140028446A1 US 201314045120 A US201314045120 A US 201314045120A US 2014028446 A1 US2014028446 A1 US 2014028446A1
- Authority
- US
- United States
- Prior art keywords
- tag
- field
- extended services
- sensor
- extended
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
- G06K17/0022—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations arrangements or provisious for transferring data to distant stations, e.g. from a sensing device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/0716—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips at least one of the integrated circuit chips comprising a sensor or an interface to a sensor
- G06K19/0717—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips at least one of the integrated circuit chips comprising a sensor or an interface to a sensor the sensor being capable of sensing environmental conditions such as temperature history or pressure
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
- G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
- G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
- G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
- G06K19/07749—Constructional details, e.g. mounting of circuits in the carrier the record carrier being capable of non-contact communication, e.g. constructional details of the antenna of a non-contact smart card
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
Definitions
- This invention relates in general to radio frequency identification (RFID) systems and, more particularly, to techniques that enhance the functionality of RFID tags, including enhancement of sensor functionality in tags.
- RFID radio frequency identification
- RFID systems are used for a variety of different applications. As one example, RFID systems are commonly used to track and monitor shipping containers or other mobile assets. RFID tags are attached to the shipping containers or other assets, and exchange wireless communications with other system components, including stationary interrogators and/or readers.
- extended services may be implemented by adding supplemental hardware and/or software components to a tag.
- a tag may include one or more sensors, along with a software module that handles the sensors.
- a tag may include a global positioning system (GPS) receiver, along with a software module that processes data from the GPS receiver.
- GPS global positioning system
- a tag may include a software module that provides enhanced security for wireless communications, by encrypting and decrypting information being sent and received by the tag.
- ISO 21451.7 is based on another industry-standard protocol commonly know as IEEE 1451.7.
- IEEE 1451.7 another industry-standard protocol commonly know as IEEE 1451.7.
- the ISO 21451.7 protocol has been generally adequate for its intended purposes, it has not been entirely satisfactory in all respects.
- the ISO 21451.7 protocol is specifically designed for interaction with only a single sensor.
- FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system, that includes an interrogator and a tag, and that embodies aspects of the present invention.
- RFID radio frequency identification
- FIG. 2 is a diagrammatic view showing the format of a universal data block (UDB) that is used for transfers of certain types of data.
- UDB universal data block
- FIG. 3 is a diagrammatic view showing some data that is stored in a memory of the system of FIG. 1 .
- FIG. 4 is a diagrammatic view of a digital word contained in wireless signals transmitted from the interrogator to the tag of FIG. 1 .
- FIG. 5 is a diagrammatic view of a digital word contained in wireless signals transmitted from the tag to the interrogator of FIG. 1 .
- FIG. 6 is a diagrammatic view of one example of a command that can appear in the digital word of FIG. 4 .
- FIG. 7 is a diagrammatic view of one example of a response that is a reply to the command of FIG. 6 , and that can appear in the digital word of FIG. 5 .
- FIG. 8 is a diagrammatic view of another example of a command that can appear in the digital word of FIG. 4 .
- FIG. 9 is a diagrammatic view of another example of a response that is a reply to the command of FIG. 8 , and that can appear in the digital word of FIG. 5 .
- FIG. 10 is a diagrammatic view of one example of UDB data that can appear in the response of FIG. 9 .
- FIG. 11 is a diagrammatic view of another example of UDB data that can appear in the response of FIG. 9 .
- FIG. 12 is a diagrammatic view of yet another example of UDB data that can appear in the response of FIG. 9 .
- FIG. 13 is a diagrammatic view of an example of a payload that contains a command, and that could appear in the command of FIG. 6 .
- FIG. 14 is a diagrammatic view of an example of a payload that contains a reply to the command of FIG. 13 , and that could appear in the response of FIG. 7 .
- FIG. 15 is a diagrammatic view of another example of a payload that contains a command, and that could appear in the command of FIG. 6 .
- FIG. 16 is a diagrammatic view of an example of a payload that contains a reply to the command of FIG. 15 , and that could appear in the response of FIG. 7 .
- FIG. 17 is a diagrammatic view of yet another example of a payload that contains a command, and that could appear in the command of FIG. 6 .
- FIG. 18 is a diagrammatic view of an example of a payload that contains a reply to the command of FIG. 17 , and that could appear in the response of FIG. 7 .
- FIG. 19 is a diagrammatic view of an example of a payload that contains an alternative reply to any of the commands of FIG. 13 , 15 or 17 , and that could appear in the response of FIG. 7 .
- FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system 10 , and that embodies aspects of the present invention.
- the system 10 includes an RFID tag 11 , an interrogator 12 , and a control system 13 .
- the interrogator 12 is a device that is also sometimes referred to as a reader.
- the system 10 actually includes many tags of the type shown at 11 , and several interrogators of the type shown at 12 . However, for simplicity and clarity in the discussion that follows, only one tag 11 and one interrogator 12 are shown and described. In the disclosed embodiment, the interrogator 12 is stationary, and the tag 11 can move relative to it.
- the tag 11 may be mounted on a not-illustrated shipping container, on a vehicle (such as a truck or forklift), on an item that is being transported (such as a box containing a television set), or on some other type of mobile asset.
- a vehicle such as a truck or forklift
- an item that is being transported such as a box containing a television set
- some other type of mobile asset such as a box containing a television set
- the interrogator 12 in the disclosed embodiment is stationary, it would alternatively be possible for the interrogator to be mobile. And if the interrogator 12 is mobile, then it would alternatively be possible for the tag 11 to be stationary.
- FIG. 1 does not show all of the circuitry present within the interrogator, but instead shows only selected portions of the circuitry that are relevant to an understanding of aspects of the present invention.
- the interrogator 12 includes a microcontroller 21 .
- a microcontroller is an integrated circuit containing a microprocessor, a read-only memory (ROM), and a random access memory (RAM).
- the ROM stores a computer program that is executed by the microprocessor, along with static data used by the microprocessor.
- the RAM stores dynamic data that is changed by the microprocessor during system operation.
- the interrogator 12 includes a network interface 22 that is coupled to the microcontroller 21 , and that is also coupled through a network 23 to the control system 13 .
- the network 23 is a type of network commonly referred to in the art as an Ethernet network.
- the network 23 could alternatively be any other suitable type of network or communications system.
- the interrogator 12 also includes an ultra high frequency (UHF) transceiver 26 , and an antenna 27 through which the transceiver can send and receive wireless signals 28 .
- the wireless signals 28 contain information that is explained in more detail later.
- the wireless signals 28 are generated by frequency shift keying (FSK) to modulate information onto a radio frequency (RF) carrier signal.
- FSK frequency shift keying
- RF radio frequency
- the carrier signal has a frequency of 433.92 MHz, but it could alternatively have any other suitable frequency.
- One possible alternative frequency is 915 MHz.
- the disclosed embodiment uses 433.92 MHz because it is available for use in a larger number of countries under prevailing governmental regulations regarding the transmission of electromagnetic signals.
- the wireless signals 28 have a transmission range of about 300 feet, but the transmission range could alternatively be larger or smaller.
- the interrogator and tag in the disclosed embodiment can communicate using an existing international industry standard known as ISO 18000-7.
- ISO 18000-7 This international standard was promulgated by the International Organization for Standardization (ISO), which is headquartered in Geneva, Switzerland. Persons skilled in the art are familiar with the ISO 18000-7 standard.
- ISO 18000-7 refers to a specific version of the standard, which is ISO/IEC FDIS 18000-7:2009(E).
- the interrogator 12 and tag 11 can communicate in conformity with the ISO 18000-7 standard, they can also communicate in new and unique ways that are not currently part of the 18000-7 standard, but are potential enhancements or extensions that could be added to the 18000-7 standard. These enhancements or extensions are discussed later.
- FIG. 1 does not show everything that is present in the tag 11 , but instead shows only selected portions that are relevant to an understanding of aspects of the present invention.
- the tag 11 includes a UHF transceiver 41 , and an antenna 42 through which the transceiver 41 can send and receive wireless signals, including the wireless signals 28 .
- the tag 11 also includes a microcontroller 46 having a processor 47 and a memory 48 .
- the memory 48 is a diagrammatic representation of all types of memory that happen to be present within the microcontroller 46 , including ROM, RAM, flash memory, and/or any other type of storage. Some of the information stored in the memory 48 is discussed later.
- the tag 11 includes a temperature sensor 51 and a shock sensor 52 , which are located within a housing of the tag 11 .
- the temperature sensor 51 monitors the ambient temperature within the tag, which corresponds to the ambient external temperature near the tag.
- the shock sensor 52 can detect the magnitude of a physical shock experienced by the tag or by an asset to which the tag is attached, for example where the tag or asset is struck with force by some other object.
- a humidity sensor 53 is provided externally of the tag 11 .
- the humidity sensor 53 may be mounted on the exterior of the housing of the tag, or may be mounted on some other structure that is spaced some distance from the tag.
- the sensors 51 - 53 are each operatively coupled to the microcontroller 46 , either by wires, or by some form of wireless link, such as an infrared (IR) or an RF link.
- wires 54 couple the humidity sensor 53 to the microcontroller 46 within the tag 11 .
- the temperature sensor 51 , shock sensor 52 and humidity sensor 53 shown in FIG. 1 are merely exemplary.
- the system 10 could have various other types of sensors, and could have a larger or smaller number of sensors. Moreover, any given sensor could be located either inside or outside of the tag 11 .
- the tag 11 includes a global positioning system (GPS) receiver 57 , and an associated antenna 58 .
- GPS global positioning system
- the GPS receiver 57 can receive standard wireless GPS signals 59 transmitted by several conventional GPS satellites that orbit the earth, and that are represented diagrammatically at 61 in FIG. 1 .
- the GPS signals from satellites 61 include standard GPS positioning information that can be used in a known manner to calculate the location of the tag 11 on the surface of the earth.
- the tag 11 includes a battery 63 that powers all of the circuitry within the tag, as well as the external humidity sensor 53 .
- the humidity sensor 53 could have a separate battery.
- the battery 63 is a long-lasting lithium battery of a known type, but could alternatively be some other type of battery.
- the memory 48 stores several computer programs that are executed by the processor 47 , including a main program 71 , a sensor application 72 , a security application 73 , a real time locating system (RTLS) application 74 , and a GPS application 75 .
- the main program 71 provides the basic functionality of the tag, including RFID functionality.
- the sensor application 72 manages all of the sensors 51 - 53 that are associated with the tag 11 , and maintains some data 77 regarding the sensors. The data 77 is discussed later.
- the security application 73 provides enhanced security, for example by encrypting and decrypting information being sent and received via the wireless signals 28 , and by verifying for the tag 11 the authenticity of the remote interrogator 12 as a device that is authorized to communicate with the tag.
- the RTLS application 74 supplements the RFID functionality of the tag 11 by providing RTLS capability of a type that is known in the art, and that is therefore not described here in detail.
- the GPS receiver 57 provides the GPS application 75 with position information extracted from the GPS signals 59 , and the GPS application 57 uses this position information to calculate the current location of the tag 11 on the surface of the earth.
- the application programs 72 - 75 each provide a service that supplements or extends the capabilities of the main program 71 of the tag.
- the application programs 72 - 75 are therefore collectively referred to herein as extended services 81 .
- the communication between the main program 71 and each of the application programs 72 - 75 is referred to as an extended services interface 82 .
- the application programs 72 - 75 shown in FIG. 1 are merely exemplary.
- the tag 11 could have other types of extended services that are not illustrated and described here. Although FIG. 1 happens to show four types of extended services at 72 - 75 , the tag 11 could have a larger or smaller number of extended services, or could have no extended services at all. In the disclosed embodiment, the tag 11 is configured to handle a maximum of 16 extended services 81 . Alternatively, however, the maximum number of extended services could be higher or lower.
- the memory 48 of the microcontroller 46 has a portion set aside to store universal data block (UDB) data 86 .
- UDB is an industry-standard format for transmitting data.
- FIG. 2 is a diagrammatic view showing the standard format of a UDB 88 .
- the UDB 88 has N similar data slots, where N is an integer.
- Each of the N data slots has the same format, including the same three fields. These three fields are a type field, a length field and a data field.
- the data field contains the actual data, and has a length that corresponds to the amount of data.
- the type field identifies the type of data in the data field, and the length field identifies the actual length of the data field in bytes.
- the number N of data slots in the UDB 88 is not fixed, but can be varied in order to accommodate the number of data items that need to be transferred in a given situation.
- the data in the data field can optionally include multiple elements that each have the three-field type-length-data (TLD) format.
- TLD three-field type-length-data
- a TLD block or data slot can be nested within the data field of another TLD block or data slot.
- FIG. 3 is a diagrammatic view showing some of the UDB data stored at 86 in the memory 48 ( FIG. 1 ).
- FIG. 3 does not show all of the data stored in the UDB data 86 , but only selected items that are relevant to an understanding of aspects of the present disclosure.
- the UDB data 86 includes a group of data elements that are collectively referred to as UDB type 0x00.
- UDB type 0x00 Two of the elements in this UDB type are an extended services list 91 and an alarm summary list 93 .
- the extended services list 91 is a list of all the extended services 81 ( FIG. 1 ) that are currently installed on the tag 11 .
- the alarm summary list 93 is a list of all currently-active alarms that are associated with the extended services applications 81 . For example, if the temperature detected by the temperature sensor 51 is currently in excess of a specified upper limit, then that constitutes an alarm condition that would be reflected in the alarm summary list 93 .
- the extended services list 91 and the alarm summary list 93 are not part of the ISO 18000-7 standard, but instead are potential enhancements or extensions that could be added to the 18000-7 standard.
- the UDB data 86 also includes sixteen UDB types 0x80 through 0x8F that are respective memory blocks or storage sections 101 - 116 .
- the storage sections 101 - 116 are sometimes referred to herein as mailboxes.
- Each of the extended services 81 actually present on the tag 11 is assigned a respective one of the storage sections 101 - 116 .
- each of the extended services 81 on the tag is assigned a unique extended services identifier (ESID), which is a value from 0x80 to 0x8F.
- ESIDs are uniquely defined for each tag, based on the set of extended services actually installed on that particular tag.
- the GPS application 75 may have an ESID of 0x80 on one tag, an ESID of 0x83 on another tag, and an ESID of 0x8F on yet another tag.
- each of the extended services 81 is assigned only one mailbox in the disclosed embodiment, it would alternatively be possible for an extended service to be assigned two or more of the mailboxes.
- the storage sections 101 - 116 are each used for transmission of information between a respective one of the extended services applications 81 and other parts of the overall system.
- the sensor application 72 ( FIG. 1 ) has been assigned an ESID of 0x80 on the tag 11 , where ESID 0x80 corresponds to the storage section 101 having UDB type 0x80.
- the sensor application 72 can place information in the storage section 101 , such as the current status of the various sensors. That information can later be retrieved from the storage section 101 , for example by the interrogator 12 in a manner described later.
- information intended for the sensor application 72 can be placed in the storage section 101 , for example by the interrogator 12 in a manner described later.
- the storage sections 101 - 116 with UDB types 0x80 through 0x8F are not part of the ISO 18000-7 standard, but are potential enhancements or extensions that could be added to the 18000-7 standard.
- the interrogator 12 ( FIG. 1 ) can ask the tag 11 to send it any of the data that is stored within the UDB data 86 .
- the interrogator 12 can ask the tag 11 to send it the extended services list 91 , so the interrogator will know exactly which extended services 81 are actually installed on the particular tag 11 .
- the interrogator 12 can ask the tag 11 to send it the alarm summary list 93 , so the interrogator will know whether any extended service 81 on that tag currently has an alarm condition that may require attention.
- the interrogator 12 can ask the tag 11 to send it one or more of the storage sections 101 - 116 , in order to provide the interrogator with more detail about one or more of the extended services applications on the tag.
- FIG. 4 is a diagrammatic view of a digital word 128 that is contained in the wireless signals 28 sent by the interrogator 12 to the tag 11 .
- the general format of the digital word 128 conforms to the ISO 18000-7 communication protocol.
- the bits of the digital word 128 are incorporated into the wireless signals 28 by serially modulating the bits onto the 433.92 MHz carrier signal using FSK modulation.
- the bits of the word 128 are transmitted serially, from left to right in FIG. 4 .
- the digital word 128 includes several fields.
- the first field is a preamble 131 , which is a pre-defined pattern of bits that will allow a device receiving the signal to recognize that a wireless signal 28 is beginning, and to synchronize itself to the wireless signal.
- the preamble is approximately eight bits, but the specific number of bits can vary in dependence on factors such as characteristics of a particular receiver that is expected to receive the signal.
- the next field 132 in the word 128 is a protocol identification (ID) 132 .
- the protocol ID 32 identifies a communication protocol, such as a particular version of the 18000-7 protocol, so that a device receiving the word 128 will know what fields appear in the remainder of the word.
- the next field in the digital word 128 is a packet options field 133 , which is a standard field that is not necessary to an understanding of the present invention, and is therefore not described here in detail.
- the next field is a packet length field 134 , which is a numerical value representing the length in bytes of the entire digital word 128 , excluding the preamble 131 and a postamble 141 .
- the next field is a tag manufacturer ID 135 .
- the digital word 128 is used for point-to-point communications, where a particular interrogator transmits a message to a particular tag.
- a given tag can be uniquely identified by its manufacturer and its serial number.
- the tag manufacturer ID 135 is a code identifying the manufacturer of the particular tag to which the message containing the digital word 128 is directed.
- the next field in the digital word 128 is a session ID 136 . This is typically a code that uniquely identifies the interrogator 12 that transmitted the wireless signal 28 containing the digital word 128 .
- the next field contains a tag serial number 137 , which is the serial number of the specific tag to which the digital word 128 is directed.
- the next field in the digital word 128 is a command operation code (opcode) 138 .
- the operation code 138 tells the tag what it should do in response to the signal.
- the opcode 138 can be one of a number of different opcodes that are specified in the ISO 18000-7 standard.
- the opcode field 138 may contain a new and unique opcode that is not yet part of the ISO 18000-7 standard, but could be added to the standard as an enhancement or extension.
- the command opcode 138 is followed by a command parameters field 139 .
- the command parameters field 139 may or may not be present, depending on which opcode appears in the command opcode field 138 . That is, some commands involve only an opcode and no parameters, and in that case the command parameters field 139 would not be present. However, most commands do require one or more parameters in addition to the opcode, and thus the command parameters field 139 will typically be present. However, the length and content of the command parameters field 139 will vary from opcode to opcode.
- the next field in the digital word 128 is an error control field 140 containing a value that is a cyclic redundancy code (CRC).
- CRC cyclic redundancy code
- Communications between the interrogator 12 and the tag 11 often occur in environments that have relatively high noise levels. Therefore, it is desirable for a receiving device to be able to evaluate whether the word 128 that it received in a wireless signal 28 is correct, or has errors. Consequently the error control field 140 is included in the digital word 128 in order to permit the receiving device to identify and/or correct errors.
- CRC cyclic redundancy code
- the next field in the digital word 128 is a postamble 141 , or in other words a packet end field.
- This field signals to a receiving device that the transmission is ending.
- the postamble 141 has eight bits that are all set to a binary zero.
- the postamble 141 could alternatively have some other suitable configuration.
- the command opcode field 138 and the command parameters field 139 together constitute a command 143 . Some examples of different commands that could appear at 143 are discussed later.
- FIG. 5 is a diagrammatic view of a digital word 148 that is contained in wireless signals transmitted at 28 from the tag 11 to the interrogator 12 in response to receipt by the tag of a wireless signal 28 containing a digital word such as that shown at 128 in FIG. 4 .
- the general format of the digital word 148 conforms to the ISO 18000-7 communication protocol.
- the digital word 148 includes several fields.
- the first two fields are a preamble 151 and a protocol ID 152 .
- the preamble 151 is equivalent to the preamble 131 in digital word 128 ( FIG. 4 ).
- the protocol ID 152 will normally be identical to the protocol ID 132 ( FIG. 4 ) in the digital word 128 to which the received digital word 148 is a reply.
- the next field is a tag status field 153 .
- This field contains certain status information regarding the tag that is transmitting the digital word 148 .
- the tag status field 153 contains a bit that is set if the tag needs some type of service. This bit will be set if the battery 63 ( FIG. 1 ) is low and needs to be replaced.
- the details of the tag status field 153 are known in the art, are not necessary to an understanding of the unique aspects of the present invention, and are therefore not discussed in further detail here.
- the next field in the digital word 148 is a packet length 154 , which is the total number of bytes in the digital word 148 , excluding the preamble 151 and a postamble 161 .
- the next four fields are a session ID 155 , a tag manufacturer ID 156 , a tag serial number 157 , and a command opcode 158 , which are respectively identical to the fields 136 , 135 , 137 and 138 in the previously-received digital word 128 to which the digital word 148 is a reply.
- the tag 11 may be simultaneously communicating with two or more interrogators, and the session ID 155 ensures that one interrogator accepts the digital word 148 , while other interrogators recognize the digital word is not for them and discard it.
- the tag manufacturer ID 156 and tag serial number 157 uniquely identify the tag 11 that is transmitting the digital word 148 .
- the interrogator 12 will typically be communicating simultaneously with a large number of tags, and the tag manufacturer ID 156 and tag serial number 157 will tell the interrogator exactly which tag sent the digital word 148 .
- the command opcode 158 tells the interrogator 12 exactly which of its prior commands the tag is replying to by sending the digital word 148 .
- the next field in the digital word 148 is a response parameters field 159 , the size and configuration of which will vary in dependence on the opcode that appears in field 158 .
- the last two fields in the digital word 148 are an error control field 160 containing a CRC code, and a postamble 161 .
- the fields 160 and 161 are functionally equivalent to the fields 140 and 141 in the digital word 128 .
- the command opcode field 158 and the response parameters field 159 together constitute a response 163 . Some examples of different responses that may appear at 163 are discussed later.
- FIG. 6 is a diagrammatic view of a command 143 A that is one example of a command that can appear at 143 in the digital word 128 of FIG. 4 .
- the command 143 A is an extended services command that includes a command opcode field 171 followed by a command parameters field 139 A.
- the extended services command 143 A does not exist under the current ISO 18000-7 protocol, but instead is a new and unique extension or enhancement that could be added to the 18000-7 protocol.
- the command opcode 171 for this command is 0x27, which is an opcode that does not exist in the current ISO 18000-7 protocol. This command opcode 171 would appear in the command opcode field 138 of the digital word 128 in FIG. 4 .
- the command parameters 139 A include a sequence ID 172 , an extended services ID (ESID) 173 , and a payload 174 .
- the sequence ID 172 is used in situations where a single wireless transmission is not sufficient to deliver the entire payload to the tag. For example, the amount of information that needs to be sent in the payload field 174 may be larger than the maximum permissible size of the payload field, and the maximum permissible size of the payload field may vary as a function of local government regulations regarding wireless transmissions. Consequently, where necessary, the sequence ID 172 is used to identify a specific segment of a multiple-segment transmission, and also to indicate the number of segments yet to be transmitted.
- the sequence ID 172 in the first transmission is set to N ⁇ 1
- the sequence ID in the next transmission is set to N ⁇ 2, and so forth, until the sequence ID in the final transmission is set to zero (0).
- the tag 11 would collect and assemble all segments of the overall transmission before delivering anything to the designated extended services application. If the information to be sent is not large and can be sent in a single transmission without being split, then the sequence ID 172 for that first and only transmission is set to zero (0).
- each of the extended services 81 ( FIG. 1 ) in the tag 11 is assigned a unique ESID, which is one of the values from 0x80 to 0x8F.
- the ESID field 173 contains one of these ESIDs, and thus uniquely identifies a particular one of the extended services 81 on the tag 11 to which the command 143 A relates.
- the payload 174 contains information that the main program 71 of the tag 11 extracts from the command 143 A, and then places in the respective mailbox or storage section 101 - 116 assigned to the particular extended services program identified by the ESID field 173 . The main program 71 then notifies the designated extended services application that this information is present in the mailbox.
- the main program 71 of the tag 11 merely stores the payload 174 in the mailbox of the designated extended services program, without any study or analysis of the content of the payload. Some examples of information that can be in the payload 174 are discussed later. Although in the disclosed embodiment the main program 71 merely stores the payload 174 in the mailbox of the designated extended services program, it would alternatively be possible for the main program 71 to bypass the mailbox, and instead deliver the payload directly to the extended services application.
- FIG. 7 is a diagrammatic view of a response 163 A that is an example of a response to the specific command 143 A of FIG. 6 , and that can appear as the response 163 in the digital word 148 of FIG. 5 .
- the response 163 A is an extended services reply, or in other words a reply to the extended services command shown in FIG. 6 .
- the extended services reply 163 A of FIG. 7 may or may not be sent to the interrogator, depending for example on which extended services application is identified by the extended services ID 173 in the command 143 A of FIG. 6 .
- the extended services reply 163 A does not exist under the current ISO 18000-7 protocol, but instead is an extension or enhancement that could be added to the 18000-7 protocol.
- the response 163 A includes a command opcode field 181 , a sequence ID field 182 , and an ESID field 183 , the contents of which are respectively identical to the command opcode 171 , sequence ID 172 and ESID 173 in the command 143 A to which the tag is responding.
- the payload 184 may be simply an acknowledgement by the tag 11 that the payload 174 of the received command 143 A has been delivered to the mailbox of the extended services application identified by the ESID 173 in that received command.
- the payload 184 may be a reply from the particular extended services application identified by ESID 173 in the command 143 A.
- the tag 11 does not study or analyze the content of the payload 184 .
- the tag 11 simply takes the payload 184 from the designated one of the extended services 81 , or from the mailbox for that application, and forwards the payload 184 to the interrogator 12 without change.
- the payload 184 is a reply from an extended services application
- the length of the payload 184 can vary, and is under control of the particular extended services application that generates the payload.
- the extended services application can instead promptly provide for the payload 184 an interim reply indicating that its actual reply will be delayed. Then, the interrogator 12 can later issue another command 143 A to actually retrieve the actual reply.
- the information provided by the extended services application may be larger than the maximum permissible size of the payload 184 . In that event, the information can be put into the mailbox assigned to that particular extended services application, and then the payload 184 can be used to notify the interrogator that the information is in the mailbox and is waiting to be retrieved in a manner discussed below.
- FIG. 8 is a diagrammatic view of a different command 143 B that may appear at 143 in the digital word 128 .
- the command 143 B is a read UDB command that is defined in the current ISO 18000-7 standard.
- the command 143 B includes a command opcode 191 of 0x70, and command parameters 139 B.
- the command parameters 139 B include a UDB type code field 192 .
- the value in field 192 identifies one of the various UDB types in the UDB data 86 ( FIG. 3 ).
- the UDB type code at 192 in FIG. 8 may be 0x00, or one of 0x80 through 0x8F.
- the next field 193 in the command parameters 139 B is an offset value representing an offset into the data corresponding to the UDB type code appearing at 192 .
- the interrogator 12 can send multiple separate commands that request respective segments of the data, and each such command would have a respective different offset value at 193 in order to uniquely identify the start of each such data segment.
- the last of the command parameters 139 B is a maximum packet length value 194 .
- the field 194 specifies the maximum permissible length of a packet returned by the tag. In other words, the field 194 specifies the maximum value that can appear in the packet length field 154 of the digital word 148 ( FIG. 5 ).
- the tag can elect to use a packet length less than the maximum length specified in field 194 , but the tag is not permitted to use a larger packet length.
- the interrogator may elect to adjust the maximum packet length value that it puts in the field 194 of transmitted messages, based on factors such as ambient operating conditions.
- the interrogator 12 and tag 11 may elect to reduce the maximum packet length value presented in the field 194 of transmitted messages. Later, if the environment becomes less noisy, the interrogator may elect to increase the maximum packet length value presented in the field 194 of transmitted messages.
- FIG. 9 is a diagrammatic view of a response 163 B that is transmitted by the tag 11 in response to the command 143 B of FIG. 8 , and that can appear as the response 163 in the digital word 148 of FIG. 5 .
- the response 163 B has a format that is defined in the current ISO 18000-7 standard.
- the response 163 B includes a command opcode 201 followed by a response parameters field 159 B, where the response parameters field includes a UDB type code field 202 , a UDB type total length field 203 , a requested offset field 204 , and a UDB data field 205 .
- the fields 201 , 202 , and 204 are identical to the fields 191 , 192 and 193 in the particular command 143 B to which the tag is responding.
- the field 203 identifies the total amount of data (in bytes) that the particular tag currently has stored in the UDB data 86 ( FIG. 3 ) for the specified UDB type. Thus, for example, if the UDB type is specified to be 0x80, the field 203 will identify the total number of bytes of data that are currently stored in the storage section 101 of the UDB data 86 . This tells the interrogator 12 how much data of the specified UDB type is currently stored in the tag, so the interrogator 12 knows how much data is available to be retrieved.
- the UDB data field 205 contains an actual segment of data from the UDB data 86 , presented in TLD format.
- FIG. 10 is a diagrammatic view of one specific example of UDB data 205 A that can appear in the field 205 of the response 163 B in FIG. 9 .
- the UDB data 205 A includes a UDB element type field 211 . This field is used to distinguish different element types within a given UDB type.
- UDB type 0x00 encompasses several different types of data, including the extended services list 91 and the alarm summary list 93 .
- the extended services list 91 is identified as UDB element type 0x17, whereas the alarm summary list 93 is identified as UDB element type 0x18.
- the UDB element type field 211 contains the value 0x17 to indicate that the UDB data 205 A contains the extended services list 91 from FIG. 3 .
- the next field in the UDB data 205 A is a length field 212 , which contains a numerical value identifying the length in bytes of the data that follows the length field 212 .
- the data includes several items 213 through 215 that each identify a respective one of the extended services 81 ( FIG. 1 ) actually installed on the tag 11 . Only extended services that are actually installed on the tag are listed. If no extended services are currently installed on the tag, then none of the items 213 - 215 will be present, and the length field 212 will contain a zero. The items 213 - 215 all have the same format, and the item 213 is expanded to show this format.
- the item 213 includes a description type field 231 , a length field 232 , an ESID field 233 , and a data field 234 .
- the description type field 231 contains either a value 0x00 or a value 0x01, to specify the format for the data field 234 .
- the data field 234 uniquely identifies the particular extended services application by setting forth a previously-assigned numerical value unique to that application.
- the description type field 231 contains the value 0x01
- the data field 234 contains a string of ASCII characters uniquely identifying the particular type of extended services application.
- the length field 232 gives the length in bytes of the fields 233 and 234
- the ESID field 233 contains the ESID value assigned by the tag to the particular extended services application to which item 213 corresponds.
- the interrogator 12 can use the ESID value in field 233 to uniquely identify the particular extended services application in subsequent communications, and will know from the data field 234 exactly what type of extended services application it is working with.
- FIG. 11 is a diagrammatic view of a different example of UDB data 205 B that could appear at 205 in the response 163 B of FIG. 9 .
- the UDB data 205 B includes a UDB element type field 241 , a length field 242 , and some ESID fields 243 - 245 .
- the UDB element type field 241 contains a value 0x18, to indicate that the data in the UDB data 205 B is the alarm summary list 93 ( FIG. 3 ) from the UDB data 86 .
- the length field 242 contains a numerical value representing the length in bytes of all the ESID fields 243 - 245 .
- the fields 243 - 245 do not necessarily identify all extended services applications 81 that are currently installed on the tag 11 .
- the fields 243 - 245 identify only those extended services applications 81 that currently have an active alarm of some type. If no extended services application currently has an active alarm, then none of the fields 243 - 245 will be present, and the length field 242 will contain a value of zero.
- FIG. 12 is a diagrammatic view of still another example of UDB data 205 C that could appear at 205 in the response 163 B of FIG. 9 .
- the command 143 B of FIG. 8 can specify a particular UDB type code in field 192 , and this can be one of the type codes 0x80 through 0x8F that correspond to the storage sections or mailboxes 101 - 116 in the UDB data 86 ( FIG. 3 ).
- the UDB data 205 C includes several TLD blocks 248 - 249 , each of which includes a type field, a length field and a data field. The data fields of these TLD blocks contain some or all of the data from the specified storage section or mailbox 101 - 116 .
- the UDB data 205 C could include only a single TLD block, if the corresponding storage section contained only a single data element. Further, if the corresponding storage section did not happen to contain any data, the UDB data 205 C would no TLD blocks, and would have a length of zero.
- the interrogator 12 and any of the extended services 81 can directly exchange information with each other, where information from the interrogator 12 is placed in the payload 174 of the extended services command 143 A shown in FIG. 6 , and information from the particular extended service is either placed in the payload 184 of the extended services response 163 A shown in FIG. 7 , or placed in the UDB data field 205 of the read UDB reply 163 B shown in FIG. 9 .
- This technique can be referred to as “tunneling” information through the ISO 18000-7 wireless signals 28 and the main program 71 of the tag 11 .
- a discussion will first be provided of certain exchanges that can occur between the interrogator 12 and the sensor application 72 ( FIG.
- the interrogator 12 and the sensor application 72 can exchange information in a manner conforming to an industry-standard protocol commonly known as ISO 21451.7, which is based on another industry-standard protocol commonly know as IEEE 1451.7.
- ISO 21451.7 refers to a specific version of that standard, which is ISO/IEC/IEEE WD 21451.7, 2009-07-13.
- IEEE 1451.7 refers to a specific version of that standard, which is IEEE P1451.7/D1.0, October 2008.
- the interrogator 12 and sensor application 72 can also carry out information exchanges in a manner that is not currently part of either the ISO 21451.7 standard or the IEEE 1451.7 standard, but that involves new and unique enhancements or extensions that could be added to these standards.
- FIG. 13 is a diagrammatic view of one example of a payload 174 A that could appear as the payload 174 in the extended services command 143 A of FIG. 6 .
- the payload 174 A is a new read-sensor-identifier command that does not exist under the current ISO 21451.7 protocol, but instead is an extension or enhancement that could be added to the 21451.7 protocol.
- ISO 21451.7 and IEEE 1451.7 ach include a read-sensor-identifier command, but it can only read information regarding a single sensor.
- the new read-sensor-identifier command in payload 174 A will cause the sensor application 72 to return a single reply that identifies all sensors associated with the tag 11 .
- the command in payload 174 A includes a 5-bit command field 321 , a 1-bit parameter field 322 , and a 2-bit field 323 containing padding bits.
- the command field 321 contains a unique code identifying the read-sensor-identifier command.
- the parameter field 322 contains a single bit that identifies a format the sensor application 72 should use in its reply to identify each sensor. In particular, if the bit in the parameter field 322 is a binary “0”, then the sensor application 72 will identify each sensor with the serial number of the sensor, and a unique sensor ID code that is sometimes referred to as a port address.
- the sensor application 72 will identify each sensor by providing the unique sensor ID code for the sensor, and fields 1-3 from a transducer electronic data sheet (TEDS) for that particular sensor.
- TMS transducer electronic data sheet
- a TEDS for a given sensor is essentially a table having a series of pre-defined fields that each provide information about a respective characteristic of the sensor.
- field 1 is a 3-bit field that normally contains the binary value “001”.
- Field 2 is a 7-bit field containing a value that identifies the particular type of sensor, such as whether the sensor is a temperature sensor, a shock sensor, a humidity sensor, and so forth.
- Field 3 is a 5-bit field used only for certain types of sensors, in particular to identify a specific sub-type of the general sensor type identified in field 2. For example, if field 2 indicates that the sensor is a chemical sensor, field 3 will identify the particular type of chemical sensor.
- the padding bit field 323 the ISO 21451.7 and IEEE 1451.7 protocols are bit-based protocols, whereas the ISO 18000-7 protocol is a byte-based protocol.
- the 5-bit command field 321 and the 1-bit parameter field 322 total up to six bits, which is less than a byte.
- the 2-bit field 323 of padding bits is therefore provided to ensure that the payload 174 A has an overall size of one byte.
- the field 323 contains a binary value of “00”.
- the bits in the field 323 have no substantive meaning, and are discarded by the sensor application 72 after it receives the payload 174 A sent by the interrogator.
- FIG. 14 is a diagrammatic view of a payload 184 A that can appear as the payload 184 of the extended services response 163 A shown in FIG. 7 .
- the sensor application 72 After the sensor application 72 receives the command 321 in the payload 174 A, it prepares the payload 184 A of FIG. 14 and returns it to the interrogator 12 as a read-sensor-identifier reply.
- the read-sensor-identifier reply in the payload 184 A of FIG. 14 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols.
- the payload 184 A includes several fields 331 through 337 .
- Field 331 is a 5-bit response field containing identically the same code that appeared in the command field 321 of the payload 174 A.
- the next field is a 1-bit NAK field. This field contains a binary “0” to indicate that the sensor application 72 did not encounter any error in executing the command specified at 321 in the payload 174 A. If an error had occurred, then the NAK field would contain a binary “1”, but in that case the remainder of the payload would have a different format, as discussed in more detail later.
- the next field 333 of the payload 184 A is a 4-bit numerical value specifying the total number of sensors associated with the tag 11 .
- the field 333 is followed by several fields 334 through 336 that each provide identifying information for a respective one of the sensors in the tag.
- the number of fields 334 - 336 will be equal to the numerical value appearing in field 333 . If the tag has no sensors, then field 333 will contain a value of zero, and none of the fields 334 - 336 will be present.
- the fields 334 - 336 each have a length of either 22 bits or 71 bits, as discussed in more detail below.
- the last field 337 in the payload 184 A is only present if needed, and contains padding bits to the extent needed to ensure that the overall length of the payload 184 A is an integer number of bytes.
- the fields 334 through 336 that identify respective sensors can each have one of two different formats, and these two alternative formats are each shown in the lower portion of FIG. 14 .
- the parameter bit 322 in the payload 174 A of FIG. 13 is a binary “0”
- each of the fields 334 through 336 will contain two fields 341 and 342 .
- Field 341 is a 7-bit field containing the unique sensor ID or port address discussed above
- field 342 is a 64-bit field containing a numerical value that is the serial number of the particular sensor. Fields 341 and 342 together contain a total of 71 bits.
- Field 346 is a 7-bit field containing the same sensor ID that would appear in field 341
- fields 347 through 349 are respectively a 3-bit field, a 7-bit field, and a 5-bit field that respectively contain TEDS fields 1 through 3.
- Fields 346 through 349 together contain a total of 22 bits.
- FIG. 15 is a diagrammatic view of a payload 174 B that is an alternative example of a payload that could appear as the payload 174 of the extended services command 143 A in FIG. 6 .
- Payload 174 B contains a sensor-read-records command that does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols.
- the payload 174 B includes five fields 361 through 365 .
- the first field 361 is a 5-bit command field containing a unique code that identifies the sensor-read-records command.
- the next field 362 is a 7-bit field containing the unique sensor ID or port address of a particular sensor for which information is being requested.
- the interrogator will have previously obtained this unique sensor ID for each of the sensors, by using the read-sensor-identifier command of FIG. 13 , in response to which it receives the IDs back in the fields 341 or 346 of the response shown in FIG.
- the next field in the payload 174 B is a 4-bit measurement type field 363 that identifies the particular type of measurement information being requested.
- the permissible measurement type codes are identified in ISO 21451.7, and are therefore not all described in detail here. But by way of example, the interrogator could use the measurement type field 363 to request (1) an average of the readings from the specified sensor, (2) the most recent reading from the specified sensor, (3) part or all of a log of a series of readings from the specified sensor, either with or without date and time information for each reading, or (4) other types of measurement information. This information is all maintained by the sensor application 72 of FIG. 1 in the sensor data 77 .
- the next field 364 is 16-bit field containing a numerical value specifying the number of the first record to be returned from the data maintained for the measurement type specified at 363 .
- the next field 365 is an 8-bit field containing a numerical value specifying the number of records being requested.
- the interrogator might, for example, send a first sensor-read-records command in which the field 364 specifies record 1 and the field 365 requests 10 records.
- the sensor application 72 would then send back ten records.
- the interrogator 12 might then send a second sensor-read-records command in which the field 364 specifies record 11, and the field 365 specifies 10 records.
- the sensor application 72 would then return records 11 through 20.
- FIG. 16 is a diagrammatic view of a payload 184 B that could appear as the payload 184 in the extended services response 163 A of FIG. 7 .
- the payload 184 B contains a sensor-read-records reply, which the sensor application 72 returns in response to receipt of a sensor-read-records command 174 B ( FIG. 15 ).
- the sensor-read-records reply in the payload 184 B of FIG. 16 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols.
- the payload 184 B includes six fields 371 - 376 .
- the fields 371 , 373 and 374 will respectively be identical to the fields 361 , 364 and 365 in a sensor-read-records command received from the interrogator in the payload 174 B ( FIG. 15 ).
- the field 372 is a 1-bit NAK field that will contain a binary “0” to indicate no error occurred.
- the field 375 will contain the requested data.
- the field 376 is a padding bits field, and will only be present where needed to ensure that the overall length of the payload 184 B is an integer number of bytes.
- FIG. 17 is a diagrammatic view of a payload 174 C that is an example of still another payload that could appear at 174 in the extended services command 143 A of FIG. 6 .
- the payload 174 C contains a read-all-sensor-status command, which is a request for the sensor application 72 to return status information regarding each sensor associated with the tag 11 .
- the read-all-sensor-status command of FIG. 17 does not exist under the current ISO 21451.7 protocol, but instead is an extension or enhancement that could be added to the 21451.7 protocol.
- This command has two fields 401 and 402 .
- the field 401 is a 5-bit field containing a unique code that identifies this particular command.
- the field 402 is a 3-bit field of padding bits that contains a binary value of “000”, in order to give the payload 174 C an overall length of one byte.
- FIG. 18 is a diagrammatic view of a payload 184 C that is a further example of a payload that could appear at 184 in the extended services response 163 A of FIG. 7 .
- the payload 184 C is a read-all-sensor-status reply issued by the sensor application 72 after it receives the read-all-sensor-status command shown in FIG. 17 .
- the read-all-sensor-status reply of FIG. 18 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols.
- the payload 184 C includes several fields 411 through 417 .
- the field 411 is a 5-bit response field containing identically the same numerical code as the field 401 in the command of FIG. 17 .
- the next field 412 is a 1-bit NAK field containing a binary “0” to indicate that the sensor application 72 did not encounter any error in executing the command of FIG. 17 .
- the next field 413 is a 4-bit field containing a numerical value identifying the total number of sensors associated with the tag 11 .
- the field 413 is followed by some fields 414 through 416 that are each a 32-bit field containing status information for a respective one of the sensors associated with the tag.
- the number of fields 414 through 416 is equal to the numerical value appearing in the field 413 .
- the field 413 will contain a value of zero, and none of the fields 414 through 416 will be present.
- the last field 417 contains six padding bits that are each a binary “0”, to ensure that the overall length of the payload 184 C is an integer number of bytes.
- Each of the fields 414 through 416 contains seven fields that are shown at 421 through 427 .
- the field 421 is a 7-bit field containing the unique sensor ID or port address that was discussed earlier.
- the next field 422 is a 1-bit enabled status field that indicates whether the specified sensor is currently enabled or disabled.
- the interrogator 12 can send the sensor application 72 a command that identifies a particular sensor and indicates the sensor is to be enabled or disabled.
- the enabled status bit 422 indicates whether the sensor is currently enabled or disabled.
- the next field 423 is a 4-bit field reserved for future use. This is followed by a 12-bit sensor type field 424 , which contains fields 1 through 3 of the TEDS for the specified sensor.
- the next field 425 is a 2-bit field reserved for future use.
- the next field 426 is a 2-bit alarms set field. One bit indicates whether or not monitoring is currently enabled for a lower threshold associated with the specified sensor, and the other bit indicates whether or not monitoring is currently enabled for an upper threshold associated with that sensor.
- the next field 427 is 4-bit alarms triggered field. One bit indicates whether or not an alarm has been triggered for the upper threshold. The next bit indicates whether an alarm has been triggered for the lower threshold. The next bit indicates whether, for any of the data logs maintained for that sensor, a memory full condition has been reached, and memory rollover has not been asserted (or is not possible to assert). The remaining bit indicates whether the specified sensor has flagged a low battery condition, based on criteria specified by the sensor manufacturer. Where a tag has multiple sensors supported by a single battery, such as the battery 63 of FIG. 1 , a low battery condition can cause multiple sensors to report a low battery status condition.
- FIG. 19 is a diagrammatic view of a payload 184 D that is yet another example of a payload that can appear at 184 in the extended services response 163 A of FIG. 7 .
- the payload 184 D contains an error reply that does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols.
- the sensor application 72 may encounter some type of error in attempting to execute and respond to a command received from the interrogator 12 .
- the interrogator may ask the sensor application 72 to return a specified number of data records of a data type for which the sensor application 72 currently has a smaller number of records. The sensor application 72 therefore needs to notify the interrogator 12 that an error has occurred.
- the payload 184 D of FIG. 19 represents an error reply that the sensor application 72 can send to the interrogator 12 to identify an error.
- the payload 184 D includes five fields 451 through 455 .
- the field 451 is a 5-bit response field that contains identically the same value as the first field of the particular command that triggered the error. In other words, the field 451 would contain the value from one of the field 321 ( FIG. 13 ), the field 361 ( FIG. 15 ), the field 401 ( FIG. 17 ), or the command field in some other command that is not discussed here.
- the next field 452 is a 1-bit NAK field that contains a binary “1” to indicate an error has occurred. Assume for the sake of discussion that the sensor application 72 received the sensor-read-records command of FIG. 15 .
- the interrogator 12 would receive back a response beginning with a 5-bit field containing the code from field 361 of the command, followed by the 1-bit NAK field. The interrogator would look at the first five bits of the response to identify the corresponding command, and would then look at the 1-bit NAK field to determine whether or not an error occurred. If the NAK bit is a binary “0”, then the interrogator knows that no error occurred, and that the NAK field will be followed by the four fields 371 - 376 shown in FIG. 16 . In contrast, if the 1-bit NAK field is a binary “1”, then the interrogator knows that an error occurred, and that the remainder of the message will be the three fields 453 - 455 shown in FIG. 19 .
- the NAK field 452 is followed by a 6-bit error code field 453 .
- This field contains a code or a numerical value that uniquely identifies the particular error encountered by the sensor application 72 .
- the error code field 453 is followed by an optional data field 454 .
- the data field 454 may or may not be present, depending on the error code in field 453 . That is, some error codes may be accompanied by related data that appears in the field 454 , while other error codes may have no need to return related data. As to errors that do return data in the field 454 , the size of the data field may vary from one type of error to another.
- the last field 455 is a padding bits field that may or may not be present. It will be included where necessary to ensure that the overall length of the payload 184 D is an integer number of bytes.
- the foregoing discussion has given several specific examples of how the interrogator 12 and sensor application 72 can communicate with each other using the payload 174 ( FIG. 6 ) and the payload 184 ( FIG. 7 ).
- the payloads 174 and 184 can also be used to effect communication between the interrogator 12 and any of the other extended services applications 81 ( FIG. 1 ) that are present in the tag 11 .
- the commands and replies discussed in association with FIGS. 13 through 19 are specific to the sensor application 72 , and include some extensions or enhancements to the ISO 21451.7 and IEEE 1451.7 standards, which relate specifically to sensors.
- each extended services application 81 As to communications between the interrogator 12 and other extended services applications 81 , the manufacturer or author of each extended services application 81 , such as those shown at 73 to 75 in FIG. 1 , would define formats for commands and replies that are customized to suit the particular function and operation of that extended services application. It is not necessary to describe here in detail a separate command and reply structure for each of the extended services applications 73 - 75 in FIG. 1 . As discussed earlier, the extended services applications 81 in FIG. 1 are merely exemplary, and there are a variety of other extended services applications that could be implemented on the tag 11 .
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Hardware Design (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Toxicology (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Electromagnetism (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Radar Systems Or Details Thereof (AREA)
Abstract
A method and apparatus involve a radio frequency identification tag that receives a wireless signal containing a message type conforming to an extension of a standard communication protocol and having an extended services segment, the tag then transmitting the extended services segment through an extended services interface. According to a different aspect, a method and apparatus involve a radio frequency identification tag that stores data which includes respective information regarding each of multiple extended services, and that responds to receipt of a wireless signal which is an extension to a standard protocol by transmitting a further wireless signal which is an extension to the protocol and contains at least part of the data. According to yet another aspect, a method and apparatus involve a radio frequency identification tag that responds to receipt of one wireless signal by transmitting a further wireless signal containing information regarding multiple sensors.
Description
- This application claims the priority under 35 U.S.C. §119 of provisional application No. 61/182,444 filed May 29, 2009, the entire disclosure of which is hereby incorporated herein by reference.
- This invention relates in general to radio frequency identification (RFID) systems and, more particularly, to techniques that enhance the functionality of RFID tags, including enhancement of sensor functionality in tags.
- Radio frequency identification (RFID) systems are used for a variety of different applications. As one example, RFID systems are commonly used to track and monitor shipping containers or other mobile assets. RFID tags are attached to the shipping containers or other assets, and exchange wireless communications with other system components, including stationary interrogators and/or readers.
- Over time, RFID tags are being provided with a progressively increasing degree of extended functionality, above and beyond that needed for basic RFID operation. These optional extended functions are sometimes referred to as “extended services”. As one aspect of this, extended services may be implemented by adding supplemental hardware and/or software components to a tag. For example, a tag may include one or more sensors, along with a software module that handles the sensors. As another example, a tag may include a global positioning system (GPS) receiver, along with a software module that processes data from the GPS receiver. As yet another example, a tag may include a software module that provides enhanced security for wireless communications, by encrypting and decrypting information being sent and received by the tag.
- Many RFID tags and interrogators are currently being manufactured to communicate according to a protocol that is an international standard commonly known as ISO 18000-7. Although this protocol has been generally adequate for its intended purposes, it has not been entirely satisfactory in all respects. As one example, this protocol does not allow an interrogator to efficiently obtain from a given tag an identification of all the extended services that are implemented on the tag.
- A further consideration is that there are industry-standard protocols that can be used to interact with a single sensor. One example is ISO 21451.7, which is based on another industry-standard protocol commonly know as IEEE 1451.7. Although the ISO 21451.7 protocol has been generally adequate for its intended purposes, it has not been entirely satisfactory in all respects. As one aspect of this, there is currently no convenient way to use this protocol in conjunction with the ISO 18000-7 protocol, so that an interrogator can directly and efficiently communicate with a sensor that is provided in a tag. As another aspect, the ISO 21451.7 protocol is specifically designed for interaction with only a single sensor. Thus, in addition to the fact that there is currently no way to use the ISO 21451.7 protocol in conjunction with the ISO 18000-7 protocol, where a tag has multiple sensors it would be necessary for the tag to be simultaneously running several separate, identical instantiations of a single-sensor software module for ISO 21451.7 (one module for each sensor). This would obviously be very cumbersome and inefficient.
- A better understanding of aspects of the present invention will be realized from the detailed description that follows, taken in conjunction with the accompanying drawings, in which:
-
FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID) system, that includes an interrogator and a tag, and that embodies aspects of the present invention. -
FIG. 2 is a diagrammatic view showing the format of a universal data block (UDB) that is used for transfers of certain types of data. -
FIG. 3 is a diagrammatic view showing some data that is stored in a memory of the system ofFIG. 1 . -
FIG. 4 is a diagrammatic view of a digital word contained in wireless signals transmitted from the interrogator to the tag ofFIG. 1 . -
FIG. 5 is a diagrammatic view of a digital word contained in wireless signals transmitted from the tag to the interrogator ofFIG. 1 . -
FIG. 6 is a diagrammatic view of one example of a command that can appear in the digital word ofFIG. 4 . -
FIG. 7 is a diagrammatic view of one example of a response that is a reply to the command ofFIG. 6 , and that can appear in the digital word ofFIG. 5 . -
FIG. 8 is a diagrammatic view of another example of a command that can appear in the digital word ofFIG. 4 . -
FIG. 9 is a diagrammatic view of another example of a response that is a reply to the command ofFIG. 8 , and that can appear in the digital word ofFIG. 5 . -
FIG. 10 is a diagrammatic view of one example of UDB data that can appear in the response ofFIG. 9 . -
FIG. 11 is a diagrammatic view of another example of UDB data that can appear in the response ofFIG. 9 . -
FIG. 12 is a diagrammatic view of yet another example of UDB data that can appear in the response ofFIG. 9 . -
FIG. 13 is a diagrammatic view of an example of a payload that contains a command, and that could appear in the command ofFIG. 6 . -
FIG. 14 is a diagrammatic view of an example of a payload that contains a reply to the command ofFIG. 13 , and that could appear in the response ofFIG. 7 . -
FIG. 15 is a diagrammatic view of another example of a payload that contains a command, and that could appear in the command ofFIG. 6 . -
FIG. 16 is a diagrammatic view of an example of a payload that contains a reply to the command ofFIG. 15 , and that could appear in the response ofFIG. 7 . -
FIG. 17 is a diagrammatic view of yet another example of a payload that contains a command, and that could appear in the command ofFIG. 6 . -
FIG. 18 is a diagrammatic view of an example of a payload that contains a reply to the command ofFIG. 17 , and that could appear in the response ofFIG. 7 . -
FIG. 19 is a diagrammatic view of an example of a payload that contains an alternative reply to any of the commands ofFIG. 13 , 15 or 17, and that could appear in the response ofFIG. 7 . -
FIG. 1 is a block diagram of an apparatus that is a radio frequency identification (RFID)system 10, and that embodies aspects of the present invention. Thesystem 10 includes anRFID tag 11, aninterrogator 12, and acontrol system 13. Theinterrogator 12 is a device that is also sometimes referred to as a reader. Thesystem 10 actually includes many tags of the type shown at 11, and several interrogators of the type shown at 12. However, for simplicity and clarity in the discussion that follows, only onetag 11 and oneinterrogator 12 are shown and described. In the disclosed embodiment, theinterrogator 12 is stationary, and thetag 11 can move relative to it. For example, thetag 11 may be mounted on a not-illustrated shipping container, on a vehicle (such as a truck or forklift), on an item that is being transported (such as a box containing a television set), or on some other type of mobile asset. Although theinterrogator 12 in the disclosed embodiment is stationary, it would alternatively be possible for the interrogator to be mobile. And if theinterrogator 12 is mobile, then it would alternatively be possible for thetag 11 to be stationary. - With reference to the
interrogator 12,FIG. 1 does not show all of the circuitry present within the interrogator, but instead shows only selected portions of the circuitry that are relevant to an understanding of aspects of the present invention. Theinterrogator 12 includes amicrocontroller 21. Persons skilled in the art are familiar with the fact that a microcontroller is an integrated circuit containing a microprocessor, a read-only memory (ROM), and a random access memory (RAM). The ROM stores a computer program that is executed by the microprocessor, along with static data used by the microprocessor. The RAM stores dynamic data that is changed by the microprocessor during system operation. Theinterrogator 12 includes anetwork interface 22 that is coupled to themicrocontroller 21, and that is also coupled through anetwork 23 to thecontrol system 13. InFIG. 1 , thenetwork 23 is a type of network commonly referred to in the art as an Ethernet network. However, thenetwork 23 could alternatively be any other suitable type of network or communications system. - The
interrogator 12 also includes an ultra high frequency (UHF)transceiver 26, and anantenna 27 through which the transceiver can send and receivewireless signals 28. Thewireless signals 28 contain information that is explained in more detail later. In the embodiment ofFIG. 1 , thewireless signals 28 are generated by frequency shift keying (FSK) to modulate information onto a radio frequency (RF) carrier signal. However, it would alternatively be possible to use some other type of modulation. In the disclosed embodiment, the carrier signal has a frequency of 433.92 MHz, but it could alternatively have any other suitable frequency. One possible alternative frequency is 915 MHz. However, the disclosed embodiment uses 433.92 MHz because it is available for use in a larger number of countries under prevailing governmental regulations regarding the transmission of electromagnetic signals. In the disclosed embodiment, the wireless signals 28 have a transmission range of about 300 feet, but the transmission range could alternatively be larger or smaller. - As to the wireless signals 28 transmitted between the
interrogator 12 andtag 11, the interrogator and tag in the disclosed embodiment can communicate using an existing international industry standard known as ISO 18000-7. This international standard was promulgated by the International Organization for Standardization (ISO), which is headquartered in Geneva, Switzerland. Persons skilled in the art are familiar with the ISO 18000-7 standard. As used herein, the term ISO 18000-7 refers to a specific version of the standard, which is ISO/IEC FDIS 18000-7:2009(E). Although theinterrogator 12 andtag 11 can communicate in conformity with the ISO 18000-7 standard, they can also communicate in new and unique ways that are not currently part of the 18000-7 standard, but are potential enhancements or extensions that could be added to the 18000-7 standard. These enhancements or extensions are discussed later. - Turning to the
tag 11,FIG. 1 does not show everything that is present in thetag 11, but instead shows only selected portions that are relevant to an understanding of aspects of the present invention. Thetag 11 includes aUHF transceiver 41, and anantenna 42 through which thetransceiver 41 can send and receive wireless signals, including the wireless signals 28. Thetag 11 also includes amicrocontroller 46 having aprocessor 47 and amemory 48. InFIG. 1 , thememory 48 is a diagrammatic representation of all types of memory that happen to be present within themicrocontroller 46, including ROM, RAM, flash memory, and/or any other type of storage. Some of the information stored in thememory 48 is discussed later. - The
tag 11 includes atemperature sensor 51 and ashock sensor 52, which are located within a housing of thetag 11. Thetemperature sensor 51 monitors the ambient temperature within the tag, which corresponds to the ambient external temperature near the tag. Theshock sensor 52 can detect the magnitude of a physical shock experienced by the tag or by an asset to which the tag is attached, for example where the tag or asset is struck with force by some other object. Ahumidity sensor 53 is provided externally of thetag 11. Thehumidity sensor 53 may be mounted on the exterior of the housing of the tag, or may be mounted on some other structure that is spaced some distance from the tag. The sensors 51-53 are each operatively coupled to themicrocontroller 46, either by wires, or by some form of wireless link, such as an infrared (IR) or an RF link. For example,wires 54 couple thehumidity sensor 53 to themicrocontroller 46 within thetag 11. Thetemperature sensor 51,shock sensor 52 andhumidity sensor 53 shown inFIG. 1 are merely exemplary. Thesystem 10 could have various other types of sensors, and could have a larger or smaller number of sensors. Moreover, any given sensor could be located either inside or outside of thetag 11. - The
tag 11 includes a global positioning system (GPS)receiver 57, and an associatedantenna 58. Through theantenna 58, theGPS receiver 57 can receive standard wireless GPS signals 59 transmitted by several conventional GPS satellites that orbit the earth, and that are represented diagrammatically at 61 inFIG. 1 . The GPS signals fromsatellites 61 include standard GPS positioning information that can be used in a known manner to calculate the location of thetag 11 on the surface of the earth. - The
tag 11 includes abattery 63 that powers all of the circuitry within the tag, as well as theexternal humidity sensor 53. Alternatively, thehumidity sensor 53 could have a separate battery. In the disclosed embodiment, thebattery 63 is a long-lasting lithium battery of a known type, but could alternatively be some other type of battery. - Referring again to the
microcontroller 46, thememory 48 stores several computer programs that are executed by theprocessor 47, including amain program 71, a sensor application 72, asecurity application 73, a real time locating system (RTLS)application 74, and aGPS application 75. Themain program 71 provides the basic functionality of the tag, including RFID functionality. The sensor application 72 manages all of the sensors 51-53 that are associated with thetag 11, and maintains somedata 77 regarding the sensors. Thedata 77 is discussed later. Thesecurity application 73 provides enhanced security, for example by encrypting and decrypting information being sent and received via the wireless signals 28, and by verifying for thetag 11 the authenticity of theremote interrogator 12 as a device that is authorized to communicate with the tag. TheRTLS application 74 supplements the RFID functionality of thetag 11 by providing RTLS capability of a type that is known in the art, and that is therefore not described here in detail. TheGPS receiver 57 provides theGPS application 75 with position information extracted from the GPS signals 59, and theGPS application 57 uses this position information to calculate the current location of thetag 11 on the surface of the earth. - The application programs 72-75 each provide a service that supplements or extends the capabilities of the
main program 71 of the tag. The application programs 72-75 are therefore collectively referred to herein asextended services 81. The communication between themain program 71 and each of the application programs 72-75 is referred to as anextended services interface 82. The application programs 72-75 shown inFIG. 1 are merely exemplary. Thetag 11 could have other types of extended services that are not illustrated and described here. AlthoughFIG. 1 happens to show four types of extended services at 72-75, thetag 11 could have a larger or smaller number of extended services, or could have no extended services at all. In the disclosed embodiment, thetag 11 is configured to handle a maximum of 16extended services 81. Alternatively, however, the maximum number of extended services could be higher or lower. - The
memory 48 of themicrocontroller 46 has a portion set aside to store universal data block (UDB)data 86. A UDB is an industry-standard format for transmitting data.FIG. 2 is a diagrammatic view showing the standard format of aUDB 88. TheUDB 88 has N similar data slots, where N is an integer. Each of the N data slots has the same format, including the same three fields. These three fields are a type field, a length field and a data field. The data field contains the actual data, and has a length that corresponds to the amount of data. The type field identifies the type of data in the data field, and the length field identifies the actual length of the data field in bytes. The number N of data slots in theUDB 88 is not fixed, but can be varied in order to accommodate the number of data items that need to be transferred in a given situation. The data in the data field can optionally include multiple elements that each have the three-field type-length-data (TLD) format. In other words, a TLD block or data slot can be nested within the data field of another TLD block or data slot. A detailed explanation of UDBs is provided in U.S. Pat. No. 7,434,731, the entire disclosure of which is hereby incorporated herein by reference. -
FIG. 3 is a diagrammatic view showing some of the UDB data stored at 86 in the memory 48 (FIG. 1 ).FIG. 3 does not show all of the data stored in theUDB data 86, but only selected items that are relevant to an understanding of aspects of the present disclosure. In this disclosure, when “0x” precedes a group of characters, it is an indication that the characters are in hexadecimal format. TheUDB data 86 includes a group of data elements that are collectively referred to as UDB type 0x00. Two of the elements in this UDB type are anextended services list 91 and analarm summary list 93. Theextended services list 91 is a list of all the extended services 81 (FIG. 1 ) that are currently installed on thetag 11. Thealarm summary list 93 is a list of all currently-active alarms that are associated with theextended services applications 81. For example, if the temperature detected by thetemperature sensor 51 is currently in excess of a specified upper limit, then that constitutes an alarm condition that would be reflected in thealarm summary list 93. Theextended services list 91 and thealarm summary list 93 are not part of the ISO 18000-7 standard, but instead are potential enhancements or extensions that could be added to the 18000-7 standard. - The
UDB data 86 also includes sixteen UDB types 0x80 through 0x8F that are respective memory blocks or storage sections 101-116. The storage sections 101-116 are sometimes referred to herein as mailboxes. Each of theextended services 81 actually present on thetag 11 is assigned a respective one of the storage sections 101-116. In this regard, each of theextended services 81 on the tag is assigned a unique extended services identifier (ESID), which is a value from 0x80 to 0x8F. These ESIDs are uniquely defined for each tag, based on the set of extended services actually installed on that particular tag. Thus, for example, theGPS application 75 may have an ESID of 0x80 on one tag, an ESID of 0x83 on another tag, and an ESID of 0x8F on yet another tag. Although each of theextended services 81 is assigned only one mailbox in the disclosed embodiment, it would alternatively be possible for an extended service to be assigned two or more of the mailboxes. - The storage sections 101-116 are each used for transmission of information between a respective one of the
extended services applications 81 and other parts of the overall system. For the sake of discussion, assume that the sensor application 72 (FIG. 1 ) has been assigned an ESID of 0x80 on thetag 11, where ESID 0x80 corresponds to thestorage section 101 having UDB type 0x80. The sensor application 72 can place information in thestorage section 101, such as the current status of the various sensors. That information can later be retrieved from thestorage section 101, for example by theinterrogator 12 in a manner described later. In addition, information intended for the sensor application 72 can be placed in thestorage section 101, for example by theinterrogator 12 in a manner described later. Later, that information can be retrieved from thestorage section 101 by the sensor application 72. The storage sections 101-116 with UDB types 0x80 through 0x8F are not part of the ISO 18000-7 standard, but are potential enhancements or extensions that could be added to the 18000-7 standard. - The interrogator 12 (
FIG. 1 ) can ask thetag 11 to send it any of the data that is stored within theUDB data 86. For example, theinterrogator 12 can ask thetag 11 to send it theextended services list 91, so the interrogator will know exactly which extendedservices 81 are actually installed on theparticular tag 11. Theinterrogator 12 can ask thetag 11 to send it thealarm summary list 93, so the interrogator will know whether anyextended service 81 on that tag currently has an alarm condition that may require attention. Further, theinterrogator 12 can ask thetag 11 to send it one or more of the storage sections 101-116, in order to provide the interrogator with more detail about one or more of the extended services applications on the tag. - The manner in which the
interrogator 12 can communicate with theextended services 81 on thetag 11 will now be described in more detail.FIG. 4 is a diagrammatic view of adigital word 128 that is contained in the wireless signals 28 sent by theinterrogator 12 to thetag 11. The general format of thedigital word 128 conforms to the ISO 18000-7 communication protocol. The bits of thedigital word 128 are incorporated into the wireless signals 28 by serially modulating the bits onto the 433.92 MHz carrier signal using FSK modulation. The bits of theword 128 are transmitted serially, from left to right inFIG. 4 . - The
digital word 128 includes several fields. The first field is apreamble 131, which is a pre-defined pattern of bits that will allow a device receiving the signal to recognize that awireless signal 28 is beginning, and to synchronize itself to the wireless signal. In the disclosed embodiment, the preamble is approximately eight bits, but the specific number of bits can vary in dependence on factors such as characteristics of a particular receiver that is expected to receive the signal. - The
next field 132 in theword 128 is a protocol identification (ID) 132. Theprotocol ID 32 identifies a communication protocol, such as a particular version of the 18000-7 protocol, so that a device receiving theword 128 will know what fields appear in the remainder of the word. The next field in thedigital word 128 is apacket options field 133, which is a standard field that is not necessary to an understanding of the present invention, and is therefore not described here in detail. The next field is apacket length field 134, which is a numerical value representing the length in bytes of the entiredigital word 128, excluding thepreamble 131 and apostamble 141. - The next field is a
tag manufacturer ID 135. Thedigital word 128 is used for point-to-point communications, where a particular interrogator transmits a message to a particular tag. A given tag can be uniquely identified by its manufacturer and its serial number. Thetag manufacturer ID 135 is a code identifying the manufacturer of the particular tag to which the message containing thedigital word 128 is directed. - The next field in the
digital word 128 is asession ID 136. This is typically a code that uniquely identifies theinterrogator 12 that transmitted thewireless signal 28 containing thedigital word 128. The next field contains a tagserial number 137, which is the serial number of the specific tag to which thedigital word 128 is directed. - The next field in the
digital word 128 is a command operation code (opcode) 138. When thetag 11 receives awireless signal 28 containing thedigital word 128, theoperation code 138 tells the tag what it should do in response to the signal. In the disclosed embodiment, theopcode 138 can be one of a number of different opcodes that are specified in the ISO 18000-7 standard. Alternatively, as discussed in more detail later, theopcode field 138 may contain a new and unique opcode that is not yet part of the ISO 18000-7 standard, but could be added to the standard as an enhancement or extension. - The
command opcode 138 is followed by acommand parameters field 139. Thecommand parameters field 139 may or may not be present, depending on which opcode appears in thecommand opcode field 138. That is, some commands involve only an opcode and no parameters, and in that case thecommand parameters field 139 would not be present. However, most commands do require one or more parameters in addition to the opcode, and thus thecommand parameters field 139 will typically be present. However, the length and content of thecommand parameters field 139 will vary from opcode to opcode. - The next field in the
digital word 128 is anerror control field 140 containing a value that is a cyclic redundancy code (CRC). Communications between theinterrogator 12 and thetag 11 often occur in environments that have relatively high noise levels. Therefore, it is desirable for a receiving device to be able to evaluate whether theword 128 that it received in awireless signal 28 is correct, or has errors. Consequently theerror control field 140 is included in thedigital word 128 in order to permit the receiving device to identify and/or correct errors. Although the disclosed embodiment uses a CRC value, it would alternatively be possible to use any other suitable error detection and/or correction scheme, such as parity bits, or a forward error correction (FEC) code. - The next field in the
digital word 128 is a postamble 141, or in other words a packet end field. This field signals to a receiving device that the transmission is ending. In the disclosed embodiment, thepostamble 141 has eight bits that are all set to a binary zero. However, thepostamble 141 could alternatively have some other suitable configuration. Thecommand opcode field 138 and thecommand parameters field 139 together constitute acommand 143. Some examples of different commands that could appear at 143 are discussed later. - As explained above, when the
tag 11 receives thedigital word 128, thecommand opcode 138 instructs the tag to take some type of action. Sometimes this action does not require thetag 11 to send any reply back to theinterrogator 12. Typically, however, thetag 11 will need to send a reply to theinterrogator 12.FIG. 5 is a diagrammatic view of adigital word 148 that is contained in wireless signals transmitted at 28 from thetag 11 to theinterrogator 12 in response to receipt by the tag of awireless signal 28 containing a digital word such as that shown at 128 inFIG. 4 . The general format of thedigital word 148 conforms to the ISO 18000-7 communication protocol. Thedigital word 148 includes several fields. The first two fields are apreamble 151 and aprotocol ID 152. Thepreamble 151 is equivalent to thepreamble 131 in digital word 128 (FIG. 4 ). Theprotocol ID 152 will normally be identical to the protocol ID 132 (FIG. 4 ) in thedigital word 128 to which the receiveddigital word 148 is a reply. - The next field is a
tag status field 153. This field contains certain status information regarding the tag that is transmitting thedigital word 148. For example, thetag status field 153 contains a bit that is set if the tag needs some type of service. This bit will be set if the battery 63 (FIG. 1 ) is low and needs to be replaced. The details of thetag status field 153 are known in the art, are not necessary to an understanding of the unique aspects of the present invention, and are therefore not discussed in further detail here. - The next field in the
digital word 148 is apacket length 154, which is the total number of bytes in thedigital word 148, excluding thepreamble 151 and apostamble 161. The next four fields are asession ID 155, atag manufacturer ID 156, a tagserial number 157, and acommand opcode 158, which are respectively identical to thefields digital word 128 to which thedigital word 148 is a reply. Thetag 11 may be simultaneously communicating with two or more interrogators, and thesession ID 155 ensures that one interrogator accepts thedigital word 148, while other interrogators recognize the digital word is not for them and discard it. Thetag manufacturer ID 156 and tagserial number 157 uniquely identify thetag 11 that is transmitting thedigital word 148. Theinterrogator 12 will typically be communicating simultaneously with a large number of tags, and thetag manufacturer ID 156 and tagserial number 157 will tell the interrogator exactly which tag sent thedigital word 148. Thecommand opcode 158 tells theinterrogator 12 exactly which of its prior commands the tag is replying to by sending thedigital word 148. - The next field in the
digital word 148 is aresponse parameters field 159, the size and configuration of which will vary in dependence on the opcode that appears infield 158. The last two fields in thedigital word 148 are anerror control field 160 containing a CRC code, and apostamble 161. Thefields fields digital word 128. Thecommand opcode field 158 and the response parameters field 159 together constitute aresponse 163. Some examples of different responses that may appear at 163 are discussed later. -
FIG. 6 is a diagrammatic view of acommand 143A that is one example of a command that can appear at 143 in thedigital word 128 ofFIG. 4 . Thecommand 143A is an extended services command that includes acommand opcode field 171 followed by acommand parameters field 139A. The extended services command 143A does not exist under the current ISO 18000-7 protocol, but instead is a new and unique extension or enhancement that could be added to the 18000-7 protocol. In the disclosed embodiment, thecommand opcode 171 for this command is 0x27, which is an opcode that does not exist in the current ISO 18000-7 protocol. Thiscommand opcode 171 would appear in thecommand opcode field 138 of thedigital word 128 inFIG. 4 . - The
command parameters 139A include asequence ID 172, an extended services ID (ESID) 173, and apayload 174. Thesequence ID 172 is used in situations where a single wireless transmission is not sufficient to deliver the entire payload to the tag. For example, the amount of information that needs to be sent in thepayload field 174 may be larger than the maximum permissible size of the payload field, and the maximum permissible size of the payload field may vary as a function of local government regulations regarding wireless transmissions. Consequently, where necessary, thesequence ID 172 is used to identify a specific segment of a multiple-segment transmission, and also to indicate the number of segments yet to be transmitted. In more detail, if the information to be sent is large and is therefore split into N segments that will each be transmitted separately, thesequence ID 172 in the first transmission is set to N−1, the sequence ID in the next transmission is set to N−2, and so forth, until the sequence ID in the final transmission is set to zero (0). Thetag 11 would collect and assemble all segments of the overall transmission before delivering anything to the designated extended services application. If the information to be sent is not large and can be sent in a single transmission without being split, then thesequence ID 172 for that first and only transmission is set to zero (0). - As discussed earlier, each of the extended services 81 (
FIG. 1 ) in thetag 11 is assigned a unique ESID, which is one of the values from 0x80 to 0x8F. TheESID field 173 contains one of these ESIDs, and thus uniquely identifies a particular one of theextended services 81 on thetag 11 to which thecommand 143A relates. Thepayload 174 contains information that themain program 71 of thetag 11 extracts from thecommand 143A, and then places in the respective mailbox or storage section 101-116 assigned to the particular extended services program identified by theESID field 173. Themain program 71 then notifies the designated extended services application that this information is present in the mailbox. Themain program 71 of thetag 11 merely stores thepayload 174 in the mailbox of the designated extended services program, without any study or analysis of the content of the payload. Some examples of information that can be in thepayload 174 are discussed later. Although in the disclosed embodiment themain program 71 merely stores thepayload 174 in the mailbox of the designated extended services program, it would alternatively be possible for themain program 71 to bypass the mailbox, and instead deliver the payload directly to the extended services application. -
FIG. 7 is a diagrammatic view of aresponse 163A that is an example of a response to thespecific command 143A ofFIG. 6 , and that can appear as theresponse 163 in thedigital word 148 ofFIG. 5 . Theresponse 163A is an extended services reply, or in other words a reply to the extended services command shown inFIG. 6 . The extended services reply 163A ofFIG. 7 may or may not be sent to the interrogator, depending for example on which extended services application is identified by theextended services ID 173 in thecommand 143A ofFIG. 6 . The extended services reply 163A does not exist under the current ISO 18000-7 protocol, but instead is an extension or enhancement that could be added to the 18000-7 protocol. - The
response 163A includes acommand opcode field 181, asequence ID field 182, and anESID field 183, the contents of which are respectively identical to thecommand opcode 171,sequence ID 172 andESID 173 in thecommand 143A to which the tag is responding. Thepayload 184 may be simply an acknowledgement by thetag 11 that thepayload 174 of the receivedcommand 143A has been delivered to the mailbox of the extended services application identified by theESID 173 in that received command. Alternatively, thepayload 184 may be a reply from the particular extended services application identified byESID 173 in thecommand 143A. Where thepayload 184 is a reply from an extended services application, thetag 11 does not study or analyze the content of thepayload 184. Thetag 11 simply takes thepayload 184 from the designated one of theextended services 81, or from the mailbox for that application, and forwards thepayload 184 to theinterrogator 12 without change. Where thepayload 184 is a reply from an extended services application, the length of thepayload 184 can vary, and is under control of the particular extended services application that generates the payload. Some examples of information that can be in thepayload 184 are discussed later. In some cases, after an extended services application receives thecommand 143A, it may not be able to provide requested information for thepayload 184 within a time limit imposed by the ISO 18000-7 standard. In that case, the extended services application can instead promptly provide for thepayload 184 an interim reply indicating that its actual reply will be delayed. Then, theinterrogator 12 can later issue anothercommand 143A to actually retrieve the actual reply. In other situations, the information provided by the extended services application may be larger than the maximum permissible size of thepayload 184. In that event, the information can be put into the mailbox assigned to that particular extended services application, and then thepayload 184 can be used to notify the interrogator that the information is in the mailbox and is waiting to be retrieved in a manner discussed below. -
FIG. 8 is a diagrammatic view of adifferent command 143B that may appear at 143 in thedigital word 128. Thecommand 143B is a read UDB command that is defined in the current ISO 18000-7 standard. Thecommand 143B includes acommand opcode 191 of 0x70, andcommand parameters 139B. Thecommand parameters 139B include a UDBtype code field 192. The value infield 192 identifies one of the various UDB types in the UDB data 86 (FIG. 3 ). For example, with reference to the left side ofFIG. 3 , the UDB type code at 192 inFIG. 8 may be 0x00, or one of 0x80 through 0x8F. Thenext field 193 in thecommand parameters 139B is an offset value representing an offset into the data corresponding to the UDB type code appearing at 192. Thus, for example, where theinterrogator 12 wishes to read a large amount data from theUDB data 86, the interrogator can send multiple separate commands that request respective segments of the data, and each such command would have a respective different offset value at 193 in order to uniquely identify the start of each such data segment. - The last of the
command parameters 139B is a maximumpacket length value 194. When a tag eventually replies to thecommand 143B, thefield 194 specifies the maximum permissible length of a packet returned by the tag. In other words, thefield 194 specifies the maximum value that can appear in thepacket length field 154 of the digital word 148 (FIG. 5 ). The tag can elect to use a packet length less than the maximum length specified infield 194, but the tag is not permitted to use a larger packet length. Over time, the interrogator may elect to adjust the maximum packet length value that it puts in thefield 194 of transmitted messages, based on factors such as ambient operating conditions. For example, if theinterrogator 12 andtag 11 are currently operating in a noisy environment, the interrogator may elect to reduce the maximum packet length value presented in thefield 194 of transmitted messages. Later, if the environment becomes less noisy, the interrogator may elect to increase the maximum packet length value presented in thefield 194 of transmitted messages. -
FIG. 9 is a diagrammatic view of aresponse 163B that is transmitted by thetag 11 in response to thecommand 143B ofFIG. 8 , and that can appear as theresponse 163 in thedigital word 148 ofFIG. 5 . Theresponse 163B has a format that is defined in the current ISO 18000-7 standard. Theresponse 163B includes acommand opcode 201 followed by aresponse parameters field 159B, where the response parameters field includes a UDBtype code field 202, a UDB typetotal length field 203, a requested offsetfield 204, and aUDB data field 205. - The
fields fields particular command 143B to which the tag is responding. Thefield 203 identifies the total amount of data (in bytes) that the particular tag currently has stored in the UDB data 86 (FIG. 3 ) for the specified UDB type. Thus, for example, if the UDB type is specified to be 0x80, thefield 203 will identify the total number of bytes of data that are currently stored in thestorage section 101 of theUDB data 86. This tells theinterrogator 12 how much data of the specified UDB type is currently stored in the tag, so theinterrogator 12 knows how much data is available to be retrieved. TheUDB data field 205 contains an actual segment of data from theUDB data 86, presented in TLD format. -
FIG. 10 is a diagrammatic view of one specific example of UDB data 205A that can appear in thefield 205 of theresponse 163B inFIG. 9 . The UDB data 205A includes a UDBelement type field 211. This field is used to distinguish different element types within a given UDB type. For example, with reference toFIG. 3 , UDB type 0x00 encompasses several different types of data, including the extendedservices list 91 and thealarm summary list 93. Theextended services list 91 is identified as UDB element type 0x17, whereas thealarm summary list 93 is identified as UDB element type 0x18. These two UDB element types do not exist under the current ISO 18000-7 protocol, but instead represent an extension or enhancement that could be added to the 18000-7 protocol. InFIG. 10 , the UDBelement type field 211 contains the value 0x17 to indicate that the UDB data 205A contains the extended services list 91 fromFIG. 3 . - The next field in the UDB data 205A is a
length field 212, which contains a numerical value identifying the length in bytes of the data that follows thelength field 212. InFIG. 10 , the data includesseveral items 213 through 215 that each identify a respective one of the extended services 81 (FIG. 1 ) actually installed on thetag 11. Only extended services that are actually installed on the tag are listed. If no extended services are currently installed on the tag, then none of the items 213-215 will be present, and thelength field 212 will contain a zero. The items 213-215 all have the same format, and theitem 213 is expanded to show this format. - More specifically, the
item 213 includes a description type field 231, alength field 232, anESID field 233, and adata field 234. In the disclosed embodiment, the description type field 231 contains either a value 0x00 or a value 0x01, to specify the format for thedata field 234. In particular, if the description type field 231 contains the value 0x00, then thedata field 234 uniquely identifies the particular extended services application by setting forth a previously-assigned numerical value unique to that application. Alternatively, if the description type field 231 contains the value 0x01, then thedata field 234 contains a string of ASCII characters uniquely identifying the particular type of extended services application. - The
length field 232 gives the length in bytes of thefields ESID field 233 contains the ESID value assigned by the tag to the particular extended services application to whichitem 213 corresponds. Theinterrogator 12 can use the ESID value infield 233 to uniquely identify the particular extended services application in subsequent communications, and will know from thedata field 234 exactly what type of extended services application it is working with. -
FIG. 11 is a diagrammatic view of a different example ofUDB data 205B that could appear at 205 in theresponse 163B ofFIG. 9 . TheUDB data 205B includes a UDBelement type field 241, alength field 242, and some ESID fields 243-245. The UDBelement type field 241 contains a value 0x18, to indicate that the data in theUDB data 205B is the alarm summary list 93 (FIG. 3 ) from theUDB data 86. Thelength field 242 contains a numerical value representing the length in bytes of all the ESID fields 243-245. The fields 243-245 do not necessarily identify allextended services applications 81 that are currently installed on thetag 11. Instead, the fields 243-245 identify only those extendedservices applications 81 that currently have an active alarm of some type. If no extended services application currently has an active alarm, then none of the fields 243-245 will be present, and thelength field 242 will contain a value of zero. -
FIG. 12 is a diagrammatic view of still another example ofUDB data 205C that could appear at 205 in theresponse 163B ofFIG. 9 . As discussed above, thecommand 143B ofFIG. 8 can specify a particular UDB type code infield 192, and this can be one of the type codes 0x80 through 0x8F that correspond to the storage sections or mailboxes 101-116 in the UDB data 86 (FIG. 3 ). InFIG. 12 , theUDB data 205C includes several TLD blocks 248-249, each of which includes a type field, a length field and a data field. The data fields of these TLD blocks contain some or all of the data from the specified storage section or mailbox 101-116. AlthoughFIG. 12 shows a series of TLD blocks, theUDB data 205C could include only a single TLD block, if the corresponding storage section contained only a single data element. Further, if the corresponding storage section did not happen to contain any data, theUDB data 205C would no TLD blocks, and would have a length of zero. - As explained earlier, the
interrogator 12 and any of theextended services 81 can directly exchange information with each other, where information from theinterrogator 12 is placed in thepayload 174 of theextended services command 143A shown inFIG. 6 , and information from the particular extended service is either placed in thepayload 184 of theextended services response 163A shown inFIG. 7 , or placed in theUDB data field 205 of theread UDB reply 163B shown inFIG. 9 . This technique can be referred to as “tunneling” information through the ISO 18000-7 wireless signals 28 and themain program 71 of thetag 11. For simplicity and clarity, a discussion will first be provided of certain exchanges that can occur between theinterrogator 12 and the sensor application 72 (FIG. 1 ) that manages the three sensors 51-53. As one aspect of this, theinterrogator 12 and the sensor application 72 can exchange information in a manner conforming to an industry-standard protocol commonly known as ISO 21451.7, which is based on another industry-standard protocol commonly know as IEEE 1451.7. As used herein, the term ISO 21451.7 refers to a specific version of that standard, which is ISO/IEC/IEEE WD 21451.7, 2009-07-13. And as used herein, the term IEEE 1451.7 refers to a specific version of that standard, which is IEEE P1451.7/D1.0, October 2008. Theinterrogator 12 and sensor application 72 can also carry out information exchanges in a manner that is not currently part of either the ISO 21451.7 standard or the IEEE 1451.7 standard, but that involves new and unique enhancements or extensions that could be added to these standards. -
FIG. 13 is a diagrammatic view of one example of apayload 174A that could appear as thepayload 174 in theextended services command 143A ofFIG. 6 . Thepayload 174A is a new read-sensor-identifier command that does not exist under the current ISO 21451.7 protocol, but instead is an extension or enhancement that could be added to the 21451.7 protocol. In this regard, ISO 21451.7 and IEEE 1451.7 ach include a read-sensor-identifier command, but it can only read information regarding a single sensor. In contrast, the new read-sensor-identifier command inpayload 174A will cause the sensor application 72 to return a single reply that identifies all sensors associated with thetag 11. - The command in
payload 174A includes a 5-bit command field 321, a 1-bit parameter field 322, and a 2-bit field 323 containing padding bits. Thecommand field 321 contains a unique code identifying the read-sensor-identifier command. Theparameter field 322 contains a single bit that identifies a format the sensor application 72 should use in its reply to identify each sensor. In particular, if the bit in theparameter field 322 is a binary “0”, then the sensor application 72 will identify each sensor with the serial number of the sensor, and a unique sensor ID code that is sometimes referred to as a port address. On the other hand, if the bit in theparameter field 322 is a binary “1”, then the sensor application 72 will identify each sensor by providing the unique sensor ID code for the sensor, and fields 1-3 from a transducer electronic data sheet (TEDS) for that particular sensor. - In this regard, and as is known in the art, a TEDS for a given sensor is essentially a table having a series of pre-defined fields that each provide information about a respective characteristic of the sensor. Under the TEDS standard,
field 1 is a 3-bit field that normally contains the binary value “001”.Field 2 is a 7-bit field containing a value that identifies the particular type of sensor, such as whether the sensor is a temperature sensor, a shock sensor, a humidity sensor, and so forth.Field 3 is a 5-bit field used only for certain types of sensors, in particular to identify a specific sub-type of the general sensor type identified infield 2. For example, iffield 2 indicates that the sensor is a chemical sensor,field 3 will identify the particular type of chemical sensor. - Turning to the
padding bit field 323, the ISO 21451.7 and IEEE 1451.7 protocols are bit-based protocols, whereas the ISO 18000-7 protocol is a byte-based protocol. InFIG. 13 , the 5-bit command field 321 and the 1-bit parameter field 322 total up to six bits, which is less than a byte. The 2-bit field 323 of padding bits is therefore provided to ensure that thepayload 174A has an overall size of one byte. Thefield 323 contains a binary value of “00”. The bits in thefield 323 have no substantive meaning, and are discarded by the sensor application 72 after it receives thepayload 174A sent by the interrogator. -
FIG. 14 is a diagrammatic view of apayload 184A that can appear as thepayload 184 of theextended services response 163A shown inFIG. 7 . After the sensor application 72 receives thecommand 321 in thepayload 174A, it prepares thepayload 184A ofFIG. 14 and returns it to theinterrogator 12 as a read-sensor-identifier reply. The read-sensor-identifier reply in thepayload 184A ofFIG. 14 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols. - In more detail, the
payload 184A includesseveral fields 331 through 337.Field 331 is a 5-bit response field containing identically the same code that appeared in thecommand field 321 of thepayload 174A. The next field is a 1-bit NAK field. This field contains a binary “0” to indicate that the sensor application 72 did not encounter any error in executing the command specified at 321 in thepayload 174A. If an error had occurred, then the NAK field would contain a binary “1”, but in that case the remainder of the payload would have a different format, as discussed in more detail later. - The
next field 333 of thepayload 184A is a 4-bit numerical value specifying the total number of sensors associated with thetag 11. Thefield 333 is followed byseveral fields 334 through 336 that each provide identifying information for a respective one of the sensors in the tag. The number of fields 334-336 will be equal to the numerical value appearing infield 333. If the tag has no sensors, then field 333 will contain a value of zero, and none of the fields 334-336 will be present. When present, the fields 334-336 each have a length of either 22 bits or 71 bits, as discussed in more detail below. Thelast field 337 in thepayload 184A is only present if needed, and contains padding bits to the extent needed to ensure that the overall length of thepayload 184A is an integer number of bytes. - As discussed above, the
fields 334 through 336 that identify respective sensors can each have one of two different formats, and these two alternative formats are each shown in the lower portion ofFIG. 14 . In particular, if theparameter bit 322 in thepayload 174A ofFIG. 13 is a binary “0”, then each of thefields 334 through 336 will contain twofields 341 and 342. Field 341 is a 7-bit field containing the unique sensor ID or port address discussed above, andfield 342 is a 64-bit field containing a numerical value that is the serial number of the particular sensor.Fields 341 and 342 together contain a total of 71 bits. On the other hand, if theparameter bit 322 in thepayload 174A ofFIG. 13 is a binary “1”, then the fields 334-336 will each contain fourfields 346 through 349.Field 346 is a 7-bit field containing the same sensor ID that would appear in field 341, and fields 347 through 349 are respectively a 3-bit field, a 7-bit field, and a 5-bit field that respectively containTEDS fields 1 through 3.Fields 346 through 349 together contain a total of 22 bits. -
FIG. 15 is a diagrammatic view of apayload 174B that is an alternative example of a payload that could appear as thepayload 174 of theextended services command 143A inFIG. 6 .Payload 174B contains a sensor-read-records command that does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols. Thepayload 174B includes fivefields 361 through 365. Thefirst field 361 is a 5-bit command field containing a unique code that identifies the sensor-read-records command. Thenext field 362 is a 7-bit field containing the unique sensor ID or port address of a particular sensor for which information is being requested. The interrogator will have previously obtained this unique sensor ID for each of the sensors, by using the read-sensor-identifier command ofFIG. 13 , in response to which it receives the IDs back in thefields 341 or 346 of the response shown inFIG. 14 . - The next field in the
payload 174B is a 4-bitmeasurement type field 363 that identifies the particular type of measurement information being requested. The permissible measurement type codes are identified in ISO 21451.7, and are therefore not all described in detail here. But by way of example, the interrogator could use themeasurement type field 363 to request (1) an average of the readings from the specified sensor, (2) the most recent reading from the specified sensor, (3) part or all of a log of a series of readings from the specified sensor, either with or without date and time information for each reading, or (4) other types of measurement information. This information is all maintained by the sensor application 72 ofFIG. 1 in thesensor data 77. - The
next field 364 is 16-bit field containing a numerical value specifying the number of the first record to be returned from the data maintained for the measurement type specified at 363. Thenext field 365 is an 8-bit field containing a numerical value specifying the number of records being requested. The interrogator might, for example, send a first sensor-read-records command in which thefield 364 specifiesrecord 1 and thefield 365requests 10 records. The sensor application 72 would then send back ten records. Theinterrogator 12 might then send a second sensor-read-records command in which thefield 364 specifiesrecord 11, and thefield 365 specifies 10 records. The sensor application 72 would then returnrecords 11 through 20. -
FIG. 16 is a diagrammatic view of apayload 184B that could appear as thepayload 184 in theextended services response 163A ofFIG. 7 . Thepayload 184B contains a sensor-read-records reply, which the sensor application 72 returns in response to receipt of a sensor-read-records command 174B (FIG. 15 ). The sensor-read-records reply in thepayload 184B ofFIG. 16 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols. - The
payload 184B includes six fields 371-376. Thefields fields payload 174B (FIG. 15 ). Thefield 372 is a 1-bit NAK field that will contain a binary “0” to indicate no error occurred. Thefield 375 will contain the requested data. Thefield 376 is a padding bits field, and will only be present where needed to ensure that the overall length of thepayload 184B is an integer number of bytes. -
FIG. 17 is a diagrammatic view of apayload 174C that is an example of still another payload that could appear at 174 in theextended services command 143A ofFIG. 6 . Thepayload 174C contains a read-all-sensor-status command, which is a request for the sensor application 72 to return status information regarding each sensor associated with thetag 11. The read-all-sensor-status command ofFIG. 17 does not exist under the current ISO 21451.7 protocol, but instead is an extension or enhancement that could be added to the 21451.7 protocol. This command has twofields field 401 is a 5-bit field containing a unique code that identifies this particular command. Thefield 402 is a 3-bit field of padding bits that contains a binary value of “000”, in order to give thepayload 174C an overall length of one byte. -
FIG. 18 is a diagrammatic view of apayload 184C that is a further example of a payload that could appear at 184 in theextended services response 163A ofFIG. 7 . Thepayload 184C is a read-all-sensor-status reply issued by the sensor application 72 after it receives the read-all-sensor-status command shown inFIG. 17 . The read-all-sensor-status reply ofFIG. 18 does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols. - The
payload 184C includesseveral fields 411 through 417. Thefield 411 is a 5-bit response field containing identically the same numerical code as thefield 401 in the command ofFIG. 17 . Thenext field 412 is a 1-bit NAK field containing a binary “0” to indicate that the sensor application 72 did not encounter any error in executing the command ofFIG. 17 . Thenext field 413 is a 4-bit field containing a numerical value identifying the total number of sensors associated with thetag 11. Thefield 413 is followed by somefields 414 through 416 that are each a 32-bit field containing status information for a respective one of the sensors associated with the tag. The number offields 414 through 416 is equal to the numerical value appearing in thefield 413. If the tag has no sensors, then thefield 413 will contain a value of zero, and none of thefields 414 through 416 will be present. Thelast field 417 contains six padding bits that are each a binary “0”, to ensure that the overall length of thepayload 184C is an integer number of bytes. - Each of the
fields 414 through 416 contains seven fields that are shown at 421 through 427. Thefield 421 is a 7-bit field containing the unique sensor ID or port address that was discussed earlier. Thenext field 422 is a 1-bit enabled status field that indicates whether the specified sensor is currently enabled or disabled. In this regard, theinterrogator 12 can send the sensor application 72 a command that identifies a particular sensor and indicates the sensor is to be enabled or disabled. The enabledstatus bit 422 indicates whether the sensor is currently enabled or disabled. - The
next field 423 is a 4-bit field reserved for future use. This is followed by a 12-bitsensor type field 424, which containsfields 1 through 3 of the TEDS for the specified sensor. Thenext field 425 is a 2-bit field reserved for future use. Thenext field 426 is a 2-bit alarms set field. One bit indicates whether or not monitoring is currently enabled for a lower threshold associated with the specified sensor, and the other bit indicates whether or not monitoring is currently enabled for an upper threshold associated with that sensor. - The
next field 427 is 4-bit alarms triggered field. One bit indicates whether or not an alarm has been triggered for the upper threshold. The next bit indicates whether an alarm has been triggered for the lower threshold. The next bit indicates whether, for any of the data logs maintained for that sensor, a memory full condition has been reached, and memory rollover has not been asserted (or is not possible to assert). The remaining bit indicates whether the specified sensor has flagged a low battery condition, based on criteria specified by the sensor manufacturer. Where a tag has multiple sensors supported by a single battery, such as thebattery 63 ofFIG. 1 , a low battery condition can cause multiple sensors to report a low battery status condition. -
FIG. 19 is a diagrammatic view of apayload 184D that is yet another example of a payload that can appear at 184 in theextended services response 163A ofFIG. 7 . Thepayload 184D contains an error reply that does not exist under either the current ISO 21451.7 protocol or the current IEEE 1451.7 protocol, but instead is an extension or enhancement that could be added to these protocols. More specifically, and as discussed earlier, the sensor application 72 may encounter some type of error in attempting to execute and respond to a command received from theinterrogator 12. For example, the interrogator may ask the sensor application 72 to return a specified number of data records of a data type for which the sensor application 72 currently has a smaller number of records. The sensor application 72 therefore needs to notify theinterrogator 12 that an error has occurred. Thepayload 184D ofFIG. 19 represents an error reply that the sensor application 72 can send to theinterrogator 12 to identify an error. - The
payload 184D includes fivefields 451 through 455. Thefield 451 is a 5-bit response field that contains identically the same value as the first field of the particular command that triggered the error. In other words, thefield 451 would contain the value from one of the field 321 (FIG. 13 ), the field 361 (FIG. 15 ), the field 401 (FIG. 17 ), or the command field in some other command that is not discussed here. Thenext field 452 is a 1-bit NAK field that contains a binary “1” to indicate an error has occurred. Assume for the sake of discussion that the sensor application 72 received the sensor-read-records command ofFIG. 15 . Theinterrogator 12 would receive back a response beginning with a 5-bit field containing the code fromfield 361 of the command, followed by the 1-bit NAK field. The interrogator would look at the first five bits of the response to identify the corresponding command, and would then look at the 1-bit NAK field to determine whether or not an error occurred. If the NAK bit is a binary “0”, then the interrogator knows that no error occurred, and that the NAK field will be followed by the four fields 371-376 shown inFIG. 16 . In contrast, if the 1-bit NAK field is a binary “1”, then the interrogator knows that an error occurred, and that the remainder of the message will be the three fields 453-455 shown inFIG. 19 . - In
FIG. 19 , theNAK field 452 is followed by a 6-biterror code field 453. This field contains a code or a numerical value that uniquely identifies the particular error encountered by the sensor application 72. Theerror code field 453 is followed by anoptional data field 454. Thedata field 454 may or may not be present, depending on the error code infield 453. That is, some error codes may be accompanied by related data that appears in thefield 454, while other error codes may have no need to return related data. As to errors that do return data in thefield 454, the size of the data field may vary from one type of error to another. Thelast field 455 is a padding bits field that may or may not be present. It will be included where necessary to ensure that the overall length of thepayload 184D is an integer number of bytes. - The foregoing discussion has given several specific examples of how the
interrogator 12 and sensor application 72 can communicate with each other using the payload 174 (FIG. 6 ) and the payload 184 (FIG. 7 ). Thepayloads interrogator 12 and any of the other extended services applications 81 (FIG. 1 ) that are present in thetag 11. The commands and replies discussed in association withFIGS. 13 through 19 are specific to the sensor application 72, and include some extensions or enhancements to the ISO 21451.7 and IEEE 1451.7 standards, which relate specifically to sensors. - As to communications between the
interrogator 12 and otherextended services applications 81, the manufacturer or author of eachextended services application 81, such as those shown at 73 to 75 inFIG. 1 , would define formats for commands and replies that are customized to suit the particular function and operation of that extended services application. It is not necessary to describe here in detail a separate command and reply structure for each of the extended services applications 73-75 inFIG. 1 . As discussed earlier, theextended services applications 81 inFIG. 1 are merely exemplary, and there are a variety of other extended services applications that could be implemented on thetag 11. - Although a selected embodiment has been illustrated and described in detail, it should be understood that a variety of substitutions and alterations are possible without departing from the spirit and scope of the present invention, as defined by the claims that follow.
Claims (30)
1. An apparatus comprising a radio frequency identification tag having a main section that provides basic radio frequency identification functionality, that has an extended services interface, and that receives wireless signals containing a message type which includes an extended services segment and which is an extension to an industry-standard communication protocol, said main section responding to receipt of a wireless signal containing a message conforming to said message type by transmitting said extended services segment thereof through said extended services interface.
2. An apparatus according to claim 1 , wherein said communication protocol is the ISO 18000-7 communication protocol.
3. An apparatus according to claim 1 , wherein said extended services segment is an extension to an industry-standard further communication protocol that is different from said communication protocol for said wireless signals.
4. An apparatus according to claim 3 , wherein said tag includes a further section that includes a sensor and that that receives said extended services segment from said main section through said extended services interface, said further communication protocol being one of the IEEE 1451.7 communication protocol and the ISO 21451.7 communication protocol.
5. An apparatus according to claim 1 , including a further section that provides extended services functionality different from said basic functionality, and that receives said extended services segment from said main section through said extended services interface.
6. An apparatus according to claim 5 , wherein said further section is part of said tag.
7. An apparatus according to claim 5 , wherein said further section is physically separate from said tag.
8. An apparatus according to claim 5 , wherein said extended services functionality includes provision of security for said tag.
9. An apparatus according to claim 5 , wherein said further section includes one of a sensor, a receiver circuit that receives wireless satellite signals containing positioning information, and a real time locating circuit.
10. An apparatus according to claim 5 , wherein said further section includes a plurality of sensors, and a single instantiation of an application that interfaces each of said sensors to said extended services interface, and that is compatible with and also implements an extension to one of IEEE 1451.7 and ISO 21451.7.
11. An apparatus according to claim 1 , wherein said main section responds to receipt through said extended services interface of a further segment by transmitting a further wireless signal that conforms to said communications protocol and that contains said further segment.
12. An apparatus comprising a radio frequency identification tag having a main section that provides basic radio frequency identification functionality, that has an extended services interface, and that receives wireless signals, said main section storing data that includes respective information regarding each extended service accessible through said extended services interface, and said main section responding to receipt of a wireless signal containing a selected command that is an extension to a command set of an industry-standard communication protocol by transmitting a further wireless signal containing a message that is an extension to said communication protocol and that contains at least part of said data.
13. An apparatus according to claim 12 , wherein said communication protocol is the ISO 18000-7 communication protocol.
14. An apparatus according to claim 12 , wherein said data includes a list identifying each extended service that is accessible through said extended services interface, said further wireless message including at least part of said list.
15. An apparatus according to claim 12 , wherein said data includes a list identifying each extended service that is accessible through said extended services interface and that currently has an active alarm condition, said further wireless message including at least part of said list.
16. An apparatus according to claim 12 , wherein said data includes, for each extended service that is accessible through said extended services interface, a respective segment containing information received through said extended services interface and relating to the corresponding extended service, said further wireless message including at least part of a respective said segment.
17. An apparatus according to claim 12 , including a further section that provides extended services functionality different from said basic functionality, and that is coupled to said extended services interface.
18. An apparatus according to claim 17 , wherein said further section is part of said tag.
19. An apparatus according to claim 17 , wherein said further section includes a portion that is physically separate from said tag.
20. An apparatus according to claim 17 , wherein said extended services functionality includes provision of security for said tag.
21. An apparatus according to claim 17 , wherein said further section includes one of a sensor, a receiver circuit that receives wireless satellite signals containing positioning information, and a real time locating circuit.
22. An apparatus according to claim 17 , wherein said further section includes a plurality of sensors, and a single instantiation of an application that interfaces each of said sensors to said extended services interface, that is compatible with one of IEEE 1451.7 and ISO 21451.7, and that implements an extension to said one of IEEE 1451.7 and ISO 21451.7.
23. An apparatus comprising a radio frequency identification tag having a section that sends and receives wireless signals and that has a multi-sensor interface, said section responding to receipt of a wireless signal containing a request by transmitting a further wireless signal containing information regarding multiple sensors.
24. An apparatus according to claim 23 , wherein said request and said information conform to an extension of an industry-standard sensor communication protocol.
25. An apparatus according to claim 24 , wherein said sensor communication protocol is one of IEEE 1451.7 and ISO 21451.7.
26. An apparatus according to claim 25 , wherein said section includes a single instantiation of a multi-sensor application that is coupled to said multi-sensor interface, that is compatible with one of IEEE 1451.7 and ISO 21451.7, and that implements an extension to said one of IEEE 1451.7 and ISO 21451.7.
27. An apparatus according to claim 23 , wherein said information in said further wireless signal includes an identification of each sensor.
28. An apparatus according to claim 23 , wherein said information in said further wireless signal includes status information regarding each sensor.
29. An apparatus according to claim 23 , wherein said tag includes a plurality of sensors, said section interacting with each said sensor through said interface.
30. An apparatus according to claim 23 , wherein said wireless signals conform to a communication protocol.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/045,120 US20140028446A1 (en) | 2009-05-29 | 2013-10-03 | Method and Apparatus for Tunneling Information in RFID Communications |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18244409P | 2009-05-29 | 2009-05-29 | |
US12/789,804 US8587431B2 (en) | 2009-05-29 | 2010-05-28 | Method and apparatus for tunneling information in RFID communications |
US14/045,120 US20140028446A1 (en) | 2009-05-29 | 2013-10-03 | Method and Apparatus for Tunneling Information in RFID Communications |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,804 Continuation US8587431B2 (en) | 2009-05-29 | 2010-05-28 | Method and apparatus for tunneling information in RFID communications |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140028446A1 true US20140028446A1 (en) | 2014-01-30 |
Family
ID=42647371
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,804 Active 2031-06-14 US8587431B2 (en) | 2009-05-29 | 2010-05-28 | Method and apparatus for tunneling information in RFID communications |
US14/045,120 Abandoned US20140028446A1 (en) | 2009-05-29 | 2013-10-03 | Method and Apparatus for Tunneling Information in RFID Communications |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/789,804 Active 2031-06-14 US8587431B2 (en) | 2009-05-29 | 2010-05-28 | Method and apparatus for tunneling information in RFID communications |
Country Status (4)
Country | Link |
---|---|
US (2) | US8587431B2 (en) |
EP (1) | EP2435951A2 (en) |
CN (1) | CN102460466A (en) |
WO (1) | WO2010138834A2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170097249A1 (en) * | 2015-06-24 | 2017-04-06 | Meggitt (Orange County), Inc. | Sensor and cable with local wireless read and write capability and methods of using same |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8588192B2 (en) * | 2010-01-27 | 2013-11-19 | Infosys Limited | System and method for forming application dependent dynamic data packet in wireless sensor networks |
US20130285795A1 (en) * | 2010-10-22 | 2013-10-31 | Juhani Virtanen | Advanced functionality of remote-access devices |
WO2012100147A1 (en) * | 2011-01-21 | 2012-07-26 | Blackbird Technology Holdings, Inc. | Method and apparatus for discovering people, products, and/or services via a localized wireless network |
CN103344181B (en) * | 2013-07-11 | 2016-01-13 | 上海大学 | System segment inside tunnel being positioned and automatically detects |
CN105631493B (en) * | 2014-11-06 | 2019-02-22 | 国家电网公司 | A kind of method of automatic identification mutual inductor identity |
US10520577B2 (en) * | 2017-11-29 | 2019-12-31 | Steel Shad Fishing Company LLC | Methods and devices for determining and saving location information |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7044387B2 (en) * | 2002-09-05 | 2006-05-16 | Honeywell International Inc. | RFID tag and communication protocol for long range tag communications and power efficiency |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7394381B2 (en) * | 2004-05-06 | 2008-07-01 | Ut-Battelle, Llc | Marine asset security and tracking (MAST) system |
US7339469B2 (en) * | 2004-11-22 | 2008-03-04 | Maersk Logistics Usa, Inc. | Shipping container monitoring and tracking system |
WO2007076095A2 (en) * | 2005-12-22 | 2007-07-05 | Axcess International Inc. | Hybrid radio frequency identification (rfid) tag system |
US7434731B2 (en) * | 2006-05-11 | 2008-10-14 | Savi Technology, Inc. | Method and apparatus for efficient data transmission from a tag |
JP2008085649A (en) * | 2006-09-27 | 2008-04-10 | Toshiba Corp | Rfid communication system and method |
JP5198802B2 (en) * | 2007-06-08 | 2013-05-15 | 沖電気工業株式会社 | Wireless tag communication system, wireless tag access device, compatible wireless tag detection method, and compatible wireless tag detection program |
-
2010
- 2010-05-28 EP EP10728952A patent/EP2435951A2/en not_active Withdrawn
- 2010-05-28 WO PCT/US2010/036605 patent/WO2010138834A2/en active Application Filing
- 2010-05-28 US US12/789,804 patent/US8587431B2/en active Active
- 2010-05-28 CN CN2010800301475A patent/CN102460466A/en active Pending
-
2013
- 2013-10-03 US US14/045,120 patent/US20140028446A1/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7044387B2 (en) * | 2002-09-05 | 2006-05-16 | Honeywell International Inc. | RFID tag and communication protocol for long range tag communications and power efficiency |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170097249A1 (en) * | 2015-06-24 | 2017-04-06 | Meggitt (Orange County), Inc. | Sensor and cable with local wireless read and write capability and methods of using same |
Also Published As
Publication number | Publication date |
---|---|
WO2010138834A3 (en) | 2011-03-31 |
US8587431B2 (en) | 2013-11-19 |
WO2010138834A2 (en) | 2010-12-02 |
US20100302037A1 (en) | 2010-12-02 |
CN102460466A (en) | 2012-05-16 |
EP2435951A2 (en) | 2012-04-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20140028446A1 (en) | Method and Apparatus for Tunneling Information in RFID Communications | |
JP4107966B2 (en) | Signaling system and transponder for the system | |
US7071825B2 (en) | Self-monitored active rack | |
US7333479B2 (en) | RFID system with packetized data storage in a mobile environment: methods, systems and program products | |
US8570172B2 (en) | RFID system with distributed transmitters | |
US6972682B2 (en) | Monitoring and tracking of assets by utilizing wireless communications | |
US8761706B2 (en) | Passive RF devices that communicate using a wireless network protocol | |
US20080150698A1 (en) | Radio frequency identification tag with passive and active features | |
US8436716B2 (en) | Method of upgrading an operation program of a radio frequency identification system | |
US20120075073A1 (en) | Rfid reader device | |
JP4984774B2 (en) | RF tag reader and retransmission control method | |
US8830064B1 (en) | Run commands for RFID tags | |
CN101796528A (en) | Backscatter limited tags | |
US9104923B1 (en) | Encapsulating commands for RFID tags and RFID readers | |
US8830038B1 (en) | Encapsulating commands for RFID tags | |
EP3387581A1 (en) | Systems and methods for a cloud connected transponder | |
JP4964567B2 (en) | Wireless communication device | |
US8779896B2 (en) | RFID reader and method for controlling gain thereof | |
KR20170054652A (en) | Delivery information transmission system for parcel or postal matter | |
CN111444735B (en) | Code scanning identification method and system for a large number of articles in short time | |
US20080186144A1 (en) | Method for the at least temporary activation of bidirectional communication and transponder | |
KR101131461B1 (en) | Method for matcing active rfid reader of simple reader protocol | |
KR20100118674A (en) | Frequency bandwidth free rfid system | |
JP2005293518A (en) | Interrogator for wireless tag communications system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |