U.S. patent application number 15/630440 was filed with the patent office on 2017-10-05 for method and apparatus for addressing in a resource-constrained network.
The applicant listed for this patent is Blackbird Technology Holdings, Inc.. Invention is credited to John Peter Norair.
Application Number | 20170289320 15/630440 |
Document ID | / |
Family ID | 46753245 |
Filed Date | 2017-10-05 |
United States Patent
Application |
20170289320 |
Kind Code |
A1 |
Norair; John Peter |
October 5, 2017 |
METHOD AND APPARATUS FOR ADDRESSING IN A RESOURCE-CONSTRAINED
NETWORK
Abstract
An electronic device may receive a protocol data unit (PDU)
comprising a plurality of addressing bits. Data-link-layer
processing of the PDU may be based on each of the addressing bits.
Network layer processing of the PDU may be based on a first subset
of the plurality of addressing bits. Transport-layer processing of
the PDU may be based on a second subset of plurality of addressing
bits. The data-link-layer processing may comprise determining
whether the PDU is unicast-addressed or non-unicast-addressed. For
a unicast-addressed PDU, the data-link-layer processing may
comprise determining whether the PDU is destined for the electronic
device based on a comparison of a Target ID field of the PDU and a
device ID of the electronic device. For a non-unicast-addressed
PDU, the Target ID field may not be present, and whether the PDU is
destined for the electronic device may be determined based on other
criteria.
Inventors: |
Norair; John Peter; (San
Francisco, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Blackbird Technology Holdings, Inc. |
Dover |
DE |
US |
|
|
Family ID: |
46753245 |
Appl. No.: |
15/630440 |
Filed: |
June 22, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15350517 |
Nov 14, 2016 |
|
|
|
15630440 |
|
|
|
|
13408461 |
Feb 29, 2012 |
9497715 |
|
|
15350517 |
|
|
|
|
61464376 |
Mar 2, 2011 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 1/0083 20130101;
Y02D 30/70 20200801; H04W 56/002 20130101; H04W 56/0025 20130101;
H04W 72/0446 20130101; H04L 49/555 20130101; H04W 56/001 20130101;
H04L 69/22 20130101; H04W 52/54 20130101; H04W 4/023 20130101; H04W
74/085 20130101; H04W 52/36 20130101; H04L 1/0061 20130101; H04L
43/0882 20130101; H04W 72/0473 20130101; H04L 47/822 20130101; H04L
43/0847 20130101; Y02D 70/166 20180101; H04W 52/243 20130101; H04B
17/318 20150115; H04L 47/12 20130101; H04W 48/08 20130101; H04W
40/023 20130101; H04W 28/04 20130101; Y02D 70/164 20180101; H04W
74/0808 20130101; Y02D 70/144 20180101; H04L 43/16 20130101; H04W
52/245 20130101; H04W 28/0205 20130101; H04W 74/0816 20130101; H04W
52/0235 20130101; Y02D 70/142 20180101; H04W 52/06 20130101; H04W
52/242 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04W 28/02 20060101 H04W028/02; H04L 12/911 20060101
H04L012/911; H04L 12/26 20060101 H04L012/26; H04W 56/00 20060101
H04W056/00; H04W 52/36 20060101 H04W052/36; H04B 17/318 20060101
H04B017/318; H04W 72/04 20060101 H04W072/04; H04W 52/24 20060101
H04W052/24; H04L 12/939 20060101 H04L012/939; H04W 74/08 20060101
H04W074/08; H04W 28/04 20060101 H04W028/04; H04W 40/02 20060101
H04W040/02; H04W 48/08 20060101 H04W048/08; H04W 4/02 20060101
H04W004/02; H04W 52/06 20060101 H04W052/06; H04W 52/02 20060101
H04W052/02; H04W 52/54 20060101 H04W052/54; H04L 1/00 20060101
H04L001/00; H04L 12/801 20060101 H04L012/801 |
Claims
1. A method performed by an electronic device, the method
comprising: receiving a protocol data unit (PDU) comprising a
plurality of addressing bits; performing data-link-layer processing
of said PDU based on each of said plurality of addressing bits;
performing network layer processing of said PDU based on a first
subset of said plurality of addressing bits; and performing
transport-layer processing of said PDU based on a second subset of
said plurality of addressing bits.
2. The method of claim 1, wherein said data-link-layer processing
of said PDU comprises determining whether said PDU is a
unicast-addressed PDU or non-unicast-addressed PDU.
3. The method of claim 2, wherein, in instances that said PDU is a
unicast-addressed PDU, said data-link-layer processing comprises
determining whether said PDU is destined for said electronic device
based on a comparison of a Target ID field of said PDU and a device
ID of said electronic device.
4. The method of claim 3, wherein, in instances that said PDU is a
non-unicast-addressed PDU, said Target ID field is not present in
said PDU and whether said PDU is destined for said electronic
device is determined based on criteria other than a device ID of
said electronic device.
5. The method of claim 2, wherein, in instances that said PDU is a
non-unicast-addressed PDU, said network-layer processing of said
PDU comprises determining whether said PDU comprises a Routing
Header field.
6. The method of claim 5, wherein, in instances that said PDU is a
non-unicast-addressed PDU, said transport-layer processing of said
PDU comprises determining whether said PDU comprises a Query
Template field.
7. The method of claim 6, wherein, during said transport-layer
processing of said PDU, said electronic device compares data in
said Query Template field to data stored in said electronic
device.
8. The method of claim 7, wherein, during said transport-layer
processing of said PDU, a result of said comparison is utilized to
determine whether said electronic device is an intended recipient
of said PDU.
9. The method of claim 7, wherein, during said transport-layer
processing of said PDU, a result of said comparison is utilized to
determine whether to forward said PDU to another electronic
device.
10. A communication system comprising: an electronic device
operable to: receive a protocol data unit (PDU) comprising a
plurality of addressing bits; perform data-link-layer processing of
said PDU based on each of said plurality of addressing bits;
perform network layer processing of said PDU based on a first
subset of said plurality of addressing bits; and perform
transport-layer processing of said PDU based on a second subset of
said plurality of addressing bits.
11. The communication system of claim 10, wherein said
data-link-layer processing of said PDU comprises determining
whether said PDU is unicast-addressed or non-unicast-addressed
PDU.
12. The communication system of claim 11, wherein, in instances
that said PDU is a unicast-addressed PDU, said data-link-layer
processing comprises determining whether said PDU is destined for
said electronic device based on a comparison of a Target ID field
of said PDU and a device ID of said electronic device.
13. The communication system of claim 12, wherein, in instances
that said PDU is a non-unicast-addressed PDU, said Target ID field
is not present in said PDU and whether said PDU is destined for
said electronic device is determined based on criteria other than a
device ID of said electronic device.
14. The communication system of claim 11, wherein, in instances
that said PDU is a non-unicast-addressed PDU, said network-layer
processing of said PDU comprises determining whether said PDU
comprises a Routing Header field.
15. The communication system of claim 14, wherein, in instances
that said PDU is a non-unicast-addressed PDU, said transport-layer
processing of said PDU comprises determining whether said PDU
comprises a Query Template field.
16. The communication system of claim 15, wherein, during said
transport-layer processing of said PDU, said electronic device
compares data in said Query Template field to data stored in said
electronic device.
17. The communication system of claim 16, wherein, during said
transport-layer processing of said PDU, a result of said comparison
is utilized to determine whether said electronic device is an
intended recipient of said PDU.
18. The communication system of claim 17, wherein, during said
transport-layer processing of said PDU, a result of said comparison
is utilized to determine whether to forward said PDU to another
electronic device.
19. A communication system comprising: an electronic device
operable to: receive a protocol data unit (PDU) comprising a
plurality of addressing bits; determine whether said received PDU
is unicast-addressed, anycast-addressed, multicast-addressed, or
broadcast-addressed PDU based on said plurality of addressing bits;
if said PDU is unicast-addressed, determine whether said PDU is
destined for said electronic device during data-link-layer
processing of said PDU; and if said PDU is anycast-addressed or
multicast-addressed, determine whether said PDU is destined for
said device during transport-layer processing of said PDU.
20. The communication system of claim 19, wherein: said
transport-layer processing comprises comparing a search token
contained in said PDU to data stored in said electronic device; and
determining that said PDU is intended for said electronic device if
a correlation between said search token and said data stored in
said electronic device is above a threshold.
Description
CLAIM OF PRIORITY
[0001] This patent application is a continuation of U.S. patent
application Ser. No. 15/350,517 filed on Nov. 14, 2016, which is a
continuation of U.S. patent application Ser. No. 13/408,461 filed
on Feb. 29, 2012, which in turn makes reference to, claims priority
to and claims benefit from U.S. Provisional Patent Application Ser.
No. 61/464,376 entitled "Advanced Communication System for
Wide-area Low Power Wireless Applications and Active RFID" and
filed on Mar. 2, 2011.
[0002] Each of the above-referenced applications is hereby
incorporated herein by reference in its entirety.
INCORPORATION BY REFERENCE
[0003] This patent application also makes reference to:
[0004] U.S. Provisional Patent Application Ser. No. 61/464,376
entitled "Advanced Communication System for Wide-Area Low Power
Wireless Applications and Active RFID" and filed on Mar. 2,
2011;
[0005] U.S. Provisional Patent Application Ser. No. 61/572,390
entitled "System for Adding Dash7-Based Applications Capability to
a Smartphone" and filed on Jul. 15, 2011;
[0006] U.S. patent application Ser. No. 13/267,640 entitled "Method
and Apparatus for Adaptive Searching of Distributed Datasets" and
filed on Oct. 6, 2011;
[0007] U.S. patent application Ser. No. 13/267,621 entitled "Method
and Apparatus for Low-Power, Long-Range Networking" and filed on
Oct. 6, 2011;
[0008] U.S. patent application Ser. No. 13/270,802 entitled "Method
and Apparatus for a Multi-band, Multi-mode Smartcard" and filed on
Oct. 11, 2011;
[0009] U.S. patent application Ser. No. 13/270,959 entitled "Method
and Apparatus for an Integrated Antenna" and filed on Oct. 11,
2011;
[0010] U.S. patent application Ser. No. 13/289,054 entitled "Method
and Apparatus for Electronic Payment" and filed on Nov. 4,
2011;
[0011] U.S. patent application Ser. No. 13/289,050 filed on Nov. 4,
2011;
[0012] U.S. patent application Ser. No. 13/297,348 entitled "Method
and Apparatus for Interfacing with a Smartcard" and filed on Nov.
16, 2011;
[0013] U.S. patent application Ser. No. 13/354,513 entitled "Method
and Apparatus for Memory Management" and filed on Jan. 20,
2012;
[0014] U.S. patent application Ser. No. 13/354,615 entitled "Method
and Apparatus for Discovering, People, Products, and/or Services
via a Localized Wireless Network" and filed on Jan. 20, 2012;
[0015] U.S. patent application Ser. No. 13/396,708 entitled "Method
and apparatus for Plug and Play, Networkable ISO 18000-7
Connectivity" and filed on Feb. 15, 2012;
[0016] U.S. patent application Ser. No. 13/396,739 entitled "Method
and Apparatus for Serving Advertisements in a Low-Power Wireless
Network" and filed on Feb. 15, 2012;
[0017] U.S. patent application Ser. No. 13/408,440 entitled "Method
and Apparatus for Forward Error Correction (FEC) in a
Resource-Constrained Network" and filed on Feb. 29, 2012;
[0018] U.S. patent application Ser. No. 13/408,447 entitled "Method
and Apparatus for Adaptive Traffic Management in a
Resource-Constrained Network" and filed on Feb. 29, 2012;
[0019] U.S. patent application Ser. No. 13/408,453 entitled "Method
and Apparatus for Dynamic Media Access Control in a Multiple Access
System" and filed on Feb. 29, 2012;
[0020] U.S. patent application Ser. No. 13/408,457 entitled "Method
and Apparatus for Rapid Group Synchronization" and filed on Feb.
29, 2012;
[0021] U.S. patent application Ser. No. 13/408,464 entitled "Method
and Apparatus for Query-Based Congestion Control" and filed on Feb.
29, 2012; and
[0022] U.S. patent application Ser. No. 13/408,466 entitled "Method
and Apparatus for Power Autoscaling in a Resource-Constrained
Network" and filed on Feb. 29, 2012.
[0023] Each of the above stated applications is hereby incorporated
herein by reference in its entirety.
FIELD OF THE INVENTION
[0024] Certain embodiments of the invention relate to networking.
More specifically, certain embodiments of the invention relate to a
method and apparatus for addressing in a resource-constrained
network.
BACKGROUND OF THE INVENTION
[0025] Existing methods and system for addressing in a wireless
network are inefficient. Further limitations and disadvantages of
conventional and traditional approaches will become apparent to one
of skill in the art, through comparison of such systems with some
aspects of the present invention as set forth in the remainder of
the present application with reference to the drawings.
BRIEF SUMMARY OF THE INVENTION
[0026] A method and/or apparatus is provided for addressing in a
resource-constrained network, substantially as illustrated by
and/or described in connection with at least one of the figures, as
set forth more completely in the claims.
[0027] These and other advantages, aspects and novel features of
the present invention, as well as details of an illustrated
embodiment thereof, will be more fully understood from the
following description and drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0028] FIG. 1 depicts exemplary communication devices which may
comprise a dynamically adaptable media access controller.
[0029] FIG. 2 is a diagram illustrating processing of a received
PDU as it traverses the physical layer, data link layer, and
transport layer in an electronic device.
[0030] FIGS. 3A and 3B illustrate an exemplary protocol data unit
(PDU) structure.
[0031] FIGS. 4A-4E depict the structure of exemplary portions of a
transport-layer PDU.
[0032] FIGS. 5A-5F depict the structure of exemplary portions of a
transport-layer PDU.
[0033] FIG. 6A is a flowchart depicting exemplary steps for
processing a broadcast-addressed PDU.
[0034] FIG. 6B is a flowchart depicting exemplary steps for
processing a multicast-addressed PDU.
[0035] FIG. 6C is a flowchart depicting exemplary steps for
processing an anycast-addressed PDU.
[0036] FIG. 6D is a flowchart depicting exemplary steps for
processing a unicast-addressed request PDU.
[0037] FIG. 6E is a flowchart depicting exemplary steps for
processing a unicast-addressed response PDU.
DETAILED DESCRIPTION OF THE INVENTION
[0038] As utilized herein the terms "circuits" and "circuitry"
refer to physical electronic components (i.e. hardware) and any
software and/or firmware ("code") which may configure the hardware,
be executed by the hardware, and or otherwise be associated with
the hardware. As utilized herein, "and/or" means any one or more of
the items in the list joined by "and/or". As an example, "x and/or
y" means any element of the three-element set {(x), (y), (x, y)}.
As another example, "x, y, and/or z" means any element of the
seven-element set {(x), (y), (z), (x, y), (x, z), (y, z), (x, y,
z)}. As utilized herein, the terms "block" and "module" refer to
functions than can be implemented in hardware, software, firmware,
or any combination of one or more thereof. As utilized herein, the
term "exemplary" means serving as a non-limiting example, instance,
or illustration. As utilized herein, the term "e.g.," "for
example," introduce a list of one or more non-limiting examples,
instances, or illustrations.
[0039] FIG. 1 depicts exemplary communication devices which may
comprise a dynamically adaptable media access controller. Shown in
FIG. 1 are details of an exemplary first device 102 and details of
an exemplary second device 104.
[0040] The CPU 204 may comprise circuitry operable to control
operation of the first device 102. The CPU 204 may, for example,
execute an operating system and/or other programs such (e.g.,
programs that enable a user interface of the device 102). The CPU
204 may generate one or more control signals for controlling the
operation of the device 102. The CPU 204 may, for example, control
a mode of operation of the device 102.
[0041] The CPU 214 may comprise circuitry operable to control
operation of the second device 104. In some instances, the CPU 214
may be substantially similar to the CPU 204. In instances that the
device 102 is less resource-constrained device, such as a base
station or network controller, and the device 104 is more
resource-constrained device, such as a battery-powered tag or a
smartcard as described in above-incorporated U.S. patent
application Ser. No. 13/270,802, the CPU 204 may be less-complex
(e.g., comprise fewer gates, utilize less power, utilize less
memory, etc.) than the CPU 214. In one embodiment, for example, the
CPU 204 may comprise a RISC or ARM processor, and the CPU 214 may
comprise a state-machine having a relatively small number of states
(e.g., four states).
[0042] The radio 207 may comprise a processor 208 and an analog
front-end (AFE) 209. The processor 208 may comprise circuitry
operable to interface with the AFE 209 to receive and transmit
data, and to process received and to-be-transmitted data. For
transmission, the processor 208 may be operable to receive data
from the CPU 204 and/or memory 206, encode, packetize, and/or
otherwise process the data to prepare it for transmission in
accordance with one or more wireless protocols, and output the data
to the AFE 209 for transmission. For reception, the processor 208
may be operable to receive data via the AFE 209, process the
received data and output received data to the memory 206 and/or the
CPU 204. Exemplary protocols which may be supported by the second
device 104 include the ISO 18000-7 standard, and protocols
described in the above-incorporated U.S. Provisional Patent
Application Ser. No. 61/464,376 filed on Mar. 2, 2011.
[0043] The radio 217 may comprise a processor 218 and an analog
front-end (AFE) 219. The baseband processor 218 may comprise
circuitry operable to interface with the AFE 219 to receive and
transmit data, and to process received and to-be-transmitted data.
In some instances, the baseband processor 218 may be substantially
similar to the baseband processor 208. In instances that the device
102 is less-resource-constrained device, such as a base station or
network controller, and the device 104 is a
more-resource-constrained device, such as a battery-powered tag,
the baseband processor 218 may be less-complex (e.g., comprise
fewer gates, utilize less power, utilize less memory, etc.) than
the baseband processor 208. In one embodiment, for example, the
baseband processor 208 may be operable to implement more complex
signal processing algorithms (e.g., FEC decoding) than the baseband
processor 218.
[0044] The analog front-end (AFE) 209 may comprise circuitry
suitable for processing received and/or to-be-transmitted data in
the analog domain. For transmission, the AFE 209 may receive
digital data from the baseband processor 208, process the data to
generate corresponding RF signals, and output the RF signals to the
antenna 210. For reception, the AFE 209 may receive RF signals from
the antenna 210, process the RF signals to generate corresponding
digital data, and output the digital data to the baseband processor
209. In some instances, the AFE 219 may be substantially similar to
the AFE 209. In instances that the device 102 is
less-resource-constrained device, such as a base station or network
controller, and the device 104 is a more-resource-constrained
device, such as a battery-powered tag, the AFE 219 may be
less-complex (e.g., comprise fewer gates, utilize less power,
utilize less memory, etc.) than the AFE 209. In one embodiment, for
example, the AFE 209 may comprise a more-sensitive receiver, a more
powerful transmitter than the AFE 219.
[0045] Circuitry of the memory 206 may comprise one or more memory
cells and may be operable to store data to the memory cell(s) and
read data from the memory cell(s). The one or more memory cell may
comprise one or more volatile memory cells and/or one or more
non-volatile memory cells. The memory 206 may store data arranged,
for example, as an indexed short file block (ISFB) and/or indexed
short file series block (ISFSB) as described in the
above-incorporated U.S. Provisional Patent Application Ser. No.
61/464,376.
[0046] Circuitry of the memory 216 may comprise one or more memory
cells and may be operable to read data from the memory cell(s)
and/or store data to the memory cell(s). The memory 216 may store
data arranged, for example, as an indexed short file block (ISFB)
and/or indexed short file series block (ISFSB) as described in the
above-incorporated U.S. Provisional Patent Application Ser. No.
61/464,376. In some instances, the memory 216 may be substantially
similar to the memory 206. In instances that the device 104 is
resource-constrained, the memory 216 may be less-complex (e.g.,
comprise fewer gates, utilize less power, etc.) than the memory
206.
[0047] Each of the clocks 211 and 221 may be operable to generate
one or more oscillating signals which may be utilized to control
synchronous circuitry of the device 100. The clock 211 may
comprise, for example, one or more crystal oscillators,
phase-locked loops, and/or direct digital synthesizers. The clock
211 may also comprise a "date/time" or "real-time" clock operable
to keep track of time of day, day of week, day of month, month,
and/or year.
[0048] The interfaces 212 and 222 may enable configuring and/or
programming the devices 102 and 104, respectively. In an exemplary
embodiment, one or more values of one or more timing parameters may
be programmed via the programming interfaces 212 and/or 222.
[0049] Each of the antennas 210 and 220 may be operable to transmit
and receive electromagnetic signals in one or more frequency bands.
In an embodiment of the invention, the antennas 210 and 220 may be
operable to transmit and receive signals in the ISM frequency band
centered at 433.92 MHz.
[0050] In operation, the device 102 may be, for example, a base
station or network controller, and the device 104 may be a mobile
device such as a smart phone or a smartcard. The devices 102 and
104 may communicate via the radios 207 and 217. Each protocol data
unit (PDU) communicated between the devices 102 and 104 may utilize
one of the following four types of addressing: broadcast, unicast,
multicast, and anycast.
[0051] As utilized herein, a broadcast-addressed PDU is destined
for all devices. Accordingly, the device 102/104 may treat all
received broadcast-addressed PDUs as being destined for the device
102/104.
[0052] As utilized herein, a unicast-addressed PDU is destined for
a specific device which has a device ID that matches a Target ID
field of the unicast PDU. Accordingly, the device 102/104 may treat
a received unicast-addressed PDU as being destined for the device
102/104 only if the Target ID field of the PDU matches the device
ID of the device 102/104.
[0053] As utilized herein, a multicast-addressed PDU is destined
for any one or more devices which meet certain criteria (other than
Target ID). Accordingly, the device 102/104 may treat a received
multicast-addressed PDU as being destined for the device 102/104
only if the device 102/104 meets certain criteria set forth in the
PDU.
[0054] As utilized herein, an anycast-addressed PDU is destined for
any one or more devices which meet certain criteria and may be
forwarded by devices which do not meet the certain criteria.
Accordingly, the device 102/104 may treat a received
anycast-addressed PDU as being destined for the device 102/104 only
if the device 102/104 meets certain criteria set forth in the PDU.
Furthermore, the device 102/104 may treat a received
anycast-addressed PDU as not being destined for the device 102/104
if the device 102/104 does not meets certain criteria set forth in
the PDU. The device 102/104 may, nevertheless, forward the
anycast-addressed PDU that was not destined for it.
[0055] FIG. 2 is a diagram illustrating processing of a received
PDU as it traverses the physical layer, data link layer, and
transport layer in an electronic device. As shown in FIG. 2, the
physical-layer PDU comprises a preamble 232, a sync word 234, and a
payload 236. The physical layer may synchronize to the preamble and
inspect the sync word. The physical layer may remove the preamble
232 and synch word 234 and pass the payload 236 to the data link
layer. The payload 236 passed to the data link layer may comprise
header 238 and a payload 240. The data link layer may inspect the
header 238 and process the PDU accordingly. The data link layer may
pass both the header 238 and the payload 240 to the network layer.
The network layer may inspect the header 238 and a header 242 which
was contained in the payload 240. The network layer may then
perform routing based on the headers 238 and/or 242. The network
layer may pass the header 238, the header 242, and the payload 244
to the transport layer. The transport layer may inspect the header
238, the header 242, and the header 246 and process the PDU
accordingly.
[0056] FIGS. 3A and 3B illustrate an exemplary protocol data unit
(PDU) structure. Referring to FIG. 3A, the physical layer PDU 302
comprises a preamble 308, a sync word 306, and a payload 304. The
payload 304 comprises a data link layer PDU 310 which, in turn,
comprises a length field 320, a header 318, a payload 316, a footer
314, and a CRC field 312. The header 318, in turn, comprises a
frame header 330, a DLLS header 328, an address control header 326,
a source ID field 324, and a target ID field 322. The frame header
330 comprises a TxEIRP field 332, a subnet field 334, and a frame
control field 336. The DLLS header 328 comprises a data link layer
security (DLLS) code field 338 and DLLS initialization data field
340. The Address control header 326 comprises a dialog identifier
field 342, and a flags field 344. The frame control field 336
comprises a listen flag 346, a DLLS flag 348, an enable addressing
flag 350, a frame continuity flag 352, a CRC32 flag 354, a not mode
2 flag 356, and a mode 2 frame type field 358. The flags field 344
comprises an addressing option field 260, a virtual ID flag 362, a
network layer security flag 364, and application flags 366 The
addressing option field comprises a Query Template flag 360 and a
No Routing Header flag 362.
[0057] The preamble 308 comprises a series of bits to enable a
device receiving the PDU to synchronize its circuitry. The sync
word field 306 indicates whether the PDU 302 is a foreground or
background PDU (background PDUs may be utilized, for example, for
synchronization as described in the above-incorporated U.S. patent
application Ser. No. 13/408,457.
[0058] The length field 320 indicate the length of the PDU 310. The
payload 316 is described below with respect to FIG. 3B. The footer
field 314 is utilized for data link layer security (DLLS). The
cyclic redundancy check (CRC) field 312 is used to determine
whether the PDU 310 was received without errors.
[0059] The TxEIRP field 332 indicates the power at which the PDU
302 was transmitted. The subnet field 334 is utilized for
addressing the PDU 310 to certain devices. The listen flag 346
indicate whether the device that transmitted the PDU 302 will
listen for responses. The DLLS flag 348 indicates whether the DLLS
header 328 is present. The enable addressing flag 350 indicates
whether the address control header 326 and the source ID field 324
are present. The frame continuity flag 352 indicates whether
another PDU should immediately follow the PDU 302. The CRC32 flag
354 indicates a CRC algorithm utilized for the PDU 310. The
not-mode-2 flag 356 indicates whether the frame type field has an
unspecified/proprietary value and/or whether a header extension
field is present. The mode 2 frame type field 358 indicates a type
of the PDU 310 (e.g., whether the PDU 310 is a dialog frame, a
dialog NACK, or a stream frame).
[0060] The addressing option field 360 indicates whether the PDU
310 is broadcast, multicast, anycast, or unicast addressed. In an
exemplary embodiment, if the contents of the addressing option
field 360 are determined to be `00` during data-link-layer
processing of the PDU 310, the PDU 310 is determined to be a
unicast-addressed PDU. If the contents of the addressing option
field 360 are determined to be other than `00` during
data-link-layer processing of the PDU 310, the PDU 310 is treated
as a broadcast-addressed PDU at the data link layer. The Query
Template flag 360 indicates whether a Query Template is present in
the network layer PDU 316 (described below with respect to FIG.
3B). The No Routing Header flag 360 indicates whether a Routing
Header 386 is present in the network layer PDU 316 (described below
with respect to FIG. 3B).
[0061] The source ID field 324 contains a device-specific
identifier of the device which transmitted the PDU 310. The target
ID field 322 is present if the PDU 310 is unicast-addressed and
contains the device-specific identifier of a device for which the
unicast-addressed PDU 310 is destined.
[0062] Now referring to FIG. 3B, the network layer PDU 320
comprises a header 382, a payload 383, and a Mode 2 Network Layer
Security (M2NLS) authorization data 384. The header 382 comprises
an M2NLS header 385 and a Routing Header 386. The M2NLS header 385
comprises M2NLS code field 387, M2NLS initialization data field
388, and a target address field 389. The M2NLS code field 387
defines the usage of the M2NLS initialization data field 388. The
M2NLS initialization data field 388 contains initialization data
for a security process. The target address field 389, when present
(e.g., because NLS is in use), contains the same device ID as is
contained in the Target ID field 322.
[0063] The Routing Header 386 comprises a hop control field 390, a
hop extension field 391, an origin device ID field 392, and a
destination device ID field 393. The hop control field 390
comprises an extension field flag 394, an Origin ID flag 395, a
destination ID flag 396, a VID flag 397, and a hops remaining field
398. The extension field flag 394 indicates whether the hop
extension field 391 is present in the PDU. The Origin ID flag 395
indicates whether the Origin device ID field 392 is present in the
PDU. The destination ID flag 396 indicates whether the Destination
device ID field 392 is present in the PDU. The VID flag 397
indicates whether the Origin device ID field 393 and the
Destination device ID field 393 is a hardware-unique ID or a
virtual ID. The hops remaining field 398 indicates the number of
hops remaining before forwarding of the PDU must cease. The hop
extension field 389 contains data relevant to the routing/hopping
algorithm in use. The origin device ID field 390 contains a
device-specific identifier 390 of the device from which the PDU 320
originated. The destination device ID field 391 contains a
device-specific identifier 390 of the ultimate destination of the
PDU 320.
[0064] The payload 383 comprises a transport-layer PDU comprising a
command code field 374, a command extension field 375, and one or
more of the templates 376-381 described with respect to FIGS.
4A-4E. The command code field 374 comprises an extension flag 367,
a command type field 368, and an opcode field 370. The extension
flag 367 indicates whether the command extension field 375 is
present. The command type field 368 indicates a network protocol
associated with the PDU 320, whether the PDU 320 is a response, an
error response, an initial request, an intermediate request, or a
final request. The opcode field 370 indicates the type of transport
layer PDU contained in the PDU 320. The command extension field 375
comprises a collision avoidance (CA) type field 371, a no collision
sense multiple access (CSMA) field 372, and a no response field
373. The collision avoidance type field 371 indicates an algorithm
or equation to be utilized for calculating parameter values
utilized for CSMA and/or other functions. The no CSMA flag 372
indicates whether devices responding to the PDU 320 should utilize
CSMA when responding. The no response flag 373 indicates whether
devices receiving the PDU 320 should send a response.
[0065] FIGS. 4A-4E depict the structure of exemplary portions of a
transport-layer PDU. In FIG. 4A, the dialog template 376 comprises
a response timeout field, a response channel list length field, and
a response channel list. In FIG. 4B, the ack template 377 comprises
a number of ack fields and an ack device IDs field. In FIG. 4C, the
query template 378/379 comprises a compare length field, a compare
code field, a compare mask field, and a compare value field. The
compare code field may comprise a mask enable flag, a comparison
type field, and a comparison parameters field. In FIG. 4D, the
error template 380 comprises an error code field, an error subcode
field, an M2QP error data field, and an extended error data field.
In FIG. 4E, the command data template 381 comprises one or more of
a comparison template, a call template, a return template, and
command-specific data which is the data indicated by the one or
more present comparison, call, and/or return templates. The various
templates of the command data template are described below with
respect to FIGS. 5A-5F.
[0066] FIGS. 5A-5F depict the structure of exemplary portions of a
transport-layer PDU. In FIG. 5A, for an opcode field 370 that
indicates file, the comparison template comprises a comparison file
ID and a comparison byte offset. In FIG. 5B, for an opcode field
370 that indicates series, the comparison template comprises a
comparison series ID and a comparison byte offset. In FIG. 5C, for
an opcode field 370 that indicates file, the call template
comprises a max returned bytes field, a return file ID, and a
return file entry offset. In FIG. 5D, for an opcode field 370 that
indicates series, the call template comprises a max returned bytes
field, a series ID, and a file series data offset. In FIG. 5E, for
an opcode field 370 that indicates file, the return template
comprises a return file ID, a file offset, an IFSB total length,
and file data. In FIG. 5F, for an opcode field 370 that indicates
series, the return template comprises a series ID, a series length,
a file series data offset, a file series total data length, one or
more file IDs, one or more file lengths, and a file series data
starting offset.
[0067] Additional details of the frames and fields described above
with respect to FIGS. 3A-5F, and possible other
structures/configurations of the PDU, are described in the
above-incorporated U.S. Provisional Patent Application Ser. No.
61/464,376.
[0068] FIG. 6A is a flowchart depicting exemplary steps for
processing a broadcast-addressed PDU. The exemplary steps begin
with step 602 when a device (e.g., the device 104) receives a
broadcast-addressed PDU. In step 604, during physical-layer
processing of the received PDU, the contents of the sync word field
306 may be verified to be a valid and/or desired sync word. If not,
the received PDU may be discarded. In step 606, the device 104 may
strip-off the preamble 308 and the sync word field 306 and pass the
PDU to the data link layer.
[0069] In step 608, a CRC check may be performed on the received
PDU, if the CRC check fails, the PDU may be discarded. In step 610,
the device 104 may inspect the subnet field 334 to confirm that the
device 104 is on the subnet for which the PDU is intended. If not,
the PDU may be discarded. In step 612, the device 104 may determine
the difference between the power at which the PDU was received vs.
the power at which it was transmitted. Based on this metric, the
PDU may be discarded if, for example, it requires a response and it
would require too much power to transmit that response. In step
614, the device 104 may inspect the addressing options field 360
and determine that the PDU is non-unicast-addressed. In step 616,
the PDU may be passed to the network layer.
[0070] In step 618, the No Routing Header flag 362 may be inspected
to determine that the Routing Header field 386 is not present in
the PDU. In step 620, the PDU may be passed to the transport
layer.
[0071] In step 622, the device 104 may inspect the Query Template
flag 362 and determine that a Query Template field 378 is not
present in the PDU. In step 624, the device 104 may further process
the PDU, generate and transmit a response to the PDU, and/or
generate and transmit an acknowledgment of the PDU.
[0072] FIG. 6B is a flowchart depicting exemplary steps for
processing a multicast-addressed PDU. The exemplary steps begin
with step 630 when a device (e.g., the device 104) receives a
multicast-addressed PDU. In step 632, during physical-layer
processing of the received PDU, the contents of the sync word field
306 may be verified to be a valid and/or desired sync word. If not,
the received PDU may be discarded. In step 634, the device 104 may
strip-off the preamble 308 and the sync word field 306 and pass the
PDU to the data link layer.
[0073] In step 636, a CRC check may be performed on the received
PDU, if the CRC check fails, the PDU may be discarded. In step 638,
the device 104 may inspect the subnet field 334 to confirm that the
device 104 is on the subnet for which the PDU is intended. If not,
the PDU may be discarded. In step 640, the device 104 may determine
the difference between the power at which the PDU was received vs.
the power at which it was transmitted. Based on this metric, the
PDU may be discarded if, for example, it requires a response and it
would require too much power to transmit that response. In step
642, the device 104 may inspect the addressing options field 360
and determine that the PDU is not-unicast-addressed. In step 644,
the PDU may be passed to the network layer.
[0074] In step 646, the No Routing Header flag 362 may be inspected
to determine that the Routing Header field 386 is not present in
the PDU. In step 648, the PDU may be passed to the transport
layer.
[0075] In step 650, the device 104 may inspect the Query Template
flag 362 and determine that one or more Query Template fields
378/379 are present in the PDU. In step 652, the device 104 may
perform a comparison as set forth by the one or more Query Template
fields 378/379. In step 654, the device 104 may determine whether
it is a device for which the PDU is destined based on the results
of the comparison. If the device 104 is not a destination device of
the PDU, then in step 658 the device 104 may discard the PDU. If
the device 104 is a destination device of the PDU, then in step 656
the device 104 may further process the PDU, generate and send a
response to the PDU, and/or generate and send an acknowledgment of
the PDU.
[0076] FIG. 6C is a flowchart depicting exemplary steps for
processing an anycast-addressed PDU. The exemplary steps begin with
step 660 when a device (e.g., the device 104) receives an
anycast-addressed request PDU. In step 662, during physical-layer
processing of the received PDU, the contents of the sync word field
306 may be verified to be a valid and/or desired sync word. If not,
the received PDU may be discarded. In step 664, the device 104 may
strip-off the preamble 308 and the sync word field 306 and pass the
PDU to the data link layer.
[0077] In step 666, a CRC check may be performed on the received
PDU, if the CRC check fails, the PDU may be discarded. In step 668,
the device 104 may inspect the subnet field 334 to confirm that the
device 104 is on the subnet for which the PDU is intended. If not,
the PDU may be discarded. In step 670, the device 104 may determine
the difference between the power at which the PDU was received vs.
the power at which it was transmitted. Based on this metric, the
PDU may be discarded if, for example, it requires a response and it
would require too much power to transmit that response. In step
672, the device 104 may inspect the addressing options field 360
and/or the Frame Type field 358 and determine that the PDU is a
non-unicast-addressed request. In step 674, the PDU may be passed
to the network layer.
[0078] In step 676, the No Routing Header flag 362 may be inspected
to determine that the Routing Header field 386 is present in the
PDU. In step 678, the Routing Header field 386 may be processed to
determine if and/or how the PDU should be forwarded if
transport-layer processing of the PDU indicates that the PDU may be
forwarded. In step 680, the PDU may be passed to the transport
layer.
[0079] In step 682, the device 104 may inspect the Query Template
flag 362 and determine that one or more Query Template fields
378/379 are present in the PDU. In step 684, the device 104 may
perform a comparison as set forth by the one or more Query Template
fields 378/379. In step 686, the device 104 may determine whether
it is a device for which the PDU is destined based on the results
of the comparison. If the device 104 is not a destination device of
the PDU, then in step 690 the device 104 may forward the PDU in
accordance with the Routing Header field 386 (e.g., forward the PDU
if the Routing Header field 386 indicates there are one or more
hops remaining). If the device 104 is a destination device of the
PDU, then in step 688 the device 104 may further process the PDU,
generate and send a response to the PDU, and/or generate and send
an acknowledgment of the PDU.
[0080] FIG. 6D is a flowchart depicting exemplary steps for
processing a unicast-addressed request PDU. The exemplary steps
begin with step 601 when a device (e.g., the device 104) receives a
unicast-addressed request PDU. In step 603, during physical-layer
processing of the received PDU, the contents of the sync word field
306 may be verified to be a valid and/or desired sync word. If not,
the received PDU may be discarded. In step 605, the device 104 may
strip-off the preamble 308 and the sync word field 306 and pass the
PDU to the data link layer.
[0081] In step 607, a CRC check may be performed on the received
PDU, if the CRC check fails, the PDU may be discarded. In step 609,
the device 104 may inspect the subnet field 334 to confirm that the
device 104 is on the subnet for which the PDU is intended. If not,
the PDU may be discarded. In step 611, the device 104 may determine
the difference between the power at which the PDU was received vs.
the power at which it was transmitted. Based on this metric, the
PDU may be discarded if, for example, it requires a response and it
would require too much power to transmit that response. In step
613, the device 104 may inspect the addressing options field 360
and/or the Frame Type field 358 and determine that the PDU is a
unicast-addressed request. In step 615, the device 104 may verify
that the Target ID field 322 of the PDU matches the Device ID
(which may be a hardware-specific ID or a virtual ID) of the device
104. (If NLS is utilized, step 615 may be performed at the network
layer based on the Target Address field 389.) In step 617, the PDU
may be passed to the network layer.
[0082] In step 619, the No Routing Header flag 362 may be inspected
to determine that a Routing Header field 386 is not present in the
PDU. In step 621, the Routing Header field 386 may be processed to
determine if and/or how the PDU should be forwarded if
transport-layer processing of the PDU indicates that the PDU may be
forwarded. In step 623, the PDU may be passed to the transport
layer.
[0083] In step 625, the device 104 may inspect the Query Template
flag 362 and determine that a Query Template field 378/379 is not
present in the PDU. In step 627, the device 104 may inspect the
contents of the Target ID 322 and the Destination Device ID 393 and
determine if the device 104 may further process the PDU, generate
and send a response to the PDU, and/or generate and send an
acknowledgment of the PDU. In step 629 the device 104 may forward
the PDU in accordance with the Routing Header field 386 (e.g.,
forward the PDU if the Routing Header field 386 indicates there are
one or more hops remaining).
[0084] FIG. 6E is a flowchart depicting exemplary steps for
processing a unicast-addressed response PDU. The exemplary steps
begin with step 631 when a device (e.g., the device 104) receives a
unicast-addressed response PDU. In step 633, during physical-layer
processing of the received PDU, the contents of the sync word field
306 may be verified to be a valid and/or desired sync word. If not,
the received PDU may be discarded. In step 635, the device 104 may
strip-off the preamble 308 and the sync word field 306 and pass the
PDU to the data link layer.
[0085] In step 637, a CRC check may be performed on the received
PDU, if the CRC check fails, the PDU may be discarded. In step 639,
the device 104 may inspect the subnet field 334 to confirm that the
device 104 is on the subnet for which the PDU is intended. If not,
the PDU may be discarded. In step 641, the device 104 may determine
the difference between the power at which the PDU was received vs.
the power at which it was transmitted. Based on this metric, the
PDU may be discarded if, for example, it requires a response and it
would require too much power to transmit that response. In step
643, the device 104 may inspect the addressing options field 360
and/or the Frame Type field 358 and determine that the PDU is a
unicast-addressed response. In step 645, the device 104 may verify
that the Target ID field 322 of the PDU matches the Device ID
(which may be a hardware-specific ID or a virtual ID) of the device
104. (If NLS is utilized, step 645 may be performed at the network
layer based on the Target Address field 389.) If the contents of
the Target ID field 322 match the device ID of device 104, then the
exemplary steps may advance to step 647.
[0086] In step 647, the PDU may be passed to the network layer. In
step 649, the No Routing Header flag 362 may be inspected to
determine that the Routing Header field 386 is present in the PDU.
In step 651 the device 104 may forward the PDU in accordance with
the Routing Header field 386 (e.g., forward the PDU if the Routing
Header field 386 indicates there are one or more hops remaining).
In step 655, the PDU may be passed to the transport layer. In step
657, the device 104 may inspect the Query Template flag 362 and
determine that a Query Template field 378/379 is not present in the
PDU. In step 659 the device 104 may further process the PDU and/or
generate and send an acknowledgment of the PDU.
[0087] Returning to step 645, if the contents of the Target ID
field 322 do not match the device ID of device 104, then the
exemplary steps may advance to step 653 in which the device 104 may
discard the PDU.
[0088] In accordance with an exemplary embodiment of the invention,
an electronic device 104 may receive a protocol data unit (PDU) 302
comprising a plurality of addressing bits in an Addressing Options
field 360. The device 104 may perform data-link-layer processing of
the PDU based on each bit of the Addressing Options field 360. The
device 104 may perform network layer processing of the PDU based on
a first subset (e.g., a Query Template flag 360) of the plurality
of addressing bits, and perform transport-layer processing of the
PDU based on a second subset (e.g., a No Routing Header flag 362)
of plurality of addressing bits. The data-link-layer processing of
the PDU may comprise determining whether the PDU is a
unicast-addressed PDU or non-unicast-addressed PDU.
[0089] In instances that the PDU is a unicast-addressed PDU, the
data-link-layer processing may comprise determining whether the PDU
is destined for the electronic device based on a comparison of a
Target ID field 322 of the PDU and a device ID of the electronic
device 104. In instances that the PDU is a non-unicast-addressed
PDU, the Target ID field 322 may not be present in the PDU and
whether the PDU is destined for the electronic device may be
determined based on criteria other than a device ID of the
electronic device 104 (e.g., based on a Query Template field). In
instances that the PDU is a non-unicast-addressed PDU, the
network-layer processing of the PDU may comprise determining
whether the PDU comprises a Routing header field. In instances that
the PDU is a non-unicast-addressed PDU, the transport-layer
processing of the PDU may comprise determining whether the PDU
comprises one or more Query Template fields 378/379.
[0090] During the transport-layer processing of the PDU, the
electronic device 104 may compare data in the Query Template
field(s) 378/379 to data stored in the electronic device (e.g., the
device 104 may search its memory 216 for a string contained in the
Query Template field and/or may determine compare the contents of a
memory location specified by the Query Template field 348/379 to a
value in the Query Template field 378/379). During the
transport-layer processing of the PDU, a result of the comparison
may be utilized to determine whether the electronic device 104 is
an intended recipient of the PDU. During the transport-layer
processing of the PDU, a result of the comparison may be utilized
to determine whether to forward the PDU to another electronic
device.
[0091] Other embodiments of the invention may provide a
non-transitory computer readable medium and/or storage medium,
and/or a non-transitory machine readable medium and/or storage
medium, having stored thereon, a machine code and/or a computer
program having at least one code section executable by a machine
and/or a computer, thereby causing the machine and/or computer to
perform the steps as described herein for addressing in a
resource-constrained network.
[0092] Accordingly, the present invention may be realized in
hardware, software, or a combination of hardware and software. The
present invention may be realized in a centralized fashion in at
least one computing system, or in a distributed fashion where
different elements are spread across several interconnected
computing systems. Any kind of computing system or other apparatus
adapted for carrying out the methods described herein is suited. A
typical combination of hardware and software may be a
general-purpose computing system with a program or other code that,
when being loaded and executed, controls the computing system such
that it carries out the methods described herein. Another typical
implementation may comprise an application specific integrated
circuit or chip.
[0093] The present invention may also be embedded in a computer
program product, which comprises all the features enabling the
implementation of the methods described herein, and which when
loaded in a computer system is able to carry out these methods.
Computer program in the present context means any expression, in
any language, code or notation, of a set of instructions intended
to cause a system having an information processing capability to
perform a particular function either directly or after either or
both of the following: a) conversion to another language, code or
notation; b) reproduction in a different material form.
[0094] While the present invention has been described with
reference to certain embodiments, it will be understood by those
skilled in the art that various changes may be made and equivalents
may be substituted without departing from the scope of the present
invention. In addition, many modifications may be made to adapt a
particular situation or material to the teachings of the present
invention without departing from its scope. Therefore, it is
intended that the present invention not be limited to the
particular embodiment disclosed, but that the present invention
will include all embodiments falling within the scope of the
appended claims.
* * * * *