System and method for management of a shared frequency band

Management system and method for shared frequency band

This application claims priority for the following applications (all of each priority application is hereby incorporated for reference): United States Provisional Application 60/374,363 filed on April 22, 2002; United States filed on April 22, 2002 Provisional application 60/374,365; US provisional application 60/380,891 filed on May 16, 2002; US provisional application 60/380,890 filed on May 16, 2002; US provisional application 60/319,435 filed on July 30, 2002 ; US provisional application 60/319,542 filed on September 11, 2002; US provisional application 60/319,714 filed on November 20, 2002; US provisional application 60/453,385 filed on March 10, 2003; March 2003 U.S. Provisional Application 60/320,008 filed on the 14th; U.S. Application 10/246,363 filed on September 18, 2002; U.S. Application 10/246,364 filed on September 18, 2002; U.S. Application 10 filed on September 18, 2002 /246,365.

This application is a continuation of part of U.S. application 10/246,363 filed on September 18, 2002.

BACKGROUND OF THE INVENTION In the past few years, the explosive growth of wireless applications and devices has produced a large amount of public welfare benefits. Wireless networks and equipment have been deployed in millions of offices and homes, and a large number of public areas have recently been added. These wireless deployments are foreseen to continue at an exciting rate and provide increasing convenience and productivity.

This increase, which is occurring in unlicensed frequency bands, shows a downward trend. In the United States, the unlicensed frequency band established by the FCC consists of most of the spectrum at 2.4 GHz and at 5 GHz, and its use is free. The FCC currently imposes requirements on unlicensed frequency bands, such as limiting the transmission power spectral density and limiting antenna gain. What everyone realizes is that as unlicensed band devices become more popular and their density in specific areas increases, the "tragedy in the public domain" effect will often become obvious, and the entire wireless facility (and user satisfaction) Degree) will collapse. This phenomenon has been observed in environments with high-density wireless devices.

The type of signal protocol used by the device in the unlicensed frequency band is not designed to cooperate with other types of signals operating in the frequency band. For example, a frequency hopping signal (eg, a signal transmitted from a device using the BluetoothTM communication protocol or a signal transmitted from some cordless phones) can hop to a frequency channel of an IEEE 802.11 wireless local area network (WLAN), thereby causing interference with the operation of the WLAN. Thus, technology is needed to develop all the benefits of unlicensed frequency bands without degrading the level of service users expect.

Historically, the general approach for the wireless industry to solve the problem of "tragedy in the public domain" has been to simply move to another public domain with a higher frequency spectrum. However, this solution will not work for too long because of the lack of spectrum and the higher frequency bands with less attractive technical features (reduced signal propagation and inability to penetrate surfaces).

Enterprises that use unlicensed frequency bands concentrate on the deployment and integration of larger-scale wireless networks (such as WLAN) in wired networks. WLANs can complicate existing network management solutions because they introduce additional requirements for effective management of the radio frequency spectrum. Current WLAN systems and management technologies focus on management activities at the network level of the WLAN, and hardly provide the ability to manage frequency bands, in which multiple types of signals (such as communication protocols/network types, device types, etc.) are presented. A technique is needed to obtain and use the knowledge of what is happening in the shared radio frequency bands, such as unlicensed bands, so that devices can act intelligently with regard to their frequency usage, thereby maintaining the performance of the device and operating in the frequency band Network of devices.

Summary of the invention

Briefly, the present invention provides systems, methods, software and related subroutines for managing activities in a shared radio frequency band, where the radio frequency band consists of multiple disparate types of signals and various technologies in terms of frequency and time. Device sharing. An example of such a frequency band is an unlicensed frequency band. The radio frequency energy in the frequency band is captured at one or more locations in the area where activity in one or more devices and/or the frequency band is occurring. The signal appearing in the frequency band is detected by the sampling component or the entire frequency band at certain time intervals. The signal pulse energy in the frequency band is detected and used to classify the signal according to the signal type. Using knowledge of the types of signals that appear in the frequency band and other statistics related to spectrum activities (known as spectral information), actions can be taken in equipment or equipment networks to avoid interference with other signals, and to maximize the use of frequency bands with other signals at the same time. optimization. Spectral information can be used to suggest actions to device users or network administrators, or automatically invoke actions in devices or device networks to maintain desired performance.

Devices that use unlicensed or shared frequency bands can adopt the features and functions described herein to better promote frequency band sharing and coexistence among multiple devices using disparate technologies. Devices that have the ability to collect information and act on it or on information obtained by other devices are referred to herein as "cognitive radio devices." Any device operating in the shared frequency band can include cognitive radios of varying degrees to perceive their local radio environment and/or detect the presence (and application needs) of other devices that are accessing the same unlicensed frequency band. The ability to sense, detect, and classify other users sharing the frequency band near the device is very important to be able to determine how the device can use the spectrum most efficiently. The cognitive radio system is applied to each device and each device network.

Cognitive radio equipment enables stable and effective use of unlicensed frequency bands, and facilitates secondary access applications. Cognitive radio can perceive their radio environment, detect the presence of other wireless devices, classify these other devices, and then implement communication-specific policies. Cognitive radios can also be equipped with location-aware features to help them determine the way they can communicate most effectively, or, in the case of secondary access, whether they can definitely access a certain spectrum.

Cognitive radio benefits users of cognitive radio devices and other "dumb" device users working nearby. Through the spectrum recognition of their radio environment, cognitive radio devices can avoid interference from other devices and thus maintain a more reliable wireless connection than dumb devices, which cannot adapt to their behavior. Because cognitive radio devices can adapt to their environment to transmit on less crowded frequencies, they produce less radio interference than dumb devices. This leads to an improvement in the user experience of cognitive device and dumb device users.

As with licensed wireless applications, predictability of performance is very important for satisfactory unlicensed band wireless service transmission. The successful provision of cognitive spectrum management technology has the potential to help unlicensed frequency band applications evolve from the current convenient but usually secondary wireless situation to unlicensed frequency band connections, which are regarded as reliable, primary, and stable connections. .

Unlike wired and licensed frequency band wireless connections, in which access media is controlled and effectively managed, unlicensed frequency bands can be used by disparate wireless technologies. The results of a device operating in such an environment based on performance can be catastrophic. For example, and as mentioned above, two commercially successful unlicensed standards, IEEE802.11b and Bluetooth, behave "unintelligent" when operating in close proximity to each other.

Through the intelligent use of unlicensed frequency bands, the entire capacity can be increased and meet the needs of more users. The reuse of frequencies has dramatically increased capacity, where the same frequency band is used in multiple geographic areas. As demonstrated by the operators of currently licensed frequency bands, reducing the size of the "frequency unit" will allow for higher throughput at the expense of other equipment. The limitation of power levels in unlicensed frequency bands makes frequency reuse a substantial necessity in the provision of wireless services in an area spanning several hundred square meters. By adopting intelligent power control mechanisms, frequency reuse in unlicensed frequency bands can be further expanded.

For so-called personal area network (PAN) applications, where the range of the wireless connection is limited to a few meters, the interference level generated by such PAN devices is made very low, by controlling the output power to the lowest possible level required to maintain its wireless connection Level to achieve. For those devices that can sense that no other devices are competing for wireless media in their vicinity, they will transmit at the highest possible data rate and use the required spectrum without degrading the performance of other nearby devices. Based on detecting the presence of other devices accessing the spectrum, the device can then reduce its bandwidth usage to minimize interference with other devices. Such flexible and intelligent use of unlicensed frequency bands is an example of cognitive radio equipment.

The ability of a device to identify and react to the occupancy of its local RF environment through measurement and classification opens up opportunities to substantially increase wireless capacity, which enables short-range wireless devices to act as secondary access users while in unoccupied licensed Frequency band. Through spectrum management, this access can be provided without conflicting with the services provided on these licensed frequency bands.

The objectives and advantages of the present invention will become more apparent after referring to the following description with reference to the accompanying drawings.

Description of the drawings

Figure 1 is a block diagram of multiple devices that can operate in unlicensed or shared frequency bands at the same time.

Figures 2 and 3 show the spectral profiles of signal types that can appear in two exemplary radio frequency bands simultaneously.

Figure 4 is a diagram showing the general data flow of the spectrum management system.

Figure 5 is a general flow chart of the spectrum management process.

Figure 6 is a block diagram showing the various processes and basic architecture of the spectrum management system.

Fig. 7 is a block diagram of a real-time spectrum analysis element (hereinafter referred to as SAGE) used in a spectrum management system.

Figure 8 is a diagram showing how the output of SAGE can be used to classify signals detected in frequency bands.

Figure 9 is a general flow chart of the signal classification process used in the spectrum management system.

Figure 10 is an exemplary coverage map that can be generated by a spectrum management system.

Figure 11 is a block diagram of an exemplary communication device that can function in a spectrum management system.

Figure 12 is a block diagram of an exemplary spectrum sensor device that can function in a spectrum management system.

Figure 13 is a ladder diagram showing how the network spectrum interface called by the application programming interface is used by the application to start the spectrum analysis function.

Figures 14 and 15 are flowcharts of examples of how the information generated in the spectrum management system can be used.

Figures 16-21 are diagrams of exemplary display screens used to convey spectrum management-related information to users.

Figures 22-25 are diagrams of exemplary ways in which spectrum activity information can be displayed.

FIG. 26 is a flowchart of a process of using information related to spectrum management to notify a user about the performance of devices operating in a frequency band.

Fig. 27 is a simplified diagram of multiple scenarios of a scenario in an unlicensed frequency band that can be handled by the spectrum management process.

Figure 28 is a block diagram of a more detailed architecture of the spectrum management system.

Figure 29 is a block diagram of the hierarchical interaction between devices in the wireless local area network (WLAN) application of the spectrum management process.

Figures 30 and 31 are block diagrams of the Network Spectrum Interface (NSI) between the various process levels of the spectrum management architecture.

Fig. 32 is a flowchart of the interaction between resource managers in each software level of the spectrum management system.

Figures 33 and 34 are block diagrams of other hierarchical relationships between the processing levels of the spectrum management architecture.

Figure 35 is a detailed block diagram of the interaction between the intermediate levels in the spectrum management system architecture.

Figure 36 is a detailed block diagram of the interaction between higher levels in the spectrum management system architecture.

Figure 37-40 is a simplified diagram of several interactions of the engine NSI with equipment in a WLAN environment.

Figure 41 is a diagram of an exemplary spectrum utilization map (SUM) established based on spectrum analysis and other information obtained from equipment operating in a frequency band.

Detailed description of the drawings. The systems, methods, software, and other technologies described herein are designed to coordinate the use of shared frequency bands such as unlicensed frequency bands, where multiple types of signals appear (often simultaneously), and users of the frequency bands Interference between them may also occur. Many of the concepts described here can be applied to frequency bands, which do not have to be "unlicensed", such as when a licensed frequency band is used for secondary licensed or unlicensed purposes.

The term "network" is used in a variety of ways hereinafter. There may be one or more wireless networks, each of which includes multiple devices or nodes operating in a shared frequency band. An example of such a network is WLAN. There is also a network called piconet, which is formed by BluetoothTM capable devices. Many of the examples described here are done with respect to IEEE802.11 WLAN, mainly because WLAN has seen widespread use and is expected to continue. In addition, the term network refers to a wired network and refers to a collection of one or more wired and wireless networks. The spectrum management system, method, software, and device features described herein are not limited to any specific wireless network, and can also be used for any wireless network technology currently known or developed below for sharing frequency bands.

First, referring to FIG. 1, it shows an environment in which multiple devices transmit or transmit signals in a common frequency band in their working mode at certain points, and they may at least partially overlap in frequency and time. When these devices are close enough to each other, or when they transmit signals at a high enough power level, there will inevitably be interference between the signals of one or more devices. The dotted lines shown in Figure 1 are intended to indicate areas where activity from any device shown may affect other devices. Figure 1 shows a non-exhaustive exemplary selection of devices that can operate in unlicensed frequency bands, including cordless phones 1000, frequency hopping communication devices 1010, microwave ovens 1020, WLAN access points 1050(1) and their associated A wireless local area network (WLAN) composed of client stations (STA) 1030(1), 1030(2), ..., 1030(n), a baby monitoring device 1060, and any other existing or new wireless devices 1070. Multiple WLAN APs 1050(1) to 1050(n) can work in this area, each of which has one or more related client STAs 1030(1) to 1030(n). Alternatively, the area shown in Figure 1 may be one of a number of other similar areas in which activity is occurring in the frequency band. Depending on the desired coverage area, one or more APs can be assigned to corresponding areas in several areas, and each area may be shared with other users, such as those users shown in the single area in FIG. 1. One or more WLAN APs 1050(1) to 1050(n) can be connected to a wired network (such as an Ethernet network), and a server 1055 is also connected to the wired network. Depending on the type, the cordless phone 1000 can be an analog, digital, and frequency hopping device. The frequency hopping communication device 1010 may include devices that work according to the BluetoothTM wireless communication protocol, the HomeRFTM wireless communication protocol, and cordless phones. In addition, the radar device 1080 can operate in an unlicensed frequency band. Other devices that can work in the frequency band also include devices such as digital (and/or) video cameras, cable set-top boxes, and so on.

As will become more apparent in the following, the spectrum management method described herein can be implemented in any device or device network operating in the frequency band (such as those shown in Figure 1). The necessary hardware and/or software functions should be configured in the hardware/software platform of the device to enable the device to be used as a cognitive radio device and thus perform spectrum management steps: signal detection, accumulation/measurement, classification, and control/reporting. For example, cognitive radio devices that support WLAN applications can perform smarter spectrum access and waveform determination, and ultimately provide higher connection reliability, by cooperating with at least one of the following: its data rate, packet size, channel , Transmission power, etc., classifying the interference signal as a microwave oven, frequency hopping device or alternative to another WLAN.

Alternatively, or in addition, spectrum management can be implemented by arranging a plurality of spectrum sensitive elements 1200(1) to 1200(n) shown in FIG. 1 at various positions, where any one of a plurality of signal types is associated The activities appear in the frequency band to form an overlay network of sensitive components. The spectrum information collected by the spectrum sensitive element is fed back to one or several processing platforms such as the network management station 1090 or server 1055, the main processor of the AP, etc., where policy decisions are made and control can be generated. For example, there may be another server 1057 that executes the WLAN management application of APs 1050(1) to 1050(n). The server 1055 or the network management station 1090 may generate control or report to the server 1057 affecting changes in one or more APs.

The network management station 1090, the server 1055, and the server 1057 need not be physically located in the area, where other devices are working in the area. The network management station 1090 can be connected to the same wired network as the server 1055, and can be from one or more WLAN APs 1050(1) to 1050(n) and/or from one or more spectrum sensitive elements 1200(1) to 1200 (n) Receive spectrum activity information. For example, the network management station 1090 has a processor 1092, a memory 1094 that stores one or more software programs executed by the processor, and a display monitor 1096. The network management station 1090 may also execute one or more software programs for managing wired and wireless networks, such as a WLAN served by WLAN APs 1050(1) to 1050(n). The spectrum sensitive elements 1200(1) to 1200(n) can be connected to the AP, the server 1055 or the spectrum management station 1090 through a wired or wireless connection.

At present, in the United States, unlicensed frequency bands are in the Industrial, Technology, and Medical (ISM) and UNII frequency bands, and include unlicensed frequency bands at 2.4 GHz and unlicensed frequency bands at or near 5 GHz. These are just a few examples of existing unlicensed frequency bands. In other countries, other parts of the spectrum have been set aside for unlicensed use. By definition, an "unlicensed" frequency band usually means that no user has any rights over others when using the frequency band. No user has purchased the exclusive right to use the spectrum. There is a set of basic power and bandwidth conditions associated with unlicensed frequency bands, but any user working under these conditions can use it for free at any time. The result of the "unlicensed" nature of these frequency bands is that the devices operating in them will inevitably interfere with each other's operation. When interference occurs, the signal from one device to another device may be received improperly, causing the sending device to retransmit (and thus reducing throughput), or may completely destroy the communication connection between the two communication devices. In addition, because the frequency band is free to use, zero cost encourages more applications and users of unlicensed frequency bands, and as a result, it makes the frequency band more congested and more susceptible to interference. Therefore, it is necessary to manage the work of devices operating in unlicensed frequency bands to ensure effective and fair use by all users.

Figures 2 and 3 show some examples of spectrum usage in two unlicensed frequency bands in the United States. Figure 2 shows the spectrum profile of exemplary devices operating in the 2.4 GHz unlicensed frequency band, such as frequency hopping devices, cordless phones, IEEE 802.11b WLAN communication devices, baby monitoring devices, and microwave ovens. Frequency hopping equipment will occupy a predictable or random sub-band at any given time, and therefore, over time, can span the entire frequency band. Non-frequency hopping cordless phones can occupy one of several sub-bands at any given time. IEEE802.11b devices usually occupy one of the three RF channels in the 2.4GHz band at any given time, and baby monitors are similar. The microwave oven will emit short bursts of energy that can span most of the unlicensed channel. Other devices that can work in the 2.4GHz frequency band are IEEE802.11g WLAN devices.

Figure 3 shows a similar set of cases for the 5GHz unlicensed frequency band. In the United States, there are actually three unlicensed frequency bands at 5GHz. Two of them are adjacent, and the third is not adjacent to the other two (for simplicity, it is not considered in Figure 3). In the unlicensed frequency band of 5GHz, there may be IEEE802.11a WLAN equipment operating in 8 different sub-bands (channels), direct sequence spread spectrum (DSSS) cordless phones, and various radar equipment.

Managing unlicensed frequency bands in which multiple types of signals can appear at the same time includes minimizing interference and maximizing spectrum efficiency. Minimizing interference is expressed in terms of signal-to-noise ratio (SNR), bit error rate (BER), etc., and maximizing spectral efficiency is expressed as the data rate per bandwidth used per unit area (bps/Hz/m2) or expressed as "feeling The number of "satisfied" users, where satisfaction is based on meeting certain performance criteria, such as: data rate, latency, jitter, dropped sessions, and blocked sessions. The goal of spectrum management is to take evasive actions to avoid possible interference, detect and report interference when it occurs, and make intelligent decisions to mitigate interference when it is unavoidable. In addition, spectrum management is flexible to handle the needs of different end users and the emergence of new equipment and equipment types.

Figures 4 and 5 show general concepts associated with spectrum management of unlicensed frequency bands. Information about the activity in the frequency band, called spectrum activity information, will be obtained from any one or several devices working in the frequency band, which has a certain degree of capability described below in conjunction with FIGS. 7 and 8. This is called spectrum sampling in step 2000, and can include sampling radio frequency energy or scanning sub-bands (on-demand or periodically) in the entire frequency band in a period of time to determine spectrum-based and time-based activities in the frequency band. . It is possible for each step shown in Figure 5 to be performed in a radio device such as a cognitive radio device. Alternatively, or in addition, the spectrum activity information is collected at multiple devices (such as at multiple spectrum sensitive elements of the sensitive element overlay network) and the spectrum activity information is processed at the computing device to generate one or more for working in the frequency band. Reporting and/or control of individual devices or device networks (such as one or more APs). The spectrum information collected and used at the same device or collected from the sensitive element overlay network can be used to connect spectrum aware reports or control to general network management applications that manage the wired and wireless networks in the enterprise.

