Journal of Network and Systems M anagement, Vol. 5, No.

1, 1997

In t roduction to the Automatic Message Accounting Data Network System (AMADNS)1

Lee E. Heindel,2 , 3 Helen L. Hogan, 2 and Vincent A. Kasten 2

It has become necessary with the ever-increas ing volume of billing data generated by the telecommunications industry to revisit the whole area of billing data collection, starting with Automatic Message Accounting (A MA ) data, and evolving to the future sources of charging data. The Automatic M essage Accounting Data Networking System (AM ADNS) supports the collection , processing, transfer, and management of AM A data from Generating Systems such as central of ce switches to an array of applicatio ns. AM ADNS systems must be well-structured and exible in ways that will support future generating systems as they are integrated into the various different networks being created within the telecommu nications industry. This paper presents an introduction to the generic requiremen ts for AM ADNS as presented in the Bellcore Generic Requiremen ts for the Automatic M essage Accounting Data Networkin g System (AM ADNS), Issue 1, Bellcore document GR-1343-COR E. K E Y W OR D S: Distributed billing systems; data networking; billing system s architecture.

1. INTRODUC TION Automatic Message Accounting is the mechanized process of measuring and accounting for the use of network telecommunications resources by customers

1 Bellcore

does not provide comparativ e analysis or evaluation of products or vendors. Any mention of products or vendors in this document is done where necessary for the sake of scienti c accuracy and precision, or for backgroun d information to a point of technolo gy analysis, or to provide an example of a technolo gy for illustrative purposes, and should not be construed as either positive or negative commentary on that product or that vendor. Neither the inclusion of a product or a vendor in this document, nor the omission of a product or vendor, should be interpreted as indicating a position or opinion of that product or vendor on the part of the authors or of Bellcore. 2 Bellcore, 6 Corporate Place, Piscataway, New Jersey 08 854. 3 Correspondence should be directed to Lee E. Heindel, Heindel Solution Systems, 4901 Pine Cone Circle, Middleto n, Wisconsin 53562. 31

32

Heindel, Hogan, and Kasten

and carriers. The data generated during the AM A process must be transferred from the points of data generation (e.g., switching systems) to the points of data application. In addition to data transfer, data processing and data management are required to support the provision of AMA data to applications. The transfer, processing, and management of AMA data is called AM A Data Networking and is provided by the AMA Data Networking System (AMADNS) [1, 2]. AMADNS supports the transfer, processing, and management mechanisms required to supply data applications with AMA data. The future environment will see substantially higher AMA data volumes due to new network services and more-comprehensive measurement strategies for existing services. At the same time, new applications will require access to AM A data, and some of these applications have special needs, such as specialized data processing, and near-real-time and on-demand access to AM A data. In addition, the value of given AMA data may vary widely (e.g., due to the use of data aggregation), thereby requiring the capability to treat different AMA data in a different manner. AM ADNS is designed to support the anticipated AMA data volumes and special needs of multiple applications while retaining the high degree of quality, availability, and security required for AMA data. Changes in the AM A environment have created additional challenges for AMA data transfer, processing, and management. These changes motivated the creation of AMADNS to meet future AM A data collection needs in the following ways: Higher data transmission rates to support large volumes of data Signi cant increases in the volume of AMA data due to the introduction of new network services and increased or new measurements for existing network services are expected throughout the decade. In fact, analysis has shown that the AMA data volumes will likely quadruple by 19 98 from the levels in 19 91. Support for multiple applications for AM A data Invoice processing , the processing of AMA data necessary for billing customers and carriers for their use of network resources, is the only application for AM A data currently supported. Although invoice processing is the most important application for AMA data, additional applications which require or could bene t from access to AM A data have been identi ed. (For the remainder of this paper, the term Application is used to refer to any application using AM A data.) The new applications include fraud detection, Customer Network Management ( CNM ) for various services, Message Detail Recording ( MDR ), marketing, and engineering and planning for various networks. Hence, multiple Applications will have to be provided access to AMA data. Impro ved data access Many new applications require data transfer alter-

Automatic Message Accounting Data Network System

33

natives that are not currently supported. These alternatives include nearreal-time data transfer (e.g., for fraud detection) and on-demand data access via remote data requests (e.g., for marketing.) Specialized processing capabilities New applications and new network services require specialized data processing capabilities, which are not currently supported. Specialized processing needs include data aggregation (e.g., for packet-based services) and correlation (e.g., for support of complex billing situations where multiple systems generate AMA data for the same call. ) AM ADNS is architected to meet these important challenges by incorporating many of the technological advances that have recently occurred. The emergence of standard protocols [ 3 5] will allow greater interoperability between different components in AM ADNS. The development of fast transmission technology allows for support of higher-speed protocols for the system interfaces, which will enable the growing data volumes to be handled and the near-realtime data access needs of Applications to be ful lled. In addition, advanced mechanisms for remote data access will meet the on-demand access needs of Applications. There are numerous other bene ts to be derived from the deployment of AM ADNS. The use of higher-speed interfaces for data transfer will result in improved cost ef ciency. In addition, reductions in cost can be achieved by employing network-based data transfer to eliminate manual operations (e.g., tape-based data transfer). AMADNS will also help to increase and protect a telecommunications companys revenue base and reduce costs by providing new applications with access to AM A data. AMADNS offers greater exibility in data transfer and processing to enable rapid support for new or changed applications and points of data generation. (A point of data generation will be referred to as a Generating System for the remainder of this paper.) Furthermore, standard network management procedures employed by AMADNS will provide better control over the system.

