U.S. patent application number 15/173790 was filed with the patent office on 2016-09-29 for method and apparatus for adaptive traffic management 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 | 20160285719 15/173790 |
Document ID | / |
Family ID | 46753245 |
Filed Date | 2016-09-29 |
United States Patent
Application |
20160285719 |
Kind Code |
A1 |
Norair; John Peter |
September 29, 2016 |
METHOD AND APPARATUS FOR ADAPTIVE TRAFFIC MANAGEMENT IN A RESOURCE-
CONSTRAINED NETWORK
Abstract
An electronic device may utilize or support adaptive traffic
management in a resource-constrained network. The adaptive traffic
management may comprise applying a multi-stage filtering to packets
received by the electronic device, wherein each stage of the
multi-stage filtering may comprises a validation check and a
failure of any validation check of any stage when handling a packet
terminates the handling of the packet. The adaptive traffic
management may comprise apply an adaptive search function, whereby
when the number of search responses received by the electronic
device exceeds a particular maximum response threshold, one or more
criteria for modifying search requests may be selected, to reduce
number of expected search responses, and the modified search
criteria may be applied to generated modified search command(s)
that are applied in the search function.
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/173790 |
Filed: |
June 6, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15075401 |
Mar 21, 2016 |
|
|
|
15173790 |
|
|
|
|
14519381 |
Oct 21, 2014 |
9325634 |
|
|
15075401 |
|
|
|
|
13408447 |
Feb 29, 2012 |
8867370 |
|
|
14519381 |
|
|
|
|
61464376 |
Mar 2, 2011 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 43/0882 20130101;
H04W 40/023 20130101; H04W 52/54 20130101; H04W 72/0446 20130101;
H04L 43/16 20130101; H04W 4/023 20130101; H04W 28/0205 20130101;
H04W 74/0808 20130101; H04L 49/555 20130101; H04W 52/0235 20130101;
H04W 52/242 20130101; H04L 1/0061 20130101; H04L 47/822 20130101;
H04W 56/001 20130101; H04L 47/12 20130101; Y02D 70/142 20180101;
H04W 56/0025 20130101; H04W 52/06 20130101; H04W 52/245 20130101;
H04L 69/22 20130101; H04W 48/08 20130101; H04W 56/002 20130101;
H04W 52/36 20130101; H04W 72/0473 20130101; H04W 74/085 20130101;
Y02D 70/164 20180101; H04W 52/243 20130101; H04L 43/0847 20130101;
Y02D 70/166 20180101; H04W 28/04 20130101; H04W 74/0816 20130101;
Y02D 70/144 20180101; Y02D 30/70 20200801; H04B 17/318 20150115;
H04L 1/0083 20130101 |
International
Class: |
H04L 12/26 20060101
H04L012/26; H04L 12/911 20060101 H04L012/911; H04L 12/939 20060101
H04L012/939 |
Claims
1. A method, comprising: in an electronic device comprising a
communication interface for communicating over a physical medium:
applying multi-stage filtering to packets received by said
electronic device, wherein: each stage of said multi-stage
filtering comprises a validation check, and a failure of any
validation check of any stage when handling a packet terminates
said handling of said packet; and at least one stage of said
multi-stage filtering comprises a check that said packet is
destined for said electronic device, and said check that said
packet is destined for said electronic device is determined based
on subnet masking.
2. The method of claim 1, comprising applying, in a first stage of
said multi-stage filtering, an error detection check to determine
whether said packet was corrupted during communication over said
physical medium.
3. The method of claim 2, wherein said error detection check
comprises a validation based on cyclic redundancy check (CRC) value
associated with said packet.
4. The method of claim 1, comprising applying, in a stage of said
multi-stage filtering, a check that communication of said packet
meets predetermined energy criteria.
5. The method of claim 4, comprising validating, during said
checking of whether said communication of said packet meets
predetermined energy criteria, that loss of energy associated with
said communication is less than a preconfigured threshold.
6. The method of claim 5, comprising determining said loss of
energy based on measurement of received signal strength indication
(RSSI) and original transmit power for said packet, said original
transmit power being obtained from information embedded in said
packet.
7. The method of claim 1, comprising comparing, during said subnet
masking based check, subnet-related parameters embedded in said
packet with subnet-related parameters in said electronic
device.
8. A system, comprising: an electronic device comprising a
communication interface for communicating over a physical medium,
said electronic device being operable to apply a multi-stage
filtering to packets received by said electronic device, wherein:
each stage of said multi-stage filtering comprises a validation
check, and a failure of any validation check of any stage when
handling a packet terminates said handling of said packet; and at
least one stage of said multi-stage filtering comprises a check
that said packet is destined for said electronic device, and said
check that said packet is destined for said electronic device is
determined based on subnet masking.
9. The system of claim 8, wherein said electronic device is
operable to apply, in a first stage of said multi-stage filtering,
an error detection check to determine whether said packet was not
corrupted during communication over said physical medium.
10. The system of claim 9, wherein said error detection check
comprises a validation based on cyclic redundancy check (CRC) value
associated with said packet.
11. The system of claim 8, wherein said electronic device is
operable to apply, in a stage of said multi-stage filtering, a
check that communication of said packet meets predetermined energy
criteria.
12. The system of claim 11, wherein said electronic device is
operable to validate, during said checking of whether said
communication of said packet meets predetermined energy criteria,
that loss of energy associated with said communication is less than
a preconfigured threshold.
13. The system of claim 11, wherein said electronic device is
operable to determine said loss of energy based on measurement of
received signal strength indication (RSSI) and original transmit
power for said packet, said original transmit power being obtained
from information embedded in said packet.
14. The system of claim 8, wherein said electronic device is
operable to compare during said subnet masking based check,
subnet-related parameters embedded in said packet with
subnet-related parameters in said electronic device.
15. A system, comprising: an electronic device that comprises a
communication interface for communicating over a physical medium,
said electronic device being operable to: determine, after
reception of a plurality of search responses from a plurality of
other electronic devices, whether the number of search responses
exceeds a maximum response threshold, wherein the search responses
are triggered by a first search request transmitted by said
electronic device; when the number of search responses exceeds said
maximum response threshold, generate a modified search request to
reduce number of expected search responses; and transmit said
modified search request.
16. The system of claim 15, wherein said generating said modified
search request comprises adjusting transmit power used when
transmitting said modified search request.
17. The system of claim 15, wherein said electronic device is
operable to adjust query parameters during said generating of said
modified search request such that query parameters embedded in said
modified search request are different than query parameters
embedded in said first search request.
18. The system of claim 17, wherein said query parameters comprise
one or more of: compare length, compare code, compare mask, and
compare value.
19. The system of claim 15, wherein said electronic device is
operable to adjust subnet-related parameters during said generating
of said modified search request such that subnet-related parameters
of said modified search request are different than subnet-related
parameters of said search request.
20. The method of claim 19, wherein said subnet-related parameters
comprise a subnet specifier and/or a subnet mask.
Description
CLAIM OF PRIORITY
[0001] This patent application is a continuation of U.S.
application Ser. No. 15/075,401, filed Mar. 21, 2016, which is a
continuation of U.S. application Ser. No. 14/519,381, filed Oct.
21, 2014, which is a divisional of U.S. application Ser. No.
13/408,447, filed Feb. 29, 2012, now U.S. Pat. No. 8,867,370, which
makes reference to, claims priority to and claims benefit from U.S.
Provisional Patent Application Ser. No. 61/464,376 which was filed
on Mar. 2, 2011, now expired.
[0002] The above-referenced application is hereby incorporated
herein by reference in its entirety.
CROSS-REFERENCE TO RELATED APPLICATIONS/INCORPORATION BY
REFERENCE
[0003] This patent application also makes reference to:
U.S. Provisional Patent Application Ser. No. 61/464,376 titled
"Advanced Communication System for Wide-Area Low Power Wireless
Applications and Active RFID" and filed on Mar. 2, 2011, now
expired; U.S. Provisional Patent Application Ser. No. 61/572,390
titled "System for Adding Dash7-Based Applications Capability to a
Smartphone" and filed on Jul. 15, 2011, now expired; U.S. Pat. No.
8,976,691 titled "Method and Apparatus for Adaptive Searching of
Distributed Datasets;" U.S. Pat. No. 9,042,353 titled "Method and
Apparatus for Low-Power, Long-Range Networking;" U.S. Pat. No.
8,718,551 titled "Method and Apparatus for a Multi-band, Multi-mode
Smartcard;" U.S. patent application Ser. No. 13/270,959 titled
"Method and Apparatus for an Integrated Antenna" and filed on Oct.
11, 2011, now abandoned; U.S. patent application Ser. No.
13/289,054 titled "Method and Apparatus for Electronic Payment" and
filed on Nov. 4, 2011, now abandoned; U.S. patent application Ser.
No. 13/289,050 titled "Method and Apparatus for Tire Pressure
Monitoring" and filed on Nov. 4, 2011, now abandoned; U.S. Pat. No.
8,622,312 titled "Method and Apparatus for Interfacing with a
Smartcard;" U.S. Pat. No. 9,104,548 titled "Method and Apparatus
for Memory Management;" U.S. patent application Ser. No. 13/354,615
titled "Method and Apparatus for Discovering, People, Products,
and/or Services via a Localized Wireless Network" and filed on Jan.
20, 2012, now abandoned; U.S. Pat. No. 8,909,865 titled "Method and
apparatus for Plug and Play, Networkable ISO 18000-7 Connectivity;"
United States Patent Publication No. 2012/0209716 titled "Method
and Apparatus for Serving Advertisements in a Low-Power Wireless
Network" and filed on Feb. 15, 2012; U.S. patent application Ser.
No. 13/408,440 titled "Method and Apparatus for Forward Error
Correction (FEC) in a Resource-Constrained Network" and filed on
Feb. 29, 2012, now abandoned; U.S. Pat. No. 9,191,340 titled
"Method and Apparatus for Dynamic Media Access Control in a
Multiple Access System;" U.S. Pat. No. 8,774,096 titled "Method and
Apparatus for Rapid Group Synchronization;" United States Patent
Publication No. 2012/0226822 titled "Method and Apparatus for
Addressing in a Resource-Constrained Network;" U.S. Pat. No.
8,885,586 titled "Method and Apparatus for Query-Based Congestion
Control;" U.S. Pat. No. 9,154,392 titled "Method and Apparatus for
Power Autoscaling in a Resource-Constrained Network."
[0004] Each of the above stated applications is hereby incorporated
herein by reference in its entirety.
FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
[0005] [Not Applicable].
MICROFICHE/COPYRIGHT REFERENCE
[0006] [Not Applicable].
FIELD OF THE INVENTION
[0007] Certain embodiments of the invention relate to
communications. More specifically, certain embodiments of the
invention relate to a method and an apparatus for adaptive traffic
management in a resource-constrained network.
BACKGROUND OF THE INVENTION
[0008] Existing methods of transmitting packets, and handling
received packets result in inefficient use of resources and/or
energy. 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
[0009] A system and/or method is provided for adaptive traffic
management in a resource-constrained network, substantially as
shown in and/or described in connection with at least one of the
figures, as set forth more completely in the claims.
[0010] 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 SEVERAL VIEWS OF THE DRAWINGS
[0011] FIG. 1 is a block diagram illustrating an exemplary
communication setup comprising a plurality of
spatially-distributed, resource-constrained devices, which may be
utilized in accordance with an embodiment of the invention.
[0012] FIG. 2 is a block diagram illustrating an exemplary
electronic device that may support optimized packet filtering, in
accordance with an embodiment of the invention.
[0013] FIG. 3A is a block diagram illustrating exemplary structure
of physical layer (PHY) packet carrying a data link layer frame, in
accordance with an embodiment of the invention.
[0014] FIG. 3B is a block diagram illustrating exemplary structure
of a subnet field in a data link layer frame, in accordance with an
embodiment of the invention.
[0015] FIG. 3C is a block diagram illustrating exemplary structure
of a data link frame utilized by a requester device in a
resource-constrained network to specify response criteria, in
accordance with an embodiment of the invention.
[0016] FIG. 4A is a block diagram illustrating an exemplary
implementation of the OSI model within an electronic device that
may support optimized packet filtering, in accordance with an
embodiment of the invention.
[0017] FIG. 4B is block diagram illustrating implementation of
various aspect of the invention at different layers of the OSI
model, in accordance with an embodiment of the invention
[0018] FIG. 5A is a flow chart that illustrates exemplary steps for
performing a multi-stage filtering process during handling of
received packets, in accordance with an embodiment of the
invention.
[0019] FIG. 5B is a flow chart that illustrates exemplary steps for
performing cyclic redundancy check (CRC) validation as one stage of
a multi-stage filtering process during handling of received
packets, in accordance with an embodiment of the invention.
[0020] FIG. 5C is a flow chart that illustrates exemplary steps for
performing subnet matching as one stage of a multi-stage filtering
process during handling of received packets, in accordance with an
embodiment of the invention.
[0021] FIG. 5D is a flow chart that illustrates exemplary steps for
performing link quality assessment as one stage of a multi-stage
filtering process during handling of received packets, in
accordance with an embodiment of the invention.
[0022] FIG. 6 is a flow chart that illustrates exemplary steps for
adjusting transmission criteria by a requester device to optimize
traffic in a resource-constrained network, in accordance with an
embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0023] Certain embodiments of the invention may be found in a
method and apparatus for adaptive traffic management in a
resource-constrained network. In various embodiments of the
invention, an electronic device may apply multi-stage filtering to
packets received by the electronic device. In this regard, the
multi-stage filtering may comprise a validation and/or a check in
each stage of the multi-stage filtering, whereby a failure of any
validation or check of any stage when handling a packet terminates
handling of the packet. Furthermore, at least one stage of the
multi-stage filtering comprises a check that the packet is destined
for the electronic device, and that check that the packet is
destined for the electronic device may be determined based on
subnet masking. In this regard, subnet masking based checks may
comprise comparing subnet-related parameters embedded in the packet
with subnet-related parameters in the electronic device. The
multi-stage filtering may comprise applying in a first stage an
error detection check to determine whether the packet was corrupted
during communication over the physical medium. In this regard, the
error detection check may comprise a validating the packet based on
cyclic redundancy check (CRC) value associated with the packet. The
multi-stage filtering may also comprise applying, in one of the
stages, a check that communication of the packet meets
predetermined energy criteria. In this regard, checking whether
communication of the packet meets predetermined energy criteria may
comprise validating that loss of energy associated with the
communication is less than a preconfigured threshold. The loss of
energy may be determined, for example, based on measurement of
received signal strength indication (RSSI) and original transmit
power for the packet, which may be obtained from information
embedded in the packet.
[0024] In an embodiment of the invention, an electronic device may
determine, after reception of a plurality of search responses from
a plurality of other electronic devices, whether the number of
search responses, which were triggered by a search request
transmitted by the electronic device, exceeds a maximum response
threshold. When the number of search responses exceeds the maximum
response threshold, the electronic device may generate a modified
search request to reduce number of expected search responses, and
transmit the modified search request. In this regard, generating
the modified search request may comprise adjusting transmit power
used in transmitting the modified search request. The electronic
device may also be operable to adjust query parameters during the
generating of the modified search request such that query
parameters embedded in the modified search request are different
than query parameters embedded in the initial search request. In
this regard, query parameters may comprise one or more of: compare
length, compare code, compare mask, and compare value. The
electronic device may also adjust subnet-related parameters during
the generating of the modified search request such that
subnet-related parameters of the modified search request are
different than subnet-related parameters of the search request. In
this regard, subnet-related parameters comprise a subnet specifier
and/or a subnet mask. The electronic device may, in response to the
search responses exceeding the maximum response threshold, and
prior to transmission of the modified search request, transmit one
or more frames to change the device subnet specifier stored in one
or more of the plurality of other electronic devices.
[0025] 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)}.
[0026] FIG. 1 is a block diagram illustrating an exemplary
communication setup comprising a plurality of
spatially-distributed, resource-constrained devices, which may be
utilized in accordance with an embodiment of the invention.
Referring to FIG. 1 there is shown a first device 102, second
devices 104.sub.1-104.sub.16, and perimeters
106.sub.1-106.sub.3.
[0027] The first device 102 may comprise suitable logic, circuitry,
interfaces, and/or code operable to transmit and receive wireless
signals in accordance with one or more wireless protocols.
Exemplary protocols which may be supported by the device 102 may
include the ISO 18000-7 protocol, and protocols described in the
above-incorporated U.S. Provisional Patent Application having Ser.
No. 61/464,376 and filed on Mar. 2, 2011. The first device 102 may
be less resource-constrained device. In this regard, the first
device 102 may be, for example and without limitation, a laptop
computer, a desktop computer, a tablet computer, a smart phone, a
server, a set-top box, a gateway, a base station, a meter or code
reader, or may comprise a combination of one or more such
devices.
[0028] Each of the second devices 104.sub.1-104.sub.16 may comprise
suitable logic, circuitry, interfaces, and/or code operable to
transmit and receive wireless signals in accordance with one or
more wireless protocols, which may include the ISO 18000-7
standard, and protocols described in the above-incorporated U.S.
Provisional Patent Application having Ser. No. 61/464,376 and filed
on Mar. 2, 2011. Each of the second devices 104.sub.1-104.sub.16
may be operable to store data (e.g., in the form of delimited
strings of characters). At least some of the second devices
104.sub.1-104.sub.16 may be more resource-constrained devices. In
this regard, one or more of the second devices 104.sub.1-104.sub.16
may have relatively little memory, relatively little processing
energy, operate on battery energy, and/or may otherwise be
constrained in terms of one or more resources. The second devices
104.sub.1-104.sub.16 may comprise, for example, RFID tags,
smartcards, keyfobs, cellphones, portable media players,
appliances, and/or utility meters.
[0029] The second devices 104.sub.1-104.sub.16 may be located at
different distances relative to the first device 102. Accordingly,
the perimeters 106.sub.1-106.sub.3 may represent and/or delineate
different zones of operations for the first device 102. Operating
at each of the perimeters 106.sub.1-106.sub.3 may correspond to,
for example, utilization of different transmit power levels by
device 102. That is, the device 102 may utilize a first transmit
power T.sub.1 to communicate with devices within the first
perimeter 106.sub.1, utilize a second transmit power T.sub.2 to
communicate with devices within the second perimeter 106.sub.2, and
utilize a third transmit power T.sub.3 to communicate with devices
within the third perimeter 106.sub.3, wherein
T.sub.3>T.sub.2>T.sub.1.
[0030] In operation, the device 102 may communicate one or more of
the devices 104.sub.1-104.sub.16. In this regard, communications
among the devices 102 and 104.sub.1-104.sub.16 may be based on the
ISO 18000-7 protocol, and/or similar protocols such as the
protocols described in the above-incorporated U.S. Provisional
Patent Application having Ser. No. 61/464,376 and filed on Mar. 2,
2011. Use of such protocols may be preferred for low-power, long
range communication, such as to enable RFID and like exchanges
among the devices 102 and 104.sub.1-104.sub.16. For example, at the
433 MHz band, low power communication based on such protocols may
be in the range of 1-2000 m. Establishing communications among the
devices 102 and 104.sub.1-104.sub.16 may comprise utilizing a
search mechanism to allow a device (e.g. device 102) to locate and
establish connectivity with one or more other devices (e.g. one or
more of devices 104.sub.1-104.sub.16). Cross-referenced U.S.
application Ser. No. 13/267,640, filed on Oct. 6, 2011, provides
more details on implementing and/or using adaptive search among a
plurality of devices, such as devices 102 and 104.sub.1-104.sub.16.
For example, the device 102 may initially search for particular one
or more of the devices 104.sub.1-104.sub.16. The search may be
performed by locating devices having a particular string (e.g., a
group of one or more ASCII or UNICODE characters). The device 102
may generate a search request packet and transmit the search
request packet. If the search request packet is transmitted at
energy T.sub.1, the search request packet may be received by
data-bearing devices 104.sub.1-104.sub.4. If the search request
packet is transmitted at energy T.sub.2, the search request packet
may be received by devices 104.sub.1-104.sub.8. If the search
request packet is transmitted at energy T.sub.3, the search request
packet may be received by devices 104.sub.1-104.sub.16. Note that
the above assumes signal propagation in the absence of interference
or physical obstructions that critically impair communications
between the device 102 and one or more of the devices
104.sub.1-104.sub.16.
[0031] In various embodiments of the invention, the devices 102 and
104.sub.1-104.sub.16 may be operable to support and/or utilize
adaptive traffic management, to enhance energy and/or resource
utilization in these devices. In this regard, such adaptive traffic
management may incorporate use of intelligent and/or adaptive
packet handling in the receiving devices, such as by use of
efficient and/or optimized packet filtering, to enable identifying
packets having particular characteristics promptly and efficiently,
to facilitate discarding and/or terminating handling of these
packets and doing so in a timely and efficient manner, thus
preventing unnecessary use of energy or resources. In an embodiment
of the invention, adaptive packet handling in the receiving devices
may incorporate use of optimized packet filtering, which may
comprise use of a multi-level filtering scheme. In this regard,
such multi-level filtering may be utilized to enable determining
when a packet (or frame carried therein) meets (or fails to meet) a
plurality of corresponding conditions. These conditions may be
determined by applying, at each level, a corresponding check or
validation step. Some of the conditions incorporated into, and/or
checked in the multi-level filtering scheme, may be adaptively set
or configured to force discarding packets (or frames). To further
enhance the filtering scheme, the various checks incorporated into
the multi-level filtering scheme may be ordered within the
multi-level scheme in a particular order that may achieve faster
resolution. In other orders, the order of the filtering checks may
be such in descending order based on likelihood of reaching a
discarding determination--that is a first check may have the
highest probability that a particular packet, the second check
having lesser probability that the particular packet would be
discarded, and so forth.
[0032] The adaptive traffic management may also incorporate use of
intelligent and/or adaptive management of functions in the devices
that may trigger communication and/or exchange of packets, to
enable controlling communication of packets in a manner that
optimizes energy consumption and/or resource utilization in the
devices, and/or bandwidth or channel utilization in the network.
For example, use of optimized search functions and/or policies by
requesting devices may enable controlling and/or limiting the
amount of responses, triggered by the search requests communicated
by the requesting devices, in accordance with the constraints of
the network and/or the capabilities--e.g., energy and/or
resources--of the responding and/or the requesting devices. The
search function may be optimized and/or enhanced by, for example,
adjusting the search criteria to reduce the number of responding
devices that would meet the search criteria and thus may
communicate responses; and/or by adjusting (e.g., reducing) the
transmit power used by the requesting device to control the search
range, and thus the number of potential responding devices. Another
adjustment may comprise modifying channel assignments in the
network to prevent any particular channel(s) from being overloaded
with response messaging while other channel(s) remain wholly or
partially un-utilized--i.e., implement intelligent channel
assignments to ensure balance load during search operations. These
same mechanisms may also be utilized in increasing the search range
and/or number of devices responding to search requests, such as
when energy and/or resource availability in the network and/or
devices improves to allow handling more responses.
[0033] FIG. 2 is a block diagram illustrating an exemplary
electronic device that may support optimized packet filtering, in
accordance with an embodiment of the invention. Referring to FIG. 2
there is shown an electronic device 200.
[0034] The electronic device 200 may be similar to the electronic
devices 102 and/or 104.sub.x of FIG. 1, and may comprise suitable
logic, circuitry, interfaces, and/or code that may be operable to
implement various aspects of the invention. The electronic device
200 may comprise, for example, a host processor 202, a system
memory 204, a signal processing module 206, a transmit front-end
(FE) 210, a transmission antenna 220, a plurality of receive
front-end (FE) 212.sub.A-212.sub.N, and plurality of reception
antennas 222.sub.A-222.sub.N.
[0035] The host processor 202 may comprise suitable logic,
circuitry, interfaces, and/or code that may be operable to process
data, and/or control and/or manage operations of the electronic
device 200, and/or tasks and/or applications performed therein. In
this regard, the host processor 202 may be operable to configure
and/or control operations of various components and/or subsystems
of the electronic device 200, by utilizing, for example, one or
more control signals. The host processor 202 may enable execution
of applications, programs and/or code, which may be stored in the
system memory 204, for example.
[0036] The system memory 204 may comprise suitable logic,
circuitry, interfaces, and/or code that may enable permanent and/or
non-permanent storage, buffering, and/or fetching of data, code
and/or other information, which may be used, consumed, and/or
processed in the electronic device 200. In this regard, the system
memory 204 may comprise different memory technologies, including,
for example, read-only memory (ROM), random access memory (RAM),
Flash memory, solid-state drive (SSD), and/or field-programmable
gate array (FPGA). The system memory 204 may store, for example,
configuration data, which may comprise parameters and/or code,
comprising software and/or firmware.
[0037] The signal processing module 206 may comprise suitable
logic, circuitry, interfaces, and/or code for enabling processing
of signals transmitted and/or received by the electronic device
200. The signal processing module 206 may be operable to perform
such signal processing operation as filtering, amplification,
up-convert/down-convert baseband signals, analog-to-digital
conversion and/or digital-to-analog conversion, encoding/decoding,
encryption/decryption, and/or modulation/demodulation. The signal
processing module 206 may be operable and/or configured to support
low-power wireless protocol, such as ISO 18000-7, protocols
described in above-incorporated U.S. Provisional Patent Application
No. 61/464,376, and/or similar related protocols.
[0038] The transmit FE 210 may comprise suitable logic, circuitry,
interfaces, and/or code that may be operable to perform wireless
transmission, such as over a plurality of supported RF bands. The
transmit FE 210 may enable, for example, performing wireless
communications of RF signals via the transmission antenna 220. In
this regard, the transmission antenna 220 may comprise suitable
logic, circuitry, interfaces, and/or code that may enable
transmission of wireless signals within certain bandwidths and/or
based on certain protocols. For example, one or more of the
transmission antenna 220 may enable transmission over the 433 MHz
band, which may be suitable for ISM communication based on, for
example, ISO 18000-7, protocols described in above-incorporated
U.S. Provisional Patent Application No. 61/464,376, and/or similar
related protocols.
[0039] Each of the plurality of receive FEs 212.sub.A-212.sub.N may
comprise suitable logic, circuitry, interfaces, and/or code that
may be operable to perform wireless reception, such as over a
plurality of supported RF bands. Each of the plurality of receive
FEs 212.sub.A-212.sub.N may enable, for example, performing
wireless communications of RF signals via corresponding one of the
plurality of reception antennas 222.sub.A-222.sub.N. Each of the
plurality of reception antennas 222.sub.A-222.sub.N may comprise
suitable logic, circuitry, interfaces, and/or code that may enable
reception of wireless signals within certain bandwidths and/or
based on certain protocols. For example, one or more of the
plurality of reception antennas 222.sub.A-222.sub.N may enable
reception of signals communicated over different channels within
the 433 MHz band, which may be suitable for ISM communication based
on, for example, ISO 18000-7, protocols described in
above-incorporated U.S. Provisional Patent Application No.
61/464,376, and/or similar related protocols.
[0040] In various embodiments of the invention, the electronic
device 200 may support and/or implement adaptive traffic
management, to enable optimizing energy consumption and/or resource
utilization in the electronic device 200 during communications of
signals. For example, the electronic device 200 may be operable to
use optimized packet handling during reception of signals. In this
regard, the electronic device 200 may be configured to implement
and utilize a multi-stage packet filtering. The electronic device
200 may also be configured to apply adaptive and/or intelligent
management of at least certain functions relating to transmission
of signals. For example, in instances where the electronic device
200 may execute search operations, the electronic device 200 may be
operable to use adaptive search function that may enable
controlling the number and/or characteristics of expected responses
in accordance with energy and/or resource constraints in the
electronic device 200, and/or network limitations.
[0041] FIG. 3A is a block diagram illustrating exemplary structure
of a physical layer (PHY) packet carrying a data link layer frame,
in accordance with an embodiment of the invention. Referring to
FIG. 3A, there is shown an exemplary physical layer (PHY) packet
carrying a data link layer frame, which may be structured in
accordance with wireless protocols utilized by electronic devices
that implement various aspects of the invention. Cross-referenced
U.S. application Ser. No. 13/408,453, filed on Feb. 29, 2012 (now
U.S. Pat. No. 9,191,340), and cross-referenced U.S. application
Ser. No. 13/408,461, filed on Feb. 29, 2012 (now published as
2012/0226822) provide more details on the structures of exemplary
PHY packets and/or data link layer frames.
[0042] The data link layer (DLL) frame carried in PHY packets may
comprise a length field, indicating the length of the DLL frame, a
header and a footer, providing information pertaining to the frame
and/or handling thereof, and payload field. The DLL frame may also
comprise a cyclic redundancy check (CRC) field 330. The header may
comprise transmit equivalent isotropic radiated power (TxEIRP)
field 310, which may indicate the original transmit power applied
by the transmitting device in transmitting the packet (or frame).
In other words, the TxEIRP field 310 embedded in the frame header
provides the receiving device with information pertaining to the
transmit power applied by the transmitting device, enabling the
receiving device to precisely determine the original transmit power
for received signals being handled by the receiving device.
[0043] The DLL frame may also comprise a subnet field 320. The
subnet field 320 may be utilized in uniquely designating one or
more devices as the target (receiving) device(s) for particular
frame. Alternatively the subnet field 320 may be set to enable all
devices reachable by a particular requesting device to accept and
handle a particular frame. The subnet field is described in more
details in FIG. 3B.
[0044] The cyclic redundancy check (CRC) field 330 may be used in
conjunction with CRC operations. In this regard, CRC may provide a
mechanism for performing error-detection in a network, enabling
detection (and correction) of accidental and unintended changes to
data communicated among devices in the network. The CRC operation
may comprise determining particular check values for blocks of
data, and then attaching these check values into the corresponding
blocks (e.g. CRC field 330), at the transmitting side. The check
values are then validated, at the receiving side, to detect any
corruption or modification of the data in the blocks, and/or to try
to correct that corruption. The CRC function determines the CRC
check value for a block of data based on the remainder of a
polynomial division of the content of the block. At the receiving
end, a similar calculation may be performed, and corrective action
may be taken when data corruption is detected, such as when the
check values (attached to the block and determined locally) do not
match. CRC functions are typically categorized based on the length
of the polynomial used thereby. For example, the CRC scheme applied
to DLL frames structured in accordance with the current invention
may be based on a 16-bit CRC scheme (i.e., CRC16). The invention
need not be so limited, however.
[0045] FIG. 3B is a block diagram illustrating exemplary structure
of a subnet field in a data link layer frame, in accordance with an
embodiment of the invention. Referring to FIG. 3B, there is shown
the subnet field 320 of an exemplary data link layer frame, which
may be structured in accordance with wireless protocols utilized by
electronic devices that implement various aspects of the invention.
Cross-referenced U.S. application Ser. No. 13/408,453, filed on
Feb. 29, 2012 (now U.S. Pat. No. 9,191,340), and cross-referenced
U.S. application Ser. No. 13/408,461, filed on Feb. 29, 2012 (now
published as 2012/0226822) provide more details on the structures
of exemplary data link layer frames.
[0046] The subnet field 320 may be utilized to allow configurable,
data-based filtering of incoming frames. The subnet field 320 may
comprise two sub-fields, a frame subnet specifier 320.sub.A and a
frame subnet mask 320.sub.B. For example, the subnet field 320 may
be structured as an 8-bit value, with the upper 4 bits containing
the frame subnet specifier 320.sub.A and the lower 4 bits
containing the value of the frame subnet mask 320.sub.B. Values
embedded into the two sub-fields of the subnet field 320 may be
utilized by devices receiving data link layer frames to determine
whether (or not) the frames are handled (or not) by the device.
This process is described as "subnet matching." In this regard,
each device may maintain corresponding internal subnet values
(i.e., device subnet specifier and device subnet mask), which may
be compared during subnet matching with the subnet field 320
embedded in received incoming frame. For example, during subnet
matching the values of the subnet specifiers (the frame and the
device) are compared, such as for exact match, unless the frame
subnet specifier is set to a particular value (e.g., 0xF) that
indicates a universal acceptance of the frame. The subnet masks
(the frame and the device), which may comprise self-referential
bitmasks, may be applied to mask other values used during subnet
matching. Subnet matching is explained in more details with respect
to subsequent figures.
[0047] FIG. 3C is a block diagram illustrating exemplary structure
of a data link frame utilized by a requester device in a
resource-constrained network to specify response criteria, in
accordance with an embodiment of the invention. Referring to FIG.
3B, there is shown an exemplary mode 2 network protocol (M2NP) PDU
340 carrying therein a mode 2 query protocol (M2QP) command 350,
which may be structured in accordance with the present invention.
Cross-referenced U.S. application Ser. No. 13/408,453, filed on
Feb. 29, 2012 (now U.S. Pat. No. 9,191,340), and cross-referenced
U.S. application Ser. No. 13/408,461, filed on Feb. 29, 2012 (now
published as 2012/0226822) provide more details on M2NP PDUs and/or
the M2QP commands.
[0048] The M2QP command 350 may be utilized during search
operations--that is a requesting device may communicate the M2QP
command 350 to trigger search responses from certain devices
receiving the command (i.e., responding devices) under particular
conditions. The M2QP command 350 may comprise a global query
template 360.sub.A and a local query template 360.sub.13. Both of
the global query template 360.sub.A and the local query template
360.sub.B are structured using the same generic query template 360.
These fields may be utilized during search operations, to specify
actions undertaken by receiving devices when determining whether
the receiving devices should respond to received M2QP commands or
to disregard the command (and thus not send back a response). In
particular, the receiving devices may compare values embedded into
the M2QP command 350 with corresponding values maintained locally
by these devices, to determine whether (or not) to respond to the
received M2QP command 350. Furthermore, various fields (and values
stored therein) of the M2QP command 350 may specify various details
and/or conditions pertaining to the comparisons being performed in
determining whether (or not) to respond. Accordingly, configuring
and/or modifying various fields or values embedded in the M2QP
command 350, such as the global query template 360.sub.A and the
local query template 360.sub.B, may enable adjusting outcome of
search functions.
[0049] In an embodiment of the invention, during adaptive traffic
management operations, various fields of the M2QP command 350, such
as is the global query template 360.sub.A and the local query
template 360.sub.B, may be modified to enable adjusting search
functions being executed by a requesting device. For example, the
number of receiving devices that may decide to respond to a
received M2QP command 350 may be determined by adjusting comparison
related values embedded in the global query template 360.sub.A and
the local query template 360.sub.B, such as: the comparison length
(i.e., the length, in bits, of the portion of the embedded compare
value being matched); the comparison mask (a bitmask for masking
portion of embedded compare value being matched); the comparison
value (the value being compared to a corresponding internal value
in the devices); and/or the compare command, which may specify
whether masking is used (or not), the type of comparison (e.g.
logical `or`), and any pertinent comparison parameters. For
example, to reduce the number of devices that may qualify for
responding to a particular M2QP command 350, masking may be turned
off (that is the whole compare value must be matched), and/or the
type of comparison specified by the compare command may be changed
from logical `or` to bitwise `and.` This may enable a requesting
device to reduce the number of responses being communicated in a
resource-constrained network even when the transmit power of the
requesting device (and this the search range) is kept
unchanged.
[0050] FIG. 4A is a block diagram illustrating an exemplary
implementation of the OSI model within an electronic device that
may support optimized packet filtering, in accordance with an
embodiment of the invention. Referring to FIG. 4A, there is shown
the device 200 of FIG. 2.
[0051] The device 200 may be operable and/or configured to
incorporate an OSI model based implementation in accordance with
the protocol described in the above-incorporated U.S. Provisional
Patent Application No. 61/464,476, filed on Mar. 2, 2011. In this
regard, the 7 OSI layers may be implemented via one or more
physical components of the device 200. For example, the Physical
(PHY) Layer (layer 1 of the OSI model) may be implemented via the
transmit FE 210 and the receive FE 212.sub.A-212.sub.N; the Data
Link Layer (layer 2 of the OSI model) and the Network Layer (layer
4 of the OSI model) may be implemented via the signal processing
module 206; while the remaining layers, comprising the Transport
Layer (layer 4 of the OSI model), the Session Layer (layer 5 of the
OSI model), the Presentation Layer (layer 6 of the OSI model), and
the Application Layer (layer 7 of the OSI model) may be implemented
via the main processor 202.
[0052] During communications from and/or to the device 200, the
seven OSI layers may be utilized to perform different functions
and/or processes for facilitating such communications, and/or
enable controlling various aspects related thereto. In this regard,
the OSI module may typically be utilized to enable performing
required header/footer encapsulation and/or stripping, and may
comprise exchange of data among the OSI layers, after handling the
data within each OSI layer--e.g., in accordance with particular
protocol(s). For example, each OSI layer may attach to data
received from higher OSI layer(s), headers/footers relating to that
OSI layer, such as to enable a corresponding layer in a peer device
to handle the data; and may strip such headers/footers from data
received from lower OSI layer(s), typically after utilizing the
headers/footers in handling data within that OSI layer, before
forwarding the data to higher OSI layer(s). During OSI related
processing, data may be internally exchanged among the OSI layers,
and/or the physical components in which OSI layers are implemented,
using data buses for example. The handling of data (e.g.
encapsulation or stripping) may require buffering of data by one or
more OSI layers, as demonstrated by use of transmit/receive (Tx/Rx)
buffers 410 in the Data Link Layer 404.
[0053] To control operations of the OSI model, the OSI layers may
need to exchange data enabling configuring and/or adjustment of
functions and/or modules in the OSI layers. For example, the
Physical Layer 402 may provide to the Data Link Layer 404 various
information, shown as PHY_Ctrl_Info, which may in turn enable
configuring and controlling the Physical Layer 402 (e.g., via
PHY_Config) by the Data Link Layer 404 (and by higher layers
operating via the Data Link Layer 404). The PHY_Ctrl_Info may
comprise status information relating to the Physical Layer 402,
and/or to various functions or modules thereof. The PHY_Ctrl_Info
may also comprise information obtained via the Physical Layer
402.
[0054] Similarly, the Data Link Layer 404 may provide to the higher
OSI layers 406 with various information, shown as DL_Ctrl_Info,
which enable configuring and controlling the Data Link Layer 404
(e.g., via DL_Config) by the higher OSI layers 406. The
DL_Ctrl_Info may comprise status information relating to the Data
Link Layer 404 (and Physical Layer 402), and/or to various
functions or modules thereof. The DL_Ctrl_Info may also comprise
information obtained via the Data Link Layer 404. Dedicated
configuration registers, such as configuration registers 412 of the
Data Link Layer 404 may be utilized to store and maintain
parameters used in effectuating requested configurations and/or
adjustments.
[0055] In various embodiments of the invention, the OSI module
implemented by the device 200 may be configured and/or adjust to
enable and/or support adaptive traffic management. For example, the
OSI model may be configured to support optimized packet handling.
In this regard, implementing optimized packet handling in the OSI
model may comprise adding new, dedicated functions and/or modules,
and/or modifying or adjusting existing functions and/or modules
performing operations that may affect transmission and/or reception
of packets the device 200 during communications. For example, the
OSI model may be modified and/or configured to implement a
multi-stage packet filtering scheme in conjunction with reception
of packets. FIG. 4B describes in more details an exemplary
incorporation of optimized packet filtering into the OSI model.
[0056] FIG. 4B is block diagram illustrating implementation of
various aspects of the invention at different layers of the OSI
model, in accordance with an embodiment of the invention. As shown
in FIG. 4B, the device 200 may comprise various modules and/or
processes that may be run in different layers of the OSI model, and
may interact to facilitate performing various functions and/or
operations of the device 200.
[0057] For example, the device 200 may comprise a received signal
strength indication (RSSI) module 430, which may operate at the
Physical Layer (layer 1 of the OSI model); and a link quality
assessment module 440, a subnet matching module 442, and a cyclic
redundancy check (CRC) validation module 444, which may operate at
the Data Link Layer (layer 2 of the OSI model).
[0058] The RSSI module 430 may implement RSSI measurement
operations, in which the strength of received signals may be
determined, and reported as a value corresponding to particular
relative level between the minimum and maximum values.
[0059] The link quality assessment module 440 may implement link
quality assessment, during which certain checks are performed to
determine whether a received frame (extracted from received packet)
may be discarded, or processing of the frame is continued. In this
regard, during link quality assessment, the TxEIRP field is
extracted from the frame's header, and the value of detected RSSI
for the frame is subtracted from the TxEIRP field to derive a
corresponding link budget utilization value. If link quality
filtering is enabled (e.g., by assertion of LQ.sub.EN), the frame
would be discarded and Data Link Layer processing terminated when
the derived link budget utilization value is greater than a
particular link quality threshold (shown as LQ.sub.thr). The
LQ.sub.thr may be configurable, in a manner that enables
determining whether a particular frame is discarded based on
determination of loss of power during communication of the frame.
In this regard, setting LQ.sub.thr to a relatively-high value may
reduce power consumption because: the device may process fewer
received packets (because they are dropped rather than being
processed), the device may transmit fewer packets (because there
are fewer successfully-received packets to respond to), and/or the
average transmit power is lower (because responses are only being
sent from devices which are reachable via a short/low-attenuation
path). The value of LQ.sub.thr may be configured based, for
example, on one or more of: location of the device (e.g.,
determined by GPS and/or other wireless signals), type of device
(e.g., whether the device is a laptop, a smartphone, or a
battery-powered tag), power source of the device (e.g., plugged-in
or running on battery), remaining battery charge, which particular
and/or types of the devices are desired to be communicated with,
and results of past communications (e.g., number of responses
received to previous requests).
[0060] The subnet matching module 442 may implement subnet
matching, during which certain checks are performed to determine
whether a received frame (extracted from received packet) may be
discarded, or whether processing of the frame is to be continued.
In this regard, during subnet matching, certain subnet-related
values embedded in received frames may be compared to corresponding
subnet-related values maintained internally in the electronic
device (shown as DS.sub.specifier and DS.sub.mask). For example,
each frame may comprise a frame subnet specifier, which must match
a corresponding internally maintained device subnet specifier
(DS.sub.specifier) for a successful subnet matching to
occur--alternatively, successful subnet matching may result when
the frame subnet specifier is a universal acceptance value. Other
subnet related values may comprise subnet masks (both frame and
device--that is DS.sub.mask), and these masks may comprise
bitmasks. In this regard, during subnet matching, device and frame
subnet masks may be logically `anded,` and compared when
determining whether subnet matching was successful. Subnet matching
is described in more details in FIG. 5C.
[0061] In an exemplary embodiment, the DS.sub.mask values of
devices having a particular DS.sub.specifier may be normally
distributed between 0 and 15. That is, approximately 1/16.sup.th of
the devices may have a DS.sub.mask value of 0, 1/16.sup.th of the
devices may have a value of 1, and so on. Accordingly, controlling
the value of the FSM may enable controlling the number of devices
which respond to a particular request. For example, an FSM of 1111
may result in all devices responding, an FSM of 0111 may result in
half of the devices responding, an FSM of 0011 may result in 1/4 of
the devices responding, and an FSM of 0001 may result in 1/8.sup.th
of the devices responding, and FSM of 0000 may result in
1/16.sup.th of the devices responding.
[0062] The CRC validation module 444 may implement data integrity
checking, during which certain checks are performed to determine
whether a received frame (extracted from received packet) may be
discarded, or processing of the frame is continued. In this regard,
during CRC validation, the CRC value embedded (or attached) to
particular frame is compared to locally determined CRC value based
on content of the frame. For example, when 16-bit CRC (CRC16) is
utilized, when the CRC16 calculation of the content of a received
frame matches the CRC16 value (field 330) attached to the frame,
processing of the frame (by the Data Link Layer) may continue. In
an embodiment of the invention, the CRC16 calculation applicable
via the CRC validation module 444 may include all previous bytes of
the frame, and it may utilize the International Telegraph and
Telephone Consultative Committee (CCITT) CRC16 polynomial, or
x.sup.16+x.sup.12+X.sup.5+x.sup.0 (1021) with initial value
0xFFFF.
[0063] In operation, the link quality assessment module 440, the
subnet matching module 442, and the CRC validation module 444 may
be utilized to enable performing multi-stage filtering of received
packets in the device 200. For example, the CRC validation module
444 may be utilized to perform a first filtering stage, in which
CRC validation is applied, with the frame being discarded if CRC
validation fails, and handling of the frame continuing if the CRC
validation succeeds. The link quality assessment module 440 may be
utilized to perform a second filtering stage, in which link quality
assessment is applied, with the frame being discarded if link
quality assessment fails, and handling of the frame continuing if
the link quality assessment succeeds. The subnet matching module
442 may be utilized to perform a third filtering stage, in which
subnet matching is applied, with the frame being discarded if
subnet matching fails, and handling of the frame continuing if the
subnet matching succeeds.
[0064] The order of functions applicable in the different stages of
the multi-stage filtering scheme may be configurable. In this
regard, the selective matching of particular validation functions
with the various stages of the filtering scheme may be done in a
manner that best optimize the handling of the packet. In other
words, the assignment of the various checks and/or validation
functions performed during the multi-stage filtering may be
determined based on probability of failure, with checks more likely
to fail (i.e., conditions more like to be met) being performed
earlier, and check less like to fail being done subsequently.
Furthermore, the ordering of the checks and/or validation steps may
also depend on evaluation of the relevance of these checks or
validations. For example, checks or validations relating to the
integrity of the received fames and/or data carried therein may be
performed earlier, since any errors in the content may result in
false outcomes in remaining checks. For example, because the
outcome of the subnet matching or link quality assessment may be
false when the content of frames is corrupted (altering fields or
values used during these checks), the first stage of the
multi-stage filtering may be tailored to validate the reliability
of the frames, such as by applying the CRC validation as a first
stage since it ensures that the content of the frames, which may
comprise values used by the other checks (e.g., TxEIRP 310 and
frame subnet 320) are trustworthy.
[0065] FIG. 5A is a flow chart that illustrates exemplary steps for
supporting optimized packet filtering in an electronic device, in
accordance with an embodiment of the invention. Referring to FIG.
5A, there is shown a flow chart 500 comprising a plurality of
exemplary steps for performing multi-stage packet filtering in an
electronic device, such as device 200, during reception of packet
by the electronic device in a resource-constrained network.
[0066] In step 502, after a start step, CRC validation may be
performed (FIG. 5B) on a particular frame carried via a received
packet. In step 504, a determination whether the CRC validation was
successful may be performed. In instances where the outcome of the
CRC validation is not successful, the plurality of exemplary steps
may terminate, with the frame being discarded, and/or handling or
processing of the frame being terminated--that is, any resources,
functions and/or modules being allocated and/or spawned for
handling of the frame being released and/or terminated.
[0067] Retuning to step 504, in instances where the outcome of the
CRC validation is successful, the plurality of exemplary steps may
proceed to step 506. In step 506, subnet matching may be performed
(FIG. 5C) on the frame. In step 508, a determination whether the
subnet matching was successful may be performed. In instances where
the outcome of the subnet matching is not successful, the plurality
of exemplary steps may terminate, with the frame being discarded
and/or handling or processing of the frame being terminated.
[0068] Retuning to step 508, in instances where the outcome of the
subnet matching is successful, the plurality of exemplary steps may
proceed to step 510. In step 510, link quality assessment may be
performed (FIG. 5D) on the frame.
[0069] FIG. 5B is a flow chart that illustrates exemplary steps for
performing cyclic redundancy check (CRC) validation as one stage of
a multi-stage filtering process during handling of received
packets, in accordance with an embodiment of the invention.
Referring to FIG. 5B, there is shown a flow chart 520 comprising a
plurality of exemplary steps for performing CRC validation as part
of a multi-stage packet filtering scheme in an electronic device,
such as device 200.
[0070] In step 522, after a start step, the CRC value (e.g. field
330) attached to a frame carried in a received packet may be
extracted. In step 524, CRC validation may be performed using the
extracted CRC value, and locally calculated CRC value based on the
content of the frame. In instances where the CRC validation is
successful (i.e. the CRC is valid), the plurality of exemplary
steps may proceed to step 526, where the processing and handling of
the frame may continue (i.e., a successful check).
[0071] Returning to step 524, in instances where the CRC validation
fails (i.e. the CRC is not valid), the plurality of exemplary steps
may proceed to step 528, where the frame may be discarded, and
processing and handling of the frame may be terminated (i.e.,
failed check).
[0072] FIG. 5C is a flow chart that illustrates exemplary steps for
performing subnet matching as one stage of a multi-stage filtering
process during handling of received packets, in accordance with an
embodiment of the invention. Referring to FIG. 5C, there is shown a
flow chart 540 comprising a plurality of exemplary steps for
performing subnet matching as part of a multi-stage packet
filtering scheme in an electronic device, such as device 200.
[0073] In step 542, the frame subnet specifier (FSS)--i.e., the
value of subfield 320.sub.A--may be extracted from the frame's
subnet field 320. In step 544, a determination of whether the frame
subnet specifier (FSS) is the universal acceptance value may be
performed. In this regard, a particular value (e.g., 0xF) may be
reserved for use as a default value that triggers bypassing the
specifier matching during subnet matching in receiving devices. In
instances, where the frame subnet specifier (FSS) is the universal
acceptance value, the process may jump to step 548.
[0074] Returning to step 544, in instances, where the frame subnet
specifier (FSS) is NOT the universal acceptance value, the process
may proceed to step 546. In step 546, a comparison between the
frame subnet specifier (FSS) and a corresponding, locally
maintained (in the device) subnet specifier (DSS) may be performed.
In other words, the frame subnet specifier (FSS) is compared
against the DSS. In this regard, the comparison may be directed to
determining if the two values match. The matching may be, but not
limited to, exact matching. In instances where the frame subnet
specifier (FSS) does not match the device subnet specifier (DSS),
the plurality of exemplary steps may proceed to step 554, where the
frame may be discarded, and processing and handling of the frame
may be terminated--that is, any resources, functions and/or modules
being allocated and/or spawned for handling of the frame being
released and/or terminated.
[0075] Returning to step 546, in instances where the frame subnet
specifier (FSS) matches the device subnet specifier (DSS), the
plurality of exemplary steps may proceed to step 548. In step 548,
the frame subnet mask (FSM)--i.e., the value of subfield
320.sub.B--may be extracted from the frame's subnet field 320; and
a combined mask value may be generated from the frame subnet mask
(FSM) and the corresponding, internally maintained (in the device)
subnet mask (DSM). In this regard, the combined mask value may be
generated by bitwise `anding` the frame subnet mask (FSM) with
device subnet mask (DSM). In step 550, a comparison between the
combined mask value and the device subnet mask (DSM) may be
performed. In other words, the combined mask value (generated by
bitwise anding of FSM and DSM) is compared against a DSM. In this
regard, the comparison may be directed to determining if the two
values match. The matching may be, but not limited to, exact
matching. In instances where the combined mask value does not match
the device subnet mask (DSM), the plurality of exemplary steps may
proceed to step 554, where the frame may be discarded, and
processing and handling of the frame may be terminated (i.e.
failure).
[0076] Returning to step 550, in instances where the combined mask
value matches the device subnet mask (DSM), the plurality of
exemplary steps may proceed to step 552, where processing and
handling of the frame may continue (i.e. success).
[0077] FIG. 5D is a flow chart that illustrates exemplary steps for
performing link quality assessment as one stage of a multi-stage
filtering process during handling of received packets, in
accordance with an embodiment of the invention. Referring to FIG.
5D, there is shown a flow chart 560 comprising a plurality of
exemplary steps for performing link quality assessment as part of a
multi-stage packet filtering scheme in an electronic device, such
as device 200.
[0078] In step 562, after start of process, a determination whether
link quality assessment is enabled may be performed. In this
regard, link quality assessment may be enabled (or disabled) by
asserting (or de-asserting) a control signal or control parameters
(e.g. in register), such as LQ.sub.EN, which may in turn activate
corresponding function or module (e.g. link quality assessment
module 340) for performing and/or managing power autoscaling
operations. In instances where it may be determined that link
quality assessment is not enabled the process may terminate.
[0079] Returning to step 562, in instances where it may be
determined that link quality assessment is enabled the process may
proceed to step 564. In step 564, a determination whether a
received (data link) frame comprises a TxEIRP field may be
performed. In this regard, the TxEIRP field may indicate the
equivalent isotropic radiated power (EIRP)--i.e., power--that the
transmitting device originally utilized in transmitting the packet
(or frame) which is being handled by the receiving device. In
instances where it may be determined that the received frame does
not comprise the TxEIRP field the process may terminate.
[0080] Returning to step 564, in instances where it may be
determined that the received frame comprises the TxEIRP field the
process may proceed to step 566. In step 566, the TxEIRP field (or
value thereof) may be extracted. In step 568, the received signal
strength indication (RSSI) may be determined. In this regard, the
RSSI may measure the strength of the signal(s) carrying the packet
that comprise the frame in question, as determined by the receiving
device. In step 570, the link budget utilization value may be
determined, by subtracting the measured RSSI value from the
extracted TxEIRP. In other words, the link budget utilization value
may correspond to the loss of power during communication of the
signals carrying the packet (frame) between the transmitting device
and the receiving device. In step 572, it may be determined whether
the calculated link budget utilization value is greater than a
particular link quality threshold. In this regard, the link quality
threshold LQ.sub.thr may be configurable value. Specifically, the
LQ.sub.thr parameter may be set and/or adjusted during adaptive
power autoscaling, to enable modifying signal reception sensitivity
in the device 200. The value of the LQ.sub.thr threshold, and/or
any adjustment thereof, may be dictated by the applicable power
autoscaling algorithm. In instances where it may be determined that
the link budget utilization value is greater than the link quality
threshold (LQ.sub.thr), the process may proceed to step 574,
enabling handling and/or processing of the frame to continue.
Returning to 572, in instances where it may be determined that the
link budget utilization value is not greater than the link quality
threshold (LQ.sub.thr), the process may proceed to step 576, where
handling and/or processing of the frame may be stopped and the
frame may be discard.
[0081] In an embodiment of the invention, parameters utilized in
applying and/or controlling link quality assessment may be set
and/or modified in accordance with applicable filtering scheme used
in the device 200, to adjust filtering outcome of this process.
Adjusting the LQ.sub.thr threshold, for example, may cause a
corresponding adjustment in the determination whether to discard a
packet or to continue processing it. In this regard, when the
LQ.sub.thr threshold is set to a low value, received signals
communicated over links having high link budget value (i.e. large
power loss) may be perceived (the signal) as being sufficiently
reliable, and packets/frames carried via such signal may be
processed; whereas when the LQ.sub.thr threshold is set to a high
value, received signals communicated over links having low link
budget value (i.e. small power loss) may perceived as not being
sufficiently reliable, and packets/frames carried via such signals
are discarded. The value of the LQ.sub.thr threshold may be
adjusted in accordance with applicable multi-stage filtering
scheme. In this regard, adjusting the LQ.sub.thr threshold may
enable modifying reception sensitivity--that is setting the
LQ.sub.thr threshold to a low value would enable handling and/or
processing packets/framed carried via signal communicated over a
link having a particular link budget value (power loss) whereas
packets/frames, carried via similar signals communicated over link
with similar link budget value would be discarded when the
LQ.sub.thr threshold is increased
[0082] FIG. 6 is a flow chart that illustrates exemplary steps for
adjusting transmission criteria by a requester device to optimize
traffic in a resource-constrained network, in accordance with an
embodiment of the invention. Referring to FIG. 6, there is shown a
flow chart 600 comprising a plurality of exemplary steps that may
be performed by an electronic device, such as device 200, to
provide enhanced search in a resource-constrained network.
[0083] In step 602, a requesting device may initiate a search
operation. In this regard, the search operation may comprise
transmitting one or more search commands, such as the M2QP command
350 of FIG. 3C, whereby devices receiving this command (the
receiving devices) may determine whether (or not) to respond to the
search command. Determining whether or not to respond to search
commands may be based on compare functions executed in the
receiving devices, based on information embedded in the search
command and/or information maintained locally. These values may
comprise both values that are being compared and/or parameters
specifying details and/or conditions applicable to the compare
functions. In step 604, a determination whether the number of
received search responses exceeds a maximum response threshold may
be performed. In other words, the requesting device may determine
whether the search operation performed in step 602 resulted in a
large number of responses that may be undesirable in light of the
network and/or device constraints--that is whether the search
triggers a number of responses that is deemed too large to be
handled, due to bandwidth utilization in the network (or particular
channels), and/or energy consumption or resource utilization in
conjunction with handling the responses. The value of the maximum
response threshold may be configurable, and it may be modified
based on changing conditions in the network and/or the requesting
devices (e.g., freeing up of bandwidth in the network, drainage in
energy supply of the requesting device, execution of other
functions with lower/higher priority, etc.). The maximum response
threshold may be determined implicitly, such as based on detecting
of too many data collisions (e.g., too many bad CRC); or
explicitly, such as if the response window is sufficiently crowded.
In instances where it may be determined that the number of
responses exceeded the maximum response threshold, the process may
terminate.
[0084] Returning to step 604, in instances where it may be
determined that the number of responses did exceed the maximum
response threshold; the process may proceed to step 606. In step
606, the requesting device may select one or more search
optimization criteria for modifying the search function. For
example, the search optimization may comprise adjustment of
transmit power, such as by reducing transmit power to physically
narrow the search range. Additionally or alternatively, the search
optimization may comprise adjustments that logically narrow the
search range--i.e. reduce the number of devices that would meet the
conditions required for responding to the search. Such logical
narrowing of the search may be achieved by modifying the search
command itself (e.g., by adjusting the query template parameters).
The logical narrowing of the search may be achieved by modifying
the classification and/or assignment of devices and/or channels in
the network. For example, subnet assignments may be adjusted such
that smaller number of devices would successfully pass subnet
matching applicable based on the search command (e.g., the
requesting device may send a multicast frame which results in a new
DSS being written to some of the responding devices). Additionally
or alternatively, some receiving device(s) may be reassigned to
and/or instructed to respond on a different channel than the one(s)
on which the search command is transmitted or specified as
acceptable response channel(s). Similarly, different subsets of
responding devices may be instructed to respond on different
channels and/or at different times. In step 608, the search
optimization criteria selected in step 606 are applied, and the
search operation is re-executed with a new search command being
generated, in accordance with the modified criteria, and
transmitted.
[0085] While the process described in FIG. 6 is based on checking
for the condition that the number of received search responses
exceeds a maximum response threshold, the invention need not be so
limited. For example, in an embodiment of the invention, a check of
whether the number of received search responses reaches a minimum
response threshold may also be performed, and the search function
may be adjusted to increase the range of search, both physically
(e.g., by increasing the transmit power) and/or logically, such as
by increasing the number of devices that would meet the conditions
required for responding to the search, by adjusting the query
template parameters and/or subnet related parameters for
example.
[0086] 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 adaptive traffic
management in a resource-constrained network.
[0087] 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 computer system, or in a distributed fashion where
different elements are spread across several interconnected
computer systems. Any kind of computer 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 computer system with a computer program that, when
being loaded and executed, controls the computer system such that
it carries out the methods described herein.
[0088] 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.
[0089] 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.
* * * * *