For example, as shown in Figure 4, the spectrum activity information is in one or more APs 1050(1) to 1050(n) and/or in one or more spectrum sensitive elements 1200(1) to 1200( n) or any other equipment equipped with certain capabilities described below. For example, three spectrum sensitive elements are illustrated in FIG. 4, which can be placed in a location or various locations of a building. Spectrum activity information can be generated in a device capable of receiving signals in a frequency band, or, in the device, the raw data output by a radio receiver (data converter connected to the output of the receiver) is connected to another one that does not have to be in the frequency band. Equipment that works or resides locally to those that work in the frequency band. The spectrum activity information may generally include information related to activities in the frequency band, and statistical information associated with wireless networks operating in the frequency band, such as IEEE802.11x WLAN statistical information, which can be obtained by APs or STAs operating in the WLAN.

Some cognitive radio devices can know only the environment/outside spectrum activity that affects them. Other more intelligent devices can know the spectrum activity of themselves and all the devices connected to them. For example, a STA may have its own cognitive radio capability, but the AP associated with it has each of its STA and its own intelligence. However, the AP can inform the STA about the spectrum situation at the AP or other STAs. For a higher level, a server that manages multiple APs will have intelligence for the entire multi-AP network. When spectrum activity information is sent "upstream" for further processing, it can be divided into necessary components or elements or compressed.

Spectrum activity information (or raw data used to generate it) is reported locally or remotely to other devices to display, analyze, and/or generate real-time alarm signals related to activities in the frequency band. In addition, spectrum activity information can be accumulated and saved for a short-term (a few seconds or minutes) or a long-term (a few minutes to a few hours) for subsequent analysis. For example, long-term preservation of spectrum activity information is useful for data mining and other non-real-time processing applications, which will be described below.

In addition, or independent of the reporting function, the spectrum activity information can be processed in the processor (local or remote from the source device of the actual spectrum activity information). The signal classification step 2010 includes processing the output of the spectrum sampling step to measure and classify the signal based on characteristics such as power, duration, bandwidth, frequency hopping characteristics. The output of the signal classification step 2010 is to classify the data of the detected signal/device. The classified output can be, for example, "cordless phone", "frequency hopping device", "frequency hopping cordless phone", "microwave oven", "802.11x WLAN device", and so on. The signal classification information generated by processing spectrum activity information can be reported to local or remote locations like spectrum activity information, and used to generate real-time alarm signals. For example, when an interference condition (the presence of another signal in a device in a frequency band or a frequency band in which a device network operates, a working adjacent channel, etc.) is detected, a real-time alarm signal may be generated to notify the network administrator of the condition. The real-time warning signal can take the form of picture display, audio, email message, radio paging message, etc. The warning signal may include suggestions to users or network administrators to make adjustments to the equipment and equipment network operating in the frequency band.

The policy enforcement step 2020 involves determining, if any, what to do with the information output by the signal classification step 2010. For example, the policy specifies what spectrum action or control should be taken in the communication device or device network based on the output of the signal classification step 2010. The output of the policy execution step 2020 may include suggested actions to network administrators, applications, or systems to remedy or adjust the situation. In addition, in processing spectrum activity information, controls may be generated to adjust one or more operating parameters of the equipment or equipment network operating in the frequency band. The spectrum action step 2030 generates specific controls to implement actions. Examples of control are: assigning devices to different sub-bands or channels in the frequency band (Dynamic Frequency Selection-DFS), network load balancing (based on channel frequency or time), adjusting transmission power (Transmission Power Control-TPC), Adjust the communication data rate, adjust the parameters of the transmitted data packets, perform interference mitigation or coexistence algorithms, perform spectrum etiquette procedures, perform spectrum priority schemes, or re-allocate STAs to APs in the WLAN. Examples of interference mitigation algorithms are disclosed in the pending U.S. Patent Publication No. 20020061031 published on May 23, 2002. Other actions that can be taken include reporting spectrum activity information to users and administrators so that artificial intelligence interactions can diagnose problems, optimize network settings, and remove sources of interference. Even when the adjustment is made automatically, an event report or alarm signal can be generated to notify the network administrator of the condition. The control can be at the special equipment level to change the operating parameters of the equipment or at the network level to change the operating parameters of the wireless network operating in the frequency band. For example, by changing one or more operating parameters used by IEEE 802.11x AP equipment, its impact How does the STA associated with the AP work in the wireless network.

The control signal can be generated in devices that actually operate in the frequency band (see Figures 11 and 12) or in computing devices that are remote from those devices that operate in the frequency band. In the latter case, the network management station 1090 or the server 1055 (Figure 1) can receive the spectrum activity information and generate control signals. The control signal is then transmitted back to one or more devices operating in the frequency band. For example, if the control signal belongs to a parameter of a WLAN AP or STA, the control signal may be transmitted to one or more APs via the network connection by the network management station 1090 or the server 1055 (as shown in FIG. 1). ) To 1050(n)). The AP will receive the control signal and change one of its operating parameters. In addition, the control signal can be transmitted to a specific STA, which provides an appropriate command to the AP of the STA so that the AP transmits parameter change information to the STA.

Spectrum Management System Structure With reference to Figure 6, the spectrum management system architecture will be described. The architecture will be described starting with the "lowest" level and going up to higher levels. The comment on the box side in Figure 6 is meant to indicate that these processes can be performed, which will become more apparent when it comes to additional features. The lowest level is the hardware located in the equipment operating in the frequency band and the drivers associated with the hardware. Thus, this level may be referred to as the hardware/driver level in the following. Examples of these devices (cognitive radio devices) have been mentioned above in conjunction with FIG. 1, and exemplary devices will be described in detail in FIG. 11. There are at least a real-time spectrum analyzer (SAGE) 20 and a radio receiver or radio transceiver (hereinafter "radio") 12 in the device to receive and sample radio frequency energy in the frequency band. The SAGE 20 can be implemented in hardware or software and combined with the radio 12 to process signals received by the radio 12 operating in a narrowband or wideband mode. In the wideband mode, the radio receiver/transceiver 12 can down-convert the signal across the entire frequency band of interest during any given time interval. If the radio receiver/transceiver 12 operates in a narrowband mode, the radio receiver (or transceiver) can be tuned to different sub-bands across the frequency band to obtain information for the entire frequency band. Depending on the particular equipment, there may also be a modem 14 which is used to perform baseband signal processing in accordance with a particular communication standard.

Also at the lowest level, there is a set of drivers associated with SAGE 20, transceiver/receiver 12 and modem 14. The SAGE driver 15 connects the spectrum activity information generated by the SAGE 20 to a higher-level process, and connects the control to the SAGE 20. The spectrum awareness driver 17 responds to manually or automatically generated controls to change the operating parameters of the device or device network. For example, if the device is an IEEE 802.11 AP, changes in operating parameters may affect changes in the operation of the AP and STAs associated with the AP. The spectrum awareness driver 17 can respond to control signals to change operating parameters that are not required by the rules of a specific communication protocol, and adopt a specially designed low medium access control (LMAC) layer associated with a specific communication standard such as IEEE802.11. Have the control points necessary to adjust those parameters.

The spectrum awareness driver 17 can receive instructions from more advanced jamming algorithms to adjust the transmission rate, storage fragmentation limit, and so on. In addition, the spectrum-aware driver 17 can receive instructions to perform dynamic packet scheduling to avoid transmitting information packets that may interfere with time and frequency from another device, dynamic packet fragments, and data "busy" encrypted signals. In addition, the spectrum awareness driver 17 can receive instructions to change the center frequency of work, work bandwidth, data rate, transmission power, and the like. The spectrum awareness driver 17 generates appropriate control signals to modify any of these operating parameters in the appropriate hardware or firmware of the radio device.

With reference to Fig. 7, SAGE20 will be briefly described. SAGE has a more detailed description in US Patent No. 10/246,365 entitled "Real-time Spectrum Analysis System and Method in Communication Equipment" filed on September 18, 2002, all of which are incorporated herein for reference.

SAGE20 obtains real-time information about activities in the frequency band and can be implemented as a VLSI accelerator or in the form of software. The SAGE 20 includes a spectrum analyzer (SA) 22, a signal detector (SD) 23, a snapshot buffer (SB) 24 and a universal signal synchronization device (USS) 25.

SA22 generates data representing a real-time spectrogram of the bandwidth of the RF spectrum, for example, a spectrum up to 100 MHz processed using Fast Fourier Transform (FFT). Similarly, SA22 can be used to monitor all activities in frequency bands, such as the 2.4GHz or 5GHz band. As shown in Figure 7, the data path leading to SA22 includes an automatic gain control module (AGC), a windowing module, an NFFT=256 point complex FFT module, and a spectrum correction module. The windowing and FFT module can support up to 120Msps (complex) sampling rate. The windowing module uses Hanning or rectangular windows to perform pre-FFT windowing on I and Q data. The FFT module provides (I and Q) FFT data for each of the 256 frequency bins, which span the bandwidth of the frequency band of interest. For each FFT sampling time interval, the FFT module outputs M (such as 10) bits of data for each FFT frequency receiver, for example, 256 receivers. The spectrum correction algorithm corrects side tone suppression and DC offset.

Inside SA22 are low-pass filter (LPF), linear-log converter, decimator and statistical module. The LPF performs a uniform gain, single-pole low-pass filtering operation on the power value of the signal at each FFT frequency. Use Pfft(k) to represent the power value of the signal at the FFT frequency f(k). Once every FFT period, the low-pass filter output Plpf(k) is updated as follows: Plpf(k,t)=α1·Plpf(k, t)+(1-α1)·Plpf(k, t-1), 1k256, which is a parameter indicating the LPF bandwidth. Calculate the decibel value PdB(k)=10*log(/Plpf_td(k)/) for each FFT value Plpf_td(k) in the linear-logarithmic module of the FFT output (calculated as dBFS, that is, all dB on the ADC) ; The decibel value is then converted to an absolute power level (dBm) by subtracting the receiver gain control from the dBFS value. PDB(k) is a data field corresponding to the power at multiple frequency receivers k. The statistics (stats) module accumulates through the RAM interface I/F26 and saves the following statistics in the stats buffer of the dual-port RAM (DPR): the frequency of the working cycle in a period of time; the average power in a period of time Vs. frequency; the maximum (max) power vs. frequency in a period of time; and the number of peaks in a period of time. The statistics module gives basic information about other signals around the device running SAGE20. The duty cycle is a continuous count of the number of times the receiver's power exceeds the power limit at the FFT frequency. The maximum power of the receiver at a specific FFT frequency is tracked at any time. The peak histogram tracks the number of peaks detected in the time interval.

The statistical module has a module for accumulating statistical information of power, duty cycle, maximum power, and peak histograms. The statistical information in successive FFT time intervals is accumulated in DPR. After a certain amount of FFT interval, determined by the configurable value stored in the spectrum analyzer control register, a pair of processor interrupts are generated to make the processor read the statistical information from the DPR to its memory. For example, before the processor reads the value from the DPR, the statistical information of 10,000 FFT intervals is kept in the DPR.

To accumulate (average) power statistics, the generated PDB(k) data field is provided to the statistics module. It can be extracted by an optional extractor. The status module adds the power of each frequency receiver in the previous time interval to the power of the frequency receiver in the current time interval. The sum of continuous power of each frequency receiver is output to DPR28 as SumPwr statistical information, also known as average power statistical information.

The work count statistics are generated by comparing PDB(k) with the power limit value. Whenever the power of the frequency receiver exceeds the power limit value, the previous work count statistics information of the frequency receiver is increased, which corresponds to the work count statistics information (DutyCnt), again, it is the power exceeding the power at the FFT frequency Continuous count of the number of limit values.

Maximum power statistics (MaxPwr) are tracked at each frequency receiver. The current maximum power value of each frequency k is compared with the new power value of each frequency k. Either the current maximum power or a new PDB(k) is output, depending on whether the new PDB(k) exceeds the current maximum power of the frequency.

The number of peaks detected by the peak detector during each FFT interval is counted, buffered and stored in the frequency distribution register for output to the DPR28.

Each of these statistics will be described in detail below.

SD23 discriminates the signal pulses in the received signal data and filters these signals based on their frequency spectrum and temporal characteristics, and transfers the characteristic information about each pulse to the dual-port RAM (DPR) 28. SD23 also provides pulse timing information to the USS25 module to allow the USS25 to synchronize its clock with transmission to/from other devices (for example, to exclude interference with QoS-sensitive ULB devices such as cordless phones, Bluetooth headsets, 802.11-based video devices, etc.). SD23 includes a peak detector and several pulse detectors, such as 4 pulse detectors. The peak detector looks for spectral peaks in the FFT data at its output and reports the bandwidth of each detected peak. Center frequency and power. The output of the peak detector is one or more peaks and related information. Each pulse detector detects and characterizes the signal pulse based on the input of the peak detector.

The peak detector detects the peak value of a group of FFT points in the adjacent FFT frequency receiver, each of which is higher than the set minimum power level. Once each FFT interval has elapsed, the peak detector outputs data describing those frequency receivers with FFT values higher than the peak limit value, and it describes which frequency receiver in the adjacent frequency receiver group has Maximum value. In addition, the peak detector delivers the power-to-frequency receiver data field for each FFT interval. This can be represented by pseudo-code (where k is the frequency receiver index): PDBdiff(k)=PDB(k)-SD_PEAKTH;

If(PDBdiff(k)0)PDBpeak(k)=PDB(k); PEAKEN(k)=1; ElsePDBpeak(k)=0; PEAKEN(k)=0; end peak output of each detected peak Bandwidth, center frequency and power.

The pulse detector calculates the relevant limit value based on the configuration information and checks whether the peak value exceeds the relevant limit value. If the peak value exceeds the relevant limit value, it defines the peak value as a pulse candidate. Once a pulse candidate is found, the pulse detector compares the identified pulse candidate with pulse definitions such as power, center frequency, bandwidth, and duration (defined by the pulse detector configuration information). After matching the pulse candidate with the defined pulse associated with the configuration information, the pulse detector declares that the pulse has been detected and outputs the pulse event data (power, center frequency, bandwidth, duration) associated with the detected pulse And start time).

SB24 collects a set of raw digital signal samples of the received signal for signal classification and other purposes, such as time of arrival measurement. SB24 can be triggered to start sampling collection from SD23 or from an external trigger source using the snap trigger signal SB_TRIG. When the snapshot trigger condition is detected, the SB24 buffers a set of digital samples and declares an interrupt to the processor. The processor then performs background-level processing on the samples for identifying and locating another device.

USS25 detects and synchronizes with periodic signal sources, such as frequency hopping signals (such as BluetoothTM SCO and some cordless phones). The USS25 interference spectrum awareness driver 17 (FIG. 6) manages the scheduling of packet transmission in the frequency band according to the Medium Access Control (MAC) protocol as provided by the IEEE 802.11 communication standard. The USS25 includes one or more clock modules, each of which can be configured to track the clock of the signal identified by the pulse detector in the SD23.

The processor (not shown) interferes with the SAGE20 to receive the spectrum information output by the SAGE20, and controls certain operating parameters of the SAGE20. The processor may be any suitable microprocessor, which may be located on the same semiconductor chip as SAGE20 or on another chip. The processor interferes with SAGE20 through DPR28 and control registers.

The control registers 27 include registers that enable the processor to configure, control, and monitor SAGE20. There are control/status register, interrupt enable register, interrupt flag register, spectrum analyzer control register, signal register control register, snapshot buffer control register and USS control register.

Referring again to FIG. 6, at the next higher level, there are a measurement engine 50, a classification engine 52, a location engine 54, and a spectrum expert 56. These processes can be executed by software. The spectrum activity information used by any of the processes 50, 52, and 54 may originate from a communication device operating in the frequency band and/or from one or more spectrum sensitive elements located at different locations in the area of interest (Fig. 1) For example, sensitive components are located on the periphery or other locations of businesses or other facilities. In addition, the measurement engine 50, the classification engine 52, and the spectrum expert 56 can be executed locally in a device working in the radio frequency band, such as an AP, or remotely executed in a server computer, such as a server 1055 or a network management station 1090 as shown in FIG. 1.

The measurement engine 50 collects and aggregates the output from SAGE 20 and normalizes the data into meaningful data units for further processing. In particular, the measurement engine 50 accumulates statistical information of the output data from the SAGE20 over a period of time to track the average power, maximum power, and duty cycle of each of the multiple frequency receivers in the entire frequency band, and other statistics described below. information. In addition, the measurement engine 50 accumulates the pulse event data of the signal pulse output by the SAGE that meets the set standard. Each pulse event can include data on power level, center frequency, bandwidth, start time, duration, and end time. The measurement engine 50 can create a histogram of signal pulse data, which is useful for signal classification, examples of which will be described below. Finally, the measurement engine 50 accumulates the originally received signal data (from the snapshot buffer of SAGE20) for position measurement in response to higher-level instructions from the architecture. The measurement engine 50 can maintain a short-term storage of spectrum activity information. In addition, the measurement engine 50 may gather statistical information about the performance of a wireless network operating in a radio frequency band, such as IEEE802.11 WLAN. The exemplary output of the measurement engine 50 is described below in conjunction with the network spectrum interface. Illustrated examples of the output of the measurement engine 50 are shown in FIGS. 21-25. In addition, more advanced applications can respond to user instructions (through an appropriate user interface) to monitor the data and statistics of the measurement engine to determine whether there is a device or device network performance degradation. Based on the determined cause of the performance degradation, certain actions can be recommended or taken automatically.

In response to requests from other software programs or systems (network spectrum interface, classification engine 52 or location engine 54 as described below), measurement engine 50 responds to configure SAGE 20 (via SAGE driver 15) and/or radio 12, according to the request For data types, run SAGE20 with those configurations, and use one or several responses from several data types generated by processing the data output by SAGE20.

The classification engine 52 compares the output of the SAGE 20 (accumulated by the measurement engine 50) with the data template and related information of the known signal to classify the signal in the frequency based on the energy pulse information detected by the SAGE. The classification engine 52 can detect signals that interfere with the operation of one or more devices (eg, occupy or appear in the same channel as a device operating in an unlicensed frequency band). The output of the classification engine 52 includes the type of signal detected in the frequency band. The classified output can be, for example, "cordless phone", "frequency hopping device", "frequency hopping cordless phone", "microwave oven", "802.11x WLAN device", and so on. The classification engine 52 can compare the signal data provided by the measurement engine with an information database of known signals or signal types. The signal classification database can be updated with reference data of new equipment using the frequency band. In addition, the classification engine 52 can output information describing one or more of the center frequency, bandwidth, power, pulse duration, etc. of the classified signal, which can be easily obtained directly from the output of the signal detector of SAGE. This is particularly useful for classifying signals that are determined to interfere with the operation of other devices in the frequency band.

Examples of signal classification techniques are described in detail in US application 10/246,364 entitled "Signal Classification System and Method for Signals in Frequency Bands" filed on September 18, 2002, all of which are incorporated herein for reference. These signal classification techniques that can be used are based on pulse histograms, pulse time signals and other customary algorithms. Examples of which are described in the aforementioned pending patent applications and briefly described in conjunction with FIGS. 8 and 9. It should be understood that other signal classification techniques are also known in the prior art.

