Patent Description:
The present invention relates to wireless telecommunications networks, and more specifically relates to systems, equipment, components, software and methods for troubleshooting signals in cellular communications networks.

<FIG> shows an overview of a typical wireless telecommunications network <NUM>. To facilitate an understanding of the invention, the steps in carrying on a conversation between New York and California on a wireless cellular network <NUM> will now be explained. When the person in New York inputs on his cellular phone <NUM> the number of the person in California and presses "call" or "send", a process is started to find the person in California and send a message to them to make his phone ring. When the person in California answers the call, a transmission path is set up to send and receive their conversation across the country.

For the purposes of this invention, the details of how the phone conversation is set up need not be described. This present invention is concerned with enabling the accurate recovery of a transmitted message in the section <NUM> of the network <NUM> which is linked by a radio transmitter and radio receiver. This section <NUM> of the network <NUM> is called the "Radio Access Network" which is commonly abbreviated as "RAN". For purposes of illustration, we will describe a voice conversation. However, the same concepts apply to any other radio transmission (data, video, etc.).

Telecommunications is a chain of transmit and receive processes. In the case of voice conversations, human speech is received by a microphone and converted to analog signals (modulation of electromagnetic force (changes in voltage with respect to time)). The analog signals are converted to a digital representation in an analog-to-digital converter and then the digits (<NUM> and <NUM>) are transported over a distance to a receiver where the <NUM> and <NUM> are converted from digital back to analog and presented to a person via a speaker. If the digital signal (<NUM> and <NUM>) is not received exactly as it was transmitted, then there is distortion in the audio signal, and the person at the receiving end may not understand the conversation.

Referring again to <FIG>, each connection between a transmitter and a receiver is commonly referred to as a "hop". An end-to-end connection consists of several hops, each of which must correctly transmit and receive the data, through multiple Mobile Switching Centers (MSC) <NUM>. The limiting factor in the network equipment's ability to accurately recover the signal is the signal to interference plus noise ratio ("SINR") at the receiver. Every receiving device has an SINR at which it can no longer correctly recover the signal that was sent by the transmitter. Mathematically, the signal to interference and noise ratio is expressed as: <MAT> where the level (amount) of the signal and the level of the noise are measured in the same units (usually power, expressed in Watts).

For each hop in the telecommunications network <NUM>, the path between the transmitter and the receiver is called the "transmission medium" <NUM>. In the mobile phone network <NUM>, the transmission mediums are:.

The environment in which pressure waves are transmitted by a talker to a microphone (item <NUM>) and from a speaker to a listener (item <NUM>) can be a significant source of distortion in the quality of the end-to-end conversation (example: talking or listening in a crowded, noisy room). However, this SINR environment is outside the control of the Wireless Service Provider (WSP), so it is not a process the WSP tries to quantify, measure, and manage.

The transmission of electrical signals in the network (item <NUM>) occurs over short distances (usually along a circuit path inside a piece of equipment or short distances between pieces of equipment) and are generally near <NUM>% reliable (literally greater than <NUM>% reliability).

Transmission of light pulses through fiber-optic cables occurs over long distances, but the transmission medium <NUM> is very good. The characteristics of the fiber-optic cables are very well known and are very stable (i.e. the characteristics have very low variability). Therefore, even though transmission of light pulses over fiber-optic cable <NUM> covers long distances, it can be engineered to consistently provide greater than <NUM>% reliability.

The transmission medium <NUM> in which almost all the problems occur is the over-the-air radio wave environment. While the characteristics of radio wave transmission in free space (e.g., between the earth and the moon) are very well understood, the transmission of radio waves in the mobile phone network <NUM> can only be predicted statistically. There are several reasons for this:.

The net result is that the over-the-air radio transmission environment has high variability in the signal part (numerator) of the SINR equation and sometimes also has high variability in the interference and noise part (denominator) of the SINR equation.

The signal to noise ratio of the fiber-optic (and electrical) part of the network <NUM> is highly predictable, and the signal-to-noise ratio of the Radio Access Network <NUM> is highly unpredictable. If the variability is low, then telecommunications engineers can accurately design the system for high reliability. If there is high variability in the system, it is much more difficult to achieve high reliability. This is why the RAN environment is always the limiting factor in the reliability of mobile telecommunications networks.

In addition to the reliability problems, there are also capacity constraints in the RAN environment. The capacity for data transfer (measured in bits per second) over a fiber-optic line is vastly greater than the data transmission capacity of the RAN environment.

Frequency spectrum is a shared public resource that is regulated and controlled by governmental agencies (the Federal Communications Commission in the United States). The FCC auctions licenses to operate in defined frequency ranges to the wireless service providers. The frequency spectrum of the RAN environment is a precious resource because there is a finite supply. Because there is a limited supply of frequency spectrum, and because of the growth in demand for wireless services by consumers, the cost for these licenses has risen dramatically. The most recent frequency auction in the United States garnered $<NUM> billion dollars for the right to use <NUM> (megahertz) of frequency.

Two problems which reduce the reliability and capacity of the wireless telecommunications network <NUM> are breakdowns in the balance of the diversity antennas <NUM>, and increases in the noise level at the radio receiver. The equipment in the network <NUM> monitors for these conditions and sends notifications when problems are detected. The generic terms for these notifications are:.

There are many potential causes of problems in the RAN <NUM>, but the common of them are:.

The root causes, physical manifestations, and alarms and indications of the physical manifestations are summarized in Table <NUM>. The key point of the table is that the alarms and notifications are generally insufficient by themselves to diagnose and repair the root causes of the problems.

A typical procedure for diagnosing the root causes requires:.

A knowledgeable technician or RF engineer on site while the problem is occurring. However, problems are often intermittent (i.e. PIM only when it is windy or intermittent interference). It is like the gremlin in your car that does not show itself when you take it to the repair shop - you know something is wrong but you cannot diagnose it, so you just start changing parts and hope the problem goes away.

The Wireless Telecom Network <NUM> is currently undergoing a transition in the architecture of the radio access network (aka RAN <NUM>). The traditional RAN architecture (which has been used since the <NUM>) employed equipment in which the electronics were housed in a controlled environment and the radio signal was sent and received over a coaxial transmission line <NUM> to an antenna <NUM> which transmitted and received the radio signal over the air to mobile phones <NUM>. A typical embodiment of this architecture is shown in <FIG>. Throughout the rest of this disclosure, the inventors will refer to the traditional RAN or T-RAN for short.

The modern approach splits the function of the base station <NUM> into two pieces of equipment, called the Radio Equipment ("RE") <NUM> and the Radio Equipment Controller ("REC") <NUM> as shown in <FIG>. The RE <NUM> and the REC <NUM> can be separated by an arbitrary distance. For example, with this technology is used at an independent tower location, the RE <NUM> is usually mounted near the top of the tower and the REC <NUM> is at the bottom of the tower. There is also a new architecture called C-RAN (Cloud or Centralized RAN), in which several RECs <NUM> are housed in a central location and the REs <NUM> are connected to them over distances up to <NUM> kilometers.

The Radio Equipment <NUM> transmits the radio signal to the mobile phones <NUM> and receives signals from those mobile phones <NUM>. The Radio Equipment <NUM> may have multiple transmitters and receivers at the same frequency, for diversity or so-called MIMO (Multiple Input Multiple Output) functions. The Radio Equipment Controller <NUM> processes the baseband modulation data (in the mathematical format of "I/Q vectors", where "I" represents the in-phase signal component and "Q" represents the quadrature phase signal component).

In the C-RAN architecture shown in <FIG> and <FIG>, the REC <NUM> and the RE <NUM> have a digital data connection that can be extended up to <NUM> kilometers (about <NUM> miles) over a highly reliable fiber-optic connection <NUM>, often using an interface called the Common Public Radio Interface ("CPRI"). Hundreds of REs <NUM> can be connected to the REC equipment <NUM> that is housed in one location. This is why the C-RAN architecture is sometimes also referred to as "Base Station Hoteling".

There are three primary reasons that the Wireless Service Providers are investing in the C-RAN architecture:.

The CPRI connection between RE <NUM> and REC <NUM> employs fiber-optic transmission lines <NUM> to transport I/Q data. I/Q data is to radio frequency modulation what an MP3 is to music - it is the digital representation of the analog modulation (change in voltage with respect to time).

In the downlink communication channel (from the network <NUM> to the mobile telephone <NUM>), the I/Q data has no distortion, because at the point that it is observed, it has not yet been subjected to the effects of the RAN environment or any other sources of distortion.

In the uplink communication channel, the I/Q data contains the signal created by the phone <NUM> plus the effects of the RAN environment (path loss and fading effects) and distortion from noise sources (the problems the RANALYZER™ system of the present invention is designed to diagnose). In the uplink direction, the REC <NUM> processes the I/Q data and attempts to recover the original signal (in the presence of noise) as transmitted by the phone <NUM>.

The RANALYZER™ system of the present invention processes the I/Q data and attempts to separate out the noise component (in the presence of signal) to determine the root cause (source) of the noise. The methods for separating out the noise from the signal and analyzing the noise to discover its source, in accordance with the present invention, and the RANALYZER™ system <NUM> of the present invention, will now be disclosed. <CIT> discloses determining distance to passive intermodulation source using CW signals and a <NUM>/<NUM> degree phase splitter to provide Imaginary and Real signal components for determining signal phase.

<FIG>, consisting of <FIG> shows a block diagram of the RANALYZER™ system <NUM> of the present invention in a generic form. The system observes the communication between the Radio Equipment <NUM> and Radio Equipment Controllers <NUM> by obtaining a portion of the signal used for this communication. This signal is most commonly over a fiber-optic connection, but other connections are possible such as a wireless connection (see <FIG>). The observed signals are feed into a high-speed logic device, such as a Field Programmable Gate Array (FPGA), which acts as a digital signal processor <NUM> which performs various operations to extract knowledge about impairments in the Radio Access Network (RAN) <NUM>. These observations may be triggered by alarms from the network <NUM>, made manually by an operator, or by automatically scanning among the various available connections between RECs <NUM> and REs <NUM> by using an electrical or mechanical (preferably, robotic) switch assembly <NUM>.

Communications between REC <NUM> and RE <NUM> are observed in each direction-from the Radio Equipment Controller <NUM> to the Radio Equipment <NUM> (also known as the "Downlink"), and from the Radio Equipment <NUM> to the Radio Equipment Controller <NUM> (also known as the "Uplink").

