APPARATUS AND METHOD FOR ADVANCED COMMUNICATION IN LOW-POWER WIRELESS APPLICATIONS

• US 20110074552A1
• Filed: 09/29/2010
• Published: 03/31/2011
• Est. Priority Date: 09/29/2009
• Status: Abandoned Application

• Current Assignee: Savi Technology Incorporated
• Original Assignee: Savi Technology Incorporated
• Inventors: CARGONJA, NIKOLA, M HO, JOSEPH S., NORAIR, JOHN PETER
• Application Number:
  US12/893,790
• Publication Number:
  US 20110074552A1
• Time in Patent Office: Days
• US Class Current: 340/10.1
• CPC Class Codes: G06K 7/0008 General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
• CPC Class Codes: H04Q 2213/13095 PIN / Access code, authentication
• CPC Class Codes: H04W 52/0216 using a pre-established activity schedule, e.g. traffic indication frame
• CPC Class Codes: H04W 52/0229 where the received signal is a wanted signal
• CPC Class Codes: H04W 52/0235 where the received signal is a power saving command
• CPC Class Codes: Y02D 30/70 in wireless communication networks

Abstract

A low power device is presented. In some embodiments, the low power device communicates with other devices utilizing transport channels defined from combinations of a plurality of physical channels. In some embodiments, the low power device communicates with other devices utilizing packets that includes a preamble, a header with a sync and frame info, and a frame. The frame, for example, can be a wake-up frame, a request frame, a response frame, or one or more data frames. In some embodiments, the wake-up frame can include a count-down integer indicating the number of wake-up frames before a request frame is sent. In some embodiments, arbitration may be utilized between devices responding to a request. In some embodiments, specific requests commands can be included in the request frame and corresponding response frames are responsive to the commands.

Claims

1. A device, comprising:

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.

2. The device of claim 1, wherein the transceiver performs forward error correction encoding.

3. The device of claim 1, wherein the transceiver encodes the digital data utilizing data whitening.

4. The device of claim 1, wherein the transceiver is configured to transport data utilizing a modulation and an encoding.

5. The device of claim 4, wherein the encoding includes forward error correction.

6. The device of claim 4, wherein the encoding includes data whitening.

7. The device of claim 4, wherein the modulation includes frequency shift modulation (FSK).

8. The device of claim 7, wherein the modulation includes gaussian filtered frequency shift modulation (GFSK).

9. The device of claim 4, wherein the modulation and the encoding can be dynamically chosen from a group of supported modulation and encoding.

10. The device of claim 1, wherein the plurality of physical channels are channels positioned within a defined band.

11. The device of claim 10, wherein the defined band is a 433 MHz ISM band.

12. The device of claim 10, wherein the plurality of physical channels includes eight physical channels of width 216 kHz spanning the 433 MHz ISM band.

13. The device of claim 10, wherein the plurality of physical channels includes six physical channels of width 290 kHz spanning the 433 MHz ISM band.

14. The device of claim 10, wherein the plurality of physical channels includes seven physical channels of width 248 kHz spanning the 433 MHz ISM band.

15. The device of claim 10, wherein the set of defined transport channels includes one or more combinations of adjacent ones of the physical channels.

16. The device of claim 15, wherein a turbo transmission data rate can be performed utilizing one of the set of defined transport channels having the combination of adjacent physical channels.

17. The device of claim 15, where a normal transmission data rate can be performed utilizing transport channels that are defined with only one of the physical channels.

18. The device of claim 10, wherein at least one of the defined transport channels provides compatibility with a legacy device.

19. The device of claim 10, wherein the processor chooses a transport channel dynamically.

20. The device of claim 10, wherein the processor sets transport channels according to a preset rule.

21. The device of claim 10, wherein two or more transport channels are simultaneously utilized to transport data, wherein the data is split between the one or more transport channels and bonded.

22. The device of claim 1, wherein the transmission data rate of each of the transmission channels is adaptively chosen.

23. The device of claim 1, wherein the transmission data rate for each of the transmission channels is fixed.

24. A device, comprising:

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.

25. The device of claim 24, wherein the device in states, the states including one or more of an off state, a sleep state, a listen state, a receive state, a transmit state, a hold state, and an idle state

