GB2427328A - Revenue assurance system - Google Patents

Abstract

A revenue assurance system for mobile telephony networks places a series of test calls over a network and compares metering and billing records produced by the network with those that should in principle have been produced by each test call. A tester unit (1) comprises a radiotransparent casing (2) holding several mobile telephone handsets (3) and optionally additional SIM cards (5) connectable to the handsets (3). The tester unit (1) is positioned at a desired test location and is controlled by a laptop computer (7) over a short range wireless link (8), such as a Bluetooth link, or by a wired connection. The laptop (7) is programmed with a series of test calls, which it instructs one or more handsets (3) to make over a selected network. The network's metering (11) and billing systems (12) generate a call data record (cdr) for each test call. The laptop (7) generates a corresponding test cdr for each test call. These may be sent batchwise to a central database (13) for comparison with the network cdrs. Also, each call is followed as a single software thread in real time, allowing selected types of error to be identified and reported as soon as they occur.

Description

REVENUE ASSURANCE SYSTEM

The present invention relates to apparatus to check the accuracy of mobile telephone charging arrangements and to a method of checking these arrangements using such apparatus.

Telecommunications service providers have a great interest in ensuring that their customers are accurately billed for the services provided. The procedures for checking billing accuracy are generally referred to as "revenue assurance", and the larger providers have sizeable Revenue Assurance departments responsible for locating and eliminating so-called "revenue leakage". Overcharging will frequently be identified by the customers themselves, requiring recompense and leading to impaired customer loyalty. Undercharging, on the other hand, may please the customer, but can add up to significant losses of income to the provider for even marginal undercharging, given the numbers of calls involved. In either case, providers will need to comply with standards set by regulatory authorities - in the United Kingdom, for example, Ofcom's Metering and Billing Directive (OTR 003:2001).

Revenue leakage is a particular problem in the field of wireless/mobile telephony. Whereas a conventional land-line telephony service may have only a few (e.g. distance-related) alternative tariffs available for each call, a mobile telephone call may fall under many different tariffs. This may depend not only on the caller's provider and the service package to which the caller has subscribed, but also on the service provider used by the person called.

Furthermore, mobile telephony systems provide a range of non-voice services, such as SMS (text messaging) and video calls, each requiring a different set of tariffs.

As an extra layer of complexity, many mobile telephony service providers are what is known as "virtual" operators. A subscriber may sign up to a virtual operator offering its own particular set of tariff packages, but the actual telephony service will be provided on a network run by a larger "network provider" (e.g. Vodafone, 02 and so forth in the UK).

Thus, the network provider will bill the virtual operator for a call at a first tariff set by an agreement between them, while the virtual operator bills the caller under a second tariff set according to the service package chosen by the caller.

It is common practice for both virtual operators and network providers that are dealing directly with consumers to base their charging systems on call data records (cdrs), one of which is generated for each call made.

Incorrect billing may be caused by errors in two distinct areas. Metering systems collect data about an individual call, particularly its duration. Billing systems use these data to calculate a charge for the call. An error in either system may lead to the cdr for the call specifyiiig an incorrect charge. - 3

The complexity of the systems used, both hardware and software, is such that human error and software "bugs" can easily lead to systematic incorrect billing on a scale that makes investment in revenue assurance worthwhile. While larger providers are likely to have in- house Revenue Assurance departments, virtual operators may instead hire in expertise from specialist revenue assurance organisations.

Attempts have been made to conduct revenue assurance by using softwaregenerated virtual call data records (vcdrs) to challenge billing systems (for example, see International Patent Application No. W002/03336 to Ericsson). However, it is believed that because no actual calls are made by such systems, they do not test the metering system, and accurate call timing is fundamental to accurate charging.

It is therefore preferred to conduct revenue assurance by means of actual calls placed through the network, so that both metering and billing arrangements are tested. These test calls can then be designed so that if problems exist they are likely to trigger them into being.

Proprietary systems are in use which comprise custom-built electronic apparatus, known as call generators, that can be programmed to make a series of test calls through a selected mobile telephony network or operator, for which the correct charge is known. These can then be reconciled with the charge indicated on the corresponding cdrs produced by the respective metering and billing system, to identify where errors leading to revenue leakage may be present.