2. SYSTEM ARC HITECT URE This section presents a high-level view of AMADNS, including the logical architecture and primary system characteristics. The logical functional architecture of AM ADNS is illustrated in Fig. 1. As shown, AMADNS is composed of Data Servers, one or more Data Processing and Management Systems (DPMS s), one or more System Managers, and the various interfaces to these components. The Generating Systems and Applications connected via AMADNS represent the sources and destinations, respectively, of AM A data. The ow of AMA data from Generating Systems to Applications is described later.

34

Heindel, Hogan, and Kasten

Fig. 1. AM ADNS logical functional architectur e.

Generating Systems generate the AM A data. Generating Systems include Switching Systems, Service Control Points ( SCPs), Signal Transfer Points ( STP s), and Operations Systems (OS s). More than one Generating System (e.g., a Switching System and an SCP) could be contained within a single device. Each Generating System generates AMA data in a particular format, usually Bellcore AMA Format (BAF). Once formatted (i.e., organized into a de ned unit), these data are called AMA records, which are organized collections of AMA data elements. A Generating System transfers AM A records to a Data Server soon after the records are generated. A Data Server can be implemented either internally or externally to a Generating System. In both cases, a single Data Server can serve multiple Generating Systems. An internal Data Server could serve multiple Generating Systems contained within the same device, and an external Data Server could serve multiple stand-alone and or jointly-contained Generating Systems. Furthermore, an external Data Server is assumed to be located near the associated Generating System(s) (i.e. in the same building). Therefore, the interface between a Generating System and an external Data Server is based on a Local Area Network ( LAN ). After receiving AM A records from a Generating System, a Data Server processes the records, and stores them in an AMA le. The Data Server then transfers the AMA le to a DPMS. The AMA les are transferred between a Data Server and DPMS using standard protocols for le transfer and networking.

Automatic Message Accounting Data Network System

35

The allowable network-based protocols correspond to both Wide Area Networks (WANs) and LANs, which will be used appropriately to connect Data Servers to DPMSs. Upon receiving AMA les from multiple Data Servers, a DPMS processes the AMA records contained in these les as required by the individual Applications desiring access to the records and stores the desired AMA data (which consists of original AM A records and or the results of data processing) in the form of individual AM A les. These les are eventually transferred to individual Applications. File creation is possible when an Applications data and data processing needs are pre-de ned. A DPMS could optionally store some or all of the AM A records received in AM A les in a database, termed the AMA Database . The AM A records placed in the AMA Database would not be altered by data processing performed at the DPMS (other than that necessary to support communication or to validate the records). If supported, the AMA Database enables subsequent on-demand data requests from Applications, which may be necessary when the speci c data desired by an Application cannot be predetermined. AM A data (i.e., AMA les or individual AMA records) are transferred between a DPMS and an application using standard protocols for le transfer, (optionally) remote data access, and networking. Both le transfer and remote data access services may be required to satisfy the varyin g data access needs of applications. The allowable network-based protocols correspond to both WANs and LANs, which will be used appropriately to connect local and remote applications to a DPMS. Applications are the destinations of AMA data. They are the software programs requiring access to AMA data to provide a service to telecommunication company customers or to support internal telecommunication operations. A System Manager manages Data Servers and DPMSs. A System Manager could also manage (or at least obtain network management data from) devices providing communications between these system components. Data Servers and DPMSs are termed Managed Components within the context of system management. The types of system management functions supported by a System Manager for controlling Managed Components are con guration, fault, performance, security, and accounting management. The System Manager manages the Managed Components using a standard interface [6]. This interface is used to transfer system management data necessary for administration and maintenance of these components. The interface is composed of standard protocols for network management, le transfer, remote login, and networking. As with the other system interfaces, the allowable network-based protocols correspond to both WANs and LANs, which will be used appropriately to connect local and remote Managed Components to a System Manager.

36

Heindel, Hogan, and Kasten

3. SYSTEM CH AR ACTER ISTICS AMADNS is architected to provide the AM A data transfer, processing, and management capabilities necessary for the future AM A environment. The key characteristics of AMADNS are sender-initiated and receiver-initiated data transfer, near-real-time data availability, standard protocols, specialized data processing, and standard system management. AMA data transfer is performed throughout the end-to-end logical data path (i.e., AMA data are transferred from a given Generating System to the associated Data Server, to a DPMS, and nally to one or more Applications). For two of the interfaces along this logical data path, namely the DDI and the DAI , the AMA data transfer between communicating components can be initiated by either the sender or receiver of the data. This capability enables the maximum possible exibility for data transfer. The DDI is used to transfer AMA les between a Data Server (the sender) and a DPMS (the receiver). Both Data Servers and DPMSs are capable of initiating a le transfer based on user-settable time schedules, time periods, volume of AMA data available, and manual requests. The DAI is also used to transfer AM A data either in the form of les or, optionally, replies to data requests between a DPMS, the sender, and an Application (the receiver). AMADNS supports data transfer initiation by both DPMSs and Applications. Data transfers to Applications can be initiated by a DPMS based also on user-settable time schedules, time periods, volume of AM A data availab le, and manual requests. A DPMS can initiate the transfer of les to an Application. An Application can request both AMA les for that Application or speci c AMA data contained in the AMA Database (if on-demand access is supported). Near-real-time data availability enables Applications to access AMA data soon after the data are generated (e.g., 15 minutes). Some time-sensitive Applications (e.g., fraud detection) require data access of this type, while other Applications can bene t from having access to recently generated AMA data. It is important to note that AMADNS has not been architected to address real-time services (i.e., services requiring the availability of AM A data within several seconds of when the data are generated). However, in AMADNS, time schedules and other trigger events enable les to be sent as frequently as desired. Frequent le transfers enable AMA data to be transferred across the DDI soon after they are generated by a Generating System and across the DAI soon after the corresponding AM A les are received from a Data Server. The higher-speed networks used for the system interfaces of AMADNS enable data transfer to be completed in a much shorter time. The prioritizing of data for processing and transfer is the nal primary feature supported by AMADNS which enables near-real-time data availability. Standard protocols provide an open environment by enabling interoperabil -

