Title of Invention	A METHOD AND A TELECOMMUNICATION SYSTEM FOR FORMATTING CALL DETAIL RECORDS IN A TELEPHONE EXCHANGE
Abstract	In known telephone systems it is very difficult to change call detailed records COR formatted from a raw data flow. In the proposed method, the exchange supplier formats a special mother form, which is a file and which shows in plain language (in ASCII form) all names and parameters of fields in the raw data flow. The operator has a program using a graphic in- terface and showing the mother form in the display. Beside it a user form blank is seen and the user selects the fields he desires simply by dragging with the mouse the field of his choice from the mother form into the user form an by dropping the field here (drag and drop). In this manner the user formats his own form, which contains such data only which he wishes to have in the COR. When the user form has arrived at the telephone exchange and at the billing centre, it can be activated at any time. The formatting process hereby extracts from the raw data flow the data corresponding to fields stated in the form, thus formatting the COR and sends it to the billing centre, which using the same form made by the user will interpret the data contained in the received COR, that is, it creates fields and attaches data belonging to fields from the COR. Thus, the names of fields are not transferred from the exchange to the billing centre.

Title of Invention

A METHOD AND A TELECOMMUNICATION SYSTEM FOR FORMATTING CALL DETAIL RECORDS IN A TELEPHONE EXCHANGE

Abstract

In known telephone systems it is very difficult to change call detailed records COR formatted from a raw data flow. In the proposed method, the exchange supplier formats a special mother form, which is a file and which shows in plain language (in ASCII form) all names and parameters of fields in the raw data flow. The operator has a program using a graphic in- terface and showing the mother form in the display. Beside it a user form blank is seen and the user selects the fields he desires simply by dragging with the mouse the field of his choice from the mother form into the user form an by dropping the field here (drag and drop). In this manner the user formats his own form, which contains such data only which he wishes to have in the COR. When the user form has arrived at the telephone exchange and at the billing centre, it can be activated at any time. The formatting process hereby extracts from the raw data flow the data corresponding to fields stated in the form, thus formatting the COR and sends it to the billing centre, which using the same form made by the user will interpret the data contained in the received COR, that is, it creates fields and attaches data belonging to fields from the COR. Thus, the names of fields are not transferred from the exchange to the billing centre.