Fig. 8 shows exemplary signal pulses of signals that may be present in the frequency band. This has IEEE802.11b signal activity consisting of pulses 1-6. Pulses 1, 3, and 5 are forward channel 802.11b transmissions, and pulses 2, 4, and 6 are acknowledgment signals. There are also frequency hopping signals, such as the B1uetoothTMSCO signal including pulses 7-14. The timing, intensity, and duration of the signal are not shown in accurate proportions. The pulse event data for signal pulses 1-6 are generated by, for example, a suitably configured pulse detector. The pulse event data for signal pulses 7-14 is generated by another suitably configured pulse detector. The signal pulse data for the two types of signals are accumulated at any time. The signal pulse data can be accumulated in different histograms. In addition, spectrum analysis information can be derived from signal activity in the frequency band, and this information can be used to generate the number of different transmissions that appear in the frequency band in a given period of time by comparing the power values at different frequencies in the same period of time ( Above the limit value) is counted to achieve.

Examples of pulse event data generated for the exemplary pulse shown in FIG. 8 are provided below.

Pulse 1 SDID: 1 (Identification Pulse Detector 1) Pulse bandwidth: 11MHz Center frequency: 37MHz Pulse duration: 1.1msec Power: -75dBm pulse 2SDID: 1 Pulse bandwidth: 11MHz Center frequency: 37MHz Pulse duration: 200microsec Power: -60dBm Pulse 3SDID: 1 Pulse bandwidth: 12MHz Center frequency: 37MHz Pulse duration: 1.1msec Power: -75dBm

Pulse 4SDID: 1 pulse bandwidth: 11MHz center frequency: 37MHz pulse duration: 200microsec power: -60dBm pulse 5SDID: 1 pulse bandwidth: 13MHz center frequency: 37MHz pulse duration: 18msec power: -75dBm pulse 6SDID: 1 pulse bandwidth: 11MHz Center frequency: 37MHz Pulse duration: 200microsec Power: -60dBm Although not listed above, the start time of the pulse is also included in the information of each pulse, thus enabling the calculation of the time between consecutive pulses detected by the pulse detector .

The pulse event data of pulse 7-14 is very similar to pulse 1-6 except for the center frequency. For example, the pulse 7-14 may have a pulse width of 1 MHz and a pulse duration of 350 microseconds, and the center frequency will vary in almost the entire range of the 2400 MHz to 2483 MHz frequency band. The SDID of pulse 7-14 is 2 because pulse detector 2 is configured to detect these pulse types.

Fig. 9 generally shows how the accumulated signal pulse data is compared with reference data. The accumulated signal pulse data is used to compare the signal pulse data of the classified signal with the reference or digest signal pulse data of the known signal. Each histogram of the accumulated signal pulse data is compared with the similar histogram of the reference signal pulse data. The degree of matching between the accumulated signal pulse data and the reference signal pulse data can be adjusted, and for some reference signal pulses, relative to other signal pulse data, it can be found that some pulse data are very close. match. To this end, each reference data group can have its own matching criteria that must be met in order to finally declare a match. For example, when comparing the accumulated signal pulse data with the reference data of the BluetoothTM SCO signal, in order to declare a match, the pulse duration, bandwidth, and time between the two pulse histograms must match very accurately. A scoring system can be used in which digital values are assigned to the comparison results between each signal characteristic. For some signal types, if the total digital value (such as the total score) is at least as large as a certain value, a match can be declared. Additional constraints may also require that certain signal characteristics must have a minimum degree of matching.

Reference data for various signals of usable frequency bands can be obtained from actual measurement and analysis of those devices, and/or from information databases provided by regulatory agencies such as the Federal Communications Commission (FCC) in the United States. The FCC can maintain a database of transmission parameters for each device that is allowed to operate in the frequency band and make it publicly available. Examples of such parameters are: working frequency range spectrum communication channel selection (bandwidth) and characterization: frequency hopping: frequency hopping rate and frequency hopping center frequency fixed channel: channel center frequency symbol rate modulation mode (such as QPSK, OFDM, QAM ,...) Transmission spectrum shielding transmission power level Transmission on/off time characterizes the minimum and maximum "on" time minimum and maximum "off" time slots between the channel channels, if appropriate comparison steps can involve the known signal The pulse timing signal is compared with the accumulated signal pulse data (usually in a relatively short period of time) to determine whether there is a match within certain predetermined and adjustable tolerances. The visual paradigm is like sliding the pulse timing template of the known signal along the accumulated pulse data of the unknown signal to determine whether it matches sufficiently. Pulse timing signals can provide a particular representation of equipment or a class of equipment. They are very useful for classifying signals with very strict timing properties.

The accumulated pulse data of a specific pulse may imply that it belongs to a specific type, but it is not necessarily limited. For example, an implied feature of 802.11 signals is the appearance of signal pulses of very short duration, which are no more than 200 microseconds, and the time between pulses is no more than 20 microseconds. However, the additional data (center frequency and bandwidth) is not enough to confirm that it is an 802.11 signal. Therefore, pulse timing signal analysis (ie, pattern formation) is performed on the pulse data. For example, pulse timing analysis of 802.11 signals focuses on identifying two signal pulses on the same center frequency that are separated by no more than 20 microseconds, and the second signal pulse (802.11ACK pulse) is no more than 200 microseconds. The duration of the first pulse of the 802.11 signal is not particularly relevant to this analysis.

A similar analysis can be performed on the pulse data versus pulse signal information of the BluetoothTM SCO signal, where the activity consists of two energy pulses (pulses) that are very close in time. The energy associated with the first pulse may appear at one frequency in the frequency band, and the energy associated with the second pulse may appear at another frequency in the frequency band, which is separated from the first pulse by a time interval, which is consistent with Reproduce on the basis of. In fact, the BluetoothTM SCO signal is representative of many unlicensed band devices that use frequency hopping sequences and include the second device (such as the "slave device) after an accurate period of time after the transmission of the first device (such as the "master device). "Device) for transmission. The time interval between the leading or trailing edge of the first pulse and the leading edge of the second pulse is usually very consistent. The duration of the two pulses can be quite short. In addition, the time interval between the leading edge of the second pulse and the leading edge of the next first pulse can be very consistent. Bluetooth TMACL transmission is quasi-periodic, which at some times appears to be periodic and has a timing signal similar to BluetoothTM SCO transmission, and sometimes it is not.

If the spectral information is derived from sampling of a part of the frequency band instead of the entire frequency band, the pulse timing signal analysis of the frequency hopping signal is slightly different. For example, when the frequency hopping signal is likely to appear anywhere in the frequency band such as the 2.4GHz band, if only the data of the 20MHz part of the frequency band is provided as input to the classification process, the signal pulse data will show a relatively small proportion of the frequency hopping signal Pulse. The pulse timing signal analysis can thus be adjusted.

When more than one device is transmitting in the frequency band, it is particularly useful to use pulse timing signal analysis to classify the signal. The pulse timing signal information of the signal can be represented by data describing the characteristics of the pulse, such as the pulse duration, the time between pulses, and so on. This information can then be compared with similar pulse timing signal information to determine if there is a match.

Both the measurement engine 50 and the classification engine 52 can generate spectrum events that are reported to a higher-level software program or system. For example, based on the analysis of spectrum activity information generated by SAGE20, a report of a specific type of event can be given, such as a BluetoothTM device being turned on or off in a frequency band, or a cordless phone is working. These spectrum events will be described further below.

Referring again to FIG. 6, the location engine 54 calculates the physical location of the device operating in the frequency band. An example of a position measurement technique includes using the snapshot buffer data collected by the measurement engine 50 to perform two or more known positions (e.g., in the signal transmitted by the device to be positioned and another reference signal (e.g. AP)). The time difference of arrival (TDOA) of two or more STAs is measured to determine the location of various devices (such as interference signals) operating in the frequency band. At some point, simply moving the interfering signal to a different location can solve a transmission problem that another device or device network may be experiencing. The location engine 54 can collate measurement results obtained from multiple locations in the network. An example of a location engine is described in US application 60/319,737 entitled "System and Method for Locating Wireless Devices in Asynchronous Wireless Networks" filed on November 27, 2002, all of which are incorporated herein for reference. . A large number of other techniques that use TDOA and Time of Arrival (TOA) measurements to determine the location of a wireless radio communication device are known in the prior art and can also be used for location engines.

Alternatively, the location engine 54 may be located in software "above" the network spectrum interface (NSI) 70. When an interference condition in the frequency band is detected, the spectrum expert 56 or the network expert 80 may order the location engine 54 to physically locate the source of the interference signal. The output of the location engine 54 may include location information, power level, device type, and/or device (MAC) address. The security service 82 may instruct the location engine 54 to locate fraudulent devices that may have security issues.

The spectrum expert 56 is a process of optimizing the work of the equipment operating in the frequency band, assuming that the knowledge about the activity in the frequency band is obtained by the measurement and classification engine. For example, the spectrum expert 56 processes data from SAGE 20 and optional statistics from specific wireless networks operating in frequency bands, such as IEEE 802.11x networks, to make recommendations to adjust parameters of the device or automatically perform those adjustments in the device. The spectrum expert 56 may be a software program that is executed, for example, executed by a host device connected to an AP, a server, or a network management station (FIG. 1). The parameters that can be adjusted (manually or automatically) based on the output of the spectrum expert 56 include channel, transmission power, memory fragmentation limit, RTS/CTS, transmission data rate, CCA limit, interference avoidance, etc. Other examples of interference mitigation techniques are described in US application 10/248,434 entitled "Interference mitigation system and method for periodic interfering signals in short-range wireless applications" filed on January 20, 2003, all of which are combined in This is for reference. The spectrum expert 56 may turn on triggers for alarm conditions in the frequency band, such as detection of signals that interfere with the operation of equipment or equipment networks operating in the frequency band, to automatically report alarm information and/or adjust parameters in the equipment in response thereto. For example, the spectrum expert 56 may work to control or suggest the control of a single WLAN AP.

Spectrum experts 56 are critical information decision makers. The spectrum expert 56 (and/or the network expert described below) can determine what kind of alarm and/or control to generate based on the spectrum policy information. Spectrum policy information is an information body, which defines corresponding alarms and/or controls based on the determined conditions that will appear in the frequency band. This body of information is updatable to take into account new equipment operating in the frequency band and/or changes in the rules regarding the requirements of the frequency band. In addition, the spectrum expert 56 can decide to act, how to act, or not to act. For example, a spectrum expert may decide to interfere with another signal or decide not to interfere. Examples of how spectrum policies can be applied are described below.

The spectrum expert 56 can use the spectrum activity information to intelligently control the IEEE802.11 WLAN parameters in the AP.

1. Measuring the quality of received signals and information about interfering signals may require adjustment of the AP and/or STA transmission data rate.

2. Tracking information packet errors and SAGE pulse data may require adjustment of storage fragmentation limit values.

3. The detection in the statistical information of the packet sequence indicating the hidden node may require the execution of the RTS/CTS sequence. The RTS/CTS sequence is used as a "transmission confirmation system" and is turned off when possible, such as in a low-noise environment, because it slows down the transmission, but it can be activated when necessary, such as to discover STAs.

4. Using SAGE spectrum analysis data, the AP can be controlled to select a new and cleaner channel.

5. The use of SAGE-related data and signal classification data indicating interference signals may require adjustment of the AP's transmission power.

6. Perform actions based on the specific device type or even the recognized brand and device model (through snapshot buffers and other spectrum data).

Generally, the spectrum expert 56 can be implemented in a radio device, which controls itself (in the case of an AP) while controlling the behavior of several other radio devices associated with it. These types of decisions and controls are called local policy decisions or controls because they affect a device or a particularly limited group of devices. The network expert 80 described below can make broader types of policy decisions and controls, such as those that affect the entire network of devices (multiple APs in the WLAN and their associated STAs).

A sensitive element overlay network composed of one or more spectrum sensitive elements 1200(1) to 1200(n) can generate spectrum activity information, which is provided to a server that controls devices operating in the frequency band. For example, signal detection is performed at the sensor level, and measurement and accumulation can be performed at the sensor level or the AP's main processor. The spectrum expert is executed on the main processor of the main device, which is connected to the AP and used to control the AP. Signal detection is performed at the sensor level, and measurement and accumulation can be performed at the sensor level or the AP's main processor.

The level of abstraction in which the measurement engine 50, the classification engine 52, and the spectrum expert 56 are located may be referred to as the "spectrum" or "spectrum awareness" level in the following.

The NSI 70 shown in Figure 6 interferes with the measurement engine 50, classification engine 52, location engine 54, and spectrum expert 56 processes (and lower level drivers) to higher level services. The NSI 70 serves as an application programming interface (API), which can be implemented by application programs (on one or more computer-readable media) to approximate the spectrum analysis functions of these processes. The end user orders on demand to check the spectrum knowledge or activity information that can be received from the application at a specific device, and the NSI converts the command into a request for a specific spectrum analysis function from one of the processes. It is also possible to have an interaction between the measurement engine 50, the classification engine 52, the location engine 54 and the spectrum expert 56, which uses an interface similar to the NSI70. In addition, the physical location of the modules in FIG. 6 is not meant to limit the possible logical arrangements of these functions, applications or processes. For example, NSI can be used to connect any one or more of the modules shown in FIG. 6 with the measurement engine, classification engine, and/or spectrum analysis function of the spectrum expert. In addition, there may be fewer formal interfaces or connections between any two processes shown in Figure 6.

The level of abstraction just above the NSI70 can be called the "network" level. At the network level, there may be various services. For example, there are network experts 80, security services 82, location services 86, and data mining services 88. The software located on the NSI, although separately identified and described below, can also be collectively and generally referred to as network management software (NMS), which can be executed by the network management station 1090 (FIG. 1).

The network expert 80 is similar to the spectrum expert 56, but it works at a higher level, such as spanning multiple WLAN APs such as AP1050(1) to 1050(n) and their related STAs, as shown in Figure 1. The network expert 80 optimizes the network based on usage cost, capacity, and QoS. The network expert 80 can make suggestions to the network administrator or automatically adjust parameters in one or more wireless networks. For example, the network expert 80 can control or suggest parameters: AP and AP antenna arrangement, AP channel allocation, load balancing of STAs across APs (STAs are allocated to different APs based on network load conditions), transmission power, and RTS/CTS parameter. In addition, network experts can notify network administrators or network management applications of interference detected anywhere in the network. The network expert 80 can optimize the coverage of devices in the wireless network, which is achieved by allocating STAs to APs, which can provide the best throughput and reliable communication connections. The spectrum activity information processed by the network expert can originate from APs working in the frequency band or from one and/or more spectrum sensitive elements located at different locations in the area of interest, such as in a commercial enterprise or other facility The periphery or other location. The network expert 80 may also have triggers to generate warning messages when certain conditions are detected. A WLAN AP with spectrum monitoring capabilities (and control capabilities) can be used by any WLAN associated with it Any spectrum information provided to it by the STA is added to its spectrum knowledge. However, the network expert 80 may have a more global view of the spectrum activity of the entire area of the unlicensed frequency band, which may include multiple wireless networks of the same or different types (such as IEEE 802.11 WLAN, WPAN, B1uetoothTM, etc.). Conversely, the WLAN AP can notify its associated STAs of the spectrum status monitored by the AP.

The network expert 80 can use the spectrum measurement data to optimize 802.11 protocol functions, such as channel scanning, where SAGE20 analyzes the data of the entire frequency band to output information so that the classification engine 52 can identify what appears in other channels; channel selection/load balancing, where SAGE20 aggregates full-band statistics for channel utilization. The advantages of these technologies are faster channel acquisition, faster channel delivery, and STA-based load balancing.

The network expert 80 works on the basis of spectrum activity information obtained from a wider area such as the network. One way to obtain this information is through multiple cognitively-enabled APs, each of which is connected to a server that executes the network expert 80. Alternatively, or in addition, a sensitive element overlay network composed of one or more spectrum sensitive elements 1200(1) to 1200(n) is configured in the entire network or area of interest. The network expert 80 executes and controls or is connected to control the AP on a server connected to the sensitive element, such as managing an application through a WLAN. Signal detection is performed at the sensor level, and measurement and classification can be performed at the sensor level or on the server.

The network expert 80 may be connected to a general network management system, such as a system supported by the network management station 1090 shown in FIG. 1. A general network management system can control the enabling, disabling, and configuration of network components such as APs. The system integration module 90 (described below) can connect the network expert 80 with the general network management system to allow the network expert 80 to be notified of changes in the general network management system, and to notify the changes in the wireless network such as channel allocation and STA association General network management system.

Thus, the network expert 80 can make wider types of policy decisions and controls. In addition, the network expert 80 can serve as a higher level of control for multiple situations of the spectrum expert 56. Each spectrum expert is associated with a device that is part of a larger network or regional device deployment. The bar graph is shown in Figure 28, which will be described below. If this is done, the network expert 80 must consider the local policy decisions and controls made by the spectrum expert 56 within its scope. The network expert 80 will preserve and maintain local policy decisions and controls made by its spectrum expert 56. The network expert 80 may make regional policy decisions or control or network-wide policy decisions or control. The regional scope decision is about activities that appear in a specific "area" or activities that are controlled on-site by some but not all spectrum experts 56 within the scope of network experts. The network-wide decision is about activities that occur across the entire network across all areas or sites where the network exists. When making regional or network-wide decisions, the network experts 80 can make these decisions so that they do not interfere with local policy decisions or controls made by the spectrum experts 56, or can make certain decisions that supersede certain local decisions . For example, a specific AP under the control of a network expert may be experiencing occasional interference on a specific channel at a certain time of the day, and similarly, it is adjusted (e.g., by the spectrum expert 56) to move to during that time of the day Another channel. The network expert 80 may decide to permanently move the specific AP to a specific channel based on other information. This may conflict with the occasional need for the AP to stay away from the channel at certain times of the day. Therefore, the network expert 80 will modify its decision to move the AP to the channel to respect the local policy at the AP. When considering local policy decisions, the network expert 80 can modify its decision to avoid "oscillation" in network or regional behavior.

The security service 82 provides security information based on spectrum activities and related information generated at a lower level. For example, the security service 82 can detect when there is a denial of service attack on more than one device working in the frequency band or on the network, detect "parking lot" attacks, find the location of fraudulent devices such as unauthorized APs, and perform RF" "Fingerprint" identification to determine whether there is a device disguised as an authorized device (such as a station or AP).

Denial of service attacks can be detected by examining spectrum activity information to find large-bandwidth noise signals that can interfere with one or more signals in the frequency band. If the noise signal continues during a very important time period, the security service can announce that a denial of service attack is being carried out on one or more wireless networks operating in the frequency band. Alarm information or reports can be generated to notify the network administrator of the situation and describe the attack situation (approximate location of the source, power level, frequency bandwidth, time of occurrence, etc.).

A parking lot attack is when the user of a wireless network device receives and/or transmits signals on the wireless network without authorization. For example, if the wireless device is placed close to the working network, it is sufficient to receive and/or transmit signals on the network. You can get past encryption interference or encryption is not enabled on the network. If the user of the device is only listening to the transmitted signal, there may be no way to detect it. However, if the physical boundary (two-dimensional or three-dimensional) of the service network can be constructed around the AP, the location engine 54 can be used to determine whether the device is outside the physical boundary by the transmission from the device, which indicates that unauthorized devices may attempt to access Information stored on the server connected to the AP's wired network.

Unauthorized devices (such as AP) can be detected by checking the transmission of the device and the information contained in the transmission (such as the IEEE802.11 Service Set Identifier (SSID)) used from it. The SSID is relative to the stored one. Whether the group valid SSID is valid can be determined. If the AP is operating in the frequency band with an invalid SSID, the security service 82 may instruct the location engine 54 to determine the location of the AP.