These call generators are expensive items to purchase, which is believed to have limited their use to larger operators and to specialist revenue assurance organisations. They are not easily transportable and have a substantial power requirement, so are complex to deploy, e.g. for tracking down whether problems are Occurring at a particular switch site of the network, or the like. They are usually either installed at a mobile network switch site or in a vehicle, in which case they need to he hard-wired into the vehicle's battery for power. The complexity of this equipment also leads to a significant requirement for technical support and maintenance.

Such call generators are also not particularly flexible in operation. A list of test calls to be made ("call list") is generated centrally and sent to the call generator as a first data file. The call generator then operates autonomously, working its way through the call list and recording data such as the precise time and duration of each call made. Once it has finished the call list, a second file containing these data is returned to a central database for processing and checking against the resulting cdrs from the network(s) tested.

Some models of call generator are linked to the central database by a fixed cable connection, which clearly restricts the mobility of the resulting system. An alternative arrangement is to use the mobile telephony network itself to transfer the data files. However, the current GSM standard for mobile telephony comprises a protocol for data transfer, known as data 9600, which has several drawbacks in practice. The connection speed of data 9600 is only 9.6kbps, so data transfer is very slow. The call generator thus spends a large portion of its time idle while waiting for data input or output to complete. Data 9600 has a low bandwidth priority across the network, and so it is found that the connection is frequently dropped while a datafile is being transferred. This is exacerbated by the length of the connections required to transfer each file. A failed data file transfer can lead to a call list not being executed at the desired time (or possibly, at all). Lastly, data 9600 calls are expensive, and the cumulative cost of all the data transfer connections required is a significant addition to the cost of operating the revenue assurance s'stem.

One further drawback of existing arrangements is that they do not provide a rapid indication of the presence 6f a problem, as they can in practice only operate by accumulating and transferring entire data files. Jt would be beneficial if revenue assurance testing could be carried out such that serious errors could be reported immediately, rather than several hours later once the complete data file has been analysed and the errors traced back.

It is hence an object of the present invention to provide revenue assurance apparatus and methods for performing revenue assurance that obviate the above disadvantages, allowing more flexibility in operation, being cheaper to produce and to operate, and ideally which are usable in a mobile arrangement, away from conventional fixed power supplies and/or data colmectjons. It is a further object to provide revenue assurance apparatus and methods which are capable of generating more prompt indications of errors.

According to a first aspect of the present invention, there is provided revenue assurance apparatus for mobile telephony networks comprising at least one mobile telephone handset means, computing means so programmed as to generate instructions for the handset means to make a test call, means to compare a predicted and an actual outcome of said test call and alerting means adapted to indicate when an actual outcome fails to correspond to a predicted outcome.

Preferably said comparison means is adapted so to compare a predicted and an actual outcome during or substantially immediately following said test call.

Advantageously, said alerting means is adapted so to indicate substantially immediately following a failure of an actual and a predicted outcome to correspond.

Optionally, said revenue assurance apparatus comprises apparatus as described in the second aspect below.

According to a second aspect of the present invention, there is provided revenue assurance apparatus for mobile telephony networks comprising at least one mobile telephone handset means, computing means so programmed as to generate instructions for the handset means to make a test call, and direct wireless communication means operatively connecting the handset means and the computing means.

Preferably, the direct wireless communication means is operable on a waveband allocated for short-range use without specific licensing.

Advantageously, the direct wireless communication means is operable in the 2.4GHz waveband (2.40 to 2.4835 GHz).

Additionally or alternatively, the direct wireless communication means may be operable in the 5.8G1-Jz waveband (S.725-5.875GHz) The wireless communication means may operate according to the Bluetooth protocol. - 7

Alternatively, the wireless communication means may operate according to the Wi-Fi protocol.

Preferably, the apparatus comprises casing means, substantially transparent to radio waves and securely enclosing said at least one mobile telephone handset means.

Advantageously, the casing means is selectably openable to provide physical access to the at least one handset means.

The casing means may be manually transportable.

The casing means may be provided with power supply means for the at least one handset means.

Said power supply means may comprise means to connect the at least one handset means to a mains power supply.

The casing means preferably contains a plurality of handset means, optionally an even number thereof, such as four.

The apparatus may comprise additional Subscriber Identity Module (SIM) card means operatively connectable to the or each handset means.