Full Text	Extraction of desired data from data flow Field of the invention This invention concerns extraction of desired data from a structured data flow, especially extraction of predetermined data from a continuous flow of call detailed records produced by a telephone exchange. Background of the invention Billing in consequence of services is implementation of the agree¬ment between the service producer and his customer. In principle, there are two kinds of billing: decentralised and centralised billing. In decentralised billing, the customer pays to the seller for each time of using services provided by the seller. The payment is performed ei¬ther with conventional money or with some equivalent means of payment, e.g, postage stamps are used when paying for delivery of letters. A more re¬cent example of a means of payment used in decentralised billing is elec¬tronic money where each "coin" consists of a an encrypted binary sequence, which must be verified by a bank server. In centralised billing, the use of services is monitored by the seller or by a third party. The customer is billed periodically, e.g. once a month. The bill is based on monitoring data collected for the preceding billing period. Examples of centralised billing are electricity, telephone and credit card bill ing. Centralised billing consists of three steps. The first step is an agreement between the parties on services and on related billing. The second step is monitoring (or measurement) of the use of services and saving of data con¬cerning the use. The third step is formatting of the bill and sending the same to the customer. The bill is formed according to data saved in the billing system. The centralised billing used in a telephone network is based on an agreement between subscribers and operator. The essential point of the agreement is that the subscriber gets access to telephone services, that is, he may make and receive calls, and as a compensation for the service pro¬vided he performs payments according to predetermined tariffs, as specified in bills sent to him by the operator. The bills typically include charging of two types: fixed charges and use charges. The fixed charges are independent of whether services are used or not. Use charges depend on how many calls the subscriber has made and possibly also on how many calls he has re¬ceived. To be able to debit for use charges the operator must monitor made and received calls. Such monitoring is connection-based and it is performed by network switches. Figure 1 illustrates a known centralised billing method used in a telephone network by presenting a part of a public telephone network. For each call which is made the local exchange LE (the subscriber's Local Ex¬change) performs a call detailed data collection and formats a CDR (Call Detailed Record). The record contains all the information required in billing for one call as well as any desired quantity of other information related to the call. Call detailed data collection is always used when specified detailed in¬formation on a call is required for billing or for monitoring of call details. The structure of the call detailed record is determined by a an operation control command before the call detailed data collection is introduced. The record structure must be determined as a uniform structure in all exchange ele¬ments controlled by the network management. Hereinafter the call detailed records will also be called by the name of CDR and the program formatting the call detailed records will be called the CDR generator. Formatted CDRs are sent to the BS (Billing Centre) for post processing. Fonnatting of the call detailed record requires that the operator es¬tablish some basis for formatting of the call detailed record. Formatting may be based e.g. on call detailed data collection of all the calls of the subscriber or formatting may be based on the call type, that is, whether the call in ques¬tion is a normal call, a facility call, such as call transfer etc., a call free of charge,, an IN call (intelligent network call) etc. In fixed network applications there are about 30 different formatting bases. The formatted call detailed re¬cords are first saved in the memory and are then sent to the centralised bill¬ing system, where they are saved in mass storage, e.g. on magnetic tape or on a hard disk. Between the exchange and the billing system there may also be an additional processing step, wherein call detailed data collection records are "pre-processed" for the billing system. Such pre-processing may be format¬ting, where e.g. a tariff class field Is converted from one format into another. Whether there is pre-processing or not, call detailed data collection will pro¬duce enormous data blocks containing even millions of records, and these may be saved in the billing system's mass storage. The records form the raw information which the billing system begins to process. Thus, processing of call detailed data collection records takes place at a later moment as batch processing which is separate from the generation of call detailed data collection records. It should be noted that in practice billing may be even much more complicated than the example described above. E.g. in a mobile station network, each mobile services switching centre taking part in the call may generate call detailed data collection rec¬ords. However, the billing principle is as described in the foregoing. Processing of a CDR format in present fixed network telephone systems is described in the following referring to Figure 2. The figure shows functions of the telephone exchange which are essential from the viewpoint of the invention. The call detailed data collection process obtains information related to the call as raw data in individual messages mainly from the call control. The call detailed data collection process saves the information in a record reserved for the call. On termination of the call or in connection with interim data collection, the data collection process sends the call record as a whole in messages of various types to the process for saving of call detailed rec¬ords. The message has a call type number indicating the nature of its con¬tents and a message sequence number, The structure of successive mes¬sages is always the same and the type will determine which fields in the message must be filled in. If the number of fields to be filled in is less than the number of fields in the message, then void fields are filled in with a filling code. The messages are thus always sent in their entirety. The saving process goes to read the message structure in a sepa¬rate format file and starts formatting of the record from a raw data flow which it receives. The structure of the call record and of the format file is fixedly structured in the code of the process for storing the call detailed data collec¬tion. Fixed coding is done, because the place of the field in the call record is not found out from the format file. The process for saving the call detailed data collection reads the formatting file successively and from the received call record it picks up a field for locating it in the CDR, if in the formatting file the said field is defined as one to be taken along. The manner in which the individual field is coded in the CDR is also fixedly established in the code of the process for saving the call detailed data collection. If it is desired in some application to have a different processing for some field in a message, e.g. a time field format, then this must be done through control of the application switch. When the process for saving the call detailed data collection has completed the CDR, it locates it in the RAM block. Normally, one block can accommodate 5-10 CDRs. When the block is completed, it Is saved on the hard disk of the concerned telephone exchange or it is sent outside the ex¬change to some I/O equipment, e.g. to the hard disk of the operation control centre. It is also possible to send received blocks directly to the post proc¬essing process. It Is possible for the operator to output e.g. CDRs formatted of some subscriber's calls from a block saved on the hard disk of the operation control centre. This is done with a Man Machine Language (MML) command. The command starts a read program, wherein the structure of the format file of call detailed data collection and the names of fields corresponding to its sub-files are fixedly coded. Reading is performed from the ring buffer of the hard disk. Formats saved in the formatting file will also be briefly described. The operator brings about the format he desires with an MML command. The command will first output for the operator in plain language in the monitor display all fields .1. sub-files available in the message. Thereupon the opera¬tor selects those fields which he wishes to locate in the format to be made. From the available fields the operator may take a field or remove a field, but he can not change the order of fields. When the user has made his choice, the format is completed and it may be output to the display or printed out on paper. The output will indicate in plain language which fields are present in the format. The format may be e.g. in the form CALL SUBSCRIBER NUMBER 10 whereby the name of the field is call subscriber number and the numerical value 10 expresses the place of the field combination in the CDR. The MML function reads the fields (sub-files) available in the format file of the call detailed data collection process and uses the same both in the MML command, with which the user creates the format he desires, and in the MML command, with which the format chosen by the user is output onto the display or on paper. It is shown by the format file which fields can be chosen and whether the chosen field is present in the call detailed record CDR. The format file contains as many sub-files as the maximum number of fields in the call detailed record CDR, The structure of the format file's sub-file is of the type: FIELD_IN_RECORD POSITION TRUE 0 As can be seen from the shown type, it does not indicate the field name in plain language. For this reason, the names of fields in plain lan¬guage as well as their correspondence in the format file are fixedly coded in the MML function. Coding is e.g. as follows: IF CRPARA.SUB_REC(1).FIELDJN_REC0RD=TRUE THENDO: CALL MOVBC'CALL TIME",MML_F0RMAT.RECORD_HEADER... This means that if a field located in position 0 from a fomiat file by the name of CRPARA, which field is here called FIELD_IN_RECORD, is true, that is, the user chose it when making the format, then it is given the name CALL TIME in plain language. There are some drawbacks in the state-of-the-art formatting of call detailed records described in the foregoing. Firstly, when call detailed records are sent from a telephone ex¬change to a billing centre performing post processing, the data flow to be sent is a big one, Above ail, it contains plenty of void or unmarked fields. When the raw data flow contains data in binary form, in hexadecimal form and in ASCII form, then the formatted CDRs will also contain data which is in different forms. Data in different forms will add to the quantity of data to be transmitted from the exchange. Secondly, if the billing centre wants CDRs of other kinds, that is, to add new fields or to remove fields presently in use, it is not only difficult but also risky to make any changes, since it must unconditionally be ensured that any changes made in the formatting file are made correctly and that the receiving end of the post processing site, that is, the billing centre, is able correctly to interpret the changed CDR data flow. In addition, some data is also usually lost when the format is changed. Thirdly, since in the state-of-the-art arrangement the incoming data flow in all functions related to the format or field names and their correspon¬dence in the format file are fixedly coded in the program blocks, necessary changes must always be made in the call detailed data collection saving process, in the data collection process, in the MML program and in programs related to output of CDRs when an entirely new data element is desired in the format. Besides changes in programs, the formatting file structure must also be changed and a change must be made in the conversion program of this file. The second and third items are so troublesome that the exchange supplier must know which format the buyer desires even a year before the exchange is delivered to the buyer. Thus, it is both difficult and expensive to change the format once it is made. The present invention alms at a method not suffering from the mentioned drawbacks in use. The objective is thus a method where chang¬ing of the format is more dynamic and more reliable than in any known method. It ought to be possible to change the format "on the move" and post processing must be prepared at once to process any changed CDRs. It should be possible to create different CDRs for various purposes and thus also to bring about CDRs which are shorter than present CDRs. The established objectives are achieved with the method and sys¬tem described in the independent claims. Brief summary of the invention The invention is based on the idea to use a special form for ex¬tracting desired data from a raw data flow. The number of forms may be high, however, so that there may be only one active form for each type of message. Each form defines exactly that infonnation, which should be ex¬tracted from the raw data flow in order to format a CDR. When a form is acti¬vated, the formatting process will extract the data determined by the form from the data flow. To this end, the exchange supplier formats a special mother form showing in plain language (in ASCII form) all the names and parameters of fields arriving as a raw data flow. Thus, the mother form is a file containing the message structure. Each different message has its own mother form. The mother forms are delivered to the user e.g. on a diskette. The user has a program using a graphic user interface which shows the desired mother form in the display. Beside this a user form blank can be seen and the user chooses the fields he desires simply by using the mouse to drag the field of his choice from the mother form to the user form where he drops the field he has chosen (drag and drop). In this manner the user makes his own form, which contains only the data he wants to include in the CDR. If the user so desires, he may also determine the form in which he likes the data to be. It is possible that the user wishes all data to be in binary form. The user delivers his form e.g. on a diskette to the exchange and to the billing centre. On arrival of the user form at the telephone exchange, it can be ac¬tivated at any time. When the form is active, the formatting process will use this fomfi in the manner of a filter and extracts from the raw data flow the data corresponding to the fields indicated on the form, thus formatting the CDR. When the CDR is completed, the exchange will send it to the billing centre, which using the same form made by the user will interpret the data contained in the received CDR, that is, it creates fields and attaches the data belonging to the fields from the CDR. The names of fields are thus not transferred from the exchange to the billing centre. Before activation of the user form, It is possible to test the form. Hereby in the exchange the formatting process makes the CDRs defined In the form and sends them to the billing centre. This for its part will find that the CDRs are test CDRs and will handle them accordingly. Only after testing has shown that the user form works correctly both in the exchange and in the billing centre, it may be put into active use. Brief description of the drawings The invention will be described more closely in the following with the aid of the attached diagrammatic drawings, in which Figure 1 shows the billing principle. Figure 2 shows formatting of CDRs, Figure 3 shows network elements taking part in implementation of the inven¬tion Figure 4 shows a mother form, Figure 5 shows a user form. Figure 6 illustrates formatting of a user form, and Figure 7 shows use of the form in fomnatting of CDRs. Detailed description of the invention Figure 3 shows a telecommunication network which may be a PSTN or an ISDN network and which comprises several telephone ex- changes 1,2,..,N, each one of which formats a subscriber record CDR relat¬ing to a call made by a subscriber through an exchange. The Network Man¬agement System NMS indicated by reference number 4 attends to network management by controlling various exchanges. The billing centre BC indi¬cated by reference number 5 receives call detailed records CDR arriving from different exchanges, it processes them and forms bills to be sent to subscribers. If there is no separate network management, then control and configuration of the exchange may be performed in the exchange proper in¬stead of using remote operation. Reference number 6 indicates a general purpose computer, which contains a program with which the operator/user uses a mother form for making a user form according to the invention. The supplier of the telephone exchange for his part makes the mother form in a manner explained hereinafter. The exchange supplier naturally has exact information about the contents of the raw data flow arriving in the message. The message struc¬ture is always the same, that is, the fields of the message and their parame¬ters (location, length, type etc.) are constant. The message type determines which fields will be filled in when forming the message. The message is al¬ways sent in its entirety, so any fields left void must be filled with filling code. Thus, the type of message may change, although the message number re¬mains the same. The message number and the type of data block arrive in the data flow. Table 1 below illustrates the contents of a message. signal charging_msg_s = ( seq_number order_numbcr call_recordJnd byte; dword; record_number_t; in_cgr_name out_cgr_name call_record service record cgr_name_t; cgr_name_t; caIl_record_t; svcfil_t; Table 1 The message is a "signal charging message" and its number is 0x4543. The data flow of the message is successive fields of different lengths, e.g. the first field in position 0 is seq_number and its length is one byte, the next field in position 2 is order_number and its length is n word. In reality, there are no field names in the message, but the message consists of field bits, which are after one another without break and without any separa¬tor marks. However, the location of each field is determined unambiguously when field positions and lengths are known. Thus, e.g. the beginning of the third field's call_record_ind (position 3) is found out. by jumping from the be¬ginning of the message by the number of bits of the two preceding fields of messages, that is, forward by one word and one byte. From this point for¬ward there are as many bits of the third field in the flow as is indicated by the length of the field. Since the exchange supplier always has a tool, that is, a program, with which the message structure can be opened as position and field data, It is simple to use this program and a suitable windows© program for making the mother form. The Windows program is used for making a form having a form header and CDR headers of the desired form. The headers are in plain language. Placed under the headers are field names and field data such as the toolkit has opened them from the message. All fields are contained in the mother form. However, the order of fields need not be the same as in the message data flow. The toolkit functions as a link between message fields and the contents of fields in the data flow. Figure 4 shows the form of a mother form. The file name seen in the top part of the form contains mother form data: the first digits of the se¬ries of numbers, here 4543, give the message number to which the form is related, the next three digits 000 indicate the type of message. The letter M indicates that the form is a mother fomn. The three digits after full stop indi¬cate the version in succession of the mother form: if the message is changed, the mother form will of course also be changed, whereby it will have a new version number, This data contained in the file name is not part of the fomn proper, but it is brought into the display by the windows© pro¬gram. The form header on the following line contains the fields Format Number, which indicates the message number and type, Output Mode, which here is BIN and Indicates the mode of the CDR produced with the form, and Output device, which indicates where the CDRs to be fomiatted are saved. The place of storage may be e.g. VDS, that is, Virtual Disk Sys- tern or VIDAST, where some hundred CDRs are collected on the disk and are then sent as a cluster to the billing centre. Output device may also de¬termine that the CDR be sent immediately after fonnatting to the Hot Billing System. Then comes data relating to the header line of the CDR to be for¬matted on the mother form. The data relates to CDR headers and is grouped under the Header field name, Type and Length of the headers. Thus all header fields and their data existing in the message and uncovered with the toolkit will come under Header field name. In the examples, the record length, hea_recordJength, is first as record type W (Word) and length 2 words. After these comes data relating to data fields of CDRs of the mes¬sage proper. This is grouped under headers Data field Name, Type, Length, Position and Format. All data fields and their data existing in the message and uncovered with the toolkit come under the headers. The form shows e.g. subscriber A's field, the data type, length, position (26"' byte in the message) and format (BCD coded). In the Format column of the form the character of the field is indicated: BCD means Binary Coded Decimal, DM is datum. The numbers located after these are instructions for the formatting program. E.g. number 1 might mean convert the binary coded data into BCD format. The mother form according to Figure 4 is thus formed for each message. The header and data fields and their parameters can be seen in each form in a form which is easy to read and in plain language. The work station is able to make the linkage from a field on the mother form to the right spot in the raw data flow. After the mother form has been formatted by the supplier of the telephone exchange, e.g. in the telephone exchange shown in Figure 3, a copy of it will be transferred from the computer to a diskette. The mother form on the diskette Is of a read-only type, so it can not be edited in any way. This means that when the exchange supplier has made the mother form and delivered it to the operator, the latter can not change the mother fomn. Of course, the supplier may make changes. Thereafter the diskette is taken to the operator's billing centre or to the network management unit, and it is pushed into a general purpose com¬puter, e.g. into computer 6 in Figure 3. This computer has a windows based program, which creates a user form and the operation of which will be de¬scribed in the following. 1 The user form shown in Figure 5 has a lay-out which is quite similar to that of the mother fonn. Thus the file name of its top part contains the same data as In the mother form: the first digits 4543 of the series of num¬bers give the message number, to which the mother form and thus also the user form are related, the following three digits 003 indicate the message type. The letter P states that the form is a passive form. The significance of this will be explained later. The full stop is followed by three digits stating the version of the user form: the user may at any time create a new form, whereby it will have a new version number. The form header on the following line contains the fields Format Number, Output Mode and Output device, which states that the CDR to be formatted with the form will be saved on a diskette. These are followed by data relating to the first header line of the CDR to be formatted, Header field name, Type and Length. The proper fields contained in the CDR come under Data field Name, Type, Length , Position and Format. The said form headers and header lines come automatically ac¬cording to the mother form into the user's computer display when he has started the program and has pushed the diskette into the read station. The field names are exactly the same as in the mother form and they can neither be changed nor must they be changed. Figure 6 shows a view seen by the user after starting the program and after he has pushed the diskette into the work station. The view is a typi¬cal windows view with its basic keys. On the right hand the diskette has pro¬vided a mother form according to Figure 4, which contains ail possible mes¬sage fields. On the left hand is a user form blank according to Figure 5. The user picks up the fields he desires from the mother form simply by choosing them with the mouse and by dragging them into the user form and dropping them under the respective field header. Thus, in the case shown in the fig¬ure, the user has chosen from the header fields of the mother form the first four fields, but from the data fields only Subscriber A's field and those fields which give the start time of the call and the end time of the call respectively. It is possible for the user in some cases also to change parameters of the fields. Thus e.g. the length of the Subscriber A field, which is 16 char- acters in the figure, may be shortened to 8 characters by replacing the num¬ber 16 with the number 8. When the user has made the form he desires, it is saved and transferred in one way or the other to computer 5 in the billing centre and to exchange 1, Figure 3. Field "customer form" in the top part of the form con¬tains status code P, which means a passive form. Saving may be done on a diskette, which is taken to the OMU unit (Operation & Maintenance Unit) of the telephone exchange and to the billing centre. Saving may also be done in such a way that the user form is transferred as a file transfer or the diskette is taken to network management 4, Figure 3. When he desires, the user of this will press e.g. the send key on the computer 6, whereby, network management will transfer the user form to the telephone exchange and to the billing centre. Testing of the user form can now be performed. When the form has been transferred to the telephone exchange and to the billing centre, testing is performed without Interfering with any formatting and sending of CDRs which are going on at the time. Testing is carried out in such a way that net¬work management gives the name of the passive form to be tested and the exchange is notified that this form is being tested. The MML function then feeds such a test data flow to the telephone exchange which has the struc¬ture of a proper message. The test data may be a binary file corresponding to binary data of the correct message and which may be edited. From the incoming test data flow the formatting process picks up the data corre¬sponding to fields specified in the form and formats CDRs according to the form. The fomiatted test CDRs are sent among CDRs proper to the billing centre. The test CDRs are data queues of a certain length which are sent to the billing centre as they are produced. Since it has at its disposal exactly the same user form as the one with which desired data was extracted from the test data flow during the formatting process in the exchange, it is able by using the same form as interpreter easily to format field names and to ap¬pend to these exactly correct data from the data flow. As a result, the billing centre obtains In the display the field names given in the form and the correct records under the names. For the billing centre to be able to distinguish test CDRs from proper CDRs, the arrangement may be such that the test form produces some separator in the CDR, whereby the billing centre will not take the test CDR to post processing proper. It is of course possible to take test CDRs to post processing proper and to format telephone bills of them. This is advan¬tageous so that the correct function of the test form can be ensured until the end. The separator marks in the test CDRs guarantee that formatted tele¬phone bills will not be sent any further. When testing has shown that ail is working without fault, the form which is in a passive state (mark P) may be activated by changing the mark into A (Active). Activation is done e.g. by network management by using the windows program to bring up the passive form and by pressing the "activate form" key, Figure 6. The change from passive into active is done in the tele¬phone exchange. Thereupon the call detailed data collection saving process, Figure 2, immediately puts the now active user form into use and begins for¬matting CDRs, wherein there are records indicated in fields of the form. The formatted CDRs are sent by the telephone exchange to the billing centre, which using the same form can extract the connect records from the data flow. Some checks may be made in the telephone exchange as regards the formatted CDRs. Firstly, an Initial check can be made by ensuring that the call end time minus the call start time picked up from records is equal to the length of the call. Secondly, a CRC check or some other known transfer protection may be added to the data to be sent on the transfer path from the telephone exchange to the billing centre. Thirdly, a separator mark of suffi¬cient length may be added to forms so that formatted CDRs can be clearly distinguished from each other. Figure 7 shows the use of user forms in a telephone exchange. The user forms in a passive state are saved in the OMU. In function 71 the user makes the form or forms he desires, which are then taken on a diskette to the telephone exchange or to the network management common to all ex¬changes and to the billing centre. The user requests that an MML command be given for performance of the test. When the operator wishes to introduce a certain form to get the CDRs he desires, he presses the Activate Form key in the program, which gives the MML function a request for activation of the form. The command picks up the desired form from the directory and makes it active, function 72. At the same time, the billing centre has introduced the same form. The for¬matting process 73 produces desired CDRs, which are sent to the billing centre. The use of forms according to the invention allows very flexible ed¬iting of CDRs. When e.g. it is desired to add a field to the CDR, say, an en¬cryption code, an old form is taken as a basis and the encryption code Is added to it. The Windows program generates a new version of the form, which will have a new format number. The new form is sent to the telephone exchange and to post processing. During this time, the CDRs are still filled with the old form. After the test CDR has been sent and the functioning of post processing has been ensured in the billing centre, the new form is acti¬vated at the same time as the old form is made passive. The exchange will immediately produce CDRs, wherein the encryption code is present and which carry the new format number. The format is thus exchanged on the move. The use of forms is also very convenient when raising the ex¬change standard, which means changing of the exchange software. Hereby generated and frozen mother forms con-esponding to the new standard and having as their file name e.g. 4543000M.100 are taken to a new directory of the computer. The version number has been changed here into a new hun¬dred number and the first number is 100. The now active user forms are then copied into the same directory and a conversion program is run, which will convert old user forms to correspond with the new message, where fields have new positions. Field names are used as search keys. The version is changed in the conversion, e.g. 4534003A.008 -> 4543003P.101 and like¬wise the format number changes e.g. 003008 -> 003101. New passive forms are then sent to the telephone exchange on the so-called trial side, where testing of the new software is performed without interfering with the old run¬ning software, and to post processing. Next, new test CDRs are sent from the trial side, if possible, and the functioning of post processing is ensured. Upon completion of testing; the new fomns are activated from the trial side and switch-over is done, whereupon the new forms are in use. If there is no separate network management and billing centre in the network, the user form is made with the aid of a separate general pur¬pose computer, which is indicated by reference number 7 in Figure 3. The mechanism of the invention has the advantages that change of format can be done dynamically on the move and post processing is imme¬diately synchronised into the change. Several different CDRs can be made for different requirements, whereby it is possible to format short CDRs. A cor¬rect functioning is ensured by sending test CDRs. The form contains all the data relating to formatting, transferring and interpretation of CDRs. CDR for¬mats are managed in a centralised manner and the same graphic user in¬terface is used both by the exchange supplier and by the operator. a1. A method of formatting billing records in a telephone exchange, wherein call records come in messages of different types containing raw data to the formatting process, which formats call detailed records (CDR) to be sent to a billing centre, there is a toolkit for opening the message structure containing raw data into field headers and field parameter data, characterized in that of the opened message a mother form is formatted, which is a file and which contains all field headers and field parameter data of the message in plain language, a user form is formatted, which is a file, by choosing in a desired order desired field headers and their parameter data from the mother form, call detailed records (CDR) are formatted by separating data of fields specified in the user form from the incoming message. 2. Method as defined in claim 1, characterized in that for each message a separate mother form is formatted, 3. Method as defined in claim 1, characterized in that the message number and the message type identifier and the mother form's ver¬sion number are placed in the file name of the mother form. 4. Method as defined in claim 3, characterized in that the file name of the user form is given in accordance with the file name of the mother form, so that the message number and message type identifier are transferred to it and the user form's version number is located in it 5. Method as defined in claim 3, characterized in that such a status data field is placed in a header field of the user form which states whether the user form is passive (P) or active (A), and in that call detailed records (CDR) are formatted according to fields specified in this user form only when the form is active. 6. Method as defined in claim 1, characterized in that the mother form is formatted by the supplier of the telephone exchange while the operator formats the user form. 7. Method as defined in claim 1, characterized in that the supplier of the telephone exchange formats both the mother form and the user form, 8. Method as defined in claim 5, characterized in that the user form is tested before its activation, so that test call detailed records are formatted with its aid from a test data flow, a separator mark is placed in the formatted test call detailed rec¬ords before they are sent to the billing centre the billing centre extracts the test call detailed records from the in¬coming data flow using the user form. 9. Method as defined in claim 5, characterized in that in response to activation of the passive user form, the formatting process of the telephone exchange immediately begins formatting call detailed records (CDR) by extracting data of fields specified in the user form from incoming messages. 10. Method as defined in claim 1, c h a r a c t e r i ze d in that the billing centre uses the user form for interpreting data of received call detailed records. 11. Method as defined in claim 10, characterized in that in response to activation of the passive user form, the billing centre immidiate, begins using the user form for processing received call detailed records, 12. Telecommunication system comprising several telephone exchanges, wherein call records in various type of messages containing raw data arrive in a formatting process which mats call detailed records (CDR), and which sends the call d.etailed records further, a billing centre which receives call detailed records (CDR) and performs post processing of these to format telephone hills, possibly network management for controlling the operfition of tele¬phone exchanges, characterized in that the system comprises: at least one mother form, which is a file and contains all field head¬ers and field parameter data of the message, at least one user form, which is a file and where desired field head¬ers and their parameter data are located in a desired order from the mother form, means of activating the user form in the telephone exchange so that the formatting process will format call detailed records (CDR) by sepa¬rating data of fields specified in the user form from the incoming message. 13. Telecommunication system as defined in claim 12, characterized in that the user form is also placed in the billing centre and that when the user form is active the billing centre uses this user form for extracting data of fields specified therein from call detailed records (CDR). 14. Telecommunication as defined in claim 12, characterized in that in response to the operator's request for acti¬ vation the network management performs activation of the user form of the telephone exchange. 15. Telecommunication system as defined in claim 12, characterized in that the mother form is made by the supplier of t- telephone exchange as a file delivered to the operator as a diskette recon- ing and that the user form is made by the operator based on the mother as a file delivered to the supplier of the telephone exchange and to the billing centre as a diskette recording or through the network. 16. Telecommunication system as defined in claim 11. characterized in that both the mother form and the user form are ASCII files. 17. A method of formating billing records in a telephone exchange, substantially as herein described, with reference to the accompanying drawings. 18. Telecommunication system, substantially as herein described, with reference to the accompanying drawings. Dated this 16th day of April 1998

