WO1999016232A1

WO1999016232A1 - Data processing system for communications network

Info

Publication number: WO1999016232A1
Application number: PCT/GB1998/002849
Authority: WO
Inventors: Prajay Vinod Shah
Original assignee: British Telecommunications Public Limited Company
Priority date: 1997-09-24
Filing date: 1998-09-21
Publication date: 1999-04-01
Also published as: GB0005485D0; BR9812217A; AU9174198A; GB2344966A

Abstract

A method of processing data concerning communication instances between at least two communications networks comprises the steps of obtaining data concerning communication instances between the communications networks, the data including routing information identifying the communication network from which the communications originate and at least one parameter capable of being processed to generate billing information; storing the data as a plurality of batches; generating a list identifying the batches of data ready to be processed; and operating a plurality of similar independent billing processes in parallel, each billing process using the list to identify a batch of data ready to be processed, to read and to process the batch of data to generate billing information.

Description

DATA PROCESSING SYSTEM FOR COMMUNICATIONS NETWORK

The present invention generally relates to a data processing system for processing data related to communications in a plurality of interconnected communications networks. In particular, the present invention relates to processing of data concerning communications instances in order to generate billing information for communication instances between two communications networks. Where communication instances, for instance telephone calls or data transfers, occur within a single network, it is known to log and process data related to those communication instances. Commonly, in a public switched telephone network (PSTN), data will be collected concerning call duration and processed with respect to at least time of day and call type, so that the network operator can generate an item on a bill destined for the subscriber who initiated the call.

Over recent years, the data systems for PSTNs have necessarily become increasingly complex as the choice of service and call type available to subscribers has greatly increased. For instance, with the introduction of 0800 numbers in the UK, it is no longer the initiating subscriber who will be billed. Many more complicated services are already being tried, or available, on PSTNs, such as call forwarding where a call initiated by a first subscriber to a selected number is forwarded automatically by the network to a different number, the difference in cost being born by the receiving subscriber. Another aspect of communications networks which is in the course of considerable change is the multiplicity of network operators in existence. In the past, PSTNs have been run primarily by government organisations as part of the national infrastructure. Privatisation of the PSTNs and the relaxation of regulatory monopolies in the UK means that there are more network operators available to the subscriber and these network operators must, for practical reasons, provide internetwork connection. This means that a network operator must take into account not only communication instances arising in their own network, or in a limited number of connected networks of independent but similar administrations, but also communication instances arising in a theoretically very large number of competing networks of different types and providing a wide variety of services to subscribers It is therefore of importance that data be collected and processed in connection with communication instances arising outside an operator's network but terminating in or simply crossing the operator's network.

In the paper 'Access Charge and Revenue Architecture' A T & T Technical Journal, Vol. 66, No. 3, May 1 987, New York, US, pages 73 to 81 , by Obuchowski, a data system for predicting access charges and revenue is disclosed, for use by an inter exchange carrier in a PSTN of the US type after the separation of local and long distance carriers in the '80s' (divestiture) .

When calls pass through the network of more than one operator, price and charging agreements between operators for the carriage of each others calls come into play. Such arrangements can vary from the simple Sender Keeps All (SKA) arrangement to complex pricing formulae. It has been an established practice between the separate network operators or administrations in telecommunications, that call data would be collected by the administration responsible for the network in which a call arises. If that call then terminates in a second network, the administration concerned with the second network relies on the data collected by the administration responsible for the first network, for instance for accounting purposes. In GB2254224, a system is described for avoiding double accounting of outgoing international calls based on intelligent network technology.

However, the telecommunications environment is changing quickly, politically as well as technically. With the advent of greater competition, it is increasingly attractive to network administrations to monitor not only traffic arising in their own network but also traffic arising elsewhere but crossing or terminating in their own network. If the network in which traffic arises belongs to a competing operator or administration, it is desirable that it is at least possible to cross check the competing operator's accounts. In known arrangements, data collection points concerning calls in a PSTN have been at local exchanges or networks since the local exchange picks up traffic as it arises. This arrangement, however does not provide for data collection with respect to inter-network traffic. Even were there to be data collection points to collect data on calls incoming to a network, the logistics involved in processing such data to any level of detail are daunting. For instance, it has been estimated that calls incoming to the PSTN operated in Britain by British Telecommunications pic (BT) (hereinafter the British PSTN) from other network administrations including the Isle of Man and the Cellnet cellular network reached 75 million calls per day in April 1 997.