Preferably, the computing means is programmed to receive data from the at least one handset means concerning each test call made thereby.

Advantageously, the computing means is programmed to calculate a call data record (cdr) based on said data for each test call.

The computing means may he programmed to compile data and/or cdrs concerning a plurality of test calls for transfer to a database means.

The database means may be programmed to compare said data and/or cdrs received from the computing means with data and/or cdrs concerning the same test calls received from metering and billing systems of a mobile telephony network through which the test calls were made.

Preferably, the computing means is programmable to generate a set of test calls complying with preselected parameters.

Advantageously, the computing means is programmed to instruct the or one of the handset means to make each test call of said set at a preselected time.

According to a third aspect of the present invention, there is provided a method for testing call metering and/or billing systems of a mobile telephony network comprising the steps of providing apparatus as described in the first or second aspects above, causing the computing means thereof to ihstruct a handset means thereof to make a test call over a mobile telephony network, producing a theoretical call data record for the test call and comparing it to an actual call data record for the same call produced by the mobile telephony network.

Preferably, the method comprises the step of causing the computing means to generate a series of such test calls.

Advantageously, the method comprises the step of positioning the or each handset means in a preselected location remote from a central computing means.

According to a fourth aspect of the present invention, there is provided a revenue assurance software program adapted so to control one or more mobile telephone handset means that they make a series of predetermined test calls over a mobile telephony network, to record data concerning said calls, and to calculate a theoretical call data record for each of said calls.

Preferably, the program is adapted to calculate said theoretical call data records on the basis of a preselected charging tariff package.

Advantageously, the program is adapted to consolidate the theoretical call data records for the series of test calls into data file means and to transmit said data file means to database means for subsequent analysis.

The program may be adapted to handle each said call as a separate software thread.

An embodiment of the present invention will now be more particularly described by way of example and with reference to the accompanying drawings, in which: Figure 1 is a schematic perspective view of a network tester unit of a revenue assurance system embodying the present invention; and Figure 2 is a diagrammatic representation of the operation of a revenue assurance system embodying the present invention.

Referring now to the Figures, and to Figure 1 in particular, a network tester unit I comprises a rigid casing 2 of a strong radio-transparent plastics material, for example a composite- reinforced thermosetting resin or engineering thermoplastics material. The casing 2 hinges open as shown, but in use will usually be closed and locked for security, especially when it is to be left unattended for prolonged periods of operation.

The casing 2 contains a plurality of conventional mobile telephone handsets 3; only four handsets 3 are shown for clarity, but six or even eight handsets 3 are usable in practice enabling higher call volumes. The handsets 3 may be embedded in a resilient bed of foam 4 or the like, to add to the robustness of the network tester unit 1 in use and while being transported. When closed, the casing 2 is dustproof Each handset 3 contains a conventional Subscriber Identification Module (SIM) card, as normal, but additiOnal SIM cards 5 may be provided, operatively linked to each handset 3, so that it may act as several distinct virtual handsets (for example each set up to operate under a different package of call tariffs). While each handset 3 retains its own integral battery power supply, an electrical power connection 6 is provided so that the handset batteries may be recharged and so that a mains power supply may be used when the network tester unit 1 is operated conveniently near a power socket. Otherwise, the handsets 3 will still be capable of prolonged operation on battery power alone. The network tester unit 1 may contain additional rechargeable battery packs if prolonged remote operation is envisaged. 1]

The network tester unit 1 shown is light, compact and easily transportable to any desired location from which test calls are to be made. It may be left open as shown if a user wishes to monitor the progress of test calls on the handsets' integral display screens, but will usually be securely locked shut. The radio-transparent casing allows the handsets 3 to make calls unimpededly, and also allows the handsets 3 to be controlled by short-range wireless links (see below for details). The network tester unit I requires no additional aerials for either function, relying on the integral aerial of each handset 3 instead.

A revenue assurance system incorporating such a network tester unit 1 is shown in outline in Figure 2. The network tester unit 1 is positioned at a desired location within the coverage of a mobile telephony network. A personal computer 7, here a conventional laptop computer, is programmed with software (described in detail below) which generates commands to instruct a mobile telephone handset to make a call of selected duration and nature (e.g voice, data, SMS, video and so forth). These commands are transmitted to a handset 3 within the network tester unit I by a Bluetooth short-range wireless data link 8 (Bluetooth is a registered trade mark). Other short-range. wireless links are possible, as detailed below, but the Bluetooth protocol allows high-speed data transfer, operates in a waveband requiring no operating licence, and many computers 7 and handsets 3 are now supplied with Bluetooth connectivity built in automatically or as a routine option.

