Cellular/PCS management system and method

[0002] 1. Field of the Invention

[0003] The present invention is directed to managing wireless communications networks and, specifically, cellular and/or personal communication system (PCS) networks (hereinafter, collectively, “cellular network(s)” or “cellular system(s)”). More particularly, the present invention is directed to monitoring events in a cellular network and associating a particular event or series of events with a likely type of failure in the cellular system, thereby preempting failures or quickly detecting failures.

[0004] 2. Background of the Invention

[0005] Demand for cellular system capacity has grown substantially over recent years and growth continues even today. To accommodate this ever increasing demand, new cellular antennas and switches are being fielded, along with associated cabling and other infrastructure necessary to support expansion of the network.

[0006] However, as the cellular system grows, so do the number of problems or failures that tend to occur in the network. That is, even though failures may not be particularly common in any single piece of equipment, the more such equipment is placed in the field, the more likely failures will tend to occur in the aggregate. Unfortunately, this increased number of failures can overburden available technicians and cellular system management personnel and engineers.

[0007] More particularly, it is often the case that the underlying cause of a particular failure in the cellular system is not known at the time the failure is detected. For example, when a single channel at a cell site begins to fail or fails, the failure can, under certain circumstances, cause “ripple” effects throughout the entire cell site, making it appear as though there is a problem with the entire cell site. That is, the fact that the failure is related to only one channel may not be immediately apparent to the cellular system operator. It is not until a technician is dispatched to the cell site to troubleshoot the failure that it is discovered that the underlying cause of the failure was, in fact, the failure of only a single channel module, and that the replacement of that one module will rectify the overall problem.

[0008] Also, a cellular system failure may sometimes go unnoticed by the cellular system operator until cellular system customers begin complaining about spotty or inadequate service.

[0009] In other words, under conventional cellular system management system, it is often difficult to timely detect and determine the source or cause of a problem or failure without having to rely on system customers or having to dispatch technicians to apparent trouble spots. Furthermore, due to the limited number of properly trained technicians, there may not be a suitable technician who is readily available to troubleshoot system failures.

[0010] The present invention provides a method and system to more effectively manage and/or monitor a cellular or PCS system or network. In accordance with the present invention, the network is monitored using event data that is available from the system infrastructure itself, including infrastructure data such as billing data, blocking statistics, call processing data, call activity counters, system alarm information and any other event data that can be collected and analyzed in accordance with the principles of the present invention. In the context of the present invention, billing data includes calling and called party telephone numbers and length of call, and blocking statistics include the number and frequency of calls initiated by a cellular system user that cannot be processed as a result of the cellular system being too busy. Call processing data includes, for example, cell site handoff data, call activity counters including counters for RF cell loss or high BER, and alarms including autotune combiner failures or power amplifier failures.

[0011] In accordance with the present invention, a computer is programmed to perform the tasks of remotely accessing a cellular switch (or database) and downloading data that is available from the cellular system infrastructure. The downloaded data is then parsed to capture particular events that have been found to be relevant to cellular system operation. Such events include, for example, blocked calls, dropped calls, noise, lack of audio, one-way audio or any other event that detrimentally impacts a cellular system customer. The events just described are, in accordance with the present invention, gleaned from the information or data available from the cellular system infrastructure.

[0012] The events gleaned from the cellular system infrastructure via parsing are then analyzed with respect to a predetermined event-to-failure “mapping” or “correlation” scheme. For example, through empirical experimentation, the present inventor has recognized that certain types of failures can be detected by analyzing the information that is available from the cellular system infrastructure. Using billing data along with call processing data, for example, one can find instances of cellular telephone calls that last only a short period of time, e.g., 5 to 7 seconds, and which are initiated and ended by the same cellular telephone user. Such short telephone calls can often be attributed to problems with a channel's audio signal. By detecting short calls of this nature and counting how may similar telephone calls are begun and ended in such a fashion over a predetermined period of time, it is often possible to predict, with considerable certainty, that a channel's audio signal is about to fail or has already failed.

[0013] In the preferred embodiment of the present invention, once a likely or possible failure in the cellular system is detected, a person responsible for tending to or managing the resolution of that particular type of failure is notified by, for example, email, telephone, wireless telephone or pager, or other PCS device. The failure or potential failure can then be tended to in a timely and efficient manner.