26. The device of claim 25, wherein the device operating in the endpoint regime

transitions from the sleep state to the listen state on a wake-on event;

transitions from the listen state to the receive state if a wake-up frame is detected or the RFID device is expecting a request frame and otherwise transitions to the sleep state;

transitions from the receive state to the transmit state after receiving a request frame and formulating a response frame for transmission, and otherwise transitions to the sleep state; and

transitions from the transmit state to the hold state upon instructions received in the request frame.

27. The device of claim 25, wherein the device operating in the subcontroller regime

transitions from the hold state to the listen state upon receipt of a wake-on event;

transitions from the hold state to the transmit state in order to transmit a request frame;

transitions from the listen state to the receive state in response to detection of an incoming frame;

transitions from the receive state to the transmit state if the incoming frame is a request frame to transmit a response frame;

transitions from the receive state to the hold state if the incoming frame is a response frame;

transitions from the transmit state to the listen state if an outgoing request frame is transmitted; and

transitions from the transmit state to the hold state upon completion of a dialog with another device.

28. The device of claim 25, wherein the device operating in the gateway regime

transitions from a listen state to a receive state upon receipt of a response frame;

transitions from the listen state to a transmit state to transmit a request frame; and

transitions from the transmit state to the listen state after transmission of the request frame.

29. The device of claim 24, wherein the device is configured with other devices in a star network.

30. The device of claim 24, wherein the device is configured with other devices in a tree network.

31. The device of claim 24, wherein the device is configured with other devices in a mesh network.

32. The device of claim 24, wherein the device is configured with other devices in a network that allows hopping of requests and responses through the network.

33. The device of claim 25, wherein the device in the off state is off and the device transitions from the off state by receipt of an external trigger.

34. The device of claim 25, wherein the sleep state is a low power state and the device exits the sleep state on detection of a wake-on event, wherein a wake-on event includes a wake-up frame in a wakeup packet, a sensor alarm, a RF transmission, or a scheduling event.

35. The device of claim 34, wherein the device in the sleep state

activates from a low power operation periodically to check for a carrier;

returns to the lower power operation if the carrier is not detected;

checks for a wake-up frame if the carrier is detected;

returns to the low power operation of the wake-up frame is not detected;

returns to the low power operation for a nap period indicated if the wake-up frame if the wake-up frame is detected; and

exits the sleep state at the end of the nap period if the wake-up frame is detected.

36. The device of claim 35, wherein if more than one transport channel is activate then the device activates periodically such that each active transport channel is scanned during a scan time period.

37. The device of claim 36, wherein each active transport channel is scanned on a configurable frequency.

38. The device of claim 35, wherein the device activates from the lower power state according to a schedule and a real-time clock.

39. The device of claim 38, where each active transport channel is scanned on a configurable schedule.

40. The device of claim 25, where the device is in a hold state

transitions to the listen state if the hold state is asynchronous and a previous state was the transmit or the receive state;

transitions to the idle state if the hold state is asynchronous and the previous state was the listen state;

transitions to the listen state if the hold state is asynchronous and a timeout condition has occurred or transitions to the idle state if the hold state is synchronous and the timeout condition has occurred;

transitions to the transmit state if a hold period has expired and the hold state is synchronous; and

transitions to a listen state if the hold period has expired and a wake-up frame is detected.

41. The device of claim 25, wherein in the transmit state the device performs an arbitration.

42. The device of claim 41, wherein the arbitration is a scheduled transmission slot and the device

checks a schedule against a real-time clock for the scheduled transmission slot, and

transmits on one of the transport channels on the scheduled transmission slot.

43. The device of claim 41, wherein the arbitration is a non-arbitrated carrier sense multiple access procedure.

44. The device of claim 43, wherein the device

picks a transport channel;

checks to determine whether the transport channel is clear;

if the transport channel is clear, the device then waits a period of time and rechecks the transport channel to determine whether the transport channel is still clear;

if the transport channel is still clear, then clear the channel for transmission;

if the transport channel is not clear on either the check or the recheck, determine whether a time-out has occurred, otherwise wait a second period of time and then pick a second transport channel.

45. The device of claim 41, wherein the arbitration is an arbitrated carrier sense multiple access procedure.

