U.S. patent number 10,104,555 [Application Number 14/305,159] was granted by the patent office on 2018-10-16 for systems and methods for a cognitive radio having adaptable characteristics.
This patent grant is currently assigned to Shared Spectrum Company. The grantee listed for this patent is Shared Spectrum Company. Invention is credited to Igor Bazarov, Dmitry Dain, Eugene Livis, Mark Allen McHenry.
United States Patent |
10,104,555 |
Dain , et al. |
October 16, 2018 |
Systems and methods for a cognitive radio having adaptable
characteristics
Abstract
Systems and methods for configuring a network of radios for
dynamic spectrum access are described. A network radio can include
hardware and/or software modules for detecting a radio environment
and negotiating common communications channels with a plurality of
other radios in the network. Network radio behavior can be defined
by a plurality of predefined policies which are used in combination
with the information about the radio environment to select common
operating parameters.
Inventors: |
Dain; Dmitry (Herndon, VA),
Bazarov; Igor (Herndon, VA), Livis; Eugene (Vienna,
VA), McHenry; Mark Allen (McLean, VA) |
Applicant: |
Name |
City |
State |
Country |
Type |
Shared Spectrum Company |
Vienna |
VA |
US |
|
|
Assignee: |
Shared Spectrum Company
(Vienna, VA)
|
Family
ID: |
40526903 |
Appl.
No.: |
14/305,159 |
Filed: |
June 16, 2014 |
Prior Publication Data
|
|
|
|
Document
Identifier |
Publication Date |
|
US 20150296382 A1 |
Oct 15, 2015 |
|
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
13462302 |
May 2, 2012 |
8767556 |
|
|
|
11839496 |
May 22, 2012 |
8184653 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04W
72/0453 (20130101); H04W 16/14 (20130101); H04W
72/08 (20130101); H04W 88/08 (20130101) |
Current International
Class: |
H04W
4/00 (20180101); H04W 16/14 (20090101); H04W
72/04 (20090101); H04W 72/08 (20090101); H04W
88/08 (20090101) |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
1220499 |
|
Jul 2002 |
|
EP |
|
1571861 |
|
Sep 2005 |
|
EP |
|
2260879 |
|
Apr 1993 |
|
GB |
|
2004/054280 |
|
Jun 2004 |
|
WO |
|
2006/101489 |
|
Sep 2006 |
|
WO |
|
2007/034461 |
|
Mar 2007 |
|
WO |
|
2007/058490 |
|
May 2007 |
|
WO |
|
2007/094604 |
|
Aug 2007 |
|
WO |
|
2007/096819 |
|
Aug 2007 |
|
WO |
|
2007/108963 |
|
Sep 2007 |
|
WO |
|
2007/108966 |
|
Sep 2007 |
|
WO |
|
2007/109169 |
|
Sep 2007 |
|
WO |
|
2007/109170 |
|
Sep 2007 |
|
WO |
|
Other References
Ackland,"High Performance Cognitive Radio Platform with Integrated
Physical and Network Layer Capabilities", Network Centric Cognitive
Radio, 2005. cited by applicant .
Cabric et al.,"Implementation issues in spectrum sensing for
cognitive radios", Signals Systems and Computers, 2004. Conference
record of the 38th Asilomar Conference on Pacific Grove, CA, USA,
Nov. 7-10, 2004, NJ, USA, vol. 1, pp. 772-776, sections I-IV, Nov.
7, 2004. cited by applicant .
Ditri,"Dynamic spectrum access moves to the forefront", 2008. cited
by applicant .
EPO,"Supplementary European Search Report", for European
Application No. 01 94 5944, dated Apr. 24, 2009. cited by applicant
.
Erpek,"Location-based Propagation Modeling for Opportunistic
Spectrum Access in Wireless Networks", 2007. cited by applicant
.
European Patent Office,"European Examination Report", in
Application No. PCT/US2007022356. cited by applicant .
Falconer et al.,"Frequency Domain Equalization for Single-Carrier
Broadband Wireless Systems", IEEE Communications Magazine, Apr.
2002. cited by applicant .
Han et al.,"Spectral correlation based on signal detection method
for spectrum sensing in IEEE 802.22 WRAN systems", Advanced
Communication Technology, 2006. ICACT 2006. The 8th International
Conference, vol. 3, Feb. 20-22, 2006, NJ, USA, pp. 1765-1770. cited
by applicant .
Leu,"Ultra sensitive TV detector measurements", New Frontiers in
Dynamic Spectrum Access Networks, 2005. cited by applicant .
Liu et al.,"Project: IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs)", pp. 1-25, May 10, 2006. cited by
applicant .
Mahbubani et al.,"Dynamic channel allocation in wireless ad-hoc
networks", pp. 1-12. cited by applicant .
Marshall et al.,"XG Dynamic Spectrum Experiments, Findings and
Plans Panel", DoD Spectrum Summit, 2006. cited by applicant .
McHenry,"Adaptive Spectrum Technology: Findings From the DARPA XG
Project", 2007. cited by applicant .
McHenry,"Creation of a Spectrum Sharing Innovation Test-Bed and the
President's Spectrum Policy Initiative Spectrum Sharing Innovation
Test-Bed", 2006. cited by applicant .
McHenry,"Dynamic Spectrum Sharing Presentation", 2005. cited by
applicant .
McHenry,"The probe spectrum access method", New Frontiers in
Dynamic Spectrum Access Networks. DySPAN 2005. 2005 First IEEE
International Symposium on, 2005, pp. 346-351. cited by applicant
.
McHenry,"XG DSA Radio System", New Frontiers in Dynamic Spectrum
Access Networks, 2008. cited by applicant .
McHenry,"XG dynamic spectrum access field test results [Topics in
Radio Communications]", Communications Magazine, IEEE, No. vol. 45,
Issue: 6., 2007. cited by applicant .
Perich,"Experimental Field Test Results on Feasibility of
Declarative Spectrum Management", 3rd IEEE International Symposium
on New Frontiers in Dynamic Spectrum Access Networks, 2008. cited
by applicant .
Perich,"Policy-Based Network Management for NeXt Generation
Spectrum Access Control", 2nd IEEE International Symposium on New
Frontiers in Dynamic Spectrum Access Networks, 2007. cited by
applicant .
Ramanathan et al.,"Next Generation (XG) Architecture and Protocol
Development (XAP)", 2005. cited by applicant .
Rohde et al.,"RF/Microwave Circuit Design for Wireless
Applications", published by Wiley-Interscience, Mar. 2000. cited by
applicant .
Seelig,"A Description of the Aug. 2006 XG Demonstrations at Fort
A.P. Hill", 2nd IEEE International Symposium on New Frontiers in
Dynamic Spectrum Access Networks, 2007. cited by applicant .
SSC,"Products", 2007. cited by applicant .
SSC,"Shared Spectrum Company Successfully Demonstrates neXt
Generation (XG) Wireless Communications System", 2006. cited by
applicant .
SSC,"Shared Spectrum Company to Demonstrate XG Radio Technology at
IEEE DYSPAN Conference", 2007. cited by applicant .
SSC,"Shared Spectrum Company to Introduce Dynamic Spectrum Access
Technology at WIMAX Conference", 2007. cited by applicant .
SSC,"Thales Communications and Shared Spectrum Company Team to Add
Dynamic Spectrum Access Technology to Military Radios", 2007. cited
by applicant .
Steadman,"Dynamic Spectrum Sharing Detectors", 2nd IEEE
International Symposium on New Frontiers in Dynamic Spectrum Access
Networks, 2007. cited by applicant .
Steenstrup,"Channel Selection among Frequency-Agile Nodes in
Multihop Wireless Networks", 2005. cited by applicant .
Tenhula,"Dynamic Spectrum Sharing Bid, Lease and MVNO/MVNE:
Spectrum Options for Operators", 2006. cited by applicant .
Tenhula,"Policy-Based Spectrum Access Control for Public Safety
Cognitive Radio Systems", 2008. cited by applicant .
Tenhula,"Secondary Markets and Spectrum Leasing", UTC Telecom 2006,
Tampa, FL, May 23, 2006. cited by applicant .
Tenhula,"Shared Spectrum Company Successfully Demonstrates Next
Generation (XG) Wireless System", 2006. cited by applicant .
Tenhula,"Update on XG and Follow-on Programs: Cognitive Radio for
Tactical and Public Safety Communications", 2008. cited by
applicant .
USPTO,"Office Action", Re.: U.S. Appl. No. 12/541,621. cited by
applicant .
USPTO,"Office Action", Re.: U.S. Appl. No. 12/541,624. cited by
applicant .
WIPO,"International Search Report", for Application No.
PCT/US07/21940, dated Feb. 14, 2008. cited by applicant .
WIPO,"International Search Report", for Application No.
PCT/US01/14853, dated Feb. 8, 2002. cited by applicant .
WIPO,"International Search Report", for Application No.
PCT/US07/11414, dated Mar. 18, 2008. cited by applicant .
WIPO,"International Search Report", for Application No.
PCT/US04/17883 filed Jun. 9, 2004, dated Mar. 25, 2005. cited by
applicant .
WIPO,"International Search Report", for Application No.
PCT/US07/22356 filed Oct. 19, 2007, dated Oct. 6, 2008. cited by
applicant .
WIPO,"International Search Report", for Application No.
PCT/US08/073194, dated Sep. 28, 2009. cited by applicant .
WIPO,"PCT Office Communication", for Application No.
PCT/US2008/073193, dated Jun. 2, 2009. cited by applicant .
XG VIP Demo,"Anticipated XG VIP Demo Invitees", 2006. cited by
applicant .
Zeng,"Maximum-Minimum Eigenvalue Detection for Cognitive Radio",
Personal, Indoor and Mobile Radio Communications, IEEE 18th
International Symposium on, 2007, pp. 1-5. cited by applicant .
Zhao,"Distributed coordination in dynamic spectrum allocation
networks", New Frontiers in Dynamic Spectrum Access Networks.
DySPAN 2005. First IEEE International Symposium on, 2005, pp.
259-268. cited by applicant .
Zheng,"Device-centric spectrum management", New Frontiers in
Dynamic Spectrum Access Networks. DySPAN 2005. 2005 First IEEE
International Symposium on, 2005, pp. 56-65. cited by applicant
.
Zhou et al.,"Detection timing and channel selection for periodic
spectrum sensing in cognitive radio", 2008 IEEE, p. 1-5. cited by
applicant.
|
Primary Examiner: Harper; Kevin C
Attorney, Agent or Firm: Morris & Kamlay LLP
Government Interests
GOVERNMENT INTERESTS
The work leading to this invention was funded in part by the
Defense Advanced Research Projects Agency (DARPA), grant number:
FA8750-05-C-0150. The U.S. Government may have certain rights in
this invention.
Parent Case Text
CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of U.S. application Ser. No.
13/462,302, filed May 2, 2012, which is a continuation of U.S.
application Ser. No. 11/839,496, filed Aug. 15, 2007, now U.S. Pat.
No. 8,184,653, the disclosure of each of which is incorporated by
reference in its entirety.
Claims
The invention claimed is:
1. A method of operation of a dynamic spectrum access (DSA) device,
said method comprising: while operating in a first mode, selecting
an initial startup operating channel frequency of the dynamic
spectrum access device; subsequent to selecting the initial startup
operating channel frequency, entering a channel maintenance mode in
which a plurality of communications are exchanged between the DSA
device and at least one remote DSA device, at least one of the
plurality of communications comprising an indication of the radio
frequency environment in the region of a device sending the
communication; subsequent to selecting the initial startup
operating channel frequency: detecting a non-cooperative radio
operating on the initial startup operating channel frequency; and
responsive to detecting the non-cooperative radio operating on the
initial startup operating frequency, entering a channel switching
mode in which a new operating channel frequency is selected for use
by the DSA device based at least in part upon the indication of the
radio frequency environment.
2. The method of claim 1, wherein the step of selecting the initial
startup operating channel frequency further comprises: selecting an
available channel from a candidate channel list provided by a
spectrum manager of the DSA device.
3. The method of claim 2, wherein the available channel has a
lowest frequency from among a plurality of channels in the
candidate channel list provided by the spectrum manager.
4. The method of claim 1, further comprising: sending a synchronize
request to a remote DSA device; receiving an acknowledgement from
the remote DSA device, the acknowledgement comprising an indication
of a preferred frequency; and selecting the preferred frequency as
the initial startup operating channel frequency.
5. The method of claim 1, further comprising: sending an advertise
request to a remote DSA device; receiving an advertise reply from
the remote DSA device, the advertise reply comprising an indication
of an available channel identified by the remote DSA device; and
selecting the new operating channel frequency based upon the
indication of the available channel identified by the remote DSA
device.
6. The method of claim 5, further comprising: prior to sending the
advertise request, receiving a reset packet from the remote DSA
device, the reset packet indicating the presence of a
non-cooperative radio.
7. The method of claim 5, further comprising: sending an indication
of the new operating channel frequency to the remote DSA
device.
8. The method of claim 1, further comprising: sending an indication
of the new operating channel frequency to a remote DSA device.
9. The method of claim 1, further comprising: detecting a
non-cooperative radio operating on the initial startup operating
channel frequency; and sending a reset packet to a remote DSA
device indicating the non-cooperative radio operating on the
initial startup operating channel frequency.
10. The method of claim 9, further comprising: receiving an
advertise request from the remote DSA device; and sending an
advertise reply to the remote DSA device, the advertise reply
comprising an indication of an available channel identified by the
DSA device.
11. The method of claim 1, further comprising: receiving an
advertise request from the remote DSA device; and sending an
advertise reply to the remote DSA device, the advertise reply
comprising an indication of an available channel identified by the
DSA device.
12. The method of claim 11, further comprising: receiving an
indication of the new operating channel frequency from the remote
DSA device.
13. The method of claim 1, further comprising, while operating in
the channel maintenance mode: maintaining a list of a plurality of
channels, each channel in the plurality of channels being
categorized as one of: not allowed based on a policy, not cleared,
cleared, primary, control, data, or in use.
14. A DSA system comprising: a first DSA device; and a second DSA
device; wherein the first DSA device is configured to operate in a
first mode, during which the device selects an initial startup
operating channel frequency, and subsequent to selecting the
initial startup operating channel frequency, enters a channel
maintenance mode in which a plurality of communications are
exchanged between the first DSA device and the second DSA device,
at least one of the plurality of communications comprising an
indication of the radio frequency environment in the region of a
device sending the communication, and subsequent to selecting the
initial startup operating channel frequency, the first DSA device
enters a channel switching mode in which a new operating channel
frequency is selected for use based at least in part upon the
indication of the radio frequency environment; and wherein the
first DSA device enters the channel switching mode in response to a
detection of a non-cooperative radio operating on the initial
startup operating channel frequency.
15. The system of claim 14, wherein the first DSA device is a base
station.
16. The system of claim 14, wherein the first DSA device is a
subscriber unit.
17. The system of claim 14, wherein the first DSA device comprises
a spectrum manager that provides a candidate channel list from
which the new operating channel frequency is selected.
18. The system of claim 14, wherein, while operating in the first
mode, the first DSA device is configured to send a synchronize
request to the second DSA device, to receive an acknowledgement
from the second DSA device comprising an indication of a preferred
frequency, and to select the preferred frequency as the initial
startup operating channel frequency.
19. The system of claim 14, wherein, while operating in the channel
maintenance mode, the first DSA device is configured to: send an
advertise request to the second device; receive an advertise reply
from the second DSA device, the advertise reply comprising an
indication of an available channel identified by the second DSA
device; and select the new operating channel frequency based upon
the indication of the available channel identified by the second
DSA device.
20. The system of claim 19, wherein the first DSA device is
configured to send, subsequent to selecting the new operating
channel frequency, an indication of the new operating channel
frequency to the second DSA device.
21. The system of claim 14, wherein the second DSA device is
configured to: detect a non-cooperative radio operating on the
initial startup operating channel frequency; and responsive to
detecting the non-cooperative radio operating on the initial
startup operating channel frequency, send a reset packet to the
first DSA device indicating the non-cooperative radio operating on
the initial startup operating channel frequency.
22. The system of claim 14, wherein the second DSA device is
configured to: receive an advertise request from the first DSA
device; and send an advertise reply to the first DSA device, the
advertise reply comprising an indication of an available channel
identified by the second DSA device.
23. The system of claim 14, wherein the first DSA device is further
configured to maintain, while operating in the channel maintenance
mode, a list of a plurality of channels, each channel in the
plurality of channels being categorized as one of: not allowed
based on a policy, not cleared, cleared, primary, control, data, or
in use.
24. The method of claim 1, wherein the initial startup operating
channel frequency is selected prior to environmental sensing
performed on the initial startup operating channel frequency.
25. The method of claim 1, wherein the initial startup operating
channel frequency is selected prior to the DSA device communicating
with the at least one remote DSA device.
26. The method of claim 1, wherein the initial startup operating
channel frequency is selected independently of the indication of
the radio frequency environment.
27. The system of claim 14, wherein the DSA device is configured to
select the initial startup operating channel frequency prior to
performing environmental sensing on the initial startup operating
channel frequency.
28. The system of claim 14, wherein the DSA device is configured to
select the initial startup operating channel frequency prior to the
DSA device communicating with the at least one remote DSA
device.
29. The system of claim 14, wherein the DSA device is configured to
select the initial startup operating channel frequency
independently of the indication of the radio frequency environment.
Description
TECHNICAL FIELD
The following is related to a radio frequency (RF) device, operable
in a network, that dynamically adapts to its environment to
establish and maintain communications with other radios in the
network.
BACKGROUND
Cellular phones, personal digital assistants, walkie-talkies,
garage door openers, computers, routers and other communication
devices all incorporate radio technology to establish and maintain
communications over the air. Some RF devices, such as cordless
telephones, may automatically search for a channel to establish
communications and then release the channel when the radio is
finished. These radios may operate according to rules, parameters
and limitations imposed upon them by government regulation, an
owner or operator, a network, radio frequency requirements or
limitations of the physical environment. Most of these radios,
however, are unable to automatically adapt to significant or
challenging changes within the network or environment.
Some of these devices operate within a network, which may be
interconnected to other networks such as a public switched
telephone network or the Internet. A radio may be part of a network
over which it sends and receives information to other radios or
devices. A networked radio device typically does not possess the
capability of adapting to its operating environment without manual
intervention by a user (e.g., by a user manually tuning it to
another frequency or channel that has improved reception) or
without receiving rudimentary signaling information and
instructions from its network.
Networked radios designed to operate within one particular band or
sets of particular channels cannot operate outside of the
designated band or channels without appropriate authorization from
regulatory authorities or spectrum owners. For example, a radio may
search a specified band to find an open channel for communications
with the network. The radio will sequentially or randomly step or
hop through the band until an open channel is found or an
indication is given (e.g., through a control signal) that the
network is otherwise busy (e.g., no channels are available). Such a
radio, however, does not determine a new band or frequency range
from which to search for channels if a channel is not found. The
radio either works within its prescribed frequency band according
to its fixed characteristics (such as transmit power, bandwidth,
and modulation scheme) or it does not work at all.
If a typical radio confronts harmful interference, then its
communications signals will not be transmitted or received. The
radio also might receive a command from a base station to shut down
for any number of reasons. For example, under U.S. government
regulations, radios operating on certain frequencies in the 5 GHz
band must cease transmissions on that channel within a specified
time from the detection of radar signals, which have priority over
radio transmissions. A typical radio, however, is not able to
adjust, or is not agile in the sense that it can determine on its
own how to overcome interference problems. Further, if the radio
encounters different parameters or a change within its environment
that demands different parameters, then the radio were unable to
determine the parameters impacted or what behavioral modifications
should be made.
For example, public safety radios used by firefighters often have
problems working in the basements of buildings on a frequency
assigned to the radio. If the radio is able to dynamically sense
its environment and adjust its frequency, modulation, power and
network parameters, then the radio would be able to maintain
connectivity even under challenging conditions. Radios that do not
have a dynamic capability to adapt to the environmental and user
changes result in a loss of service. Moreover, if regulatory
parameters change, then the radios become incapable of being
re-programmed to support new rule-sets without costly refurbishing
at a facility or location away from the users.
Some radios, known as software-defined radios, can be reconfigured
to adapt to a changing environment. These radios, however, are not
able to dynamically adjust their operating behavior outside of a
predetermined, fixed set of parameters without uploading new
software to the radio or modifying its hardware. Furthermore, these
radios generally are not able to achieve performance objectives
aside from normal communications, such as avoiding interference or
conversely, maintaining communications even at the expense of
causing interference to radios outside the network or with lower
priority.
Other radios use simple spectrum access techniques generally to
operate within a single frequency band and strive to achieve basic
communications within narrow slices of unused spectrum. These
radios/methods, however, are not suitable for operating across a
broad cross section of frequency bands.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A illustrates the primary software modules and hardware
components of a cognitive radio.
FIG. 1B illustrates the primary components of a cognitive radio in
further detail.
FIG. 2 illustrates the rendezvous process for a base station
node.
FIG. 3 illustrates the rendezvous process for a subscriber
node.
FIG. 4 illustrates a message sequence for a base station in startup
mode.
FIG. 5 illustrates a message sequence for a subscriber unit in
startup mode.
FIG. 6 illustrates a message sequence in channel maintenance
mode.
FIG. 7 illustrates a message sequence for a subscriber unit in
channel switching mode.
FIG. 8 illustrates a message sequence for a base station in channel
switching mode.
FIG. 9 illustrates an example policy file.
FIG. 10 illustrates and example hardware configuration file.
The headings provided herein are for convenience only and do not
necessarily affect the scope or meaning of the claimed
invention.
DETAILED DESCRIPTION
In a broad sense, systems and methods for configuring a radio are
disclosed in detail below. The systems and methods described herein
can efficiently detect environmental conditions and configure the
radio in response.
System Functional Overview
The system and methods disclosed herein can operate according to
dynamic spectrum access principles. A networked radio node can
dynamically adapt to its channel and/or RF environment to maintain
reliable communications with other network radios, and can do so
without interference to non-network (i.e., non-cooperative) radios.
Furthermore, a radio node can operate within certain policy
constraints, which may vary depending upon geographic location,
time of day, regulatory requirements and other situational
factors.
In some embodiments, a radio node can operate over a very wide
bandwidth or in multiple frequency bands, by rapidly detecting
interference, adjusting its operating frequency, power, occupied
bandwidth or other parameters when it does so. The software
executing on the radio can use a detector to sense its channel
and/or RF environment by periodically or continually scanning some
or all of the spectrum for channels that are either clear for use,
off-limits due to interference or regulatory restrictions, or have
other radio signals operating on them. With this information, the
radio software can maintain a list of candidate channels that it
may use to communicate with other radio nodes.
Radio nodes within a certain operating region may sense different
RF characteristics of their channel and/or RF environment. Based on
this sensed information, a negotiation ("rendezvous") is performed
among the nodes in order to select a common operating channel. An
operating channel selected can be one that has improved
performance. When non-cooperative interference (e.g., interference
from a RF source outside of the network) appears within a network
or a subnetwork of radio nodes, a new rendezvous operation may be
performed resulting in a new operating channel for all or most
radio nodes. Detection of non-cooperative interference by one radio
node in a network does not require that a new operating frequency
will be used by its entire network of nodes; rather the objective
is to maintain communication for the majority of nodes. For
example, if only one or a few out of many radio nodes detect
interference, those nodes may cease communication while other nodes
(which remain out of range of interference) can continue operating.
In some embodiments, radio nodes can be configured to not interfere
with other non-cooperative nodes and can maintain reliable
communications subject to the non-interference and policy
constraints.
The principal software modules, hardware components and application
programmer interfaces (APis) of one example embodiment are
illustrated in FIG. 1A. These software modules include spectrum
manager 105, rendezvous 110, policy manager 115, and database
manager 120. Rendezvous 110 can coordinate with other network radio
nodes while complying with non-interference requirements. Policy
manager 115 can inform spectrum manager 105 of any policy
constraints. Detector interface API 130 provides detector 135 scan
information to spectrum manager 105, and database manager 120 can
provide persistent storage for detector results and other
information.
Systems and methods for performing channel and/or RF environment
detection are further described in co-pending U.S. patent
application Ser. No. 11/839,503, filed Aug. 15, 2007, titled
"METHODS FOR DETECTING AND CLASSIFYING SIGNALS TRANSMITTED OVER A
RADIO FREQUENCY SPECTRUM," now U.S. Pat. No. 8,055,204, the
contents of which are hereby incorporated by reference in their
entirety.
The principal APIs include the radio interface API 125 and the
detector interface API 130. In some embodiments, the radio
interface API 125 is used by a radio hardware manufacturer for
integrating the radio software modules and the radio hardware, such
as a modem 150. Radio interface API 125 can provide interfaces for
configuration, data communication, and status. In some embodiments,
the detector interface API 130 can also be used by a radio
manufacturer for integrating a detector 135. Detector interface API
130 can be used to provide interfaces for controlling signal
detection. As illustrated in FIG. 1A, multiple software
configuration interfaces can be included, such as policy management
interface 140 and configuration interface 145. Because the radio
software architecture is modular, a third-party can utilize other
proprietary or standardized modules or hardware.
The functionality of the principal modules of the radio is
described in more detail below and further illustrated in FIG. 1B.
While the description herein is provided with reference to certain
software and hardware embodiment, the functions described can be
performed by any combination of hardware, software, or firmware
operating alone or in combination.
Spectrum Manager
Referring now to both FIGS. 1A and 1B, spectrum manager 105 can use
information from the detector interface API 130 as well as the
policy manager 115 to manage frequency spectrum usage to maintain
reliable communications while avoiding interference and complying
with any other policy constraints that may be imposed. The spectrum
manager 105, through scheduler 160, can control the detector 135
and modem 150 to ensure conformance with radio policies and to
control detection timing. For example, spectrum manager 105 can
also maintain information that rendezvous 110 can use to negotiate
an operating frequency with other networked radios. Spectrum
manager 105 can maintain list of candidate channels that rendezvous
110 may use to negotiate an operating frequency with other network
radios. Spectrum manager 105 can use scan information from detector
interface API 130 as well as policy information to maintain the
candidate channel list. Spectrum manager 105 can also maintain or
access channel information as seen by neighboring network radio
nodes.
Rendezvous
The rendezvous subsystem 110 establishes a control channel over
which an operating frequency is determined for a particular network
of radio nodes. Rendezvous behavior can depend on the type of radio
node. In some embodiments, two radio node types are supported: base
station (BS) nodes and subscriber (SU) nodes.
FIG. 2 illustrates an example rendezvous process for a BS node. In
step 201, a free channel is selected. In step 205, a keep alive
packet is transmitted. In step 210, periodic keep alive packets and
advertise request packets are transmitted. In step 215, if a reply
to the advertise request packet is received, update can be made to
neighborhood control channel information in step 220.
If a non-cooperative radio is detected or a reset is received in
step 225, an advertise request packet can be transmitted in step
230. After a reply to the advertise request packet is received in
step 235, a new channel can be determined in step 240. If a
decision is made to switch to the new channel in step 245, then a
channel switch is transmitted in step 250. After waiting for a
flush, the channel can be changed in step 255 and the radio can
resume sending periodic keep alive packets and advertise request
packets in step 210. If a decision is made not to switch to the new
channel in step 245, no switch will be made and the radio can
resume sending periodic keep alive packets and advertise request
packets in step 210.
FIG. 3 illustrates an example rendezvous process for an SU node. In
step 301, a base station ID is acquired from a network ID
configuration file. A synchronize packet can be transmitted in step
305. In step 310, it is determined whether an acknowledgement has
been received. If no acknowledgement has been received, the base
station will return to step 301 acquire a station ID from a network
ID configuration file. If an acknowledgement is received in step
310, a periodic keep alive packet can be transmitted in step 315.
If an advertise request packet is received in step 320, an
advertise reply can be transmitted in step 325 and the base station
will return to step 315 and send periodic keep alive packets. If a
non-cooperative radio is detected in step 330, a reset will be
transmitted in step 335. If an advertise request packet is
subsequently received in step 340, an advertise reply will be sent
in step 345. If a channel switch request is then received in step
350, the base station will return to step 315 and send periodic
keep alive packets.
Considered in further detail, rendezvous module 110 can operate in
at least three modes: (a) startup, (b) channel maintenance, and (c)
channel switching. In some embodiments, channel switching can be
triggered by the detection of non-cooperative interference. These
modes are discussed in more detail below.
Startup
Upon cold start, the process for determining an operating channel
frequency is begun. The process can vary depending upon the type of
radio node.
For BS nodes in startup mode, a free channel is selected from a
candidate channel list. (See step 201 in FIG. 2.) In some
embodiments, the candidate channel list is provided by the spectrum
manager. The selection from the candidate channel list can be
performed such that the channel with a low or the lowest frequency
(in Hz) is chosen to optimize or otherwise improve RF propagation.
(See step 401 in FIG. 4.) The radio (through the radio interface
module) is then commanded to operate on the selected frequency, and
a keep alive packet is then transmitted. (See step 205 in FIG. 2
and step 402 in FIG. 4) As illustrated in the message sequence
chart of FIG. 4, the base station can identify a suggested
transmission channel 401 and transmit a keep alive packet to a
subscriber unit in step 402. After transmission of the keep alive
packet, the base station radio can transition to a steady state in
step 405.
As non-limiting examples, the keep alive packet transmitted by the
base station can include channel information, such as:
a) a preferred receive frequency on which other nodes can operate.
In some embodiments, the frequency is the same frequency selected
by the BS on which the keep alive is sent;
b) a number of other network nodes on a channel;
c) a number of candidate channels that are cleared for use. In some
embodiments, the number is limited to 40 channels; and
d) an actual list of candidate channels that are cleared for use
(as determined by the BS).
The keep alive packet can also carry the geo-location of the BS
radio node. In some embodiments, the geo-location can be
latitude/longitude data. After the keep alive is transmitted, the
BS node transitions into channel maintenance mode, which is
described in more detail below.
For SU nodes in startup mode, a synchronize packet (SYN) is first
sent to the BS radio node. (See step 305 in FIG. 3.) In some
embodiments, the SU node acquires the BS node identifier and the BS
preferred operating frequency from a file or database. The SYN
packet can contain some or all of the types of channel information
discussed above with regard to the keep alive packet. After sending
the SYN packet, an SU node waits for an acknowledgement (ACK) from
the BS node. (See step 310 in FIG. 3.) The ACK packet can contain a
preferred frequency and other channel information or parameters
upon which the SU should operate. After receiving and processing
the ACK packet, an SU node transitions to the channel maintenance
mode. (See step 315 in FIG. 3.)
As illustrated in the message sequence chart of FIG. 5, the
subscriber unit can obtain a base station node ID based on a
network ID supplied by a database in step 501. A SYN packet can be
transmitted to one or more base stations in step 505. After
receiving an acknowledgment from the base station in step 510, the
subscriber unit can enter a steady state in step 515.
Channel Maintenance
A series of packets can be exchanged in the process of channel
maintenance. FIG. 6 illustrates a message sequence chart
summarizing channel maintenance behavior.
As illustrated in FIG. 6, a SU can send a keep alive packet in step
601. A BS node in channel maintenance mode can periodically send a
keep alive packet 605 and send an advertise request packet (ARP)
610. After receipt of advertise reply 620 by the base station, the
process can repeat in steps 630-660. In some embodiments, the
periodic time interval, PingTimeoutMsec (670) can be determined by
policy manager 115. The time interval could be set for any value,
and in some embodiments, can be set to one second. These packets
transmitted by the base station can be used to inform the
subscriber units about the channel and/or RF environment as
detected by the base station. As non-limiting examples, the channel
and/or RF environment data can include preferred receive frequency,
known network channels, and channel list. This information can be
stored in a subscriber unit's neighborhood data structure, as
discussed above.
An SU node in channel maintenance mode will periodically send a
keep alive packet to its associated BS, as illustrated by steps 601
and 630 in FIG. 6. The time interval for sending the packet can be
determined by the policy maker and, in some embodiments, can be set
to one second. In addition, an SU can respond with an advertise
reply packet each time it receives an advertise request packet from
the BS. (See steps 620 and 660 in FIG. 6.) These packets can be
used to inform the BS of the channel and/or RF environment as
detected by the neighboring subscriber units. As non-limiting
examples, the channel and/or RF environment can include preferred
receive frequency, known network channels, and candidate channel
list. This information can be stored the BS's neighborhood data
structure, as discussed above and can be used during channel
switching.
Channel Switching
At any time during channel maintenance mode, a radio node may
detect a problem with the current operating channel via the
spectrum manager subsystem. Some possible reasons for a problem
with the current channel can include lost neighbors, an empty
channel, and detection of a non-cooperative radio. Detection of a
problem can cause the node to transition into channel switching
mode.
Detecting a non-cooperative radio designates the current operating
channel as a "primary channel." For SU nodes, the lost neighbors
and empty channel cases can result in the node behaving as if it
were at the beginning of the startup mode. In this mode, a BS node
will find a new channel from its candidate list and transmit a keep
alive packet. An SU node will send a SYN packet to a preconfigured
BS ID on a preconfigured channel, as described above. In the case
of a node detecting a non-cooperative radio, the behavior is
different for each type of radio node.
The channel switching protocol for a base station is illustrated in
FIG. 7. In step 705, a BS node will transmit an advertise request
upon detecting a non-cooperative radio. The BS will then wait for
an advertise reply from one or more of the SUs. In some
embodiments, the BS can be configured to wait for 200 msec for the
SUs to respond. A variable such as MAX_TIME_TO_WAIT_FOR_RESPOND can
be used for this purpose. The advertise replies (step 710) received
within this time frame provide the BS with information concerning
the available channels identified by the responding SU. The BS can
then select a new channel frequency to which to switch. In some
embodiments, the selection can be based on the available channel
that is most common to most or all of the SUs. The BS then
transmits a channel switch request packet to SUs in step 715,
notifying them of the new operating frequency. In some embodiments,
the BS node can be configured to wait for 100 msec before
commanding its own radio to the new operating frequency (for both
transmit and receive). A variable such as
TIME_TO_WAIT_FOR_RF_TO_FLUSH can be used for this purpose. The BS
node will then transition back to the channel maintenance mode. An
SU node that receives the channel switch request can change its
operating channel frequency accordingly and then switch itself back
to channel maintenance mode.
A channel switching protocol for a base station is illustrated in
FIG. 8. An SU node can send a reset packet to the BS upon detecting
a non-cooperative radio. The BS will determine if a better channel
is available, taking into account some or all known SUs. In some
embodiments, the BS will check for the most common channel among
all SUs. If this check results in the currently operating channel,
then the BS takes no action and lets the SU drop off. However, if
the common channel check results in a new channel frequency, the BS
will start the channel switch process as described above, as if the
BS had itself detected a non-cooperative node. In this case, the BS
sends an advertise request (step 801), waits for and then processes
any advertise replies (805), and then determines a new most common
channel. By this procedure, the BS may be provided with the most
recent information before selecting, and switching to, a new
channel. After determining a new channel, the BS then sends a
channel switch request packet (step 810) before switching its own
radio to the new channel and transitioning back to channel
maintenance mode. The SU nodes that receive the channel switch
request change their operating channel frequency accordingly and
then operate in channel maintenance mode.
Spectrum Manager
The spectrum manager 105 can be configured to maintain the state of
multiple logical channels and establish the basis for the candidate
channel list that rendezvous 110 uses and detecting when
non-cooperative interference occurs on a channel. In some
embodiments, the spectrum manager can operate according to one or
more policies set by the policy manager. In such embodiments, the
policy manager can provide multiple operating parameters as well as
the list of allowable channels governed by the policy. Channels
that are not available per the policy can be automatically marked
as "Not Allowed."
The spectrum manager analyzes the output of the detector subsystem
and characterizes allowable channels according to their RF
signatures. Channels can be periodically analyzed, and if an
appropriate signature is found, then the channel can be marked as a
control channel. Similarly, if a non-cooperative transmitter is
detected, then the channel can be marked as a primary channel, the
rendezvous subsystem can be immediately notified, and a channel
switch potentially triggered. Channels that have neither network
nor non-cooperative signals are marked as cleared. Furthermore, a
channel state can be marked as cleared if the channel had
previously been marked as either network or non-cooperative and a
certain amount of time has elapsed without another detection of
network or non-cooperative signals. In some embodiments, channels
for which there is not enough data from the detector shall be
marked as non-cleared.
The state of multiple channels can be maintained in real-time or
near real-time, as the spectrum manager periodically analyzes and
updates channel states. In some embodiments, the analysis and
update can be performed every 100 milliseconds as well as whenever
the detector completes a scan. The channels marked as network and
cleared can be included in the list of candidate channels that is
utilized by rendezvous. Network signals may be relevant to SUs,
while cleared channels may be relevant to BSs.
Note that the designations of a logical channel are not limited to
designations as either network or primary (i.e., non-cooperative).
Additional designations can include: cooperative signal present
only, cooperative signal and weak uncooperative detected,
cooperative signal and strong uncooperative detected, weak
uncooperative signal detected, strong uncooperative signal
detected, network signal present with weak uncooperative signal,
network signal present with strong uncooperative signal, network
signal present with cooperative and weak uncooperative signals,
network signal present with cooperative and strong uncooperative
signals, network signal present over 80% of snapshot, and strong
noise present.
The spectrum manager module can be implemented by a spectrum exec
module. The spectrum exec module is illustrated in FIG. 1B as a
unit of spectrum manager 105. The spectrum exec module can operate
according to certain parameters set by the policy manager. These
parameters can include channel size (e.g., 2 MHz, comprised of 1.75
MHz signal bandwidth plus a 0.25 MHz guard band), maximum number of
channels, spectrum low, spectrum high, scan timeout (relevant to
time to live), time to live (time period to keep a channel marked
as primary after no more detections), network time to live (time
period to keep a channel marked as network after no more
detections), policy start frequency, policy stop frequency,
predetermined detection threshold, detect frequency low (in some
embodiments, the same as spectrum low frequency), and detect
frequency high (in some embodiments, the same as spectrum high
frequency).
Additional parameters can include the bin bandwidth, which, in some
embodiments, can be set to be 25 kHz. The detector outputs the RF
energy contained within each bin, and spectrum exec determines the
state of channels by analyzing bins within the channel.
As described above, the spectrum exec can maintain the state of a
channel, based on information from both the policy manager and the
detector. The primary outputs of spectrum exec can include the
candidate channel list that is used by rendezvous and a trigger
that is sent to rendezvous upon detecting non-cooperative
interference.
The spectrum exec can define multiple channel states. As
non-limiting examples, a channel may be defined to have one or more
of the following states:
a) Not allowed: This may be set by the policy maker.
b) Not cleared: In some embodiments, can be set if channel
frequency is outside bounds of detect frequency range. In other
embodiments, can be set when not enough data has been collected to
determine a valid state of the channel.
c) Cleared: Indicates that neither network nor non-cooperative
signals were recently detected on the channel.
d) Primary: A non-cooperative signal has been detected.
e) Control: Denotes a live network channel; multiple control
channels may be detected.
f) Data: In some embodiments, may indicate a channel is being used
for data transfer.
g) In use: In some embodiments, may indicate a channel is a control
channel and a data channel.
Spectrum exec can be triggered by any one of multiple events. For
example, spectrum exec can be triggered by a periodic timer (e.g.,
set for 100 msec) and one generated by a wide-band FFT detector
(after a scan has been performed and via a callback function). In
some embodiments, a proprietary detector can be used.
When triggered by the detector, the spectrum exec can execute two
primary steps to update the channel state for some or all of the
channels. First, a look-through process (described in more detail
below) divides a logical channel into bins and characterizes a
channel based on the RF energy within the bins as measured by the
detector. Second, a channel update process updates the channel
state by analyzing both the output of the look-through process and
timing information (the current time and the elapsed time since the
latest network or non-cooperative signal detection).
The look-through process considers the RF energy within the bin for
some or all of the channels. For those channels, look-through
counts the number of bins where the detected network power level is
greater than a predetermined threshold parameter (in some
embodiments, specified in dbm). When the number of bins is greater
than a certain percentage (in some embodiments, 20%), the same
number of bins of an abstract representation of the channel are
marked as network and the abstract representation is time stamped
with the current time.
If the channel does not qualify as a network channel, then the
process is repeated with a lower threshold (predetermined threshold
minus threshold variation) under certain circumstances (e.g., when
the new threshold is above a certain estimated noise level). If the
channel still does not meet the criteria (e.g., more than 20% of
bins above the lower threshold) but does have at least one bin
above the original threshold, then the same number of bins of the
abstract representation of the channel are marked as primary and
the abstract representation is time stamped with the current
time.
At the conclusion of the look-through process, the channel update
process can be invoked. The channel update process analyzes the
abstract representation of logical channels constructed by the
look-through process. For some or all of the logical channels
between spectrum low and spectrum high (in some embodiments, these
are the same as the scan bandwidth), the state of the channel is
updated. For updated channels, its state is marked as not cleared
when the channel frequency is either below the detect low frequency
or above the detect high frequency parameters.
If not marked as not cleared, the bins for the abstract
representation (as defined by the look-through process) of each
channel are processed. If any bin within a channel has been marked
as primary and has not expired (i.e., the time since the last
non-cooperative detection is less than the time to live parameter
value), then the channel state is marked as primary. Furthermore,
when a logical channel is newly marked as primary (i.e., a
non-cooperative signal is first detected), then rendezvous can be
notified.
If no bins are marked as primary, then the abstract representation
is checked for network designation. If a sufficient percentage (the
same percentage used by the look-through process, for example 20%)
of bins are marked as network and this designation has not expired
(i.e., the time since the last network detection is less than the
network time to live parameter value), then the channel state is
marked as control.
If the checks for not cleared, primary, and control fail, then the
channel state is set to cleared, concluding the channel update
process. The cleared state corresponds to the case when neither a
network signature nor a primary detection has occurred on a valid
channel within the last time to live timeframe.
When spectrum exec is triggered by a periodic timer, the channel
update process (described above) is executed. The periodic update
to the channel states serves as a collector, so that when the
detector is off, the state of the channels is validated by
designating a channel state as cleared when the time to the last
detection has exceeded the corresponding time to live limit.
Detector Interface
The detector interface subsystem provides the interface wrapper
around the detector. The interface can support any type of
detector, including, for example, wide-band FFT detector,
narrow-band ultra-high sensitivity detector, group sensing detector
and other proprietary or non-proprietary devices.
To control operation, the detector interface generates a periodic
scan request to the detector. The detector interface controls the
operation of the detector through parameter settings that are
governed by the policy. The detector interface also processes scan
results sent from the detector and forwards them to the spectrum
manager module.
In some embodiments, the detector interface subsystem can be
implemented on wide-band FFT and/or other detector modules. The
detector interface can be implemented with two threads of control:
one for periodically sending scan requests to the detector (by a
scan scheduler), and the other for asynchronously reading and
processing the scan results from the detector.
The detector interface can use a parameter (e.g.,
Requested_Scans_Per_Second) set by policy manager. The detector
interface can also use certain parameters that characterize a
particular detector's capabilities, such as scan bin size (Hz),
maximum bins per scan, and scan Hz per msec.
The spectrum manager can control the initial operation of the
detector interface by enabling an autoscan function and by
specifying the high and low frequencies between which the detector
can operate. Once autoscan is enabled and the frequency range is
set, the detector interface periodically triggers the detector with
a scan request. The amount of time that elapses between each scan
request is set by policy manager. In some embodiments, the time can
be set to 100 milliseconds (e.g., Requested Scans Per
Second=10).
The frequency range over which a particular scan is performed may
be a sub-band within the entire frequency range of the radio node,
depending on the scan width that is set by the detector's hardware
profile. In some embodiments, multiple scan results may be
requested for each scan cycle (e.g., 100 msec).
For a given scan request, the detector interface subsystem can
specify the following control parameters: bin size (in some
embodiments, 25 kHz), high and low frequency for the scan, sample
size (number of FFT points), processing (window to use for power
spectral estimation; e.g., Rectwin, Hanning, Hamming, Bartlett,
Welch, and Blackman), attenuation (dB), averaging, and spur
reduction.
Before sending the scan request to the detector, the detector
subsystem can synchronize itself with the modem. In some
embodiments, the detector interface can disable the modem
transmitter; in other embodiments the detector interface can
synchronize to the modem power amplifier turning off. Once this
occurs, the scan request is sent to the detector. While a detection
is in process, access to the detector is restricted (e.g.,
additional scan requests are disallowed)
The detector interface can also read scan results from the detector
as a response to a scan request. Upon receiving a scan result
packet from the detector, the detector interface processes the
results. If multiple scans were requested and the limit has not
been reached at this point, a new scan request is sent to the
detector. In some embodiments, 5 scans per request are performed,
as per the hardware configuration file. Once the requested scans
are complete, the detector interface processes the results and
sends them to the spectrum manager subsystem. In some embodiments,
only the results of the last scan are sent. In the case of a
wide-band FFT detector, the modem transmitter may also be
re-enabled.
As non-limiting examples, the following results can be compiled
before sending to spectrum manager: detected power levels for some
or al of the bins, scan width (the sub-band that was scanned),
center frequency, scan completion time (approximate time when scan
results were received), max bins per scan (in some embodiments,
equal to 4096 per the detector hardware profile). The scan results
are then sent to the spectrum manager, triggering the look-through
and channel update processes.
To detect hardware faults (and other potential anomalies), the
detector interface also includes a watchdog function. The watchdog
runs periodically to determine whether a certain amount of time has
elapsed without hearing from the detector. In some embodiments, the
time is three seconds, and is based on a parameter in the hardware
configuration file. If this time period has elapsed, then the
detector interface pings the detector. If no response to this ping
(or scan requests) is heard within the same time period, then the
detector is logged as lost.
Policy Maker
In some embodiments, the policy manager can be used to load a
policy file. As non-limiting examples, parameters that are set in
the policy file can include: NodeId, MaxTxPower, MaxNodes,
NumPolicies, UpdateChannelTime, Requested ScansPerSec, ScanTimeout,
StrongDetectionThreshold, NodeTimeout,
MaxReadChannelsToCheckAtOnce, AllowRendezvousToForceChanSwitch,
AllowedFreqMin/Max, NodeType, and InitialNetworkId.
Additionally, frequency low, frequency high, and channel size
parameters can be loaded for further policy options. In some
embodiments, only a single policy is implemented. Spectrum Low (a
parameter used system wide) specifies the lowest end of the
frequency range for the radio node, and can be set to be the lowest
frequency among all of the Frequency Low values of the policies. In
some embodiments, 306 MHz can be specified as the Spectrum Low.
Spectrum High (a parameter used system wide) specifies the highest
end of the frequency range for the radio node, and can be set to be
the highest frequency among all of the Frequency High values of the
policies. In some embodiments, 407 MHz can be specified as the
Spectrum Low. Channel Size (a parameter used system wide) can be
set to be the narrowest frequency channel among all of the Channel
Size values of the policies. In some embodiments, 1.75 MHz can be
specified as the Channel Size.
Radio Interface
Upon power-up, the radio interface subsystem configures its own
transmit/receive buffers and UDP/IP sockets for communication with
the modem. It can set the transmit power based on the policy, and
initializes the modem hardware. After initialization, the radio
interface waits for packets inbound from the modem. When a packet
is received, it processes the packet by invoking the appropriate
subsystem (e.g., a process packet function in rendezvous). The
radio interface also provides the interface used by the rendezvous
module to set transmit and receive frequencies, and for
transmitting packets through the modem.
As non-limiting examples, two modem types can be implemented:
RadioUDP and RadioModem.
Database Manager Interface
The database manager interface (or spectrum database manager) can
be used to provide the interface to a database (e.g., SQLite) that
is used to store detector scan results. Upon power up, this module
sets up internal data structures (e.g., FIFOs and access pools) and
creates a database to store detector results. The database manager
provides an interface for reading from and writing to the detector
database. The write interface can be used by spectrum exec to store
results.
Configuration Files
One or more configuration files can be used by the system. In some
embodiments, one file can be used for policy configuration
(PolicyFile.ini) and the other for hardware configuration
(HwIniFile.ini).
An example policy file is illustrated in FIG. 9. In some
embodiments, additional parameters can be implemented such as:
NumPolicies, NodeType, InitialNetworkId, ScanHzPerScan and
ScanHzPerMsec.
CONCLUSION
Many specific details of certain embodiments of the invention are
set forth in the description and in FIGS. 1-10 to provide a
thorough understanding of these embodiments. A person skilled in
the art, however, will understand that the invention may be
practiced without several of these details or additional details
can be added to the invention. Well-known structures and functions
have not been shown or described in detail to avoid unnecessarily
obscuring the description of the embodiments of the invention. As
used herein, one or more components "coupled" to each other can be
coupled directly (i.e., no other components are between the coupled
components) or indirectly (i.e., one or more other components can
be placed between the coupled components).
Unless the context clearly requires otherwise, throughout the
description and the claims, the words "comprise," "comprising," and
the like are to be construed in an inclusive sense, as opposed to
an exclusive or exhaustive sense; that is to say, in the sense of
"including, but not limited to." Additionally, the words "herein,"
"above," "below," and words of similar import, when used in this
application, shall refer to this application as a whole and not to
any particular portions of this application. Where the context
permits, words in the above Detailed Description using the singular
or plural number may also include the plural or singular number
respectively. The word "or," in reference to a list of two or more
items, covers all of the following interpretations of the word: any
of the items in the list, all of the items in the list, and any
combination of the items in the list.
The above detailed description of embodiments of the invention is
not intended to be exhaustive or to limit the invention to the
precise form disclosed above. While specific embodiments of, and
examples for, the invention are described above for illustrative
purposes, various equivalent modifications are possible within the
scope of the invention, as those skilled in the relevant art will
recognize. For example, while processes or blocks are presented in
a given order, alternative embodiments may perform routines having
steps, or employ systems having blocks, in a different order, and
some processes or blocks may be deleted, moved, added, subdivided,
combined, and/or modified to provide alternative or
subcombinations. Each of these processes or blocks may be
implemented in a variety of different ways. Also, while processes
or blocks are at times shown as being performed in series, these
processes or blocks may instead be performed in parallel, or may be
performed at different times.
The teachings of the invention provided herein can be applied to
other systems, not necessarily the system described above. The
elements and acts of the various embodiments described above can be
combined or altered to provide further embodiments.
These and other changes can be made to the invention in light of
the above Detailed Description. While the above description
describes certain embodiments of the invention, and describes the
best mode contemplated, no matter how detailed the above appears in
text, the invention can be practiced in many ways. Details of the
system may vary considerably in its implementation details, while
still being encompassed by the invention disclosed herein.
The terminology used in the Detailed Description is intended to be
interpreted in its broadest reasonable manner, even though it is
being used in conjunction with a detailed description of certain
specific embodiments of the invention. Certain terms may even be
emphasized; however, any terminology intended to be interpreted in
any restricted manner will be overtly and specifically defined as
such in this Detailed Description section. In general, the terms
used in the following claims should not be construed to limit the
invention to the specific embodiments disclosed in the
specification, unless the above Detailed Description section
explicitly defines such terms. Accordingly, the actual scope of the
invention encompasses not only the disclosed embodiments, but also
all equivalent ways of practicing or implementing the invention
under the claims.
* * * * *