Automatic Message Accounting Data Network System

37

ity . Interoperability is the capability of heterogeneous systems to communicate with each other. Interoperability enables cost-effective system deployment and expansion, more choices for equipment procurement, and more-effective system management. Specialized data processing refers to processing beyond the basic operation of a system component. The term specialized processing module is used for the software that provides a particular specialized data processing function. Some examples of specialized processing modules are validation, aggregation, correlation, and format conversion. Data Servers and DPM Ss provide the mechanisms that allow specialized processing modules to be integrated into their operations. A standard software execution environment is supported by these system components to facilitate the development, integration, and porting of specialized processing modules. Standard system management ensures the ef cient operation of a system composed of heterogeneous machines and facilitates the recon guration and maintenance of such a system. Centralized system management eliminates various redundant operations and enables an administrator to obtain an overall view of the system. Standard centralized system management is provided in AM ADNS by the System Manager. The System Manager manages Managed Components, namely Data Servers and DPMSs. The System Manager provides administrators with an overall view of the system and enables them to control each Managed Component. This overall system view is achieved by maintaining a logical image of the AMADNS systems. The system image and the actual system are kept in synchronization through the constant exchange of information between the Managed Components and the System Manager using a standard network management protocol. A System Manager s control over components is supported in the areas of con guration, fault, performance, security, and accounting management. The System Manager administers data transfer, data processing, and security information used by Data Servers and DPMSs to perform their functions. In addition, the System Manager supports fault detection, remote program loading, and automated maintenance. 4. SYSTEM FUNCTIONALITIES BY COMPONENT Figure 2 illustrates the internal elements and interfaces providing the primary capabilities of a Data Server. The arrows in Fig. 2 indicate the direction of the main ow of data across the interfaces. Core function modules perform the data transfer, processing, and management tasks necessary for the basic functioning of a system component. The core functions of a Data Server are communications with other components, le transfer scheduling, and le management. Specialized processing modules are the software providing processing

38

Heindel, Hogan, and Kasten

Fig. 2. Data server logical function al architectur e.

beyond the basic operation of a system component. Although specialized processing modules are not necessary for the basic operation of a Data Server, they may be necessary for supporting a particular type of Generating System (e.g., a module that provides data aggregatio n for broadband switching systems may be desirable). Support function modules perform the tasks needed to ensure proper operation of a system component. Support functions for a Data Server include administrative and maintenance activities. Figure 3 illustrates the internal elements and interfaces providing the primary capabilities of a DPMS. The arrows in Fig. 3 indicate the direction of the main ow of data across the interfaces. The core function modules of a DPMS perform the basic component tasks. The modules support communications with other components, le transfer scheduling, le management, (optionally) database management, (optionally) data request processing, and archiving. Although specialized processing modules are not necessary for the basic operation of a DPMS, they may be necessary for supporting particular types of Generating Systems and Applications (e.g., a module that provides correlation of multiple AM A records generated for the same call may be desired to support a billing system). It is expected that a DPMS will support more specialized processing modules than a Data Server. Standard AMA les are transferred to a DPMS over the Data Server DPMS Interface. The transfer may be initiated by either system component. Transfer initiation by the DPMS is based on user-settable time schedules, time periods, volume of AMA data available, and manual requests. AM A data, either in the form

Automatic Message Accounting Data Network System

39

Fig. 3. DPMS logical function al architectur e.

of les or (optionally) replies to data requests, are transferred to Applications over the DPMS Application Interface. Either system component can initiate this transfer, the DPMS can initiate a le transfer to an Application, or an Application can directly request an already-created AMA le or, if supported, speci c AMA data stored in the AMA Database. The AMA les transferred from a DPMS to an Application are either Standard AMA les or Tape Format AM A les. A Tape Format AM A le is composed of AM A records organized into the format used for AM A records placed on a 9-track magnetic tape. A DPMS sends Tape Format AM A les to billing system Applications, and Standard AM A les to all other Applications. Several interfaces are employed for the management of a DPMS. The System Manager DPMS Interface is used by a DPMS to receive con guration, fault, performance, security, and accounting management, including program loading and maintenance. As for a Data Server, a DPMSs operation and maintenance interfaces are used for local maintenance and testing, and the alarm interface is used to output signals that produce visual and audible noti cation of alarm conditions. Figure 4 illustrates the internal elements and interfaces providing the primary capabilities of a System Manager. The arrows in Fig. 4 indicate the direction of the main ow of data across the interfaces. Management Applications are software that perform the primary functions of a System Manager. These applications access, create, and modify management data, issuing requests to Managed Components to accomplish their tasks. The System Manager supports Management Applications that provide con guration, performance, fault, security, and accounting management. System Manager employ nonvolatile mass storage for maintaining a man-

40

Heindel, Hogan, and Kasten

Fig. 4. System manager logical function al architectur e.