A system has been designed by the present applicants to collect and process data relating to calls incoming to a major telecommunications network, the British PSTN, which can produce and output sufficient detail to allow the associated network administration to generate account information which not only can be allocated to outside network administrations appropriately, but also supports itemised billing information. This system is the subject of International Patents Nos. W094/23529 and W094/23530. Such a system is shown in outline in Figure 1 . Networks 1 and 2 comprise networks outside the administration of network 3. Network 3 in this example comprises the British PSTN. In the PSTN telephone calls made from telephones are received by Digital Local Exchanges (DLE) and can be received directly by Digital Main Switching Units (DMSU). The calls can be routed by the DLEs to the DMSUs in order to pass calls over long distances. The DMSUs can comprise points of interconnection between the first and third networks and the second and third networks. For every call that passes between network 3 and network 1 or network 2 a call detail record is produced by the exchange (DMSU) and DLE for indirect access (IA) calls at the point of interconnection. Periodically a Network Mediation Processor (NMP) 1 polls the exchange (DMSU or DLE) over an X25 network in order to download the call detail records. Call detail records contain routing information identifying the point of origination of the call and the destination, and information which can be used for billing purposes e.g. duration of the call and time of day. The call detail records are received in files from each of the exchanges (DMSUs or DLEs) and polled by the streamer 2. The streamer 2 uses information contained in a routing reference model to deduce the origination and/or destination network for the call. The streamer then divides each of the call record files for the DMSUs into files specific to each network. These call record files are then passed to the company system 3 for charging and pricing. The results of the charging and pricing operation can be summarised into reporting tables which can be accessed by the client system 4 Also, itemised call records can be stored and any errors can be stored. Thus the earlier system provides a system which can collect and process data in sufficient detail to generate accounting information and itemised billing.

However, the volume of call records which can be processed have been found to be limited due to the processing operation carried out in the company system and illustrated in Figure 7 of WO94/23530.

The present invention has thus been designed to overcome the processing limitations of the earlier system.

In accordance with a first aspect the present invention provides a method of processing data concerning communication instances between at least two communications networks, the method comprising the steps of: obtaining data concerning communication instances between the communication networks, the data including routing information identifying the communication network from which the communications originate and at least one parameter capable of being processed to generate billing information; storing said data as a plurality of batches; generating a list identifying the batches of data ready to be processed; and operating a plurality of similar independent billing processes in parallel, each billing process using said list to identify a batch of data ready to be processed, to read and to process the batch of data to generate billing information.

In accordance with another aspect the present invention provides data processing apparatus for processing data concerning communication instances between at least two communications networks, the apparatus comprising: obtaining means for obtaining data concerning communication instances between the communications networks, the data including routing information identifying the communications network from which the communications originate and at least one parameter capable of being processed to generate billing information; storage means for storing said data as a plurality of batches; list generation means for generating a list identifying the batches of data ready to be processed; and processing means for carrying out similar independent billing processes in parallel, each billing process using said list to identify a batch of data ready to be processed, to reach and to process the batch of data to generate billing information.

Thus in accordance with the present invention the speed of the processing of the communication data is greatly enhanced by parallel processing operations carried out with reference to a list identifying the data ready to be processed. The parallel processing of data can be carried out either using one or more processors carrying out a plurality of billing processes in a multi-tasking environment. Alternatively, a plurality of separate processors could be provided each carrying out a separate billing process. In one embodiment one of the communications networks comprises a

PSTN and the data is collected from exchanges in the PSTN.

The obtained data can be formed into the plurality of batches or files by grouping together data for communication instances originating in each communications network. In order to allow each of the billing processes to independently carry out separate billing processing, without duplication, preferably the batch of data identified in the list is flagged as being processed when one of the billing processes selects it for reading and processing. This prevents another billing process from reading and processing the same batch of data. The list can take the form of a table or database such as an Oracle (trade mark) database. The list can thus identify the batch of data i.e. the file and the location of storage of the file. The location can simply be the directory in which the file is stored. Alternatively, where the system operates as a distributed network of computers, and the files can be stored in a distributed manner across the network, the location of storage of the file can identify on which machine or node in the network the file is stored and in which directory on the machine the file is stored.