Full Text

Extraction of desired data from data flow
Field of the invention
This invention concerns extraction of desired data from a structured data flow, especially extraction of predetermined data from a continuous flow of call detailed records produced by a telephone exchange.
Background of the invention
Billing in consequence of services is implementation of the agree¬ment between the service producer and his customer. In principle, there are two kinds of billing: decentralised and centralised billing.
In decentralised billing, the customer pays to the seller for each time of using services provided by the seller. The payment is performed ei¬ther with conventional money or with some equivalent means of payment, e.g, postage stamps are used when paying for delivery of letters. A more re¬cent example of a means of payment used in decentralised billing is elec¬tronic money where each "coin" consists of a an encrypted binary sequence, which must be verified by a bank server.
In centralised billing, the use of services is monitored by the seller or by a third party. The customer is billed periodically, e.g. once a month. The bill is based on monitoring data collected for the preceding billing period. Examples of centralised billing are electricity, telephone and credit card bill ing. Centralised billing consists of three steps. The first step is an agreement between the parties on services and on related billing. The second step is monitoring (or measurement) of the use of services and saving of data con¬cerning the use. The third step is formatting of the bill and sending the same to the customer. The bill is formed according to data saved in the billing system.
The centralised billing used in a telephone network is based on an agreement between subscribers and operator. The essential point of the agreement is that the subscriber gets access to telephone services, that is, he may make and receive calls, and as a compensation for the service pro¬vided he performs payments according to predetermined tariffs, as specified in bills sent to him by the operator. The bills typically include charging of two types: fixed charges and use charges. The fixed charges are independent of whether services are used or not. Use charges depend on how many calls

