introduction to the automatic message accounting data network system

7/22/2019 Introduction to the Automatic Message Accounting Data Network System

1/24

Journal of Network and Systems Management, Vol. 5, No. 1, 1997

31

Introduction to the Automatic Message Accounting

Data Network System (AMADNS)1

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

It has become necessary with the ever-increasing volume of billing data generated by

the telecommunications industry to revisit the whole area of billing data collection,

starting with Automatic Message Accounting (AMA ) data, and evolving to the future

sources of charging data. The Automatic Message Accounting Data Networking

System (AMADNS) supports the collection, processing, transfer, and management

of AMA data from Generating Systems such as central ofce switches to an array

of applications. AMADNS 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 telecommunications industry. This paper

presents an introduction to the generic requirements for AMADNS as presented in

the Bellcore Generic Requirements for the Automatic Message Accounting Data

Networking System (AM ADNS), Issue 1, Bellcore document GR-1343-COR E.

K EY W ORDS: Distributed billing sys tems ; data networking; b illing systems

architecture.

1. INTRODUCTION

Automatic Message Accounting is the mechanized process of measuring and

accounting for the use of network telecommunications resources by customers

1Bellcore does not provide comparative analysis or evaluation of products or vendors. Any mention

of products or vendors in this document is done where necessary for the sake of scientic accuracyand precision, or for background information to a point o f technology analysis, or to provide an

example of a technology 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.2Bellcore, 6 Corporate Place, Piscataway, New Jersey 08 854.3Correspondence should be directed to Lee E. Heindel, Heindel Solution Systems, 4901 Pine Cone

Circle, Middleton, Wisconsin 53562.


2/24

Heindel, Hogan, and Kasten32

and carriers. The data generated during the AMA 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 ofAMA data to applications. The transfer,

processing, and management of AMA data is called AMA Data Networkingand

is provided by the AMA Data Networking System (AMADNS) [1, 2]. AMADNS

supports the transfer, processing, and management mechanisms required to sup-

ply data applications with AMA data. The future environment will see substan-

tially higher AMA data volumes due to new network services and more-com-

prehensive measurement strategies for existing services. At the same time, new

applications will require access to AMA data, and some of these applications

have special needs, such as specialized data processing, and near-real-time and

on-demand access to AMA data. In addition, the value of given AMA data may

vary widely (e.g., due to the use of data aggregation), thereby requiring the capa-

bility to treat different AMA data in a different manner. AMADNS is designed to

support the anticipated AMA data volumes and special needs of multiple applica-

tions while retaining the high degree of quality, availability, and security required

for AMA data.

Changes in the AMA environment have created additional challenges for

AMA data transfer, processing, and management. These changes motivated thecreation of AMADNS to meet future AMA data collection needs in the fol lowing

ways:

Higher data transmission rates to support large volumes of dataSigni-

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 1998 from the levelsin 1991.

Support for multiple applications for AMA dataInvoice processing, the

processing of AMA data necessary for billing customers and carriers for

their use of network resources, is the only application for AMA data

currently supported. Although invoice processing is the most important

application for AMA data, additional applications which require or could

benet from access to AMA data have been identied. (For the remain-

der of this paper, the term Application is used to refer to any application

using AMA data.) The new applications include fraud detection, Cus-

tomer 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.

Improved data accessM any new applications require data transfer alter-


3/24

Automatic Message Accounting Data Network System 33

natives that are not currently supported. These alternatives include near-

real-time data transfer (e.g., for fraud detection) and on-demand data

access via remote data requests (e.g., for marketing.)

Specialized processing capabilitiesNew applications and new network

services require specialized data processing capabilities, which are not

currently supported. Specialized processing needs include data aggrega-

tion (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.)

AMADNS is architected to meet these important challenges by incorporat-

ing many of the technological advances that have recently occurred. The emer-

gence of standard protocols [35] will allow greater interoperability between

different components in AMADNS. The development of fast transmission tech-

nology allows for support of higher-speed protocols for the system interfaces,