agement database and management les. The management database holds management data collected from Managed Components and facilitates the composition of management reports. Management les are those les created, accessed, modi ed, or distributed by Management Applications (e.g., program les sent to Managed Components). The System Manager Managed Component Interface enables the System Manager to remotely manage the Managed Components. The Management Applications use this interface to perform their tasks. The System Manager System Manager Interface, which is optional, enables coordination between multiple System Managers. This interface provides the means by which the controlling and monitoring functions of system management can be distributed among multiple management stations. Such distribution accommodates growth in the number of Managed Components and facilitates system management. The user interface provides the means for a human user (e.g., system administrator) to locally access the System Manager. A user views information and controls Managed Components via the user interface. The interface is characterized by a multi-window environment that enables a user to simultaneously view management information for multiple Managed Components and easily switch between control of one component and control of another component. In addition, the user interface is highly graphical so that the control of system components can be effectively performed using visual images.

5. SYSTEM INTER FACE S AMADNS is composed of many system interfaces. At the Upper Layers, the Internet File Transfer Protocol (FTP) is used for le transfers between a Data Server and DPMS, a DPMS and an Application, and a System Manager and Managed Component. The OSI Remote Database Access (RDA) protocol based on the Structured Query Language (SQL) is optionally supported to handle on-demand data requests made by Applications. In addition, the Simple Network Management Protocol (SNMP) [6] supports management of the over-

Automatic Message Accounting Data Network System

41

Fig. 5. Potential system interface con gurations.

all AMADNS, and Telnet is used for remote login capabilities. Upper Layer protocols are not required for the Generating System Data Server Interface as this interface is characterized by the one-way transfer of AM A records over secure LANs. Figure 5 illustrates ve possible ways in which end systems for AM ADNS could be connected.

6. SYSTEM SECU RITY The security of AM A data is of paramount importance to telecommunications companies. Since AMA data is a source of revenue, the data must be protected. Because public data networks could be used for the transfer of AMA les and other communications, protecting the data becomes more dif cult. Therefore, appropriate security mechanisms are supported to counter anticipated network security threats. The system components (namely the Data Servers, DPMSs, and System Managers) apply the following security mechanisms for protection again st unauthorized access and sabotage: identi cation, authentication, resource access control, data and system integrity, continuity of service, and auditing. The security mechanisms speci c to communications must also be supported by the Generating Systems and Applications with which the system components communicate. In addition, the system components are expected to be located in a physically secure environment that prevents easy local access to components. Identi cation and authentication are supported for both local access and remote (i.e., network-based) access to a system component. For local access, the provision of a login ID and password is suf cient to gain access to the component. However, for remote access via FTP, Telnet, and

42

Heindel, Hogan, and Kasten

RDA, additional capabilities are supported to counter network security threats. An encryption procedure is used for these protocols to help ensure that a password sent across a network is not recorded by an eavesdropper and used at a subsequent time. However, for remote access via SNMP, an unencrypted password, called a community name , is exchanged to authenticate the user. Since this mechanism does not prevent the recording and re-use of the community string by an eavesdropper, it is likely that system components will only permit read-only access to management information when SNMP is used. SNMPv2 is expected to be employed for AMADNS in the future to eliminate the security limitations characteristic of SNMP. Resource access control is supported by a system component to limit authenticated users access to component resources. Users are granted access rights that indicate the les, data, and software to which a user has access, as well as the functions the user can perform on these resources (e.g., read a le, delete data, run software). Data integrity is supported by a system component to help ensure the integrity of data received by another source. Protocol error detection, originator identi cation, and data update validation provide the necessary level of data integrity in most cases. 7. THE DATA SERV ER The Data Server is the system component associated with one or more Generating Systems that provides AM A data processing, temporary data storage, and data transfer to a Data Processing and Management System (DPMS). A Data Server may be implemented as an internal part of a Generating System or as an external device. If a Data Server is implemented as an internal part of a Generating System, the data transmission path between the Data Server and the Generating System may not be accessible. In this case, requirements associated with the Generating System Data Server Interface are not applicable. Internal and external Data Servers can serve more than one Generating System. A Data Server receives AMA records from one or more Generating Systems, processes the records, and stores them in nonvolatile mass storage. These AMA records are transferred to a DPMS, in the form of Standard AMA les, based on a prede ned time schedule, a pre-de ned volume of AMA data received, or a manual request. The major functions of a Data Server are:

Receiving AM A records from associated Generating Systems. Performing necessary processing on AM A data. Maintaining AMA data before and after the data are transferred. Sending AMA data to a DPMS over a network. A Data Server consists of core function modules, specialized processing modules, support function modules, and mass storage, each of which are

Automatic Message Accounting Data Network System

43

described throughout this section. A Data Server is accessed through the following interfaces: The Generating System Data Server Interface (GDI) enables an external Data Server to receive AM A records from the Generating System(s) it serves. The Data Server DPM S Interface (DDI) enables a Data Server to transfer Standard AM A les to DPMSs over a network. The System Manager Data Server Interface enables a Data Server to communicate management information with the System Manager. This interface provides remote access to the Data Server for control and monitoring functions via a standard network management protocol, le transfer protocol, and remote login protocol. The operation interface provides operation and administration personnel with local access to the Data Server for control and monitoring functions via input output messages. The maintenance interface provides maintenance personnel with local access to information that may be used for monitoring the components status and alarms, controlling user-settable con guration parameters, and locating and repairing faults. The alarm interface provides a means for local trouble noti cation. The removable media interface enables the Data Server to send AMA data to a removable medium for transfer to a DPMS. This interface could also be used to receive program les.