46. The device of claim 45, wherein the device

listens for a request from an arbitrator

compares with the request to determine if the device is being addressed;

returns to listen for another arbitrator request after a fixed wait if the device is not being addressed;

checks a transport channel indicated by the request to see if it is clear;

if the transport channel is clear, waits a period of time and then rechecks the transport channel to see if it is still clear and responds if the transport channel is still clear;

if the transport channel is not clear, then check for a time out and waits for a wait period.

47. The device of claim 46, wherein if there is insufficient time to respond or if the time out has occurred, then the device waits for a next window.

48. A device, comprising:

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.

49. The device of claim 48, wherein the preamble is a recurring data pattern of non-return-to-zero signal.

50. The device of claim 48, wherein the header includes a frame sync and a frame identification.

51. The device of claim 50, wherein the frame sync is a non-return-to-zero signal configured for data boundary detection and filtering.

52. The device of claim 50, wherein the frame ID indicates the type of frame and includes flags indicating one or more of the following:

encoding, encryption, frame sub-type, and parity.

53. The device of claim 48, wherein the packet is wake-up packet and the frame is a wake-up frame.

54. The device of claim 53, wherein the wake-up packet is one of a plurality of wake-up packets transmitted in a wake-up chain and the wake-up frame includes an integer indicating the number of wake-up packets yet to be transmitted before a request packet is transmitted.

55. The device of claim 48, wherein the packet is a request packet and the frame is a request frame.

56. The device of claim 55, wherein the request frame includes a protocol header, a command code, a routing template, and command data.

57. The device of claim 56, wherein the request frame further includes a command extension.

58. The device of claim 56, wherein the request frame further includes a CRC16 integer.

59. The device of claim 56, wherein the command code includes an extension flag, a sleep flag, a routing type, and an opcode.

60. The device of claim 59, wherein the extension flag indicates presence of a command extension.

61. The device of claim 59, wherein the routing type can be one of a unicast routing, a multi-cast routing, a broadcast routing, or an anycast routing.

62. The device of claim 61, wherein the routing type is the unicast routing and the routing template includes a requester device ID, a response timeout, and a response channel.

63. The device of claim 61, wherein the routing type is the multicast routing and the routing template is a multicast initial request template that includes a requester device ID, a window duration, an arbitration guard time, a start offset, a multicast compare code, a window compare code, a mask length, a mask, a multicast compare value, and a window compare value.

64. The device of claim 63, wherein the routing type is the multicast routing and the routing template is a multicast arbitration request template that includes a requester device ID, a window compare code, a mask length, a window compare value, a number of ACKs and one or more ACK device IDs.

65. The device of claim 61, wherein the routing type is the broadcast routing and the routing template includes a requester device ID, a response timeout, a number of response transport channels, and identification for each of the response transport channels.

66. The device of claim 61, wherein the routing type is the anycast routing and the routing template includes an origin device ID, a forwarder device ID, a number of hops remaining, an anycast timeout, one or more response transport channel IDs, a start offset, a compare code, a mask length, a mask, and a compare value.

67. A device, comprising:

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.

68. The device of claim 67, wherein the request frame includes a protocol header, a command code, a routing template, and command data.

69. The device of claim 68, wherein the request frame further includes a command extension.

70. The device of claim 68, wherein the request frame further includes a CRC16 integer.

71. The device of claim 68, wherein the command code includes an extension flag, a sleep flag, a routing type, and an opcode.

72. The device of claim 71, wherein the routing type is a unicast routing, a multicast routing, or a broadcast routing and the routing template includes a requester ID and a responder ID.

73. The device of claim 71, wherein the routing type is the anycast routing and the routing template includes an origin device ID, a responder ID, and a forwarder device ID.

74. The device of claim 67, wherein the response frame is an error response frame, the routing template is a unicast routing template, and the command data includes an error code, an error subcode, and error data.

75. The device of claim 67, wherein each data frame includes a protocol ID, a frame length, a number of frames remaining, a frame number, and encapsulated data.

76. The device of claim 75, wherein the data frames further includes a CRC16 integer.

77. The device of claim 75, wherein the encapsulated data includes data elements that are stored in the memory.