If a security-related breach is detected on one or more wireless networks or devices operating in the frequency band, the security service 82 can generate real-time alarm information to the network administrator. In the case of detecting a potential parking lot attack, a program can be set to require the user of the device outside the boundary (or the device itself) to provide the AP to confirm that it is an authorized device security code. A device that cannot provide this code is considered an unauthorized device, and the service for that device is terminated. Alarm information can also be generated to notify the network administrator to further investigate the user.

Another way to manage security in a wireless network is to save the RF signal of each authorized device, such as the RF signal of each authorized STA or AP. RF signals can be created by capturing the detailed signal pulse characteristics of each authorized device, which are obtained using SAGE-enabled devices, and the information describing these characteristics is stored in the database. Whenever a STA associates with an AP, its signal pulse characteristics can be compared with the information database to determine whether it is an authorized device. This program protects the users of the STA from obtaining a valid MAC address (by listening to transmissions in the WLAN) and from using the MAC address to pretend to be the STA. Even if the MAC address will be valid, the RF fingerprint of the rogue device will likely not match the RF fingerprint of the authorized device stored in the database.

The location service 86 provides a value-added service to the location measurement performed by the location engine 54. An example of these services is an overlay. An example is shown in Figure 10, which quickly transmits sound on the IP device, finds the printer closest to the device, finds the missing device, and performs accident location (E911). As another example, the location service 86 may process spectrum information from multiple points or nodes (multiple spectrograms) in the area of an unlicensed frequency band implementation (such as an enterprise) and compile the information into an easy-to-understand format.

The data mining service 88 includes capturing spectrum activity information (and optionally output from spectrum experts) for long-term storage in the database. By using queries to analyze non-real-time spectrum activity information, network administrators can determine different situations such as what time of day interference is the problem, what area of the work area has the heaviest spectrum load, and so on.

Above the network level are the system integration module 90 and the user interface (UI) module 92. The system integration module 90 connects data from any service down to other applications, protocols, software tools or systems, and is generally referred to as a network management application 94. For example, the system integration module 90 can convert the information into an SNMP format. The functions performed by the system integration module 90 are specified by specific applications, protocols, systems, or software tools that want to work with the following services. The network management application 94 may be executed by the network management station 1090 (FIG. 1) to manage wired and wireless networks. UI92 can provide a graphical, audio or video type interface of information generated by any of the following services for people to consume. Examples of graphical user interfaces for spectrum activity information and alarm information are shown in Figures 16-25, which will be described below. These advanced processes can be performed on a computer device far away from where radio frequency band activity occurs. For example, the network management application 94 may be executed by a network management station 1090 located in a central monitoring or control center (telephone service provider, cable Internet service provider, etc.), which is connected to sensitive element devices, APs, etc. A wide area network (WAN) connected to the Internet, dedicated high-speed wired connection, or other long-distance wired or wireless connection controlled equipment (such as AP).

Any device that receives radio frequency energy in the frequency band of interest can be equipped with SAGE20 to generate spectrum activity information. Fig. 11 shows an example of such a cognitive radio device. The communication device includes a radio 12 that down-converts the received radio frequency energy and up-converts the signal for transmission. The radio 12 may be a narrowband radio or a radio capable of broadband and narrowband operation. An example of a broadband radio transceiver was filed on April 22, 2002, entitled "System and Architecture of Wireless Transceiver Using Synthetic Waveform and Spectrum Management Technology" in the United States Provisional Application 60/374,531 and October 11, 2002 It is disclosed in U.S. application 10/065,388 filed in Japan and entitled "Multiple Input Multiple Output Radio Transceiver". The baseband part (which may include or correspond to the modem shown in FIG. 6) is connected to the radio 12 and performs digital baseband processing of the signal. One or more analog-to-digital converters (ADC) 18 convert the analog baseband signal output of the radio 12 into digital signals. Similarly, one or more digital-to-analog converters (DAC) 16 convert the digital signals generated by the baseband section 14 for up-conversion of the radio 12. Referring to Figure 6, SAGE20 is shown as receiving input from ADC18.

A processor 30 may be provided, which is connected to the baseband part 14 and the SAGE20. The processor 30 executes instructions stored in the memory 32 to perform several software spectrum management functions, which are described herein as "monolithic" or "embedded" software functions. Therefore, certain software stored in the memory 32 is referred to herein as monolithic or embedded software. Examples of monolithic or embedded software functions are the SAGE driver 15, the spectrum awareness driver 17, and the measurement engine 50, although the additional processes shown in FIG. 6 such as the classification engine 52, the location engine 54 and the spectrum expert 56 can be executed by the processor 30. The phantom line shown in FIG. 11 means to point out that several or all of those elements enclosed therein can be manufactured in a single digital application specific integrated circuit (ASIC). The processor 30 also performs MAC processing associated with the communication protocol. The larger boxes around the radio and other components are meant to indicate that these elements can be implemented in a network interface card (NIC) form factor. The processor 30 may have the ability to generate traffic statistics about the specific communication protocol used by the device. Examples of IEEE802.11 traffic statistics are described below.

A main processor 40 may be provided, which is connected to the processor 30 through a suitable interface 34. The main processor 40 may be a part of a main device, such as a personal computer (PC), a server 1055, or a part of a network management station 1090 (FIG. 1). The memory 42 stores host or "off-core" software to perform more advanced spectrum management functions. Examples of processes executable by the main processor 40 include a measurement engine 50, a classification engine 52, a location engine 54, and a spectrum expert 56. In addition, the main processor 40 can execute even higher-level processes, such as the network expert 80 and lower-level processes.

The communication device shown in FIG. 11 may be a part of or correspond to various devices operating in a frequency band, such as an IEEE802.11 WLAN AP or STA. The communication device can share information with a computer far away from it, such as a server 1055 or a network management station 1090 as shown in FIG. 1. The remote computer may have wireless communication capability (or be connected to a communication device through another device with wireless communication capability through a cable). The software that executes the system integration module 90 and the UI 92 (FIG. 6) can be executed by the main processor 40 or by a remote computer such as a server 1055 or a remote network management station 1090.

One of the cognitive radio devices shown in Figure 11 can detect, measure, and classify activities that occur in the frequency band, and through functions such as spectrum expert 56, can make intelligent decisions about whether to change any of its operating parameters. Such as operating frequency, transmission power, data rate, packet size, transmission timing (to avoid other signals), etc. In addition, the radio device can detect, measure, and classify activities in the frequency band in response to control generated on the basis of information generated by another radio device.

FIG. 12 shows a simplified diagram of spectrum sensitive elements (such as spectrum sensitive elements 1200(1) to 1200(n), which were mentioned above in conjunction with FIG. 4). The spectrum sensitive element is a radio device that receives signals in the frequency band of interest. In this sense, the spectrum sensitive element is a spectrum monitor, and can also detect, measure and classify to provide spectrum information, which is provided to other radio equipment, network control applications, etc., which can control the entire device The work of the network. The spectrum sensitive element includes at least one radio receiver capable of down-converting signals in the frequency band of interest, either in a wideband mode or in a scanning narrowband mode. If possible, as shown in Figure 12, the spectrum sensitive element includes two radio receivers 4000 and 4010 (dedicated to different unlicensed frequency bands) or a dual-band radio receiver. There is an ADC18 which converts the output of the radio receiver into a digital signal, which is then connected to SAGE20 or other equipment capable of generating signal pulses and spectrum. The DAC16 can be used to provide control signals to the radio receiver via the switch 4020.

The interface 4030, such as Cardbus, Universal Serial Bus (USB), mini-PCI, etc., connects the output of the SAGE20 and other components to the main device 3000. There is an optional embedded processor 4040 to perform native processing (measurement engine 50, classification engine 52, location engine 54 and spectrum expert 56 as shown in Figure 6), and an Ethernet module 4050 to connect to wired networks, FLASH Memory 4060 and SDRAM 4070. There is also an optional lower level MAC (LMAC) logic module 4080 associated with a specific communication protocol or standard ("Protocol X") or a modem 4090 associated with Protocol X. The protocol X can be any communication protocol that works in the frequency band, such as the IEEE802.11x protocol. The device can support multiple protocols. Many modules can be integrated in a digital logic gate array ASIC. The LMAC logic 4080 and the modem 4090 can be used to track communication throughput on protocol X and generate traffic statistics. The larger box around the radio and other components is meant to indicate that the spectrum sensitive component device can be implemented in the NIC form factor for PCI PC card or mini-PCT configuration. Or, to save embedded processors, many of these components can be implemented directly on the processor/CPU motherboard.

The main device 3000 may be a computer with a processor 3002 and a memory 3004 to process spectrum activity information provided by the spectrum sensitive element via a wired network connection, a USB connection, or even a wireless connection (such as an 802.11x wireless network connection). The display monitor 3010 may be connected to the main device 3000. The memory 3004 in the host device can store a software program, which corresponds to the aforementioned embedded software and/or host software (used in the process shown in FIG. 6). In addition, the memory 3004 can store driver software for the host device, such as a driver for an operating system such as a Windows operating system (Windows® XP, Windows® CE, etc.). The main device 3000 may be a desktop or notebook personal computer or a personal digital assistant, or a computer device local or remote from the spectrum sensitive element, or the server 1055 or the network management station 1090 shown in FIG. 1.

In some forms of spectrum sensitive components, there is SAGE20, but there are no other processing components, such as embedded processors. Sensitive components should be connected to the processor in the main device or remote server, where the output of SAGE20 is processed to perform signal measurement/accumulation, classification, etc. This may be desirable for low-cost spectrum sensitive components to be used as part of a sensitive component overlay network, where most of the signal processing is performed at one or more centrally located computing devices.

Another change is to implement the functions of SAGE20 in the software on the main processor 3002. The ADC output of any one or more devices working in the frequency band (especially those devices with broadband capable radio receivers) can be provided to the main processor, where the above-mentioned spectrum management functions are all executed in software, such as Measurement engine, classification engine, etc. For example, the output of the ADC 18 may be connected to the main processor 3002 across any of the interfaces shown in FIG. 12, which executes the SAGE process and one or more other processes in software.

The spectrum sensitive element can be configured in any device located in the area where work occurs in unlicensed or shared frequency bands. For example, it can be located in a consumer's device such as a video camera, home theater, PC peripheral, etc. Any other device connected to the spectrum sensitive element can obtain the spectrum knowledge learned by the spectrum sensitive element and will add to any knowledge about the spectrum itself that it can learn from its own spectrum monitoring capabilities, if supported. In addition, the spectrum knowledge learned by the local device (such as a PC) from the remote device can be used to configure and/or diagnose the work at the local device (such as a PDA) and the remote device.

The LMAC logic 4080 may be implemented in software executed by the embedded processor 4040. One advantage of the software-implemented LMAC is that it is easier to generate additional statistical information associated with protocol X than the firmware implementation. These statistics can be accumulated by software counters and allocated storage locations in the LMAC software. Examples of additional IEEE802.11 statistical information that can be generated by the radio device shown in FIGS. 11 and 12 will be described below. Some of these statistics are good indicators of performance degradation in devices such as WLAN AP or WLAN STA, and can be used to automatically initiate corrective actions or controls, or generate information to warn users/network administrators, software applications Wait. Many of these statistics can be provided by a 32-bit counter, but only as short as 5 minutes. The software from the main drive can periodically poll these counters and convert them into 64-bit counters (wrap time of 43 Kyears), which will reduce single-chip storage requirements.

Examples of additional IEEE802.11 MIB extensions for STAs that can be generated from the statistical information generated by the LMAC logic are explained below. These statistics can be used to determine general channel problems and problems affecting a subset of STAs, such as those based on location and local interference signals. For example, these statistics can point out packet error rate (PER) information and provide insights into possible types of interference signals, and can be used to help adjust memory fragmentation and RTS limits.

lmst_RxTime The timestamp when the last frame (of any type) has been received from this STA. This means that the STA appears on the channel, but it does not mean that it is a response to the association/authentication state or other higher-level activities. For the multicast STA record, it is updated when the last multicast frame is sent.

lmst_AckMSDU The number of MSDUs that were successfully sent, that is, the last/only fragment was ACKed or it was multicast. The total number of data/mgmt frames sent is derived from the number of confirmed and unconfirmed numbers.

The number of fragments successfully sent by lmst_AckFrag (not including the last fragment counted in lmst_AckMSDU).

lmst_RxCTS The number of times RTS was sent and CTS was received. The number of RTS frames sent is derived from the number of CTS frames received and the number of unreceived frames.

lmst_NoCTS The number of times RTS was sent, no CTS was received.

The number of unicast data/mgmt frames sent by lmst_RxACK and the ACK frames received. This indicates the actual ACK control frame, not the PCF/HCF piggyback ACK. For PER calculations, lmst_AckMSDU+lmst_AckFrag may be more useful. The difference between those statistical information, this field is the number of piggyback ACKs processed.

lmst_NoACK The number of unicast data/mgmt frames sent, and no ACK was received.

Llmst_BadCRC CTS or ACK control frame is expected to be the number of times, and the frame with CRC error is received. This may mean that the frame was received by the recipient, but the response was lost. Other frames with CRC errors cannot be correlated because the frame type and source address fields are suspicious.

lmst_BadPLCP The number of expected CTS or ACK control frames, and the number of received frames that the PHY cannot demodulate. This may mean that the frame was received by the recipient, but the response was lost. Other frames with PLCP errors cannot be associated with each other because the frame type and source address fields are not provided from the PHY. This condition is also counted under the lmif_BadPLCP statistics.

lmst_MaxRetry indicates frames that have been withdrawn due to excessive retransmissions.

lmst_HistRetry[8] provides a histogram of the number of retransmission attempts before receiving the response. This includes RTS to CTS, and each fragment to ACK is in the frame exchange sequence. Flag 0 is used for the first successfully transmitted frame. This usually produces an inverted exponential curve, and if it deviates greatly, it indicates a large operational interruption, such as remote interference from a microwave oven.

lmst_HistSize[2][4] provides a histogram of PER vs. frame size. The first flag is OK and no response, and the second flag is for the frame size relative to the fragmentation limit. It is used to quickly adjust the fragment limit value.

The following statistics provide information on received data/management frames. Statistical information can be maintained on each received frame. Certain statistical information is only expected on the AP or STA unless there is an overlapping BSS on the channel, and can provide insight into the channel bandwidth lost due to the overlap.

lmst_FiltUcast filters the data/management frame because it is presented to another STA.

lmst_FiltMcast filters data/management frames because it is dedicated to a multicast address, which is not enabled in the multicast hash.

lmst_FiltSelf filters the data/management frame because it is a multicast frame being forwarded by the AP to the BSS.

lmst_FiltBSS filters the data/management frame because it is a multicast frame and its BSSID does not match the filter.

Llmst_FiltType filters data/management frames because its frame type/subtype is disabled by the frame type filter. This can include zero data frame types, unsupported management frame types, and can include other types during the BSS scan.

lmst_FiltDup filters the data/management frame because it is a copy of the previously received frame. This indicates that the ACK frame is being lost. Although not all errors will be detected here, this can provide a rough approximation of the PER in the opposite direction.

The lmst_FwdUcast unicast data/management frame is transmitted to the embedded processor.

The lmst_FwdMcast multicast data/management frame is delivered to the embedded processor.

Llmst_BadKey filters data/management frames because it requires a decryption key that has not yet been provided. This indicates a configuration error on the side of the connection.

lmst_BadICV filters the data/management frame because it failed to decrypt successfully. This can indicate a security attack.

lmst_TooSmall filters the data/management frame because it is encrypted, but does not include the required encrypted header. This indicates a protocol error.

The following statistics provide information on other frame exchanges.

lmst_RxRTSother The number of times the RTS was received, which was not presented to the STA.

lmst_TxCTS The number of times the RTS was received, and the CTS was sent as a response.

lmst_TxACK The number of unicast data/management frames received, and ACK is sent as a response.

The following statistics can provide information that can be used to adjust the transmission data rate.

lmst_TxAveRate The average rate of successfully transmitted data/management frames. Divide by (lmst_AckMSDU+lmst_AckFrag) for the average rate code. It only counts confirmed frames.

lmst_RxAveRate The average rate of unicast data/management frames successfully received. Divide by lst_TxACK for the average rate code. This includes all confirmed frames, including filtered frames. Because this can include duplication (lmst_FiltDup), its value is not completely symmetrical with transmission.

The following statistical information provides information on received frames with various errors, but cannot be traced back to the originating station.

lmif_SaveCRC[3] This provides the time stamp and PHY statistics of the last frame received with a CRC error.

The number of frames with CRC errors received by lmif_BadCRC is either counted here, or in lst_BadCRC.

lmif_SavePLCP[4] This provides the timestamp, PLCP header, and PHY statistics of the last frame received counted in lmif_BadPLCP.

The number of frames received by lmif_BadPLCP[4] where the PHY cannot demodulate the PHY header is broken for some reason. These include CRC/parity error, bad SFD field, invalid/unsupported rate, and invalid/unsupported modulation.

lmif_SaveMisc[3] This provides the timestamp, PHY statistics, and the first 4 bytes of the MAC header of the last frame received, and the remaining received errors are listed in this group.

The number of frames received by lmif_TooSmall that are too small for their frame type/subtype. This indicates a protocol error.

The number of frames with invalid/unsupported versions received by lmif_BadVer. This indicates a protocol error, or a newer (incompatible) version of the 802.11 specification has been released.

The number of control (or preliminary) frames with invalid/unsupported frame types/subtypes received by lmif_BadType. This indicates a protocol error, or a newer (incompatible) version of the 802.11 specification has been released.

lmif_FromUs The number of frames received from "our" MAC address. This indicates a security attack and should be reported to the network management application.

The statistics below provide information exchanged by other frames, where the source address is not known.

lmif_RxCTSother is dedicated to the number of CTS frames of other stations.

lmif_RxCTSbad is the number of CTS frames received when there is no RTS unresolved. This indicates a protocol error.

lmif_RxACKother is dedicated to the number of ACK frames from other stations.

lmif_RxACKbad The number of ACK frames received when there is no data/management frames are not resolved. This indicates a protocol error.

The following statistics provide information on channel usage, and Carrier Sense Multiple Access (CSMA).

The time it takes for seq_CntRx to receive 802.11 frames, in units of 0.5μs. Part of the time taken to demodulate the frame is counted in seq_CntCCA until the PHY header has been processed.

seq_CntTx The time it takes to transmit 802.11 frames, in units of 0.5μs.

seq_CntCCA The time it takes for energy detection, but no 802.11 frame is received, in units of 0.5μs. Part of the time taken to demodulate the frame is counted in seq_CntCCA until the PHY header has been processed. This can also be used to detect the presence of strong interference, which has blocked the network (denial of service to the network) such as a baby monitor.

seq_CntEna The time it takes for the channel to be enabled and idle, in units of 0.5μs. This includes the time that the CSMA channel cannot be used, such as SIFS time and channel compensation time. High usage can provide an indication of a denial of service attack or the presence of hidden nodes.

seq_Timer is the time taken by the last LMAC to recover (normal running time), in units of 0.5μs. Any time not specified by the previous 4 counters indicates when the channel is disabled.

lmif_CCAcnt The number of times the received energy was detected. This does not include any transmission time.

lmif_CCAother The number of times the received energy was detected, but no 802.11 frames were received (even frames that could not be demodulated).

The total number of lmif_RxFIP received events, as specified in other statistics per frame type.

The total number of lmif_TxFIP transmission events, as specified in other statistics per frame type.

