U.S. patent application number 16/290605 was filed with the patent office on 2019-06-27 for method and apparatus for dynamic media access control in a multiple access system.
The applicant listed for this patent is Blackbird Technology Holdings, Inc.. Invention is credited to John Peter Norair.
Application Number | 20190200310 16/290605 |
Document ID | / |
Family ID | 46753245 |
Filed Date | 2019-06-27 |
View All Diagrams
United States Patent
Application |
20190200310 |
Kind Code |
A1 |
Norair; John Peter |
June 27, 2019 |
METHOD AND APPARATUS FOR DYNAMIC MEDIA ACCESS CONTROL IN A MULTIPLE
ACCESS SYSTEM
Abstract
An electronic device may be operable to control access to a
physical medium (e.g., airwaves, a copper cable, or an optical
fiber) utilizing carrier sense multiple access (CSMA). The amount
of time that the electronic device must sense the physical medium
as being inactive before it permits transmission of a message onto
the physical medium may be determined based on: the size of the
message, the type of the message, the symbol rate at which the
message is to be transmitted, and/or a channel onto which the
message is to be transmitted. Similarly, other aspects of how and
when electronic device transmits and/or receives on the physical
medium may be controlled via one or more dynamically configurable
parameters which may be configured based on characteristics of
received and/or to-be-transmitted messages.
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.: |
16/290605 |
Filed: |
March 1, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16038430 |
Jul 18, 2018 |
|
|
|
16290605 |
|
|
|
|
15200265 |
Jul 1, 2016 |
|
|
|
16038430 |
|
|
|
|
14943661 |
Nov 17, 2015 |
|
|
|
15200265 |
|
|
|
|
13408453 |
Feb 29, 2012 |
9191340 |
|
|
14943661 |
|
|
|
|
61464376 |
Mar 2, 2011 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 47/822 20130101;
Y02D 30/70 20200801; H04W 56/0025 20130101; H04W 72/0473 20130101;
Y02D 70/166 20180101; H04W 28/04 20130101; H04W 40/023 20130101;
H04W 52/245 20130101; H04L 49/555 20130101; H04W 4/023 20130101;
Y02D 70/144 20180101; H04B 17/318 20150115; H04W 56/002 20130101;
H04W 72/0446 20130101; H04L 1/0083 20130101; H04L 69/22 20130101;
H04W 28/0205 20130101; Y02D 70/164 20180101; H04W 52/06 20130101;
H04W 52/242 20130101; H04W 74/085 20130101; H04W 74/0808 20130101;
H04W 74/0816 20130101; H04W 52/243 20130101; H04L 43/0882 20130101;
H04L 43/16 20130101; H04W 52/36 20130101; H04L 43/0847 20130101;
Y02D 70/142 20180101; H04W 48/08 20130101; H04L 1/0061 20130101;
H04L 47/12 20130101; H04W 56/001 20130101; H04W 52/54 20130101;
H04W 52/0235 20130101 |
International
Class: |
H04W 56/00 20060101
H04W056/00; H04L 29/06 20060101 H04L029/06; H04W 52/24 20060101
H04W052/24; H04W 74/08 20060101 H04W074/08; H04W 72/04 20060101
H04W072/04; H04L 1/00 20060101 H04L001/00; H04W 28/04 20060101
H04W028/04; H04W 28/02 20060101 H04W028/02; H04W 52/54 20060101
H04W052/54; H04W 52/02 20060101 H04W052/02; H04W 52/06 20060101
H04W052/06; H04W 4/02 20060101 H04W004/02; H04W 48/08 20060101
H04W048/08; H04W 40/02 20060101 H04W040/02; H04L 12/939 20060101
H04L012/939; H04B 17/318 20060101 H04B017/318; H04W 52/36 20060101
H04W052/36; H04L 12/26 20060101 H04L012/26; H04L 12/911 20060101
H04L012/911; H04L 12/801 20060101 H04L012/801 |
Claims
1. A system comprising: an electronic device operable to control
access to a physical medium utilizing carrier sense multiple access
(CSMA), wherein the amount of time that said electronic device must
sense said physical medium as being inactive before said electronic
device permits transmission of a message onto said physical medium
is determined based on the size of said message.
2. The system of claim 1, wherein said amount of time that said
electronic device must sense said physical medium as being inactive
before said electronic device permits transmission of said message
onto said physical medium is determined based on a type of said
message.
3. The system of claim 1, wherein said amount of time that said
electronic device must sense said physical medium as being inactive
before said electronic device permits transmission of said message
onto said physical medium is determined based on a symbol rate at
which said message is to be transmitted.
4. The system of claim 1, wherein said amount of time that said
electronic device must sense said physical medium as being inactive
before said electronic device permits transmission of said message
onto said physical medium is determined based on a channel onto
which said message is to be transmitted.
5. The system of claim 1, wherein: said message is in response to a
request received by said electronic device via said physical
medium; and said channel onto which said message is to be
transmitted is determined based on a field of said received
request.
6. The system of claim 5, wherein: said field of said received
request comprises a list of channels; said electronic device
sequentially listen to channels in said list of channels until a
channel meeting certain requirements is found or until a timeout
occurs.
7. The system of claim 1, wherein: said message is in response to a
request received via said physical medium by said electronic
device; and the maximum amount of time that said electronic device
attempts to transmit said message onto said physical medium is
determined based on a field of said previously-received request
message.
8. The system of claim 1, wherein: said message is in response to a
request received via said physical medium by said electronic
device; and while said message is pending transmission, a portion
of said electronic device alternates between a listen state and a
wait state, wherein the amount of time that said portion of said
electronic device spends in one or both of said listen state and
said wait state is determined based on one or more fields of said
received request.
9. The system of claim 8, wherein said one or more fields of said
received request determine an equation and/or algorithm utilized by
said electronic device for said determining said amount of time
that said portion of said electronic device spends in one or both
of said listen state and said wait state.
10. The system of claim 1, wherein said electronic device comprises
memory and a receiver and is operable to: read a series of n-tuples
from said memory, each of said n-tuple comprising a channel
identifier, a scan duration value, and a time-to-next-scan value;
and for each of said read n-tuples: configure said receiver to
receive on the channel associated with said channel identifier for
an amount of time equal to said scan duration value; and power-down
said receiver for an amount of time equal to said time-to-next-scan
value minus said scan duration value.
11. The system of claim 1, wherein said electronic device comprises
memory, a transmitter, and a receiver and is operable to: read a
series of n-tuples from said memory, each of said n-tuple
comprising a channel identifier, a contention period value, and a
time-to-next-scan value; and for each of said read n-tuples:
configure said transmitter to transmit a beacon on the channel
associated with said channel identifier; configure said receiver to
listen for a response to said beacon for an amount of time equal to
said contention period value; and wait a period of time equal to
said time-to-next-scan value minus said contention period value
before operating based on the next n-tuple in said series of
n-tuples.
12. A method comprising: in an electronic device which utilizes
carrier sense multiple access (CSMA) for communicating over a
physical medium: determining the amount of time that said
electronic device must sense said physical medium as being inactive
before permitting transmission of a message onto said physical
medium based on the size of said message.
13. The method of claim 12, wherein said determining said amount of
time that said electronic device must sense said physical medium as
being inactive before said electronic device permits transmission
of said message onto said physical medium is based on a type of
said message.
14. The method of claim 12, wherein said determining said amount of
time that said electronic device must sense said physical medium as
being inactive before said electronic device permits transmission
of said message onto said physical medium is based on a symbol rate
at which said message is to be transmitted.
15. The method of claim 12, wherein said determining said amount of
time that said electronic device must sense said physical medium as
being inactive before said electronic device permits transmission
of said message onto said physical medium is based on a channel
onto which said message is to be transmitted.
16. The method of claim 12, wherein: said message is in response to
a request received by said electronic device via said physical
medium; and said channel onto which said message is to be
transmitted is determined based on a field of said received
request.
17. The method of claim 16, wherein: said field of said received
request comprises a list of channels; said electronic device
sequentially listen to channels in said list of channels until a
channel meeting certain requirements is found or until a timeout
occurs.
18. The method of claim 12, wherein: said message is in response to
a request received via said physical medium by said electronic
device; and the maximum amount of time that said electronic device
attempts to transmit said message onto said physical medium is
determined based on a field of said previously-received request
message.
19. The method of claim 12, wherein: said message is in response to
a request received via said physical medium by said electronic
device; and while said message is pending transmission, a portion
of said electronic device alternates between a listen state and a
wait state, wherein the amount of time that said portion of said
electronic device spends in one or both of said listen state and
said wait state is determined based on one or more fields of said
received request.
20. The method of claim 19, wherein said one or more fields of said
received request determine an equation and/or algorithm utilized by
said electronic device for said determining said amount of time
that said portion of said electronic device spends in one or both
of said listen state and said wait state.
Description
CLAIM OF PRIORITY
[0001] This patent application is a continuation of U.S. patent
application Ser. No. 16/038,430, filed on Jul. 18, 2016, which is a
continuation of U.S. patent application Ser. No. 15/200,265, filed
on Jul. 1, 2016, which is a continuation of U.S. patent application
Ser. No. 14/943,661, filed on Nov. 17, 2015, which is a
continuation of U.S. patent application Ser. No. 13/408,453, filed
on Feb. 29, 2012, which 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 identified applications is hereby
incorporated herein by reference in its entirety.
INCORPORATION BY REFERENCE
[0003] This patent application also makes reference to:
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; 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; 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; 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; 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; U.S. patent application Ser. No.
13/270,959, entitled "Method and Apparatus for an Integrated
Antenna" and filed on Oct. 11, 2011; U.S. patent application Ser.
No. 13/289,054, entitled "Method and Apparatus for Electronic
Payment" and filed on Nov. 4, 2011; U.S. patent application Ser.
No. 13/289,050 filed on Nov. 4, 2011; U.S. patent application Ser.
No. 13/297,348, entitled "Method and Apparatus for Interfacing with
a Smartcard" and filed on Nov. 16, 2011; U.S. patent application
Ser. No. 13/354,513, entitled "Method and Apparatus for Memory
Management" and filed on Jan. 20, 2012; 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; 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; 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; 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; 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; U.S. patent application Ser. No. 13/408,457, entitled "Method
and Apparatus for Rapid Group Synchronization" and filed on Feb.
29, 2012; U.S. patent application Ser. No. 13/408,461, entitled
"Method and Apparatus for Addressing in a Resource-Constrained
Network" and filed on Feb. 29, 2012; 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 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.
[0004] Each of the above-referenced applications is hereby
incorporated herein by reference in its entirety.
FIELD OF THE INVENTION
[0005] Certain embodiments of the invention relate to networking.
More specifically, certain embodiments of the invention relate to a
method and apparatus for dynamic media access control in a multiple
access system.
BACKGROUND OF THE INVENTION
[0006] Existing methods of media access control for a shared
communication medium are often 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
[0007] A system and/or method is provided for dynamic media access
control in a multiple access system, substantially as illustrated
by and/or described in connection with at least one of the figures,
as set forth more completely in the claims.
[0008] 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
[0009] FIG. 1 depicts exemplary communication devices which may
comprise a dynamically adaptable media access controller.
[0010] FIG. 2 is a diagram illustrating aspects of the invention
taking place at different layers of the OSI model.
[0011] FIGS. 3A-3C are a flowchart illustrating the use of dynamic
CSMA for communicating over a shared physical medium.
[0012] FIG. 4A is a flowchart illustrating hold-state or idle-state
operation of an electronic device.
[0013] FIG. 4B is a flowchart illustrating receive-state operation
of an electronic device.
[0014] FIG. 5A is a flowchart illustrating the determination of
guard time for a CSMA process based on a type of message to be
transmitted.
[0015] FIG. 5B is a flowchart illustrating the determination of
guard time for a CSMA process based on a rate at which a message is
to be transmitted.
[0016] FIG. 5C is a flowchart illustrating the determination of
guard time for a CSMA process based on a length of a message to be
transmitted.
[0017] FIGS. 6A-6D depict data structures which may be utilized for
implementing dynamic media access control algorithms.
[0018] FIG. 7 depicts an exemplary file system in a device
comprising a dynamically adaptable media access controller.
[0019] FIG. 8 is a flowchart illustrating exemplary steps for
channel scanning in a device comprising a dynamically adaptable
media access controller.
[0020] FIG. 9 is a flowchart illustrating exemplary steps for
beacon transmission by a device comprising a dynamically adaptable
media access controller.
[0021] FIGS. 10A-10C illustrate generation of parameters utilized
by a dynamically adaptable media access controller.
[0022] FIG. 11A illustrates the structure of an exemplary physical
layer frame containing a first type of data link layer protocol
data unit (PDU).
[0023] FIG. 11B illustrates the structure of an exemplary physical
layer frame containing a second type of data link layer protocol
data unit (PDU).
[0024] FIG. 12A illustrates the structure of an exemplary first
type of network-layer PDU.
[0025] FIG. 12B illustrates the structure of an exemplary second
type of network-layer PDU.
[0026] FIG. 13 depicts the structure of an exemplary
transport-layer PDU.
[0027] FIGS. 14A-14E depict the structure of exemplary portions of
a transport-layer PDU.
[0028] FIGS. 15A-15F depict the structure of exemplary portions of
a transport-layer PDU.
DETAILED DESCRIPTION OF THE INVENTION
[0029] 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 terms "e.g.," and "for
example," introduce a list of one or more non-limiting examples,
instances, or illustrations.
[0030] 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.
[0031] 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.
[0032] 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).
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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. Each of the clocks 211 and
221 may comprise, for example, one or more crystal oscillators,
phase-locked loops, and/or direct digital synthesizers. Each of the
clocks 211 and 221 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.
[0039] 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.
[0040] 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.
[0041] 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. In communicating
over the physical medium (e.g., the airwaves for wireless
communication or a cable for wired communication), values of one or
more media access control (MAC) parameters that control when and/or
how to access the physical medium may be dynamic (i.e., configured
"real-time" or "on-the-fly"). For example, values of one or more
MAC parameters may be changed on a per-message and/or per-dialog
(an exchange of one or more logically-related messages) basis.
Exemplary MAC parameters whose values may be dynamically determined
include: which channel(s) to transmit and/or receive on, whether to
utilize CSMA, how long to listen before transmitting, how long to
listen after transmitting, and/or how long a channel must be free
before transmitting on that channel. Parameter values may, for
example, change based on the contents of a message received over
the medium and/or based on instructions stored locally (e.g., in
memory 216 for the device 104). Such instructions may, for example,
be generated by an application and/or operating system running on
the device 102 and/or 104.
[0042] FIG. 2 is a diagram illustrating aspects of the invention
taking place at different layers of the OSI model. As shown in FIG.
2, the device 104 may comprise: a congestion module 230 and/or a
flow control module 232 which may operate at the transport layer
(layer 4 of the OSI model); a carrier sense multiple access (CSMA)
module 236 which may operate at the data link layer (layer 2 of the
OSI model); and a received signal strength indicator (RSSI) module
which may operate at the physical layer (layer 1 of the OSI model).
The device 104 may also comprise a register 234 which may be
readable and/or modifiable by the congestion control module 230,
the flow control module 232, and/or the CSMA module 236.
[0043] In operation, the device 104 may receive a request message
and decide to transmit a response message in reply to the request
message. For the transmission of the response message, the
congestion control module 230 may receive a parameter T.sub.CA0, a
parameter T.sub.G, a parameter CSMA_options, and a parameter
ch_list. The parameters may be utilized directly in controlling
access to the physical medium and/or utilized for determining
values of other parameters which, in turn, may be utilized in
controlling access to the physical medium. One or more of the
parameters may have been received in, and/or derived from,
information contained in the received request message. In this
manner, the requesting device may control, at least in part, if,
how, and/or when the responding device 104 transmits a response to
the request.
[0044] The parameter ch_list may comprise a list of channel
identifiers, where each channel identifier is uniquely associated
with a particular combination of center frequency and bandwidth.
The list of channels may correspond to channels on which the
requesting device (i.e., the device that sent the request message)
will listen for responses. The congestion control module 230 may
modify the parameter ch_list to generate ch_list' which may then be
passed onto the CSMA module 236. The modification of ch_list to
generate ch_list' may be, for example, to remove one or more
channels from the list because the device 104 is aware that the
removed channel is highly congested, the device 104 does not
support the channel, and/or for some other reason.
[0045] The parameter T.sub.CA0 may correspond to the amount of time
that the device 104 has to begin transmitting the response message
onto the physical medium. In an exemplary embodiment, T.sub.CA0 may
correspond to T.sub.C-T.sub.resp, where the value of T.sub.C
("contention period" or "response timeout") is the amount of time
that the requesting device is going to listen for responses to the
request message (T.sub.C may have been received in the request
message), and T.sub.resp is the amount of time it will take the
device 104 to transmit the response message.
[0046] The parameter CSMA_options may indicate whether to utilize
carrier sense (i.e., whether to "listen before talk") and/or which
equations and/or algorithms the device 104 should utilize for
calculating values for one or more timing parameters utilized by
the CSMA module 236 and/or the congestion control module 230. Two
exemplary parameters which may be calculated are T.sub.G' ("guard
time) and T.sub.CA ("collision avoidance timeout"). To illustrate,
in an exemplary embodiment, T.sub.CA may be set equal to T.sub.CA0
for a first value of CSMA_options, but T.sub.CA may be set equal to
T.sub.CA0/2 for a second CSMA_options. Other factors may
additionally or alternatively be used for calculating T.sub.CA.
Such factors may comprise, for example, characteristics (e.g., type
and/or length) of the response message, and/or characteristics
(e.g., data rate, frequency, bandwidth, modulation type, and/or
symbol rate) of the channel onto which the response message is to
be transmitted. After calculating T.sub.CA, the congestion control
module 230 may store the value of T.sub.CA in the register 234.
[0047] The parameter T.sub.G may be an initial value for a
parameter T.sub.G' ("guard time"). T.sub.G' which may determine how
long the device 104 must sense the physical medium as being
inactive before the device 104 begins transmitting the response
message onto the physical medium. Other factors in determining a
value of T.sub.G' may include CSMA_options, T.sub.CA, T.sub.CA0,
characteristics (e.g., type and/or length) of the response message,
and/or characteristics (e.g., data rate, frequency, bandwidth,
modulation type, and/or symbol rate) of the channel onto which the
response message is to be transmitted.
[0048] Upon initialization from the congestion control module 230,
the CSMA module 236 may perform CSMA as, for example, described
below in reference to FIG. 3C. If an available channel is detected,
the CSMA module 236 may assert TxEN and the flow control module 232
may then manage the transmission of the response packet onto the
medium on the available channel. Upon TxEN being asserted, the flow
control module 232 may modify the value stored in the register 234.
If, after trying for a period of time equal to T.sub.CA, none of
the channels in the channel list are determined to be available,
then, depending on the value of T.sub.CA, the device 104 may abort
transmission of the response or may take a break and try again
later. For example, if the congestion control module sets
T.sub.CA=T.sub.CA0 then upon the CSMA failing to obtain access to
the medium for a period of time T.sub.CA, the device 104 may abort
transmission of the response message. Conversely, if
T.sub.CA<T.sub.CA0, then the congestion control module 230 may
wait for a period of time T.sub.wait, and then trigger the CSMA
module 236 to once again attempt to gain access to the medium. The
second attempt may last for up to a period of time equal to
T.sub.CA0-T.sub.CA-T.sub.wait. Factors in determining a value of
T.sub.wait may include CSMA_options, T.sub.CA, T.sub.CA0,
characteristics (e.g., type and/or length) of the response message,
and/or characteristics (e.g., data rate, frequency, bandwidth,
modulation type, and/or symbol rate) of the channel onto which the
response message is to be transmitted.
[0049] FIGS. 3A-3C are a flowchart illustrating the use of dynamic
CSMA for communicating over a shared physical medium. Referring to
FIG. 3A, the exemplary steps begin with step 302 in which the
device 102 generates a request message. The message may, for
example, comprise a query template and seek responses from devices
which possess certain characteristics and/or store certain
data.
[0050] In step 304, the device 102 determines a value of one or
more parameters that instruct devices receiving the request as to
if, how, and/or when to send responses to the request message. For
example, the device 102 may determine a value of T.sub.C (the
amount of time it will listen for responses to the request),
CSMA_options (a flag which indicates an equation and/or algorithm
that responding devices should use when calculating values for
certain timing parameters), and a list of one or more channels on
which the device 102 will listen for responses. The device 102 may
determine T.sub.C, CSMA_options, and/or the channel list based on,
for example: the type of request, the symbol rate of the channel(s)
over which the request will be transmitted and/or responses
received, the results of past requests (e.g., knowledge about the
devices that have responded to past requests), the location of the
device 102 (e.g., based on received GPS signals, other wireless
signals, and/or user input), the number or responses that are
desired, and/or any other suitable criteria. For example, the
device 102 may set T.sub.C to a larger value if it wants to receive
many and/or long responses, and may set T.sub.C to a smaller value
if it wants to receiver fewer and/or shorter responses.
[0051] In step 306, the device 102 inserts the value(s) of the one
or more parameters calculated in step 304 into one or more fields
of the request message. In step 308, the device 102 transmits the
request message. In an exemplary embodiment, the device 102 may
perform CSMA and transmit the request message only upon sensing
that the medium is free. In such instances, timing parameters
utilized as part of the CSMA process may be the same as the values
calculated for the potential response messages, or may be
different. For example, first values of timing parameters, such as
T.sub.CA and T.sub.G', may be utilized when transmitting request
messages whereas second values of timing parameters, such as
T.sub.CA and T.sub.G', may be utilized when transmitting response
messages. In another exemplary embodiment, for request messages,
the device 102 may not sense whether another device is already
transmitting because, for example, it may not care whether a
collision occurs or may know (e.g., through scheduling) that the
medium is free.
[0052] In step 310, the request message is received by the device
104. In step 312, the device 104 processes the received request
message and decides to transmit a response message. In step 314,
the device 104 determine values of T.sub.CA and T.sub.G' to be
utilized for transmitting the response message. The value of
T.sub.CA for the response message may be calculated, for example,
as described above with respect to FIG. 2. The value of T.sub.G'
for the response message be calculated as, for example, described
below with respect to FIGS. 5A-5C.
[0053] Referring now to FIG. 3B, in step 316 it is determined
whether the value of T.sub.CA calculated in step 314 is compared to
a threshold. If the value of T.sub.CA is less than a threshold
(i.e., the requesting device will cease listening before the
complete response message can be transmitted) then in step 318, the
device 104 aborts transmission of the response message.
[0054] Returning to step 316, if the value of T.sub.CA is greater
than the threshold, then, in step 320, the congestion control
module 230 triggers the CSMA process performed by the CSMA module
236. In step 322, the CSMA process described below with respect to
FIG. 4B takes place. In step 324, if transmission was successful
(i.e., either CSMA was disabled or an available channel for
transmitting the response message was detected during step 322),
then the exemplary steps advance to step 330. In step 330, the flow
control module 232 sets the T.sub.CA register 234 to a value
guaranteed to be less than the threshold utilized in step 316. For
example, the flow control module 232 may set the T.sub.CA register
234 to a value of -1.
[0055] Returning to step 324, if the step 322 did not result in a
successful transmission, then the exemplary steps advance to step
326. In step 326, the congestion control module counts down an
amount of time T.sub.wait. The value of T.sub.wait may be
calculated based on variety of factors such as, for example,
CSMA_options, T.sub.CA0, T.sub.CA, T.sub.G', the length of the
response message, the type (e.g., foreground or background) of the
response message, the symbol rate at which the response message is
to be transmitted, and/or a search score generated by comparing a
received search token with locally stored data.
[0056] In step 328, the value stored in the T.sub.CA register 234
is updated. In an exemplary embodiment, the value stored in the
register 234 may be updated by subtracting off the amount of time
that has elapsed since the value was calculated. In another
exemplary embodiment, a new value of T.sub.CA may be calculated
based on, for example, CSMA_options, T.sub.G,' and/or on how much
time is left in the contention period (the time period of duration
T.sub.C during which the requesting device will listen for
responses).
[0057] Referring now to FIG. 3C, in step 342, if CSMA is disabled
(i.e., the device 104 is configured to transmit onto the medium
without first sensing whether another device is currently
transmitting) then the steps advance to step 356. In step 356, the
CSMA module 236 asserts TxEN. In step 358 the message is
transmitted by the flow control module 232.
[0058] Returning to step 342, if CSMA is enabled, then in step 344,
a variable i is set to 1. In step 346, the physical layer receiver
of the device 104 is powered-up and configured to receive on the
i.sup.th channel identified by the parameter ch_list'. In step 348,
the CSMA module 236 detects whether CS from the physical layer is
asserted. The PHY may assert CS when the received signal strength
is above a threshold. The threshold utilized by the RSSI module 238
may have been pre-configured by an administrator and/or configured
dynamically based on, for example, past performance and/or based on
information contained in the received request message. If CS is not
asserted, then in step 350, the CSMA module 236 waits for a period
of time equal to T.sub.G'. In step 352, the CSMA module 236 again
detects whether CS from the physical layer is asserted. If CS is
not asserted then, in step 356 the CSMA module 236 asserts TxEN. In
step 358 the flow control module 232 manages the transmission of
the response message onto the physical medium.
[0059] Returning to steps 348 and 352, if either of these steps
detect that CS is asserted, then the exemplary steps advance to
step 362. In step 362, the variable i is incremented by 1. In step
364, the value of T.sub.CA in register 236 is updated by
subtracting off the amount of time that has elapsed since the
register was last programmed. In step 366, the updated value of
T.sub.CA is compared to a threshold (i.e. it is determined whether
there would still be time to transmit the response message before
the contention period ends). If not, then in step 370, TxEN remains
deasserted and the steps advance to step 360. If so, then in step
368 it is determined whether all channels in the channel list have
been checked for availability. If not, then the exemplary steps
return to step 346. If all channels have been checked, then the
exemplary steps advance to step 370.
[0060] FIG. 4A is a flowchart illustrating hold-state or idle-state
operation of an electronic device. The exemplary steps begin with
step 402 when the device 104 enters an idle or hold state of
operation. In step 404, the device 104 determines values of one or
more MAC parameters such as, for example, Channel ID, scan duration
(T.sub.SD), and time-to-next-scan (T.sub.NS). In step 406, upon the
triggering of a scan (e.g., based on a value of T.sub.NS and/or a
real-time clock) a physical layer receiver of the device 104 is
powered-up and configured to listen on the channel indicated by the
value of Channel ID determined in step 404. In step 408, if the
device listens for T.sub.SD without CS being asserted, then the
exemplary steps advance to step 410. In step 410, the device 104
waits an amount of time equal to T.sub.NS before returning to step
404. On the other hand, in step 408, if CS is asserted before
T.sub.SD times out, then the device 104 may transition to a receive
state of operation as, for example, described with respect to FIG.
4B.
[0061] FIG. 4B is a flowchart illustrating receive-state operation
of an electronic device. The steps begin with step 414 when the
device 104 enters a receive state of operation. In step 416 the
device may receive a number of bits which may constitute all or
part of a frame. In step 418, the device 104 may compare at least a
portion of the received bits to one or more known values. The
result of the comparison may indicate whether the bits received in
step 418 were part of a valid frame and, if so, the type of frame.
For example, a valid frame may begin with a plurality of bits that
constitute a sync word. Accordingly, the device 104 may compare the
initial plurality of bits to one or more known-good values of the
sync word. If the initial plurality of bits is not a valid sync
word, then the received bits may be discarded and the device
returns to an idle or hold state of operation. If the initial
plurality of bits is a valid sync word, then the exemplary steps
advance to step 420.
[0062] In step 420, the device may receive any remaining bits of
the frame. In step 422, the device 104 may parse one or more fields
of the received frame to determine whether the device 104 was an
intended recipient of the frame and/or whether the device 104 cares
about the frame (i.e., wants to devote resources to further
processing the message). Frames not intended for the device 104
and/or not of interest to the device 104 may be discarded without
further processing. In step 424, if there are additional frames to
be received then the steps may return to step 420. If there are no
additional frames to receive then in step 426 the device 104 may
determine whether the received packet passes (i.e. is not dropped
during) MAC filtering. If not, then the device 104 may return to
step 408 in which it may re-evaluate T.sub.SD and reinitialize
reception. If so, then the device 104 may transition to a transmit
state (e.g., as described in portions of FIGS. 4A-4C).
[0063] FIG. 5A is a flowchart illustrating the determination of
guard time for a CSMA process based on a type of message to be
transmitted. The exemplary steps begin with step 502 when the
device 104 has a frame to transmit. In step 504 the device 104 may
determine whether the frame to be transmitted is a first type of
frame (e.g., a foreground frame) or a second type of frame (e.g., a
background frame). If the frame is of the first type, then in step
506 T.sub.G' may be set to a first value. If the frame is of the
first type, then in step 506 T.sub.G' may be set to a second value,
which may be higher than the first value.
[0064] FIG. 5B is a flowchart illustrating the determination of
guard time for a CSMA process based on a symbol rate at which a
message is to be transmitted. The exemplary steps begin with step
510 when the device 104 has a frame to transmit. In step 512 the
device 104 may determine whether the frame to be transmitted at a
first symbol rate (e.g., 200 kS/s) or at a second symbol rate
(e.g., 55.55 kS/s). If the frame is to be transmitted at the first
symbol rate, then, in step 514, T.sub.G' may be set to a first
value. If the frame is to be transmitted at the second symbol rate,
then in step 506 T.sub.G' may be set to a second value, which may
be higher than the first value.
[0065] FIG. 5C is a flowchart illustrating the determination of
guard time for a CSMA process based on a length of a message to be
transmitted. The exemplary steps begin with step 520 when the
device 104 has a frame to transmit. In step 522 the device 104 may
determine whether the length of the frame to be transmitted is
below or above a threshold. If the length of the frame is less than
the threshold, then, in step 524, T.sub.G' may be set to a first
value. If the length of the frame is greater than the threshold,
then, in step 526, T.sub.G' may be set to a second value, which may
be higher than the first value.
[0066] Although FIGS. 5A-5C illustrate scenarios selecting between
two values of T.sub.G', in practice values of T.sub.G' may be
selected from a larger set of options such that T.sub.G' could be
controlled with more granularity.
[0067] FIGS. 6A-6D depict data structures which may be utilized for
implementing dynamic media access control algorithms.
[0068] Referring to FIG. 6A, there is shown a scan n-tuple (a
four-tuple) 602 comprising a Channel ID field 604.sub.1, a scan
type field 604.sub.2, a scan duration field 604.sub.3, and a
time-to-next-scan field 604.sub.4. The Channel ID field 604.sub.1
may indicate a frequency and/or bandwidth of a channel on which to
listen for traffic. The scan type field 604.sub.2 may determine the
type of frame(s) to listen for (e.g., background or foreground
frames). The scan duration field 604.sub.3 may indicate how long to
listen to the channel. The time-to-next scan field 604.sub.4 may
indicate how long to wait between listening to the channel
identified in scan n-tuple 602 and listening to a channel
identified in another scan n-tuple.
[0069] Referring to FIG. 6B, there is shown an exemplary sequence
606 of scan n-tuples 602.sub.1-602.sub.M, where M is an integer.
Each of the scan n-tuples 602.sub.1-602.sub.M in the sequence 606
may be as described with respect to FIG. 6A.
[0070] In operation, upon entering an idle state of operation
(e.g., at a time triggered by a real-time clock), the device 104
may read the first scan n-tuple 602.sub.1, listen to the channel
identified by field 604.sub.1 of scan n-tuple 602.sub.1 for the
type of frame identified in field 604.sub.2 of scan n-tuple
602.sub.1. The device 104 may begin counting-down the amount of
time in field 604.sub.4 while concurrently beginning listening for
the amount of time in field 604.sub.3. After the longer of these
two time fields expires, the device 104 may read the next scan
n-tuple 602.sub.2 in the sequence 606 and operate accordingly, that
is, enter a listen state followed by a wait state according to the
fields of the scan n-tuple 602.sub.2. The device 104 may repeat
this process until it has operated in accordance with each of the
scan n-tuples 602.sub.1-602.sub.M. After completing the scan
described in the last n-tuple of the sequence 606, the device may
return to the first n-tuple in the sequence 614.
[0071] Referring to FIG. 6C, there is shown a beacon n-tuple (a
six-tuple) 610 comprising a Channel ID field 612.sub.1, a CSMA
options field 612.sub.2, a pointer 612.sub.3, a contention period
duration (T.sub.C) field 612.sub.4, a redundancy count field
612.sub.5, and a time-to-next-beacon field 612.sub.5. The Channel
ID field 612.sub.1 may indicate a frequency and/or bandwidth of a
channel on which to transmit a beacon. The CSMA options field
612.sub.2 may indicate if responses should utilize CSMA when
responding and, if so, how they should determine parameters for
performing the CSMA. The pointer field 612.sub.3 may point to a
file or block of data that is to be transmitted as part of the
beacon (e.g., transmitted as the payload of a frame). The
contention period duration field 612.sub.4 may indicate how long
the device should listen for responses to the beacon. The
redundancy count field 612.sub.5 may indicate how many times the
beacon transmission should be repeated. The time-to-next beacon
field 612.sub.6 may indicate how long to wait between transmitting
the beacon described in beacon n-tuple 610 and transmitting a
beacon described in another beacon n-tuple.
[0072] Referring to FIG. 6D, there is shown an exemplary sequence
614 of beacon n-tuples 610.sub.1-610.sub.M, where M is an integer.
Each of the beacon n-tuples in the sequence 614 may be as described
with respect to FIG. 6C.
[0073] In operation, upon entering a beacon transmit state of
operation (e.g., at a time triggered by a real-time clock), the
device 104 may read the first beacon n-tuple 610.sub.1 and transmit
a beacon comprising: data pointed to by field 612.sub.3 of n-tuple
610.sub.1; and fields determined by field 612.sub.3 of beacon
n-tuple. The device may then listen for responses to the beacon for
the amount of time indicated in field 612.sub.4 of n-tuple
610.sub.1. The device may repeat the beacon up to the number of
times in field 612.sub.5 of n-tuple 610.sub.1 until a response is
received or until the amount of time T.sub.NB in field 612.sub.6 of
n-tuple 610.sub.1 elapses. After a response is received, or
T.sub.NB elapses, the device 104 may read the next n-tuple
610.sub.2 in the sequence 614 and operate accordingly, that is,
enter a transmit state followed by a listen state and/or a wait
state according to the fields of the n-tuple 610.sub.2. The device
104 may repeat this process until it has operated in accordance
with each of the n-tuples 610.sub.1-610.sub.M. After completing
beacon transmission in accordance with the last n-tuple in the
sequence 614, the device may exit the beacon transmit mode of
operation or may return to the first n-tuple in the sequence
614.
[0074] The n-tuples, sequences, and states of operation described
with respect to FIGS. 6A-6D are only exemplary. Other
implementations in which channel scan and and/or transmit
operations are controlled by one or more ordered sets of parameters
will be understood from the foregoing and from inspection of the
above-incorporated U.S. Provisional Patent Application Ser. No.
61/464,376.
[0075] FIG. 7 depicts an exemplary file system in a device
comprising a dynamically adaptable media access controller. The
file system comprises a scan sequence 606.sub.1, a scan sequence
606.sub.2, a beacon transmit sequence 614.sub.1, a beacon transmit
sequence 614.sub.2, portion 702 for storing media access control
parameters, and a portion 704 for storing data. The file system may
be, for example, the same as or similar to the indexed short file
block (IFSB) described in the above-incorporated U.S. Provisional
Patent Application Ser. No. 61/464,376.
[0076] The sequences 606.sub.1 and 606.sub.2 may be instances of
the sequence 606 described in FIG. 6B. Which of the sequences
606.sub.1 and 606.sub.2 is utilized for scanning at any particular
time may depend on a variety of factors such as, for example: where
the device is located, time of day/week/month/year, type(s) of
device(s) to be communicated with, number of devices to be
communicated with, types of messages to be listened for, time since
last transmit and/or receive activity, etc. In an exemplary
embodiment, the sequence 606.sub.1 may be utilized when the device
is in an idle state of operation and the sequence 606.sub.2 may be
utilized when the device is in a hold state of operation. In an
exemplary embodiment, the sequence 606.sub.1 may be utilized when
the device is operating in a first location and the sequence
606.sub.2 may be utilized when the device is operating in a second
location
[0077] The sequences 614.sub.1 and 614.sub.2 may be instances of
the sequence 614 described in FIG. 6D. Which of the sequences
614.sub.1 and 614.sub.2 is utilized for transmitting beacons at any
particular time may depend on a variety of factors such as, for
example: where the device is located, time of day/week/month/year,
type(s) of device(s) to be communicated with, number of devices to
be communicated with, types of data to be sent in the beacons, etc.
In an exemplary embodiment, the sequence 606.sub.1 may be utilized
when transmitting beacons intended for a first type of device and
the sequence 606.sub.2 may be utilized when transmitting beacons
intended for a second type of device. In an exemplary embodiment,
the sequence 606.sub.1 may be utilized when transmitting beacons in
a first location and the sequence 606.sub.2 may be utilized when
transmitting beacons in a second location.
[0078] The portion 702 may store values of one or more parameters
such as, for example, parameters which configure the congestion
control module 230, the flow control module 232, the CSMA module
236, and/or the RSSI module 238. Such parameters may, for example,
be programmed into the portion 702 by a system administrator and/or
may be configured based on received request messages.
[0079] The portion 704 may store data as, for example, described
with reference to the indexed short file block (ISFB), the indexed
short file series block (ISFSB), and/or the generic file block
(GFB) described in the above-incorporated U.S. Provisional Patent
Application Ser. No. 61/464,376.
[0080] FIG. 8 is a flowchart illustrating exemplary steps for
channel scanning in a device comprising a dynamically adaptable
media access controller. The exemplary steps begin with step 802 in
which a scan sequence is triggered in the device 104. The scan
sequence may be triggered by, for example, a real-time clock
reaching a predetermined value. In step 804, a variable i is set to
1. In step 806, the device 104 gets an n-tuple 602.sub.i. The
n-tuple 602.sub.i may be, for example, input via the programming
interface 222 and/or read from the memory 216. In step 808, one or
more configuration registers or variables for performing a channel
scan may be set to the values in the n-tuple 602.sub.i. For
example, the Channel ID for scan i may be set to value of the
Channel ID field 604.sub.1 of the n-tuple 602.sub.i, the scan type
for scan i may be set to the value of the scan type field 604.sub.2
of the n-tuple 602.sub.i, the scan duration for the scan i may be
set to the value of the scan duration field 604.sub.3 of the
n-tuple 602.sub.i, and the time-to-next-scan value for the scan i
may be set to the value of the time-to-next scan field 604.sub.4 of
the n-tuple 602.sub.i.
[0081] In step 810, the PHY of the device 104 may be configured
according to the Channel ID. That is, the center frequency and
bandwidth of the receiver may be configured according to the
Channel ID.
[0082] In step 812, the device 104 may listen for a sync word that
corresponds to the scan type of the scan i. If the scan duration
elapses, and/or if the received signal strength on the channel
being scanned goes below a threshold value (which may be
configurable), without receiving the sync word, then in step 813
the device 104 may wait for the remainder of T.sub.NS, which may
have started counting in step 806 or 808 (e.g., if 100 milliseconds
have elapsed since the n-tuple 602.sub.i was retrieved, then the
device may wait for T.sub.NS-100 ms in step 813).
[0083] In step 814 it may be determined whether i has reached a
maximum value. The maximum value of i may be, for example, M+1
(where M is the number of n-tuples in the sequence 606). If i has
not reached its maximum value, then, in step 816, i may be
incremented and the steps may return to step 806.
[0084] Returning to step 814, if i has reached its maximum value,
then in step 818 the scan sequence may be complete. Upon completing
the scan sequence, the device 104 may, for example, begin a new
scan sequence, begin a beacon transmit sequence, or go into a sleep
mode.
[0085] Returning to step 812, if a sync word of the type being
listened for is received before the scan duration times out, then
in step 820 the device 104 will receive one or more frames and, in
step 822, process the received frame(s). If in step 822 one or more
of the received frames are dropped during MAC filtering, step 812
may be resumed.
[0086] FIG. 9 is a flowchart illustrating exemplary steps for
beacon transmission by a device comprising a dynamically adaptable
media access controller. The exemplary steps begin with step 902 in
which a beacon transmit sequence is triggered in the device 104.
The scan sequence may be triggered by, for example, a real-time
clock reaching a predetermined value. In step 904, a variable i is
set to 1. In step 906, the device 104 gets an n-tuple 610.sub.i.
The n-tuple 610.sub.i may be, for example, input via the
programming interface 222 and/or read from the memory 216. In step
908, one or configuration registers or variables for performing a
channel scan may be set to the values in the n-tuple 610.sub.i. For
example, the Channel ID for beacon i may be set to value of the
Channel ID field 612.sub.1 of the n-tuple 610.sub.i; CSMA options
for responses to beacon i may be set to the CSMA options field
612.sub.2 of the n-tuple 610.sub.i; the data transmitted in beacon
i may be the data pointed to by the pointer field 612.sub.3 of the
n-tuple 610; the amount of time the device 104 listens for
responses to beacon i may be the value in the contention period
duration (T.sub.C) field 612.sub.4 of the n-tuple 610.sub.i; R, the
maximum number of times that the device 104 repeats transmission of
the beacon i, may be set to the value of the redundancy count field
612.sub.5 of the n-tuple 610.sub.i; and T.sub.NB, the time at which
the device 104 transmits beacon i+1 may be set to the value of the
time-to-next-beacon field 612.sub.5 of the n-tuple 610.sub.i. In
step 912, the beacon i is transmitted onto the physical medium. In
step 914, the device 104 may listen for a response for up to
T.sub.C. In step 916, the value R may be decremented by 1 and, in
step 918, if R is greater than zero, then the steps may return to
step 912.
[0087] Returning to step 918, if R is less than or equal to zero,
then in step 920 the device may wait for the remainder of T.sub.NB,
which may have started counting in step 906 or 908 (e.g., if 100
milliseconds have elapsed since the n-tuple 602.sub.i; was
retrieved, then the device may wait for T.sub.NB-100 ms in step
920). In step 922, it may be determined whether i has reached a
maximum value. The maximum value of i may be, for example, the
number of n-tuples in a sequence 614. If i has not reached its
maximum value and no acknowledgement was detected in step 914,
then, in step 924, i may be incremented and the steps may return to
step 906.
[0088] Returning to step 922, if i has reached its maximum value,
then in step 926 the beacon transmit sequence may be complete. Upon
completing the beacon transmit sequence, the device 104 may, for
example, begin a new beacon transmit sequence, begin a scan
sequence, or go into a sleep mode.
[0089] FIGS. 10A-10C illustrate generation of parameters utilized
by a dynamically adaptable media access controller. A device, such
as device 104, may comprise a parameter generation module 1002
which may be operable to configuring media access control in the
device 104 based on a high-level input from, for example, an
application or operating system of the device 104 (e.g., via an
application programming interface).
[0090] Referring to FIG. 10A, in response to a request to implement
a first MAC protocol, the parameter generation module 1002
generates a set of parameter values 1004 which may be utilized by,
for example, the congestion control module 232, the flow control
module 234, and/or the CSMA module 236.
[0091] Referring to FIG. 10B, in response to a request to implement
a second MAC protocol, the parameter generation module 1002
generates a set of parameter values 1006 which may be utilized by,
for example, the congestion control module 232, the flow control
module 234, and/or the CSMA module 236.
[0092] In FIGS. 10A and 10B, the parameter values to realize the
first and second MAC protocols were static. Some MAC protocols,
however, may require the periodic or continual (e.g., at or near
real-time) updating of values of the parameters. For example, in
FIG. 10C, a third MAC protocol is implemented by alternating
between a set of parameter values 1008 and a set of parameter
values 1010.
[0093] Thus, as illustrated in FIGS. 10A-10C, a variety of time
and/or frequency division multiple access protocols may be
implemented in the device 104 simply through intelligent control of
one or more parameter values. Such protocols could include, for
example, media access control utilized in IEEE 802.11 and IEEE
802.15.4.
[0094] FIG. 11A illustrates the structure of an exemplary physical
layer frame containing a first type of data link layer protocol
data unit (PDU). The physical layer frame comprises a preamble, a
sync word, and a payload. The payload comprises a data link layer
(OSI layer 2) PDU, in this case, a background frame. The background
frame comprises a subnet field, a background protocol ID (BPID)
field, and CRC field. The payload comprises a background protocol
ID (BPID) field and protocol data. The protocol data comprises a
channel ID field and an estimated time of arrival (ETA) field if
the background protocol is the advertising protocol. The protocol
data comprises a reservation type field and a reservation duration
field if the background protocol is the reservation protocol.
[0095] FIG. 11B illustrates the structure of an exemplary physical
layer frame containing a second type of data link layer protocol
data unit (PDU). The physical layer frame comprises a preamble, a
sync word, and a payload. The payload comprises a data link layer
(OSI layer 2) PDU, in this case, a foreground frame. The foreground
frame comprises a length field, a headers field, a payload, a
footer, and a cyclic redundancy check field. The payload may
comprise a network layer (OSI layer 3) PDU. The headers field
comprises TxEIRP field, a subnet field, a frame control field, a
data link layer security (DLLS) code, DLLS initialization data, a
dialog identifier, a flags field, a source ID, and a target ID. The
frame control field comprises a listen flag, a DLLS flag, an enable
addressing flag, a frame continuity flag, a CRC32 flag, a not mode
2 flag, and a mode 2 frame type flag. The flags field comprises an
addressing option flag, a virtual ID flag, a network layer security
flag, and application flags.
[0096] FIG. 12A illustrates the structure of an exemplary first
type of network-layer PDU. In FIG. 12A, the enable addressing field
of the layer 2 PDU indicates that the PDU contained in the payload
of the layer 2 PDU is a mode 2 datastream protocol (M2DP) PDU.
Specifically, the payload of the layer 2 PDU comprises a frame ID
field and a M2DP payload.
[0097] FIG. 12B illustrates the structure of an exemplary second
type of network layer PDU. In FIG. 12B, the enable addressing field
of the layer 2 PDU indicates that the PDU contained in the payload
of the layer 2 PDU is a mode 2 network protocol (M2NP) PDU.
Specifically, the payload of the layer 2 PDU comprises a mode 2
network layer security (M2NLS) code, M2NLS initialization data, a
target address, a hop control field, a hop extension field, an
origin device ID, a destination device ID, a M2NP payload, and M2NP
authentication data. The M2NP payload may contain a layer 4 PDU.
The hop control field comprises hop extension flag, an Origin ID
flag, a Destination ID flag, origin/destination virtual ID flag,
and a hops remaining field.
[0098] FIG. 13 depicts the structure of an exemplary
transport-layer PDU. The transport protocol associated with the PDU
in FIG. 13 is the mode 2 query protocol (M2QP). The M2QP PDU
("command") comprises a command code field, a command control
field, and may comprise one or more of a dialog template, an ack
template, a global query template, a local query template, an error
template, and a command data template. The command code field
comprises an extension flag, a command type field, and an M2QP
opcode. The command extension field comprises a collision avoidance
(CA) type field, a no CSMA flag, and a no response flag. The
structures of the various templates are described with respect to
FIGS. 14A-14E.
[0099] FIGS. 14A-14E depict the structure of exemplary portions of
a transport-layer PDU. In FIG. 14A, the dialog template comprises a
response timeout field, a response channel list length field, and a
response channel list. In FIG. 14B, the ack template comprises a
number of ack fields and an ack device IDs field. In FIG. 14C, the
query template 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. 14D, the error
template comprises an error code field, an error subcode field, an
M2QP error data field, and an extended error data field. In FIG.
14E, the command data template 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. 15A-15F.
[0100] FIGS. 15A-15F depict the structure of exemplary portions of
a transport-layer PDU. In FIG. 15A, for an M2QP opcode that
indicates file, the comparison template comprises a comparison file
ID and a comparison byte offset. In FIG. 15B, for an M2QP opcode
that indicates series, the comparison template comprises a
comparison series ID and a comparison byte offset. In FIG. 15C, for
an M2QP opcode that indicates file, the call template comprises a
max returned bytes field, a return file ID, and a return file entry
offset. In FIG. 15D, for an M2QP opcode that indicates series, the
call template comprises a max returned bytes field, a series ID,
and a file series data offset. In FIG. 15E, for an M2QP opcode that
indicates file, the return template comprises a return file ID, a
file offset, an IFSB total length, and file data. In FIG. 15F, for
an M2QP opcode 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.
[0101] Additional details of the frames and fields described above
with respect to FIGS. 11A-15F are described in the
above-incorporated U.S. Provisional Patent Application Ser. No.
61/464,376.
[0102] In accordance with various aspects of the present invention,
an electronic device 104 may be operable to control access to a
physical medium (e.g., airwaves, a copper cable, or an optical
fiber) utilizing carrier sense multiple access (CSMA). The amount
of time that the electronic device 104 must sense the physical
medium as being inactive before it permits transmission of a
message onto the physical medium may be determined based on: the
size of the message, the type of the message, the symbol rate at
which the message is to be transmitted, and/or a channel onto which
the message is to be transmitted. Similarly, how long and/or how
many times the electronic device attempts to transmit the message
may be based the size of the message, the type of the message, the
symbol rate at which the message is to be transmitted, and/or a
channel onto which the message is to be transmitted.
[0103] The message may be in response to a request received by the
electronic device via the physical medium, and the channel onto
which the message is to be transmitted may be determined based on a
field (e.g., Response Channel List) of the received request. The
field of the received request may comprises a list of channels, and
the electronic device 104 may sequentially listen to channels in
the list until a channel meeting certain requirements (e.g., signal
strength below a threshold for at least a period of time T.sub.G')
is found or until a timeout occurs (e.g., T.sub.CA has elapsed
since a CSMA process was initiated or T.sub.C has elapsed since the
request was sent). The maximum amount of time that the electronic
device 104 attempts to transmit the message onto the physical
medium may be determined based on a field (e.g., Response timeout)
of the received request message. While the message is pending
transmission, a portion of the electronic device 104 may alternate
between a listen state and a wait state, wherein the amount of time
in one or both of the listen state and the wait state may be
determined based on one or more fields (e.g., Response timeout
and/or CA type) of the received request. Additionally or
alternatively, the one or more fields of the received request may
determine an equation and/or algorithm utilized by the electronic
device for the determining the amount of time spent in one or both
of the listen state and the wait state.
[0104] The electronic device 104 may comprise memory and a receiver
and may be operable to: read a series of n-tuples from the memory,
each of the n-tuple comprising a channel identifier, a scan
duration value, and a time-to-next-scan value. For each of the read
n-tuples, the device 104 may be operable to: configure the receiver
to receive on the channel associated with the channel identifier
for an amount of time equal to the scan duration value; and
power-down the receiver for an amount of time equal to the
time-to-next-scan value minus the scan duration value.
[0105] The electronic device 104 may comprise a memory, a
transmitter, and a receiver and may be operable to read a series of
n-tuples from the memory, each of the n-tuple comprising a channel
identifier, a contention period value, and a time-to-next-scan
value. For each of the read n-tuples, the device 104 may be
operable to: configure the transmitter to transmit a beacon on the
channel associated with the channel identifier; configure the
receiver to listen for a response to the beacon for an amount of
time equal to the contention period value; and wait a period of
time equal to the time-to-next-scan value minus the contention
period value before operating based on the next n-tuple in the
series of n-tuples.
[0106] 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 dynamic media access
control in a multiple access system.
[0107] 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.
[0108] 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.
[0109] 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.
* * * * *