78. The device of claim 75, wherein the frame includes a protocol header, the protocol header including a protocol ID, a frame length, device flags, and a session ID.

79. The device of claim 78, wherein the device flags include one or more of the following:

a NACK, a system fault, a low battery, and a sensor alarm.

80. The device of claim 68, wherein the frame includes command data.

81. A device, comprising

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.

82. The device of claim 81, wherein data elements includes one or more the following:

universal data block (UDB) elements, raw data block (RDB) elements, un-addressable elements, real-time clock elements, key table elements, device ID elements, protocol ID elements, privileges and authentication elements.

83. The device of claim 82, wherein the device ID elements can be a universal ID or a virtual ID.

84. The device of claim 82, wherein the un-addressable elements are user-defined elements.

85. The device of claim 82, wherein the protocol element provides for the protocols supported by the device.

86. The device of claim 82, wherein the privileges and authentication element includes privilege and authentication data.

87. The device of claim 82, where in the UDB elements includes one or more of device proprietary data, standard device settings, PHY configurations, real time scheduler, sleep scan periods, hold scan periods, protocol lists, UDB type code lists, RDB element lists, Location data lists, IPv6 addressing, IPv6 elements, sensor lists alarm lists, authentication keys, routing codes, user IDs, hardware faults, and extended services lists.

88. A device, comprising:

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.

89. The device of claim 88, wherein the routing type is one of a unicast routing, a multi-cast routing, a broadcast routing, or an anycast routing.

90. The device of claim 89, wherein the opcode indicates an inventory from device ID.

91. The device of claim 90, wherein

the request frame includes the header, the command code, and wherein the routing template can be appropriate for the unicast routing, the multi-cast routing, the broadcast routing, or the anycast routing.

92. The device of claim 90, wherein the response frame includes the header, the command code, and the routing template is appropriate for the unicast routing.

93. The device of claim 89, wherein the opcode indicates an inventory from UDB element.

94. The device of claim 93, wherein the request packet includes the protocol header, the command code, the routing template, and a UDB element ID.

95. The device of claim 93, wherein the response packet includes the protocol header, the command code, and the routing template is appropriate for the unicast routing.

96. The device of claim 89, wherein the opcode indicates a collection of UDB element.

97. The device of claim 96, wherein the request packet includes the protocol header, the command code, the routing template, a comparison UDB element ID, and a return UDB element ID.

98. The device of claim 96, wherein the response packet includes the protocol header, the command code, the routing template appropriate for the unicast routing, a UDB element ID, a UDB element length, and a UDB element data.

99. The device of claim 89, wherein the opcode indicates a collection of UDB type.

100. The device of claim 99, wherein the request template includes the protocol header, the command code, the routing template, a comparison UDB element ID, and a return UDB type code.

101. The device of claim 99, wherein the response template includes the protocol header, the command code, the routing template appropriate for the unicasts routing, a total UDB type length, a UDB element ID, a UDB element length, and a UDB element data.

102. The device of claim 89, wherein the opcode indicates an announcement of UDB element.

103. The device of claim 102, wherein the request frame includes the protocol header, the command code, the routing template, a UDB element ID, a UDB element length, and a UDB element data.

104. The device of claim 102, wherein the response frame includes the protocol header, the command code, and a routing template appropriate for the unicast routing.

105. The device of claim 89, wherein the opcode indicates an announcement of UDB type.

106. The device of claim 105, wherein the request frame includes the header, the command code, the routing template, a total UDB type, an UDB element ID, an UDB element length, an UDB element data.

107. The device of claim 105, wherein the response frame includes the header, the command code, and the routing template appropriate for the unicast response template.

108. The device of claim 89, wherein the opcode is a request data.

109. The device of claim 108, wherein the request frame includes the header, the command code, the routing template appropriate for the unicast routing, a data frame channel, an encapsulated protocol ID, and encapsulated protocol data.

110. The device of claim 108, wherein the response frame includes the header, the command code, the routing template appropriate for the unicast routing, a number of data frames, and a total data length.

111. The device of claim 110, wherein the response frame is followed by data frames consistent with the number of data frames and the total data length.

112. The device of claim 89, wherein the opcode is a propose data frame.