The lmif_TxSkip channel can be used for the number of transmissions through the CSMA protocol, but no frame can be used for transmission. This can help distinguish performance problems due to upper MAC (UMAC) or host processor bottlenecks restricting the 802.11 channel or protocol.

lmif_CWnBack The number of times that channel compensation or postponement is executed.

lmif_CWused The number of time slots consumed by compensation or postponement.

lmif_HistDefer[4] For each attempt to start the frame exchange sequence, this indicates whether postponement or compensation is required, and why. The four cases are: no delay is required; after receiving energy and/or receiving frames, being delayed; after transmitting, being delayed; and compensation after not receiving CTS/ACK response. Before each attempted frame exchange sequence, only one record of the last cause can be counted.

Matching activity information and using NSI to access spectrum activity information measurement engine 50, classification engine 52, location engine 54, and spectrum expert 56 perform spectrum analysis functions and generate information that can be used by applications or systems, which access these functions through NSI 70. The NSI 70 can be embodied by instructions stored on a computer/processor readable medium and executed by a processor (server 1055 or network management station 1090) executing one or more application programs or systems. For example, the processor can execute instructions for the NSI "client" function, which generates requests and configurations for spectrum analysis functions and receives the resulting data for use in applications. The processor executing the measurement engine, classification engine, location engine and/or spectrum expert will execute the instructions stored on the relevant computer/processor readable medium (shown in Figure 1, 11 or 12) in response to the request from the NSI customer Request to execute an NSI "server" function to generate configuration parameters and start the spectrum analysis function through the measurement engine, classification engine, location engine and/or spectrum expert to execute the requested spectrum analysis function and return the obtained data. The measurement engine may then generate controls for the SAGE driver 15 to configure the SAGE 20 and/or radio 12.

It should also be understood that the classification engine, the location engine, and the spectrum expert can be regarded as a client of the measurement engine, and can generate requests for the measurement engine and receive data from the measurement engine, similar to the interaction between the application and the measurement engine The way. In addition, spectrum experts can be regarded as customers of classification engines and location engines and request analysis services of those engines.

NSI70 can be transmitted separately (such as supporting sockets, SNMP, RMON, etc.) and can be designed to be implemented in wired or wireless formats, such as TCP/IP traffic from 802.11AP to PC, which is designed to accept traffic to Run software for further analysis and processing. TCP/IP traffic (or some other traffic regardless of the protocol) can also be carried by the PCI bus in the laptop PC, assuming that the PC has built-in 802.11 technology or 802.11 NIC. If the source of the spectrum information data stream is a TCP/IP connection, the application may implement a socket and access the correct port to read the data stream. An example of typical code used for this purpose is shown below. (This example is written in Java language and represents the code on the client side). Once the port connected to the data stream is established, the use of the data stream is determined by the network management software itself.

The class DataInputStream has methods such as reading. The DataOutputStream class allows writing Java primitive data types; one of its methods is to write bytes. These methods can be used to read data from NSI70 or write data to NSI70.

If the transmission of the data stream occurs on other low-level media, other methods can be used to access the data stream. For example, if the data is carried on the PCI bus of the PC, the PCI device driver will usually provide access to the data.

The information provided by the NSI to the application corresponds to the data generated by the measurement engine 50 (via SAGE), the classification engine 52, the location engine 54 and/or the spectrum expert 56.

When used as an API, NSI has a first set of messages that identifies (and activates) the spectrum analysis function to be executed (also called service or test) and provides configuration information for that function. These are called dialog control messages and are sent to NSI by the application. There is also a second set of messages, called indicative messages, which are sent by the NSI (after the requested spectrum analysis function is executed) to the application, containing the test data of interest.

Most spectrum analysis functions (ie tests) have different configuration parameters, which are sent via dialog control messages, and which determine the specific details of the test. For example, in the monitoring spectrum, the dialog control message tells the NSI how wide the bandwidth should be (narrowband or wideband), and the center frequency of the bandwidth is monitored. In many cases, the detailed test configuration parameters of the spectrum analysis function can be omitted from the dialog control message. In those cases, NSI uses set default values.

Examples of spectrum analysis functions that can be performed by the measurement engine 50 (together with the service of SAGE20) and the resultant data returned include: spectrum analyzer power versus frequency data. The data describes the total power in the spectrum as a function of frequency on a specific bandwidth.

Spectrum analyzer statistical information data. This data provides a statistical analysis of the data in the RF power versus frequency measurement.

Pulse event data. This data describes the characteristics of each RF pulse detected by SAGE20. The features used (and thus the pulse type) to be detected by SAGE20 can be configured.

Pulse histogram data. This data describes the distribution of pulses per unit time, based on the percentage of pulses distributed between different frequencies, energy levels and bandwidths.

Snapshot data. This data contains the raw digital data portion of the RF spectrum captured by the SAGE20's snapshot buffer. This data can help identify the location of the device, and can also be used to extract identifier information, for example, it can determine the brand of certain devices operating in the frequency band. Snapshot data can also be used for signal classification.

The classification engine 52 can perform a spectrum analysis function to determine and classify the signal types appearing in the frequency band. Together with the optional suggestions or descriptive information provided by the classification engine 52 or the spectrum expert 56, the returned data is called the spectrum event data , Which describes special events, such as detecting whether a specific signal type is active or inactive in the frequency band. The output of the classification engine 52 can be used by the spectrum expert 56 and the network expert 80 and other applications or processes.

There are many ways to format NSI messages to provide desired API functions and spectrum analysis functions. The following is an example of the message format, which is provided for completeness, but it should be understood that other API message formats can be used to provide the same type of interface between the application and the spectrum analysis function regarding activities in the frequency band, many of them Both types of signals can appear at the same time.

Ordinary message headers can be used by dialog control messages and informational messages. The common header, called smlStdHdr_t header, appears at the very beginning of all messages and provides some general identification information of the message. Examples of the general format of general headings are illustrated in the table below.

The indicative message starts with two headers: a normal header (smlStdHdr_t), followed by an information header (smlInfoHdr_t). The smlInfoHdr_t header provides special identification parameters for the indicative message:

A summary of all messages that can be sent via NSI is included in the table below. The numerical values in the following table correspond to the values used in the msgType subfield of the smlStdHrd_t field.

Examples of indicative messages, as implied above, are the NSI formatted versions of the output of the measurement engine 50 and classification engine 52 and optionally the spectrum expert 54 will be described.

The spectrum analyzer power versus frequency data SAGE20 will analyze the frequency band whose center frequency can be controlled. In addition, the bandwidth of the frequency band being analyzed can be controlled. For example, a part of the entire frequency band such as 20 MHz (narrowband mode) may be analyzed, or substantially the entire frequency band may be analyzed, such as 100 MHz (wideband mode). The selected frequency band is divided into multiple frequency "receivers" (such as 256 receivers), or adjacent sub-bands. For each receiver, and for each sampling interval, a report of the power detected in the receiver is made from the output of SAGE20, which is measured as dBm. The measurement engine 50 provides configuration parameters to the SAGE driver 15 and accumulates the output of the SAGE 20 (Figure 1).

Figure 22 (which will be described further below) shows a graph resulting from power measurements taken at a given time interval. In this diagram, the vertical bars do not represent different frequency receivers. Among the two zigzag lines shown in FIG. 22, the lower line represents a directed graph of data in a single snapshot of the spectrum at a given instant. It corresponds to the data in the single sapfListEntries field described below. However, the spectrum analysis message may contain multiple sapfListEntries fields; each such field corresponds to a single snapshot of the spectrum. The zigzag line above is constructed by a software application. It represents the peak value seen in the RF spectrum during the entire test period to the present moment.

An example of the structure of spectrum analyzer power versus frequency data is as follows.

In the second standard title, msgType is 46 to identify the message as an indicative message, and sessType is 10 (SM_L1_SESS_SAPF) to identify the data result from the spectrum analyzer power versus frequency test dialogue.

The following fields are standard information headers used for spectrum analyzer power versus frequency data.

The following field smlSapfMsgHdr_t describes the spectrum being monitored. While the message provides the center frequency and receiver bandwidth, it cannot provide the total bandwidth to be measured. This can be calculated as: low end=frqCenterkHz-128*binSize, high end=frqCenterkHz+128*binSize. The radio receiver used to monitor the bandwidth need not actually span the entire bandwidth. Therefore, partial frequency receivers at one end of the spectrum will generally exhibit zero (0) RF power.

For a single snapshot of the RF spectrum at an instant, the field sapfListEntries explained below contains the information of main interest, namely the power level (dBm) of the receiver at each frequency.

The frequency range corresponding to the receiver "N" is given, where N is from 0 to 255: LowFrequency[N]=smlSapfMsgHdr_t.frqCenterKHz+(N-128)*smlSapfMsgHdr_t.binSizeKHzHighFrequency[N]=smlSapfMsgHdr_t.frqHz-center127) *smlSapfMsgHdr_t.binSizeKHz spectrum analyzer statistics spectrum analyzer statistics/message provides statistical analysis of data in the spectrum.

A single message is established from a specified number of FFT cycles, where a single FFT cycle represents the output of a 256 frequency receiver like FFT. For example, 40,000 consecutive FFTs of the RF spectrum, performed in a total time of 1/10 second, are used to construct statistics for a single message.

Figure 23 shows the types of information that can be conveyed in the statistical data of the spectrum analyzer. The bottom line represents the average power during the sampling period (that is, during 40,000 FFT or 1/10 second). The upper line indicates the "absolute maximum power" in all the spectrum analyzer statistical messages received so far.

Examples of the entire structure of the spectrum analyzer statistics are:

The message header smlSaStatsMsgHdr_t field contains parameters describing the sampling process, the example of which is as follows.

For example, there are 256 consecutive statsBins, each with 4 subfields as shown in the following table. Each statsBin, together with its 4 sub-fields, contains statistical data for a specific bandwidth. To calculate the bandwidth of each frequency receiver, the following formula can be used: binWidth=smlSaStatsMsgHdr_t.bwKHz/256 The lower bandwidth and upper bandwidth of each receiver are given by the following formula: LowBandwidth[N]=smlSaStatsMsgHdr_t.centerFreqKHz+(( N-128)*binWidth)HighBandwidth[N]=smlSaStatsMsgHdr_t.centerFreqKHz+((N-127)*binWidth)

There are 10 consecutive activeBins, which record "peak" activity. The receiver can be seen as being indexed continuously, from 0 to 9. For each receiver, the value in the receiver should be interpreted as follows. At the Nth receiver, if the value in the receiver is X, then for (X/2)% of the time, there are N peaks in the RF spectrum during the sampling period, except for the special case of the 10th receiver below. In addition, it is called the receiver 9.

As mentioned above in conjunction with SAGE20, the peaks are spikes, or very short energy pulses in the RF spectrum. If the pulse lasts for a certain period of time (such as approximately 2.5 microseconds), SAGE20 will detect the peak value and the peak value will be included in the statistics describing the segment. This short peak is usually not included in the pulse data or pulse statistics. Also as mentioned above, if a series of continuous peaks are seen in a continuous period of time, all peaks are at the same frequency, the series-once it reaches a certain minimum time limit-it will be counted as a pulse. Figure 23 also shows how the number of peaks associated with activity in the frequency band can be displayed.

For testing purposes, the exact minimum duration of the pulse can be configured by the application, but a typical time can be 100 microseconds. Since SAGE20 can detect RF events as short as 2.5 microseconds, a typical pulse needs to continue to pass at least 40 FFT before being recognized as a pulse.

A pulse event data signal pulse is a continuous emission of RF energy in a specific bandwidth starting at a specific time. SAGE20 detects pulses in the radio frequency band, which meet certain configurable characteristics of bandwidth, center frequency, duration, and inter-pulse time (also called "pulse gap"). When SAGE20 detects a pulse with these characteristics, it outputs the pulse event data of the pulse, including: start time-measured from the first time SAGE starts to detect the pulse.

Duration-the life of the pulse.

Center frequency-The center frequency of the pulse.

Bandwidth-how wide the pulse is.

Power-average power (dBm).

The entire structure of the pulse event (PEVT) data/message is shown in the following table.

The information header field is a standard information header for pulse event messages.

There may be one or many pulse events in the message. Each case of the classPevts field below describes the characteristics of a pulse.

While the pulse histogram data may access information about individual pulses, it can also be used to work with statistical information about pulses detected and appearing in the frequency band at any time. This information is provided by pulse histogram data. The pulse histogram tracks the following distribution: pulse duration (percentage of pulses with short, middle, and long duration); time slots between pulses (with short, middle, and long time slots between them) Percentage of pulse); pulse bandwidth; pulse frequency; and pulse power.

Figure 24 shows a graphical display of an exemplary pulse histogram.

The entire structure of the pulse histogram data is shown in the table below.

The PhistMsgHdr field describes the spectrum being monitored and some other parameters of the entire sampling process.

The pulse duration histogram field contains a series of bytes. Each data byte or receiver-in turn-indicates the percentage of pulses that fall within a given duration (multiplied by 2). The following table categorizes the data into smallBins, mediumBins, and largeBins, and is only an example of how to track the pulse duration.

The first receiver (receiver 0) contains the percentage (×2) of pulses between 0 microseconds and 9 microseconds. The second receiver (receiver 1) contains the percentage of pulses (×2) between 10 microseconds and 19 microseconds in the duration. Each of these "receivers" is 10 microseconds wide. This can continue to the 20th receiver (receiver 19), which has a value of pulse percentage (×2) between 190 and 199 microseconds.

The next 26 receivers are similar, except they are wider. In particular, they are 50 microseconds wide. The receiver 20 has a value indicating that the pulse percentage (×2) is between 200 microseconds and 249 microseconds. Again, there are 26 receivers 50 microseconds wide. The receiver 45 has a value indicating that the pulse percentage (×2) is between 1450 microseconds and 1499 microseconds.

Each of the last 27 receiver groups indicates a wider pulse percentage (×2), in particular, 500 microseconds wide. The receiver 46 includes pulses whose duration is between 1500 microseconds and 1999 microseconds. The receiver 72 includes pulses whose duration is between 14499 microseconds and 14999 microseconds.

Pulse duration histogram receiver

The pulse gap histogram indicates the percentage of the gap between pulses (×2), where the duration of the gap falls within a given time range. The receiver does not reflect when the gap appears, they reflect how long the gap is. The gap is measured between the beginning of one pulse and the beginning of the next pulse. This is because the beginning of the pulse tends to be drawn sharply, while the pulse may gradually weaken. For example, suppose there are 20 gaps in total between pulses. Among these 20 gaps, only two gaps have a duration between 10 microseconds and 19 microseconds. The first gap, which lasted 12 microseconds, appeared at 15.324 seconds. The second gap, which lasted 15 microseconds, appeared at 200.758 seconds. Both gaps are recorded in the second receiver (receiver 1). Since the two gaps reflect 10% of all recorded gaps, the value in the second receiver (receiver 1) will be 2×10%=20 (because all percentages are multiplied by 2).

Pulse Gap Histogram Receiver

For the pulse bandwidth histogram, each data receiver reflects a gradually wider bandwidth. For example, if the first receiver represents pulses with a bandwidth from 0 to 9.999 kHz, the second receiver represents pulses from 10 to 19.999 kHz, the third receiver pulses are from 20 to 29.999 kHz wide, and so on. The value stored in the receiver is the percentage of pulses (×2) that have a bandwidth within the specified range. For example, assume that the size of each receiver is 80 kHz. It is also assumed that SAGE20 detects 1000 pulses and has 256 frequency receivers. The pulse has a bandwidth between 0 and 20480kHz. As another example, assume that SAGE20 detects 65 pulses, each with a pulse between 400 and 480 kHz. Then, 6.5% of the pulses fall within the sixth bandwidth range, then the sixth receiver (receiver 5) will have a value of 2×6.5%=13.

Bandwidth receivers can have exactly the same width. For example, if the first receiver is 80 kHz wide (and includes data of pulses with a bandwidth from 0 to 79.999 kHz), then all consecutive receivers will be 80 kHz wide. The second receiver includes pulses from 80 to 159.999 kHz; the 256th receiver is also 80 kHz wide and includes pulses with a bandwidth from 20400 to 20479.999 kHz.

Pulse bandwidth histogram receiver

For the pulse center frequency histogram, each data receiver reflects a frequency range. The value stored in the receiver is multiplied by the percentage of pulses whose center frequency falls within the specified frequency range.

All frequency receivers can be exactly the same width. However, generally speaking, the lowest receiver (byte 0) does not start with a frequency of 0 Hz. Recall that the pulse histogram message header (PhistMsgHdr_t) has a subfield histCenterFreqkHz, which is measured in kHz. This field defines the center frequency of the pulse center frequency histogram.

The following formula gives the actual frequency range covered by each receiver of the histogram, which also indicates the low and high frequencies of the range. The number N is the number of receivers, where the number of receivers is counted from freqBins 0 to freqBins 255: Low Frequ.(bin N)=histCenterFreqkHz-(128*binSizekHz)+(N*binSizekHz)High Frequ.(bin N)=histCenterFreqkHz- (128*binSizekHz)+((N+1)*binSizekHz))

Assume that the size of each receiver is 100kHz and the bandwidth is 2.4GHz. In fact, the frequency being monitored is in the range from 2,387,200kHz to 2,412,800kHz. It is also assumed that SAGE20 detects 1000 pulses and the center frequency of 80 pulses is in the range from 2,387,600 kHz to 2,387,699 kHz. Then 8% of the pulses fall within the fifth bandwidth range, then the receiver 4 will have a value of 2×8%=16.

The field structure of the pulse center frequency histogram is shown in the following table.

Pulse center frequency histogram receiver

For the pulse power histogram, each receiver reflects a certain power range, measured in dBm. The value of each receiver reflects the percentage (×2) of those pulses whose power level falls within the specified range.

Pulse power histogram receiver

Snapshot data Snapshot data, unlike other data provided by NSI, is not based on data analysis by SAGE or software. Instead, this data provides raw data from the ADC, which precedes SAGE and converts the received analog signal into a digital signal.

The raw ADC data can be expressed in n-bit I/Q format, where "n" is specified by'bitsPerSample'. Snapshot sampling can be used for position measurement, or for detailed pulse classification (such as identifying the exact model of the device). The size of the sampling data contained in'snapshotSamples' is usually 8k bytes. The entire structure of the message is shown in the following table.

An example of the smSnapshotMsg_t field of the snapshot message is defined as follows.

Spectrum event data (such as monitoring signal activity) The msgType of the spectrum event data is 46, and the sessType is 14 (SM_L1_SESS_EVENT). The format of the smEventMsg_t spectrum event message field is described in the following table.

An example of the manner in which the spectrum event message can be displayed is shown in Figures 16-20 and will be described below.

The software and system communicate to the NSI to request data from the service on the other side of the NSI, which uses the dialogue control message mentioned above. An example of the format of the dialog control message is as follows. After the standard title is the information unit. The information unit is a data structure with several parts, as described in the following table:

Typical information units provide data such as SAGE configuration data, radio configuration data, and service-specific data (such as pulse data, spectrum data, etc.). Examples of NSI information elements are provided in the following table: Information element name infoElementType Description (decimal) IE_RETURN_CODE 1 Activity completion status return code information IE_SESSION_CFG 2 Dialogue priority and startup configuration IE_SAGE_CFG 3 Common SAGE configuration for multiple services IE_RADIO_CFG 4 Common radio configuration IE_COPY_CFG 5 Request a copy of any data used for the service, with optional configuration update notification.