It is also envisaged that network tester units I could be linked to the personal computer 7 by a hardwired connection, or by connecting them to a LAN or WAN, where the flexibility produced by the Bluetooth link is not required.

The handsets 3 within the network tester unit I make a series of such test calls (represented by lines 9) through the network being tested (represented by mast 10). Each call 9 is metered by an existing metering system II of the network, and a billing system 12 of the network calculates a charge for the call 9, using a tariff appropriate to the particular handset 3 (or SIM card 5) making the call. A call data record (cdr) is then produced for the call. (NB: where the call is placed over the network of a virtual operator, this will be the cdr used by the virtual operator to charge a customer).

Meanwhile, the actual duration and nature of the call are reported back to the computer 7 along the Bluetooth link 8. The software on the computer 7 (which is supplied with data on the tariffs to be employed, and so Torth) calculates what the charge for the call should be, and generates a test cdr, which is saved in its memory. At convenient intervals, such as on completion of a series of test calls, a datafile containing each test cdr is transferred to a central database 13. This transfer can he made along a direct wire connection 14, for example where the computer 7 is being used in an environment where it has access to a local area network (LAN) or a landline Internet/e-mail connection, or where a laptop computer 7 is brought hack to a docking station linked to a LAN. Alternatively, a radio link 15 may be used; this may be to a wireless LAN (WAN) through a 3G internet laptop connection, or may comprise a mobile telephone internet or data call (e.g. by data 9600). Although these are relatively slow, once the data has been digested down to a file of test cdrs the resulting datafile is relatively compact; in any case, these downloads of data to the central database 13 are in most cases particularly urgent.

To complete the revenue assurance process, existing software reconciles the test cdrs with the corresponding cdrs generated by the billing system 12. Where the test and actual cdrs do not agree, this is highlighted. Analysis of these discrepancies will reveal where there are errors in the metering and/or billing systems 11, 12 of the network, which can then be fixed and subsequently retested.

In some situations, it may be desirable to identify errors as soon as possible. The system described above may then be programmed to report its results at more frequent intervals than after each series of test calls, Indeed, it is capable of operating such that a call can be followed in real time. Since each cdr is handled as a separate software thread, it can be reported individually. In this mode a significant error requiring rapid correction can be identi tied promptly, where existing systems would need an hour at best for the error to come to light, and more typicaily six to twelve hours, during which multiple errors may well have been accumulating unnoticed.

The Bluetooth links 8 have a reliable operating range of at least 10 metres, providing a data transfer rate of aiound 700 kbps, which is easily fast enough for real-time control of the handsets 3 in the network testing unit 1, and data acquisition in return. The range is sufficient that the network tester unit I may be placed anywhere where a mobile telephone call might be made, while the laptop computer 7 (and a user of the system) may remain somewhere more convenient.

Current Bluetooth technology uses the 2.4G1-Iz waveband (in the UK, this extends from 2.40G1lz to 2.4835GHz), which does not require official licensing. Another technology using this waveband is known as WiFi, which is intended for wireless links between computers and peripherals, for example. WiFi-capable mobile telephone handsets 3 are likely to become available in the near future, thus allowing the Bluetooth link 8 shown in Figure 2 to be replaced by a WiFi link if preferred.

The WiFi standard is being developed to use alternative wavebands in order to provide extra capacity. In the UK, wavehands at around 5.2GHz, 5. 3GHz and 5.5GHz have been allocated by Ofcom to radio LANs, and a waveband at around 5.8GHz has been allocated to "short range indoor data links" together with one just below 10.7GHz. Standards known as Ultrawideband and WiMax are also being developed to allow devices to communicate using these "licence-fee" wavebands. While no other wavebands have yet been specifically allocated for such short-range wireless links, it is likely that others may be allocated in future if existing wavebands become saturated.