These four pairs of signals are converted from optical format to electrical format preferably using an optical-to-electrical converter <NUM> situated before or after the electrical or mechanical switch assembly <NUM>, and then fed into a high-speed digital device known as a Field Programmable Gate Array, or FPGA, acting as a digital signal processor <NUM>, as mentioned above. FPGAs are in many ways similar to microprocessors, but can be much faster at performing certain operations, although they are much more difficult to program and tend to be somewhat less flexible. The FPGA (digital signal processor) <NUM> performs a number of signal processing functions, to obtain I/Q data, spectrum traces, and various other pieces of information about the observed signals that are detailed later. An Application-Specific Integrated Circuit (ASIC), may also be used as the digital signal processor <NUM> to provide similar functionality. In the future, specially programmed general purpose processors may even be able to keep up with the needed data rate. Each of these methods do not affect the fundamental functionality of the system <NUM> of the present invention.

This information is passed to an analytic computer unit <NUM>, such as a microprocessor, which may include a server <NUM>, for some additional processing, mostly involving the Automatic Analysis and Identification of Interference and Noise Sources (q. ), as well as storage of I/Q data and traces for later additional analysis.

The server <NUM> then makes these data available to a client via a network connection, that is, through a private or public internet protocol network <NUM>. More specifically, a display <NUM> may be located locally to the RANALYZER™ system <NUM> and connected to the analytic computer unit <NUM>, or may be remotely located and provided analytical data through the private or public internet protocol network <NUM>. In this way, the client may observe the analytical results at a convenient (local or remote) location.

The server <NUM> also receives control and setup information from the client, as well as alarms and indicator signals from a High-Level Network Equipment Monitoring System <NUM> that is closely linked to the Radio Equipment Controllers <NUM>. This monitoring system <NUM> provides Diversity Imbalance alarms, high RSSI alarms, as well as several other alarms and indications that are useful to help find the real problem in the RAN <NUM>, as detailed below. The I and Q digital data, spectrum traces and other analytical data may be stored in memories within the digital signal processor <NUM> or the analytic computer unit <NUM>, or remotely in a post-processing and mass storage memory <NUM> coupled to the analytic computer unit <NUM> and server <NUM> through the internet protocol network <NUM>. The dataflow through the system <NUM> is shown in <FIG> and <FIG>. The control information that is passed from the client is exemplified by the screens in <FIG>, as described below. It should be noted that that the RANALYZER™ system <NUM> has many more displays than this, as explained in the section Signal Displays herein; these are merely examples of different types of displays in the RANALYZER™ system <NUM>.

<FIG> shows a block diagram overview of the RANALYZER™ system <NUM> as used in a C-RAN. The system <NUM> observes the communication between the Radio Equipment Controllers <NUM> in the C-RAN hub and the various geographically-dispersed Radio Equipment <NUM> by means of fiber optic couplers (aka "taps") <NUM>. The observed signals are sent via links <NUM> to a fiber-optic switch <NUM> which selects certain (preferably up to four (<NUM>)) pairs of signals from many fibers. One such switch <NUM> is a robotic "patch panel", with preferably up to <NUM> input pairs. More than <NUM> pairs can be switched if the robotic switches <NUM> are daisy-chained. A GPS receiver <NUM> is also provided in the system <NUM>, in order to coordinate measurements among multiple systems, by capturing complex I and Q samples at the same time in each unit, both by knowing the time of day to make the capture, and capturing at a precise time, triggered by a one pulse-per-second output from the receiver, which is closely tied to UTC time. This is especially important in the case of the Macro Site Context below.

While the most common connection between the REC <NUM> and RE <NUM> ("fronthaul") is via fiber optics, sometimes an RF or microwave connection is used, such as illustrated in <FIG>, with detailed connections shown in <FIG>. The form of this interconnection does not affect the functionality of the RANALYZER™ system <NUM>; merely a different connection to obtain the I/Q data carried on the REC-to-RE connection is used. This connection may take one or several of a number of different forms, depending on the implementation of the C-RAN:.

<FIG> shows the RANALYZER™ system <NUM> in the context of a traditional base station, often called a Macro cell or Macro site. In this case, there are a much smaller number of fibers to observe, so a smaller number of input switch ports on the switch assembly <NUM> are needed. Additionally, some of the data used for diagnoses may come from other cell sites, rather than other REs connected to RECs in a C-RAN. Because of this, it's especially important for macro site systems to communicate with other RANALYZER systems <NUM> via the Private Internet Protocol Network <NUM>, so that this data can be used for diagnoses, as well as coordinating the capture of complex I and Q sample data at the same time.

A key aspect of macro site systems is that since there are fewer radio heads to observe, the system cost must be much lower, to maintain a reasonable cost per observed radio. Therefore, many cost optimizations are needed, including:.

<FIG> shows the RANALYZER™ system <NUM> in the context of offline analysis. In this case, I/Q samples or spectrum traces recorded by a RANALYZER™ system <NUM> are recorded into memories either locally (memories <NUM>, <NUM>, <NUM> or <NUM>) or via a network connection (memories <NUM> or <NUM>). These data can then be analyzed in more detail by a subject matter expert (SME) on a RANALYZER™ system <NUM> that need not be directly connected to any REs or RECs. The construction of <FIG> can be seen to be identical to <FIG>, <FIG>, and <FIG>, with these physical connections removed. Since captured I/Q samples (along with metadata such as when the samples were captured, the link direction-uplink or downlink-and the REs or RECs it was gathered from, as well as other information stored in the Event System (q. ) database) contain all the information that the RANALYZER™ needs for diagnosing RAN problems, these data can be moved via a network connection, or even physical transport of storage media, to any other RANALYZER™ system for detailed analysis.

Since the cost of hardware to observe the RAN <NUM> is significant, it is optimal to have fewer measurement points than there are points to observe. A switch <NUM> of some kind, listed below, can be used to connect the RANALYZER™ observation hardware to many different RAN branches.

One method of switching observed RAN branches into the RANALYZER™ system <NUM> is to use an optical switch <NUM>. Optical switches <NUM> to date are optimized for network, rather than measurement, use, and are too costly to be practical. However, a lower-cost optical switch <NUM> would also be possible for use in observing the RAN <NUM>, such as described herein.

Since the C-RAN can have hundreds, if not thousands, of fiber or RF connections, there is a problem selecting the correct connection to monitor, especially from a remote location, and at low cost. While the RF connection solutions are listed above, one solution for the fiber case is to convert the fiber-optic signal to electrical signals using an optical-to-electrical converter <NUM>, then use an electronic switch <NUM> to select which signal(s) to present to the RANALYZER™ system <NUM>. Unlike typical "crossbar" switches, however, there is no need to have many outputs. Only a few outputs are necessary to drive the RANALYZER™ system <NUM>, allowing the switch <NUM> to be lower in cost than would otherwise be the case. See the section on MxN switching for more details about this.

The connectivity problem has been solved for decades in a local environment by the use of a "patch panel", where a person plugs a cable into a socket, similar to the old plug boards used by telephone operators. However, the large number of connections (which make it easy for a person to select the wrong connection) and the desire to control this remotely cause problems for traditional patch panels. Another alternative is to use mirror-based optical switches, but these quickly become cost-prohibitive for a large number of connections.

A solution to this problem is to use a mechanical robot in conjunction with the traditional patch panel. The robot can be remotely instructed to move a cable connected to the monitoring system to attach to the desired test point.

Drawings of the robotic optical switch assembly <NUM> can be found in <FIG> and <FIG>. The robotic optical switch assembly <NUM> has four test output cables <NUM> which are connected to the input of the digital signal processor <NUM> or the optical-to-electrical converter <NUM> (if such is required) of the RANALYZER™ system <NUM>. On the inside of the robotic switch assembly <NUM>, the output test cables <NUM> are called "test connection cables" and the fiber optic connector <NUM> at the end of the connection cable <NUM> is called a "test connection plug". Multiple robotic switch assemblies <NUM> can be daisy-chained together by connecting the test output cables <NUM> of one system <NUM> to four of the external monitor ports (inputs) <NUM> on another system.

The monitor port inputs <NUM> to the robotic switch assembly <NUM> is an array of modified LC-type bulkhead connectors <NUM>. The connectors <NUM> on the outside of the system are called "exterior monitor jacks". The mated connectors <NUM> on the inside of the system are called "interior monitor jacks". A backplane structure <NUM> in the form of a panel supports an array of connectors <NUM>, <NUM> which preferably consists of <NUM> columns x <NUM> rows of connector pairs in a rectangular grid. Preferably, there are a total of <NUM> locations (<NUM> x <NUM>). These <NUM> ports are allocated as follows: <NUM> input ports are for uplink/downlink monitor pairs, four ports are for parking the test cables <NUM> when not in use, four ports are used for daisy-chaining multiple robotic switch assemblies <NUM> when required to have greater than 4x192 connections and the remaining <NUM> ports are used for internal cleaning and diagnostic functions. These diagnostic functions can include a test signal generated in the RANALYZER™ system <NUM> (used for bit-error-ratio testing of the test connection fiber cables <NUM>), a fiber inspection scope (used for verifying the cleanliness of the fiber connection in the test connection plug <NUM>) and a cleaning station (for removing dirt and other contaminants of the fiber connection on the test connection plug <NUM>). Note that having <NUM> pairs is an optimal number due to one implementation of C-RAN, where an interface to provide Coordinated Multipoint operation (CoMP) is limited preferably to <NUM> connections.

The test connection plugs <NUM> are moved by a single arm and gripper mechanism <NUM> which disconnects the test connection plug <NUM> from its protected parking spot in the array of connector jacks <NUM> and moves it to any of the interior monitor jacks <NUM>.

The connectors <NUM>, <NUM> are mounted in an array to a rigid back panel <NUM> with structural supports <NUM> to increase the stiffness of the panel <NUM> of connectors <NUM>, <NUM> and prevent movement while inserting and retracting the fiber-optic plugs <NUM>. The interior monitor jacks <NUM> have chamfered lead-in areas to increase the acceptable tolerances for insertion of the test connection plugs <NUM> into the interior monitor jacks <NUM> by the gripping mechanism <NUM>. The combination of the structure members <NUM> to improve the stiffness of the array of monitor jacks <NUM>, along with the chamfering of the monitor jacks <NUM>, increases the required alignment tolerance of the insertion of the plug <NUM> such that it can be accomplished by the system using a stepper motor <NUM> and belt drive system <NUM> in the X axis, a stepper <NUM> with leadscrew <NUM> drive in the Y axis, and stepper <NUM> with leadscrew <NUM> drive in the Z axis, all without employing alignment feedback systems.