IE_SAPF_CFG 6 Spectrum analyzer power versus frequency configuration IE_PD_CFG 7 Pulse detector configuration IE_SA_STATS_CFG 8 Spectrum analyzer statistics configuration IE_PHIST_CFG 9 PHIST service configuration IE_PEVT_CFG 10 PEVT service configuration IE_SNAP_CFG 12 Snap buffer configuration IE_VENDOR_configuration CFGCTRL 13 Vendor special information Message flow control IE_VERSION 16 The NSI version used has an advantage in using information elements in NSI dialog control messages. The format of the dialog control message can be modified or expanded at any time. As long as the technology is further developed, it does not require modification of the existing software or system using NSI. In other words, enhancing the message will not destroy the old program.

In traditional software design, network management software is coded to control the expectations of a special data structure for each dialog message. Whenever the dialog control message is changed or enhanced, the code of the network management software will be required to be changed, and the code must be recompiled.

However, with dialog control messages, this will no longer be necessary. The dialog control message is processed as follows: 1. Request the software or system to read the message header and determine what kind of message it is receiving.

2. The software developer knows what kind of information unit will follow the title field based on the description document. Design decisions are made to determine what kind of actions the software or system will take in response to those information units.

3. In the code itself, after reading the header field, the software loops through the information unit. Only for the information unit of interest-which can be marked in each information unit by the infoElementType field-the software takes appropriate action.

Additional information elements can be added to part of the dialog control message. However, during the "loop" process, the software is requested to ignore any information elements that are not of interest, so other information elements in the control message will not require any changes to the software code. Of course, one may want to upgrade the software program to take advantage of another type of information; but again, the existing software continues to work until the new software is in place.

This benefit is useful in two ways. For example, when sending a message to NSI, a software program can send information units that fine-tune the behavior of SAGE. however. Normally, the default working mode of SAGE is satisfactory and does not need to be changed. Rather than having to send an information element containing SAGE's redundant, default configuration data, the information element can simply be omitted.

The handshake protocol can be used to set up, start and terminate the dialogue between the application and the NSI. There are a variety of technologies in the prior art that provide this function. For example, all tests are started by sending the smlStdHdr_t field. In addition, optional information elements can follow. The NSI responds with the following message, which indicates that the test has started successfully, has been rejected, or the test is pending (the test is queued after other requests for the same service). The four possible dialog control response messages are started, pending, rejected, and stopped.

All start messages can have the following structure: 1. The required smlStdHdr_t field has the msgType value of SESS_START_REQ (40) and the value of sessType to indicate that the test will be executed. For example, to start a pulse event test, a sessType value of 12 is used, a name histogram test is to be started, a sessType value of 13 is used, a spectrum analyzer power versus frequency test is to be started, a sessType value of 10 is used, and so on.

2. Optional common dialog configuration information unit. This configures all possible parameters of interest for testing, as described below.

3. For pulse event testing only, the optional information unit is equipped with a pulse detector.

4. Optional information unit configuration SAGE and radio.

5. Optional, vendor's special information unit, usually (but not required) for further configuration of the radio.

6. Optional dialogue type special information unit with configuration information for specific tests (PEVT, PHIST, SAPF, etc.).

When starting the test, the general/common dialog configuration unit IE_Session_CFG is optional, that is, it has SESS_START_REQ. If it is not sent, the default value is used.

Before NSI can start any tests, the radio is configured to the initial bandwidth (or one of 2.4 GHz or 5 GHz). Similarly, at least one (if not more) of SAGE's four pulse detectors needs to be configured at least once before many pulse test services can be run. These services include pulse events, pulse histograms, snapshot data, and spectrum analyzer power versus frequency (but only if the test will be triggered by a pulse event). Once the pulse detectors are configured, they can be left in their initial configuration for subsequent testing, although the application can reconfigure them.

The radio configuration unit IE_Radio_CFG is described in the following table. It is used to fine-tune the performance of the radio. If the information element is not sent as part of the message, the radio is configured as a default value.

The SAGE configuration information unit IE_SAGE_CFG is optional. It fine-tunes the performance of SAGE20. If the information unit is not sent as part of the message, SAGE20 is configured as a default value. Examples of SAGE configuration units are presented below.

The IE_VENDOR_CFG information unit contains vendor-specific configuration information. Usually, this is a special configuration relative to the specific radio used.

NSI provides a pulse detector configuration unit (IE_PD_CFG), which is used to configure the pulse detector. This unit must be used when the pulse detector is first configured. It is also used if and when the pulse detector is reconfigured (which may rarely happen). The optional pulse event test configuration unit (IE_PEVT_CFG) is shown in the following table. If the configuration unit is not sent, the default value is used for the test.

Configuring the pulse detector includes selecting which pulse detector to use for the test. It also includes providing parameters that indicate the type of signal pulse (for example, the range of signal power, pulse duration, name center frequency, etc.) that will actually be interpreted as pulses. There are various options when it comes to pulse detectors: use existing pulse detector configurations for service.

Allocate detectors that are not currently in use.

Reconfigure the existing pulse detector.

Releasing the pulse detector makes it available for other conversations.

Whether it is the first configuration of the pulse detector or the reconfiguration of the detector before using it, the header field will first be sent with a specific msgType. After that is the pulse detector configuration unit, IE_PD_CFG, as described in the following table. (Other information elements can also be included in the message.) The pulse detector chooses to use the PD_ID subfield value 0-3. These do not correspond to physical pulse detectors; instead, they are a logical reference to the pulse detectors used by the transfer connection that supports the conversation.

The field bwThreshDbm uses a signed dBm value, which helps determine which RF signal will be counted as a pulse. The pulse is defined by a series of time-adjacent and bandwidth-adjacent "peaks" or short-lived spikes, which determine the full bandwidth of the pulse (hence the term "bandwidth limit"). A "peak layer" is established to determine which spike of radio energy is qualified as a valid "peak". The energy spikes below the "peak layer" are not eligible, while those above the "peak layer" are eligible. The bwThreshDbm parameter determines the "peak layer" based on whether the'bwThreshDbm' is positive or negative: If bwThreshDbm is negative (eg -65dBm), the peak layer has the same value as bwThreshDbm.

If bwThreshDbm is positive (such as 24dBm), the peak layer is dynamically determined based on the current noise layer: peak layer dBm=noise layer dBm+bwThreshDbm based on the noise layer mechanism (bwThreshDbm is positive) is almost exclusively used because it responds well to Changes in the radio spectrum environment.

There may be a pre-defined pulse detection configuration, which is shown in the table below, to detect certain types of signal pulses.

IE_PD_CFG Summary name Summary description/notes configProfile field value 1 ShortPulse1 Capture short pulse frequency hopping device, including Bluetooth headsets and many cordless phones.

2 LongPulse1 captures long pulses output by microwave ovens and television transmissions (baby monitors, surveillance cameras, X-10 cameras, etc.).

The short pulse summary below is suitable for detecting short pulse frequency jumpers, such as BluetoothTM headsets and many cordless phones.

IE_PD_CFG field Summary field value Comment name bwMinkHz 300 pulse bandwidth from 300kHz to 4MHz, with bwMaxkHz 4000 4.5MHz holding value bwHoldkHz 4500bwThreshDbm 24 dBm defined by pulse, above the noise floor.

cfreqMinkHz 6000 6MHz-94MHz center frequency, with 2MHzcfreqMaxkHz 94000 holding value.

cfreqHoldkHz 2000durMinUsecs 250 Pulse duration from 250 to 2000μs.

durMaxUsecs 2000durMaxTermFlag 1 If it is equal to or longer than the maximum duration of 2000 μs, the pulse is discarded.

The pulse power of pwrMinDbm -85 ranges from -85 to 0 dBm, with a holding value of 15 dBm pwrMaxDbm 0.

The long pulse summary below pwrHoldDbm 15 is suitable for detecting long pulses output by microwave ovens and television transmissions (baby monitors, surveillance cameras, X-10 cameras, etc.).

IE_PD_CFG field name Summary field value Note that bwMinkHz 300 pulse bandwidth from 300kHz to 20MHz, with bwMaxkHz 20000 8MHz holding value bwHoldkHz 8000bwThreshDbm 24 pulse defined 24dBm, above the noise floor.

cfreqMinkHz 6000 6MHz-94MHz center frequency, with 8MHzcfreqMaxkHz 94000 hold value.

cfreqHoldkHz 8000durMinUsecs 2800 Pulse duration from 2800 to 8000μs

durMaxUsecs 8000durMaxTermFlag 0 Do not give up long pulses pwrMinDbm -70 Pulse power from -70 to 0 dBm, with a hold value of 20 dBm pwrMaxDbm 0 pwrHoldDbm 20 Before the pulse histogram test is run for the first time, the pulse detector does not need to be configured. As mentioned above, this is done by running the pulse event test for the first time. The dialog control message is sent, which contains a header field with a sessType value of "13". The following is an optional information unit, as shown in the following table, which details the optional pulse histogram test configuration unit (IE_PHIST_CFG). If it is not sent, the default value (as shown in the table) is used.

The spectrum analyzer power versus frequency test starts by sending a dialog control message, which contains a header field with a sessType value of "10"; thereafter are optional information elements, as shown below.

The spectrum analyzer statistical test starts by sending a dialog control message, which contains a header field with a sessType value of "11". Optional information elements follow, as described below.

The field pwrThreshDbm takes a signed value, which helps determine the minimum power level for "duty cycle" and "peak count". The pwrThreshDbm parameter determines the "layer", or the minimum energy level of these measurements, based on whether pwrThreshDbm is positive or negative: if pwrThreshDbm is negative (eg -65dBm), the layer is the same as the value of pwrThreshDbm.

If pwrThreshDbm is positive (for example: 24dBm), the layer is dynamically determined based on the current noise layer: power layer dBm=noise layer dBm+pwrThreshDbm. The noise floor-based mechanism (pwrThreshDbm is positive) is almost exclusively used because it responds well to changes in the radio spectrum environment.

The spectrum event data test starts by sending a message, which contains a header field with a sessType value of "14".

The snapshot message test starts by sending a message, which contains a header field with a sessType value of "17", followed by an optional configuration unit. The optional snapshot message configuration unit (IE_SNAP_CFG) follows. If it is not sent, the default value is used for testing.

By specifying which pulse detector is used to trigger the snap capture, it is possible to control which type of signal pulse is detected to trigger the raw ADC data capture.

The NSI can answer the test start message to notify the requesting software application of the test status, and prioritize the application capability to transmit data for the requested test. It is also possible to stop a test that has been requested. The following table summarizes the dialog control messages that can be sent via NSI.

An example of how NSI can be used to configure and obtain data from the SAGE pulse detector is shown in Figure 13. In the chart, the solid line is used for a unified message, and the dotted line indicates the title, information unit, and indicative message that make up a single message sent. Step 6000 represents sending a start message to the software application of NSI. The message includes a message header with a specific msgType value, which indicates that this is a start message and the sessType value indicates that this is a pulse event test. If it is the first message request sent, the start message includes the IE_Radio_CFG unit or the IE_VENDOR_CFG unit. Two IE_PD_CFG units are sent to configure pulse detector 0 to detect short pulses, and to pulse detector 1 to detect long pulses. The pulse event information unit IE_PEVT_CFG has been sent to indicate which configured pulse detector is used. Applicable data from SAGE is generated and made available to NSI. In step 6010, the NSI replies with a message confirming that the service has started and the service status is in progress. In step 6020, a series of indicative messages are sent with data. Each message includes indicating that it is an indicative message and includes one or more ClassPevt fields, which store the actual data, which describes the measurement characteristics of the pulse detected within the configured parameters. In step 6030, other indicative messages are sent.

Exemplary spectrum management situation Scenario 1: Network monitoring, reporting, and action reporting are the simplest and most powerful applications of spectrum management. In this example, the report is used to help find the presence of "fraud" or unwanted noise sources.

Example 1: Company WLAN environment measurement: Each AP measures its environment. If the AP detects an unexpected noise signal, it forwards the spectrum and sampling data to the WLAN management server, such as the server 1055 in FIG. 1.

Classification: In the server, the signals are classified based on known signal pulse information. The location of the signal source is determined.

Policy: The server issues a warning to the WLAN administrator.

"The interference signal was detected and identified as a Panasonic cordless phone in room 400." Action: The server sends a report (such as e-mail, screen pop-up window, etc.) to the administrator, including spectrum analysis graphs and graphical location information. Recommendations for correct action can be provided to the network administrator.

Example 2: Home WLAN environment measurement and classification: similar to the above, but in this case, AP and STA are used for measurement, and the classification software runs on the PC connected to the STA.

Policy: Users are notified via simple language messages on their PCs, but the reaction is automatic. "The cordless phone is causing interference. Click OK to call the noise resolution wizard." The "noise resolution wizard" can be a spectrum action, which will remove the noise effect on the device, such as by moving to another channel. Or, automatically take the correct action and display the event summary information to the user.

14 and 15 show flowcharts (modified from the flowchart shown in FIG. 5) that can be used to implement the situation 1 situation. The user assistance tool can be provided through a software program executed on the WLAN AP or STA. In the case of STA, the tool may automatically perform spectrum management actions or controls. In the case of AP, where the network administrator has monitoring and other control privileges, the tool may not be automatic, but it gives the network administrator user a choice to take action. Of course, non-automatic tools can be located on devices such as STA.

Figure 14 is a flowchart of the automatic version of the tool, and Figure 15 is a flowchart of the non-automatic version. The spectrum sampling step 2000, the signal classification step 2010, and the spectrum policy execution step 2020 are similar to the steps with the same reference numbers described above in conjunction with FIG. 5. In Figure 14, after the signal classification step 2010, in step 2015, based on the output of the signal classification step, if a certain type of signal or interference is detected, an alarm message is displayed or notified to the user (the user on the computer) ). In step 2020, based on the output of the signal classification step, the spectrum policy is automatically executed. In step 2025, the spectrum event summary information is displayed or notified to the user. For example, spectrum action or control can be the implementation of interference avoidance procedures.

Referring to FIG. 15, the steps 2000, 2010, and 2015 of spectrum sampling, signal classification, and display alarm are the same as those described above in conjunction with FIG. 14. However, in FIG. 15, after the alarm is displayed, step 2016 is called to display event information with suggested actions. In step 2017, the user can select the spectrum policy to be executed or go to the "policy guide" to set the policy for this type of alarm and the action to be taken. An example of a policy guide is information, which simplifies the task of generating a spectrum policy by asking a user (or administrator) a set of questions. Based on this information, the policy guide generates spectrum policies and associated actions suitable for those parameters. The policy guide is described in detail below. The action suggested in step 2017 may be different from the suggestion to change the operating parameters of the device or network, as described below in conjunction with FIG. 26.

Figures 16-25 show the output of an exemplary graphical user interface (GUI) application for connecting the spectrum activity and management information interface to/from the user. The GUI provides the means to monitor, configure and analyze the various components of the spectrum management system. It is connected to other components of the spectrum management system via NSI, as described above in conjunction with Figure 6.

GUI applications can be written as Java(R) and can use sockets on TCP to communicate spectrum activity information associated with specific radio communication devices. Once the communication is established, the application will be generated, which waits on the port to detect spectrum activity information messages from the source device. As the information arrives through the socket, it is processed and displayed to the various components that are detecting these messages. The message dispatcher dispatches the processed messages to the appropriate display panel. All messages will also be saved in the log file located in the directory specified by the user, in PE.ini for the key PE_LOGS. The GUI application is fed back with data from the measurement engine and classification engine, as described above in conjunction with Figure 6.

The GUI includes several sub-parts: fault management. Provide means to detect, receive and provide fault information. The fault message describes the cause of the fault.

Configuration management. Provide a means to configure the spectrum composition. The spectrum consultant provides configuration-related information and guides users through the configuration process.

Performance management. Monitor the throughput of communication protocols, and collect and display statistical information indicating spectrum utilization.

Incident management. Provides means to monitor different spectrum events and displays them in the form of graphs and histograms.

Figure 16 shows how an alarm can be generated when interference is detected, where the alarm is displayed in the icon of the GUI bar. The user clicks on the icon to get more information and arrive at the spectrum management control window in Figure 17. In the spectrum management tabulation, there may be an icon indicating the signal type. In addition, there may be a sub-window that displays the "rated capacity" of the frequency band. The rated capacity can be derived from the "quality" measurement reported as the spectrum analyzer statistics above, and is a qualitative estimate of the carrying capacity of the entire frequency band.

By clicking the "Event Log" button on the spectrum management control window in Fig. 17, the event log screen in Fig. 18 is displayed. The event log displays event information in tabular form. Each event has associated fields including event message, event data and time, event timestamp, event ID and event source ID, similar to the fields of the NSI spectrum event message mentioned above:

The alarm level, ranging from low to high to severe, indicates how much interference the event can cause in 802.11 communications.

Event types include "interfering signal", "information" and "error".

A special message describing the event.

The date and time of the event. This is the date and time populated by the application based on the computer's internal clock.

A timestamp in seconds and microseconds, which indicates the time when the event occurred, and is counted from the beginning of the first test. This data is provided by the measurement engine.

ID indicates the type of device, and the following table provides a partial list of IDs.

15-bit device ID (bits 4, 3, and 2 are shown, with corresponding decimal 1: on/off value [consider empty 1 bit]) 2 (001_)-microwave oven 1 = on 4 (010_)-GN Netcom cordless phone 0 = off 6 (011_)-Bluetooth headset 8 (100_)-baby monitor For example, the display value is 7, which is the same as ([011][1]), meaning that the Bluetooth headset is turned on. 8([100][0]) means that the baby monitor has just been turned off.

The source ID identifies the target source. This parameter is important when more than one source feeds data to the application.

More detailed information about a specific event is displayed, which is achieved by clicking on the event line to open the dialog. The dialog contains detailed information about the event in the form of a text area containing a description of the event and a text area containing the details of the event. Figures 19 and 20 show examples of detailed event dialogs. Figure 19 shows exemplary spectrum event summary information after performing actions in accordance with the spectrum policy. The detailed event information indicates that the action has been automatically taken according to a process similar to that shown in FIG. 14. FIG. 20 shows event information, in which actions are not taken automatically, but suggest how the user can avoid interference from another device, according to a process similar to that shown in FIG. 15.

Figure 21 shows the display of statistical information, such as statistical information of a specific communication protocol, which may include enhanced statistics.

Figures 22-25 show exemplary display screens in a graphics panel for displaying spectral activity information. The graphics panel includes graphics on the right side of the display screen and drawing types on the tree diagram on the left. As long as the "Start" button is clicked and the data is available on the socket, the spectrum analysis graph will be drawn. If you press the "Stop" button, the drawing action is prohibited, and the spectrum analysis graph will no longer be updated. Spectrum activity information is displayed on the spectrum analysis graph, pulse histogram, and pulse graph.

The spectrum analysis diagram of FIG. 22 includes spectrum analyzer power versus frequency information, as described above. The spectrum analyzer statistical information is shown in Figure 23 and includes a spectrum analyzer statistical graph, a duty cycle graph, and a peak number bar graph. The SA statistic graph shows the statistical data on the frequency spectrum. It is based on spectrum messages, where a single message is established from a certain number of consecutive FFT cycles. The first line represents the average power during the sampling period. The second line indicates "the maximum power per single sampling period". The third line represents the "absolute maximum power" of all messages received so far. The duty cycle graph represents the percentage of time that the power in the RF spectrum is above the specified limit for a given frequency.