The common feature of these systems appears to be the use of direct lowpower wireless links between two transmitter/receiver units (in the 2. 4GHz waveband, for example, Ofcom stipulates that such unlicensed devices may not exceed 100mW radiated power). While transmitter and receiver will be constrained to a separation of tens of metres at most, this is not a significant limitation in this application, and the data transfer rates possible far exceed those available over long-range relayed wireless links (allocated to different wavebands - e.g. GSM mobile telephony uses the 850, 900, 1800 and 1900 MHz wavebands, by international convention).

The software on the computer 7 allows much greater flexibility and responsiveness than for existing revenue assurance systems using custombuilt electronic apparatus such as call generators. The standard sequence of operation for the current version is as follows.

A Bluetooth link is established to each handset 3 (and where appropriate each virtual handset formed by using additional SIM cards 5) in the network testing unit 1. A set of tariffs are entered, or are input from a data file, comprising such information as a connection charge, a duration of a charging unit, a cost of a charging unit and any gratis time or the like. A selected tariff is then assigned to each (virtual) handset 3.

A template is then set up for individual test calls, for example specifying maximum and minimum durations, and optionaI1' specifying which handset 3 is to make and/or receive the call. A group of test calls is then defined, each of which fits the template. Where not specified in the template, the software will randomly assign handsets 3 to calls. A call group will usually comp1ise a set number of calls, each of a random duration within the limits set by the template, to be made over the course of a preselected length of time and or between preselected start and end times and dates. The software generates the test calls making up the call group and presents them for the user's approval. Several call groups can be set up simultaneously the software will ensure that no handset is scheduled to be active in two call groups at the same time.

The user then selects a call group to use, and starts it executing. When the time comes for a particular test call to be made, the computer 7 passes an appropriate command to the respective handset 3, and receives information in return on the progress of the call, which can be displayed on-screen. Once a call is completed, the software records the handset calling; the handset called; the date of the call; the precise time of each of call execution, call dialling, call ringing, call answering, completion of the connection, hanging up, and disconnection; the duration of the call; and whether or not it was successfully connected. This information is then recorded in a file of test cdrs, ready to he transferred to the central database 13 when convenient.

This file of test cdrs can then he opened, if necessary reformatted to fit the format of actual cdr files obtained from the billing system 12 of the network tested, and a matching routine carried out to spot discrepancies.

Where a systematic problem in the network's billing and/or metering systems is revealed, this information can also be used to direct efforts to locate and correct it. The overall proportion of errors can also be used to check compliance with regulatory standards.

Since the computer 7 is receiving information on the progress of each call in real time, it may spot certain forms of error immediately, such as failed or dropped connections, It may be programmed to transmit an alert, for example by e-mail or SMS message, as soon as a specified problem occurs.

Similarly, when the system is operating to follow each call as a software "thread" and report the corresponding cdr individually, the matching routine can be used to watch out for all types of error or discrepancy on an almost real-time basis. Again, an alert may be triggered as soon as preselected types of error are spotted, while less serious errors may be reported periodically as described above.

The software currently in use is written in the C++.Net programming language, although no features are be1ieied to be executable only in C++. Net, and the same functions may be carried out using programs written in other languages. Similarly, the database functions currently use the Microsoft Access package, but could be implemented using other database packages if desired.

Since a majority of the functios described are implemented as software, it would be relatively straightforward to modify or add features if desired. Such features may include new call scenarios for 2G or 30 networks, for example data, video, SMS, voicemail and/or MMS and other I1uJti-media formats. The existing custom-built call generators rely to a much greater extent on hardware components and connections, and would be likely to require a degree of rebuilding if new features were required.

Another major advantage of the software-based arrangement described is that it generates a separate software "thread" for each call made, which can be followed in real time and independently of other calls being made. It is thus possible, if desired, to pick out problems as they arise, whereas the existing systems work on a batch processing approach, and nothing can be done until a full set of call groups has been executed and the results successthlly returned and analysed. In many instances, the ability to pick out and deal with problems in real time may be even more useful than the mobility and flexibility of the testing system of the present invention.

