Controlling processor load in a wireless telecommunications network node

FIELD OF THE INVENTION

The present invention lies in the field of wireless telecommunications. The present inventions relates to a wireless telecommunications network node, to a wireless telecommunications network, and to a method of controlling processor load in wireless telecommunications network node.

DESCRIPTION OF THE RELATED ART

Call events, such as denials of call access, drops, handovers, and blocked calls are recorded in wireless telecommunications networks, such as a Universal Mobile Telecommunications System (UMTS) network. A denial of call access can occur where received signal strength is unacceptable, possibly due to signal fading. A call is blocked where the network is too busy to handle that call.

A record of an event is made by a network element, such as a base station controller, shortly after the event occurs. A base station controller in a UMTS network is known as a Radio Network Controller (RNC). A record of an event is naturally known as an event record. The event records are analysed to provide statistics of the numbers of various types of call events occurring in a specified time. Also, the event records are reported to an operations and maintenance centre (OMC) at every 15 minutes or other specified interval. Much memory and processing resources are used by the network element in making the event records and processing them to provide statistics.

In known systems, an operator at the OMC enables and schedule the times at which specific types of statistics will be collected by the network element such as an RNC. However, the maximum number of types of statistics that can safely be collected is very limited. A limit is given for the network element based upon expected processor load with various types of statistics activated. Collecting additional statistics beyond this often results in the network element becoming overloaded. The network element will then need to reboot causing a disruption in service. This is a problem, particularly when it would otherwise be desirable to collect such additional statistics; for example, for diagnostic purposes when the network is not performing well.

Particularly when a fault event has occurred, it is useful to investigate radio conditions experienced by specific mobiles. Each mobile that experience a less than acceptable signal to noise ratio makes measurements of the radio conditions that it experiences. These are known as Radio Frequency (RF) measurements. The RF measurement values are sent via base stations to the radio network controller (RNC). The operator at the operations and maintenance centre (OMC) can enable recordal by the RNC of RF measurements for only a small number of the mobiles that are in connection with base stations under the control of an RNC. This number is typically only two or three mobiles per RNC. If this number is exceeded the amount of measurements recorded will be more than that network element can handle. The chance of the RNC needing to reboot due to excessive load then becomes very high.

The number of measurements, such as event records or RF measurements, that can be recorded per unit time varies. This is because the number of calls for the processor in the RNC to handle varies over time. Accordingly, the operator checks from time to time the level of traffic in the network and estimates when to enable the recording of measurements and for how long. During the hours of peak traffic, the load due to call processing is quite high. This means during expected busy periods the processing load due to measurement recording, analysis and reporting should not be increased. At other times, the load due to call processing can be expected to be less so additional measurements can then be recorded for analysis and reporting.

Accordingly, we can say that such systems are known to have problems in selecting how many measurements to record.

SUMMARY OF THE INVENTION

The inventor(s) found a way to control the number of measurements recorded by a network node such as a radio network controller (RNC) by the node monitoring the load on its processor and automatically adjusting the rate of measurement recordal to keep the processor load high but within acceptable limits.

An example of the present invention is a wireless telecommunications network node. The node includes a processor configured to handle call traffic and to record measurement data. The processor is also configured to detect processor load and to automatically adjust the rate of recordal of measurements dependent on detected processor load. The adjustments are so as to keep the processor load within predetermined limits.

BRIEF DESCRIPTION OF THE DRAWINGS

An illustrative embodiment of the present invention will now be described by way of example and with reference to the drawings, in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram illustrating a Universal Mobile Telecommunications System (UMTS) wireless telecommunications network,

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram illustrating an radio network controller (RNC) and an operations and maintenance centre (OMC) of the network shown in <figref idref="DRAWINGS">FIG. 1</figref>, and

<figref idref="DRAWINGS">FIG. 3</figref> is a diagram illustrating adjustment of the measurement recordal rate dependent upon processor load.

DETAILED DESCRIPTION

When considering a known system, the inventor realised that a method could be provided to adjust the level of measurements recordals automatically dependent on the processor loading. The processor loading includes that due to call processing. In consequence, the processor in a network element such as the radio network controller (RNC) is kept well occupied even though the level of call processing varies. There is no need for the operator to make an intervention to adjust the level of measurement recordals made. The network would be self-correcting in the rate of recordal of measurements.

Without operator intervention, in an adaptive process, the maximum number of records of measurements is automatically made, whilst the processor handles all current call traffic and the total processor load is kept to an acceptable level. The operator does not need to manually adjust the measurement recordal rate.