Figure 24 shows an exemplary pulse histogram for center frequency, bandwidth, pulse duration, pulse gap, pulse power, and pulse count. The following types of graphs can be used for observation: The center frequency represents the distribution of the center frequency of the pulse. The graph spans a bandwidth of 100MHz. The actual center frequency is determined by combining the center frequency shown in the figure with the entire RF center frequency (2.4 GHz).

Bandwidth represents the bandwidth distribution of the pulse.

The pulse duration represents the duration distribution of the pulse.

The pulse gap represents the distribution of gap time.

The pulse power indicates the power distribution of the pulse.

The pulse count indicates the number of pulse events counted per sampling interval.

FIG. 25 shows a pulse diagram of each pulse detected in the frequency band. When the "Capture" button is selected, the GUI application will capture the pulses and display them on the pulse graph. Each pulse is defined as three dimensions and presents a single point.

FIG. 26 is a flowchart describing another example of the spectrum management support tool process 5000, which can be used to debug certain spectrum conditions on a client device. Process 5000 can be initiated by user instructions to check the performance behavior of the device as required, through an appropriate user interface application, or in response to detecting performance degradation, as described below. At the beginning, in step 5010, the device monitors bit error rate (BER) or PER or other spectrum activity information. If the spectrum activity is high or the BER or PER is high, it is marked in step 5020, and in step 5030, the device can calculate the signal-to-interference and noise ratio (SINR) and perform additional spectrum analysis. Based on the calculated information, the device may determine the reason for the degradation in step 5040 either because of interference or because of low signal level.

If the cause is determined to be a low signal level, a series of user recommendations are made. Once the user performs an action, further analysis is made to see if the signal level has returned to a sufficient level. As in step 5050, the device user is notified that the signal is weak. In step 5060, local actions are suggested to the user to improve the signal level. If it is determined in step 5070 that the adjusted signal level has returned to a sufficient condition, the process is terminated. Steps 5060 and 5070 can be repeated multiple times (m iterations). If those user adjustments do not contribute to the signal level, then in step 5080, it is recommended to take additional actions at other devices on the link, such as the AP. These recommended actions may include adjusting the antenna at the AP or the location of the AP. In step 5090, it is determined again whether the signal level at the device is at a sufficient level. If not, the process continues to step 5100, where the user is notified that a reliable connection cannot be supported, and additional suggestions may include reducing or removing obstacles between the two devices, and reducing the interval/distance between the two devices .

If the cause is determined to be interference in step 5040, a series of steps are executed. First, in step 5110, the interference is classified, such as by signal type. In addition, if it is determined in step 5120 that the interference is a type that can be mitigated using interference mitigation techniques, the device automatically executes those techniques (which may include cooperation with other devices such as APs or actions of other devices). Examples of interference mitigation techniques are as described above. If the interference is of a type that cannot be automatically mitigated, various other actions are suggested to the user. In step 5140, the user is notified that the interference condition has been detected. In step 5150, if the interference is of a known type, several actions for manual handling of the interference are suggested. In step 5160, if the interference is caused by another IEEE 802.11 network on the same channel, the recommended user action is to adjust the AP of the user network to a clean/unused channel. In step 5170, if the interference is caused by the IEEE802.11 network on the adjacent channel, the suggested user actions may include adjusting the AP to a channel away from another network's channel, adjusting the physical location of the interfering network, or adjusting the user's network The location of the AP. In step 5180, if the interference is caused by the microwave oven, the suggested user actions may include adjusting the AP of the user network to a cleaner channel, adjusting the position of the AP in the user network, and adjusting the user network for better interoperability. The fragmentation limit of the AP, or increase the distance between the users device and the microwave oven.

Steps 5190 and 5200 also show another situation. In step 5190, it is the case where the interference is determined to be a BluetoothTM device. Notify the user that the BluetoothTM device (synchronous or asynchronous operation) is the cause of the interference, and suggested user actions include increasing the interval between the user's device and the interfering device. In step 5200, if the interference is caused by the cordless phone, it is recommended that the user increase the distance between the user equipment and the cordless phone base station equipment, such as at least 5 m away from the user equipment or the AP in the user network.

If it is determined in step 5150 that the interference is unknown interference, then in step 5210, the suggested user actions may include checking for recently acquired or configured wireless devices that may cause interference, increasing the interval/distance between devices with incompatible networks, and notifying the user Various potential network incompatibility.

Figure 26 shows the various steps for informing the user with information. There are many mechanisms available to notify the user, including the visual display of information, such as displaying text on a display, announcing the information with a sound-synthesized auditory report, converting the information into audiovisual fragments, and displaying one or the other representing the information to be converted Multiple icons or symbols, etc. Examples of these displays are shown in Figure 16-20.

Scenario 2: Secondary use Secondary use refers to allowing equipment to use "idle", licensed spectrum. This is not just the future situation, in Europe, it already exists in the 802.11a situation. At 5GHz, the radar is regarded as the first user, and 802.11a is the second user. The current implementation simply stalls the network and looks for RSSI.

Simple RSSI measurement and DFS are not enough to enable secondary use. The "pecking sequence" between the first-level user and the second-level user requires different responses to noise depending on whether it is from the first-level or another second-level user. By detecting and classifying the signal, it makes a distinction between radar and other spectrum users based on RSSI technology that are faster and have fewer false detections, and consider choosing a new channel that is not affected by the radar.

In order to become a secondary user, the following things will happen: Measurement: periodically suspend to check the existence of the primary user.

Classification: distinguish first-level users from other second-level users.

Policy: Determine how long to perform the measurement and how many times, and how to respond when a first-level user is detected.

Scenario 3: A high-QoS 802.11a network in the presence of interfering signals or noise carries video streams. Background noise causes the problem of packet loss. Assume that APs in the network have multi-channel capabilities.

The best solution is achieved by measuring and classifying noise and using different policies based on the interfering signal. Referring to Fig. 27, a first scenario (case 1) is shown, where the noise is background hum, which is consistently present. The policy associated with this situation can use spatial processing algorithms to improve the link tolerance between the two devices. Examples of spatial processing algorithms are disclosed in the following pending U.S. applications: Application 10/174,728, filed on June 19, 2002, entitled "System and Method for Antenna Diversity Using Joint Maximum Ratio Combination"; June 2002 Application No. 10/174,689 filed on July 19, entitled "System and method for antenna diversity combining with equal power joints with maximum ratio"; and filed on July 18, 2002, entitled "Using time-domain signal processing System and method for the maximum ratio of joints to be merged" application 10/064,482.

In case 2, the interference is caused by a slow frequency hopping signal. The policy associated with this situation should use redundant channels to reduce the packet error rate.

In case 3, the interference is caused by a fast frequency hopping signal. The policy associated with this situation should use ratio codes across wider bandwidth channels to reduce the packet error rate.

Case 4: In a dense environment, it is found that the channel is sparsely used, and it is enough to simply search for a channel without interference. This is the easier situation.

But in a intensive use environment, the device can easily find that no interference-free channel is available.

In this case, one approach is to accept the channel with the "lowest" interference. If the new network must compete with another spectrum user, the best channel selection algorithm should be considered, for example: What is the priority of each network? Which network can the new network work with? For example, the IEEE 802.11 specification is designed to allow two 802.11 networks to reasonably share channels, thereby allowing each network to allocate a portion of the bandwidth. Making such decisions in the best way requires measurement, classification, and policy capabilities.

Case 5: The 802.11BluetoothTM signal in the case of Bluetooth is a frequency hopping signal. Therefore, it can cause periodic interference to APs in an IEEE 802.11 network using a fixed channel. In order to work with BluetoothTM, the IEEE802.11 network can perform measurement and classification to determine the existence of the BluetoothTM network.

Once Bluetooth is detected, several policies can be invoked: Policy 1a: If Bluetooth is using synchronous (SCO) communication, determine the timing of any 802.11QoS packets so that they appear between the timing of SCO packets. Several techniques are described in the pending patent applications mentioned above.

Policy 1b: If Bluetooth is using SCO communication, do not transmit during the SCO period.

Policy 2: Try to minimize the impact of receiving interference from Bluetooth by adjusting the easy-to-handle antenna.

Policy 3: In response to packet errors, do not change to a lower data rate. This may just make the problem worse. Experiments have shown that when exposed to the interference of Bluetooth frequency hopping signals, IEEE802.11b devices detect an "increased error rate" and respond by reducing their wireless broadcast transmission rate. Reducing its transmission rate is not necessarily helpful, and when an IEEE802.11b device continues to detect an unacceptably high (or potentially higher) error rate, it further reduces its data rate. This action is compatible with the IEEE802.11 standard, but it is also obviously not wise enough. By reducing the wireless broadcast data rate and increasing the duration of the information packet, the device effectively increases the time it is exposed to the frequency hopping device. The main part of the standard can improve the coexistence between open standard protocols in these types of situations, and by arranging the cognitive spectrum management techniques described here, this type of performance degradation can be minimized or even avoided.

Scenario 6: Bluetooth in 802.11 In order to work with 802.11, the Bluetooth network should perform measurement and classification to determine the existence of the 802.11 network. Once the 802.11 network has been detected, the policy can be invoked: Policy 1: There is no adaptive jump device supported for the BluetoothTM network. In this case, the Bluetooth network should be free by making the storage slot where 802.11 data or ACK will appear. And to avoid interference to 802.11. An example of this technique is disclosed in US Patent Publication No. 20020061031. When the "real" data network is the current network, the BluetoothTM network only wants to use this algorithm, which is the opposite of the noise source. This also proves the advantages of signal classification over simple RSSI measurement.

Policy 2: Supported adaptive hopping device for BluetoothTM network In this case, the Bluetooth network should remove the frequency hopping signal entering the 802.11 frequency band. A well-known proposal in 802.15.2 suggests using lost packets to confirm the presence of foreigners. This is not always effective. The interference is not always symmetrical (ie, a Bluetooth network may cause problems that another network has, but the other network does not interfere with the Bluetooth network). In addition, this requires that packets be lost before another network is detected.

Case 7: A DRA dynamic rate adaptation (DRA) device with a frequency hopping signal uses more spectrum when it is available, and uses less spectrum when it is not available. For example, the increased spectrum can be used for higher data rates, QoS, etc. DRA can be implemented as a new protocol (eg, a "bed of needle" Orthogonal Frequency Division Multiplexing system), or by aggregating multiple standard channels.

However, the question arises, that is, how should DRA deal with frequency hopping protocols. One solution is that, in order to handle the frequency hopping signal gracefully, the DRA equipment must be measured and classified to detect the frequency hopping device. Once the frequency hopper has been classified, the policy can be invoked. An exemplary situation is as follows: Policy 1: If a frequency hopping signal is detected, limit the DRA to 50% of the frequency band, so that the frequency hopping network can still work.

Policy 2: If the frequency hopping network adjusts its hopping device adaptively (observed by measurement), DRA can be allowed to use 75% of the frequency band.

Scenario 8: Specific device policy In a consumer environment, the user may want to define the priority between specific devices. For example, at home, the user may want to establish a "pecking sequence" between cordless phones, streaming video, WLAN, and so on. In order to consider specific equipment-level policies, it will be necessary for equipment to measure and classify other operating equipment. Devices can be made to recognize each other by directly exchanging classification information or by using "training" methods similar to universal remote control. Unapproved equipment will be handled using various policies: in an office environment, report immediately.

In the family environment, this situation is considered low priority.

Scenario 9: Certain environmental policies will depend on environmental information such as location, time, etc.

These policies may not be updatable because they rely heavily on the wishes of users.

Network selection: In a home environment, always use a specific basic service station identifier, such as BSSID 7.

In an office environment, use the lowest CCA between BSSID 23 and 27.

In the public access environment (airport), use the BSSID that provides the lowest per-minute access charge.

Communication priority order: In the morning, give priority to WLAN download communication.

In the evening, prioritize video streaming data.

The policy wizard can be used to allow inexperienced users to create complex policies.

Scenario 10: Special adjustment policies In order to comply with the adjustment needs of various countries, different policies may be required.

These policies should be downloadable because they are not very large and they change at any time.

The European Communications Commission (ECC) may impose uniform expansion requirements on the 802.11a channel selection algorithm. Each country may have different transmission power, frequency band and channel requirements.

Case 11: Dynamic frequency selection Dynamic frequency selection is useful when no WLAN signal interferes with a specific WLAN channel. For example, referring to FIG. 1, a WLAN STA1 1030(1) (eg, a laptop with an 802.11 network interface card (NIC)) is exchanging data with a server 1055 through one of the WLAN APs 1050(1) to 1050(N). Turn on the baby monitor transmitter 1060 in the same channel that AP 1050(1) is using to exchange data with STA1030(1). The spectrum sensitive element 1200 (or cognitively-enabled AP) generates spectrum activity information provided to the network management station 1090. AP 1050(1) can provide 802.11 network statistics. Based on 802.11 network statistics, the network management station 1090 will detect that the AP 1050(1) cannot obtain interference-free channel access (CCA) to the channel. The network management station 1090 can analyze the spectrum activity information provided by the spectrum sensitive element 1200 or the AP 1050 to find another interference-free channel in the frequency band. The network management station 1090 can then reassign the clear channel to the AP 1050(1). AP 1050(1) will start transmitting beacons on the new interference-free channel. STA 1030(1) will finally turn to scanning channels to obtain new beacons on non-interference channels and communicate with APs. 1050(1) 802.11 communication will continue on the new interference-free channel. If a certain part of the frequency band is continuously used by other devices, another device or network can be programmed or controlled to not work to not transmit on these bandwidths. Conversely, by searching for "no interference" channels in a prepared manner, the device or network can be controlled to propagate on these channels.

Case 12: Adjusting the packet size The pulse histogram can indicate the duration of the interval between the detected signal pulses. If the interval is very short, the device or device's network can be programmed to "do not work" again to reduce the size of the packet to fit within the available time interval between pulses. This reduces the chance that a single packet will experience interference and also reduces the need to retransmit the packet. Of course, when the interval between pulses becomes longer, the packet size can be increased again, resulting in a higher transmission speed.

The foregoing scenario shows the advantages of aggregating intelligence about spectrum usage and the advantages of using this information. Intelligent data rate selection is another example of the advantages of intelligent systems over current systems, where there is no direct information about interference. Without an understanding of interference, it is difficult to distinguish between interference, packet errors, or problems caused by hidden nodes. As a result, the current system implements a "best guess" algorithm, which often reduces production efficiency. An example is 802.11b in response to the presence of frequency hopping signals, such as BluetoothTM SCO. The initial 802.11b response is data rate compensation, which in turn leads to more collisions, 802.11b responds to additional rate compensation and so on. In contrast, the aforementioned systems use signal classification and other interference timing information to make intelligent decisions about data rates.

In addition, current systems use static, predetermined packet fragmentation levels, and there is no information about the timing of interfering signals. In response to the interference pattern, the intelligent spectrum management system considers the optimization of the fragmentation level and the scheduling of information packets.

For a more detailed spectrum management system architecture, refer to FIG. 28, which shows a spectrum management system architecture diagram similar to that shown in FIG. 6, but splits some measurement functions, classifications, and spectrum actions or controls into multiple layers. The processing level is: 1) L0: hardware management service 1002) L1: engine management service 2003) L2: manager service 3004) APP: application service 400 compared with the diagram in Figure 6, level L0 corresponds to the hardware or physical layer level, and The driver is located above the hardware level; level L1 corresponds to the spectrum level; and level L2 corresponds to the network level. The upper layer, APP, corresponds to the UI module, the system integration module, and other systems or applications integrated by the system integration module.

L0: Hardware Management Service The L0 hardware management service 100 manages the hardware resources 10 used in the spectrum management system. These hardware resources are located in a communication device that operates in a frequency band shared with other devices and communication devices. The management of hardware resources includes management of the radio (radio transceiver or receiver) 12 on the basis of contention management and traffic data accumulation, which will be described further below.

In the L0 hardware management service level 100, there are an L0 resource manager, an L0 SAGE engine 120 that manages SAGE20, and an L0 measurement engine 130. The L0 hardware management service can be executed on a "single chip", which means an integrated circuit (IC) included in a communication device to process signals for transmission and reception in the network. This processing stage can be similarly applied to all communication devices working in the network.

The L0 SAGE engine 120 is a device driver that connects high-level commands to the SAGE20 interface, and translates these commands into signals that can be recognized by the SAGE20. The instructions may include one or more component formulation signals for SAGE20, as described below.

The L0 measurement engine 130 executes the initial accumulation of the data output by the SAGE20 into a spectrum utilization map (SUM) format. The spectrum utilization diagram will be described below.

L1: Engine Service The L1 engine service level 200 is the first level of measurement, classification, location, and policy service execution. In the engine service level, there are L1 engines, such as L1 location engine 210, L1 measurement engine 220, L1 classification engine 230, and L1 policy engine 240, which control L0 hardware management level processes and use information to perform their next level services. There is also an L1 resource manager 250 in the engine management level 200. The protocol adjustment engine 260 is located in the L1 engine service level 200, and it performs functions related to protocol management; it does not play an important role in spectrum management.

The L1 engine service level 200 is usually executed "off-chip" in the main processor of the communication device. However, some L1 processing can be performed on the chip if additional external memory is supported. Some local policy decisions, such as local interference mitigation, can be decided at the L1 engine processing level. The L1 engine service level can be similarly applied to all communication devices working in the network.

L2: The next higher level of manager service level is L2 manager service level 300. The L2 Manager service is responsible for more complex network spectrum management functions. Examples of processes at this level are the L2 location manager 310, the L2 measurement manager 320, the L2 classification manager 330, and the L2 policy manager 340. There are also L2 resource manager 350 and L2 network spectrum manager 360. The processing at this level can be performed at a central server location, which combines and calculates the information for processing, and does not have to pass through a communication device working in the network.

Other software functions that can be located at this level include database functions with reporting and query services to analyze spectrum activity information collected from lower processing levels, security policies, interference policies, management information bases (MIB), web servers, and SNMP agents , SendMail, etc.

APP: The highest level of application service level in the system architecture is APP application service level 400, in which network application programs are executed. Examples of the network include a spectrum analyzer display application 410, a location/map display application 420, a measurement/statistics application 430, and a spectrum management policy application 440.

Referring to FIG. 29, according to the spectrum management diagram, the network may include devices such as a station STA500, an access point AP510, a monitoring network spectrum manager 360, and an application service 400. The example of the network spectrum manager 360 is responsible for the subnet composed of AP510 and their related STA500. While the terms STA and AP are used here, they have the relevance of IEEE802.11x WLAN applications. It should be understood that the spectrum management architecture and the process described herein can be applied to any wireless communication application. The network spectrum manager 360, as mentioned above, may be located on a server computer (such as the network management station 1090 in FIG. 1) connected to APs in its subnet by wire or wirelessly. In many cases, the subnet is actually the entire network in question.

Spectrum management is designed to work with parallel external network management entities. For example, a general network management system may be in a suitable location for enabling, disabling, and configuring network components such as APs. The network spectrum manager has a service interface that allows notification of changes made by the external network management system. Similarly, spectrum management provides a service interface so that general network management systems can be notified of changes within the network such as channel allocation and STA association. The network update service interface can be used by any consistent application in the application service 400.