[0014] In the preferred embodiment of the present invention, the aforementioned information and/or data is captured in real or near-real time over a predetermined period of time (e.g., 4, 6 or 8 hour periods) and analyzed preferably immediately thereafter so that analysis results are quickly made available to the appropriate personnel. Quantized periods of time are preferably employed since the information available from the cellular system infrastructure is considerable and, accordingly, it may be beneficial, in view of limited computing power, for example, to limit the amount of data that is being analyzed at any given time. Further, by performing event-to-failure mapping after a relatively short period of time, failures can be more quickly identified.

[0015] It is therefore an object of the present invention to provide a method and system that collects cellular system infrastructure information and/or data, extracts cellular system events therefrom and maps the extracted events into indications of possible or likely cellular system failures.

[0016] It is yet another object of the present invention to provide a method and system that notifies the appropriate person when a failure is detected.

[0017] It is another object of the present invention to provide a method and system that analyzes aspects of at least one of billing information, blocking statistics, call processing data, counter information and alarm information available via the cellular system infrastructure in an effort to quickly identify probable failures.

[0018] It is also an object of the present invention to provide a method and system that captures cellular system information in blocks of time and analyzes the information with respect to possible indications of system failures.

[0019] It is another object of the present invention to provide a method and system for analyzing cellular system infrastructure data, detecting possible failures and notifying the appropriate manager or technician responsible for resolving such a failure.

[0020] These and other objects of the present invention will become apparent upon a reading of the following detailed description in conjunction with the accompanying drawings.

[0021] FIG. 1 is a schematic diagram illustrating an exemplary system for collecting cellular infrastructure information and identifying a probable failure via event-to-failure mapping, in accordance with the present invention.

[0022] FIG. 2 is a flowchart illustrating the preferred steps for implementing the present invention.

[0023] FIG. 3 is an exemplary email message sent in accordance with the notification features of the present invention.

[0024] The present invention provides a method and system to more effectively manage and/or monitor a cellular or PCS system or network. In accordance with the preferred embodiment of present invention, events in the network are monitored using information or data that is available from the system infrastructure itself. FIG. 1 shows an exemplary system architecture in accordance with the present invention. The figure illustrates the type of data that the present invention preferably collects and the general flow of this data or information in accordance with the principles of the present invention. As shown, billing information 100, blocking statistics 110, call process data 120, counter information 130 and system alarm information 140, or some subset of this data, are passed to event-to-failure mapping module 150, which is, for example, a software program running on computer 145. The foregoing data can be collected in real or near-real time primarily from cellular system switches and/or databases associated with cellular switches, by remotely connecting computer 145 to the switches and downloading data that has been recorded at the switch and the associated databases. Methods for implementing such connectivity to a cellular switch, for example, are well-known to those skilled in the art. Also, as shown in FIG. 1, computer 145 is connected to notification service 170, which may be an email server, paging service or the like.

[0025] Event-to-failure mapping module 150 preferably collects the various forms of data and, through filtering, ordering and data association techniques, maps an event or a series of events to probable or actual failures in the cellular network. By collecting different types of data from the various sources 100-140, it is possible to identify possible points of failure. Examples of event-to-failure mapping are described later herein.

[0026] The output of event-to-failure mapping module 150 is the identification of a probable failure 160. This probable failure is then preferably reported to a cellular system manager or technician, for example, who is responsible for resolving the identified failure. For example, if a cellular site channel is determined from the present invention to have failed, then a technician is preferably notified that, e.g., channel X at cell site Y should be replaced.

[0027] The present invention will now be explained in more detail with reference to FIG. 2, which illustrates exemplary steps for implementing the present invention. At step 205 a “platform” that stores, records or holds data or information with respect to the cellular system infrastructure is accessed. The “platform” may be a hard drive or dynamic random access memory (RAM) at a cellular switch, a database at a location other than a cellular switch, or any other data source that stores cellular system infrastructure information. In the preferred embodiment of the present invention, computer 145 is programmed to perform step 205 as well as the other steps described herein. At step 210, data is accessed and downloaded from the platform. This accessing and downloading step can be accomplished via, for example, a wire line network employing the Internet using FTP or HTTP, or any other suitable protocol for setting up a connection between a computer and a data source (typically another electronic computing device) for purposes of accessing and downloading data.