Furthermore, in analysing the event records, the most important statistics are always collected and reported while less useful statistics are sacrificed when necessary to reduce total processor load. The operator does not need to manually activate or deactivate collection of various types of statistics.

Having a good number of records to process, and analyse to provide statistics, means that the network can be upgraded readily.

Example Network

The network is a Universal Mobile Telecommunications System (UMTS) terrestrial access network (UTRAN), which is a type of wideband code division multiple access (CDMA) network for mobile telecommunications. The UTRAN network is basically as shown in <figref idref="DRAWINGS">FIG. 1</figref>. Only two radio network controllers and four base stations of the UTRAN network <b>2</b> are shown for simplicity. As shown in this Figure, the UTRAN network <b>2</b> includes base stations <b>4</b>. In the Figure, each of the base stations <b>4</b> is also designated “Node B” in accordance with UMTS terminology. Each base station typically has three cells <b>6</b>, each covered by one of three directional antennas (not shown) angled at 120 degrees to each other in azimuth. A cell, also referred to as a sector, is a radio-coverage area. Each radio network controller (RNC) <b>8</b> typically controls several base stations <b>4</b> and hence a number of cells <b>6</b>. A base station <b>4</b> is connected to its controlling radio network controller (RNC) <b>8</b> via a respective interface <b>10</b> known as an IuB interface. In use, a mobile user terminal <b>12</b> (often referred to as User Equipment (UE) in UMTS terminology) communicates with a serving radio network controller (RNC) <b>8</b> via at least one cell <b>6</b> of at least one base station <b>4</b>. In that way, the mobile user terminal communicates with the UTRAN network <b>2</b>.

The radio network controllers (RNC) <b>8</b> are connected to a remote operations and maintenance centre (OMC) <b>14</b>.

Event Records

The inventors contemplated event records which include not only details of a call event, such as a fault, and associated radio conditions experienced by a mobile user terminal, but also the geographical coordinates of the mobile user terminal. Constructing and handling the event records requires a large amount of processing resource. One reason is because the radio condition details and geographic measurements are determined by the radio network controller (RNC) every second. Also the event records are constructed and stored at the RNC, and reported from there to the operations and maintenance centre (OMC).

More specifically, the geographic location within the cell of the mobile user terminal experiencing the fault is included in an event record. The location of the fault event is given to within a few metres. The event record also includes an indication of the type of fault and radio signal transmission measurements.

In so-called third generation wireless networks, such as the Universal Mobile Telecommunications System (UMTS) network which is described, location of the mobile user terminal is known automatically by the network so as to enable location based services to be provided. The location of the mobile user terminal is determined by the network, specifically by the RNC, in response to requests made to the mobile user terminal that has requested a location-based service. The mobile user terminal provides enough information to the network, for example as to received signal strengths from various base stations, to enable the network to calculate the position of the mobile user terminal.

Alternatively, in another embodiment (not shown) otherwise similar to the first embodiment, mobile user terminals have Global Positioning System (GPS) receivers built-in which directly supply the geographic coordinates of the mobile user terminal to the network.