which will enable the growing data volumes to be handled and the near-real-

time data access needs of Applications to be fullled. In addition, advanced

mechanisms for remote data access will meet the on-demand access needs of

Applications.

There are numerous other benets to be derived from the deployment of

AMADNS. The use of higher-speed interfaces for data transfer will result in

improved cost efciency. 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 AMA data. AMADNS offers greater exibility in

data transfer and processing to enable rapid support for new or changed applica-

tions and points of data generation. (A point of data generation will be referred toas 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 ARCHITECTURE

This section presents a high-level view of AMADNS, including the logical

architecture and primary system characteristics. The logical/ functional architec-ture of AMADNS is illustrated in Fig. 1. As shown, AMADNS is composed of

Data Servers, one or more Data Processing and M anagement Systems (DPMSs),

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.


4/24


Fig. 1. AMA DNS logical / functiona l architecture.

Generating Systems generate the AMA data. Generating Systems include

Switching Systems, Service Control Points (SCPs), Signal Transfer Points

(STPs), and Operations Systems (OSs). 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 dened unit), these

data are called AMA records, which are organized collections of AMA data ele-

ments. A Generating System transfers AMA records to a Data Server soon afterthe 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 Gen-

erating 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 associ-

ated 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 AMA 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.


5/24


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 Appli-

cations desiring access to the records and stores the desired AMA data (which

consists of original AMA records and/ or the results of data processing) in theform of individual AMA les. These les are eventually transferred to indi-

vidual Applications. File creation is possible when an Applications data and

data processing needs are pre-dened. A DPMS could optionally store some

or all of the AMA records received in AMA les in a database, termed the

AMA Database. The AMA 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 specic data desired by an Application cannot be pre-

determined.

AMA 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 remotedata access services may be required to satisfy the varying 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 appli-

cations 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 telecommunica-

tion operations.

A System Manager manages Data Servers and DPMSs. A System Managercould 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 manage-

ment. The types of system management functions supported by a System Man-

ager for controlling Managed Components are conguration, fault, performance,

security, and accounting management. The System Manager manages the Man-

aged 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 man-

agement, 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.


6/24


3. SYSTEM CHARACTERISTICS

AMADNS is architected to provide the AMA data transfer, processing, and

management capabilities necessary for the future AMA environment. The key

characteristics of AMADNS are sender-initiated and receiver-initiated data trans-fer, near-real-time data availability, standard protocols, specialized data process-

ing, 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 possibleexibility 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 initi-

ating 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 trans-

fer AMA data either in the form of les or, optionally, replies to data requests

between a DPMS, the sender, and an Application (the receiver). AMADNS sup-

ports 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 AMA data available, 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 specic 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 Applica-tions (e.g., fraud detection) require data access of this type, while other Appli-

cations can benet 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 AMA data within several sec-

onds 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 corre-sponding AMA 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 availabili ty.

Standard protocols provide an open environment by enabling interoperabil-


7/24


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 opera-

tion 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 DPMSs 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 efcient operation of a system

composed of heterogeneous machines and facilitates the reconguration and

maintenance of such a system. Centralized system management eliminates var-

ious redundant operations and enables an administrator to obtain an overall

view of the system. Standard centralized system management is provided in

AMADNS by the System Manager.

The System Manager manages Managed Components, namely Data Serversand DPMSs. The System Manager provides administrators with an overall view

of the system and enables them to control each Managed Component. This over-

all 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 Compo-

nents and the System Manager using a standard network management protocol.

A System Managers control over components is supported in the areas of con-

guration, fault, performance, security, and accounting management. The Sys-tem Manager administers data transfer, data processing, and security information

used by Data Servers and DPMSs to perform their functions. In addition, the Sys-

tem 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 pri-

mary 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 func-

tioning of a system component. The core functions of a Data Server are commu-

nications with other components, le transfer scheduling, and le management.

Special ized processing modules are the software providing processing


8/24


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

beyond the basic operation of a system component. Although specialized pro-