[0028] At step 215, the downloaded data is then parsed to capture information corresponding to cellular system infrastructure events that have been determined to be particularly relevant to cellular system operation. Accordingly, cellular system information tending to provide insight into, for example, blocked calls, dropped calls, noise, lack of audio, or one-way audio are preferably extracted and stored separately from the rest of the available data. Such information can be gleaned from, for example, call release/block data including:

[0029] 1. Normal Release

[0030] 2. Call Blocked, no RF Channels available

[0031] 3. Call Blocked, no Telco trunks available

[0032] 4. Call rejected, bad ESN/MIN combo (Electronic Serial Number)/(Mobile Identification Number)

[0033] 5. Call Failed, Loss of RF uplink (Mobile to Cell)

[0034] 6. Call Failed, Loss of RF downlink (Cell to Mobile)

[0035] 7. Call Failed, High BER uplink (Mobile to Cell)

[0036] 8. Call Failed, High BER downlink (Cell to Mobile)

[0037] 9. Call Fail, No Resource available

[0038] 10. Call Fail, Loss of SAT uplink (Supervisory Audio Tone)

[0039] 11. Call Fail, Loss of SAT downlink

[0040] Data from billing records can also be used, which can provide information on call duration, switch trunks used, cell and channel information and features such as 3-way calling, call forwarding and voice mail.

[0041] The parsed data, or events, are then preferably organized into a common format, which is useful because a cellular system might employ switches made by different manufacturers or because the data that is accessed from different “platforms” may be in inconsistent formats. Thus, in order for the event-to-failure mapping of the present invention to function properly, it is preferable that all relevant events are organized in a common format. Placing the events in a common format may also include step 220, wherein the events are sorted by, for example, the time of the event, the RF channel on which the event occurred, the number of occurrences of the event or a customer's telephone or wireless device identification (ID) number.

[0042] At step 225, the parsed and sorted events are then subjected to a predetermined event-to-failure mapping. That is, through experimentation and observation, the present inventor has recognized that certain types of failures can be detected by analyzing the parsed and sorted events extracted from the cellular system infrastructure. Thus, using billing data along with call processing data, for example, one can find instances of cellular telephone calls that last only a short period of time, e.g., 5 to 7 seconds, and which are initiated and ended by the same cellular telephone user. Such short telephone calls can often be attributed to problems with a channel's audio signal. By detecting short calls of this nature and counting how many similar telephone calls that begin and end in such a fashion over a predetermined period of time, it is often possible to correctly predict that a channel's audio signal is about to fail or has already failed.

[0043] Other examples of failures that can be gleaned from the appropriate event data include:

[0044] (i) bad radio channel based on dropped calls and relevant alarms:

[0045] (ii) Tower mounted amplifier failure based on series of dropped calls and appropriate alarms

[0046] (iii) Disturbed audio based on clock alarms.

[0047] From customer service or technical support it is possible to learn that a customer is experiencing distorted audio. Alternatively, it is possible to glean such information from billing records, e.g., by detecting many short duration calls. Further, an alarm can be generated indicating there is a problem with a cell site's clock (frequency determining portion of the cell site), which could cause the distorted audio. Ultimately, such a clock problem will result in dropped calls.

[0048] The following are additional examples of event-to-failure mappings in accordance with the present invention.

[0049] 1. One Way or No Audio Call

[0050] Billing data 100 shows a short term call followed by normal length call on the same site, but different channel. The billing record also provides channel information, audio trunk information, and calling and called party information.

[0051] Blocking statistics (110) can indicate that there were no echo cancellers available for a digital call, which would create a “no audio” problem.

[0052] Call processing data 120 could show an abnormal amount of originations on the channel with no audio. This could also lead to higher than normal call failures.

[0053] The Cell level counters 130 could show a change in call originations due to a retry to get an audio connection.

[0054] On some cellular systems (e.g., Ericsson) there is a pre-check to test the audio path before a call is placed on that channel. If this pre-call check fails an alarm is sent. However, since this pre-call check does not check the RF (Radio Frequency) portion of the audio link, there could still be a failed audio without alarms.

[0055] 2. Call that Ends Abnormally

[0056] Billing records 100 supply the channel assignment, trunk information, disconnect reason, call duration, calling and called parties information.

[0057] Blocking statistics 110 need not be accessed in this example.