The test connection cable <NUM> is routed around several pulleys <NUM>, <NUM> with one on a sliding member <NUM> to allow for slack take-up as the plug <NUM> is inserted into various ports <NUM> that have a different physical distance from the cable outlet. The sliding member <NUM> is preloaded with a constant force spring <NUM> to keep a known and constant level of tension on the test connection cable <NUM> regardless of its position in the panel <NUM>. The connection cable <NUM> has a highly flexible outer jacket and construction to allow for high durability and flexibility while being routed around the pulleys <NUM>, <NUM>. The combination of the flexible cable <NUM> plus the constant force from the pulley <NUM>, <NUM> enables the system to predict the location of the fibers <NUM> with sufficient accuracy to avoid collisions and tangles.

The arm and gripper mechanism <NUM> that moves the connectors <NUM> is located (in its home position) at the bottom of the backplane panel <NUM> array of connectors <NUM>, <NUM>, and the pulleys <NUM>, <NUM> from which the test connection cables <NUM> are tensioned are located above the top row of the backplane panel <NUM> supporting the array of connectors <NUM>, <NUM>. If more than one plug <NUM> needs to be inserted into the same column of jacks <NUM>, then the plugs <NUM> and connection cables <NUM> are inserted into the jacks <NUM> in the order of top to bottom.

To access a given test connection plug <NUM>, the gripper arm <NUM> positions itself directly in front of the plug <NUM> to be moved (in-line in the Z axis). When the gripper arm <NUM> moves in the Z direction to grab the plug <NUM>, it makes several vertical steps (upward deflections in the Y direction) to avoid collisions with the connector housings and test connection cable <NUM> of adjacent plugs <NUM>. A cable guide <NUM> in the shape of a rounded wedge also aids in the vertical motion to prevent tangled cables <NUM> (see <FIG> and <FIG>).

The robotic switch assembly and system <NUM> keeps track of the current locations of the test cables <NUM> and plugs <NUM>. When the system <NUM> receives a request from the analytic computer unit <NUM> of the RANALYZER™ system <NUM> by way of a control signal to make a fiber connection to one of the monitor jacks <NUM>, it sends a reply signal to the analytic computer unit <NUM> acknowledging the request, but the robotic switch assembly <NUM> decides how to connect the plugs <NUM> so as not to tangle the cables <NUM>.

Parking positions for the test plugs <NUM> are used for tangle avoidance. If a request for connection is made by a control signal sent by the analytic computer unit <NUM> to the robotic switch assembly <NUM> that would cause a tangle to occur, then the robotic switch assembly and system <NUM> temporarily parks the test plugs <NUM> which are in the way of the other plugs <NUM> until all requested connections to the test jacks <NUM> can be made without tangling the test connection cables <NUM>.

After the connections have been made, the electronic circuitry <NUM> of the robotic switch assembly <NUM> sends a signal back to the analytic computer unit <NUM> of the RANALYZER™ system <NUM> which output cable <NUM> is connected to which monitor jack <NUM>. The analytic computer unit <NUM> of the RANALYZER™ system <NUM> works in conjunction with the robotic switch assembly and system <NUM> to allow for interrupts in data collection but maintain logical consistency of the data analysis and data collection.

The gripper mechanism <NUM> that connects and disconnects the plugs <NUM> from the jacks <NUM> has a cradle <NUM> that fits the bottom of plugs <NUM> and prevents movement in the X and Z directions. Pressure to depress a clip <NUM> that holds the plug <NUM> in the jack <NUM> is provided by a cam <NUM> that rotates in the X-Z plane by gearmotor <NUM> and worm drive <NUM>. As the cam <NUM> rotates, it depresses the clip <NUM> to release the plug <NUM> from the jack <NUM>. After the cam <NUM> has rotated, it also creates the grip pressure on the plug <NUM> to hold it in the cradle <NUM>. A two-position sensor <NUM> confirms clip release and cam retraction.

The exterior monitor jacks <NUM> on the reverse side of the panel <NUM> that supports the array of connectors <NUM>, <NUM> are routed to a series of preferably four (<NUM>) port MTP bulkhead connectors <NUM> that allow a sealed connection to the outside of the robotic switch assembly <NUM>.

A dual fan and filter system <NUM> is used to create a higher pressure inside the robotic switch assembly <NUM> than in the room in which it is located. This helps keep dust particles out of the assembly <NUM>. The slight positive pressure is achieved by having an input fan <NUM> and filters <NUM> combined with exhaust filters <NUM> only.

The robotic switch assembly <NUM> is designed to be rack mounted in a telecommunications rack. As shown in <FIG> of the drawings, the exterior housing <NUM> of the robotic switch assembly <NUM> includes slides <NUM> mounted on opposite lateral sides thereof, which mate with slides incorporated into the rack mount system (not shown). Also, a method of attaching a service-loop of fiber to the back of the housing (where the monitor fibers connect to the backplane of exterior monitor jacks) is provided. The combination of the slides <NUM> and the service loop enables the assembly <NUM> to be serviced without disconnecting the monitor fibers.

For machine service, which is expected to be every <NUM> relocations, there is a procedure to replace the probe fiber cartridge <NUM> and fan filters <NUM>, <NUM>. First, the robotic switch assembly <NUM> receives a control signal from the analytic computer unit <NUM> and is commanded to replace all test connection cables <NUM> to their home positions and the arm and gripper mechanism <NUM> to return to its home position. Then, the power to the assembly <NUM> is removed and the robotic switch assembly <NUM> is slid into its forward slide position. The top cover of the housing <NUM> is removed by removal of the mounting screws. The filters <NUM>, <NUM> on the front and rear sides of the assembly housing <NUM> can now be replaced. After replacement of the filters <NUM>, <NUM>, both ends of the probe fibers <NUM> are removed from their respective plugs <NUM>, carefully letting the fibers <NUM> fully retract, and then each port <NUM> is covered with a dust cap (not shown). Then the two screws on each side of the probe fiber slack panel <NUM> are removed and the panel <NUM> may be slid out of the housing <NUM> out of the robot. Replace with new panel and reverse the procedure, cleaning the ports and fibers before insertions. The service technician should then use a small vacuum to clean the corners of the robotic switch assembly <NUM> within the housing <NUM>, give a visual check for cleanliness and then reattach the top cover to the rest of the housing <NUM>. The robotic switch assembly <NUM> can then be returned to the rearward slide position in the rack (not shown) on which it is mounted and power may be reapplied to the assembly <NUM>. The arm and gripper mechanism <NUM> and test connection cables <NUM> may then be rehomed, if necessary, by control signals provided by the analytic computer unit <NUM> and received by the electronic circuitry <NUM> of the assembly <NUM>, and the robotic switch assembly is now ready for use.

Cameras <NUM> may be located on the inside of the housing <NUM> of the robotic switch assembly <NUM> to provide an inspection capability. Additionally, fiber inspection probes (not shown) and fiber cleaning mechanisms (not shown) may be included in the assembly <NUM>.

Backup power by way of a capacitor array (not shown) within the housing <NUM> is provided to complete a move and then position the gripper arm <NUM> to a safe position (preferably, its home position) if external power is lost.

Seismic sensors (not shown) may be included within the housing <NUM> and electrically connected to the electronic circuitry <NUM> so that the robotic switch assembly <NUM> does not attempt to make a connection between a test probe <NUM> and test jack <NUM> if the assembly <NUM> is shaking too much. The gripper arm <NUM> moves to a safe location (preferably, its home position) if vibration thresholds programmed into the electronic circuitry <NUM> are exceeded.

One or more temperature sensors (not shown) may be included within the housing <NUM> of the robotic switch assembly <NUM> and electrically connected to the electronic circuitry <NUM> to sense temperature extremes when the robotic switch assembly <NUM> is located in certain installations and possibly activate an internal heater (not shown) situated within the housing <NUM>.

Since the distance from where the four test connections cables <NUM> exit the probe fiber cartridge <NUM> to various ports in the panel <NUM> varies significantly the slack in each of the test connection cables needs to be independently controlled to prevent tangling with each other. This is accomplished through a system of fixed pulleys <NUM>, <NUM> and sliding pulleys <NUM> loaded by a constant force spring <NUM>. The pulley system for each test connection cable <NUM> are stacked on top of each other at the top of the unit as shown in Figures 16D. Each pair of test connection cables <NUM> exits the probe fiber cartridge <NUM> through a multi-roller output assembly, <NUM>. For each test connection cable <NUM> there is a series of four rollers <NUM> that both guide the test connection cable <NUM> in the proper direction and reduces the amount of internal friction in the probe fiber cartridge <NUM>. It is important to minimize the internal cartridge friction to allow the use of the minimum strength constant force spring <NUM> which minimizes the tension in the test connection cable. This minimizes signal loss and cable jacket fatigue. The rollers <NUM>, <NUM>, <NUM> and other slack system geometry are designed to prevent the test connection cables <NUM> from being subject to a bend radius smaller than the minimum allowable radius to prevent signal attenuation and cable jacket fatigue.

Upon application of power, a homing command needs to be issued to the robotic switch to zero all of the motion axes and initialize the rotating cam.

The robot operates by removing any/all of <NUM> specialized LC Duplex fiber optic connectors from home 'parking spaces' in the top center top of the panel array to any of <NUM> locations commanded by the RANALYZER server. There are <NUM> additional ports that can be used for diagnostic or advanced functionality. The process has four distinct steps:.

These four steps can be repeated and ordered utilizing a mapping algorithm to avoid cable tangling in order achieve any desired 4x192 port configuration. We will look them in reverse order.

Terms used for describing robot operation:.

In a preferred form of the robotic switch assembly <NUM>, the output test cables <NUM> can be connected to any of the interior monitor jacks <NUM>. This provides N x M (input x output) switching (where N and M are integers): the I and Q signals of any M of the N single or dual (uplink and downlink) monitor jacks <NUM> can be routed to the digital signal processor <NUM> or the optical-to-electrical converter <NUM>, if such converter <NUM> is used, of the RANALYZER™ system <NUM> for simultaneous analysis.

For the electronic version of the switch, mentioned in subsection b of this section above, configuring it for N x M operation also allows monitoring the needed RAN signals.