A Data Server maintains two types of data: AMA data Data generated by a Generating System. AMA data are received from the Generating System(s) a Data Server serves in the form of AMA records. Received AMA records are grouped into Standard AMA les and transferred to a DPMS. Some particular AM A records may be grouped in error les. Operations data Data required for day-to-day operations and component management. Some operations data are accessible in the form of les, and others may be obtained as individual units of data as identi ed by the Data Server s Management Information Base (MIB), which contains information about the management data maintained by a Data Server that are available to a System Manager. Operations data can be controlled from a System Manager or via a console through the operation interface. Program and test les are considered to be operations data. Figure 6 illustrates the typical AMA data processing ow for a Data Server. AM A records are received from one or more Generating Systems. These records may be processed by various specialized processing modules. For a Data Server,

44

Heindel, Hogan, and Kasten

Fig. 6. Typical AM A data processing ow.

specialized processing modules may include distribution, format conversion, validation, surveillance, aggregation, and correlation. As shown in Fig. 6, the output of the specialized processing modules are AMA les ready for transfer to a DPMS. In addition, erroneous records detected by a Data Server are collected in error les. It is expected that each telecommunications company will de ne its own specialized processing modules to be used. These specialized processing modules may be written by the telecommunications company, the Data Server supplier, or a third-party supplier. Therefore, it is essential that the Data Server facilitate the development and portability of specialized processing modules. The Data Server achieves this goal through its Software Execution Environment , which is the environment in which specialized data processing is performed. A Software Execution Environment consists of a components operating system, user interface, and programming language(s). In order to support portability, these elements should be commonly used industry standards (i.e., off-the-shelf and widely used elements). The interface between a Generating System and its associated Data Server is used to transfer AMA records between these components. The Data Server may be implemented internal to or external to a Generating Sys-

Automatic Message Accounting Data Network System

45

tem. The discussions presented in this section apply only to the case in which the Data Server is located external to a Generating System. The Generating System Data Server Interface (GDI) is used to transfer AM A records from a Generating System to an external Data Server, which may support multiple Generating Systems. An external Data Server is assumed to be located near (i.e., in the same building as) the Generating System(s) that it supports. Therefore, a LAN-based protocol stack is used for the GDI. Since the communication between a Generating System and Data Server consists primarily of a one-way transfer of AMA records across a LAN and the LAN is assumed to be suf ciently secure, Upper Layer protocols are not necessary for the interface. Using a short substack minimizes the AMA data transport responsibilities of a Generating System. However, Middle Layer protocols are required to ensure endto-end reliability. While an assumption has been made that each external Data Server is collocated with the Generating System(s) it serves, in certain instances a telecommunications company may choose to locate these components remote from each other. Remote location will likely occur if a telecommunications company uses external Data Servers to serve multiple Generating Systems. Although geographic separation of Generating Systems and Data Servers might in certain cases be more practical, the required levels of security and reliability are more dif cult to achieve. One or more Generating Systems will send AMA records over the GDI to the associated Data Server. Since the failure of this interface might cause AM A records to be lost, it is imperative that the interface be redundant such that a single communications equipment failure does not prevent the transfer of AM A records to the Data Server. Hence, the Generating System and Data Server support two disjoint LANs. To best help ensure the security of the AMA records transferred over the GDI, the two LANs used to connect the Generating System(s) to the associated Data Server should be used solely for the GDI. In other words, the LANs should not be used for any type of communication other than that required for the transfer of AM A records from a Generating System to a Data Server. In this case, a Data Server would use a separate physical interface port to communicate with a DPMS and System Manager. This arrangement helps to ensure that packets received by a Data Server over these LANs contain AM A records generated by an authorized Generating System. Communication between a given Generating System and the associated Data Server is always over only one of the LANs at a given time. AMA data and acknowledgments are both passed over the same LAN using the same TCP connection. However, in the case where the Data Server serves multiple Generating Systems, packets from different Generating Systems could traverse the two LANs to arrive at the Data Server. Generating Systems might use different LANs for performance reasons or because the failure of one of a Generat-

46

Heindel, Hogan, and Kasten

ing Systems LAN communication cards caused the Generating System to begin using the other LAN. Both Generating Systems and Data Servers are capable of initiating the establishment and termination of TCP connections. A Generating System is expected to send AM A records to the associated Data Server as they are generated and formatted. Since most Generating Systems generate AMA records frequently for much of the day, a constant ow of AM A records across the interface will occur. To most ef ciently support this ow, the TCP connection between a Generating System and Data Server is maintained until an abnormal condition or scheduled component shutdown (e.g., for operating system upgrade) forces the connections termination. AMA records are transferred in data packets from a Generating System to the associated Data Server. Each AMA record is generated according to the format supported by the particular Generating System. Multiple formats may exist within AM ADNS, although BAF is expected to be used by most Generating Systems. One or more AM A records are contained in each packet. To simplify the Generating Systems role related to the GDI, an AM A record is not required to be placed entirely in a single Ethernet packet (called a frame ). Hence, an AMA record may be split across two (or more) consecutive frames. It is assumed that all AM A records are delimited such that contiguous records are distinguishable. Therefore, a delimiter is not needed to separate AM A records transferred in the same data packet. The headers and trailers added to the data packet are used to control the transfer of AMA records as de ned by the corresponding protocols. AMA records are exchanged between GDI Application Program s running at a Generating System and Data Server. AM A records are transported within the data eld of a TCP packet (called a segment). The Generating Systems GDI Application Program passes the records directly to the TCP software, and the Data Server s GDI Application Program interprets the contents of the data eld of received TCP segments as AM A records. Since the GDI is intended to be as simple as possible, the GDI Application Programs residing at a Generating System and Data Server do not exchange application-speci c messages to control the transfer of AMA records. Instead, they rely solely on TCP to manage a session (e.g., invoking the TCP open port operation to set up a session and the TCP close operation to end a session). Hence, as soon as a TCP connection has been established, the Generating System begins transferring AMA records to the associated Data Server, regardless of which component initiated the connection. To support near-real-time data availability, a Data Server makes availab le to a DPMS all AM A records that have been received up to one minute prior to the start of an FTP session. A Data Server may initiate the transfer of les both to and from DPMSs and System Managers. Hence, a Data Server can initiate le transfers when it is acting as both the sender and receiver of the les. Four types of events can trigger the transfer of les. A le transfer may be triggered when a speci c date