Referring to Figure 28, examples of spectrum management services include location, measurement, classification, and policy management. Policy management configuration and activation of algorithms, which control the coexistence between different types of communication devices operating in the frequency band, channel allocation of the equipment in the frequency band, transmission power control of the equipment operating in the frequency band, and allocation to the operation in the frequency band The bandwidth of the device.

Most spectrum management services are independent of special media access protocols. For example, spectrum analysis, classification, radio measurement, and certain policies are independent of the agreement. In addition to these protocol-independent services, spectrum management also provides special support for certain protocols, such as supporting traffic statistics related to specific media access protocols, such as IEEE802.11x and coexistence algorithms. However, the entire spectrum management architecture can be applied to any frequency band, such as the unlicensed frequency bands of the ISM in the United States and other unlicensed frequency bands in the world.

The network spectrum interface turns to Figure 30, and there are multiple NSI APIs connected to the architecture of Figure 28. They are: 1) Hardware NSI170, which connects the L0 hardware management service 100 interface to the L1 engine management service 200;

2) Engine NSI270, which interfaces the L1 engine management service 200 to the L2 manager service 300. The engine NSI270 is similar to the NSI mentioned in FIG. 6; and 3) the manager NSI370, which interfaces the L2 manager service 300 to the application service 400.

NSI is a logical interface, which is embodied in various program interfaces and transmission mechanisms, and any appropriate transmission mechanism can be adopted. It mainly affects the hardware NSI170. For example, if the L0 hardware management service is executed on the chip, and the L1 engine management service is executed in the main device driver, the transmission mechanism for the hardware NSI can be on the PCI interface. On the other hand, if the L0 hardware management service is executed on the chip along the L1 engine management service, the transmission can be a native (on-chip) software interface. In either case, the hardware NSI service model can be the same.

Figure 31 shows how NSI is used between the various levels of the spectrum management software architecture in the context of the system hierarchy shown in Figure 28. For each NSI, there is an application programming interface (API), which defines the transmission protocol of the interface. At the highest level of the spectrum management architecture, there is the NSI management service API372, which defines how information is exchanged between the L2 manager service 300 and the application service 400. The NSI manager service API 372 of any subnet can be connected to the L2 manager service interface of the same subnet or other subnets. At the next level, there is the NSI engine service API 272, which defines how information is exchanged between the L2 manager service 300 and the L1 engine service 200. There is an NSI hardware API 172, which defines how information is exchanged between the L1 engine management service 200 and the L0 hardware management service 100.

At the STA network level, there is also the NSI hardware API 174, which defines the information exchange between the L0 hardware management service 100 and the L1 engine management service 200 in the STA. Similarly, there is the NSI engine service API 274, which defines the information exchange between the L1 engine management service 200 and the application service 400.

Resource Manager With reference to Figure 32, the resource manager function will be described. Within each network component of each level of spectrum management software architecture is a resource manager. The resource manager is responsible for (1) mediating the contention of common resources by the same level software components (such as radio transceiver and SAGE); and (2) requesting access to common low-level resources; and (3) arranging in response to requests from superiors The progress of the service at this level. The resource manager may already have knowledge and complete control over the scheduling of the use of low-level resources. Once the service request has been authorized, the upper-level components will usually interact directly with the lower-level counterparts. When resource adjustment is required, the L2 network spectrum manager 360 adjusts the various resource managers involved.

Turning to Figure 33, spectrum management is related to the scheduling and adjustment of resources, which are required to deliver spectrum management services such as classification, location, and measurement. Spectrum information is the transmission of raw data to higher-level information content for the intelligent use of this information.

The software components included in the management of network resources are the resource manager and the L2 network spectrum manager 360 in each software level. The L2 network spectrum manager 360 manages the resources of the entire network. It is essentially the master of network control. The network update service interface 450 is an application service for managing update requests, which may come from an external network management system or other upper-layer applications.

The L0 and L1 resource managers 110 and 250 are respectively responsible for managing resource requests within their own network components (STA or AP). The L2 resource manager manages network resource requests. However, it does not manage any activities. It essentially manages the total resources controlled by the L2 network spectrum manager 360.

For each MAC protocol, it is effectively managed by the L2 network spectrum manager 360, and there is an L1 protocol adjustment engine 260 (FIG. 28), which manages the actual protocol MAC engine.

The software components shown in Figure 33 control network activity, but they do not make intelligent choices about what actions to take. These intelligent decisions are made either by the policy engine/manager or by applications in the application service level 400.

With reference to Fig. 34, the concept of spectrum information is further described. The spectrum information indicates that it is in two general categories: smart spectrum information 600 and smart spectrum control 620. The intelligent spectrum information 600 is the result of converting the original spectrum activity data into increasingly higher information content. For example, the LOSAGE engine 120 captures impulse events, which are analyzed by the L1 classification engine 230, which then transmits the preprocessed results to the L2 classification manager 330 for further analysis (if necessary).

The smart spectrum control 620 is an instruction that changes the behavior of the device operating in the frequency band. The L1 policy engine 240 and the L2 policy manager 340 are the main mechanisms for intelligently responding to network conditions. Actions include AP channel selection, STA load balancing, and interference mitigation (coexistence algorithm), etc. In addition, the manager NSI370 (Figure 30) provides a policy manager service, which allows more advanced network applications to update or influence policies.

Figures 35 and 36 show the details of the interaction between the modules in the different stages of the spectrum management system. In these figures, the solid lines between the boxes represent data flow, and the dashed lines represent control.

FIG. 35 shows the information interface between the L0 hardware management service and the hardware resource, and the information interface of the hardware NSI between the L0 hardware management service and the L1 engine service. The L0 resource manager 110 manages the use of radio resources to prevent conflicting use of radios. For example, the L0 resource manager 110 may receive a request from the L1 resource manager to perform spectrum management tasks, such as changing the center frequency, bandwidth, or power, or for SAGE function/control requests. The L0 resource manager 110 will generate control signals to control the center frequency, bandwidth, and/or output power level used by the radio, and will arbitrate the radio use between the MAC protocol process for receiving or transmitting the signal and the SAGE request. On the other hand, when running SAGE20, the L0 resource manager 110 will control the radio operating in the broadband mode to sample the entire or substantial part of the frequency band for spectrum management functions or to transmit broadband signals in the frequency band. Based on the received request, the L0 resource manager 110 will set the duration of radio usage for the SAGE or signal communication function.

The LOSAGE engine 120 provides device driver, SAGE20 configuration and interface management. These responsibilities include the use of SAGE Dual Port RAM (DPR). The SAGE dual port RAM is used by several SAGE internal components. The LOSAGE engine 120 is responsible for allocating DPR resources to various applications and rejecting requests when the DPR resources are currently unavailable. The LOSAGE engine 120 transmits the SAGE information to other L0 subsystems, for example, to the L0 measurement engine 130 or the L1 classification engine 230.

The L0 SAGE engine 120 receives configuration information of several of its components from the L1 engine. For example, it receives configuration information of the snapshot buffer from the L1 position engine 210, and provides the content of the snapshot buffer to the L1 position engine 210 based on an appropriate trigger event. Similarly, the L0 SAGE engine 120 receives the SAGE signal detector configuration information from the L1 classification engine 230. The L0 SAGE engine 120 outputs the signal detector pulse event to the L1 classification engine 230. The L1 policy engine 240 provides control of the USS component of SAGE20.

The L1 measurement engine 220 and the L0 measurement engine 130 exchange configuration information of the SAGE measurement analyzer and signal detector. In addition, the L0 measurement engine outputs pulse events from the SAGE signal detector, as well as statistical information and duty cycle information from the SAGE spectrum analyzer. The L0 measurement engine 120 accumulates this information, which constitutes the initial information of the spectrum utilization map (SUM). At this level, this information is called LO SUM 160. The L0 SUM 160 can be periodically delivered offline to the L1 SUM 265 and the L1 measurement engine 220 for accumulation in the L2 SUM.

The L1 measurement engine 220 provides the power versus frequency (PF) spectrogram information and the spectrum analyzer statistical information generated by the SAGE20 spectrum analyzer, and the pulse events output by the SAGE signal detector to the L2 manager. The L1 measurement engine 130 may receive SAGE spectrum analyzer configuration information from the L2 measurement manager 320 to configure low-pass filter parameters, decimation factors, and other items. The L1 measurement engine 220 outputs the time stamp and the associated received signal strength indicator (RSSI) power value for each of the multiple fast Fourier transform (FFT) binary files. For spectrum analyzer statistics, SAGE20's spectrum analyzer can be used for low-pass filter parameters, decimation factors, cycle counters (the number of spectrum analyzer updates performed before forwarding statistics), and the minimum power used for task counting It is configured similarly. Spectrum analyzer statistics include the timestamp of each FFT binary file and associated statistics, including average power, maximum power, and the amount of time above the minimum power.

The pulse event is output by the pulse detector component of the SAGE signal detector. For example, SAGE contains 4 pulse detectors. The L1 measurement engine 220 collects pulse events. More than one L1 user can use the same pulse event stream. For example, the L2 classification manager 330 may use pulse events to achieve more detailed classification. The same impulse event stream is also checked by the L1 classification engine 230.

The user of the pulse event stream can specify a specific pulse detector by specifying the signal detector ID such as 0 to 3. Otherwise, the L2 network spectrum manager 360 selects the pulse detector. The configuration information of the pulse detector includes ID, bandwidth limit, minimum center frequency, maximum center frequency, minimum power limit, minimum pulse bandwidth, maximum pulse bandwidth, maximum pulse duration, etc. Other details of the configuration of the pulse detector are disclosed in the aforementioned pending application.

The pulse event data stream includes, for example, the signal detector ID, the center frequency (at the beginning of the pulse), the pulse width (at the beginning of the pulse), the pulse duration, the time stamp at the beginning of the pulse event, and the time stamp associated with the pulse detector. The counter value of the down counter in the universal clock module and the pulse power estimation (at the beginning of the pulse).

The L1 classification engine 230 performs the first level of signal classification. The details of the signal classification procedure are disclosed in the aforementioned patent application. The L1 classification engine 230 outputs the fingerprint identification of the signal or pulse, which is performed by matching the statistical and pulse information with the fingerprint template. The result is that one or more identifiers match with respect to the type and timing of the pulse. In addition, the L1 classification engine 230 outputs statistical information that generally characterizes what is happening in the frequency band. As described above, the L1 classification engine 230 configures the SAGE pulse detector to be suitable for signal classification.

The signal identification information output by the L1 classification engine 230 is also called "fingerprint identification" and includes, for example, the center frequency (if relevant), the fingerprint ID, the estimated fingerprint ID indicating the likelihood of the device, the power of the identified device, And estimated duty cycle percentage. Fingerprint IDs include, for example, IDs used in microwave ovens, frequency hopping devices (such as BluetoothTM SCO devices or Bluetooth TMACL devices), cordless phones, IEEE802.11 devices, and IEEE802.15.3 devices, and various types of radar signals.

Classification statistics include the creation of a histogram of pulse events generated by the free SAGE signal detector. The L1 classification engine 230 configures the pulse detector to gather pulse events based on its configuration. Examples of established statistical histograms include center frequency, bandwidth, active transmission, pulse duration, time between pulses and autocorrelation. The details of these histograms and classification engines are described in the aforementioned signal classification patent application.

Figure 36 also shows various application services and how they interface with the manager service. The L2 measurement manager 320 exchanges data with the spectrum analyzer application 410 and the measurement/statistics application 430. The L2 measurement manager 320 receives the SUM data from the L1 measurement engine 220 and establishes a complete SUM called L2 SUM 380. The L2 SUM 380 includes radio and protocol statistical information. L2 SUM 280 will be described in detail with reference to Figure 41. The L2 location manager 310 and the location application 420 dock information. For example, the L2 location manager 310 provides raw location data, and the location application 420 performs processing to generate location information of various devices operating in the frequency band. The L2 classification manager 330 exchanges information with the classification definition application 425. The classification definition application 425 is an application that generates and provides new or updated signal definition reference data (also called fingerprints) used by the classification engine 230. The classification definition algorithm is disclosed in the aforementioned application for signal classification. The L2 policy manager 340 exchanges information with the policy application program 440. One function of the policy application 400 is to define and provide spectrum policies that control frequency band usage in certain situations. The policy guide, which will be described below, is an example of another function of the policy application 440.

Turning to Figure 37-40, the connection between the L1 engine service and the L2 manager service will be described. The function of the engine NSI is to provide the use of L1 engine services. As shown in Figure 37, in the WLAN application, the L1 engine service works in the AP and the client STA. An example of the engine NSI provides either the use of AP and STA, or the use of a single STA. The instance of the engine NSI is distinguished by the transport connection. That is, for each case of the engine NSI, there is a separate transmission connection. In WLAN applications, the engine NSI can be provided in APs and STAs. Similar L1 services are provided in the STA and the controlled AP. For example, the output of SAGE is provided to AP and STA. Similarly, network SUM/statistics information can come from the observations of APs and STAs.

Referring to FIG. 38, when an engine NSI user wants to access more than one AP, a separate engine NSI situation occurs. Each case is distinguished by a separate transmission connection. Figure 38 shows a single engine NSI user accessing two APs via two separate engine NSI scenarios, where each engine NSI scenario has its own transport connection.

Turning to Figures 39 and 40, the NS engine service in the access station can be implemented locally in the station or remotely via the transmission protocol. Figure 39 shows a typical situation of local access of the local station management application. The STA management application provides services to users, such as SAGE spectrum analyzer or statistical information. Figure 40 shows how the remote model permits the centralized accumulation of remote STA statistical information. It also allows the coordination of activities such as interference mitigation among APs, STAs, and interference sources.

Fig. 41 shows an example of information contained in L2 SUM380. Each Fast Fourier Transform (FFT) frequency receiver (one of multiple frequency receivers across the frequency band) has related duty cycle statistics, maximum power statistics, average power statistics, and network traffic statistics, if any. Figure 41 shows only an exemplary subset of frequency receivers.

The L2 Policy Manager Policy Manager 340 defines the response to the presence of other signals in the frequency band. These policies can be specified by the management domain or by the user/administrator. For example, the European FCC requires a mobile channel if the radar signal is detected. Alternatively, the administrator may wish to add the channel with the least noise if the traffic load is higher than 60%. The user may wish to give priority to cordless phone communication in WLAN communication.

These policies can be changed at any time and change according to usage. This makes it impossible to hard-code all situations and install the product. The created new or updated policy (for example, as described below) can be downloaded by the L2 policy manager 340 to the L1 policy engine 240. Management policy can be expressed as a well-defined grammatical form. These grammatical rules define concepts, such as RSSI level, CCA percentage, communication type (voice, data, video, etc.), protocol type, active channel, alternative channel, etc. The syntax defines operators, such as "greater than", "maximum", and "items of...".

The grammar allows the construction of the priority setting of the If/then rule in the following form: If[condition] then[activation rule] The activation rule uses the following spectrum management tools, such as DFS, TPC, etc.

Examples of spectrum policy statements are: SOHO AP: if startupactive-channel=random from lowest RSSI(AP) if active-channel packet errors> 20 active-channel=random from lowest RSSI(AP, STA) SOHO NIC: if startupactive-channel= find BSSID(1234)start withlast-active-channelLARGE WLAN AP:

if startupActive-channel=fixed 7if active-channel traffic utilization>60% add-channel 8 if measure(channel 8)=low noiseLARGE WLAN NIC: if startupactive-channel=find highest SNR with low CCAif active-channel collisions>50%find The alternate channel with low CCA policy manager 340 matches the spectrum policy rule with the current conditions and takes action, which is essentially similar to the action of the rule-based expert system "jamming engine". The matching intelligence of the policy manager 340 can use toolkits from artificial intelligence fields: lisp, prolog, etc. In addition, the policy manager 340 may use fuzzy logic to handle fuzzy terms, such as "high traffic", "bad signal strength", and so on.

The policy guide is an example of the policy application 440. It provides information to the policy manager and simplifies the task of generating spectrum policies by asking the user (or administrator) a set of questions, such as: Is this a home network or an office network? Is there more than one AP in the network? Are there one or more cordless phones in the area? Based on this information, the policy guide generates a spectrum policy suitable for those parameters. The spectrum policy is downloaded to the policy manager 340.

In summary, a method for managing the use of radio frequency bands is provided, in which multiple types of signals can appear in the radio frequency band, including the steps of generating at least one of the following: (a) Controlling equipment in the radio frequency band The control signal of the work, and (b) based on the spectrum activity information derived from the radio frequency energy appearing in the radio frequency band, information describing the specific type of activity determined to occur in the radio frequency band.

In addition, a system for managing the use of the radio frequency band is provided, in which there are multiple types of signals, including: at least one radio device that receives radio frequency energy in the radio frequency band to monitor the signals of multiple types of signals appearing in the radio frequency band Activity, and generate spectrum activity information to replace it; and a computing device connected to the radio equipment, which receives the spectrum activity information and generates at least one of the following: control for controlling equipment operating in the radio frequency band, and the description is determined A specific type of information about the activity to appear in the radio frequency band.

In addition, a processor-readable medium encoded with instructions is provided, which when executed by the processor, causes the processor to perform the steps of generating control signals, which are used to control the operation of the equipment in the radio frequency band, and (b) based on the source From the spectrum activity information of the radio frequency energy appearing in the radio frequency band, information describing a specific type of activity that is determined to occur in the radio frequency band.

In addition, a software system for managing activities in the radio frequency band is provided, in which multiple types of signals may appear, including: a first process for accumulating data associated with activities in the radio frequency band; based on data from the first process The second process of data categorizing the types of signals appearing in the radio frequency band; based on the data accumulated in the first process and/or based on the second process to determine the type of signals to appear, the third process generates at least one of the following: Control of equipment operating in the radio frequency band, and specific types of information describing activities that occur in the frequency band.

In addition, it also provides a software architecture for a system for managing activities in the radio frequency band, in which multiple types of signals can appear, including: applications that process spectrum activity information about activities in the radio frequency band to perform functions; and Application programming interface, which presents the message to one or more processes, and these processes generate spectrum activity information and return the spectrum activity information to the application.

A method for interfacing an application program with at least one process is provided. The at least one process analyzes data about activities in the radio frequency band and generates spectrum activity information, where multiple types of signals may appear, including the steps: Requesting a spectrum analysis function in at least one process; and receiving spectrum activity information generated by the at least one process.

Similarly, an application programming interface is provided, which is contained on one or more computer-readable media, which connects an application program with at least one process, and the process analyzes data about activities in the radio frequency band. The signal may appear, and the process also generates spectrum activity information, including a first group of messages requesting an analysis function from at least one process, and a second group of messages providing spectrum activity information to the application.

In addition, a device for receiving radio frequency energy in the radio frequency band and processing signals representing it is provided, including: a radio receiver, which receives radio frequency energy in the radio frequency band, and multiple types of signals can appear in the radio frequency band; spectrum analysis An instrument that calculates the power value of radio frequency energy received in at least a part of the radio frequency band within a time interval; a signal detector connected to a spectrum analyzer that detects signal pulses of radio frequency energy that meets one or more characteristics; and A processor connected to a spectrum analyzer and a signal detector that receives the output, wherein the processor is programmed to generate at least one of the following: (a) a control signal for controlling the operation of the device in the radio frequency band, and (b) Based on the spectrum activity information from the spectrum analyzer and the signal detector, information describing a specific type of activity that is determined to appear in the radio frequency band.

The foregoing description is only exemplary, and is not intended to limit any manner of the present invention.