cessing modules are not necessary for the basic operation of a Data Server, theymay be necessary for supporting a particular type of Generating System (e.g., a

module that provides data aggregation for broadband switching systems may be

desirable).

Support function modules perform the tasks needed to ensure proper opera-

tion of a system component. Support functions for a Data Server include admin-

istrative and maintenance activities.

Figure 3 illustrates the internal elements and interfaces providing the pri-

mary capabilities of a DPMS. The arrows in Fig. 3 indicate the direction ofthe main ow of data across the interfaces. The core function modules of a

DPMS perform the basic component tasks. The modules support communica-

tions with other components, le transfer scheduling, le management, (option-

ally) database management, (optionally) data request processing, and archiving.

Although specialized processing modules are not necessary for the basic opera-

tion of a DPMS, they may be necessary for supporting particular types of Gen-

erating Systems and Applications (e.g., a module that provides correlation of

multiple AMA records generated for the same call may be desired to sup-

port 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/ DPMSInterface. The transfer may be initiated by either system component. Transfer ini-

tiation by the DPMS is based on user-settable time schedules, time periods, vol-

ume of AMA data available, and manual requests. AMA data, either in the form


9/24


Fig. 3. DPMS logical / functional architecture.

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 Applicationcan directly request an already-created AMA le or, if supported, specic 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 AMA les. A

Tape Format AMA le is composed of AM A records organized into the format

used for AMA records placed on a 9-track magnetic tape. A DPMS sends Tape

Format AMA les to billing system Applications, and Standard AMA les to

all other Applications.

Several interfaces are employed for the management of a DPMS. The Sys-tem Manager/ DPMS Interface is used by a DPMS to receive conguration, 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 notication 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 conguration,

performance, fault, security, and accounting management.

System Manager employ nonvolatile mass storage for maintaining a man-


10/24


Fig. 4 . System manager logical / functional architecture.

agement database and management les. The management database holds man-

agement data collected from Managed Components and facilitates the composi-

tion of management reports. Management les are those les created, accessed,

modied, or distributed by Management Applications (e.g., program les sent

to Managed Components). The System Manager/ Managed Component Interfaceenables 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 coor-

dination 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 accom-

modates growth in the number of Managed Components and facilitates system

management. The user interface provides the means for a human user (e.g., sys-

tem administrator) to locally access the System Manager. A user views infor-

mation and controls Managed Components via the user interface. The interface

is characterized by a multi-window environment that enables a user to simulta-neously view management information for multiple Managed Components and

easily switch between control of one component and control of another com-

ponent. In addition, the user interface is highly graphical so that the control of

system components can be effectively performed using visual images.

5. SYSTEM INTERFACES

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 han-

dle on-demand data requests made by Applications. In addition, the Simple

Network Management Protocol (SNMP) [6] supports management of the over-


11/24


Fig. 5 . Potential system interface congurations.

all AMADNS, and Telnet is used for remote login capabilities. Upper Layer

protocols are not required for the Generating System/ Data Server Interface asthis interface is characterized by the one-way transfer of AMA records over

secure LANs. Figure 5 illustrates ve possible ways in which end systems for

AMADNS could be connected.

6. SYSTEM SECURITY

The security of AMA data is of paramount importance to telecommuni-

cations 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 AMAles and other communications, protecting the data becomes more difcult.

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 against unauthorized access and sabotage: identication, authentica-

tion, resource access control, data and system integrity, continuity of service,

and auditing. The security mechanisms specic 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. Identication 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 sufcient to

gain access to the component. However, for remote access via FTP, Telnet, and


12/24


RDA, additional capabilities are supported to counter network security threats.

An encryption procedure is used for these protocols to help ensure that a pass-

word sent across a network is not recorded by an eavesdropper and used at a

subsequent time. However, for remote access via SNMP, an unencrypted pass-

word, 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 detec-

tion, originator identication, and data update validation provide the necessary

level of data integrity in most cases.

7. THE DATA SERVER

The Data Server is the system component associated with one or more Gen-

erating Systems that provides AMA 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 associatedwith the Generating System/ Data Server Interface are not applicable. Internaland 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 pre-

dened time schedule, a pre-dened volume of AMA data received, or a manual

request. The major functions of a Data Server are:

Receiving AMA records from associated Generating Systems.

Performing necessary processing on AMA 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 process-

ing modules, support function modules, and mass storage, each of which are


13/24


described throughout this section. A Data Server is accessed through the fol-

lowing interfaces:

The Generating System/ Data Server Interface (GDI)enables an exter-

nal Data Server to receive AMA records from the Generating System(s)it serves.

The Data Server/ DPMS Interface (DDI) enables a Data Server to transferStandard AMA les to DPMSs over a network.

The System Manager / Data Server Interface enables a Data Server tocommunicate management information with the System Manager. This

interface provides remote access to the Data Server for control and moni-

toring 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 conguration parameters, and

locating and repairing faults.

The alarm interface provides a means for local trouble notication.

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 dataData generated by a Generating System. AMA data are

received from the Generating System(s) a Data Server serves in the formof AMA records. Received AMA records are grouped into Standard AMA

les and transferred to a DPMS. Some particular AMA records may be

grouped in error les.

Operations dataData required for day-to-day operations and compo-

nent management. Some operations data are accessible in the form of

les, and others may be obtained as individual units of data as identied

by the Data Servers Management Information Base (MIB), which con-

tains information about the management data maintained by a Data Serverthat 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.

AMA records are received from one or more Generating Systems. These records

may be processed by various specialized processing modules. For a Data Server,


14/24


F ig. 6. Typical AMA data processing ow.

specialized processing modules may include distribution, format conversion, val-

idation, surveillance, aggregation, and correlation. As shown in Fig. 6, the out-

put of the specialized processing modules are AMA les ready for transfer to a

DPMS. In addition, erroneous records detected by a Data Server are collectedin error les.

It is expected that each telecommunications company will dene its own

specialized processing modules to be used. These specialized processing mod-

ules may be written by the telecommunications company, the Data Server sup-

plier, or a third-party supplier. Therefore, it is essential that the Data Server facili-

tate 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 inter-

face, and programming language(s). In order to support portability, these ele-

ments 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-


15/24


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 transferAMA 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 sufciently 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 end-

to-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 com-

pany 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

difcult 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

AMA 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

AMA 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 associatedData 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 trans-

fer 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 Gen-

erating Systems, packets from different Generating Systems could traverse the

two LANs to arrive at the Data Server. Generating Systems might use differ-

ent LANs for performance reasons or because the failure of one of a Generat-


16/24


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 Gener-

ating System is expected to send AMA 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 AMA records

across the interface will occur. To most efciently 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 AMADNS, although BAF is expected to be used by most Generating

Systems. One or more AMA records are contained in each packet. To simplify

the Generating Systems role related to the GDI, an AMA record is not required

to be placed entirely in a single Ethernet packet (called aframe). Hence, an AMA

record may be split across two (or more) consecutive frames. It is assumed that

all AMA records are delimited such that contiguous records are distinguishable.

Therefore, a delimiter is not needed to separate AMA records transferred in thesame data packet. The headers and trailers added to the data packet are used to

control the transfer of AMA records as dened by the corresponding protocols.

AMA records are exchanged between GDI Application Programs running

at a Generating System and Data Server. AMA 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 Servers GDI Application Program interprets the contents of the data eld

of received TCP segments as AMA records. Since the GDI is intended to beas simple as possible, the GDI Application Programs residing at a Generating

System and Data Server do not exchange application-specic messages to con-

trol 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 available to a

DPMS all AMA 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 specic date


17/24


and time is reached, or when a time period expires. In addition, a le trans-

fer may be triggered when the volume ofprimary AMA data available to be

transferred reaches a pre-dened 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 AMA records

are received from a Generating System (either via an internal interface for inter-

nal Data Servers or via the GDI for external Data Servers), they are processed

and stored in Standard AMA les. During data processing, one of the afore-

mentioned events may occur to trigger the transfer of a Standard AMA le. A

scheduler controls the initiation of le transfers based on triggers. Upon receiv-

ing 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 AMA 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 . AMA le transfer processing.


18/24


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 equip-

ment failure, a transmission bus failure, or a performance degradation problem,

requires the sending of notication to appropriate personnel. Such notications

are performed by a Data Server by issuing alarms over the local alarm interface

and traps over the System Manager / Managed Component Interface. A criticalalarm is generated by the Data Server in these cases since the subsequent failure

of the properly operating transmission bus or local LAN communications equip-

ment would prevent the transfer of AMA data between a Generating System(s)

and the associated Data Server.

8. THE DATA PROCESSING AND MANAGEMENT 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 initi-

ating the data transfer or responding to a request. The DPMS receives AMA data

in Standard AMA les from the Data Servers it serves, processes the data, andstores them in mass storage in three forms: Tape Format AMA les for subse-

quent transfer to an invoice processing Application at a billing system, Standard

AMA les for subsequent transfer to Applications (other than the invoice process-

ing 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 AMA data according to the needs of Applications and gener-ating les destined for Applications

Storing AMA data for a certain period of time until the data are transferred

to Applications

Sending Tape Format AMA 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 AMAdata from Applications

Archiving AMA data.

Figure 3 shows the logical architecture of a DPMS. It consists of core func-

tion 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:


19/24


Data Server/ DPMS Interface (DDI)enables a DPMS to receive Stan-dard AMA les from the Data Servers it serves.

DPMS/ Application Interface(DAI)enables a DPMS to transfer les toApplications and receive on-demand requests from Applications.

System Manager/ DPMS Interfaceenables a DPMS to communicatemanagement 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 interfaceprovides operation and administration personnel

with local access to a DPMS for control and monitoring functions through

the use of input

/output messages.

Maintenance interfaceprovides maintenance personnel with local

access to information within a DPMS which may be used for monitor-

ing component status and alarms, controlling user-settable conguration

parameters, and locating and repairing troubles.

Alarm interfaceprovides a means for local trouble notication.

Removable media interfaceallows 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 AMAT.

Figure 6 illustrates the typical AMA data processing ow for a DPMS.

Standard AMA les are received from Data Servers. The AMA records con-

tained 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, AMA data processed by the various special-

ized processing modules may be stored in mass storage and then transferred toApplications at a later time, or the data may be sent to Applications in Tape

Format AMA les and Standard AMA les before being sent to mass storage.

These data are placed in Tape Format AMA les, Standard AMA les, and,

optionally, the AMA Database in mass storage. Figure 7 also shows two core

function modules, optional archiving and data request processing, used for out-

putting 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 specic AMA data requested by Applications and the AMADatabase, if installed.

AMA data received in Standard AMA 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. AMA data

stored in the AMA Database can be used for the following purposes:

Supporting on-demand requests for dataThe AMA Database supports


20/24


on-demand database queries for specic AMA data. Applications that do

not process AMA data on a regular basis can use database queries to

search the AMA Database for particular information

Constructing les containing AMA dataA 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 AMA Database and possibly use applicable

specialized processing modules to generate Tape Format AMA or Stan-

dard AMA les.

ArchivingAfter AMA data have been processed for most Applications,

the telecommunications company may have to retain the data for a rela-

tively 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 special-

ized data processing and accessible to Applications.

9. THE SYSTEM MANAGER

A DPMS is expected to receive most of its management control from a Sys-

tem Manager. A DPMS, which is a Managed Component from a system manage-

ment 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 dened 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 man-agement functions. Most of a System Managers 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 denes the management data, the values of the manage-

ment 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 specic managed objects in

the DPMSs MIB, receive responses to these requests, receive traps from the


21/24


DPMS, and update the values of the managed objects composing the DPMSs

MIB.

The System Manager is the system component that manages the overall

AMA Data Networking System. It provides administrators with an overall view

of the system and allows administrators to monitor and control each system com-

ponent. 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:

Conguration managementA System Manager can read and update

Data Server and DPMS management information to recongure the sys-

tem. A System Manager also enables remote provisioning of Data Servers

and DPMSs, including remote program loading.

Performance managementBy collecting information from Data Servers

and DPMSs, a System Manager can generate statistics to identify perfor-

mance problems.

Fault managem entA System Manager receives trouble notications

generated by the Managed Components so that events that cause faults

can be correlated to facilitate fault detection, diagnostics, and automated

correction.

Security managementA System Manager centralizes the administration

of login IDs, passwords, encryption keys, and access control information. Accounting managem entBy collecting information from DPMSs reect-

ing 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 Appli-

cation 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 logi-

cal architecture, which consists of Management Applications, mass storage, and

System Manager interfaces.


22/24


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 third-

party independent software suppliers. The creation of Management Applica-

tions is facilitated by the System Managers 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 Component Interfaceenables a System

Manager to exchange management information with the system compo-nents that it manages.

User interfaceprovides the means for a human user (e.g., system admin-

istrator) to locally access the System Manager. This interface is intended

to provide a user-friendly presentation.

System Manager / System Manager Interfaceenables coordination be-tween multiple System Managers. This interface, which is optional, pro-

vides the means by which the controlling and monitoring functions of

network management can be distributed among multiple management sta-

tions. 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 Managers management of a Data Server is via SNMP,

which is a message-based protocol designed to support network management.

The management framework adopted for AMADNS is based on the Internet-

standard network management framework, which consists of three basic con-cepts: 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 denes 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.


23/24


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 denes 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 SNMP-

based notications sent by Managed Components to the System Manager(s) to

indicate the occurrence of an unusual event (e.g., hardware failure). The System

Managers 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

specic 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 authenti-

cate the sender. As explained earlier, PDUs are used to accomplish the exchange

of management data between SNMP Agents and SNMP Managers. PDUs spec-

ied 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 AMADNS 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. Thesegoals 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-


24/24


tems. While processing more and more messaging data, AMADNS requires that

the messaging data be available in near-real-time.

REFERENCES

1. Bellcore Staff, Bellcore Generic Requirements for the Automatic Message Accounting Data Net-

working System (AMADNS), Issue 1, Bellcore Document GR-1343-COR E, Bellcore.

2. Lee E. Heindel, Helen L. Hogan, and Vincent A. Kasten, Automatic Message Accounting Data

Networking System (AM ADNS), The Year in Telecommunications 1995 19 96, International

Engineering Consortium, January, 19 95.

3. International Standards Organization, ISO / TC97, Information Processing Systems, Open SystemsInterconnection-Basic Reference Model, Draft International Standard ISO/ DIS 7498, April 1982.

4 . Gary R. M cLain, Open Systems Interconnect ion Handbook, McGraw-Hill Communications

Series, 1991.

5. OSN Protocol Transition Guide , Bellcore Special Report SR-STS-00152 2, Issue 1, November

1990.

6. William Stallings, SNMP, SNM Pv2, and CMIP, The P ractical Guide to Network-M anagement

Standards , Addison-Wesley, 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 theUniversity of Wisconsin-Madison in Computer Sciences. He is the co-author of the book, Lang-

Pakan Interactive Language System and is writing a book on Enterprise Management Systems.

Dr. Heindel is the author of over 35 papers on technology and management 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 Pacic

Bell. Helens career has focused on software and standards development for telephony b illing and

customer care. Helen has signicant expertise in Electronic Data Interchange (EDI) and has been

instrumental in the development of Bellcores AMA Data Network ing System (AMADNS) product.

Helen received her Bachelor of Arts degree from California State University and completed her

Masters Certicate for Project M anagement in June, 1996.

Vincent A. Kasten recently left Bellcore, where he was a Director, to form his own company.

Mr. Kasten received h is M.S. in Computer Science from Columbia University in 1979 and has much

experience in Open Systems includin g development, system internals, and is an acknowledged expert

on UNIX system performance.

introduction to the automatic message accounting data network system

Documents