Patent Application
20110074552
1. Technical Field
Embodiments of the present invention relate to communications in low-power wireless applications.
2. Description of the Related Arts
Low-power wireless devices such as, for example, radio frequency (RF) tags have been in use for some time. Radio-frequency identification (RFID) systems typically include interrogators that communicate with tags. Tags are typically attached to an article such as a shipping container or a package that is being shipped. The interrogator, then, can inventory the articles that are within its range.
Generally, an RFID tag system will include a number of tags that are attached to an asset such as a piece of inventory or a shipping asset. RFID tags include a transceiver to transmit and receive signals as well as a processor to process incoming signals from an interrogator and provide responses to the interrogator. As such, an interrogator can poll the tags that are within its range. The interrogator, then, can monitor tags as they arrive or leave an area of interest. The reader, then, periodically polls the tags within its range. Alternatively, tags can be monitored as they transit a particular area. The bandwidth of the interrogator and its range limits the number of tags that can be monitored by any given reader.
Additionally, tags have limited power sources. Active tags are typically powered by a battery, which may be depleted with frequent use. To solve this problem, tags can have active and inactive modes of operation. Therefore, tags need to operate in a power efficient and power saving mode. Some current interrogator and tag systems conform to ISO 18000-7, referred to as Mode 1 tags. However, there is a limit to the capabilities of such a system.
Therefore, what is needed is a communication system that preserves the power in a low-power device while providing for monitor of a high number of such devices.
In accordance with the present invention, a device can include a memory capable of storing data and program instructions; a processor coupled to the memory; and a transceiver coupled to the processor to receive digital data and control signals, the control signals including a transport channel signal, the transceiver coupled to transmit data over one or more transport channels, the transport channels being defined as a combination of one or more physical channels chosen from a plurality of physical channels. A method of communicating with another device according to some embodiments includes defining one or more transport channels as combinations of a plurality of physical channels; and transmitting or receiving signals on the one or more transport channels.
A device according to some embodiments may include a transceiver capable of communicating wirelessly with other devices; a processor coupled to a memory and to the transceiver, the processor operating such that the device is in one of one or more regimes, the one or more regimes chosen from a group consisting of a gateway regime, a subcontroller regime, and an endpoint regime. A method of operating a low power device according to some embodiments of the present invention includes operating in one of one or more regimes, the one or more regimes chosen from the group consisting of a gateway regime, a subcontroller regime, and an endpoint regime.
A device according to some embodiments can include a processor coupled to a memory; and a transceiver coupled to the processor, wherein the device wirelessly communicates with other devices utilizing packets, wherein each of the packets includes a preamble, a header that includes a sync and a frame info, and a frame. A method of communicating with a device includes exchanging packets from the device, the packet including a preamble, a header that includes a sync and frame info, and a frame.
A device according to some embodiments can include a processor coupled to a memory; and a transceiver coupled to the processor, wherein the device wirelessly communicates with other devices utilizing packets, wherein each of the packets includes a preamble, a header that includes a sync and a frame info, and a frame, the packets being characterized as a request packet that includes a request frame, a response packet that includes a response frame, or a data packet that includes one or more data frames.
A device according to some embodiments can include a processor; a memory coupled to the processor, wherein the memory stores data elements and programming; and a transceiver coupled to the processor, the transceiver allowing wireless communications with one or more other devices.
A device according to some embodiments can include a processor coupled to a memory; a transceiver that wirelessly communicates with one or more other devices, wherein the device transmits and receives packets that include frames to the one or more other devices, the frames including request frames or response frames and that include: a header that includes a protocol ID, a frame length, device flags, and a session ID; a command code that includes an extension flag, a sleep flag, a routing type, and an opcode; and a routing template consistent with the routing type.
A method of activating a RFID device from a sleep state according to some embodiments includes receiving a wake-on signal on a wake-on radio; transitioning the RFID device to a listen state or a transmit state in response to the wake-on signal.
A method of activating an RFID device from a hold state according to some embodiments of the invention includes transitioning to a listen state if the hold state is asynchronous and a previous state was a transmit or receive state; transitioning to an idle state if the hold state is asynchronous and the previous state was a listen state; transitioning to a listen state if the hold state is asynchronous and a timeout condition has occurred or transitions to an idle state if the hold state is synchronous and the timeout condition has occurred; transitioning to a transmit state if a hold period has expired and the hold state is synchronous; and transitioning to a listen state if a hold period has expired and a wake-up frame is detected.
A method of performing a dialog between a requesting RFID device and one or more responding RFID devices according to some embodiments of the invention includes the requesting RFID device providing a chain of wake-up packets and transmitting a request frame in a request packet on one of a plurality of transport channels; the responding RFID devices activating upon receipt of a wake-up frame from the chain of wake-up packets and receiving the request packet; the responding RFID devices each transmitting a response packet to the requesting RFID device.
A method of receiving data from a responding device according to some embodiments includes sending a request frame to the responding device; receiving a response frame from the responding device; receiving one or more data frames from the responding device; and acknowledging receipt of the one or more data frames.
A method of transmitting data to a responding device according to some embodiments includes sending a request frame to the responding device; receiving a response frame from the responding device; sending one or more data frames to the responding device; and receiving an acknowledgement from the responding device.
These and other embodiments are further described below with reference to the following figures.
a) illustrates an RFID system according to some embodiments of the present invention.
b) illustrates RFID devices as shown in
a) illustrates an embodiment of a state diagram associated with operation of a hold state according to some embodiments of the present invention.
b) and 8(c) illustrate embodiments of state diagrams illustrating operation of a wakeup operation according to some embodiments of the present invention.
a) through 20(d) illustrate dialog routing types according to some embodiments of the present invention.
e) and 20(f) illustrate an extended dialog with unicast and multicast routing, respectively.
a) illustrates a request and response frame according to some embodiments of the present invention.
b) illustrates an error response frame according to some embodiments of the present invention.
c) illustrates a data frame according to some embodiments of the present invention.
d) illustrates an embodiment of a mode 2 frame protocol header.
e) illustrates an embodiment of a mode 2 frame protocol command code.
f) illustrates an embodiment of a command extension byte for a mode 2 frame protocol command code.
a) and 22(b) illustrate embodiments of a broadcast request template and broadcast response template, respectively.
a) and 23(b) illustrate embodiments of a unicast request template and a unicast response template, respectively.
a) and 24(b) illustrate embodiments of a multicast initial request template and a multicast arbitration request template, respectively.
a) and 25(b) illustrate embodiments of an anycast request template and an anycast response template, respectively.
a) and 26(b) illustrate embodiments of an inventory from device ID request and response, respectively.
a) and 27(b) illustrate embodiments of an inventory from UDB element request and response, respectively.
a) and 28(b) illustrate embodiments of a collection of UDB element request and response, respectively.
a) and 29(b) illustrate embodiments of a collection of UDB type request and response, respectively.
a), 30(b), and 30(c) illustrate embodiments of an announcement of UDB element request, an announcement of UDB type request, and an announcement response, respectively.
a) and 31(b) illustrate embodiments of a request data frame and a propose data frame dialog sequence, respectively.
c) illustrates an embodiment of a state diagram of a data frame dialog.
a) and 32(b) illustrate embodiments of a request data frame and a corresponding response frame, respectively.
c) and 32(d) illustrate embodiments of a propose data frame and a corresponding response frame, respectively.
e) and 32(f) illustrate embodiments of an acknowledge data frame and a corresponding response frame, respectively.
a) and 33(b) illustrate embodiments an authentication frame and a corresponding response frame, respectively.
a) and 34(b) illustrate embodiments of an encapsulated UDB protocol command structure and an encapsulated UDB protocol response, respectively.
a), 35(b), and 35(c) illustrate embodiments of an UDB element data group, an UDB type data group, and an UDB privileges data group, respectively.
a), 36(b), and 36(c) illustrate embodiments of an encapsulated RDB protocol command structure sector access request, an encapsulated protocol command structure for a privilege code request, and a corresponding response, respectively.
a) and 37(b) illustrate embodiments of an RDB element data group and an RDB privileges data group, respectively.
In the figures, elements given the same designation have the same or similar functions.
The figures and the following description relate to some embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of the embodiments described herein.
a) illustrates a RFID system 100 according to some embodiments of the present invention. As shown in
Although specific examples of aspects of system 100 and of devices 110 are provided below, specific examples are provided only to facilitate better understanding of aspects of the present invention. It is to be understood that other arrangements than those specifically described can be implemented while remaining within the scope of this disclosure.
In general, devices 110 in system 100 can be described in terms of a Physical Layer (the PHY layer) that is controlled according to certain protocols by a Media Access Control layer (the MAC layer). The PHY layer enables the transmission of data bits over the radio frequency band, and describes the actual hardware and functioning of each of devices 110. The MAC layer describes the controls of the PHY layer, enables multiple devices and functions to share the same PHY layer, and typically is embodied in software that is executed by a processor on device 110. In addition to the PHY layer and the MAC layer, system 100 is further described in terms of data elements and protocols that are supported by devices 110.
In the PHY layer, some embodiments of the present invention operate within the 433.05 to 434.79 MHz band corresponding to the ISM Region 1 band and the FCC band. In some embodiments, a dynamic transport channel system utilizing a plurality of physical channels help to increase throughput and allow the inclusion of more devices 110 in system 100. The operating band can be sliced into smaller physical channels. For example, the ISM Region 1 band can be partitioned into a plurality, for example 6 or 8, physical channels. A transport channel refers to a combination of one or more physical channels utilize to carry data. Multiple physical channels can be combined into a transport channel in order to achieve higher data rates.
Modulation schemes that result in small side lobes and good detectability can be utilized. For example, some embodiments of the present invention can utilize a filtered frequency shift keying modulation (FSK), for example Gaussian FSK (GFSK). Other modulation such as amplitude shift keying (ASK), and minimum shift keying (MSK) can be utilized. Small sidelobes are important for systems that utilize multiple transport channels.
Processor 214 may also be coupled to a user interface 220 or an external interface 212. User interface 220 may provide visual and audio signals to a user that convey information regarding the status of reader 120, the presence of devices 110, or the contents of data received from devices 110. External interface 212 can be coupled to another device in order to download data stored in memory 210, provide data that is to be uploaded to one or more of devices 110, update programming of processor 214, or otherwise reconfigure reader 120. Reader 120 is powered by power source 222, which can be a battery in the case of a handheld device or may be a coupling to an external power source such as a stationary reader.
Several modes of operation can be utilized for communications between reader 120 and devices 110. For example, normal and turbo modes can be utilized. In FSK modulation, the frequency difference Δf between the higher and lower frequencies is related to the bit rate that is transmitted by the band. In general, Δf=β(Bit_Rate) where β is the modulation index. In general, larger β results in much lower bit-error rates (BER). However, lower β results in the ability to transmit much higher Bit-Rates for a given frequency deviation. As an example, in some embodiments in normal mode the modulation index can be about 1.8, while in turbo mode the modulation index can be about 0.5. The operative lower limit for β is 0.5, resulting in noisy transmission of data with a resulting high BER. Tables 1 and 2 below provide some example performance parameters for particular examples of normal and turbo mode operation according to some embodiments of the present invention.
A modulation index β=1.8 can have unique properties that give it the advantage of both narrow band and wideband FSK. Such a modulation has been utilized successfully for satellite communications where low power and long range are important objectives. The modulation index β=0.5 is a narrowband FSK that can be prone to interference, but allows for the maximum speed available. MSK modulation may do a bit better than FSK with modulation index β=0.5, about a 230 data rate, but may not be a great improvement.
As is further shown in
As discussed above, filtered FSK modulation is beneficial because it is similar to more conventional systems, or legacy systems. At 55.55 kcps, with modulation index of 1.8, the signal fits within a 216 kHz band and has good wide-band attributes. At 200 kcps, with modulation index of 0.5, the signal fits within a 432 kHz band, which is two adjacent 216 kHz bands. Further, Gaussian filter FSK (GFSK) is attractive because it is inexpensive to implement. In some embodiments, the particular modulation utilize in a given dialog may be dynamically chosen in device 110.
However, other modulations can be utilized, as discussed above. ASK utilizes a higher transmission power and does not offer a signal-to-noise ratio (SNR) as attractive as FSK, but is also rather inexpensive to implement. MSK is similar to GFSK with modulation index of 0.5, but has reduced inter-symbol interference. MSK modulation has slightly better stop-band attenuation as well. However, MSK has a higher complexity.
Quadrature phase shift keying (QPSK) may also be utilized and has a higher SNR and bandwidth efficiency than GFSK or MSK. However, QPSK has large sidelobes in the power distribution and is relatively costly to implement in terms of receive and transmit power.
In some embodiments, a single chip rate per packet can be utilized. In some embodiments, an encoding scheme is implemented in encoder 404. For example, encoder 404 may implement forward error coding (FEC) or PN9 data whitening. FEC and PN9 encoding may result in better coding gain than Manchester encoding in some embodiments, however some embodiments may utilize Manchester encoding, NRZ encoding, or 8b10b encoding. In some embodiments, an adaptive data rate can be utilized. For example, a single physical channel may be utilized for long range transport with high reliability while a double channel may be utilized for high speed short range. Encoding and adaptive data rate can allow better system performance for long and short range applications.
In transmit mode, transmit/receive 402 provides digital data to encoder/modulator 404. Encoder/modulator 404 then provides data to transmitter 406. Transmitter 406 provides signals that are transmitted through antenna 412.
In receive mode, signals from antenna 412 are provided to receiver 410, which provides data to demodulator/decoder 408. Demodulator/decoder 408 then provides the received digital data to transmit/receive 402 after performing a decoding process appropriate for the encoding performed in encoder/modulator 404.
The functions of transceiver 400 can be performed in software, hardware, or a combination of software and hardware. In some embodiments, transceiver 400 may include a separate processor to perform some of the functions of transceiver 400. In other embodiments, the same processor that controls the remainder of the device can also perform functions for transceiver 400. For example, in device 110 shown in
Transmitter 406 may utilize a number of physical channels to transmit signals through antenna 412. Table 3, for example, provides for eight physical channels in a 1.728 MHz range within the 433 MHz ISM band. The eight physical bands are each 216 kHz in width. The overall scope of the allowable frequency bands as well as the channels themselves may be regulated by different regulatory bodies. In general, any number of bands utilizing any range of frequencies can be utilized. Table 4 illustrates another allocation of physical bands in the 433 MHz ISM band. In the embodiment illustrated in
In addition to the physical channels, transmitter 406 and receiver 410 receive a signal Bandwidth Control that indicates a transport channel to be utilized. A transport channel is assigned the spectrum of one or more physical channels. A transport channel that utilizes more than one physical channel can support higher data rate than one that utilizes a single physical channel. Different transport channels can also support different modulation and coding schemes. As examples of the definition of transport channels with respect to physical channels, Table 5 defines a set of transport channels utilizing the physical channels defined in Table 3 and Table 6 defines a set of transport channels utilizing the physical channels defined in Table 4. In a transport of sequential messages, any transport channel can be utilized sequentially. For example, Transport channels 01 and 02 as defined in Table 5 may be utilized sequentially with transport channel 09.
In each definition of transport channel, the center frequency of the transport channel is the average frequency: (upper frequency of the highest physical channel+lower frequency of the lowest physical channel)/2. In some embodiments, use of channel 00 in a definition such as that provided in Table 5 may be avoided due to its overlap with transport channels 0C and 10. In some regulatory environments, usage of the band may be restricted, for example use of the 433 band may be restricted to a narrow area around 433.920 MHz, in which case the 00 transport channel may be utilized. In such cases, the outer regions of the 00 band may not be utilized. Despite the logical channel boundaries, power spectral density of normal transmitters may fall off considerably beyond about 70 kHz from the center frequency. As a result, the regulatory environments may be readily accommodated.
In some embodiments, one or more transport channels may be utilized to enable co-existence of legacy network channels. As such, in some embodiments systems may be able to utilize devices (e.g., tags) or readers that conform to earlier standards. Turbo modulation, such as that defined with respect to Table 2, for example, may utilize the larger bandwidth available with utilizing two adjacent physical channels.
In other words, the 433 MHz band can be sliced into physical channels. Each slice can be of an arbitrary width. As illustrated in Table 3, for example, the slices can be 216 kHz each, although Table 4 illustrates a system of physical channels each 290 kHz wide. Transport channels are defined in terms of combinations of physical channels. The transport channels are assigned identification codes, that can be utilized to support the communications throughout system 100. Each transport channel defined, and assigned an identification code, has a particular bandwidth, at a particular center frequency, and can support a particular transmission data rate. As discussed, some embodiments of the invention support multiple transport channels. In some embodiments, system 100 can be compatible with older systems that do not support multiple transport channels.
A physical channel bandwidth of 216 kHz is likely sufficient channel width for conducting, for example, a 55.55 kcps communication without adding too much interference in adjacent channels. Larger bandwidths can be achieved by defining transport channels to combine physical channels. Further, physical channels can be combined to provide for transport channels of larger bandwidth. Additionally, if other data rates (higher or lower) are sought, then the physical channel bandwidths and the transport channel definitions can be chosen accordingly.
As is further illustrated in
As described above, transport channels can be formed by single physical channels or by combining the bandwidth of two or more adjacent physical channels. Each of Tables 5 and 6 define transport channels with respect to single physical channels or by combinations of the bandwidths of adjacent physical channels. In some embodiments, physical channels can be defined by arbitrary combinations of physical channels. In such system, data may be transported in parallel fashion amongst the physical channels in a transport channel. In those embodiments, data is split into multiple data streams by the MAC layer and are sent amongst two or more physical channels and bonded. Transmitter 406, then, simultaneously transmits multiple physical layer signals that are coordinated with one another. In receiving such a transport channel, receiver 410 receives the multiple signals and demodulator/decoder 408 recovers the multiple data streams. Transmit/receive 402 then passes the multiple data streams to the MAC layer, which reconstructs the original data by combining the multiple data streams. Transmission of bonded data over a multiple of parallel channels includes splitting the received digital data amongst the parallel channels and transmitting the data on the channels. Receipt of a bonded set of parallel transported data over multiple physical channels includes, for example, receiving and recovering the digital data in each channel and reconstructing the original data from the recovered data.
As discussed above, there may be any number of physical channels. A set of transport channels can be defined based on defined combinations of the physical channels. There can be any number of transport channels, each with individual definitions of combinations of the available defined physical channels. For example, utilizing eight physical channels as shown in Table 3, seventeen transport channels can be defined as in Table 5. Other combinations may be added to the definitions in Table 5. As further shown in Tables 5 and 6, individual definitions of transport channels can be designated utilizing a hexadecimal transport channel identification, that can be set by the processor prior to transmission or receipt of a message and received by transmitter 406 and receiver 410. In tables 5 and 6, the transport channel ID is designated in hexadecimal notation.
Each frame of data that is transmitted can be encoded before transmission in encoder/modulator 404. Encoder/modulator 404 may include a number of supported encoding methods. In some embodiments, device 110 may dynamically select a particular encoding method from a list of supported coding methods.
In some embodiments, encoder/modulator 404 can include an encoding mechanism to support forward error correction (FEC), an example of which is shown in
Such a ½ rate convolutional code encoder 606 with interleaver 612 can provide a 5+dB SNR gain, which yields an industry-leading signal robustness. This encoder design provides a data rate of 27.77 kbps with low bit error rate. Interleaver 612 can protect against bursty bit errors caused by signal fading. Further, FEC codes are widely supported.
When receiving a data bit stream that has been encoded with a FEC encoder such as FEC encoder 600 shown in
In some embodiments, encoder/modulator 404 may also implement techniques to randomize data in order to reduce the DC bias of the data frame, such as, for example, data whitening.
Upon receipt of a data stream that has been whitened as shown in
Other encoders that may be utilized include Manchester encoding, Block coding, Reed-Solomon encoding, and Turbo Codes. However, FEC 600 provides better error coding gain than does Manchester coding. Error correction encoding increases signal robustness by introducing redundancies into the data stream at the transmitter, which enables the correction of erroneous data bits at the receiver. Such encoding increases the chance that a given message is error free. Such coding can be complicated in implementation, but modern chips are highly sophisticated.
In a comparison of ½ rate FEC encoding, full rate encoding (NRZ), and Manchester encoding, the ½ rate FEC encoding performed very well. As discussed above with respect to
The physical system described above can be controlled by a media access control (MAC) layer. The MAC layer can include functions and methodologies operating on devices 110 for data frame structuring, data encoding, collision avoidance, channel state monitoring, frame ordering, and frame routing. As such, the MAC features define the network architecture. Some communications options include, for example, a wake-on radio, carrier sense multiple access (CSMA) unsolicited beaconing (ACK or non-ACK), asynchronous collection of data, and synchronized slotted access (guaranteed time slots for communications between devices). Synchronized access is useful when communications between devices 110 has a high level of predictability.
The wake-on radio includes not just wake-up packet polling, but sensor alarms, scheduled wake-ups, and other forms of signaling a device 110 to wakeup. A wake-on radio is useful because an arbitrarily large number of devices can be present without utilizing a transport channel. Wake-on options also provide for low power optimizations for devices 110. Typically, device 110 transmits or receives packets after a wake-on event has occurred. A wake-on event can include sensor alarms, passive RFID message reception, active RF wakeups, or real-time scheduling via some protocol. As discussed in further detail below, an active RF wakeup involves device 110 periodically scanning transport channels to detect a wakeup packet. The advantages of an active wakeup process is that it allows devices 110 to spend as much time as possible in a low power state (e.g., sleep state or hold state), utilizing asynchronous request-response abilities are applicable to chaotic environments where synchronization is not possible or is impractical, and further asynchronous communications provide for deterministic worst case latency.
Devices 110 communicate with one another by exchanging packets of data that includes frame data. Several types of frames can be defined, including wakeup frames, request frames, response frames, and data frames. The receipt of wakeup frames is one of the wake-on radio modes that causes device 110 to become active. Packet types can be defined in terms of the payload frame data type included in the packet. Each of these frames are described in further detail below.
In some embodiments devices such as each of devices 110 and reader 120 as shown in
The various regimes can include, for example, an endpoint regime (similar to a tag), a subcontroller regime (operationally between a reader and a tag), a gateway regime (similar to a reader), and a master gateway regime (similar to a fixed reader that simultaneously monitors a number of transport channels). This allows various network topologies to be supported. For example, a star topology can include devices 110 in gateway regime and endpoint regime. A tree topology can be formed from devices 110 operating in gateway regimes, subcontroller regime, and endpoint regime. Further, a mesh topology can be formed with devices 110 operating in gateway regime and subcontroller regime. Utilizing a tree topology, for example, the range of a device 110 operating in a gateway regime can be greatly extended. Other regimes may also be defined for operation of the devices identified in
A device 110 that operates in an endpoint regime can be similar to that of a traditional tag. In the endpoint regime, device 110 spends most of its time in a low-power state. Once device 110 receives a wake-up event, it engages in a process of requesting reception and, usually, provides a response transmission.
A device 110 that operates in a subcontroller regime includes some of the functionality of both a traditional interrogator and a traditional tag. If device 110 is operating in the subcontroller regime, it can open and maintain a dialog with a device in the endpoint regime or other devices in the subcontroller regime. In some embodiments, if device 110 includes a subcontroller regime, then device 110 is also capable of operating in an endpoint regime.
A device 110 operating in a gateway regime includes much of the functionality of a reader and can behave much like a base-station. In
b) illustrates RFID system 100 with various ones of devices 110 operating in endpoint regime (designated E), subcontroller regime (designated S), and gateway regime, designated by device 120. There can be any number of devices 110 operating in any of the regimes.
As is further shown, device 110 operating in subcontroller regime can initiate dialogs between devices 110 operating either in the subcontroller regime or in the endpoint regime. Dialog 130 illustrates a dialog between two devices 110 each operating in subcontroller regime. Similarly, dialogs 142, 144, and 150 illustrate dialogs between devices 110 operating in subcontroller regime. Dialogs 134, 146, and 148 all illustrate dialogs operating between one device 110 operating in a subcontroller regime and one device 110 operating in an endpoint regime.
As shown in
This type of processing, where requests and responses are routed through one or more third devices 110, can be referred to as multi-hop routing. In general, only devices 110 operating the subcontroller regime or the gateway regime can engage in the forwarding of data packets involved in multi-hop routing. Devices 110 that are in the endpoint regime can not forward packets.
As such, the operable range of gateway 120 to poll devices 110 can be greatly extended by the array of devices operating in subcontroller regime relaying requests and responses. This relaying can be referred to as hopping.
Further, a star topology is illustrated by dialogs 138, 140, and 136 where device 120 is communicating with others of devices 110. A tree topology is formed with dialogs 140, 142, and 144 where device 110 at the end of dialog 144 also engages in dialogs 146, 150, and 148. Further, a mesh topology is shown with dialogs 150, 144, and 142, for example.
In addition to the various regimes of operation, each of devices 110 supports various states of operation. For example, each device 110 can support states that include an off state, a sleep state, a listen state, a receive state, a transmit state, and a hold state. A device 110 can transition between states based on the condition of an external trigger (for example a sensor interrupt). Transitions between states are governed by the definition of the particular regime in which device 110 is operating.
In the off state, device 110 is not utilizing any of its components to receive or transmit a signal in any way. The off state is included in each regime. Device 110 transitions from the off state by an external trigger that is independent of the signals sent by the RFID system itself. The external trigger can be, for example, physically turning on a power switch or installing a battery.
In some embodiments, an idle state may be defined as the base state for a particular regime. In the endpoint regime, for example, the base state may be a sleep state. In the subcontroller regime, the base state may be a hold state. In the gateway regime, the base state may be a listen state.
In the sleep state, device 110 periodically monitors the channel space for a wake-up frame. While in the sleep state, all active transport channels may be monitored for wake-up frames at least once every sleep-scan period (SSP). The SSP can be any time frame, for example 2 to 3 seconds. In some embodiments, an SSP for a particular device 110 can be set to a default, for example 2.4 seconds. If a wake-up frame is detected, device 110 can transition a listen state. If a wake-up frame is not detected, then device 110 remains in the sleep state. If there are multiple active transport channels, in some embodiments device 110 may monitor one of the active channels each time that it wakes, and should monitor all of the active channels within the SSP. In which case, device 110 may wake up periodically within the SSP in order to successively check the active channels.
In the listen state, device 110 monitors one of the active channels for a request frame. In some embodiments, there may be a time-out period, referred to as the Maximum Guard Time (MGT), after which device 110 returns to an idle state. In some cases, the MGT may be very large or device 110 may remain in the listen state indefinitely. Otherwise, device 110 receives a Request Frame Sync Word and enters the Receive State.
In the receive state, device 110 actively receives and stores the signal on the selected transport channel. In some embodiments, or some regimes of operation, device 110 may remain in receive state for an arbitrarily long time. In some embodiments, or some regimes of operation, device 110 can transition from the receive state to the listen state, the transmit state, the sleep state, or the hold state after a successful reception of a packet.
In a transmit state, device 110 is involved in sending a Request, Response, or Data Frame. Before actually transmitting data, device 110 engages in collision avoidance. Collision avoidance may include, for example, non-arbitrated CSMA and arbitrated CSMA, which is described in further detail below. The transmit state may follow any prior state, but typically follows the Receive State after reception of a Request, Response, or Data Frame.
The hold state is similar to the sleep state but can result in lower latency channel access. Device 110 may enter the hold state after a successful dialog has transpired. The hold state may also provide a momentary period during which a device that is normally in an endpoint regime can seamlessly transition to a subcontroller regime. The network structure and order of communications may remain unaffected by the switchover if handled during a hold state.
The hold state can have two substates, asynchronous or synchronous. Which of the two substates to utilize depends on the device regime or on the protocol that is in use. The asynchronous hold state is almost identical with the sleep state, except that it may use a different set of channel scan parameters than does the sleep state. Typically, the asynchronous hold state scan period is shorter and scans fewer transport channels than does the sleep state. If the asynchronous hold state is entered from another state than the hold state, device 110 will immediately enter the listen state for a period of one MGT. Upon re-entry from listen, the scan periods begin. The hold scan period (HSP) is configurable and can be set to any time. For example, HSP can be set to a nominal value, for example 72 ms. In the endpoint regime, the asynchronous hold state can time out in a long time, for example 28.8 seconds. After the hold state times out, in the endpoint regime device 110 enters the sleep state. In the subcontroller regime, there is no time-out and therefore the asynchronous hold state effectively replaces the sleep state.
In a synchronous hold state, device 110 is expected to begin a discrete time-slotting process. The “number of slots” parameter can be communicated per a request according to the protocol. The value of a virtual ID (VID) of device 110 can be used to determine the slot that that device 110 utilizes to transmit a response. If no VID is defined, then device 110 may ignore the request. In some embodiments, a hashing algorithm can be utilized in circumstances where the number of devices in the population is greater than the number of slots allowed in the hold period. In some embodiments, the hold period times out when all slots have expired. When the hold period times-out, the device can enter the listen state for a period of one MGT.
a) illustrates an example of an operation of a hold state transition 800 according to some embodiments of the present invention. As discussed above, the hold state can be a complicated state and is available in the endpoint and the subcontroller regimes. From hold state 802, device 110 transitions to step 804. In step 804, if the previous state was a receive or a transmit state, then device 110 transitions to step 806. In step 806, if the hold state is an asynchronous hold state, then device 110 transitions to listen state 808. If the previous state is not a receive or transmit state or if the hold state is a synchronous hold state, then device 110 transitions to step 810. In step 810, if the previous state was a listen state then device 110 transitions to step 812. In step 812, if the hold state is a synchronous hold state, the device 110 transitions to idle state 814. Idle state 814 corresponds to a sleep state in the endpoint regime and the asynchronous hold state in the subcontroller regime.
If the previous state was not a listen state or the hold state is an asynchronous hold state, then device 110 transitions to step 816. In step 816, if the hold state has timed out then device 110 transitions to step 818. In step 818, if the hold state is a synchronous hold state then device 110 transitions to a listen state. In step 818, if the hold state is an asynchronous hold state then device 110 transitions to an idle state. In step 816, if there is no timeout, then device 110 proceeds to step 822. In step 822, if the hold period has expired, then device 110 returns to step 818. If the hold period has not expired, then device 110 proceeds to step 826. In step 826, if the hold state is a synchronous hold state then device 110 transitions to transmit state 828. However, if the hold state is an asynchronous state, then device 110 proceeds to step 830. In step 830, if a wake-up is detected, then device 110 transitions to listen state 832. Otherwise, device 110 returns to state 802.
From receive state 906, transition 6 illustrates that device 110 transitions to sleep state 902, which occurs when an incoming request frame instructs device 110 to sleep and not form a response. Transition 7 illustrates that device 110 can transition from receive 906 to listen 904, which occurs when the incoming response frame leads to an incoming data frame. Transition 8 shows that device 110 can transition from receive 906 to transmit 908, which occurs when the incoming request frame leads to an outgoing response frame.
From transmit state 908, transition 9 shows that device 110 can transition to listen state 904, which occurs when the outgoing response frame leads to a subsequent incoming data frame. In transition 10, device 110 can transition from transmit 908 to sleep 902, which occurs when the incoming request frame includes instructions for device 110 to sleep followings its transmission of a response frame. As illustrated in transition 11, device 110 can transition from transmit state 908 back to transmit state 908, which occurs if the outgoing data frame is followed by an outgoing response frame. As illustrated in transition 12, device 110 can transition from transmit 908 to hold state 910 when the incoming request frame includes instructions to device 110 to enter hold state 910 following its transmission of a response frame.
As shown in transition 13, device 110 can transition from hold state 910 to listen state 904, which occurs when an incoming wake-up frame is detected or HSP becomes 0. Transition 14 illustrates that device 110 can transition from hold state 910 to sleep state 902, which occurs when hold state 910 times out. Finally, transition 15 illustrates that device 110 can transition from hold state 910 back to hold state 910, which occurs when no wake-up frame is detected and no time out has occurred.
Transition 19 shows that device 110 can transition from listen 1004 to hold 1002, which occurs if no incoming request frame is detected after MGT. Transition 20 illustrates that device 110 can transition from listen 1004 to receive 1006, which occurs when an incoming request frame sync word is detected.
Transition 21 shows that device 110 can transition from receive 1006 to listen 1004, which occurs when the received request frame leads to an incoming data frame. Transition 22 shows that device 110 can transition from receive 1006 to hold 1002, which occurs when the incoming request frame instructs device 110 to sleep or hold and not to form a response. Transition 23 shows that device 110 can transition from receive 1006 to transmit 1008, which occurs when the incoming request frame leads to an outgoing response frame.
Transition 24 shows that device 110 can transition from transmit 1008 to listen 1004, which occurs when the outgoing response frame leads to a subsequent incoming data frame or an incoming response frame. Transition 25 shows that device 110 can transition from transmit 1008 to hold 1002, which occurs when the incoming request frame instructs device 110 to sleep or hold following transmission of a response frame, or the outgoing request does not require a response. Transition 26 illustrates that device 110 can transition from transmit 1008 back to transmit 1008, which occurs when an outgoing data frame follows the outgoing response frame.
Devices 110 operating in either endpoint regime or subcontroller regime may include a wake-on radio. As shown in
As described above with respect to
Additionally, devices 110 may utilize the passive scanning of external RF events. In some embodiments, device 110 may initiate a dialog following the reception of an external RF event. The transmission of such a dialog can include, as data, a device ID, which may be compliant with ISO 15693, accurately identifying the device that transmitted the external RF event in addition to the device ID of device 110. These device IDs may be embedded in the protocols. Both passive scanning and external RF events can, for example, be based on passive RF described in ISO 18000-2, 18000-3, or 18000-4. The external RF event, can, for example, be a RF modulated signal or message that can be attributed to an ISO 15963 compliant device ID. Passive scanning can be any non-active method that can be utilized to receive and decode an incoming RF signal or message. In which case, as shown in
In some embodiments, device 110 remains in the sleep or hold state and does not transmit any beacon signal upon receipt of an RF event. Device 110 will follow the state transition as defined in
In some embodiments, device 110 can initiate a dialog following the detection of a sensor event. Transmission of a dialog can contain, as data, sensor identification identifying the sensor that generated the sensor event in addition to the device ID of device 110 that transmitted the packet. For example, the sensor ID can be an ISO 21451-7 compliant sensor ID. In which case, as shown in
As discussed above, in some embodiments device 110 may remain in a hold or sleep state upon receipt of a sensor event in order to wait for a wake-up packet. As shown in
Transition 30 indicates that device 110 can transition from receive 1104 to listen 1102, which occurs when an incoming response frame indicates that a data frame is coming. Transition 31 illustrates that device 110 can transition from receive 1104 to transmit 1106, which occurs when the incoming response frame precedes an outgoing data frame.
Transition 32 shows that device 110 can transition from transmit 1106 to listen 1102, which occurs when the outgoing response or data frame is completely transmitted. Finally, transition 33 shows that device 110 can transition from transmit 1106 back to transmit 1106, which occurs when an outgoing response frame is followed by an outgoing data frame.
As is illustrated above, transition between states occurs while receiving, transmitting, or responding to frames of data. As further illustrated above, in some embodiments there are distinct frame types, including a wakeup frame, a request frame, a response frame, and a data frame.
In some embodiments, preamble 1202 is a non-return-to-zero (NRZ) signal. As shown in
A constant chip rate can keep the power-spectral-density (PSD) the same throughout a dialog process. As a result, signal reception can follow a predictable model. Further, there is a strong push towards a digital solution because modern chips have stronger digital capabilities than analog capabilities and digital implementations tend to be less expensive.
In the embodiment of header 1204 shown in
Frame information 1208 can be encoded as block-code, for example eight bits in length. Frame info 1208 describes the state of the following frame data concerning, for example, encoding, encryption, and frame subtype. In some embodiments, frame info 1208 can include redundant transmission and a parity bit. In some embodiments, the parity bit can be “0” if the parity is odd or “1” when the parity is even. Frame types can include, for example, request/response frames, ACK/NACK frames, sequence ID frames, Security or Authentication frames, addressing frames, sync frames, or beacon frames.
Frame information 1208 can be encoded as a block-code of particular length. In some embodiments, frame information 1208 can be eight (8) bits in length. Frame information 1208 describes the state of the following frame data 1210 concerning encoding, encryption, and frame subtype. Frame information 1208 can include a subtype bit that indicates the subtype of the frame data, an encoding bit which indicates the type of encoding utilizes, for example whether PN9 encoding or FEC encoding is present, a cryptography bit which indicates whether or not the frame data is encrypted, and the parity bit. In some embodiments, frame information 1208 is an 8 bit field where bit 7 indicates subtype, bit 6 indicates encoding, bit 5 indicates cryptography, bit 4 is a parity bit. Bits 3 through 0 can have the same designations as bits 7 through 4.
Packet frame 1210 can be transmitted as an encoded bitstream at the requisite modulation chip rate, continuous with preamble 1202 and header 1204. The data in packet frame 1210 is of arbitrary length and can be encoded as full rate or half-rate-byte-aligned. Encoding methods for packet frame 1210 are discussed further below.
As shown in
Each of wakeup frames 1314, 1316, 1318, and 1320 can include a fixed-length integer. In some embodiments, the fixed length integer indicates the number of wakeup frames that remain in chain of wakeup packets 1300, with the last frame, frame 1320, holding the integer 0.
When device 110 wants to send a request in order to initiate a dialog, then device 110 transmits wakeup packet chain 1300, which transmits a “train” of wakeup frames 1314 through 1320. Wakeup frames are of fixed length, and therefore of fixed duration. As shown in
Each wake-up frame in packet chain 1300 can be a fixed number of bits, for example 16 bits. Table 7 indicates a particular implementation of a wake-up packet chain according to some embodiments of the present invention. One skilled in the art will recognize that other implementations fall within the scope of this disclosure.
As suggested above, and discussed further below, reception of wakeup packet 1300 is one of the wake-on radio events that results in activation of a device 110. As such, device 110 periodically scans for detection of chain of wakeup packets 1300. In some embodiments, those scan events may be scheduled. In some embodiments, device 110 periodically scans the transport channels for a wakeup event. From the count-down value in each of wakeup frames 1314 through 1320 in wakeup packet 1300, a device 110 that detects wakeup packet 1300 knows the time before a request packet 1400, discussed with respect to
b) illustrates a state diagram for device 110 in a sleep state 850. As shown in
c) illustrates a scheduled scan sleep state 860. In this case, device 110 remains in RTC compare state 862 until a real-time-clock (RTC) matches the scheduled time for a scan. When the RTC matches a scheduled event, then device 110 transitions to carrier sense 864, where if a carrier is not present device 110 transitions back to RTC compare state 862 to await the next scheduled time. If carrier sense 864 detects a carrier signal, then device 110 transitions to detect wakeup 866 where device 110 checks for a wakeup packet 1300. If wakeup packet 1300 is not detected, then device 110 transitions back to RTC compare 862. If wakeup packet 1300 is detected, then device 110 transitions to nap state 868. Again, in nap step 868 device 110 determines the amount of time before request packet 1400 will arrive and returns to an inactive state until the request packet 1400 is expected. Scheduling can be configured by a protocol, and can be different for each device 110. The scheduling can also be dynamically configured according to a predefined logic and the occurrence of events, for example, the number of carrier sense successes and failures. Further, in some cases a beacon or other action can be scheduled similarly to a wakeup scan.
In some embodiments, device 110 can scan multiple transport channels in an order and frequency that is configurable. As discussed above, each transport channel is associated with a channel ID. Each device 110 may then be loaded with a list of channel IDs to scan and how often to scan each of the channels on the list.
In some embodiments, real-time scheduling of wake-up events can be utilized. Devices 110 can be configured to align sleep scan cycles to a common clock so that the scheduled wake-up events can be utilized. Devices 110 that are operating in subcontroller or gateway regimes in scheduled networks may reliably utilize wake-up packet chains 1300 that are much shorter than the sleep scan period, as long as wake-up packet chain 1300 is of duration within the tolerance of the synchronization method.
Request packet 1402 is an arbitrary-length packet that includes a formal template, data, and, in some embodiments, a CRC-16 component. These components are described further below. A single request packet 1402 follows wakeup packet train 1300 as shown in
Response packet 1404 includes responses and acknowledgement to request packet 1402. Response frame 1416 is structurally the same as request frame 1410. Response frame 1402 and request frame 1404 are not typically included in chains of frames. Table 8 illustrates a particular example implementation of a request frame 1402 and a response frame 1404.
Data packets with multiple numbers of data frames 1510 (data frames 1510-1 through 1510-N being shown in
Silent period 1502 can be of any duration, for example a duration that is less than MGT. Transmission of data packet 1504 follows a handshaking procedure managed through data frame commands provided in request frame 1402 and response frame 1404. Table 9 illustrates a particular implementation of data packet frame 1504.
As discussed above, encoding of data in any of the packets can be accomplished in any fashion, for example FEC coding or data whitening (PN9) coding discussed above. In some cases, the data can be concatenated with a two byte CRC-16 field. The two byte CRC-16 field can conform to a CRC16 polynomial. The polynomial can be a CCITT CRC16 polynomial, or x16+x12+x5+x0 (1021).
As in any network of interacting devices, RFID system 100 also includes procedures for collision avoidance. Some embodiments of the invention use a non-arbitrated carrier sense multiple access (CSMA) procedure. Some embodiments may also employee an arbitrated CSMA procedure. One skilled in the art may also recognize that other collision avoidance procedures can be utilized.
A guarded channel refers to a channel that is currently being transmitted upon or that has been transmitted on within the last MGT period. In some embodiments, transmission onto a guarded channel is not allowed. Devices 110 that initiate a transmission undergo a CSMA procedure prior to that transmission. In some embodiments, there may be transmissions that are undertaken without undertaking the CSMA procedure. For example, in some embodiments a CSMA procedure may not be required if device 110 is entering the transmission state from a synchronous hold state into a discreet time-slot; a CSMA procedure may not be required for device 110 that transmits a relevant follow-up packet within the MGT following the prior packet; and a CSMA procedure may not be required for device 110 that is acting as the arbitrator in an arbitrated CSMA dialog when transmitting into an arbitration request window.
As discussed above, the maximum guard time (MGT) is the maximum time a device 110 in the transmission state may be silent in the space between two adjacent frames in a dialog. After the MGT passes, the dialog channel is not guarded and is therefore not guaranteed to be clear. From another perspective, the MGT is the minimum time that device 110 has to remain in the listen state before transmitting into an arbitrary channel. Although the MGT can be set to any time, due to processing time and radio start-up time, the MGT should be a non-zero value. In some particular implementations of embodiments of the present invention, MGT can be set to 4.8 ms.
The minimum transmission time (MTT) refers to the shortest permitted duration during which device 110 may continuously transmit. As a particular example, in some embodiments the MTT can be set at the equivalent time duration for transmission of 184 bits, which can vary depending on the physical aspects of the transmission. In some cases, in normal mode MTT can be around 3.3 ms±1.5% and in turbo mode MTT can be around 0.92 ms±2%. However, MTT can be set at the duration for transmission of any number of bits of data.
As shown in
If, in the first channel check 1704 or in second channel check 1712 the chosen channel is not clear, then device 110 transitions via transition 1722 or 1724, respectively, to check timeout 1710. If a timeout condition is detected, then device 110 transitions via transition 1732 to timeout 1716. Otherwise, device 110 transitions via transition 1730 to wait 1706. The timeout condition can be configurable for each device 110.
In wait 1706, device 110 delays for a period of time X and then transitions via transition 1734 back to pick channel step 1702. A new random channel may then be picked and arbitration process 1700 executed on the new random channel The amount of wait time X provided in wait 1706 can be, for example, a time equal to the duration time of the packet that device 110 is to transmit.
Further, request and response packets that are sent during the arbitration process are not preceded by a wake-up packet, so devices interested in receiving arbitrate response frames stay in the listen state for each N ms arbitration window. Devices interested in receiving arbitrator request frames enter the listen state immediately following each N ms arbitration window. As shown in
As shown in
In mask compare 1810, if request 1902 is directed at device 110, then device 110 transitions to check channel 1814. In check channel 1814, device 110 checks to see if the transport channel is clear. If it is not clear, then device 110 enters transition 1842 to check timeout 1820. If the time out has not been exceeded, then device 110, through transition 1844, enters calculated wait 1816 where it waits for a time period X. After time period X, device 110 transitions through transition 1838 to check channel 1814.
In check channel 1814, if the channel is clear, then device 110 transitions through transition 1840 to wait 1818, where it waits for a period of time C+D. After the period of time C+D, device 110 then transitions via transition 1852 to second channel check 1822. If the channel is not clear, then device 110 transitions via transition 1850 to wait 1816. If the channel is clear, then device 110 transitions via transition 1854 to send response 1856 where a response is set. After sending the response, device 110 transitions via transition 1848 to wait 1812.
In
From timeout 1820, if the timeout period has expired device 110 transitions to wait 1812. In Wait 1812, device 110 waits for a time less than N in order to check the next window period. In other words, there is not sufficient time within the arbitration period to send a response, which is an elapsed time greater than or equal to N-x. After the wait, device 110 transitions via transition 1832 to listen state 1804. From listen state 1804, device 110 can transition via transition 1826 to idle state 1806 if device 110 is finished.
As shown in
In some embodiments, a synchronized access with guaranteed time slots may be utilized. In that case, each device 110 is provided with a time slot for a response and each device 110 response to a request during its assigned time slot.
In communicating between devices 110 as shown in
a) illustrates the dialog between a requesting device 2002 and a responding device 2004 in unicast routing. Both device 2002 and device 2004 are ones of devices 110 shown in
b) illustrates a dialog of multicast routing. In multicast routing, the dialog originates from one of devices 110, the requesting device 2002, but elicits responses from multiple other devices 110, responding devices 2004, 2006, and 2008. Request frame 1410 from one device contains routing information that is unique to an arbitrary number of responding devices 2004, 2006, and 2008. Response frames 1416 include routing information that can uniquely identify the originator of the multicast dialog. As shown in
c) illustrate a dialog of broadcast routing. Broadcast routing originals from one of devices 110, the requesting device 2002, and is responded to by all available other devices 110, the responding devices 2004, 2006, and 2008. As shown in
d) illustrates a dialog consistent with anycast routing. Anycast routing can be a subset of multicast routing, with the primary difference being that the goal of multicast routing is to receive responses from all of devices 110 that match the routing information, whereas the goal of anycast routing is to finish in a short period of time even if all of devices 110 that match the search criteria in the routing information have not successfully responded. As shown in
Unicast, broadcast, and multicast routing can be useful for single-hop packet routing. Single-hop packet routing refers to dialogs between individual ones of devices 110. For example, in
e) illustrates an extended dialog 2010 between requesting device 2002 and responding devices 2004 utilizing unicast routing. As shown in
f) illustrates an extended dialog between requesting device 2002 and responding devices 2004, 2006, and 2008 in multicast routing 2014. As shown in
Devices 110 may support any number of data elements that are stored within device 110, some of which can be transmitted in frame data 1210 shown in packet 1200 of
Data elements may include protocol IDs that identify an encapsulated protocol that may be included in a data frame 1510. Further, data elements may include authentication data, which may include cryptographic keys or access privileges. System configuration data elements can include lists of available features, lists of supported protocol IDs, lists of universal data block (UDB) type codes supported by device 110, scheduling configurations, or channel scan configurations. Other data elements can include received signal strength indication (RSSI) location data lists, IPv6 addressing data, ISO 21451-7 sensor and alarm lists, UDB legacy elements, or UDB extended elements.
Less structured data can also be utilized through a raw data block (RDB) system. An RDB can be implemented with a file system that defines the privileges and file lengths of the data. Reads and writes can be performed. The Coffee File System, for example, utilizes 64 kB ROM memory and 173 bytes of RAM in device 110 and stores the privileges for each file and allows dynamic allocation. Coffee was designed for flash memory systems.
Un-addressable data elements are data elements that are not addressable by a particular used protocols. Such data elements may be user defined data elements and may be utilized to pass any data between devices 110. Some examples may be inventory data, GPS location data, environmental conditions data, access history data, or any other data that may be utilized by the user to track an article to which device 110 may be attached. Such data may or may not be encrypted according to user specifications.
A real time clock (RTC) element indicates a time. In some embodiments, for example, the real time clock can be formatted as a 32 bit integer pertaining to the number of seconds since 1 Jan. 1970, 0:00 (UTC format). The real time clock may be accessible, for example, through a synchronization UDB data element.
In some embodiments, devices 110 can support encryption and authentication requirements, which may utilize a key table. The key table can include a cryptographic key for each device 110 that establishes authentication via an authentication comment, as well as a key lifetime field that can also be defined by the authenticate command. As such, the key table can include a key for each authenticated device and the level of authentication for each authenticated device. A particular key need not be retained indefinitely and may expire after a period of time. In embodiments where multiple encryption methods can be utilized, the key table element may include information regarding the type of cryptography that each key utilizes. In some embodiments, the key table may be implemented such that when device 110 is turned off it is deleted.
A device ID element may also be utilized. In some embodiments, the device ID structure may be compliant with ISO 15963. Further, the device ID structure may be a universal ID (UID) or a virtual ID (VID).
A UID element may include an application code (AC) field, a manufacturer ID, an extension field, and a serial number. In some embodiments, the UID can be arranged (from most significant bit (MSB) to least significant bit (LSB)) with the AC field having 8 bits, the manufacture ID having 8 bits, the Extension having 8 bits, and the Serial Number having 40 bits. However, other arrangements and sizes of UID fields can be utilized.
An application code (AC) field holds a value corresponding to the type of application for which device 110 is intended. In some embodiments, the AC can be consistent with the DASH7 Alliance definition. Some embodiments may be in compliance with ISO 159683, in which case the AC field is one byte encoded as 000xxxxx, where the variable bits are declared in ANS INCITS 256 and may be extended.
The manufacture ID field holds a value indicating the manufacturer of device 110. In some embodiments, manufacturer ID's are allocated by the DASH7 Alliance and uniquely identify the particular manufacturer of device 10. In some embodiments, the manufacture ID field can be two bytes in length.
An extension field can also be included. The extension field can be a two byte field which is set to 0x00, although in some cases the field may contain the upper 8 bits of the 16 bit manufacturer ID.
The serial number is unique to device 110. In some embodiments, the serial number may be the lower 8 bits of the manufacturer ID concatenated with a 32 bit ID associated with device 110. In some embodiments, the entire serial number can be assigned by the manufacturer, which when combined with the manufacturer ID and extension field results in a unique serial number for device 110.
A virtual ID (VID) is an ID that is unique to the local network, i.e. system 100, but may not be universally unique. Furthermore, the VID may be assigned to a device 110 by another device 110 of system 100. In some embodiments, the VID can be compliant with ISO 15963 and can be a truncated version of the UID. VID can be of any size, for example 16 bits.
The protocol element can identify which of the different protocols that are supported by device 110. In some embodiments, the protocol element field can be two bytes. In some embodiments of RFID system 100, device 110 may be required to support some protocols while not supporting other protocols. For example, Table 10 provides an example embodiment of an RFID system 100 indicating the protocol IDs for various protocols and which are mandatory, which are optional, and which are not supported (deprecated). Of particular interest in Table 10 is the ISO 18000-7 mode 2 protocol (mode 2), provided with protocol ID 0x51. The mode 2 protocol is particularly discussed herein as a specific example of embodiments of the present invention.
A privileges and authentication element can be utilized to identify privilege and authentication data. In some embodiments, data elements are specified with individual privilege and authentication information. For example, each UDB search code may include its own privilege code. Further, each UDB element may include its own privilege code. Further, each raw data block (RDB) element may contain its own privilege code. Data elements can be accessed by a user according to that user's type and according to the privilege code of the data element.
The user element can be utilized to support different users of the RFID system 100 network. Different data elements may be accessible to different users. Further, read/write privileges may be different for each user. In some embodiments, for example, user types may include root, admin, and user. A root user may be a super-user or device 110's internal system. A root user may read and write any data element in device 110. An admin user is an authenticated user and may read and write to specified data elements only. A user may read or write to a restricted set of specified data elements only. In some embodiments, a root user is authenticated by a root key and an admin user can be authenticated by an admin key. A general user may not require authentication.
In some embodiments, a privilege code can be stored in a byte that indicates access to a specific data element. Table 11 illustrates the format of a privilege code byte according to some embodiments of the present invention. As such, the privilege code is a 6 bit mask, stored as a mask, that declares the read and write status of a given data element. The root privileges are set to “11” to allow access to each data element to root type users. Other privileges are set for each data element according to user type.
There can be any number of universal data block (UDB) elements. UDB elements are defined and specifically identified. An example set of UDB elements and their ID codes is described in Table 12. The ID code, for example, can be a two byte code. Some embodiments of the invention can perform reads and writes to arbitrary UDB elements while referencing the ID code. These encapsulated data elements can define the capabilities, status, and settings of device 110. Further, utilization of UDB elements allows multiple ones of devices 110 to efficiently advertise their capabilities by being read. Further, new UDB elements can be identified.
The UDB codes themselves can include device proprietary data, standard device settings, PHY configuration, schedulers, time periods, protocol lists, code lists, RDB element identification, locations, addressing, sensor lists, alarm lists, authentication keys, routing codes, user IDs, hardware faults, and application data. The particular example of UDB element definitions provided in table 12 is one example only. Embodiments of the invention may include some of these and other elements that may be defined. UDB elements can further be associated with privilege code access as described above.
UDB elements can further be typed according to description. For example, UDB types can include transit data, hardware faults, device capabilities, location, and extensions. Table 13 provides an example of UDB type codes as described with the set of UDB elements shown in Table 12.
Device proprietary data UDB element includes the device addressing elements and can include the UID, the VID, and any additional proprietary variables that may be utilized for addressing purposes. As described above, the UID can be 8 bytes and the VID can be 2 bytes and therefore the UDB element can be 10+N bytes, depending on the size of the proprietary data. In some embodiments, the privilege settings for the proprietary data UDB can be root: rw, admin: rw, and user: r- (indicating that the root type user has read/write privileges, the admin type user has read/write privileges, and the user has read privileges but not write privileges).
The device settings UDB elements describe the features of device 110. In some embodiments, the device settings UDB element can be 11 bytes with one byte utilized to indicate the active regime, one byte utilized to indicate the supported regimes, one byte utilized to indicate the maximum subframe data length, one byte utilized to indicate the maximum frame length in terms of a number of subframes, two bytes utilized to indicate the maximum raw data block (RDB) block size, three bytes utilized to indicate the total available RDB memory, one bite utilized to indicate the maximum UDB type code length, and one byte utilized to indicate the maximum UDB type codes. The default user privileges for the device settings UDB element can be, for example, root: rw, admin: r-, user: r-.
The active regime and the supported regimes can, for example, be indicated by activating a bit in one of the three LSBs of one byte with bit 0 indicating the endpoint regime, bit 1 indicating the subcontroller regime, and bit 2 indicate the gateway regime. Similarly, the supported regimes byte can indicate which regimes are supported by device 110 by placing a “1” in the appropriate ones of the three LSBs of the byte.
The number of bytes utilized to designate a particular aspect of the device features dictates the values that can be indicated. The maximum data subframe length can be, for example, between 1 and 255 bytes. In some embodiments, a minimum, for example 64, for the size of the subframe length can be utilized. The maximum data frame length can be, for example, 1 to 255 subframes. The maximum RDB block size can be set between 0 and 65536 bytes. The total available RDB memory can be set between 0 and 16777216 bytes. The maximum UDB type code length can be set between 0 and 255 UDB element IDs. The maximum UDB type codes can be set between 0 and 255.
The PHY configuration lists the available transport channels in the local network formed by system 100 and the link regulations that apply to each transport channel. In some embodiments, the length of the PHY configuration can be six bytes per supported transport channel. The transport channel ID can be indicated with 1 byte; the channel power selector can be indicated in 1 byte, the maximum transmit duration can be set with two bytes, and the post transmit wait duration can be set with two bytes. The default privileges can be root: rw, admin: rw, and user: r-.
Examples of transport channel ID definitions are indicated above with respect to Tables 5 and 6. Maximum TX duration and Post TX duration, utilizing two bytes, can be set between 0 and 65535 ms. The channel power selector can be utilized to set the channel power to auto-select or between a minimum and maximum power output. For example, bits 5:0 of the byte can provide a power value such that the power output is given by Minimum+b5:0 dBm. The minimum power, for example, can be set at −40 dBm. In some embodiments, an autoscale feature can be utilized, for example by setting bit 7 of the channel power selector byte. The autoscale feature adjusts the power of device 110 according to the strength of the received signal.
The real time scheduler UDB element allows devices to schedule wake-up scan periods with relative accuracy. The scheduler UDB element includes a handle to a RTC element and dictates the scheduled duration. Devices 110 operating in the endpoint regime can apply scheduling to the sleep scan period in the sleep state, as illustrated, for example, in
The RTC value can be a copy of the lower four bytes of the device RTC element discussed above. The RTC fractional value can, then, be a value between 0 and 65535, providing fractional seconds in 1/65535 intervals. The SSP sync mask can be a 32 bit mask for comparing the RTC with the sync value in a sleep scan of the sleep state. The SSP sync value is a 32 bit compare value for the sleep scan. The HSP sync mask is a 32 bit mask for comparing the RTC with the sync value in a hold state. The HSP sync value is a 32 bit compare value that can be utilized in a hold scan. Other values and bit sizes can be utilized for these fields.
The sync mask and sync value attributes align partly with the RTC value and partly with the RTC fractional value. The upper two bytes of the RTC value are not compared. When the masked RTC value compares identically to the Sync Value, the device begins its scan period. The default values for the Sync Mask and Sync Value attributes can be set for particular values. For example, the SSP can be set for 2.88 seconds while the HSP is set for 72 ms. Other values can be utilized.
The RTC value can be a shadow register of the RTC data element discussed above. When the synchronization UDB element is read, the RTC value can be copied from the RTC data element. When the synchronization UDB element is written, the RTC value can be written into the RTC data element.
The sleep channel scan period list can be an ordered list of channel scan period data elements. When device 110 begins its sleep scan period, the first transport channel in the list of the channel scan periods can be scanned for wake-up frames. If no wake-up frame is found, device 110 will wait for the period in the next scan before repeating the process on the next transport channel in the list. In the event that the sleep scan period occurs before all the listed channels can be scanned, device 110 restarts the sleep scan period from the initial channel scan period. In some embodiments, three bytes can be utilized for each transport channel in the scan list. The channel ID can be included in one byte and the next time scan can be two bytes that indicate the time to wait before scanning the next channel in the list. The default privilege can be root: rw, admin: rw, user: r-.
The hold channel scan period list can be identical to the sleep scan period list and is utilized in the hold state. The default privileges can be root: rw, admin: rw, user: r-.
The protocol list is a list of protocol IDs that are supported by device 110. In some cases, the protocol list can be sorted, for example in ascending order. The protocol list can be written once during the initial loading of firmware onto device 110. However, in some embodiments it may also be issued dynamically to activate or deactivate different protocols. The protocol list element can be one byte for each protocol ID. A list of example protocol IDs is provided in Table 10. The default privilege can be root: rw, admin: rw, and user: r-.
The UDB type code list element includes a list of UDB type code IDs supported by the device. The UDB type code list element includes one byte per supported type code IDs. A list of example type code IDs is provided in Table 13. The default privilege is root: rw, admin: r-, and user: r-.
The RDB element list provides a list of RDB elements that are currently active. The RDB element list can be automatically updated when RDBs are added or removed. The list can be managed as a typical stack, with the most recently accessed RDB element at the front of the list. The RDB element list can be one byte for each RDB element ID. The default privilege can be root: rw, admin: r-, and user: r-.
The location data list element is location data obtained from other of devices 110. In some embodiments, received signal strength indicator (RSSI) data is provided. In that case, the location data can be stored as a list of device IDs and RSSI data. For example, the captured device ID from a near-field device 110 can be conveyed by location coordinate and represented in the location data list as a single coordinate list. In some embodiments, the location data list can be 10 bytes per location coordinate. The origin ID can be two bytes or eight bytes, the RSSI captured on antenna 2 can be one byte, and the RSSI captured on antenna 2 can be one byte.
The IPv6 addressing data element in device 110 includes unicast, anycast, and multicast addressing parameters. In some examples, the addressing data element can include 48 bytes with the IPv6 unicast address being 16 bytes, the anycast address being 16 bytes, and the multicast address being 16 bytes. The unicast address is the address of device 110, the anycast address in the anycast address vector, and the multicast address is the multicast address vector. The default privilege can be root: rw, admin: rw, and user: r-. The IPv6 element 2 referred to in Table 12 is reserved and associated with the IPv6 addressing data element.
The ISO 21451-7 sensor list element includes a list of ISO 21451-7 sensor IDs that are included in device 110. The default privileges can be root: rw, admin: r-, and user: r-.
The ISO 21451-7 alarm list includes the alarm status of the ISO 21451-7 devices in the ISO 21451-7 sensor list element. The default privileges can be root: rw, admin: r-, and user: r-.
The root authentication key element in device 110 is the authentication key for root access. The key can be encrypted and, for example, stored in a private key protocol or public key protocol. The default privileges are root: rw, admin: --, and user: --.
Similarly, the admin authentication key is a key that enables admin access. The key can be encrypted and, for example, stored in the private key protocol or public key protocol. The default privileges are root: rw, admin: rw, and user --.
The routing code element can be that utilized in the ISO 18000-7 mode 1 protocol. The default privileges are root: rw, admin: rw, and user: r-. The routing code element is a user readable and writable memory whose purpose and size, in some cases up to 50 bytes, is user defined. The UDB element ID, as shown in Table 12, is 0x10. The length is N bytes.
The HW fault status element can be that utilized in ISO 18000-7 mode 1 protocol. The default privileges are root: rw, admin: r-, and user: r-. Examples of hardware faults include hardware reset count, watchdog reset count, and a hardware fault bitmap, which may include a low battery flag. The element may include three bytes of data: the lifetime count of hardware resets, the lifetime count of firmware resets, and the hardware fault bitmap. The hardware fault bitmap byte can include a low battery bit (e.g., bit 0) and a memory corruption bit (e.g., bit 1). The UDB extended services list element provides a way to integrate data formats and external technologies that are not explicitly supported by available protocols already defined. The length is variable. The extended services list element can provide a length N in one byte and then N bytes of individual information. The extended services list can provide a length M+1 in one byte, an extended services ID in one byte, and then a description of the services in M bytes. The default privileges can be root: rw, admin: r-, and user: r-.
The UDB extended services alarm list can provide interrupts or alarms. The length is variable. In some embodiments, a length N is provided in one byte and then N bytes each provide an extended service ID of the alarm. The default privileges can be root: rw, admin: rw, user r-.
The UDB extended service elements may be additional elements defined in a particular application. The length of the element is dependent on the particular element and application. The default privileges can be root: rw, admin: r-, and user: r-.
The UDB application extension can be the same as described in ISO 18000-7 mode 1. The default privileges can be root: rw, admin: rw, and user: r-. The Universal Data Block may include one or more UDB application extension blocks that encapsulate one or more type/length/data frames, which can be identified by an Application ID. Individual devices may support extensions defined by one or more vendors.
The Raw Data Block (RDB) element can be a 24 bit, byte-addressed virtual address space for unstructured data that includes a one byte RDB ID and a two byte block address. In some embodiments, the RDB data can be separated into individual blocks, for example 64 kB blocks, each administered by an RDB element including a privilege code, 16 bit max size attribute (the maximum data per the block), a 16 bit size attribute (the number of actual bytes written). The default privilege can be root: rw, admin: r-, and user r-.
Dialog between devices 110 is governed by a defined protocol. In some embodiments, a Mode 2 protocol layer is utilized. As discussed above with respect to
a) illustrates a frame 2100, which can be either a request frame 1410 or a response frame 1416 as shown in
Protocol header 2102 depends on the particular protocol utilized by sending device 110. A list of example protocols is provided as Table 10. For purposes of example, the ISO 18000-7 Mode 2 protocol (the Mode 2 protocol) is particularly discussed, however some embodiments of the invention can utilize other protocols as well. Other protocols may utilize different protocol headers and frame structures.
Depending on the particular protocol, a request/response frame structure 2100 may include control directives which instruct one or more devices to enter sleep state or stay active, provide an ACK or Negative ACK (HACK), provide responses to timeouts, or provide allowable response channels to utilize. Some protocols may provide for security authentication, for example cryptographic challenges and responses or key timeouts. Protocols may allow for batch read and write subprotocols, for example for UDB or RDB elements. Protocols may also allow for encapsulated protocols to utilize in data frames 1510.
In the Mode 2 protocol, protocol header 2102 can be 5 bytes in length.
Frame length 2134 provides the length of the frame in bytes, not including the one byte for protocol ID 2132. With one byte, the frame length can be set between 0 and 255 bytes.
Device flags 2136 provides one byte of alert flags regarding either requesting or responding device 110. In the mode 2 protocol, device flags 2136 is one byte given by bits b7 to b0 as illustrated in
Bit 6 of device flags 2136 is a system fault flag, which is set on the condition that device 110 should be replaced or serviced due to the appearance of a technical problem. The system fault flag can be cleared only after a cold boot of the sending device 110. Bit 5 of device flags 2136 is a low battery flag, which is set on the condition that the battery in device 110 is low. In some embodiments, the battery low flag conveys that device 110 has about 500 hours of usage remaining. Bit 5 can be cleared automatically when the battery in device 110 is no longer low in charge.
Bit 4 of device flags 2136 is set when an alarm-enabled sensor declares an alarm. Bit 4 is cleared automatically after all alarms in the sensor alarm UDB element are clear. Bit 3 of device flags 2136 is set when any alarm-enabled extended service declares an alarm. Bit 3 is cleared automatically after all alarms in the extended services alarm UDB element are cleared.
Bits 2 and 1 of device flags 2136 are currently unused. Bit 0 of device flags 2136 is set when any device IDs used in the frame are transmitted as 2 byte VIDs instead of 8 byte UIDs.
Session ID field 2138, which may be two bytes, identifies the session number of the current dialog. A response includes the same session ID value as the preceding request. After each request, the session ID value can be incremented. The session ID value can be re-computed as a new random number of device 110, for example if device 110 is in a subcontroller regime and enters the hold state or if device 110 is in a gateway regime and enters the listen state, unless it is currently managing an arbitrated CSMA dialog, as illustrated in
Following protocol header 2102 is command code 2104. As shown in
Extension flag 2140, bit 7, is set to indicate that command extension 2106 follows command code 2104 in frame 2100. If not set, there is no command extension 2106 following command code 2104, and all bits in command extension 2106 may be presumed to be set to 0.
Sleep flag 2142 of command code 2104, bit 6, can be set to instruct the receiving device to enter the sleep state following the dialog. The routing type, bits 5 and 4, can be set to indicate routing type in routing type 2144. For example, broadcast may be indicated by“00”, anycast may be indicated by“01”, unicast may be indicated by “10”, and multicast may be indicated by“11”.
Opcode 2146, bits 3 through 0, can be set for an operation code. Examples of operational codes that can be utilized in device 110 are provided in table 14. and discussed in more detail below. Operational codes describe a set of operations inherent in the command and provide a method of instructing devices 110 to perform certain functions.
As discussed above, if the NACK bit (bit 7) of device flags 2136 of protocol header 2102 is set, then an error response follows.
As shown in
Following response template 2108 is the error code 2114. Error code 2114 can be one byte and specifically identifies the detected error. Following error code 2114 is the error subcode 2116, which may also be one byte in length. Following error subcode 2116 is error data 2116. Error data 2116 can be of any length and can include a detailed description of a particular error, for example a Mode 2 Native protocol error. An extended error data field may also be included for storage of information relating to errors with encapsulated data.
An example of a set of error codes that can be utilized is provided in Table 15. Other error codes and other errors may also be detected. The error codes listed in Table 15 are applicable to Mode 2 protocols.
As shown in Table 15, error code 0x01 is an invalid command code. An invalid command code indicates that the opcode provided in command code 2104 is not recognized by the receiving device. Error 0x02 indicates an invalid command parameter. An invalid command parameter indicates that a parameter provided is inconsistent with the command code provided.
As shown in Table 15, an opcode of 0x08 indicates an authorization failure. An authorization failure occurs when the requesting device does not have the appropriate privileges to access the requested data element, for example the UDB data elements, as provided in the request. For example, a multicast command where read protected UDB element is used for comparison. As another example, a read request to a read protected UDB element results in an authorization failure. In some embodiments, along with the error code, the privilege code is provided error subcode 2116.
A generic encapsulated protocol error can occur if there is an error with a non-codified encapsulated protocol. In some embodiments, including the mode 2 example shown here, particular encapsulated protocols are encoded. In the mode 2 example, encoded encapsulated protocols include UDB, RDB, private key, public key, IPv6, and IEEE 1451.7. Each has its own specific error code, as shown in Table 15. The error code (0x50 from Table 14) is provided in error code 2114. Error subcode 2116 can provide the protocol ID, examples of which are shown in Table 10. Error data 2118, then; can be N bytes utilized to hold proprietary error data associated with the non-codified encapsulated protocol.
From Table 15, error code 0x51 indicates that the VID is not available. This error code is set when the VID bit of the device flags is set but the receiving device does not have VID functionality enabled, the receiving device has not been assigned a VID, or the VID of the receiving device has timed out. Error subcode 2116 may hold a reason code for the VID error.
Error code 0x52 is set to indicate an error in the data supplied in a request frame utilizing a UDB encapsulated protocol. Error data 2116 can be utilized to provide the specific UDB encapsulated protocol error data. Similarly, the RDB related error code, 0x53, is set to indicate an error with the data supplied in a RDB encapsulated protocol in a request frame. Error data 2116 can be utilized to provide the RDB encapsulated protocol error data.
A private key cryptographic error, set by setting error code 2114 to 0x54 as shown in Table 15, indicates that there is an error with the data supplied in a private key encapsulated protocol. Error data 2118 can be utilized to hold the RDB encapsulated protocol error data. Similarly, a public key cryptographic error, set by setting error code 2114 to 0x55 as shown in Table 15, indicates that there is an error with the data supplied in a public key encapsulated protocol. Again, error data 2118 can be utilized to provide the public key protocol error data.
The IPv6 error shown in Table 15 is set, for example by setting error code 2114 to 0x56, where there is an error with the IPv6 encapsulated protocol data. The IPv6 data error may be provided in error data 2118. Similarly, the IEEE 1451.7 error shown in Table 15 is set, for example by setting error code 2114 to 0x57, where there is an error with the IEEE 1451.7 encapsulated protocol data. The IEEE 1451.7 may be provided in error data 2118.
Returning to
As described above, broadcast routing involves one of devices 110 initiating a dialog or response to all available devices. Broadcast dialogs contain no routing compare information. A broadcast request may be acknowledge by a unicast or broadcast response on any of the channels specified in routing template 2108. Responses to broadcast requests can be conducted via non-arbitrated CSMA procedure 1700 as discussed with respect to
a) illustrates an embodiment of a broadcast request routing template 2202. Broadcast request routing template 2202 can include a 2 or 8 byte requester device ID 2204, a 2 byte response timeout 2206, a 1 byte number of response channels 2208 holding value N, followed by N 1 byte transport channel identifications 2210. Requester ID 2204 is either the VID or UID of the requesting one of devices 110. Again, indication of which ID is provided in header 2102. The response timeout 2206 allows the requester to set a time between, for example, 0 and 65535 ms for a timeout. The response timeout indicates the amount of time the responding ones of devices 110 will spend engaged in the non-arbitrated CSMA process 1700 before giving up in step 1716.
The number of channels 2208 indicates the number of individual transport channels, N, over which responding devices 110 can transmit responses. Identification of the N identified channels is then provided in response channels 2210. As discussed above, examples of transport channel identification codes are provided in Tables 5 and 6 above. As devices enter non-arbitrated CSMA procedure 1700 as shown in
b) illustrates a response broadcast routing template 2212. As shown, template 2212 includes a requester ID 2214, which can be one 2 or 8 byte field holding the requester device ID, followed by a responder ID 2216, which is a second 2 or 8 byte field holding the responder device ID. If the responding device is responding to a requesting device through a third device, then a third field, which may be a 2 or 8 byte, holding the forwarder's device ID can also be included.
a) illustrates a requester unicast routing template 2302 that can be utilized as routing template 2108. As discussed above, a unicast routing is between two particular ones of devices 110. As such, routing template 2302 is a request frame that uniquely describes one other device 110. As shown in
The response to a unicast request may be acknowledge by a unicast response or a broadcast response.
The response delivery mechanism for a unicast dialog can be non-arbitrated CSMA process 1700 unless the response channel is the same as the request channel, in which case responding device 110 may forgo using any kind of CSMA as long as it transmits within the MGT (e.g., 6 ms) of the conclusion of the request packet. If the response device 110 cannot manage to transmit a same channel response within the MGT, it then may use the non-arbitrated CSMA process 1700.
As discussed above, multicast routing is initiated by a requesting device 110 and elicits responses from multiple identified devices 110. If frame 2100 is a request frame, it includes routing information that may be unique to an arbitrary number of devices 110. If frame 2100 is a response frame, it contains routing information that can uniquely identify the requesting device 110.
In order to sufficiently transmit a request to multiple, identifiable devices 110 and expect to receive responses from the identifiable devices 110 can utilize a mask and compare technique for identification. Further, responses from multiple devices 110 that match the mask can be handled through arbitrated CSMA process 1800 as described in
a) illustrates a routing template 2402 appropriate for template 2108 if frame 2100 is the initial request frame, shown as request 1902 in
The compare codes, both the multicast compare code 2412 and window compare code 2414, can be defined to relate to a comparison between a compare value held in multicast compare value 2420 and window compare value 2422 and a masked value generated by device 110 with mask 2418. The masked value is the data element value in the receiving device 110, offset by the start offset in start offset 2410, and masked by the mask in mask 2418. The compare code can be set, for example, as follows: 0x00: compare value≠masked value; 0x01: compare value=masked value; 0x02: compare value<masked value; 0x03: compare value≦masked value; 0x04: compare value>masked value; and 0x05: compare value≧masked value. Multicast compare code 2412, window compare code 2414, multicast compare value 2420, and window compare value 2422 allow for particular devices within the overall multicast criteria to be chosen for response within the window.
The mask length 2416 provides the length N, in bytes, of the mask 2418. In some embodiments, the mask 2418 can be between 0 and 64 bytes. The multicast compare value 2420 is the N byte compare value for the multicast as a whole. The window compare value 2422 is the N byte compare value for the next arbitration window. As discussed further below, the data element that is to be compared is identified in command data 2110 following routing template 2108.
As shown in
As before, if frame 2100 is a multi-cast response frame 1404, then routing template 2108 includes a 2-8 byte requester device ID and a 2 or 8 byte responder device ID, as illustrated in the unicast response routing template 2310. Because multi-cast routing uses arbitrated CSMA process 1800, multi-cast routing cannot be involved in multi-hop routing.
a) and 25(b) illustrate an anycast request routing template 2502 and an anycast response routing template 2524, respectively. As discussed above, anycast routing is a non-guaranteed version of multi-cast routing. Anycast routing can utilize non-arbitrated CSMA process 1700. As a result, anycast routing can be well suited for management of multi-hop communications. As discussed above, devices 110 in gateway regime and devices 110 in subcontroller regime can forward packets in responsive to anycast routing, but devices 110 operating in the endpoint regime can not forward such packets.
In most embodiments, devices 110 only manage a single anycast dialog sequence at a time. Therefore, if one of devices 110 receives an anycast message of a differing session ID and requester ID than its active log, it may choose to ignore the new message. In some embodiments, each device 110 involved in an anycast dialog sequence keeps its own timeout, based on the value received in routing template 2108 of the request frame 1410. After the timeout expires, the anycast dialog sequence may be reset.
When forwarding an anycast request in a multi-hop routing sequence, the timeout may be reduced to account for the elapsed time of the forwarding process, including the duration of the forwarded wakeup packet 1300 and request packet 1410 itself. In some embodiments, deliverance of anycast command acknowledgements, if enabled, precedes the forwarding of the request. A device 110 that has previously forwarded an anycast request does not forward any further anycast requests bearing the same session ID until the anycast timeout expires. Similarly, a device that has forwarded an anycast response cannot forward another anycast response with the same response device ID and session ID until the anycast timeout has expired.
Forwarding a response frame back to the requesting device can be subject to some interpretation, depending on the sophistication of the routing algorithm. In some embodiments, response forwarding performs a recursive tracing of the routing path on which the request has traversed. However, if a device determines that it may skip one or more hops back to the requesting device, it may opt to do so.
If frame 2100 is a request frame 1410, then anycast request routing template 2502 utilized for template 2108 include an originating device ID 2504, a forwarded device ID 2506, hops remaining 2508, anycast timeout 2510, response channel 2512, start offset 2514, compare code 2516, mask length 2518, mask 2520, and compare value 2522. As discussed previously, origin device ID 2504 can be a 2 or 8 byte device ID of the original requester. Forwarder device ID 2506 can be a 2 or 8 byte device ID of a forwarding device in a multi-hop routing. As before, the origin device ID can be the VID or UID of requester device 110. The forwarder device ID is the ID of a device 110 that forwarded the request. Hops remaining 2508 indicates the number of transfers yet to occur before forwarding ceases. Timeout 2510 can be a 2 byte anycast timeout. The anycast timeout is the number of ms until the entire anycast dialog sequence times out and should be decremented in every forwarding. Response channel ID 2512 includes the response channel to utilize. Start offset 2514 can be a one byte Start offset. Compare code 2516 can be a one byte compare code defined as discussed above. Mask length 2518 can be one byte indicating the length N of the mask. Mask 2520 then can be an N byte mask. Compare value 2522 can be an N byte compare value to use in the comparison. As discussed above, the compare code can be, for example, given by 0x00: compare value≠ masked value; 0x01: compare value=masked value; 0x02: compare value<masked value; 0x03: compare value≦masked value; 0x04: compare value>masked value; and 0x05: compare value≧masked value. The start offset provides the byte offset into the data element being masked. The mask length N is the number of bytes in the mask and the compare value. In some embodiments, N can be from 0 to 64. The mask is an N byte bitmask. The compare value is an N byte value that provides a relationship to the masked data element. As discussed below, the data element can be identified in command data 2110.
b) illustrates an anycast response routing template 2524. As shown in
Command operational codes (opcodes) are provided above with respect to Table 14 above. As discussed above, the opcode field can be provided in the lower four bits of command code 2104 of frame 2100, as shown in
CRC16 2112 is the CRC16 code described above. In some commands, command data 2110 and CRC16 2112 may not be included in frame 2100.
In some cases, a response packet 1404 is followed by an associated data packet 1504 as shown in
As shown in Table 14 above, there are various types of command codes that can be executed. In particular, Table 14 shows inventory commands, collection commands, and announcement commands.
Inventory commands request short responses that include device IDs of responding devices 110. For broadcast, unicast, anycast, and multicast routing types, inventory commands use the templates provided in the command code with a command extension in the form of an UDB element ID. In broadcast routing all devices respond, in unicast routing only the addressed device responses (essentially in acknowledgement), and in multicast/anycast routing devices 110 that pass the comparison test respond. The responses bear no data additional from that included in the default response templates and therefore do not utilize data packets.
a) illustrates an example of an inventory request frame 2602, which is an example of request frame structure 2100. As show in
b) illustrates an inventory response frame 2604. Response frame 2604 includes header 2102, command code 2104, a routing template 2108 where routing template 2108 is a unicast routing template 2310.
a) illustrates an inventory from UDB element request frame 2702. In an inventory from a UDB data element, the comparison takes place with respect to the specific UDB element, so the maximum length of masks and value is less than or equal to the length of the specified UDB element. With broadcast or unicast request, there is no explicit comparison, so the recipient device will respond only if it contains the specified UDB element and its length is greater than 0. As such, inventory from UDB element request frame 2702 includes protocol header 2102, command code 2104, command extension 2106, routing template 2108, and command data 2110. Command data includes UDB element ID 2704 that identifies the particular UDB data element.
b) illustrates an inventory from UDB element response frame 2706. Response frame 2706 includes header 2102, command code 2104, and routing template 2108 that holds uncast routing template 2310.
a) illustrates a collection of UDB element request frame 2802. Collection commands are requests that return responses with either single UDB elements or multiple UDB elements in the form of UDB type codes. There can be several types of collections, for example collections commands can return the device ID, a UDB element, or a UDB type code. Searches can include any device in range or a selected device in the range. Collection commands take a UDB element ID as a comparison input. With multicast collection request, the comparison takes place on the specified UDB element, so the maximum length of masks and value is less than or equal to the length of the UDB element. With broadcast, anycast, or unicast request there is no explicit comparison, so the reception device responds only if it includes the specified UDB element and its length is greater than 0.
As such, a collection of UDB element request frame 2802 includes protocol header 2102, command code 2104, routing template 2108, and command data 2110. Command data 2110 includes a one byte comparison UDB element ID 2804 and a one byte return UDB element ID 2806. The comparison UDB element ID 2804 is utilized to perform a comparison if in multicast or anycast routing. The return UDB element ID 2806 is the UDB element to be returned.
A collection of UDB element response frame 2808 is illustrated in
a) illustrate a collection of UDB type request frame 2902. A collection of UDB type also specifies a UDB element type code that is to be returned in the response. As such, request frame 2902 for a collection of UDB type includes a protocol header 2102, a command code 2104, routing template 2108, and command data 2110. Routing template 2108 can be any of the available templates. Command data 2110 includes a comparison UDB element ID 2904 and a return UDB type code 2906. The comparison UDB element ID 2904 identifies the UDB element to use in a comparison if routing template 2108 is a multicast or anycast routing template. Return UDB type code 2906 identifies the UDB type codes to return.
b) illustrates an example of a collection of UDB type response frame 2908. In a collection of UDB type response, multiple UDB elements are transferred in series utilizing a type-length-data stream. As such, response frame 2908 includes protocol header 2102, command code 2104, routing template 2108 set to a unicast routing to the requesting device, and command data 2110 that includes a total UDB type length 2910, and a stream of UDB element ID 2912, UDB element length 2914, and UDB element data 216. The total UDB type length 2910 indicates the number of UDB elements to be returned. The UDB element ID 2912 identifies one of the UDB elements to be returned. UDB element length 2914 provides the length N of the data to be included in the UDB element data for the UDB element to be returned. UDB element data 2916 includes the N bytes of the UDB element data.
a) and 30(b) illustrate an announcement of UDB element request frame 3002 and an announcement of UDB type request frame 3010, respectively. Announcement commands are unsolicited packets that include UDB data. Announcement commands can only be transmitted by devices 110 in subcontroller or gateway regimes. Responses to an announcement command, an example of which is illustrated in announcement response frame 3020 in
As shown in
Similarly, as shown in
Data frame commands are requests that initiated extended dialogs. The data frames themselves are utilized with encapsulated protocols.
a) illustrates a request data dialog 3100 according to some embodiments of the present invention. The example of request data dialog 3100 in
b) illustrates a dialog 3113 where data is being transmitted from requesting device 3102 to one or more response devices 3104. Dialog 3113 can be either unicast or multicast routing. As shown in
As shown, the request and response of the data frame commands is the same as in any other command. Data frames 1510 are transmitted utilizing the guidelines discussed above. Transmission of data frames 3110 is preceded by non-arbitrated CSMA process 1700 as discussed above unless data 3110 is being transmitted on the same transport channel as response 3108 within the MGT.
Acknowledgments 3112 is a request frame or response frame as illustrated in
c) illustrates a state diagram 3124 describing data dialog 3100 and 3113 as illustrated in
Both request and propose data frames (request frame 3106) may use command extension 2106, which is described in
a) illustrates a request data frame 3202. As shown in
b) illustrates a response data frame 3210 responsive to request data frame 3202. As shown in
If the no response bit in command extension 2106 is set in request data frame 3202, then response device 3104 will be unable to report memory allocation errors in advance of the data frame reception. That is similarly true for propose data frame 3216 shown in
As shown in
d) illustrates the response frame 3228 that is responsive to propose data frame 3216. As shown in
e) illustrates an acknowledgment request frame 3230. As illustrated in
As shown in
Routing template 2108 can be any routing template, but is typically unicast routing template 2302 or multicast routing template 2402. Command data 2110 includes data frame channel 3232, number of damaged frames 3234, and list of damaged frame IDs 3236. Data frame channel 3232 is the transport channel ID over which the undamaged data frames will be sent. The number of damaged frames 3234 indicates how many damaged frames will be sent. Damaged frame IDs 3236 indicates the identity of the damaged frames.
f) illustrates a response frame 3238 that responsive to acknowledgment request 3230. As shown in
a) and 33(b) illustrate an authentication command. In some embodiments, authentication can be performed using either public key encryption (also known as public/private key encryption) or private key encryption. The encapsulated protocol is utilized in order for a requester device to authenticate itself as the root or admin of a responder device. After authenticating, all frame data transmitted between the authenticating device and the authenticated device can be encrypted using the methods provided by the encryption system. When the key utilized between the devices expires, the authentication can reset, and further frame traffic between these devices will be unencrypted until re-authorization. As discussed above, devices 110 can keep a table of different keys and key lifetimes that correspond to different other devices 110.
As shown in
b) shows an example of authentication response frame 3308. As shown, response frame 3308 includes protocol header 2102, command code 2104, routing template 2108, and command data 2110. Routing template 2108 is a unicast response template 2310. Command data 2110 includes key protocol data 3310, which can be public/private key protocols or private key protocols.
Encapsulated protocols are subprotocols used primarily in the data frame, but also can be utilized in certain other commands. System 100 can support any number of subprotocols. Some examples of subprotocols are provided here.
a) illustrates a UDB protocol request or response frame 3402. The UDB protocol is a read/write mechanism that can be used exclusively with data frame commands. For example, the UDB protocol can be utilized for batch reading and writing of UDB elements. The UDB protocol can also be utilized for the reading and writing of UDB type strings. Further, the UDB protocol can be utilized for batch altering of UDB element and type string privileges.
The UDB protocol request and response is initiated in the request and response of data frame controls. The UDB protocol can be encapsulated into data frames 1510, which is structured as discussed above with respect to
An implicit command behavior can also be utilized, for example in a request data frame as illustrated in
Data offset 3406 provides an offset into the total data element string to start the read or write operation. In some embodiments, data offset 3406 can be two bytes in length, thereby indicating a value between 0 and 65535. Data length 3408 provides the number of bytes to read or write after the offset value in data offset 3406. Data length 3408 may be two bytes as well. Data elements 3410 provides the element IDs, type codes, or privilege codes for each of the N elements that are indicated in number of elements 3414.
b) illustrates the UDB protocol response 3416, which includes the command code 3404.
Data frames conveying UDB protocol data can include one or more data groups. A series of data groups in a single data frame dialog may be all of the same kind.
b) illustrate a UDB type data group 3514. As shown in
c) illustrates a UDB privileges data group 3526. Privileges group 3526 includes the element ID or type code 3528 and a privileges field 3530. Element or type code identifies the element or type of UDB data. Privileges 3530 is the privileges to be read or written.
An RDB protocol can be utilized for accessing the RDB blocks. The RDB protocol is similar to the UDB protocol in form and function, except that it accesses RDBs instead of UDBs. The RDB protocol can allow for batch random-offset reads or writes to a single RDB element. Further, the RDB protocol can allow for altering of RDB element privileges.
a) illustrates the RDB protocol command structure 3602. Again, implicit behavior indicates that read RDB data objects is implemented in a request data frame command structure 3602 included in a request data frame 3210 and write RDB data objects is implemented in a request frame command structure 3602 included in a proposal data frame 3216.
As shown in
RDB element 3606 provides the identification of the RDB element. Sector data descriptors provides, for each of the elements indicated in number of elements 3612, an offset 3622 and length 3624.
g) illustrates a RDB protocol command structure 3614 for a privilege code request. Structure 3614 includes RDB protocol command code 3604 and RDB element IDs 3618, one for each of the elements indicated by the number of elements 3612.
c) indicates a response 3620 to structure 3614. As shown, structure 3620 includes RDB protocol command code 3604.
a) and 37(b) indicate RDB protocol data groups. Data frames conveying RDB protocol data include one or more data groups. A series of data groups in a single data frame dialog should be of the same kind.
b) illustrates an RDB privileges data group 3714. Group 3714 includes an element ID 3716 and privileges 3718.
Other protocols can be implemented. For example, a private key protocol, a public key protocol, an IPv6 protocol, or an IEEE 1451.7 protocol can be implemented. Other protocols may be established for implementation with system 100 as well.
The examples provided above are exemplary only and are not intended to be limiting. One skilled in the art will recognize various modifications that can be affected to various aspects of the described embodiments of the invention. Those modifications are intended to be within the scope of this disclosure. As such, the invention is limited only by the following claims.
The present disclosure claims priority to U.S. Provisional Patent Ser. No. 61/246,615, filed on Sep. 29, 2009, and to U.S. Provisional Patent Ser. No. 61/320,382, filed on Apr. 2, 2010, both of which are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61246615 | Sep 2009 | US | |
| 61320382 | Apr 2010 | US |