If an event occurs, the RNC controlling a base station handling the mobile user terminal in question stores in an event record the location of the mobile user terminal experiencing the fault together with an indication of the type of fault and radio signal transmission measurements received from the base station (NodeB). The events are usually fault events, such as call drop, call setup failure, handover failure etc. Each record includes a timestamp. Table 1 below is an example event record. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="9"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="28PT" align="center" /><colspec colname="5" colwidth="28PT" align="center" /><colspec colname="6" colwidth="35PT" align="center" /><colspec colname="7" colwidth="42PT" align="left" /><colspec colname="8" colwidth="35PT" align="center" /><colspec colname="9" colwidth="35PT" align="center" /><thead><row><entry namest="1" nameend="9" align="center">TABLE 1</entry></row><row><entry /></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row><row><entry>Record</entry><entry /><entry /><entry /><entry /><entry /><entry /><entry /><entry /></row><row><entry>#587</entry><entry /><entry /><entry>BLER</entry></row><row><entry>Timestamp</entry><entry /><entry>BLER</entry><entry>Down</entry></row><row><entry>15:35:27</entry><entry>Cell-</entry><entry>Uplink</entry><entry>link</entry><entry /><entry>CPICH</entry><entry>Cause</entry></row><row><entry>UE Id</entry><entry>id</entry><entry>dB</entry><entry>dB</entry><entry>Ec/Io</entry><entry>RSCP</entry><entry>value</entry><entry>X Coord</entry><entry>Y Coord</entry></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="9"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="28PT" align="char" char="." /><colspec colname="4" colwidth="28PT" align="char" char="." /><colspec colname="5" colwidth="28PT" align="center" /><colspec colname="6" colwidth="35PT" align="center" /><colspec colname="7" colwidth="42PT" align="left" /><colspec colname="8" colwidth="35PT" align="char" char="." /><colspec colname="9" colwidth="35PT" align="char" char="." /><tbody valign="top"><row><entry>Source</entry><entry>Cell A</entry><entry>−0.13</entry><entry>−0.78</entry><entry>−5 dB</entry><entry>−75 dbm</entry><entry>Abnormal</entry><entry>1.00076</entry><entry>59.678</entry></row><row><entry /><entry /><entry /><entry /><entry /><entry /><entry>call</entry></row><row><entry /><entry /><entry /><entry /><entry /><entry /><entry>termination</entry></row><row><entry>Active set</entry><entry>Cell B</entry><entry>−5.1</entry><entry>−5.12</entry><entry>−4 dB</entry><entry>−72 dbm</entry><entry /><entry>53.7071</entry><entry>23.2855</entry></row><row><entry>Active set</entry><entry>Cell C</entry><entry>−4.33</entry><entry>−4.75</entry><entry>−7 dB</entry><entry>−80 dbm</entry><entry /><entry>52.9669</entry><entry>24.0126</entry></row><row><entry>Monitored</entry><entry>Cell D</entry><entry /><entry /><entry>−9 dB</entry><entry>−85 dbm</entry><entry /><entry>52.7457</entry><entry>23.8804</entry></row><row><entry>set</entry></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As shown in Table 1, information is included in the event record from the cell to which the mobile experiencing the fault is located (“source cell”), from the cells in the active set of cells for handover(handoff) thereto, and from the set of cells (“monitored set”) monitored for prospective inclusion into the active set. Radio signal transmission information between the base station and mobile user terminal for which the fault occurred is also recorded along with a “cause value” indicating the type of fault.

More specifically, as shown in Table 1, the event record includes a timestamp, identity (“cell-id”) of the source cell, the identity of cells in the active set, and can include the identity of one or more cells from the monitored set. For at least the source cell and cells of the active set (but possibly also one or more cells of the monitored set), X-Y location coordinates are included together with radio signal transmission data. The radio signal transmission data is: block error rate (BLER) in the uplink direction (that is from mobile user terminal to base station), block error rate (BLER) in the downlink direction (that is from base station to mobile user terminal), the ratio (denoted Ec/Io) of signal energy (chip energy) to energy of interference from other cells, common pilot channel received signal code power (CPICH RSCP), and the “cause value” which is one of a number of standard descriptors regarding the type of the fault.

The event records are stored in the radio network controller (RNC) <b>8</b>. The event records are forwarded to the operations and maintenance centre (OMC) <b>14</b>.

Processor Load Due to Constructing and Handling Event Records

Each mobile user terminal that experiences an event, such as a fault or less than acceptable signal to noise, sends a measurement report to its base station. In this regards, the base station can be considered transparent in that the base station forwards to the RNC all measurement reports that it receives.

It is not possible to store each measurement report at the RNC for forwarding to the OMC, due to the processing load needed to maintain call traffic. Hence only a proportion of the measurements reports are converted by the RNC into event records which are stored and reported up to the OMC. This proportion is variable. This proportion could vary around 5%, for example.

When the processor load is high due to high call volume, the event record recordal rate at the RNC should be lower to reduce the number of measurement records processed. When the call volume reduces, the event record recordal rate at the RNC should be higher to enable more data about the performance of the network to be collected. The process is “dynamic”, being adaptive over time. The recordal rate at the RNC is automatically adjusted by feedback of the level of processor load so as to automatically increase or decrease the rate of recordal of measurements, as explained below with reference to <figref idref="DRAWINGS">FIG. 2</figref>.

As shown in <figref idref="DRAWINGS">FIG. 2</figref>, an RNC <b>8</b> consists of receiving circuitry <b>16</b> connected to a a processor <b>20</b>. The processor <b>20</b> mainly handles call traffic. Additionally the processor <b>20</b> handles measurement reports. Measurements regarding events including the Radio Frequency (RF) measurement data are received by the receiving circuitry <b>16</b> from all the mobiles experiencing an event. An event can be a fault such as unacceptable noise being experienced in a cell of a base station controlled by the RNC.