The system shown in Figure 2 uses only a single four-handset network testing unit 1. This allows two concurrent calls to be placed at once, since each (real) handset 3 will usually be set up to call one of the other three (real) handsets 3 (or their "alter egos" using their respective additional SIM cards 5). However, to carry out a thorough test procedure in a reasonable time, further network testing units I can be added to the system, each effectively adding four more handsets 3 which may make or receive calls. A Bluetoothcapable computer 7 will have no problems linking to and distinguishing as many handsets 3 as required. Existing systems may have extra call generators added, but this is not straightforward as they would require additional data connection links. Where wire connections to the call generators are used, the number of available sockets may rapidly be exceeded, and the resulting tangle of wiring would be difficult to keep in order. Adding extra sockets, serial ports or the like to existing apparatus would involve significant hardware modifications, and the software modifications needed to administer the extra ports have been found to be a source of technical problems, whereasBluetooth and WiFi arrangements take extra connections in their stride.

Claims (22)

1. Revenue assurance apparatus for mobile telephony networks comprising at least one mobile telephone handset means, computing means so programmed as to generate instructions for the handset means to make a test call, means to compare a predicted and an actual outcome of said test call and alerting means adapted to indicate when an actual outcome fails to correspond to a predicted outcome.

2. Apparatus as claimed in claim 1, wherein said comparison means is adapted so to compare a predicted and an actual outcome during or substantially immediately fbllowing said test call.

3. Apparatus as claimed in claim 2, wherein said alerting means is adapted so to indicate substantially immediately following a failure of an actual and a predicted outcome to correspond.

4. Apparatus as claimed in any one of claims I to 3, comprising direct wireless communication means operatively connecting the handset means and the computing means.

5. Apparatus as claimed in claim 4, wherein the direct wireless communication means is operable on a waveband allocated for short-range use without specific licensing.

6. Apparatus as claimed in either claim 4 or claim 5, wherein the direct wireless communication means is operable according to the Bluetooth and/or Wi-Fj protocols.

7. Revenue assurance apparatus for mobile telephony networks comprising at least one mobile telephone handset means, computing means so programmed as to generate instructions for the handset means to make a test call, and direct wireless communication means operatively Connecting the handset means and the computing means.

8. Apparatus as claimed in claim 7, wherein the direct wireless communication means is operable on a waveband allocated for short-range use without specific licensing.

9. Apparatus as claimed in either claim 7 or claim 8, wherein the direct wireless communication means is operable in the 2.4G1-Iz waveband (2.40 to 2.4835 GIIz) and/or the 5.8GHz waveband (5.725 to 5.875GHz).

10. Apparatus as claimed in any one of claims 7 to 9, wherein the wireless communication means is operable according to the Bluetooth protocol and/or the Wi- Fi protocol.

11. Apparatus as claimed in any one of the preceding claims, comprising a plurality of handset means, optionally an even number thereof, such as four, six or eight.

12. Apparatus as claimed in any one of the preceding claims, comprising additional Subscriber Identity Module (SIM) card means operatively connectable to the or each handset means.

13. Apparatus as claimed in any one of the preceding claims, wherein the computing means is programmed to receive data from the at least one handset means concerning each test call made thereby.

14. Apparatus as claimed in claim 13, wherein the computing means is programmed to calculate a call data record (cdr) based on said data for each test call.

15. Apparatus as claimed in any one of the preceding claims, wherein the computing means is programmed to compile data and/or cdrs concerning a plurality of test calls for transfer to a database means.

16. Apparatus as claimed in claim 15, wherein the database means is programmed to compare said data and/or cdrs received from the computing means with data and/or cdrs concerning the same test calls received from metering and billing systems of a mobile telephony network through which the test calls were made.

17. Apparatus as claimed in any one of the preceding claims, wherein the computing means is programma to generate a set of test calls complying with preselected parameters

18. Revenue assurance apparatus for mobile telephony networks substantially as described herein with reference to the accompanying drawings.

19. A method for testing call metering and/or billing systems of a mobile telephony network comprising the steps of providing apparatus as claimed in any one of the preceding claims, causing the computing means thereof to instruct a handset means thereof to make a test call over a mobile telephony network, producing a theoretical call data record for the test call and comparing it to an actual call data record for the same call produced by the mobile telephony network.

20. A method as claimed in claim 19, comprising the step of causing the computing means to generate a series of such test calls.

21. A method as claimed in either claim 19 or claim 20, comprising the step of Positioning the or each handset means in a preselected location remote from a central computing means.

22. A method for testing call metering and/or billing systems of a mobile telephony network, substantially as described herein and with reference to the accompanying drawings.