Automatic Message Accounting Data Network System

47

and time is reached, or when a time period expires. In addition, a le transfer may be triggered when the volume of primary AMA data available to be transferred reaches a pre-de ned threshold. A data transfer can also be triggered when a manual request (i.e., command(s) from an operator) for a le transfer is received. The Data Server establishes an FTP session for transferring the les when one of these trigger events occurs. Figure 7 illustrates how a Data Server could initiate the transfer of Standard AMA les to a DPMS. As AM A records are received from a Generating System (either via an internal interface for internal Data Servers or via the GDI for external Data Servers), they are processed and stored in Standard AM A les. During data processing, one of the aforementioned events may occur to trigger the transfer of a Standard AM A le. A schedule r controls the initiation of le transfers based on triggers. Upon receiving a trigger, the scheduler determines which le to send and where to send it. The scheduler then requests that the transmitter set up an FTP session with the DPMS. If the Data Server is successful in establishing an FTP session, it retrieves the Standard AM A le from mass storage and sends it to the DPMS. The le may have to be processed further (e.g., compressed) before it is transmitted. It is imperative that data are not lost or duplicated when data intended to be sent over one TCP connection are sent over another TCP connection. This TCP connection switchover could be due to the LAN hardware problems, in which

Fig. 7. AM A le transfer processing.

48

Heindel, Hogan, and Kasten

case the switchover would be from a TCP connection on one LAN to a TCP connection on the other LAN. The switchover could also be from a terminated TCP connection on one LAN to a newly established TCP connection on the same LAN. Trouble with a LAN, whether it be a local LAN communications equipment failure, a transmission bus failure, or a performance degradation problem, requires the sending of noti cation to appropriate personnel. Such noti cations are performed by a Data Server by issuing alarms over the local alarm interface and traps over the System Manager Managed Component Interface. A critical alarm is generated by the Data Server in these cases since the subsequent failure of the properly operating transmission bus or local LAN communications equipment would prevent the transfer of AMA data between a Generating System(s) and the associated Data Server.

8. THE DATA PROCESSING AND MANAGEMEN T SYSTEM The DPMS is the system component that receives the AMA data transferred from Data Servers, processes these data, stores the data in les and, optionally, a database, and provides Applications with the desired AMA data, either by initiating the data transfer or responding to a request. The DPMS receives AM A data in Standard AM A les from the Data Servers it serves, processes the data, and stores them in mass storage in three forms: Tape Format AM A les for subsequent transfer to an invoice processing Application at a billing system, Standard AMA les for subsequent transfer to Applications (other than the invoice processing Application), and, optionally, database records for subsequent on-demand requests from Applications. The major functions of a DPMS are as follows: Receiving Standard AMA les from Data Servers Processing AM A data according to the needs of Applications and generating les destined for Applications Storing AMA data for a certain period of time until the data are transferred to Applications Sending Tape Format AM A les to an invoice processing Application at a billing system Sending Standard AMA les to other Applications Optionally, maintaining a database of AMA records (termed the AMA Database ) for the purpose of supporting on-demand requests for AMA data from Applications Archiving AM A data. Figure 3 shows the logical architecture of a DPMS. It consists of core function modules, specialized processing modules, support function modules, and mass storage, which are described in detail in this section. A DPMS is accessed through the following interfaces:

Automatic Message Accounting Data Network System

49

Data Server DPMS Interface (DDI) enables a DPMS to receive Standard AMA les from the Data Servers it serves. DPMS Application Interface(DAI) enables a DPMS to transfer les to Applications and receive on-demand requests from Applications. System Manager DPMS Interface enables a DPMS to communicate management information with a System Manager. The interface provides remote access to a DPMS for control and monitoring functions via a standard network management protocol, le transfer protocol, and remote login protocol. Operation interface provides operation and administration personnel with local access to a DPMS for control and monitoring functions through the use of input output messages. Maintenanc e interface provides maintenance personnel with local access to information within a DPMS which may be used for monitoring component status and alarms, controlling user-settable con guration parameters, and locating and repairing troubles. Alarm interface provides a means for local trouble noti cation. Removable media interface allows a DPMS to archive AM A data and read Standard AMA and Tape Format AMA les recorded on tape by a Generating System, Data Server, or AM AT.