The generated billing information can also be stored and the list can include information to identify the location of storage of the billing information files in a similar manner to identifying the location of the stored call record files.

In an embodiment of the present invention a batch or file of data is obtained from each origination communication network e.g. from each exchange DMSU. The batch of data or a file is formed to contain data from the same origination communications network. This data can then be processed to generate a file of itemised call records, a file of summary information and a file of errors and/or warnings. The summary information can be merged to form summary tables and the itemised call records can be stored.

Embodiments of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic drawing of a multi-communication network system;

Figure 2 is a schematic drawing of the data processing apparatus of an embodiment of the present invention; Figures 3a, 3b and 3c are a flow diagram illustrating the steps carried out in collecting and processing data related to communication instances in accordance with an embodiment of the present invention;

Figure 4a is a flow diagram illustrating the steps in the billing process in accordance with an embodiment of the present invention; Figure 4b is a flow diagram illustrating the steps in the billing process in accordance with another embodiment of the present invention;

Figure 5 is a table illustrating the streamed file database of the master processor; and

Figure 6 is a table used for storing the results of the billing process operations.

The differences between the present invention and the earlier system of W094/23529 and WO94/23530 reside in the operations carried out in the company system 3 and the way in which the output of the streamer 2 is used. The generation of the streamed call records files is thus as disclosed in W094/23429 and WO94/23530 the disclosure of which is hereby incorporated by reference, and thus the operation of the streamer 2 will not be described in detail.

From the call details records provided over the X25 network from the exchanges (DMSUs) the streamer 2 uses the routing reference model to identify the origination and destination networks. As can be seen in Figure 2, a streamed file storage system 2a is provided to store the streamed call record files generated by the streamer 2. A streamed file database 2b is also generated to identify the files which are ready for billing. The company system 3 will read a streamed file from the streamed file storage system 2a by identifying a streamed file awaiting billing from the streamed file database 2b. Once the streamed file has been processed the streamed file database is marked accordingly and the streamed file can be deleted from the streamed file storage system 2a. In this way there is a 'de-synchronisation' between the operation of the streamer 2 and the company system 3, unlike the earlier system wherein the streamed files were sequentially output to the master processor of the company system 3 and sequentially processed. In this embodiment since the streamed files are stored they can be processed in any order by selection from the streamed file database 2b.

In this embodiment of the present invention the company system 3 comprises a master processor 5 which contains a streamed file database 5a of the form illustrated in Figure 5 which will be described in more detail hereinafter. The master processor 5 operates a procedure 5b to read charged and priced itemised call records from a cluster 8 of slave processors and to store the itemised call records in an optical storage device 6. A merge process 5c operates to read summary information from the slaves of the cluster 8 in order to merge the summary information to form summary tables. A process 5d for reading errors and warnings from the slaves of the cluster 8 is also provided in the master processor 5. The errors and warnings can be passed to a call record error analyser 7 for analysis of the errors and warnings.

In addition to the master processor 5, the company system includes a cluster 8 of slave processors. In the current embodiment 38 slaves operate in parallel. Each of these slaves runs a separate charging and pricing process and obtains the call records directly from the streamed file storage system 2a of the streamer 2.

The client system 4 comprises a processing system connected to the company system 3 to enable the display and analysis of the summary information.

In Figure 2 the passage of data is indicated by the thick lines whilst the passage of control data is indicated by the thin lines. As can be seen in Figure 2 the streamed file database 5a is central to avoid the need for the streamed files output from the streamer 2 to pass into the master processor 5. By providing the streamed file database 5a which is constructed by reading entries from the streamed file database 2b of the streamer 2, the slaves of the cluster are able to identify streamed files available for processing and can then directly obtain streamed files from the streamed file storage system 2a of the streamer 2. Although the output of the cluster 8 is passed into the master processor 5, this is of substantially smaller volume than the unprocessed streamed files from the streamer 2 and thus a potential bottleneck for the data flow is avoided.