113. The device of claim 112, wherein the request frame includes the header, the command code, the routing template appropriate for the unicast routing or the multicast routing, a data frame channel, a number of data frames, a total data length, a encapsulated protocol ID, and encapsulated protocol data.

114. The device of claim 113, wherein the response frame includes the header, the command code, and the routing template appropriate for the unicast routing.

115. The device of claim 114, wherein the device receives a data packet consistent with the request frame.

116. The device of claim 89, wherein the opcode is an acknowledge data frame.

117. The device of claim 116, wherein the request frame includes the header, the command code, the routing template, a data frame channel, a number of damaged frames, and a list of damaged frame IDs.

118. The device of claim 116, wherein the response packet includes the header, the command code, the routing template appropriate for the unicast routing, the number of data frames, and the total data length and is followed by data frames consistent with the number of data frames.

119. The device of claim 89, wherein the opcode is an authentication request.

120. The device of claim 119, wherein the request frame includes the header, the command code, the routing template, a key lifetime, and a key protocol data.

121. The device of claim 119, wherein the response frame includes the header, the command code, the routing template appropriate for the unicast response, and key protocol data.

122. The device of claim 89, wherein the request frame includes a UDB protocol command structure, the UDB protocol command structure includes a command code, a data offset, a data length, and data elements.

123. The device of claim 122, wherein a corresponding UDB protocol command structure includes the command code.

124. The device of claim 89, wherein the request frame is a UDB protocol command structure and further includes a command code, a data offset, a data length, and data elements.

125. The device of claim 89, wherein the request frame is a UDB element data group and further includes an element ID, element privileges, element length, element offset, and element data.

126. The device of claim 89, wherein the request frame is a UDB type data group and further includes a type code, type code privileges, type string length, type string offset, and type string data.

127. The device of claim 89, wherein the request frame is a UDB privileges data group and further includes an element ID and privileges.

128. The device of claim 89, wherein the request frame is an RDB protocol command structure and further includes an RDB command code, an element ID, and sector data descriptors.

129. The device of claim 89, wherein the request frame is a RDB protocol command structure and further includes an RDB command code and RDB element IDs.

130. The device of claim 89, wherein the request frame is an RDB element data group and further includes an element ID, element privileges, a sector offset, a sector length, and sector data.

131. A method of activating a RFID device from a sleep state, comprising:

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.

132. The method of claim 131, wherein the wake-on signal is detection of a wake-up frame upon periodic scanning of one or more transport channels, and further including:

determining a time duration until receipt of a request frame from data received in the wake-up frame;

napping for the time duration;

transitioning to a listen state.

133. The method of claim 132, wherein the data received in the wake-up frame is a count-down integer indicating the number of wake-up frames yet to be sent and determining the time duration includes calculating the time duration based on the number of wake-up frames yet to be sent and a duration of each wake-up frame.

134. The method of claim 131, wherein the wake-on signal is detection of a sensor alarm, and further including:

transitioning to a transmit state;

transmitting an unsolicited request frame reporting the sensor alarm.

135. The method of claim 131, wherein the wake-on signal is a scheduled time determined by comparing a real-time clock with a schedule.

136. A method of activating an RFID device from a hold state, comprising:

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.

137. A method of performing a dialog between a requesting RFID device and one or more responding RFID devices, comprising:

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.

138. The method of claim 137, further including the responding RFID devices transmitting a data packet to the requesting RFID device.

139. The method of claim 137, wherein the chain of wake-up packets include a plurality of wake-up packets, each of the wake-up packets including a wake-up frame that provides an indication of the time in which the request packet will arrive.

140. The method of claim 139, wherein the indication includes a count-down integer indicating the number of wake-up packets yet to be received.

141. The method of claim 137, wherein the request packet in includes a request frame that provides instructions to the responding RFID device regarding how to respond and providing an indication of which of a number of RFID devices are responding RFID devices.

142. The method of claim 141, wherein the request frame identifies a unicast routing where a single responding RFID device based on an ID of the RFID device to be the responding RFID device.

143. The method of claim 141, wherein the request frame identifies a multicast routing where a plurality of single responding RFID devices based on a data element stored in the responding RFID devices, wherein responding devices and further including synchronously arbitrating transmission of response frames from each of the responding RFID devices.