Figure 6 illustrates the typical AM A data processing ow for a DPMS. Standard AMA les are received from Data Servers. The AMA records contained in these les are processed by various specialized processing modules as required by Applications. For a DPMS, specialized processing modules may include validation, aggregation, correlation, distribution, format conversion, and surveillance. As shown in Fig. 7, AM A data processed by the various specialized processing modules may be stored in mass storage and then transferred to Applications at a later time, or the data may be sent to Applications in Tape Format AM A les and Standard AMA les before being sent to mass storage. These data are placed in Tape Format AM A les, Standard AMA les, and, optionally, the AM A Database in mass storage. Figure 7 also shows two core function modules, optional archiving and data request processing, used for outputting AMA data. The archiving module supports the outputting of the AMA data to a removable media drive. The data request processing module supports the outputting of speci c AMA data requested by Applications and the AMA Database, if installed. AM A data received in Standard AM A les from Data Servers could be placed in the AMA Database, as well as being processed and placed in Tape Format AMA les or Standard AMA les destined for Applications. AM A data stored in the AM A Database can be used for the following purposes: Supporting on-demand requests for data The AMA Database supports

50

Heindel, Hogan, and Kasten

on-demand database queries for speci c AMA data. Applications that do not process AMA data on a regular basis can use database queries to search the AM A Database for particular information Constructing les containing AMA data A new Application may want to retroactively receive AMA data maintained in the AMA Database, or an existing Application may inadvertently erase a le that has already been sent to it. These are just two examples of why a DPMS might retrieve selective AMA data from the AM A Database and possibly use applicable specialized processing modules to generate Tape Format AMA or Standard AMA les. Archiving After AM A data have been processed for most Applications, the telecommunications company may have to retain the data for a relatively long period of time during which minimal access will be made to these data. A DPMS uses the removable medium drive to archive data. When archived AMA data is needed, it can be loaded from the archive medium back into the AMA Database and become available for specialized data processing and accessible to Applications. 9. THE SYSTEM MANAGER A DPMS is expected to receive most of its management control from a System Manager. A DPMS, which is a Managed Component from a system management perspective, communicates with a System Manager via SNMP, FTP, and Telnet. SNMP is used by a DPMS to send traps to a System Manager and by the System Manager to set and retrieve management data de ned in the DPMSs MIB. FTP is used to exchange les such as program les (error les could also be sent to a System Manager). Telnet allows a system administrator located at the System Manager to remotely login to the DPMS to perform various management functions. Most of a System Manager s management of a DPMS is via SNMP. The SNMP-based network management framework employed for AMADNS consists of three basic concepts: an SNMP Manager , an SNMPAgent , and a MIB . An SNMP Manager is the software process residing within a System Manager that supports system management via SNMP. An SNMP Agent is the corresponding software process residing within a Managed Component (i.e., a DPMS and Data Server) that supports system management via SNMP. A MIB, which resides within each Managed Component, contains information about the management data that are available to the System Manager. It is important to note that a MIB only de nes the management data, the values of the management data, and associated traps that a DPMS makes available; a MIB does not actually contain the requested data. Using SNMP protocol data units (PDUs) , a System Manager is able to request the values of speci c managed objects in the DPMSs MIB, receive responses to these requests, receive traps from the

Automatic Message Accounting Data Network System

51

DPMS, and update the values of the managed objects composing the DPMSs MIB. The System Manager is the system component that manages the overall AM A Data Networking System. It provides administrators with an overall view of the system and allows administrators to monitor and control each system component. If so desired by the implementor, a System Manager might also be used to manage networking equipment, such as Routers and LAN hubs. A System Manager maintains an up-to-date image of AMADNS. The system image and the actual system are kept in synchronization through the constant exchange of management information between the Managed Components (i.e., Data Servers and DPMSs) and the System Manager. This information is passed over the System Manager Managed Component Interface ( SMMCI ). A System Manager provides the platform on which the following management functions can be automated:

Con guration managem ent A System Manager can read and update Data Server and DPMS management information to recon gure the system. A System Manager also enables remote provisioning of Data Servers and DPMSs, including remote program loading. Performance manageme nt By collecting information from Data Servers and DPMSs, a System Manager can generate statistics to identify performance problems. Fault managem ent A System Manager receives trouble noti cations generated by the Managed Components so that events that cause faults can be correlated to facilitate fault detection, diagnostics, and automated correction. Security manageme nt A System Manager centralizes the administration of login IDs, passwords, encryption keys, and access control information. Accounting managem ent By collecting information from DPMSs re ecting resource consumption (e.g., number of les sent to Applications), a System Manager can allocate costs to users and implement accounting policies. Each of these ve management functions will be performed by one or more Management Applications. The System Manager provides the platform on which Management Applications run. It is expected that implementors will specify and implement many of these Management Applications. As such, only the platform requirements for the System Manager and a minimal set of Management Application requirements are included in this paper. The System Manager consists of the hardware and software necessary to provide integrated management of multi-vendor AMADNS components. Figure 4 shows the System Manager logical architecture, which consists of Management Applications, mass storage, and System Manager interfaces.

52

Heindel, Hogan, and Kasten

Management Applications implement the management functions; they access, create, and modify management data and issue requests to Managed Components to accomplish their tasks. Management Applications can be created by the System Manager supplier, the telecommunication companies, or thirdparty independent software suppliers. The creation of Management Applications is facilitated by the System Manager s Application Programming Interface (API). The API provides a mean to quickly and easily tailor a System Manager to its evolving needs. Furthermore, the API enables Management Applications to be developed independent of the management protocols being used. A System Manager has three interfaces: System Manager Managed Componen t Interface enables a System Manager to exchange management information with the system components that it manages. User interface provides the means for a human user (e.g., system administrator) to locally access the System Manager. This interface is intended to provide a user-friendly presentation. System Manager System Manager Interface enables coordination between multiple System Managers. This interface, which is optional, provides the means by which the controlling and monitoring functions of network management can be distributed among multiple management stations. Such distribution accommodates growth in the number of Managed Components and facilitates network management in AMADNS composed of multiple interconnected administrations.