The provision of the cluster 8 of slave processors provides a highly resilient and stable system. As call volumes rise the capacity of the system can be increased simply by adding additional slave processors. Further, if any of the slave processors fail, this will not significantly affect the processing throughput of the company system 3.

By 'desynchronising' the operation of the streamer 2 in the company system 3, if there are any problems with processing a file which is streamed out from the streamer 2, the charging and pricing process is not in any way held up since the problem file can be circumvented since the slave processors can select any of the streamed files in the streamed file storage system 2a. Since the streamed files can be of varying size, the period required for the charging and pricing process can vary greatly. Thus, by utilizing the plurality of slave processors in the cluster 8, the call records can be efficiently charged and priced in parallel.

The company system comprises a Hewlett Packard T500/8 computer running the Unix operating system, the Oracle Relational Database Management System (RDMS) and a custom application written using the Coolstuff software from Sterling. The company system 3 networks to the streamer 2 and the client system 4 using an FDDI network using the TCP/IP protocol.

Within the company system 3 the call records are priced by the slaves of the cluster 8 according to complex pricing and charging reference tables. When the processing is complete, the data can be passed from the slaves into the master processor 5 and the Oracle summary tables in the streamed file database 5a can be incremented or changed. Reference tables provide exchange set up data, routing reference data, accounting agreements, pricing and charging data and various classes of exceptions. Pricing and charging reference tables are derived from BT's National Charging Database (NCDB) and inter operator wholesale pricing agreements. These are used by each of the slaves of the cluster. The slaves of the cluster 8 in this embodiment comprise Hewlett Packard

HP735 computers and these individually bid for processing tasks by identifying streamed files awaiting processing using the streamed file database 5a. Although in this embodiment 38 slaves are shown which are capable of handling 75 million itemised call records a day, this number can be any number dependent upon the call processing demand.

Before the method of processing the call records is described in detail, the structure of the streamed file Oracle database 5a will now be described with reference to Figure 5. A streamed file database 5a contains information copied from the streamed file database 2b of the streamer 2. Information in the two databases is mirrored When a file such as file 1 is stored in the streamed file storage area 2a of the streamer 2 and is ready for processing an entry is made in the streamed file database 2b of the streamer 2 and this is copied over to the streamed file database 5a of the company system 3. Initially the entry gives the file name and file location and sets the main status to A indicating that the file is waiting for call processing. All other entries remain blank at this time. After call processing the mam status can either be changed to M indicated that the file is awaiting merge processing or F indicating that the call processing has failed. As can be seen in Figure 5 fileδ failed call processing and thus there are no further entries. Fιle2 however was successfully call processed and is awaiting merge processing. Since the result of the call processing is a summary file for merge processing, an itemised call records file and an errors and warnings file, the database contains entries indicating a file system number for these files. For fιle2 also the status of the itemised call records is set to A and the status of errors and warnings is set to A to indicate that these files are ready for itemised call record storage and errors and warnings analysis.

Figure 6 illustrates an example of a table identifying the database used for the location and storage of the merge files, itemised call records files and errors and warnings files The file system number is used as the reference to Figure 5. The type indicates the type of file which is stored for that file system number. The status indicates whether the area is available (A), read only (N) or shutdown (S) . The location indicates the area assigned for the storage of the files. This can either be simply the directory reserved for storage of the files on the local processor, or in a network arrangement this can comprise an identification of a machine or node and a directory on that machine. Columns also indicate the free space currently available for that area and the total space available for that area.

Once merge processing has taken place to form summary tables, the mam status can either turn to P indicating completion of merge processing or W to indicate that the merge processing has failed. Further, the mam status can also be set to K if call processing has failed for a known reason or Z if merge processing has failed for a known reason Further, the status of the itemised call records storage can be set to P if storage is completed successfully, F if storage has failed, or K if storage has failed for a known reason. The errors and warnings status can be set to P for successful processing of errors and warnings, F for failure to process errors and warnings, K when there is a known failure, or N when there are no errors and warnings output from the slaves following call processing i.e. no error processing is required.