the subscriber has made and possibly also on how many calls he has re¬ceived. To be able to debit for use charges the operator must monitor made and received calls. Such monitoring is connection-based and it is performed by network switches.
Figure 1 illustrates a known centralised billing method used in a telephone network by presenting a part of a public telephone network. For each call which is made the local exchange LE (the subscriber's Local Ex¬change) performs a call detailed data collection and formats a CDR (Call Detailed Record). The record contains all the information required in billing for one call as well as any desired quantity of other information related to the call. Call detailed data collection is always used when specified detailed in¬formation on a call is required for billing or for monitoring of call details. The structure of the call detailed record is determined by a an operation control command before the call detailed data collection is introduced. The record structure must be determined as a uniform structure in all exchange ele¬ments controlled by the network management. Hereinafter the call detailed records will also be called by the name of CDR and the program formatting the call detailed records will be called the CDR generator. Formatted CDRs are sent to the BS (Billing Centre) for post processing.
Fonnatting of the call detailed record requires that the operator es¬tablish some basis for formatting of the call detailed record. Formatting may be based e.g. on call detailed data collection of all the calls of the subscriber or formatting may be based on the call type, that is, whether the call in ques¬tion is a normal call, a facility call, such as call transfer etc., a call free of charge,, an IN call (intelligent network call) etc. In fixed network applications there are about 30 different formatting bases. The formatted call detailed re¬cords are first saved in the memory and are then sent to the centralised bill¬ing system, where they are saved in mass storage, e.g. on magnetic tape or on a hard disk.
Between the exchange and the billing system there may also be an additional processing step, wherein call detailed data collection records are "pre-processed" for the billing system. Such pre-processing may be format¬ting, where e.g. a tariff class field Is converted from one format into another. Whether there is pre-processing or not, call detailed data collection will pro¬duce enormous data blocks containing even millions of records, and these

may be saved in the billing system's mass storage. The records form the raw information which the billing system begins to process.
Thus, processing of call detailed data collection records takes place at a later moment as batch processing which is separate from the generation of call detailed data collection records. It should be noted that in practice billing may be even much more complicated than the example described above. E.g. in a mobile station network, each mobile services switching centre taking part in the call may generate call detailed data collection rec¬ords. However, the billing principle is as described in the foregoing.
Processing of a CDR format in present fixed network telephone systems is described in the following referring to Figure 2. The figure shows functions of the telephone exchange which are essential from the viewpoint of the invention.
The call detailed data collection process obtains information related to the call as raw data in individual messages mainly from the call control. The call detailed data collection process saves the information in a record reserved for the call. On termination of the call or in connection with interim data collection, the data collection process sends the call record as a whole in messages of various types to the process for saving of call detailed rec¬ords. The message has a call type number indicating the nature of its con¬tents and a message sequence number, The structure of successive mes¬sages is always the same and the type will determine which fields in the message must be filled in. If the number of fields to be filled in is less than the number of fields in the message, then void fields are filled in with a filling code. The messages are thus always sent in their entirety.
The saving process goes to read the message structure in a sepa¬rate format file and starts formatting of the record from a raw data flow which it receives. The structure of the call record and of the format file is fixedly structured in the code of the process for storing the call detailed data collec¬tion. Fixed coding is done, because the place of the field in the call record is not found out from the format file. The process for saving the call detailed data collection reads the formatting file successively and from the received call record it picks up a field for locating it in the CDR, if in the formatting file the said field is defined as one to be taken along. The manner in which the individual field is coded in the CDR is also fixedly established in the code of the process for saving the call detailed data collection.

If it is desired in some application to have a different processing for some field in a message, e.g. a time field format, then this must be done through control of the application switch.
When the process for saving the call detailed data collection has completed the CDR, it locates it in the RAM block. Normally, one block can accommodate 5-10 CDRs. When the block is completed, it Is saved on the hard disk of the concerned telephone exchange or it is sent outside the ex¬change to some I/O equipment, e.g. to the hard disk of the operation control centre. It is also possible to send received blocks directly to the post proc¬essing process.
It Is possible for the operator to output e.g. CDRs formatted of some subscriber's calls from a block saved on the hard disk of the operation control centre. This is done with a Man Machine Language (MML) command. The command starts a read program, wherein the structure of the format file of call detailed data collection and the names of fields corresponding to its sub-files are fixedly coded. Reading is performed from the ring buffer of the hard disk.
Formats saved in the formatting file will also be briefly described. The operator brings about the format he desires with an MML command. The command will first output for the operator in plain language in the monitor display all fields .1. sub-files available in the message. Thereupon the opera¬tor selects those fields which he wishes to locate in the format to be made. From the available fields the operator may take a field or remove a field, but he can not change the order of fields. When the user has made his choice, the format is completed and it may be output to the display or printed out on paper. The output will indicate in plain language which fields are present in the format.
The format may be e.g. in the form
CALL SUBSCRIBER NUMBER 10
whereby the name of the field is call subscriber number and the numerical value 10 expresses the place of the field combination in the CDR.
The MML function reads the fields (sub-files) available in the format file of the call detailed data collection process and uses the same both in the MML command, with which the user creates the format he desires, and in the MML command, with which the format chosen by the user is output onto the display or on paper. It is shown by the format file which fields can be chosen

and whether the chosen field is present in the call detailed record CDR. The format file contains as many sub-files as the maximum number of fields in the call detailed record CDR,
The structure of the format file's sub-file is of the type:
FIELD_IN_RECORD POSITION
TRUE 0
As can be seen from the shown type, it does not indicate the field name in plain language. For this reason, the names of fields in plain lan¬guage as well as their correspondence in the format file are fixedly coded in the MML function. Coding is e.g. as follows:
IF CRPARA.SUB_REC(1).FIELDJN_REC0RD=TRUE THENDO:
CALL MOVBC'CALL TIME",MML_F0RMAT.RECORD_HEADER...
This means that if a field located in position 0 from a fomiat file by the name of CRPARA, which field is here called FIELD_IN_RECORD, is true, that is, the user chose it when making the format, then it is given the name CALL TIME in plain language.
There are some drawbacks in the state-of-the-art formatting of call detailed records described in the foregoing.
Firstly, when call detailed records are sent from a telephone ex¬change to a billing centre performing post processing, the data flow to be sent is a big one, Above ail, it contains plenty of void or unmarked fields. When the raw data flow contains data in binary form, in hexadecimal form and in ASCII form, then the formatted CDRs will also contain data which is in different forms. Data in different forms will add to the quantity of data to be transmitted from the exchange.
Secondly, if the billing centre wants CDRs of other kinds, that is, to add new fields or to remove fields presently in use, it is not only difficult but also risky to make any changes, since it must unconditionally be ensured that any changes made in the formatting file are made correctly and that the receiving end of the post processing site, that is, the billing centre, is able correctly to interpret the changed CDR data flow. In addition, some data is also usually lost when the format is changed.
Thirdly, since in the state-of-the-art arrangement the incoming data flow in all functions related to the format or field names and their correspon¬dence in the format file are fixedly coded in the program blocks, necessary changes must always be made in the call detailed data collection saving

process, in the data collection process, in the MML program and in programs related to output of CDRs when an entirely new data element is desired in the format. Besides changes in programs, the formatting file structure must also be changed and a change must be made in the conversion program of this file. The second and third items are so troublesome that the exchange supplier must know which format the buyer desires even a year before the exchange is delivered to the buyer. Thus, it is both difficult and expensive to change the format once it is made.
The present invention alms at a method not suffering from the mentioned drawbacks in use. The objective is thus a method where chang¬ing of the format is more dynamic and more reliable than in any known method. It ought to be possible to change the format "on the move" and post processing must be prepared at once to process any changed CDRs. It should be possible to create different CDRs for various purposes and thus also to bring about CDRs which are shorter than present CDRs.
The established objectives are achieved with the method and sys¬tem described in the independent claims.
Brief summary of the invention
The invention is based on the idea to use a special form for ex¬tracting desired data from a raw data flow. The number of forms may be high, however, so that there may be only one active form for each type of message. Each form defines exactly that infonnation, which should be ex¬tracted from the raw data flow in order to format a CDR. When a form is acti¬vated, the formatting process will extract the data determined by the form from the data flow.
To this end, the exchange supplier formats a special mother form showing in plain language (in ASCII form) all the names and parameters of fields arriving as a raw data flow. Thus, the mother form is a file containing the message structure. Each different message has its own mother form. The mother forms are delivered to the user e.g. on a diskette. The user has a program using a graphic user interface which shows the desired mother form in the display. Beside this a user form blank can be seen and the user chooses the fields he desires simply by using the mouse to drag the field of his choice from the mother form to the user form where he drops the field he has chosen (drag and drop). In this manner the user makes his own form,

which contains only the data he wants to include in the CDR. If the user so desires, he may also determine the form in which he likes the data to be. It is possible that the user wishes all data to be in binary form. The user delivers his form e.g. on a diskette to the exchange and to the billing centre.
On arrival of the user form at the telephone exchange, it can be ac¬tivated at any time. When the form is active, the formatting process will use this fomfi in the manner of a filter and extracts from the raw data flow the data corresponding to the fields indicated on the form, thus formatting the CDR. When the CDR is completed, the exchange will send it to the billing centre, which using the same form made by the user will interpret the data contained in the received CDR, that is, it creates fields and attaches the data belonging to the fields from the CDR. The names of fields are thus not transferred from the exchange to the billing centre.
Before activation of the user form, It is possible to test the form. Hereby in the exchange the formatting process makes the CDRs defined In the form and sends them to the billing centre. This for its part will find that the CDRs are test CDRs and will handle them accordingly. Only after testing has shown that the user form works correctly both in the exchange and in the billing centre, it may be put into active use.
Brief description of the drawings
The invention will be described more closely in the following with the aid of the attached diagrammatic drawings, in which
Figure 1 shows the billing principle. Figure 2 shows formatting of CDRs,
Figure 3 shows network elements taking part in implementation of the inven¬tion Figure 4 shows a mother form, Figure 5 shows a user form. Figure 6 illustrates formatting of a user form, and Figure 7 shows use of the form in fomnatting of CDRs.
Detailed description of the invention
Figure 3 shows a telecommunication network which may be a PSTN or an ISDN network and which comprises several telephone ex-

changes 1,2,..,N, each one of which formats a subscriber record CDR relat¬ing to a call made by a subscriber through an exchange. The Network Man¬agement System NMS indicated by reference number 4 attends to network management by controlling various exchanges. The billing centre BC indi¬cated by reference number 5 receives call detailed records CDR arriving from different exchanges, it processes them and forms bills to be sent to subscribers. If there is no separate network management, then control and configuration of the exchange may be performed in the exchange proper in¬stead of using remote operation. Reference number 6 indicates a general purpose computer, which contains a program with which the operator/user uses a mother form for making a user form according to the invention. The supplier of the telephone exchange for his part makes the mother form in a manner explained hereinafter.
The exchange supplier naturally has exact information about the contents of the raw data flow arriving in the message. The message struc¬ture is always the same, that is, the fields of the message and their parame¬ters (location, length, type etc.) are constant. The message type determines which fields will be filled in when forming the message. The message is al¬ways sent in its entirety, so any fields left void must be filled with filling code. Thus, the type of message may change, although the message number re¬mains the same. The message number and the type of data block arrive in the data flow. Table 1 below illustrates the contents of a message.

signal charging_msg_s = (
seq_number
order_numbcr call_recordJnd byte; dword; record_number_t;
in_cgr_name out_cgr_name call_record service record cgr_name_t; cgr_name_t; caIl_record_t; svcfil_t;
Table 1
The message is a "signal charging message" and its number is 0x4543. The data flow of the message is successive fields of different

lengths, e.g. the first field in position 0 is seq_number and its length is one byte, the next field in position 2 is order_number and its length is n word. In reality, there are no field names in the message, but the message consists of field bits, which are after one another without break and without any separa¬tor marks. However, the location of each field is determined unambiguously when field positions and lengths are known. Thus, e.g. the beginning of the third field's call_record_ind (position 3) is found out. by jumping from the be¬ginning of the message by the number of bits of the two preceding fields of messages, that is, forward by one word and one byte. From this point for¬ward there are as many bits of the third field in the flow as is indicated by the length of the field.
Since the exchange supplier always has a tool, that is, a program, with which the message structure can be opened as position and field data, It is simple to use this program and a suitable windows© program for making the mother form. The Windows program is used for making a form having a form header and CDR headers of the desired form. The headers are in plain language. Placed under the headers are field names and field data such as the toolkit has opened them from the message. All fields are contained in the mother form. However, the order of fields need not be the same as in the message data flow. The toolkit functions as a link between message fields and the contents of fields in the data flow.
Figure 4 shows the form of a mother form. The file name seen in the top part of the form contains mother form data: the first digits of the se¬ries of numbers, here 4543, give the message number to which the form is related, the next three digits 000 indicate the type of message. The letter M indicates that the form is a mother fomn. The three digits after full stop indi¬cate the version in succession of the mother form: if the message is changed, the mother form will of course also be changed, whereby it will have a new version number, This data contained in the file name is not part of the fomn proper, but it is brought into the display by the windows© pro¬gram.
The form header on the following line contains the fields Format Number, which indicates the message number and type, Output Mode, which here is BIN and Indicates the mode of the CDR produced with the form, and Output device, which indicates where the CDRs to be fomiatted are saved. The place of storage may be e.g. VDS, that is, Virtual Disk Sys-

tern or VIDAST, where some hundred CDRs are collected on the disk and are then sent as a cluster to the billing centre. Output device may also de¬termine that the CDR be sent immediately after fonnatting to the Hot Billing System.
Then comes data relating to the header line of the CDR to be for¬matted on the mother form. The data relates to CDR headers and is grouped under the Header field name, Type and Length of the headers. Thus all header fields and their data existing in the message and uncovered with the toolkit will come under Header field name. In the examples, the record length, hea_recordJength, is first as record type W (Word) and length 2 words.
After these comes data relating to data fields of CDRs of the mes¬sage proper. This is grouped under headers Data field Name, Type, Length, Position and Format. All data fields and their data existing in the message and uncovered with the toolkit come under the headers. The form shows e.g. subscriber A's field, the data type, length, position (26"' byte in the message) and format (BCD coded). In the Format column of the form the character of the field is indicated: BCD means Binary Coded Decimal, DM is datum. The numbers located after these are instructions for the formatting program. E.g. number 1 might mean convert the binary coded data into BCD format.
The mother form according to Figure 4 is thus formed for each message. The header and data fields and their parameters can be seen in each form in a form which is easy to read and in plain language. The work station is able to make the linkage from a field on the mother form to the right spot in the raw data flow.
After the mother form has been formatted by the supplier of the telephone exchange, e.g. in the telephone exchange shown in Figure 3, a copy of it will be transferred from the computer to a diskette. The mother form on the diskette Is of a read-only type, so it can not be edited in any way. This means that when the exchange supplier has made the mother form and delivered it to the operator, the latter can not change the mother fomn. Of course, the supplier may make changes.
Thereafter the diskette is taken to the operator's billing centre or to the network management unit, and it is pushed into a general purpose com¬puter, e.g. into computer 6 in Figure 3. This computer has a windows based

program, which creates a user form and the operation of which will be de¬scribed in the following.
1
The user form shown in Figure 5 has a lay-out which is quite similar to that of the mother fonn. Thus the file name of its top part contains the same data as In the mother form: the first digits 4543 of the series of num¬bers give the message number, to which the mother form and thus also the user form are related, the following three digits 003 indicate the message type. The letter P states that the form is a passive form. The significance of this will be explained later. The full stop is followed by three digits stating the version of the user form: the user may at any time create a new form, whereby it will have a new version number.
The form header on the following line contains the fields Format Number, Output Mode and Output device, which states that the CDR to be formatted with the form will be saved on a diskette.
These are followed by data relating to the first header line of the CDR to be formatted, Header field name, Type and Length. The proper fields contained in the CDR come under Data field Name, Type, Length , Position and Format.
The said form headers and header lines come automatically ac¬cording to the mother form into the user's computer display when he has started the program and has pushed the diskette into the read station. The field names are exactly the same as in the mother form and they can neither be changed nor must they be changed.
Figure 6 shows a view seen by the user after starting the program and after he has pushed the diskette into the work station. The view is a typi¬cal windows view with its basic keys. On the right hand the diskette has pro¬vided a mother form according to Figure 4, which contains ail possible mes¬sage fields. On the left hand is a user form blank according to Figure 5. The user picks up the fields he desires from the mother form simply by choosing them with the mouse and by dragging them into the user form and dropping them under the respective field header. Thus, in the case shown in the fig¬ure, the user has chosen from the header fields of the mother form the first four fields, but from the data fields only Subscriber A's field and those fields which give the start time of the call and the end time of the call respectively.
It is possible for the user in some cases also to change parameters of the fields. Thus e.g. the length of the Subscriber A field, which is 16 char-

acters in the figure, may be shortened to 8 characters by replacing the num¬ber 16 with the number 8.
When the user has made the form he desires, it is saved and transferred in one way or the other to computer 5 in the billing centre and to exchange 1, Figure 3. Field "customer form" in the top part of the form con¬tains status code P, which means a passive form.
Saving may be done on a diskette, which is taken to the OMU unit (Operation & Maintenance Unit) of the telephone exchange and to the billing centre.
Saving may also be done in such a way that the user form is transferred as a file transfer or the diskette is taken to network management 4, Figure 3. When he desires, the user of this will press e.g. the send key on the computer 6, whereby, network management will transfer the user form to the telephone exchange and to the billing centre.
Testing of the user form can now be performed. When the form has been transferred to the telephone exchange and to the billing centre, testing is performed without Interfering with any formatting and sending of CDRs which are going on at the time. Testing is carried out in such a way that net¬work management gives the name of the passive form to be tested and the exchange is notified that this form is being tested. The MML function then feeds such a test data flow to the telephone exchange which has the struc¬ture of a proper message. The test data may be a binary file corresponding to binary data of the correct message and which may be edited. From the incoming test data flow the formatting process picks up the data corre¬sponding to fields specified in the form and formats CDRs according to the form. The fomiatted test CDRs are sent among CDRs proper to the billing centre.
The test CDRs are data queues of a certain length which are sent to the billing centre as they are produced. Since it has at its disposal exactly the same user form as the one with which desired data was extracted from the test data flow during the formatting process in the exchange, it is able by using the same form as interpreter easily to format field names and to ap¬pend to these exactly correct data from the data flow. As a result, the billing centre obtains In the display the field names given in the form and the correct records under the names.

For the billing centre to be able to distinguish test CDRs from proper CDRs, the arrangement may be such that the test form produces some separator in the CDR, whereby the billing centre will not take the test CDR to post processing proper. It is of course possible to take test CDRs to post processing proper and to format telephone bills of them. This is advan¬tageous so that the correct function of the test form can be ensured until the end. The separator marks in the test CDRs guarantee that formatted tele¬phone bills will not be sent any further.
When testing has shown that ail is working without fault, the form which is in a passive state (mark P) may be activated by changing the mark into A (Active). Activation is done e.g. by network management by using the windows program to bring up the passive form and by pressing the "activate form" key, Figure 6. The change from passive into active is done in the tele¬phone exchange. Thereupon the call detailed data collection saving process, Figure 2, immediately puts the now active user form into use and begins for¬matting CDRs, wherein there are records indicated in fields of the form. The formatted CDRs are sent by the telephone exchange to the billing centre, which using the same form can extract the connect records from the data flow.
Some checks may be made in the telephone exchange as regards the formatted CDRs. Firstly, an Initial check can be made by ensuring that the call end time minus the call start time picked up from records is equal to the length of the call. Secondly, a CRC check or some other known transfer protection may be added to the data to be sent on the transfer path from the telephone exchange to the billing centre. Thirdly, a separator mark of suffi¬cient length may be added to forms so that formatted CDRs can be clearly distinguished from each other.
Figure 7 shows the use of user forms in a telephone exchange. The user forms in a passive state are saved in the OMU. In function 71 the user makes the form or forms he desires, which are then taken on a diskette to the telephone exchange or to the network management common to all ex¬changes and to the billing centre. The user requests that an MML command be given for performance of the test.
When the operator wishes to introduce a certain form to get the CDRs he desires, he presses the Activate Form key in the program, which gives the MML function a request for activation of the form. The command

picks up the desired form from the directory and makes it active, function 72. At the same time, the billing centre has introduced the same form. The for¬matting process 73 produces desired CDRs, which are sent to the billing centre.
The use of forms according to the invention allows very flexible ed¬iting of CDRs. When e.g. it is desired to add a field to the CDR, say, an en¬cryption code, an old form is taken as a basis and the encryption code Is added to it. The Windows program generates a new version of the form, which will have a new format number. The new form is sent to the telephone exchange and to post processing. During this time, the CDRs are still filled with the old form. After the test CDR has been sent and the functioning of post processing has been ensured in the billing centre, the new form is acti¬vated at the same time as the old form is made passive. The exchange will immediately produce CDRs, wherein the encryption code is present and which carry the new format number. The format is thus exchanged on the move.
The use of forms is also very convenient when raising the ex¬change standard, which means changing of the exchange software. Hereby generated and frozen mother forms con-esponding to the new standard and having as their file name e.g. 4543000M.100 are taken to a new directory of the computer. The version number has been changed here into a new hun¬dred number and the first number is 100. The now active user forms are then copied into the same directory and a conversion program is run, which will convert old user forms to correspond with the new message, where fields have new positions. Field names are used as search keys. The version is changed in the conversion, e.g. 4534003A.008 -> 4543003P.101 and like¬wise the format number changes e.g. 003008 -> 003101. New passive forms are then sent to the telephone exchange on the so-called trial side, where testing of the new software is performed without interfering with the old run¬ning software, and to post processing. Next, new test CDRs are sent from the trial side, if possible, and the functioning of post processing is ensured. Upon completion of testing; the new fomns are activated from the trial side and switch-over is done, whereupon the new forms are in use.
If there is no separate network management and billing centre in the network, the user form is made with the aid of a separate general pur¬pose computer, which is indicated by reference number 7 in Figure 3.

The mechanism of the invention has the advantages that change of format can be done dynamically on the move and post processing is imme¬diately synchronised into the change. Several different CDRs can be made for different requirements, whereby it is possible to format short CDRs. A cor¬rect functioning is ensured by sending test CDRs. The form contains all the data relating to formatting, transferring and interpretation of CDRs. CDR for¬mats are managed in a centralised manner and the same graphic user in¬terface is used both by the exchange supplier and by the operator.

a1. A method of formatting billing records in a telephone exchange,
wherein
call records come in messages of different types containing raw data to the formatting process, which formats call detailed records (CDR) to be sent to a billing centre,
there is a toolkit for opening the message structure containing raw data into field headers and field parameter data,
characterized in that
of the opened message a mother form is formatted, which is a file and which contains all field headers and field parameter data of the message in plain language,
a user form is formatted, which is a file, by choosing in a desired order desired field headers and their parameter data from the mother form,
call detailed records (CDR) are formatted by separating data of fields specified in the user form from the incoming message.
2. Method as defined in claim 1, characterized in that for each message a separate mother form is formatted,
3. Method as defined in claim 1, characterized in that the message number and the message type identifier and the mother form's ver¬sion number are placed in the file name of the mother form.
4. Method as defined in claim 3, characterized in that the file name of the user form is given in accordance with the file name of the mother form, so that the message number and message type identifier are transferred to it and the user form's version number is located in it
5. Method as defined in claim 3, characterized in that such a status data field is placed in a header field of the user form which states whether the user form is passive (P) or active (A), and in that call detailed records (CDR) are formatted according to fields specified in this user form only when the form is active.

6. Method as defined in claim 1, characterized in that the mother form is formatted by the supplier of the telephone exchange while the operator formats the user form.
7. Method as defined in claim 1, characterized in that the supplier of the telephone exchange formats both the mother form and the user form,

8. Method as defined in claim 5, characterized in that
the user form is tested before its activation, so that test call detailed records are formatted with its aid from a test data flow,
a separator mark is placed in the formatted test call detailed rec¬ords before they are sent to the billing centre
the billing centre extracts the test call detailed records from the in¬coming data flow using the user form.
9. Method as defined in claim 5, characterized in that in
response to activation of the passive user form, the formatting process of the
telephone exchange immediately begins formatting call detailed records
(CDR) by extracting data of fields specified in the user form from incoming
messages.
10. Method as defined in claim 1, c h a r a c t e r i ze d in that the billing centre uses the user form for interpreting data of received call detailed records.
11. Method as defined in claim 10, characterized in that in response to activation of the passive user form, the billing centre immidiate, begins using the user form for processing received call detailed records,
12. Telecommunication system comprising
several telephone exchanges, wherein call records in various type of messages containing raw data arrive in a formatting process which mats call detailed records (CDR), and which sends the call d.etailed records further,
a billing centre which receives call detailed records (CDR) and performs post processing of these to format telephone hills,
possibly network management for controlling the operfition of tele¬phone exchanges,
characterized in that the system comprises:
at least one mother form, which is a file and contains all field head¬ers and field parameter data of the message,
at least one user form, which is a file and where desired field head¬ers and their parameter data are located in a desired order from the mother
form,
means of activating the user form in the telephone exchange so that the formatting process will format call detailed records (CDR) by sepa¬rating data of fields specified in the user form from the incoming message.

13. Telecommunication system as defined in claim 12,
characterized in that the user form is also placed in the billing centre
and that when the user form is active the billing centre uses this user form for
extracting data of fields specified therein from call detailed records (CDR).
14. Telecommunication as defined in claim 12,
characterized in that in response to the operator's request for acti¬
vation the network management performs activation of the user form of the
telephone exchange.
15. Telecommunication system as defined in claim 12,
characterized in that the mother form is made by the supplier of t-
telephone exchange as a file delivered to the operator as a diskette recon-
ing and that the user form is made by the operator based on the mother
as a file delivered to the supplier of the telephone exchange and to the billing centre as a diskette recording or through the network.
16. Telecommunication system as defined in claim 11.
characterized in that both the mother form and the user form are
ASCII files.
17. A method of formating billing records in a
telephone exchange, substantially as herein described, with
reference to the accompanying drawings.
18. Telecommunication system, substantially as herein
described, with reference to the accompanying drawings.
Dated this 16th day of April 1998

Documents:

808-mas-1998-abstract.pdf

808-mas-1998-claims filed.pdf

808-mas-1998-claims granted.pdf

808-mas-1998-correspondnece-others.pdf

808-mas-1998-correspondnece-po.pdf

808-mas-1998-description(complete)filed.pdf

808-mas-1998-description(complete)granted.pdf

808-mas-1998-drawings.pdf

808-mas-1998-form 1.pdf

808-mas-1998-form 26.pdf

808-mas-1998-form 3.pdf

808-mas-1998-form 5.pdf

808-mas-1998-other documents.pdf

abs-808-mas-1998.jpg

« Previous Patent

Next Patent »

Patent Number

213973

Indian Patent Application Number

808/MAS/1998

PG Journal Number

13/2008

Publication Date

31-Mar-2008

Grant Date

23-Jan-2008

Date of Filing

16-Apr-1998

Name of Patentee

NOKIA TELECOMMUNICATIONS OY

Applicant Address

KEILALAHDENTIE 4, FIN-02150 ESPOO,

Inventors:

#	Inventor's Name	Inventor's Address
1	JUKKA JARVI	KOTIRINTEENTIE 8, FIN-41120 PUUPPOLA,
2	KIMMO POIKOLAINEN	SIIANTIE 3, FIN-44120, AANEKOSKI,

PCT International Classification Number

H04M 15/00

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	971621	1997-04-16	Finland