April 30th, 1999
Teemu Mäkelä
Department of Computer Science and Engineering
Helsinki University of technology
Teemu.Makela@hut.fi
In the past, it was enough for an accounting system to handle voice calls from single vendor's network equipment, but today they are required to manage a diversity of new services and platforms. To manage this competitively the systems should be easily extendable and automated. This paper describes the model of accounting process used today in telecommunications, and discusses some related issues like the interconnect billing. In the end, we look how this model could be adapted in the Internet.
6 Applying Accounting Model to Internet
Further Information
1 Introduction
The accounting system is one of the most complicated systems maintained by the telecommunications operators, yet it has not been in the spotlight of the research community. Reasons for this are easy to find; the systems have been closed, developed in-house, and so pivotal to the business, that the operators rather keep the details private. Furthermore, large parts of the accounting process have been manually operated, and still are in some places, so the needs have been very basic to start with.
The complexity of the accounting system varies greatly with different operators. Some small operators use very light setups with manual retrieval of information from single-vendor network equipment. Larger, older operators have complex in-house legacy systems, which have evolved to deal with many different environments from fixed lines to value-added mobile services and the Internet.
As the telecommunication services are becoming more complex all the time, the need for flexible, standard based accounting systems is growing. The new operators want off-the-shelf systems, customizable and scalable to their particular needs. The old operators want to improve the efficiency of their accounting process by using standard interfaces. The bottom line of this development is to gear efforts towards full automation.
Despite the variance, all the different accounting systems can be seen to have common elements and common structure: The data must be collected and processed into chargeable items, which are then collected to each subscribers account from where the invoice will be rendered. This paper presents the accounting in telecommunications networks as seen through this process.
First, Chapter 2 discusses the general principles of charging in telecommunications network. Chapter 3 presents the structure of the accounting process, and how it is implemented in PSTNs. Chapters 4 and 5 describe how interconnect billing is arranged for normal traffic, and how it could be arranged for signalling traffic. Finally, the paper is concluded with extending the study into the Internet in Chapter 6 and a short conclusion in Chapter 7.
The main requirement for charging is that it should be as simple as possible [19]. Simplicity is largely dictated by social aspects. Subscribers are more ready to pay money for the service if they understand the charging principles, and are hereby able to verify the correctness of their bills. The operator's tariff structure describes how the services are being charged for, and is therefore an essential element in charging system. Tariffs are the topic of the next section.
The charging system should also be technically simple, flexible and convertible to fulfil future demands. It should operate with sufficient accuracy and reliability, as these are essential for maintaining the customer base. All kinds of fraud and misuse should be extremely difficult to come by. Simplicity helps to achieve these technical demands. The technical aspects of charging are the topic of Chapter 3.
The charging system and tariff structure must also meet all possible local and international demands, and legislation imposed on the system. Most notables of these demands are the regulations, which for example specify what is sufficient accuracy. This topic is covered in Section 2.2.
The primary purpose of any telecommunication tariff structure, from the operator’s point of view, is to price services at least to cover the overall cost of providing those services. Tariffs have also a secondary purpose: they are used to regulate the demand placed on the available network capacity, with the aim of encouraging the use of resources to the maximum extent throughout the day and night. [13]
When defining the tariffs, operators must take into account the subscriber’s ideas on what constitutes to be a fair charging, as well as the company’s right to cover its costs and receive a reasonable profit. With the open markets of today, operators must strive to offer their services at a competitive price, but still the profit must be sufficient for ensuring subsequent development. Otherwise, the customers will move to the operator able to offer better service, which would lead to even smaller profits.
Today’s Open Network Provisioning (ONP) tariff principles state that tariffs should be unbundled, cost oriented, non-discriminating and published. These principles help especially other service providers in leasing network capacity. Towards these goals, the tariffs should comprise following pricing elements: [5]
Of these three, only the charging of usage needs support for accounting from the network, while the others can be achieved by simple arrangements in customer care and billing (CCB) systems.
Regulation aims to promote telecommunication services, and to safeguard their continuous development. The emphasis depends on local conditions: Underdeveloped countries want to encourage building of infrastructure, or the competitiveness of local telecommunications industry may be on the first place.
Aspects of accounting in telecommunication networks have been traditionally regulated by different governmental bodies. In Finland, this responsibility is handled by the Telecommunications Administration Centre (TAC Finland). TAC Finland is an agency under the Ministry of Transport and Communications with responsibility for radio, telecommunications and postal administration and television license management. [21]
TAC Finland has given a regulation on the charging principles concerning public telecommunication networks. The regulation defines two areas of demands: Correctness and implementation of charging.
Charging correctness requires, that errors due to the telecommunications companies' own activity shall not occur in more than 0.01% of all charged calls. The information collected should therefore be sufficient and stored in secured systems. This means in practice backups of data in various parts of the process, and redundant systems. Furthermore, audit logs should be collected from the process.
Requirements for the implementation of charging define general rules by which the charging must be arranged. It requires that the charge for a call can be determined prior to service transaction, hence the charging must be based on the service requested by the customer. If the user is unable to choose call routing, the price must not depend on it. For a circuit switched connection, the charging starts when the connection is established and an answer signal is received, and ends when the connection is released.
ITU-T Recommendation X.742 proposes that the whole process of ‘getting money’ from resource utilization will be called accounting. Accounting has three sub-processes [18]:
These sub-processes lead to a three tiered architecture for accounting. In the lowest layer we have the equipment generating UMRs, and on the top we sort service transaction records to service subscribers and generate an invoice. The middle tier is now left with the collection of the raw UMRs and processing them into valid service transaction records.
Figure 3.1: Information Flow in Accounting Process
This process is reflected also by the TMN model, which will be considered next. The accounting process in telephone networks today is increasingly based TMN, so having some basic knowledge of it is essential. After this, we go in more detail to the three tiers of the accounting process.
Telecommunications Management Network (TMN) is specified by ITU-T in Recommendation M.3010 [14]. The basic concept behind TMN is to provide an organized architecture to achieve the interconnection between various types of Operations Systems (OSs) and telecommunications equipment in order to exchange management information. A TMN is conceptually a separate network that interfaces with a telecommunications network at several points (see Figure 3.2).
Figure 3.2: Telecommunications Management Network
TMN architecture consists of three layers, which can be considered separately: The functional, information and physical architectures.
TMN functional architecture is based on number of TMN function blocks. Operations System Function (OSF) block processes information related to the management for the purpose of monitoring and controlling telecommunication functions. Network Element Function (NEF) block enables a TMN to control and monitor equipment in the network. Q Adaptor Function (QAF) block is used to connect non-TMN entities, which are NEF- and OSF-like, to a TMN. Mediation Function (MF) block acts on the information passing between an OSF, and NEF or QAF. It may store, adapt, filter, threshold and condense information.
TMN defines interface and reference points between these blocks. In the scope of this paper, the most important interfaces are QX between a MF and NEF, QAF and other MFs, Q3 between OSF and MF, and X between OSFs of two TMNs.
TMN information architecture uses object-oriented approach and makes use of the OSI systems management principles. Information is modeled in terms of managed objects, which are identified together as the Management Information Base (MIB). Management process can be divided into two distributable roles: The manager which issues operations and receives notifications, and the agent which manages associated objects.
TMN functions can be implemented in a variety of physical configurations. TMN physical architecture is divided into TMN building blocks. For each building block there is a function block which is characteristic of it and mandatory for the building block. The defined building blocks in the scope of the paper are Operations System (OS), Q Adaptor (QA), Network Element (NE) and Mediation Device (MD).
Figure 3.3: TMN Physical Architecture
Usage metering tracks all resource utilization in NEs, so that operators have sufficient information for facilitating accounting. Some general requirements for UMRs are: [18]
Usage metering process must be controllable. Since this process is an essential element in generating revenue, usage metering should be reliable, so that no events are lost. This means that most of the systems participating in usage metering process, and also in the whole accounting process, should be replicated, and should have enough capacity to handle also peaks in the service usage.
The charging is not the only place where usage information is utilized. Other main uses are in fault detection and collection of statistical data. Thus it is not enough to store data only for chargeable calls. Usage metering records may also be emitted for events not leading into a chargeable transaction. An example of such events is the denial of service due to scant resources. This kind of information is very critical for network planning.
There are generally two ways of achieving usage metering. In the past, periodic pulse metering (PPM) was the preferred way, but nowadays most of the new systems are using call detail records (CDR, or toll tickets, TT). In PPM, the charge is determined by charging pulses given to the counter of the A subscriber during the call. First pulse may be given as soon as the destination telephone is answered, and after that with predetermined time intervals. This interval is varied with the tariff – long distance calls have shorter interval, and when the night tariffs start, the interval is raised to promote equal resource utilization [13]. PPM's largest negative side is its poor extensibility for new services and charging models. PPM is still in use in fixed telephone networks, excluding Intelligent Network (IN) related services.
When a call is charged with CDRs, information of interest for charging is collected during the call, to be later formatted into a CDR. Usually these records are plain ASCII with fixed field lengths, but the format may vary with different vendors from EBCDIC to binary data. The fields contain at least the following basic data: A and B subscriber information, time and date of a service transaction, quantitative information of the transaction, for example duration of a call or volume of transferred data, status codes and used facilities.
The time to start collecting information is controlled by the operator and in case of calls it may be at the registering of connection, call through connection or B-answer. If the operator wants more statistical data of service usage, it may be preferred to start collection in as early stages as possible, even before it is known that the transaction is chargeable. The record is completed and output at disconnection. However, a CDR may also be output at different times during the connection. Some possible events, which may trigger the output, are the changes of charging conditions like handovers, or regular intervals during a call. A one long call may therefore generate more than one record. Also, each network element through which the call is routed generates a CDR. These must then be aggregated at the later stages of the accounting process. Since the calls are not tagged with globally unique identifiers, the accounting process correlates records from the same service transaction based on the subscriber identities and heuristics on timestamps.
Since the usage metering systems have to be capable of handling the peaks in the service usage, the CDR processing must be efficient. In some IN equipment like service nodes this requirement is even larger, since the same hardware must also perform the service logic during the peaks. These requirements go against continuous streams of CDRs to the later stages of the process. The CDRs are usually stored locally in the network equipment on magnetic disks in batches. The batches are then transferred with some predetermined intervals, threshold limits or at off peak times to the mediation devices.
Mediation systems sit between telecommunication networks and operational support systems. Mediation systems provide a seamless flow of call information between network equipment and multiple downstream applications. These applications comprise rating systems, customer care and billing systems, as well as fraud management systems and data warehouse-based applications for use in marketing and planning. The information flows through mediation platforms in two directions: UMRs are gathered from network elements and offered to billing systems, and the service provisioning requests are transferred from CCBs to switches. In this paper, we are concentrating only on the former task.
Why do we need complex mediation solutions? In the past, mediation has been managed by the manual transfer of magnetic tapes between the switches and the CCBs. Automation of this procedure has been a straightforward task for an operator with single-vendor range of switches and a legacy billing system. However, the current networking environment is increasingly multi-vendor based where vendors typically provide their own transfer formats and protocols. Furthermore, the number of different downstream operations systems is increasing. It would be infeasible to build the translation capabilities into every operational support system that the operator has. The operations systems contain also many ad-hoc, not interoperable legacy systems having their own requirements for the incoming data. For instance, they may only be capable of handling date formats with two digits for year [1]. The mediation devices (MDs) shield these applications from the constant changes in the network and provide an easy-to-manage, single point of interface to the network.
MDs exist in three levels: As components of CCBs, as standalone products, and linked to the switching equipment. Some packaged billing systems include mediation as an integral part of the system, although it is the exception rather than the rule for a package to include fully functional mediation capability. Mediation functionality contained in switches is also limited in functionality, offering usually only extraction of UMRs from the same vendors network equipment. As the volumes of call data to be handled are growing, mediation is becoming a component of the accounting process in its own right, rather than a by-product of billing.
Mediation is a process whereby raw call usage data is collected and transformed into usage information for billing. It must be able to collect large amounts of data in a timely, secure and reliable manner from a variety of network elements.
There are two basic functions provided by mediation systems: Usage metering record collection followed by conversion to a format suitable for processing in the end systems. The extent of transformations offered by various vendors differ, and some vendors even provide a basic rating functionality as part of their products. The usual functionality of mediation systems is presented in Figure 3.4.
Figure 3.4: Functions of Mediation
UMR collection is a common name for extraction of records over sets of interfaces between mediation and network elements. It controls the information exchange with multiple network elements. UMRs are usually held in a buffer on the switch itself and assembled into files containing a large number of records. Typically, this means a file transfer operation using FTAM or FTP, but it can also be a complex procedure with proprietary protocols for information transfer. UMR collection may also work in an active mode to enable real-time flow of UMRs.
Validation immediately after collection identifies errors early in the process and reduces costs due to invalid records. The process consists of performing various field checks on the UMRs. Invalid records are held for subsequent inspection and possible correction. Correction is sometimes implemented in a separate system, and may require human interfering.
Data transformation inflicts three steps on the input data. Firstly, data translation involves converting an input data item to a corresponding output data item. Common manipulations in this stage are look-up table conversions, and translations between data encoding formats like binary coded decimal to ASCII or EBCDIC. Data augmentation entails adding information to that registered by the switches where the switches don’t specifically collect information. Some examples are arithmetic operations like calculating call duration from start and end times, and adding provider identities. Data aggregation combines UMRs relating to a service transaction so that a single record is presented to the end systems. For example, if a long call generates multiple records, then these are combined.
Although mediation systems produce validated billing records in a standard format, there is still need for billing systems to handle this data. At the switch end of the mediation, there is only a concept of an event to be reported. In the other end there is no concept customers and the data is completely service transaction oriented. Data distribution delivers the service transaction records to client systems for further processing. Many clients may want the same records, but some clients may also want their records processed differently.
Mediation systems have their own databases for three purposes: For buffering raw, unprocessed UMRs, for storing processed records, and for logging audit reports. Audit reports cover the mediation activities carried out in a collection cycle. Mediation systems also provide a management interface for monitoring the mediation process, and controlling various parameters related to the process.
Billing systems, more commonly called customer care and billing (CCB) systems, are the end point for service transaction records. They receive preprocessed and possibly pre-rated records in standard formats, and turn them into invoices for service subscribers.
CCB systems have become a high growth market. Causes for this are not hard to find: Many operators have never been faced with a competition on the scale that is currently occurring, and their legacy systems were designed only for fixed voice telephone services. Today’s systems must address many new services and subscriber demands.
A good CCB system is thought of as being a leading edge in the competitive market. It is an essential factor in reducing the loss of installed base of subscribers, as the telecommunications world has become increasingly user-driven. Especially large corporate customers feel the urge for easy-to-handle bills. These bills may no longer be printed; rather they are distributed in digital forms like CDs or electronic messages. Electronic information exchange is also essential between different PNOs for interconnect accounting. Customers require one detailed, customized bill containing all services, with a billing cycle fitting their needs.
CCB system is fundamental for developing flexible customer care packages. Customers want optimized service packages with tailored tariffs. CCBs must also support rapid rollout of new services, whose lifecycle may even be only one day.
CCB systems consist of many separate applications. As the operators are reluctant to change all these at one time, new systems must be capable of interworking with legacy systems.
Some CCB systems offer the whole range of functionality, including mediation, while some are offering a more restricted set. The functionality can be usually divided into two areas, namely customer care and billing functionality, and analytical tools. CCB functionality starts with order handling and service provision followed by rating the service transaction records and billing both end-user customers and other carriers.
Analytical tools can be provided for a number of purposes but the two most frequently encountered are for fraud prevention and business planning purposes. The fraud prevention area, especially in mobile, where roaming data can take up to 72-hours to be distributed and processed, represents the leading edge of billing systems development. However, the requirement for near real-time transfer of data is almost impossible given the huge volume of data that would need to be transmitted.
Business planning tools are demanded by sales and marketing personnel. Some areas of application are customer profiling, tracking the effectiveness of marketing campaigns, and offering support for price optimization.
Currently, there is no single, always implemented interface standard between network elements, mediation devices and billing systems. Rather, the network elements implement varying protocols for fetching the CDRs, and the billing systems have in many cases their own procedures adapted to their specific needs. However, as the TMN is gaining popularity, the interfaces are being standardized where possible.
The X-interface between different operations systems, billing applications is perhaps the most important interface. An accepted standard would help to speed the adaptation of automated remuneration procedures between operators. EURESCOM project P407 was set up to provide requirements and specifications for computerization of the accounting process, and more specifically to define the TMN X-interface. This project produced deliverables in 1997, and these specify a generic TMN X-interface [6, 7].
Another interface where standardization activities have taken place is the Q3-interface. ITU-T gave in 1995 the Recommendation X.742 [18], which specifies a model and management information for the acquisition of information by a managing system of resource usage information. The specification is generic, and is specialized for call detail recording at Q3-interface in ITU-T Recommendation Q.825 [17]. ITU-T specifications Q.811 [15] and Q.812 [16] define OSI compatible protocol stacks to be used at Q3- and X-interfaces.
The installed base of accounting systems mostly doesn’t use these specifications. Below the billing systems, many operators have implemented optimized in-house interfaces and systems, while some, especially new operators resort to off-the-shelf packages. In the interconnect accounting, the call detail information exchange is mostly based on Recommendation D.176 from ITU-T [9]. It specifies formats for batches and records, thereby enabling automated information exchange.
When an end-user requests services not obtainable from one provider, or simply a connection to another end-user on different network, the operators must co-operate to meet these requests. In such cases every provider should be paid some remuneration for participating in the service provision.
From the end-users' point of view there are two ways to achieve interconnect billing: Consolidated one-stop-billing or direct billing. In one-stop-billing the subscriber receives one bill for all service usage from the contracted operator, while in direct billing subscriber receives one bill per operator whose services has been employed. The direct billing is much simpler to arrange for an operator, but end-users prefer one-stop-billing. The direct billing would also require that each operator has the billing address of the user, which would require an agreement between the user and all operators. Thus the customer billing is done by one contracted operator, which will then share the revenues between the participating operators. [4]
For one-stop-billing, operators can usually charge the account of the user based on the CDRs from their own network equipment. Later, the other involved operators send information about the services they have provided to the users of the operator. The revenue will be then shared based on the provided information. The information exchange may take place per call or in batches. Per call exchange may be preferred for national traffic.
The charging data and resulting payments can be handled by either direct or centralized arrangements. In the direct versions, each involved operator sends their data and bills directly to the originating operator. This would require the operators to manage multiple, possibly different interfaces. To reduce the amount of data interfaces, the exchange usually takes place via some Data Clearing House (DCH). In order to reduce the number of settlements and the money involved, a Clearing House balances the accounts of the involved operators. A Clearing House will collect information coming from the operators, and at certain intervals compute the collected material and arrange the clearing between the parties. An extreme case of centralized revenue sharing would be the case where all end-users interface with a single centralized agency. This however, is not preferred, as the operators would then lose the client contact. [4, 5]
In the past, information exchange has required manual labor. The data has been sent on paper, diskettes or magnetic tapes, which has been both error prone and slow process. The exchange intervals have been 1 to 3 months long. Nowadays electronic means are becoming more commonplace. The use of EDI techniques is expected to provide a faster and more secure means of exchanging data, and to reduce costs by automating the process for entering data received from other Administrations to computer systems. [10]
When most of the traffic has been circuit related, operators have accepted that the signalling traffic is accounted for in the charges for the connection. However, the new services, like roaming in mobile communications, are increasingly non-circuit related. The new services are also generating much larger volumes of signalling traffic than the basic voice service. Furthermore, in SS7 the signalling need not follow the same path as the traffic; rather it may be routed via an operator not otherwise related to the call, and therefore not remunerated. [22]
So far, this traffic is generally not accounted for, but as signalling capacity demands are growing, the operators will require remuneration for this traffic. Some mobile operators are already charging small fixed fees when a roaming subscriber first connects to their network.
In 1988, ITU-T released Recommendation D.211, which discusses general accounting options for signalling traffic. The three options are: [11, 12]
Accounting method may also be a combination of these options: Circuit related traffic may be unaccounted, or accounted by flat rate, and non-circuit related traffic might be charged by volume after some threshold. If accounting is based to transfer volumes, signalling traffic must be measured. This by itself requires more capacity from the network.
The presented three tiered model for accounting is general, and could be adopted also for the traffic in the Internet. The volume based accounting system NORDStat can be perceived through this model. NORDStat is used to measure national traffic in Funet's network. This chapter briefly discusses it as seen through the model described in the previous chapters.
NORDStat consists of three layers. In the lowest layer, there are the switches and routers as network elements. These are registering the traffic into management information bases (MIBs) accessible via Simple Network Management Protocol (SNMP). The records are available per permanent virtual channel (PVC) in the switches and per interface in the routers.
The records are then polled from the mediation layer by a Tcl/Scotty script, which stores the counters into its internal storage. The mediation layer processes these files to generate records for daily, weekly and monthly traffic for each PVC and interface. In the case of small number of counters based on well-organized connection hierarchy, as in Funet, this sort of usage metering is viable. However, if the system should be expanded to measure traffic in the level of individual packets, the load would be too heavy both in the NEs and in MDs. The only solution would be then to sample the data flow.
The billing layer takes the records and maps the PVC and interface identifiers into descriptors containing the identifier of the subscriber. These are then sorted by subscribers, after which the costs can be calculated for each subscriber.
For the full adoption of a TMN based accounting system, the interfaces would need some synchronizing work. However, we can see that the same tasks need to be achieved in both worlds when performing accounting.
We have studied in the previous chapters a model for accounting in telephone networks. The framework contains three layers: The network elements to generate raw call detail records, mediation devices to collect the records and preprocess them, and billing systems themselves to generate the bills for the customers.
In the past, there have been mainly proprietary transfer procedures between the layers, but things are changing fast. New interfaces are being specified upon TMN model and OSI protocols to ease for example interconnect accounting. Other players are also being involved in this process: Object Management Group is specifying a CORBA Telecom Event Log Service [8], which could be used for example in IN services. Except the interfaces, the whole accounting system has been proprietary. Currently there are many vendors offering both CCB and MD systems, but many operators are still using in-house systems. As the new operators are starting with off-the-shelf products, we will see whether the old operators can keep up with the development, or will they also move away from the in-house systems.
| ASCII | American Standard Code for Information Interchange |
| CCB | Customer Care and Billing |
| CDR | Call Detail Record |
| CORBA | Common Objects Request Broker Architecture |
| DCH | Data Clearing House |
| EBCDIC | Extended Binary Coded Decimal Interchange Code |
| EDI | Electronic Data Interchange |
| EURESCOM | German company carrying out R&D projects |
| FTAM | File Transfer, Access, and Management |
| FTP | File Transfer Protocol |
| IN | Intelligent Network |
| ITU | International Telecommunications Union |
| ITU-T | ITU Telecommunications sector |
| MD | Mediation Device |
| MF | Mediation Function |
| MIB | Management Information Base |
| NORDStat | Network monitoring package developed in NORDUnet |
| NE | Network Element |
| NEF | Network Element Function |
| OMG | Object Management Group |
| ONP | Open Network Provision |
| OS | Operations System |
| OSF | Operations System Function |
| OSI | Open Systems Interconnection |
| PPM | Periodic Pulse Metering |
| PSTN | Public Switched Telephone Network |
| PVC | Permanent Virtual Connection |
| Q3-interface | Interface between OSF and MF |
| Qx-interface | Interface between a MF and NEF, QAF and other MFs |
| QA | Q Adaptor |
| QAF | Q Adaptor Function |
| Scotty | Tcl Extensions for Network Management Applications |
| SNMP | Simple Network Management Protocol |
| TAC | Telecommunications Administration Centre |
| Tcl | Tool Command Language |
| TT | Toll Ticket |
| TMN | Telecommunications Management Network |
| UMR | Usage Metering Record |
| X-interface | Interface between OSFs of two TMNs |
| [1] | Chorleywood Consulting LTD, Mediation Systems - The manual of using mediation systems to improve telco customer care and billing, Chorleywood Consulting LTD, 1997 |
| [2] |
Comptel Oy, Mediation Device Solutions, Oy Comptel Ab, 1999 [referred
19.04.1999]
< http://www.comptel.fi/mds.htm> |
| [3] | Dedman, R. D., Building Customer Loyalty and Minimising Churn - A guide to effective customer care and billing systems in telecoms services, Financial Times, 1996 |
| [4] | ETSI Technical Comittee Network Aspects, Network Aspects (NA); Considerations on network mechanisms for charging and revenue accounting, ETSI Technical Report 101 619 v1.1.1, 1998, 36 p. |
| [5] | EURESCOM Project P223, TMN Guidelines and Information Model – Deliverable 2 – Volume 2 of 2 – Billing, Accounting and Charging of Joint/Co-operative Services, EURESCOM, 1994 |
| [6] | EURESCOM Project P407, TMN X-interface for Charging, Billing and Accounting – Deliverable 1 – Target Scenario, EURESCOM, 1997, 27 p. |
| [7] | EURESCOM Project P407, TMN X-interface for Charging, Billing and Accounting – Deliverable 2 – X-interface for BAC – Volume 1 of 4: Overview, EURESCOM, 1997, 27 p. |
| [8] | Expersoft Corporation, Hewlett-Packard Company, Nortel Technology, Telefonica Investigacion y Desarrollo, Telecom Event Log Service, OMG Document number: telecom/98-10-17, 1998, 56 p. |
| [9] | International Telecommunication Union, Transmission in encoded form of telephone reversed charge billing and accounting information, ITU-T Recommendation D.176, 1997, 13 p. |
| [10] | International Telecommunication Union, Exchange of international traffic accounting data between administrations using electronic data interchange (EDI) techniques, ITU-T Recommendation D.190, 1995, 9 p. |
| [11] | International Telecommunication Union, International accounting for the use of the signal transfer point (STP) in Signalling System No. 7, ITU-T Recommendation D.211, 1996, 9 p. |
| [12] | International Telecommunication Union, Charging and accounting principles for the use of Signalling System No. 7, ITU-T Recommendation D.212, 1996, 9 p. |
| [13] | International Telecommunication Union, Supplement 3: Handbook on the methodology for determining costs and establishing national tariffs, Supplement 3 to ITU-T Series D Recommendations, 1993, 43 p. |
| [14] | International Telecommunication Union, Principles for a Telecommunications management network, ITU-T Recommendation M.3010, 1996, 81 p. |
| [15] | International Telecommunication Union, Lower layer protocol profiles for the Q3 and X interfaces, ITU-T Recommendation Q.811, 1997, 57 p. |
| [16] | International Telecommunication Union, Upper layer protocol profiles for the Q3 and X interfaces, ITU-T Recommendation Q.812, 1997, 25 p. |
| [17] | International Telecommunication Union, Specification of TMN applications at the Q3 interface: Call detail recording, ITU-T Recommendation Q.825, 1998, 104 p. |
| [18] | International Telecommunication Union, Information Technology – Open Systems Interconnection – Systems Management: Usage Metering Function For Accounting Purposes, ITU-T Recommendation X.742, 1995, 50 p. |
| [19] | Lindqvist, T.-M., Charging and accounting in digital mobile cellular systems, Master's thesis, Helsinki University of Technology, Faculty of Electrical Engineering, Espoo 1993, 76 p. |
| [20] |
TAC Finland, Regulation on Charging Principles in Public Telecommunication
Networks, THK 31 A/1997 M, 1997 [referred 19.04.1999]
< http://www.thk.fi/englanti/document/thk31a97.pdf |
| [21] |
TAC Finland, Telecommunications Administration Center – Presentation,
02.06.1998 [referred 19.04.1999]
< http://www.thk.fi/englanti/esittely/n2483.htm> |
| [22] | Timperi, J.-P., Yhteiskanavamerkinantoliikenteen veloitus DX 200 -järjestelmässä, Master's thesis, Helsinki University of Technology, Department of Computer Science, Espoo 1995, 80 p. |
NORDStat used in Funet is based on the work by Håvard Eidnes at NORDUnet. Some material of the original package, including the source code, is available in http://www.nordu.net/stats/. This was then refined in Funet between years 1997 and 1998.