Depending on the number of test outputs and the configuration of REC-to-RE connections made by the robotic switch assembly <NUM>, as shown in <FIG>, it is possible to conduct various tests and diagnoses with the RANALYZER™ system <NUM> of the present invention.

It should be realized that, although an optical-mechanical robotic switch assembly <NUM> is described herein, an electronic switch assembly may be used in its place. This is especially realizable when the optical-to-electrical converter <NUM> is placed upstream (signal-wise) before the switch assembly <NUM>, or where the I and Q data is provided by the network <NUM> already in an electrical format and, thus, no optical-to-electrical converter <NUM> is required and an electronic switch device or circuit may be used to select the electrical I and Q data and provide this data to the digital signal processor.

Given that it is preferred that only M test ports <NUM> are measured at any one time (out of the larger number N), some method must be used to choose which ports <NUM> to measure. There are several methods used by the RANALYZER™ system of the present invention to do this, based on different circumstances and needed capabilities. Table <NUM> lists the diagnostic capabilities based on the number of connections to REs and RECs, which shows why the RANALYZER™ system <NUM> is designed to connect to <NUM> pairs of uplink & downlink connections between REs and RECs. Details about choosing ports to measure for different scenarios are explained below.

On receipt of an alarm from the network equipment monitoring system <NUM>
The port <NUM> related to the radio equipment <NUM> having a problem is the one to be measured. Additional ports <NUM> can be added to supplement this, as listed below. Downlink and Uplink
RAN problems are much more of an issue in the uplink, as a problem here can take out an entire sector (or perhaps even more), while downlink problems tend to be only for specific areas. The RANALYZER™ system cannot observe the RF environment for downlink signals, so why measure the downlink at all? This is because the downlink has useful information for measuring the uplink. This information includes:.

Control signals for allocating uplink transmissions. This also says when at what frequencies uplink transmissions are not allocated, which provides a convenient window for observing external interference as well as PIM products without the effect of uplink transmissions. By observing over a small window of time (e.g. several LTE frames), a spectrum almost clear of uplink transmissions can be assembled. This provides a much clearer picture of what is happening in the uplink spectrum that should not be there.

NACK/ACK ratio
NACK is short for "Not Acknowledged", i.e., a transmission that was not received properly, so it is Not ACKnowledged", while ACK is that the transmission is OK, and is therefore ACKnowledged. The "User Equipment" ("UE", which is a mobile telephone <NUM> or other device, rather than the base station <NUM>) transmits error correction and detection information along with the user data. Sometimes the error correction information is sufficient to correct the received information, but sometimes it is insufficient. When the user data is uncorrectable (as determined by the error detection information), the base station <NUM> transmits a NACK digital signal back to the mobile device <NUM> to tell the mobile device <NUM> to re-transmit the data. This happens commonly in mobile networks, as the UE moves and the power level received at the base station <NUM> changes. However, if the received power level is high, but the NACK/ACK ratio is higher than usual, this can be an indication that some kind of interference is happening. Timing reference
UEs use the base station signal as a timing reference, along with a "timing advance" command signal from the base station <NUM> to adjust the time that signals are transmitted. This allows the signals from different UEs, at different distances from the base station <NUM>, to arrive at the same time (or very closely in time). If a receive signal is observed to be at the wrong time, this may indicate a mis-configuration of a base station <NUM> or group of base stations <NUM>, or a UE that is transmitting at the wrong time. For PIM determination
Having knowledge of the downlink signal(s) allows for characterization of PIM in the uplink, and how it would change over time. This can take several forms:.

For external interference localization
Having access to uplink received signals at multiple locations allows a position estimate of that signal using several techniques, or a combination of them:.