[0058] Call processing data 120 may show hand off information, additional disconnect information, channel information before and after handoff.

[0059] Cell level counters 130 indicate if the cell that the call was on is experiencing and an increase in abnormally ending calls. Using trended data it is possible to determine when this started and then use that information to investigate additional billing records and call processing data.

[0060] Once the cell is identified, it can be determine if there are any alarms 140 associated with the channels indicated in the billing or call processing data.

[0061] 3. Calls that Change in Quality During the Call

[0062] Billing information 100 can be used to show that a call is being handed off from digital to analog and back to digital very often. This will cause the call audio quality to change. The billing information also identifies which subscriber was involved, what cell sites and what channels.

[0063] Blocking statistics 110 may not be necessary in this example.

[0064] Call processing data 120 is preferably used to supply information on which cell the anomaly is occurring, signal strengths of the calls, the BER (Bit Error Rate) of the calls, and the S/N (Signal to Noise) ratio on analog calls.

[0065] When a change to normal operations on a cell site happens it will result in counters 130 changing. This normal operation is indicated in changes to the counter trending for that cell. The trending may indicate a change in overall signal strength or a change in the average BER.

[0066] With tracking indicators from billing, statistical counters and call data a search of alarms 140 for the effected cells is started.

[0067] Furthermore, in digital cellular and PCS technologies the mobile phone itself becomes part of the network. Thus, a periodic scan of the data from billing (100) and from call process data (120) may indicate a bad mobile phone that needs to be serviced or replaced.

[0068] In the preferred embodiment of the present invention, once a likely or possible failure in the cellular system is detected, a person responsible for tending to or managing the resolution of that particular type of failure is notified by, for example, email, wireless pager or telephone, or other PCS device. Thus, at step 230, the appropriate person or persons is/are identified for those probable failures for which he/they are responsible. An email, or other well-known form of notification is then preferably sent to that person or persons. Thus, the probable failure can be tended to in a timely and efficient manner without first having to send a technician to troubleshoot or without first receiving customer complaints.

[0069] At step 235, the personnel who were identified and notified in step 230 preferably also provide feedback to improve or optimize the event-to-failure mapping. For example, a technician may report that not only did the probable failure turn out to be an actual failure, but that another related failure was also detected when the failure was investigated. By adding the related failure to event-to-failure mapping 150, the overall accuracy of the system and method of the present invention is increased.

[0070] In the preferred embodiment of the present invention, the aforementioned information and/or data is captured in real or near-real time over a predetermined period of time (e.g., 2, 4, 6 or 8 hours, i.e., preferably less than 24 hours) and analyzed thereafter so that results can be quickly made available to the appropriate personnel. Also, as those skilled in the art will appreciate, there is a vast amount of data that is accessible in the cellular system infrastructure. Thus, in the interest of processing speed, it is preferable to quantize or limit the amount of data that is processed and ultimately subjected to the event-to-failure mapping of the present invention. Moreover, prior art methods of analyzing network operations typically involve reviewing a previous day's data. However, customers expect immediate corrective action when a failure occurs. By performing analysis, i.e., event-to-failure mapping, on predetermined blocks of time that are less than 24 hours, the present invention provides prompt detection of failures and faster failure resolution, as compared to prior art systems and methodologies.

[0071] FIG. 3 shows an exemplary email message that is sent to personnel responsible for tending to or resolving cellular system failures. The exemplary email message is directed to an RF channel failure and preferably includes a brief description of the failure along with supporting data that is gleaned from the event data. In FIG. 3, frequency or channel 956 at cell site 90 recorded an error code of Supervisory Audio Tone (SAT) loss with a diagnostic of low signal to noise (S/N) ratio. This error code and diagnostic occurred 247 times in the four hour period from 12:00:00 to 16:00:00 on May 14, 2000. Thus, the person receiving this email is provided all necessary information to dispatch a technician to perform a specific repair job.

[0072] The foregoing disclosure of the preferred embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be obvious to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents.

[0073] Further, in describing representative embodiments of the present invention, the specification may have presented the method and/or process of the present invention as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. As one of ordinary skill in the art would appreciate, other sequences of steps may be possible. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. In addition, the claims directed to the method and/or process of the present invention should not be limited to the performance of their steps in the order written, unless that order is required by the description of the process in the specification.