Most of a System Manager s management of a Data Server is via SNMP, which is a message-based protocol designed to support network management. The management framework adopted for AM ADNS is based on the Internetstandard network management framework, which consists of three basic concepts: an SNMP Manager ; in SNMP Agent , and a MIB. An SNMP Manager is the software process that supports the use of SNMP to manage remote resources (e.g., hosts, Routers, gateways). An SNMP Manager resides within a network management station (NMS), which is a component that manages remote resources. An SNMPAgent is the corresponding software process residing within a remote managed resource that supports the use of SNMP for management. A MIB , which resides within each managed resource, contains information about the management data that are available to the NMS. It is important to note that a MIB only de nes the available management data; a MIB does not contain the actual data. A System Manager plays the role of an NMS, and a Managed Component plays the role of a remote managed resource. An SNMP Manager residing in the System Manager exchanges SNMP-based protocol commands, called protocol data units (PDUs) , with the SNMP Agent residing in the Managed Component.

Automatic Message Accounting Data Network System

53

This exchange is via the SMMCI. The PDUs are used to exchange the Managed Components management data. Each Managed Component maintains a MIB that holds information about these data. A MIB de nes the managed objects and traps for the Managed Component. Managed objects are management data items that are made available to a System Manager via the SMMCI. Traps are SNMPbased noti cations sent by Managed Components to the System Manager(s) to indicate the occurrence of an unusual event (e.g., hardware failure). The System Manager s API is used to develop Management Applications, which use SNMP to implement the management functions of a System Manager. Using SNMP PDUs, a System Manager is able to request the values of speci c managed objects in a Managed Components MIB, receive responses to these requests, receive traps from the Managed Component, and update the values of the managed objects composing the Managed Components MIB. A PDU carries information regarding the operation being requested, information in response to a previously requested operation, and information used to authenticate the sender. As explained earlier, PDUs are used to accomplish the exchange of management data between SNMP Agents and SNMP Managers. PDUs speci ed as part of SNMP accommodate the following capabilities: SNMP Manager retrieving of managed object values from an SNMP Agent SNMP Manager setting of user-settable managed object values through an SNMP Agent SNMP Agent sending of traps to an SNMP Manager. The SNMP-based management framework adopted for AM ADNS is based on a management paradigm called trap-directed polling . The strategy is to reduce the management overhead on a Managed Component and to reduce the impact on the bandwidth of the network used to perform system management. These goals are accomplished by having a System Manager initiate polling of managed object values in response to traps received from Managed Components, rather than requiring the System Manager to perform frequent periodic polling. Also, to avoid forced retransmissions in possibly congested networks, SNMP uses the User Datagram Protocol (UDP) , a connectionless Transport Layer protocol in the Internet protocol suite to support communications. 10. CONCLUSION This paper presented an introduction to the Bellcore Generic Requirements for the Automatic Message Accounting Data Network System (AMADNS), Issue 1, Bellcore document GR-1343-CORE. Development of the AMADNS generic requirements grew out of the need to process the ever growing volumes and types of messaging data produced by existing and planned generating sys-

54

Heindel, Hogan, and Kasten

tems. While processing more and more messaging data, AM ADNS requires that the messaging data be available in near-real-time. REFER EN CES
1. Bellcore Staff, Bellcore Generic Requiremen ts for the Automatic M essage Accounting Data Networking System (A MA DNS), Issue 1, Bellcore Document GR-134 3-CO RE, Bellcore. 2. Lee E. Heindel, Helen L. Hogan, and Vincent A. Kasten, Automatic Message Accounting Data Networkin g System (AM ADNS), The Year in Telecommunications 1995 19 96, Internati onal Engineerin g Consortium, January, 19 95. 3. International Standards Organization , ISO TC97, Information Processing Systems, Open Systems Interconnection-Basic Reference Model, Draft Internatio nal Standard ISO DIS 7498, April 1982. 4. Gary R. McLain, Open Systems Interconne ction Handbook , McGraw-Hill Communicatio ns Series, 19 91. 5. OSN Protocol Transition Guide , Bellcore Special Report SR-STS-001 52 2, Issue 1, November 19 90. 6. William Stallings, SNMP, SN MPv2, and CMIP, The Practical Guide to Network-M anagem ent Standards , Addison-We sley, 1993.

Lee E. Heindel recently retired from Bellcore where he was Director of Enterprise Solutions. Currently he is the principal of Heindel Solution Systems. Dr. Heindel received his Ph.D. from the University of Wisconsin-Madison in Computer Sciences. He is the co-author of the book, LangPak an Interactive Language System and is writing a book on Enterprise M anagement Systems. Dr. Heindel is the author of over 35 papers on technology and managemen t topics. Helen Hogan is a Marketing Director at Bellcore responsible for Customer Care solutions. Helen has 15 years experience in the telecommunications industry, including 10 years at Paci c Bell. Helens career has focused on software and standards development for telephony billing and customer care. Helen has signi cant expertise in Electronic Data Interchange (EDI) and has been instrumental in the development of Bellcores AMA Data Network ing System (A MA DNS) product. Helen received her Bachelor of Arts degree from California State University and completed her Master s Certi cate for Project M anagement in June, 19 96. Vincent A. Kasten recently left Bellcore, where he was a Director, to form his own company. Mr. Kasten received his M .S. in Computer Science from Columbia University in 1979 and has much experience in Open Systems including development, system internals, and is an acknowled ged expert on UNIX system performan ce.