The operation of call record collection and processing in the system in one embodiment of the present invention will now be described with reference to Figures 3a, 3b and 3c. In step S10 rows of the streamed file database 2b with a status R are copied into the streamed file database 5a in the master processor 5 In step S1 1 the status of each row which has been copied is set to A in the streamed file databases 2b and 5a of the streamer 2 and the master processor 5. In step S1 2 the slaves of the cluster 8 then process the streamed files as will be described hereinafter in further detail. Following the processing of the streamed files in step S1 3 the master processor receives a merge file, an errors and warnings file, and an itemised call records file from a slave for a processed file The status of the row in the streamed file database 5a for the processed file is then set to M or F in step S1 4 dependent upon whether the call processing has been successful or not. In step S1 5 the status of the row is then checked and if the status is set to F in step S1 6 an operator can manually intervene to try to correct the reason for call processing failure. If in step S1 7 it is determined that correction is possible the correction is made and in step S20 the status of the row is reset to A and the process returns to step S1 2 where the slave can select the streamed file for processing. If in step S1 7 it is determined that correction is not possible, in step S1 8 the status of the row is set to K and in step S1 9 an error report for the file is raised. The process can then return to step S1 2 for the processing of another file. If in step S 1 5 it is determined that call processing has been successful i.e. the status of the row is M, in the row details of the streamed file database 5a the locations of the merge file, the errors and warnings file and the itemised call records file are entered and the status of the errors and warnings file is set to A or N depending on whether there are errors and warnings present and the status of the itemised call records file is set to A.

Two processes are then carried out in parallel and indicated by the suffixes A and B to the step numbers hereinafter. The two parallel processes are the merging of the summary information and the storage of the itemised call records. Considering first the storage of the itemised call records, in step S22A the location of the itemised call records file with a status A is identified from the entry in the streamed file database 5a. In step S23A the file is then read and in step S24A the master processor 5 attempts to store the file onto the optical disc drive 6. In step S25A it is determined whether the storage attempt has been successful and if not in step S27A the status for the itemised call records file is set to F and in step S28A an operator can manually intervene to try to correct for the reasons for the storage failure. In step S29A it is determined whether the correction attempt has been successful and if so in step S32A the itemised call record status for the row is set to A and the process returns to step S22A in an attempt to try to store the corrected file. If in step S29A it is determined that correction is not possible in step S30A the itemised call record status for the row is set to K and in step S31 A an error report is raised for the file. The process can then return to step S1 2 for the processing of another file. Referring now to the merge processing operation, in step S22B the location of a merge file is identified from the database entry and in step S23B the merge file is read. In step S24B the summary information is merged to form a summary table. The summary tables can hold both daily summaries and monthly summaries and provide the basis from which end users can produce billing reports. Information held on these summary tables include the number of calls made, the duration of these calls and various items of settlement information. Call details are grouped by items such as operator, date of the calls, the accounting period they were processed in, the wholesale call class, the type of service, direction, point of interconnection, route, tariff period, tariff options and time period. In step S25B it is determined whether the merge processing has been successful. If not in step S26B the main status of a row is set to W and in step S27B an operator can manually intervene to try to correct the reason for the merge failure. In step S28B it is determined whether the correction attempt has been successful and if so in step S31 B the main status of the row is reset to M and the process returns to step S22B. If in step S28B it is determined that the correction attempt has not been successful, in step S29B the mam status of the row is set to Z and in step S30B an error report is raised for the file. The process can then return to step S 1 2 to process another file. If in step S25B it is determined that the merge processing has been successful, in step S32B the mam status of the row is changed to P and the merge file is deleted.

The process then splits into two parallel processes and in step S43B entries in the streamed file database 2b of the streamer 2 corresponding to the streamed file database 5a of the master processor 5 are set to status P. In step S44B the streamer then deletes the files in the streamed file storage system 2a which are marked P in the streamed file database 2b. In step S45 the status of the deleted files in the streamed file database 2b is then changed to D and the entries marked in the streamed file database 2b are deleted by an archiving process in step S46B.