The processor <b>20</b> includes a variable filter <b>18</b>, a measurement recording stage <b>21</b>, and a processor load detector <b>23</b> The variable filter <b>18</b> receives the measurement reports. Depending on the loading of the processor <b>20</b> as determined by the processor load detector <b>23</b>, the measurement reports are filtered in the sense that a large proportion of the measurement reports are discarded, typically 95%. The rest of the measurements are allowed to be processed by the recording stage <b>21</b>. This processing involves recording the measurements into event records as explained in the previous section. This processing also involves forwarding the event records to the operations and maintenance centre (OMC) <b>14</b>. The event records are stored in a record store <b>22</b> in the OMC <b>14</b>.

The proportion of measurements recorded by the recording stage <b>21</b> has a big effect on overall current load on the processor <b>20</b>. A feedback mechanism is used to keep the proportion of measurements recorded and forwarded by the processor <b>20</b> as high as possible, but without preventing a mobile user terminal making or receiving a call. Specifically, feedback information of the level of loading of processor <b>20</b> is fed back from the processor load detector <b>23</b> to variable filter <b>18</b>. The variable filter <b>18</b> automatically adjusts the proportion of incoming measurement reports that are passed to the recording stage <b>21</b> in consequence.

The feedback mechanism is illustrated in <figref idref="DRAWINGS">FIG. 3</figref>. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, initially when process starts, the recordal rate is at a minimum value of zero, and so a minimum processor load is observed which is below Threshold <b>1</b>. Threshold <b>1</b> corresponds to the highest desirable processor load. Hence the measurement recordal rate is increased incrementally in steps of 2% and for each step the total processor load is monitored. When the total processor load increases beyond Threshold <b>1</b>, the recordal rate is reduced in steps of 2%. The recordal rate is decreased until the sample rate reaches Threshold <b>2</b>. Threshold <b>2</b> corresponds to the lowest desirable processor load. Then once again, the recordal rate is increased in steps of 2%. The objective of the feedback process is to keep the total processor load between the two thresholds. In this way the total processor load is kept acceptably high, with as many event records as reasonably possible being made when process load due to call traffic permits.

Collecting Statistics

In the radio network controller (RNC), statistics are collected of the number of call attempts, number of successful calls, number of call drops within a cell over a predetermined time. These are usually used to determine so-called Key Performance indicators (KPIs) such as Call drop rate, Established Call success rate, Call blocking rate, and Total Traffic rate. The statistics are collected by analysing the event records made.

As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the event records provided by the processor <b>20</b> and the information as to the loading on processor <b>20</b> provided by processor load detector <b>23</b> are input to a statistics collector <b>24</b>. The collection of particular types of statistics by the statistics collector are activated or deactivated selectively using feedback of the processor load level. Which statistics are recorded depends not only on the processor load level detected by the processor load detector <b>23</b>, but also on a ranking of the statistics which can be collected in order of importance.

For example, a statistic can be categorised in Class <b>1</b>, Class <b>2</b>, or Class <b>3</b>, according to importance.

Accordingly, when the processor load is above Threshold <b>1</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>, the types of statistics of least importance, e.g. those in Class <b>3</b>, are deactivated one by one based on their importance within the class. If even deactivating all of these is insufficient to reduce processor load to an acceptable level, then the Class <b>2</b> types of statistics are deactivated one by one in a similar fashion, and so on, until an acceptable processor load level is reached. When the total processor load goes below Threshold <b>2</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>, the collection of statistics that were deactivated are again activated in order of importance until the processor load reaches Threshold <b>1</b>, starting with the one of the highest importance among those deactivated. This is, of course, an automatic process.

Other Embodiments

Some other embodiments lie outside the field of Universal Mobile Telecommunications System (UMTS) networks, for example in other time division multiple access and code division multiple access (CDMA) networks, for example in Global System for Mobiles (GSM) and CDMA2000.

Some advantageous embodiments relate to the control of processor load in other network nodes than radio network controllers/base station controllers; for example in base stations where the base station itself is configured to filter the measurements forwarded on to higher level node such as a base station controller.

Measurement data recorded can be of indications of events experienced by mobile user terminals and measurements of radio conditions experienced by mobile user terminals, for example in event records. The measurement data can include data of the geographical location of the respective mobile user terminal. Other possibilities include that the measurement data comprises indications of events experienced by mobile user terminals and/or measurements of radio conditions experienced by mobile user terminals and/or data of geographical location of the mobile user terminal.