144. The method of claim 141, wherein the request frame identifies an anycast routing where a plurality of single responding RFID devices based on a data element stored in the responding RFID devices and further including asynchronously arbitrating transmission of response frames from each of the responding RFID devices.

145. The method of claim 141, wherein the request frame identifies a broadcast routing, where all of the available RFID devices are identified as responding RFID devices, and further including asynchronously arbitrating transmission of response frames from each from the responding RFID devices.

146. The method of claim 145, wherein asynchronously arbitrating transmission of response frames, comprises:

choosing a potential transport channel from the plurality of transport channels;

performing a first check on the potential transport channel to determine whether it is clear;

if the potential transport channel is clear, waiting a set time and performing a second check on the potential transport channel;

if the second check on the potential transport channel is clear, then clearing the state and allowing transmission on the potential transport channel; and

if either the first check or the second check is not clear, waiting a period of time, choosing a different potential transport channel.

147. The method of claim 143, wherein synchronously arbitrating comprises:

from a listen state, listening for an arbitrator request;

performing a mask compare to determine if the responding RFID device is to respond in a next window and, if not, returning to the listen state;

performing a first check on the potential transport channel identified in the arbitrator request to determine whether it is clear;

if the potential transport channel is clear, waiting a set time and performing a second check on the potential transport channel;

if the second check on the potential transport channel is clear, then clearing the state and allowing transmission of a response frame on the potential transport channel; and

if either the first check or the second check is not clear, waiting a period of time, returning to the listen state.

148. A method of receiving data from a responding device, comprising:

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.

149. The method of claim 148, wherein the acknowledging receipt indicates defects in the one or more data frames and further including:

receiving one or more corrected data frames from the responding device; and

acknowledging receipt of the one or more corrected data frames.

150. A method of transmitting data to a responding device, comprising:

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.

151. A method of communicating with another device, comprising:

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.

152. A method of operating a low power device, comprising:

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.

153. The method of claim 152, wherein operating in the endpoint regime includes

transitioning from a sleep state to a listen state on a wake-on event;

transitioning from the listen state to a receive state if a wake-up frame is detected or the RFID device is expecting a request frame and otherwise transitioning to the sleep state;

transitioning from the receive state to the transmit state after receiving a request frame and formulating a response frame for transmission, and otherwise transitioning to the sleep state; and

transitioning from the transmit state to a hold state upon instructions received in the request frame.

154. The method of claim 152, wherein operating in the subcontroller regime includes

transitioning from a hold state to a listen state upon receipt of a wake-on event;

transitioning from the hold state to a transmit state in order to transmit a request frame;

transitioning from the listen state to a receive state in response to detection of an incoming frame;

transitioning from the receive state to the transmit state if the incoming frame is a request frame to transmit a response frame;

transitioning from the receive state to the hold state if the incoming frame is a response frame;

transitioning from the transmit state to the listen state if an outgoing request frame is transmitted; and

transitioning from the transmit state to the hold state upon completion of a dialog with another device.

155. A method of claim 152, wherein operating in the gateway regime includes:

transitioning from a listen state to a receive state upon receipt of a response frame;

transitioning from the listen state to a transmit state to transmit a request frame; and

transitioning from the transmit state to the listen state after transmission of the request frame.

156. A method of communicating with a device, comprising:

exchanging packets from the device, the packet including a preamble, a header that includes a sync and frame info, and a frame.

157. The method of claim 156, where exchanging packets includes transmitting a request packet and receiving a response packet from the device.

158. The method of claim 156, wherein exchanging packets includes receiving a request packet and transmitting a response packet to the device.

159. The method of claim 156, wherein exchanging packets further includes transmitting or receiving data packets that includes one or more data frames.

160. The method of claim 156, wherein exchanging packets includes communicating data elements and further including storing data elements.

161. The method of claim 156, wherein exchanging packets includes transmitting a request packet that includes a command chosen from an inventory from device ID request, an inventory from UDB element;

a collection of UDB element;

a collection UDB type, an announcement of UDB element, an announcement of UDB type, a request data, a propose data, an acknowledge data frame, or an authentication.