In step S33B when the row main status is P and the errors and warning status is A in the streamed file database 5a the errors and warnings file is located from the row details and read. In step S34 the errors and warnings file is then loaded into the call record error analyser 7 for analysis. In step S35B it is determined whether the loading has been successful and if not in step S37B the errors and warnings status is set to F. In step S38B an operator can manually intervene to try to correct the reason for the error file loading failure. In step S39B it is determined whether correction is possible and if so the errors and warning status is set to A in step S40 and the process returns to step S33B. If correction is not possible in step S41 B the errors and warning status is set to K and in step S42B an error report for the file is raised. The process then returns to step S1 2 for the processing of another file.

If in step S35B it is determined that the loading of the errors and warnings file has been successful, in step S36B the errors and warning status is set to P and the errors and warnings file is deleted. The process can then return to step S1 2 for the processing of another file.

Although in the flow diagram described heremabove with reference to Figures 3a to 3c the merge processing, itemised call records storage, and errors and warnings loading has been described as being a series of sequential operations, these are preferably be carried out in parallel on the three output files from the slaves of the cluster 8 resulting from the call processing. These operations can be carried out in parallel with the call processing operations of the slaves of the cluster 8. In a preferred embodiment of the present invention processing is carried out by individual modules which therefore allows for a significant degree of parallel processing.

To remove entries from the streamed file database 5a, an archiving process will delete rows having a main status P, K or Z, an itemised call record file status P or K, and an errors and warnings file status of P, K or N.

A first method of call processing the streamed files will now be described with reference to Figure 4a. The method of Figure 4a is carried out by a call processing program and a control program. In step S1 20 the control program of the slave polls the streamed file database 5a of the master processor 5 to identify a streamed file requiring processing. In step S1 21 when a file is identified the file is flagged in the streamed file database. In step S1 22 the streamed file is then copied from the streamed file storage system 2a in the streamer 2 into the slave. In step S1 23 the slave control program starts the call processing program and in step S1 24 the slave control program waits until the call processing program completes call processing. In step S1 25 once the call processing has been completed the call processing procedure is shutdown by the slave control program and in step S 1 26 the slave control program copies the summary information, the errors and warnings, and the itemised call records produced by the call processing program to the master processor 5. In step S1 27 the slave control program then changes the mam status for the file in the streamed file database to M or F and sets the itemised call record status to A and the errors and warnings status to A or N. Also, the locations of the stored merge file, itemised call records file, and errors and warnings files are identified by the appropriate file system number in the row. In step S1 28 the slave control program then deletes the local copy of the streamed file and the call process files and the process returns to step S1 20. This process is repeated and is carried out in parallel on each of the slaves of the cluster 8.

Figure 4b illustrates an alternative method of carrying out the call processing. This method differs from the method of Figure 4a in that the call processing program is constantly run and there are a plurality of call processing programs running on a single processor in a multi-tasking environment. This improves the data throughout and improves the processing time.

Referring to Figure 4b, in step S1 20 the slave control program polls the streamed file database 5a to identify a streamed file requiring processing. In step S1 21 when a file is identified it is flagged in the streamed file database 5a. In step S1 22 the streamed file is copied from the streamed file storage system 2a of the streamer 2 into the slave. In step S 1 23 the slave control program passes the file to one of the call processing programs which is requesting data. The call processing program can then carry out call processing and in step S1 24 if there are any further call processing programs requesting a file, the process returns to step S1 20 whereby the control program will get another file for processing. In step S1 25 if any call processing programs have finished processing a file, in step S1 26 the slave control program copies the summary information, the errors and warnings, and the itemised call records produced by the call processing program to the master processor 5. In step S1 27 the slave control program then changes the main status of the file in the streamed file database to M or F, enters a status for the itemised call records as A, and enters an errors and warnings status as A or N In step S1 28 the slave control program then deletes the local copy of the streamed file and the call process files and in step S1 29 the call processing program then requests more data and the process returns to step S1 20.

Although embodiments of the present invention have been described heremabove with reference to a PSTN communication network, the present invention is not limited to such a network. The present invention is applicable to any system which involves multiple communications networks. The present invention is not limited to voice communications systems and is applicable to any communications systems which require billing information to be generated.

Claims