Determining which Base Stations <NUM> are Connected to Which Fiber
When connecting the RANALYZER™ system to a communications network <NUM>, determining which radio equipment <NUM> and antenna <NUM> each fiber is connected to is a challenge. By decoding base station identification information (such as for LTE, the cellIdentity carried in System Information Block #<NUM> (SIB1), or the Physical Cell Identity (PCI) carried in the synchronization signals), a unique or near-unique identity can be associated with each RE. In many Equipment Monitoring Systems <NUM>, a report may be requested with detailed RE information, including accurate location information, the LTE cellIdentity, PCI, and other useful data such as the allocated frequencies and bandwidths used by the RE. In this case, matching this configuration information to the observed cellIdentities and PCIs, this configuration can be done automatically, or near-automatically. Verification of base station configuration
Base stations <NUM> have many configuration parameters that can be adjusted. Many of these can be observed in the transmitted information from the base station <NUM>, and can then be verified against expected values, either manually or automatically. Scanning
By scanning through all (or a subset) of uplink signals, RAN problems may be identified sooner than an alarm happens. This allows scheduling maintenance in a proactive fashion, improving RAN network quality and maintenance efficiency. Automatic Configuration of Switch Ports
There can be many different REC-to-RE connections available to the RANALYZER™ system. Manually configuring the system to know which port <NUM>, <NUM> is connected to which REC <NUM> and RE <NUM> would be a time-consuming and error-prone process. Because of this, the RANALYZER™ system automatically determines which port <NUM>, <NUM> is which, based on the following steps:.

Referring to <FIG>, using the example of the RANALYZER in a C-RAN context, the flow of data through the system, and the transformation of this data into information is as follows:.

<FIG> is explained here, with further details about each block elsewhere herein.

The Digital Signal Processor (DSP) <NUM> performs a variety of functions on the transport data received from a selected RE or REC, including:.

In a single C-RAN, measurements can easily be made on multiple REs <NUM> simultaneously, giving rise to the benefits listed herein. However, in many situations simultaneous (or near-simultaneous) measurements need to be made between different systems. This can be because of a variety of reasons, including:.

In these (and possibly other similar cases), some way of making simultaneous or near-simultaneous measurements is important. The near-simultaneous case can be fairly simple, depending on the timing requirements. A network message might be sufficient for this. However, for relative timing measurements between received signals, precise timing is essential, so a method of precise synchronization is needed. Two ways of doing this are:.

In a traditional RAN, a separate monitoring receiver or spectrum analyzer is sometimes incorporated to allow observation of the RF spectrum in the vicinity of the antenna <NUM>. Spectrum analyzers have been available for decades, and exist in a wide variety of form factors, generally with an electrical input, often connected to an antenna. The RANALYZER™ system <NUM> essentially incorporates the functionality of a spectrum analyzer, and extracts the spectrum information by examining the "I/Q vectors" that the Radio Equipment <NUM> and the Radio Equipment Controller <NUM> use to communicate with each other over the CPRI link. These I/Q vectors describe the analog signal as a function of time, and are well known to electrical and radio engineers, as well as mathematicians. In addition, multiple channels of spectrum analysis are preferably used simultaneously for analysis, for several purposes. These include:.

In a traditional spectrum analyzer, there is the concept of a "local oscillator", or L. , that can be used for examining different parts of the spectrum. In the Radio Equipment <NUM>, the frequency of that L. is fixed, which thus cannot be used for this function. Instead, RANALYZER™ system <NUM> uses Numerically Control Oscillator, or NCO, in the digital signal processor to provide this function digitally. In addition, this technique allows examining the spectrum in fine frequency detail, in an efficient way. See the section on Digital Signal Processing herein for more details on this subject.

In addition to directly examining the spectrum of the signal received by the Radio Equipment <NUM>, there are a number of benefits to examining the signal transmitted from the Radio Equipment Controller <NUM>, as well, which is performed by the RANALYZER™ system <NUM>. These include:.

There are a variety of displays shown on the display <NUM> that are useful for the engineer or technician using the RANALYZER™ system <NUM> of the present invention, including:.

In addition to saving spectrum traces and RTWP values in a memory <NUM>, the RANALYZER™ system <NUM> can also record the complex I and Q sample data from the Radio Equipment <NUM> into memories <NUM> and <NUM>, which data are used to create those traces and RTWP values. This allows the user to more closely examine what happened during the event, at a later time. This includes adjusting parameters such as Span and Resolution Bandwidth. Traditional spectrum analyzers may be able to save the traces, but do not allow adjusting these parameters after displaying the traces. Saving the I/Q data enables the user to play back the displays shown on the display <NUM> in slow-motion and, therefore, to be able to analyze bursty noise phenomena that are not perceptible by humans when played at real-time speed.

One of the difficulties of finding noise or interference is that the signal trying to be found (that noise or interference) is obscured by the traffic signals from the mobile phones <NUM>. If the SINR is very low or if there is very little traffic, this is not much of a problem, as the noise and interference will dominate the observed spectrum. However, in a significant number of cases, the (intermittent) problems manifest only when the system <NUM> is highly utilized. In those cases, it is important to be able to detect and analyze noise in the presence of signal. There are a number of possible ways to address this problem, including:.

Since noise and interference may vary with time, it can be useful for the system <NUM> to record in memory a number of spectrums. A good example of this is a stadium that has a base station with a PIM problem. Well before a game, there is essentially no downlink traffic, so there is essentially no PIM signal. As people arrive at the stadium, the traffic increases, and so does the PIM level.

However, there is a potential problem with this. Since we are building up the spectrum from looking at times and frequencies that the base station <NUM> has not told the mobile phones <NUM> to use, there can be a bit of a conflict. One would want to wait as long as possible to see the entire spectrum, but one also would like to see the changes in spectrum with time. By setting a threshold for how much of the spectrum the system <NUM> should accumulate before displaying on the display <NUM> (and possibly recording in memory) it, the user of the RANALYZER™ system can make a tradeoff between how much of the spectrum is shown on the display <NUM> versus how often it is shown. Alternatively, the user could specify how often to update the display <NUM>, regardless of how much of the spectrum has been accumulated at that time.

Also, since some of the noise can come from PIM, and since the PIM level varies with the power level transmitted by the base station <NUM>, it can be helpful to accumulate parts of the spectrum by the system <NUM> based on the transmitted power from that base station <NUM>. If the system <NUM> simultaneously records the power levels from the base station <NUM> while the system <NUM> is examining the "uplink" spectrum (from the mobile phone <NUM> to the base station <NUM>), the system <NUM> can sort those pieces of uplink spectrum into groups based on those power levels. The RANALYZER™ system <NUM> can then display on the display <NUM> the different spectrums as a function of power transmitted from the base station <NUM>. If the level of the unused uplink spectrum increases with the transmitted power from the base station <NUM>, this is a clear indication that PIM is present. If the relationship between these levels is the same as is expected from PIM (which is known from long experience by the mobile phone industry), this is an even stronger indication that PIM is present.

The RANALYZER™ system <NUM> of the present invention deals with potentially massive amounts of data. In the present state of the art for the CPRI standard, each of the optical connections <NUM>, <NUM> can carry <NUM> billion bits per second. The RANALYZER™ system <NUM> preferably has eight (<NUM>) optical inputs (i.e., the test connection plugs <NUM> of the robotic switch assembly <NUM>) (although the system <NUM> may be formed with more or fewer inputs), so there is the potential for <NUM> GB (Gigabytes) of data each second. If all of this was recorded, a one TB (Terabyte) drive would be filled in under one minute. Clearly, it is impractical to store and intelligently retrieve all this data. To deal with all this data, the RANALYZER™ system <NUM> uses the concept of a storage hierarchy with expert analysis and event-driven indexing, as illustrated in <FIG>.

The digital signal processor <NUM> (preferably, an FPGA) in the RANALYZER™ system <NUM> has several megabytes of high-speed static random access memory (SRAM <NUM>). The available storage capacity of the SRAM <NUM> is small compared to the overall storage needs of the system <NUM>, but is useful for buffering small amounts of I/Q data and a number of traces for storage in a local dynamic random access memory (DRAM) <NUM> coupled to the SRAM <NUM>, which can be several gigabytes. The DRAM <NUM> allows sufficient storage of I/Q data (several seconds) so that the spectrum can be examined by the system <NUM> in different ways, e.g. using different resolution bandwidths, on the same captured data. The DRAM <NUM> also allows storing high-speed spectrum traces, i.e. faster than the human eye can discern. This again allows more detailed inspection of the spectrum by the system <NUM> and a technician after-the-fact.

There is also a DRAM <NUM> in the analytic computer unit <NUM> or server <NUM> of the system <NUM>, which can also store high-speed I/Q data and spectrum traces, and can be somewhat larger in storage capacity than that of the DRAM <NUM> or SRAM <NUM>. This DRAM <NUM> allows storing of additional data while the Expert Analysis (see <FIG>) is being performed by the analytic computer unit <NUM> or server <NUM> of the system <NUM>. For a system <NUM> that is used at a macro-site, the DRAM <NUM> used for emulating a disk drive can provide more storage than is conveniently available with low-cost (e.g. <NUM> bit) CPUs. Local mass storage, such as from a flash memory device <NUM>, can also be used for buffering data for further processing.

More specifically, the system <NUM> of the present invention preferably includes the SRAM <NUM> in the digital signal processor <NUM>, the DRAM <NUM>, capable of more storage, connected to the digital signal processor <NUM>, the flash memory <NUM> connected to the digital signal processor <NUM>, and the DRAM <NUM> situated on the analytic computer unit <NUM> or server <NUM> and coupled to the DRAM <NUM> by way of a local or network connection. Furthermore, the system <NUM> preferably includes a high-speed solid state disc drive memory <NUM> and a large archive disc drive memory <NUM>, each of which is coupled to the DRAM <NUM> on the analytic computer unit <NUM> or server <NUM>.

Additional remotely located storage memory is also preferably provided by the system <NUM>. More specifically, off-site storage <NUM> of I/Q data, spectrum data, and other data (e.g. NACK/ACK ratio, what LTE cellIdentity applies to the I/Q and spectrum data) is provided through the private (or public) internet protocol network <NUM> and through outside servers <NUM> operatively coupled to the server <NUM>, as well as, optionally, a pool of storage devices or memories <NUM> connected to the system <NUM> through the network <NUM>.

Once the system <NUM> has identified an interfering signal or excessive noise, this is recorded in the Events System database (q. ) in the RANALYZER™ system <NUM>. To allow an operator of the system <NUM> to observe what caused the event in more detail or for automated post-processing, the captured I/Q data and/or spectrum traces (that were buffered in the RAM <NUM> or other media) are stored to the high-speed solid-state drive <NUM> forming part of the system <NUM> of the present invention.

While the speed of the SSD <NUM> is most useful, it is somewhat limited in storage capacity. When the data stored to the SSD <NUM> reaches some portion of the SSD storage capacity, then the data is off-loaded to a local hard drive <NUM> with higher storage capacity. In addition, the RANALYZER™ system <NUM> keeps track of the count of the number of occurrences of similar type events and preferably only records a (user-configurable) number of the same type of event. This reduces the storage requirements of the system <NUM> and also aids the user in filtering through large volumes of data to obtain actionable information with which to make a decision regarding how to resolve the service-impacting problem.

Additional storage can also be made available via the network connection <NUM>. This can be useful in a variety of ways, including:.

The system user can also manually archive events of interest, and reports created from those events, to a large local hard drive <NUM>, or other storage media, either local or connected via network <NUM>.

While the system <NUM> of the present invention is particularly interested in seeing the uplink spectrum, monitoring the downlink signal at the same time by the system <NUM> can also be helpful in a variety of ways, including:.

As can be seen in Table <NUM>: Most Common RAN Environment Problems and Related Network Notifications, there is a relationship between problems in the RAN <NUM> (Root Causes) and various indicators and alarms. An examination reveals that one can get similar indicators and alarms for different root causes. For example, External PIM and External Interference can give the exact same alarms. Thus, the maintenance engineer or technician knows there probably is some problem in the RAN <NUM>, but not what to fix.

It should be noted that Table <NUM> refers to antenna <NUM> and antenna <NUM>, which is common for LTE deployments. However, more than two (<NUM>) antennas for an RE <NUM> is also common, and a similar set of conditions happens in this case.

To address this, the RANALYZER™ system <NUM> analyzes the uplink signal received by the Radio Equipment <NUM> to give a much higher confidence of what is causing the problem, and therefore what needs to be fixed. The system <NUM> does this with a multi-step testing approach listed below and shown in <FIG>. While any one of these tiers is useful for determining the cause of RAN problems, the combination of them is even more powerful, as it allows the system <NUM> to have high confidence quickly, as well as efficiently screen for intermittent problems.

The first test of the system <NUM> is just to analyze the alarms and indicators that are mentioned in Table <NUM>, for the Radio Equipment <NUM> in question. While these are not definitive results, they do indicate that there likely is a problem, and give some hints about what the problem may be.

Referring to Box <NUM> (Step <NUM>) on <FIG>, the system <NUM> includes Table <NUM> as a lookup table stored in memories <NUM> and <NUM>. This table lists the most likely problems given different combinations of alarms or indicators. The system <NUM> compares received alarms with this table in memory to determine the most likely and possible causes of the alarm. This information is then:.

Key to this capability is integration with the alarming system <NUM> in the network <NUM>, for example, subscribing to the same messages that relevant technicians get when there is an alarm, then parsing the resulting messages for the useful alarm information.

To address this, the RANalyzer analyzes the signal received by the Radio Equipment to give a much higher confidence of what is causing the problem, and therefore what needs to be fixed. The system does this with a multi-tiered screening approach listed below and shown in <FIG> While any one of these tiers is useful for determining the cause of RAN problems, the combination of them is even more powerful.

Referring to <FIG>, Box <NUM> (Step <NUM>), the alarms and indicators from the network equipment monitoring system <NUM> are created for a specific LTE cellIdentity. The cellIdentity is used to tell the switch assembly <NUM> of the present invention which circuit to connect to (see also <FIG>). These alarms are the triggering event that commands the switch <NUM> of the system <NUM> to automatically connect to a circuit, and for the RANALYZER™ system <NUM> to begin its analysis to either determine the root cause of the problem or determine that the alarm is a false alarm.

Once alarms have been received and REs <NUM> automatically selected by the switch assembly <NUM> for analysis, the system <NUM> captures (i.e., extracts) the uplink I/Q data from the RE <NUM>. The system <NUM> then proceeds to <FIG> Box <NUM> (Step <NUM>), and collects a variety of data, specifically it:.

Simultaneously, I/Q samples are captured from the matching downlink connection using the switch assembly <NUM>. From these samples, the ACK and NACK messages are extracted and counted (see the section "Combining Spectrum Analysis and Receiver Functions" for more details about this). If the NACK/ACK ratio is too high, this is an indication of bursty noise or interference that is affecting that RE.

These data are referred to herein as RFX Data in Box <NUM> (Step <NUM>) of <FIG>.

In <FIG>, Box <NUM> (Step <NUM>), the system <NUM> then examines that RFX data, looking for evidence of any type of interference (PIM, rogue transmitters, or other), as listed above. Meanwhile the system <NUM> also stores the spectrum and related data, I/Q data (from both downlink and uplink) and NACK/ACK ratio in memories <NUM> and possibly <NUM> in case it is needed for further analysis and reporting in later steps of automatic analysis. The evidence being sought is spectrum or spectrogram data that does not fit the profile of normal UE transmissions (e.g., spectrum data that does not conform to the LTE uplink resource grid). If conditions result in a comparison that exceeds one of the thresholds or limits, the system records this as an Event.

If any one of the above conditions results in a comparison that exceeds one of the thresholds or limits as shown in Box <NUM> (Step <NUM>), the system <NUM> stores this occurrence in the Events System database (q. ) in the archive disk <NUM>, along with the RFX data, the I/Q data, NACK/ACK ratio and the cellIdentity of the RE being measured. The system <NUM> then proceeds as shown in <FIG>, Box <NUM> (Step <NUM>). These data are thusly available for analysis per the methods below (q. ) for diagnosing the root cause of alarms with high confidence.

If there is no pattern match over a user-selectable time, the system proceeds as shown in <FIG>, Box <NUM> (Step <NUM>).

This process performed by the system <NUM> of the present invention then can automatically repeat for different alarms for the same Radio Equipment <NUM> (perhaps for different sectors or bands, for example), or for other Radio Equipment <NUM>.

For more details on this topic, refer to the section "Getting Uplink Spectrum without UE Traffic".

This could be performed in a real-time way by the system <NUM>, and thus would be part of all spectrum screening. However, some versions of the RANALYZER™ system <NUM> may not be capable of performing the decryption necessary to determine silent periods in real-time. In this case, then I/Q data must be captured into memories <NUM>, <NUM> or <NUM>, and analyzed in post-processing mode, either locally or in a remote system connected via a network <NUM>.

One limitation of removing UE traffic from a cell is that there are other nearby UEs that may also be transmitting to other REs <NUM>. If these are close to that other cell, their received power at the cell of interest may be low enough that they can be ignored. However, if they are at the edge between cells, the received power levels may be high enough to seem like PIM or external interference. To alleviate this, since the RANALYZER™ system <NUM> can connect to multiple REC-to-RE connections, the system <NUM> may perform the same process using the observed scheduling information from adjacent cells as well, looking for times and frequencies where both the cell being tested and the adjacent cell have no scheduled uplink traffic.

In the case of the RANALYZER™ system <NUM> used in the Macrosite context (see <FIG>), this can be accomplished by scheduling those sites to capture and store I/Q samples in memory <NUM> at the same time, and then sending either the I/Q samples or preferably the extracted scheduling information to a system <NUM> at a central location (preferably the site for the sector being tested) via a network, such as network <NUM>, for processing.

However, there are a variety of reasons why this functionality may not be available, including very heavy traffic during all times when the interference is present, such as during major sports games, precluding any time/frequency pair (LTE Resource Block) when there is no traffic. The available hardware may also be insufficient for eliminating the UE traffic as well, for some versions of the system. In Box <NUM> (Step <NUM>) this determination is made, by determining if a user-adjustable portion of the spectrum has been obtained without traffic in a user-set perioed of time. In these cases, the system uses alternative, somewhat less effective or efficient means to see the noise in the presence of signal, including RTSA functionality, percentile traces, and EVM spectrum.

Another alternative that the system has available for cases where it is difficult to eliminate the uplink traffic from the spectrum display is to analyze the modulation format and error correction scheme (so-called Modulation and Coding Scheme, or MCS, in LTE) that the base station tells the UE to use, and then compare this among multiple UEs for several REs. This is shown in <FIG>, Box <NUM> (Step <NUM>) to determine if this step is necessary, Box <NUM> (Step <NUM>) for the analysis process and Box <NUM> (Step <NUM>) for the report sent to the Equipment Monitoring System <NUM>.

The system determines the MCS by examining the Downlink I/Q samples that have been captured for the problem RE, decrypting the PDCCH commands (see the section on Receiver Processing herein for more details about this), and then decoding the MCS part of the PDCCH command that contains the commanded MCS value.

In LTE, the MCS can take on values from <NUM> to <NUM>, where lower values indicate lower-order modulation and more error correction, and therefore lower throughput but more robustness to noise. In the case where many REs are relatively close to each other, such as may be the case in a stadium, the distribution of MCSs used should be similar among all REs, or at least all REs in a similar position (such as inside the stadium or in the parking lot). If some REs show a lower average peak MCS being used, this indicates that there is some reason that RE can't receive signals as well, such as external interference. There could be other reasons that a single RE has this problem, such as a bad antenna, but if multiple nearby REs have the same problem, this is more likely to be a case of external interference-for example a jammer that someone brings to the game. The system compares the average MCS among many REs around a stadium to create a "heat map" that gives a general indication of where the interference source is located.

Referring to <FIG>, Box <NUM> (Step <NUM>), once the UE traffic has been removed, and a traffic-free spectrum obtained, the system <NUM> then compares the observed uplink spectrum to reference spectrums, or parametric descriptions of spectrums, from a lookup table stored in memories <NUM> and <NUM>. These can include spectrums that both describe PIM, as well as rogue transmitters. The system <NUM> compares the calculated uplink spectrum received from the RE <NUM> and these stored reference spectrums to see if there is a match.

If a good match is found to PIM, the system <NUM> records and stores this as in the Event System database (q. ), and then proceeds as shown in Box <NUM> (Step <NUM>) in <FIG>. If not PIM, and if the spectrum matches one of the stored known rogue transmitter types listed below, the system <NUM> records and stores this in the Event System database (q. v, and proceeds as shown in Box <NUM> (Step <NUM>) in <FIG>. However, if the traffic-free spectrum shows no signal above the stored user-set noise level, that is useful information as well. In this case, the system <NUM> creates and stores this information in the Events System database (q. ), and also proceeds as shown in Box <NUM> (Step <NUM>) of <FIG>.

The methods used by the system <NUM> to find the non-conforming data include:.

Details of what the reference spectrums, or parametric descriptions of these spectrums, are listed in the relevant sections below.

The spectrum of PIM has a characteristic shape, making it identifiable by a trained observer, at least after some averaging is applied by the system <NUM> to the spectrum to remove variations. The spectrum shape for PIM can take on several similar forms depending on the relative frequencies of the signals causing the PIM as well as the Radio Equipment receive frequency. These forms are generally the slope of the spectrum, which can be rising or falling, over a range of known frequencies. If the user has configured the RANALYZER™ system <NUM> with what frequencies and bandwidths of signals are present on each antenna <NUM>, either by manual entry into a configuration database or via a report from the Equipment Monitoring System <NUM> (see the subsection Determining which Base Stations <NUM> are Connected to Which Fiber for details on this), as well as nearby antenna systems <NUM>, the RANALYZER™ system <NUM> will calculate the PIM characteristics that those frequencies and bandwidths would cause, and compare the received spectrum to that calculation. If the RANALYZER™ system <NUM> is not so configured (i.e., with knowledge of the transmit frequencies of REs <NUM> that is connected to), the RANALYZER™ system <NUM> cannot compute a specific reference spectrum, since it does not know how to combine the different signals. However, all types of PIM have a similar characteristic, in that there is a significant slope to the spectrum after averaging the spectrum from the RE <NUM> over time (there may be a slope before averaging due to multipath, and thus the system <NUM> applies averaging for this test). The slope can vary with the relevant transmit frequencies, and can be positive or negative. So, in this case, the RANALYZER™ system <NUM> does not compare the spectrum to a stored reference spectrum, but rather just calculates the slope of that spectrum. If the slope is relatively large (positive or negative), this is an indication that PIM is present. This process is somewhat slower and less precise than comparing to a specific stored computed reference spectrum, but does not require configuration of the RANALYZER™ system <NUM> with specific radio frequency information about RF transmitters. Because of the imprecision of this technique, the system <NUM> would have to consider all possible sources of interference, slowing the diagnostic process, so the system <NUM> preferably uses the radio configuration information in the improved process mentioned above.

If PIM is detected on multiple antennas <NUM> for a specific Radio Equipment <NUM>, at similar levels, it is very likely that the PIM is coming from an external source, such as a nearby metal junction that is rusty. Because of this, the system <NUM> records and stores the spectrum from all MIMO branches of the RE antenna <NUM>, as well as the relative power levels among them. This is used for analyzing and reporting of internal or external PIM, along with the extended PIM analysis listed below.

The most common types of rogue transmitters and their associated spectrum characteristics are listed in Table <NUM>.

These characteristics are stored in memories <NUM> and <NUM> in the system <NUM> as reference spectrums, and the received spectrum, with UE transmissions removed, is compared to these stored reference spectrums. If a match is found, this is displayed and reported to the technician who will be finding the rogue transmitter. This helps the technician by giving an indication of the specific type of device to be looking for.

The pattern matching is easily extended if the characteristics of other types of interference become known. While some signals are quite stable with time, such as the common case with cable TV leakage, others can come and go. The Events System database (q. ) in the analytic computer unit <NUM> in the RANALYZER™ system <NUM> helps keep track of such events.

When the system <NUM> detects that there is a received signal level above the stored, user-set threshold, but does not match one of the stored known patterns, this is most likely a type of rogue transmitter for which the system does not have a stored reference spectrum or parametric description. However, there are two other cases that need to checked by the system <NUM> - a UE that is transmitting bad signals (distorted, wrong power level, or incorrect timing advance), and an unmanaged repeater (or bi-directional amplifier) that is causing receive signal levels to be too high at the RE <NUM>. These will be covered in more detail in the below section on Extended Analysis of External Interference from Rogue Transmitters.

Referring to <FIG>, if the PIM is detected on just one of the receive antennas <NUM> for a particular sector and band, it is more likely that the PIM is coming from an internal problem, either in the cable from the Radio Equipment <NUM> to the antenna <NUM>, or in the antenna <NUM> itself. However, there are situations where externally created PIM is polarized, and (since antennas <NUM> are often polarized orthogonally) it is possible that external PIM could be seen in one antenna <NUM> but not the other if it were at a low level (close to the noise floor of the RE <NUM>) and of a similar polarization to just one antenna <NUM>. Thus, while it is likely that the PIM is coming from an internal source in this case, additional testing is required to make this a definitive judgment.

Once the system <NUM> has identified PIM as the likely cause of the problem, further tests are performed by the system <NUM> to verify that PIM is actually present and locate the source of it.

The PIM level in the uplink varies as a strong function of the downlink transmitted signals, especially the power level. The system <NUM> uses this to determine if the source of the PIM is internal or external to the cable and antenna system connected to the RE <NUM>. It is important to know if the PIM is internal or external, as the troubleshooting and repair process is very different for these two cases, and performing the wrong corrective action is very expensive.

Referring to <FIG>, Box <NUM> (Step <NUM>), the system <NUM> determines if PIM is internal or external with high confidence by using the following steps:.

There is also a somewhat unusual case where the pattern matching by the system <NUM> between MIMO antenna branches fails (i.e., there is no match). This is where there is an external PIM source that is polarized, and the polarization is spatially aligned with just one MIMO branch of the antenna <NUM>. Fortunately, cases where this happens are rare. Somewhat less rare is the case where the external PIM is polarized, but not aligned with any particular MIMO antenna <NUM>. Also, if there are more than two MIMO antenna branches for one RE <NUM>, the antennas <NUM> obviously cannot all be orthogonal, since they are pointing in the same direction. These additional antennas <NUM>, however, can give additional confidence in the PIM being internal or external, since a polarized external PIM source would show up in all antenna branches that have the same, or similar, polarization.

Because it can be difficult to find external PIM sources, knowing if there is any polarization to it can be helpful in knowing what to look for, as there will be a physical feature that is at that angle. For example, if the polarization is known to be vertical, it is unlikely that horizontal metal flashing could be the cause.

The system <NUM> determines the polarization angle for external PIM by:.

Sometimes I/Q analysis of PIM by the system <NUM> may not show the PIM problem, due to a variety of factors. These can be that the PIM is intermittent, or that it is hidden by other received signals. Because of this, if the result of the Internal or External PIM determination by the system <NUM> did not show PIM, the system <NUM> performs an additional test, shown in <FIG>, Box <NUM> (Step <NUM>). See the section on Automatic Tests during the Maintenance Window for further details about how the system <NUM> performs this test.

If the RANALYZER™ system <NUM> does not find PIM during this additional test (see <FIG>, Box <NUM>, Step <NUM>), this information is stored in the Event System database (q. The I/Q data that was stored in memories <NUM> and <NUM> during the initial screening for PIM is archived to memories <NUM>, <NUM> and <NUM>, and a report is sent to the Equipment Monitoring System <NUM>. If the system <NUM> does find PIM during this test, the system <NUM> proceeds as shown in <FIG>, Box <NUM> (Step <NUM>), to determine the location of the PIM source.

If no PIM is found from this test, the system proceeds as in <FIG>, Box <NUM> (Step <NUM>), as this is so unusual that a human being needs to be involved with discovering the root cause. To aid this process, all of the captured I/Q data from the above tests is archived into memories <NUM>, <NUM> and <NUM>, and an electronic report is sent to the Equipment Monitoring System <NUM>. This report describes the tests and the storage location of the I/Q data. By storing the RE that's been tested along with the spectrum and I/Q data, that person has a wealth of data to help with the troubleshooting process.

Referring to <FIG>, Box <NUM> (Step <NUM>), the last step in diagnosing PIM is to determine its location. This is accomplished by scheduling an out-of-service test performed by the system <NUM> during a maintenance window. The method used by the system <NUM> by which distance to PIM is accurately determined is discussed below in the section on Distance to PIM. Results of this measurement are saved in the Events System database, in memories <NUM>, <NUM>, and <NUM>. A report is then set to the Equipment Monitoring System <NUM>, as explained below.

Referring to <FIG>, Box <NUM> (Step <NUM>), based on the tests performed by the system <NUM> shown in <FIG>, in Boxes <NUM>, <NUM>, <NUM> and <NUM> (Steps <NUM>, <NUM>, <NUM> and <NUM>, respectively), an electronic report is sent to the Equipment Monitoring System <NUM>. This is commonly then forwarded to the responsible person for either corrective action or further analysis. Reporting when PIM has not been confirmed is explained above.

Referring to <FIG>, signals from rogue transmitters often have characteristics that can be determined in a variety of ways. These characteristics can create higher confidence in the determination of the type of signal causing the interference, and can be used to help build a library of unknown signals which is stored in memories <NUM> and <NUM> in the system <NUM>. When corrective action is taken, the type of device causing the rogue transmission can then be manually entered by the technician discovering the rogue transmitter into the RANALYZER™ system <NUM>. This is then stored with the captured I/Q data and signal characteristics in memory <NUM>. This then expands the number of rogue transmitter types known, helping the technician correcting a problem by letting them know what to look for. In Boxes <NUM> (Step <NUM>) and <NUM> (Step <NUM>) in <FIG> the system <NUM> determines these characteristics.

More important than diagnosing the type of rogue transmitter is providing an estimate of its location so that a human being can precisely locate it and mitigate it. The detailed methods to locate the emitter are described in the section Interfering Emitter Location; below are described the steps the system uses to capture data for these methods.

Referring to <FIG>, Box <NUM> (Step <NUM>), the system <NUM> identifies REs <NUM> that are physically nearby the problem RE <NUM>. These can be adjacent sectors or nearby cells. The fundamental concept is to gain as much data about the location of the interference source as possible. Once the useful nearby REs <NUM> have been identified, the system <NUM> commands the switch <NUM> to connect to the RE-to-REC connection, and observe uplink and downlink I/Q samples.

In <FIG>, Box <NUM>, if a vehicle, either autonomous (such as a drone) or manned, is available to be dispatched to the site, this is done.

In <FIG>, Box <NUM> (Step <NUM>), the system <NUM> captures I/Q samples from all of the related REs <NUM> found in Box <NUM> (Step <NUM>).

In <FIG>, Box <NUM> (Step <NUM>), the system <NUM> verifies that interference is present in the problem RE <NUM> at the moment before trying to locate it. If the answer is no, the interference is probably intermittent, so the system <NUM> continues to look for the interference for a user-selectable period of time (<FIG>, Box <NUM>, Step <NUM>). If that period of time is not exceeded, the system proceeds to Box <NUM> (Step <NUM>) to relocate any dispatched vehicle (see <FIG>, Box <NUM>, Step <NUM>). If the time has been exceeded, the system <NUM> proceeds to Box <NUM> (Step <NUM>), where it then checks if there is any other process that needs system resources, such as connections to uplink or downlink fibers <NUM>; this can happen if another alarm has been received or if more than one user is operating the system. See the section on Multi-user Capability for more details about this. If system resources are not needed for other processing, the system <NUM> again relocates any autonomous vehicle that has been dispatched from Step <NUM> (Box <NUM>, Step <NUM>) and continues looking for the interference, repeating until the user-selectable period of time passes. However, if the time limit has passed, and system hardware is needed for other tests, the system <NUM> stores this in the Event System database, adds this to a list of measurements to be made (also stored in the Events System database) when resources are available, and reports what measurements have been made, as well as the updated list of measurements to be made, to the Equipment Monitoring System <NUM> (Box <NUM>, Step <NUM>). In any case, when the interference is seen in the original RE <NUM>, as well as when it is not seen, this information is stored in the Event System database of the system <NUM>. This is because it is important to know when interference will be present when a person is hunting for the source of the undesired signal.

In <FIG>, Box <NUM> (Step <NUM>), if the result of the decision in Box <NUM> (Step <NUM>) is that interference is detected in the original RE <NUM>, the system <NUM> then proceeds to Box <NUM> (Step <NUM>), where UE traffic is removed from all observed uplink signals, pursuant to the process and circuitry in the section Getting Uplink Spectrum without UE traffic herein.

In <FIG>, Box <NUM> (Step <NUM>), the location of the source of the undesired signal is estimated by the system <NUM>. The details of this method are described in the section Interfering Emitter Location herein. As above, the system then proceeds to Box <NUM> (Step <NUM>) and reports the results of the location estimate to the Equipment Monitoring System <NUM>.

Referring to <FIG>, when the result of <FIG>, Box <NUM> (Step <NUM>) is that no signal was detected, a probable reason is that there is a UE that is transmitting bad signals (distorted or wrong power level). This may be due to the UE itself, or due to an unmanaged repeater (also called a Bi-Directional Amplifier, or BDA). It should be noted that a BDA may oscillate and create its own signal, as shown in Table <NUM>, or they may just make a normal (or nearly normal) looking signal, but the signal is too strong and cannot be power-controlled to a low enough level by network commands. This is a somewhat rare occurrence, but can happen when the BDA is close to the network antenna <NUM>. This circumstance can create a high RSSI alarm and it will be detected by the RTWP screen of the False Alarm Screening protocol shown in <FIG> and described elsewhere herein.

When all the UE traffic is removed, then the bad signal may also be removed (or sufficiently removed) that there is nothing (or nothing sufficient) left to detect. The system <NUM> checks for this by examining the spectrum for each UE independently. The specific steps for this are:.

If the results of the test performed by the system <NUM> in <FIG>, Box <NUM> (Step <NUM>) is that no RFX event has been detected, then it is likely that the problem signal is intermittent, or there is a false alarm.

Intermittent problems and false alarms are a significant problem in diagnosing problems in the RAN <NUM>. PIM is often intermittent. In one case, the non-linear junction that is causing the PIM may be made to contact or separate, depending on the temperature or wind conditions. Monitoring the signal by the system <NUM> from the RE <NUM> over hours or days will make this obvious, especially using the information recorded in the Event System database of the RANALYZER™ system <NUM>; see the section on Events System for more details about this. External interference may also be intermittent, or even mobile. Being able to monitor when the interference happens can give clues to its source, such as a wireless microphone used in church services. This can also give clues to finding a mobile interferer, by determining times and location when and where it is stationary. Such is performed by the system <NUM> of the present invention.

In this circumstance, the RANALYZER ™ system <NUM> continuously monitors the signal and performs the following actions, as shown in <FIG>:.

If PIM is suspected, a definitive test performed by the system <NUM> can be scheduled during a maintenance window. By effectively disconnecting the base station <NUM> from the network <NUM> (after making sure no emergency calls (e.g. <NUM>) are in progress), a test signal can be requested by the system <NUM> from the network <NUM>. This signal is often called "OCNS", but is simply a high-power test signal that can be turned on and off. If there is no traffic, while the transmit power is low there should be no indication of PIM. If transmit power is high, which the OCNS signal will cause, the PIM level should be high. If these conditions are met, there is very high confidence that PIM is present. This procedure is undertaken by the system <NUM>. Additional processing by the system <NUM> can help determine if the PIM is internal or external, as mentioned elsewhere herein.

In addition, these tests may be periodically scheduled by the system <NUM> even if PIM is not suspected at a site. This would allow tracking the levels of PIM, which in many cases degrades over time. This is especially true in locations near the ocean, where salt water spray can cause significant corrosion. As the PIM level degrades, maintenance of the antenna or cable system can be scheduled at a convenient time, before the PIM starts to affect the capability of the base station <NUM> to connect and maintain calls and transfer data at optimum rates.

To classify interference sources not readily classifiable using conventional DSP algorithms, such as ones designed by humans based on heuristics provided by human experts in the problem domain, the RANALYZER™ system <NUM> uses machine learning techniques, including artificial neural networks.

The interference source classification problem is related to the modulation classification problem, to which neural nets have been applied by others, including:.

The RANALYZER™ system <NUM> utilizes these and exploits the LTE frame structure to enable real-time processing within economical resource limits, as shown in <FIG>.

The RANALYZER™ system <NUM> applies Convolutional Neural Networks (CNNs) in various ways, including:.

These input data from blocks <NUM>, <NUM> and <NUM>, or alternatively from the Analytic Computer Unit <NUM> are each fanned out into multiple CONV* layers <NUM>. Each CONV* layer <NUM> includes a number of sub-layers, of type convolution, nonlinear activation ("ReLU"), and down-sampling or pooling ("POOL"). The exact number of each of these sub-layers and their interconnection is stored in the CNN library <NUM>, and loaded into the CNN <NUM> in the Digital Signal Processor <NUM> based on the current scenario (see block 1a, Step <NUM>, and the text related thereto for more details about scenarios).

The outputs from each set of CONV* blocks <NUM> is then fanned in to respective FC* layers <NUM>, one each for complex I/Q samples from block <NUM>, Spectrum Traces or 3D histograms from block <NUM>, or spectrums of LTE symbols from also block <NUM>. Each FC* layer contains a sequence of Fully-Connected layers, the number of which and the dimensions of which are stored in the CNN library <NUM> and loaded into the CNN <NUM> based on the current scenario.

The outputs of the respective FC* layers are then feed into respective Class Ranking blocks, <NUM> for LTE symbols, <NUM> for spectrum traces or 3D histograms, or <NUM> for complex I and Q samples. The Class Ranking blocks each identify several likely emitters or other problem sources, along with confidence metrics.

The outputs of the Class Ranking blocks <NUM>, <NUM>, and <NUM> are combined in the Decision Logic block <NUM>, which combines the likely emitter estimates and confidence metrics, along with weighting factors supplied from the CNN Library <NUM> to arrive at a final set of likely emitter estimates along with confidence metrics. These are then sent to the Analytic Computer Unit <NUM> for storage in the Event System (q. ) database and therefore archiving in memories <NUM>, <NUM>, <NUM>, or <NUM>; display to the user on Display <NUM>; and report generation to the Equipment Monitoring System <NUM>.

With this circuitry, the RANALYZER™ system <NUM> is able to perform processing on both wide and narrow spans (in time and/or frequency), with both fine and coarse resolutions (also in time and/or frequency).

While one dimensional (<NUM>-D, i.e. pure time domain or pure frequency domain) data, across a narrow span, with coarse resolution, can feasibly be processed in real time by software on a general-purpose processor, this will rarely be adequate to classify sources of interference not readily classifiable using conventional algorithms.

Moving to <NUM>-D (joint time-frequency) data, wide spans (e.g. an entire LTE frame) and/or fine resolutions (e.g. the LTE subcarrier width of <NUM>, or less) requires hardware acceleration, for which the RANALYZER™ system <NUM> uses the Digital Signal Processor <NUM>.

It should be noted that CNNs are structured in "layers" of arbitrary dimensionality. The greatest processing load is presented by the convolutional ("CONV") sub-layers and the fully connected ("FC") sub-layers. The CONV layer processing occurs nearer the CNN inputs and is well structured, thus naturally amenable to implementation in the Digital Signal Processor <NUM> that provide those inputs. The nonlinear activation ("ReLU") and down-sampling (or pooling, "POOL") layers are much simpler in comparison, and are also included in the Digital Signal Processor <NUM> to allow easy interconnection with the FC* layers <NUM>.

By selecting CONV filter kernel widths and so-called strides based on the LTE frame structure (e.g. frequency kernel width of <NUM> LTE subcarriers, and stride of half the filter width for <NUM>% filter overlap), the CONV, ReLU and POOL layers are all easily included in the Digital Signal Processor <NUM>.

The data reduction thus achieved reduces the size of the FC layers required, enabling them to be implemented either in the Digital Signal Processor <NUM>, or in in the Analytic Computer Unit <NUM>. <FIG> shows these in the CNN block <NUM>, however moving these to the Analytic Computer Unit <NUM> does not affect the overall scope of the present invention. TheClass Ranking blocks <NUM>, <NUM>, and <NUM>, as well as the Decision Logic block <NUM> also may easily be implemented in the Analytic Computer Unit <NUM>, again with no impact on the overall scope of the present invention.

Due to the large number of emitter types, a library <NUM> of neural network connections and other parameters is used for different scenarios. This reduces the required complexity of the CNN, as there may be hundreds of different emitter types, and a simple pre-classification, such as based on the frequency band of the RE can easily reduce the number of possible emitters that could be causing the interference, thus greatly simplifying the CNN needed for each scenario.

The data from the unknown signal is fed to the neural network <NUM>, along with a selected entry from the library of neural network <NUM> connections to use, based on the current scenario. The CNN then indicates the best estimate of what type of emitter is causing the problem, from the ones that it has been trained on for that scenario. The CNN also provides a confidence metric for the most likely emitter, as well as other possible emitter types with sufficiently large confidence.

The library <NUM> is created outside the RANALYZER™ system <NUM> by applying the captured complex I and Q samples to a neural network circuit <NUM> that is set to learn that signal type. The more complex I and Q samples from similar types of rogue transmitters that are available, the better this neural network circuit <NUM> will be at recognizing that signal type. Since various RANALYZER™ system <NUM> installations are connected via a Private Internet Protocol Network <NUM>, they can potentially monitor hundreds of thousands of receivers, a large set of captured I/Q samples is available for this learning function. This learning processes then updates the library <NUM> in the various RANALYZER™ system <NUM> units.

It should be noted that the system <NUM> provides data to the CNN in a variety of forms, including complex I and Q samples, complex outputs of an FFT performed on those samples, the log of the magnitude of the FFT outputs, cepstrums (the inverse FFT of the log of the FFT of the complex I and Q samples), and complex LTE symbols. The Digital Signal Process <NUM> has sufficient capability for creating all of these data forms.

One of the data forms the system <NUM> provides to the CNN is a 3D histogram of the spectrum traces. Real-time spectrum analyzer displays show a color-coded spectrum display, based on a histogram of the number of observances at each power level across the frequency range. This form of spectrum analysis which is performed by the system <NUM> enables users to see lower-power signals in the presence of bursty, higher-power signals. This form of analysis is ideal for detecting interference in the presence of LTE UE traffic because LTE UE traffic occurs in bursts of energy (relative to human perception). Such analysis is performed by the system <NUM> of the present invention. See the sub-section on Percentile Traces in Signal Displays section for more details about this.

Real-time spectrum analyzers color-code the vertical power histograms for human perception. The system <NUM> of the present invention uses the histogram data directly, by feeding this information into a pattern-matching neural network <NUM>. Again, the neural-network circuit <NUM> is trained based on previously captured 3D histogram data, from known interference types stored in memories <NUM>, <NUM>, <NUM> or <NUM>. In any case, the library <NUM> of neural-network circuits <NUM> is made available to all RANALYZER™ systems <NUM> connected in a network and exchanging information and data, so that an interference type can be recognized anywhere in that network.

The RANALYZER™ system <NUM> does not just show the spectrum and identify signals - it also keeps track of when various things happen (called Events), and stores these in a database. This database is distributed among the local system <NUM> on disk <NUM> and other RANALYZER™ systems <NUM> on disks <NUM>, as well as central storage <NUM>. A wide variety of information is stored, and a facility is provided to filter and sort the data to find what's helpful for any condition. A wide variety of events are detected by the system <NUM>, including:.

In addition to simply detecting these events, further processing performed by the system <NUM> of the present invention can greatly increase the usefulness of the information. Useful processing performed by the system <NUM> includes:.

While simply identifying problems is very useful, for an organization to effectively deal with, and ultimately fix, those problems, some kind of report needs to be created. To speed this process, the RANALYZER™ system has several mechanisms for automatically creating reports and useful parts of reports:.

The RANALYZER™ system <NUM> also allows multiple people to do these functions - observing both live and stored spectrums, spectrograms, and RTWP versus time and difference in RTWP versus time graphs. Other data recorded in the Events System database at the same time can also be observed, as well as recreating spectrums from stored I/Q data for additional analysis. This is because a C-RAN location may have hundreds of base station connections at one place, and multiple problems may be occurring at the same time.

The system <NUM> may also being doing an automatic diagnosis at the same time a user is looking at the spectrum (e.g.) from different REs. In this case, the automatic operation of the system can be considered a "user", even though no human is involved, since the automatic operation also consumes system resources such as connections to REs.

It is helpful to have an estimated location for the junction causing the observed PIM, as this aids finding it and fixing it. There is a well-known method for distance-to-PIM (DTP), which can also be applied in the case where there are REC-to-RE connections. However, this method has a significant limitation in this environment, in that there is very little bandwidth available-leading to insufficient resolution for the position estimate.

A problem with distance-to-PIM (DTP) measurements using the RE-to-REC connection using the conventional method is that with the typical RF bandwidth available in remote radio heads, e.g. <NUM> or <NUM>, the distance resolution available is very limited. A simple estimate of this resolution is <NUM>/RF bandwidth, or <NUM> to <NUM> feet for <NUM> or <NUM> bandwidths, respectively. Somewhat better resolution may be available via interpolation or other means of extracting slightly better information from the same method, but to get to the desired resolution of one foot or less, something better is needed.

There are other methods which may be performed by the system <NUM> to estimate time delay that do not rely on bandwidth. For example, counting the periods of a well-known frequency can give a very precise measurement of time delay, while requiring essentially no bandwidth at all. A modern implementation of this measures the phase of I/Q vectors over time, leading to much better resolution than one period of the frequency being used.

To apply this method to a DTP measurement in an REC-to-RE environment requires several elements:.

There are three well-known methods of estimating the location of an emitter, mentioned elsewhere herein. These can be called angle-of-arrival, power-of-arrival, and time-difference-of-arrival. The system <NUM> of the present invention uses one or more of these techniques in combination to arrive at a position estimate.

These techniques each have significant limitations, including:.

As explained above, the RANALYZER™ system <NUM> uses the Digital Signal Processor <NUM> to digitally create signals that simulate internal and external PIM products. The system then compares these simulated signals to the received signals to determine with high confidence if the PIM is internal or external. The detailed steps to accomplish this are:.

It should be noted that this technique works best when there is no uplink traffic, which can be helped by making an OCNS test during a maintenance window. See the section on Automatic Tests during the Maintenance Window for more details about this. Another advantage of doing OCNS testing during a maintenance window is that the transmitters for each MIMO branch can be turned on independently, further improving the match, or lack of match to predicted behavior.

Several example PIM scenarios for two MIMO branches are listed below, and the comparison results for those scenarios are listed in Table <NUM>. These examples are for cross-polarized antennas with <NUM> MIMO branches. Higher numbers of MIMO branches and spatially-separated antennas will have somewhat different results, not shown here.

Claim 1:
A method for use with a system including a radio equipment (RE) and a radio equipment controller (REC) being in communication through a medium having an uplink communication channel supporting uplink data communications from the RE to the REC, and a downlink communication channel supporting downlink data communications from the REC to the RE, the method comprising:
generating a first multi-tone continuous wave (CW) signal;
transmitting the first multi-tone CW signal having a first phase over the downlink communication channel;
receiving a second CW signal including one or more tones, over the uplink communication channel, resulting from a passive intermodulation distortion (PIM) of the first multi-tone CW signal;
extracting uplink I/Q data from the second CW signal;
obtaining a second phase using the uplink I/Q data; and
calculating a distance to a location of the PIM based on the first phase and the second phase.