1 . A method of processing data concerning communication instances between at least two communications networks, the method comprising the steps of: obtaining data concerning communication instances between the communications networks, the data including routing information identifying the communications network from which the communications originate and at least one parameter capable of being processed to generate billing information; storing said data as a plurality of batches; generating a list identifying the batches of data ready to be processed; and operating a plurality of similar independent billing processes in parallel, each billing process using said list to identify a batch of data ready to be processed, to read and to process the batch of data to generate billing information.

2. A method according to claim 1 wherein one of said communications networks comprises a public switched telephone network, and the obtaining step comprises collecting said data from exchanges in the public switched telephone network.

3. A method according to claim 1 or claim 2 wherein the obtained data is formed into said plurality of batches by grouping together data for communication instances originating in each communications network.

4. A method according to any preceding claim wherein a batch of data identified in said list is flagged as being processed when one of said billing processes selects to read and process the batch of data to prevent another of said billing processes from reading and processing the batch of data.

5. A method according to any preceding claim wherein said list identifies the batch of data and the location of storage of the batch of data.

6. A method according to claim 5 including the step of storing the billing information, wherein said list also identifies the location of storage of the billing information.

7. A method according to any preceding claim wherein the obtained data comprises call record information obtained from points of interconnection between said communications networks, the method including the step of forming each batch of data by forming a file of call record information for each originating communication network for a set of call records information obtained from a point of interconnection between said communication networks.

8. A method according to claim 7 wherein each of said billing processes generates a file of itemised call records, a file of summary information and a file of errors and/or warnings for each call records information file processed.

9. A method according to claim 8 including the step of merging the summary information files to build summary tables.

10. A method according to claim 8 including the step of storing the itemised call records.

1 1 . Data processing apparatus for processing data concerning communication instances between at least two communications networks, the apparatus comprising: obtaining means for obtaining data concerning communication instances between the communications networks, the data including routing information identifying the communications network from which the communications originate and at least one parameter capable of being processed to generate billing information; storage means for storing said data as a plurality of batches; list generation means for generating a list identifying the batches of data ready to be processed; and processing means for carrying out similar independent billing processes in parallel, each billing process using said list to identify a batch of data ready to be processed, to read and to process the batch of data to generate billing information.

1 2. Data processing apparatus according to claim 1 1 wherein said processing means comprises at least one processor for operating a plurality of billing processes in a multi-tasking environment.

1 3. Data processing apparatus according to claim 1 wherein said processing means comprises a plurality of processors, each said processing means being operative to operate one of said billing processes.

14. Data processing apparatus according to any one of claims 1 1 to 1 3 wherein one of said communications networks comprises a public switched telephone network, and said obtaining means comprises means for collecting said data from exchanges in the public switched telephone network.

1 5. Data processing apparatus according to any one of claims 1 1 to 14 wherein said obtaining means includes means for forming said plurality of batches by grouping together data for communication instances originating in each communications network.

1 6. Data processing apparatus according to any one of claims 1 1 to 1 5 including means for flagging a batch of data identified in said list as being processed when one of said billing processes selects to read and process the batch of data to prevent another of said billing processes from reading and processing the batch of data.

17. Data processing apparatus according to any one of claims 1 1 to 1 6 wherein said list identifies the batches of data and the location of storage of each batch of data.

1 8. Data processing apparatus according to claim 1 7 including billing information storage means for storing the billing information, wherein said list also identifies the location of storage of the billing information.

1 9. Data processing apparatus according to any one of claims 1 1 to 1 8 wherein said obtaining means is adapted to obtain said data as call record information from points of interconnection between said communications networks, the apparatus including means for forming each batch of data by forming a file of call record information for each originating communications network for a set of call records information obtained from a point of interconnection between said communications networks.

20. Data processing apparatus according to claim 1 9 wherein said processing means is adapted to run each of said billing processes to generate a file of itemised call records, a file of summary information, and a file of errors and/or warnings for each call records information file processed.

21 . Data processing apparatus according to claim 20 including means for merging the scanning information files to build summary tables.

22. Data processing apparatus according to claim 20 including means for storing the itemised call records.

23. Data processing apparatus substantially as hereinbefore described with reference to and as illustrated in any of the accompanying drawings.

24. A method of processing data substantially as hereinbefore described with reference to any of the accompanying drawings.