Table of Contents

Billing System Architecture

CDR Record Format

Billing Tools

Billing Architecture
and Call Detail Records

The BPX Service Node includes a billing system architecture designed to collect and generate point-to-point SVC billing information which can be used by service providers as the basis for billing end customers. The billing architecture is designed to collect billing information in Call Detail Records (CDRs).

This billing system architecture addresses the following requirements:

1. Records point-to-point SVC billing data to support the formatting and segmentation of the data into Bulk Data Format (BFD) and Bellcore Automatic Message Accounting Format (BAF). This includes support for long duration calls, short duration calls, and unsuccessful call attempts.

2. Collection of the following data:

• Broadband bearer capability

• Quality of Service parameter (that is both forward and backward QoS)

• Origination and destination addresses (calling party number and called party number)

• Release and Release-complete cause values

• Cell counts (forward and backward CLP=0 and CLP=0+1)

• Frame counts (forward and backward DE=0 and DE=0+1)

• Connect time (for a successful call, this is the time when the CONNECT/CONNECT_ACK message is sent/received; for an unsuccessful call, this is the time when the RELEASE message is sent/received)

• Elapsed time (Time interval between receiving CONNECT message and RELEASE message with 1/10 seconds of timing resolution.)

• Study indicator

• Node ID, shelf number, slot number, port number, VPI/VCI (or DLCI) of the UNI interface

3. Make billing data available to an external Data Server (DS) within 2 minutes after the file collection interval.

4. Record cell/frame counts on a per rate period basis (rater periods are service provider configured parameters.) There can be a maximum of 6 different rates scheduled on a weekly basis and 4 different rates on a daily basis. (Rate periods must be provided by the external Data Server.)

5. Prevent the loss of billing date (including cell/frame counts) which are more than 15 minutes old.

6. Configure billing parameters on a per-BPX Service Node basis and on a per-UNI port basis.

7. Support the provisioning of BPX Service Node timezone, tracer (audit) records, and default billing number. (In this release, timezone and tracer [audit] records must be provided by the external Data Server.)

8. Disable/Enable SVC billing feature on a per-UNI port basis and on a per-BPX Service Node base. (A future release will provide the ability to disable/enable SVC billing on a per-Data Server basis, also.)

The SVC Billing feature allows AMS functionality to be supported by BPX Service Node networks. The concept of SVC billing is to collect billing information a per-call basis, correlated them into a single AMA record, and transport the AMA record to the Service Provider Billing System.

SVC Billing requires two types of billing information:

• Call parameters, including time information

• Cell and frame counts

The BPX BXM and the AXIS ASC record the cell and frame counts at the connect delete time, and at pre-defined bucket intervals. In both cases these records are stored in the ESP as CDR files. Each call record is tagged with a 32-bit CDR number given by the ESP at call setup time. This CDR number is used as a key to correlate the different records generated during the call.

Billing System Architecture

To meet the billing system requirements, the billing system architecture is divided into several functions performed by different units of a BPX Service Node, plus several external systems, as shown in Figure C-1. This billing system architecture requires four major elements to operate:

• The BPX Service Node: ESP, BPX and AXIS

• The StrataView Plus Workstation

• The Data Server

• The Service Provider Billing System

Note that the Data Server and the Service Provider Billing System are not provided by Cisco StrataCom.

The logical flow of Figure C-1 follows the sequence indicated by the arrows:

1. The StrataView Plus Workstation interfaces with the Data Server to administrate billing parameters.

2. The StrataView Plus Workstation accesses the ESP (via Telnet) to configure per-UNI port billing parameters.

3. The ESP interfaces to the BPX/s BXM cards via the Comm Bus/ATM.

4. The ESP interfaces to the AXIS ASC via SNMP.

5. The AXIS AUSM cards deliver cell counts to the ASC.

6. The AXIS FRSM cards deliver frame counts to the ASC.

7. The AXIS ASC writes the cell and frame counts to the ESP via NFS over the Ethernet LAN.

8. The BPX BXM deposits cell counts into the ESP via NFS (that is, the Network File System, a commonly-used UNIX distributed file system) over the BXM management VCC.

9. The ESP Call Detail Record (CDR) function records call start and end information into the ESP files.

10. The Data Server retrieves CDR files via FTP (or IP over ATM if available) over the Ethernet LAN. (Since each Data Server can supports more than one ESP, it may be connected to the ESP LAN via routers.) The CDR files are stored in the /Billings directory on the ESP.

11. The Data Server delivers AMS formatted data to the Billing System.

12. The Data Server telnets into the ESP to synchronize the two components.

CDR Record Format

There are 8 record formats which the Data Server should be aware of:

• ESP Header record format, defined in Table C-1

• ESP Start record format, defined in Table C-1

• ESP End record format, defined in Table C-3

• ESP Trailer record format, defined in Table C-4

• BXM Header record format, defined in Table C-5

• Cell Count record format, defined in Table C-6

• AXIS Header record format, defined in Table C-7

• Frame Count record format, defined in Table C-8

Tables C-1 through C-8 define these record formats. Each table lists the number of bytes (length of the field), the name of the field, the data format (character or binary), and a description of the field.

Billing Tools

The BPX Service Node stores the billing records as binary files in the Billings directory. A typical Billings directory is shown in the following example:

The ellipses (...) in the figure indicate that some CDR records have been removed to condense the file for illustration purposes.

As shown in the sample Billings directory, there are basically three types of CDR files:

• cdr_start.*

• cdr_end.*

• cdr_xx.* (where xx is a number) When xx is 14 or less it is a BXM file, thus cdr_13.01.9706021200 is a BXM CDR file. When xx is 15 or greater it is a AXIS file; thus cdr_15.01.9706022215 is an AXIS file. The .01 following the cdr_13 or cdr_15 is control number and will have a value of 01, 02, 03, or 04.

The last 10 digits of every file name is the date and time stamp. For instance, 9706021200 is 1997, June 2nd at 1200 O'clock noon. Files with the extension .00 are for the current collection interval. At the end of the collection interval, they will be closed and saved without the extension.

These CDR files are in binary format and can be converted to flat file (ASCII format), which can be more easily interpreted, with the following tools:

• DispStartFile

• DispEndFile

• DispBxmFile

• DispAxisFile

Currently these read files are used to convert the CDR format to screen output, as will be illustrated in the following examples.

These tools are stored in the opt/aps/tools directory on the ESP.

To read a start file, follow these steps:

Step 2   Change directory to the /opt/aps/tools directory.

Step 3   Run DispStartFile using CDR file name as the argument as follows:

apslab5)/opt/aps/tools %> DispStartFile /Billings/cdr_start.04.9706130745 | more

Note that the pipe (| more) directs the output to the screen. The following example illustrates the output of a typical DispStartFile:

The file header is defined in Table C-1, where Record Type is H, followed by date and time, and the Node ID. The body of the file is defined in Table C-1. The fields are arranged in columns, which read from left to right, separated by spaces. Each entry takes 2 lines. As defined in Table C-2, the first field, Rec is Record Type = 1 start record; OT is Origination/Termination, where for instance 3 = ATM originating cell counts; SLN is slot number...and so on until you get to the second line where CgN is the 20-byte Calling Number field, and CdN is the 20-byte Called Number field.

Step 4   Next run DispBxmFile using the CDR file name as the argument as follows:

(apslab1)/opt/aps/tools %> DispBxmFile /Billings/cdr_13.9706131530.00 | more

Note that the pipe (| more) directs the output to the screen. The following example illustrates the output of a typical DispBxmFile:

The body of the file is defined in Table C-6. The fields are arranged in columns, which read from left to right, separated by spaces. The first field is Rec, which will be 5 for Intermediate Cell Counts or 6 for Final Cell Counts. The Tag is the CDR number used to correlate this to start/end records. The next four fields are: btcc (backward total cell count), bhcs (backward high priority cell count), ftcc (Forward total cell count), and fhccc (Forward high priority cell count).

Step 5   Next run DispAxisFile using the CDR file name as the argument:

(apslab5)/opt/aps/tools %> DispAxisFile /Billings/cdr_15.04.9706130745 | more

Note that | more pipes the output to the screen and will provide display an AXIS CDR record similar to the following example:

The AXIS CDR are used for both AUSM cell counts and FRSM frame counts. A cell count record includes the Rec (Record Type 5 for Intermediate, 6 for final, cell counts) the Tag (CDR number) and btcc (backward total cell count), bhcc (backward high priority cell counts), ftcc (forward total cell counts), and fhcc (forward high priority cell counts). The cell count record format is defined in Table C-6. A frame count record includes the Rec, tag, rtfc (receive total frame count), rde0 (receive DE=0 frame count), ttfc (transmit total frame count), tde0 (transmit DE=0 frame count), rtbc (receive total byte count), rde0 (receive DE=0 byte count, ttbc (transmit total byte count), tde0 (transmit DE=0 byte count); the frame count record format is defined in Table C-8.

Step 6   Next run DispEndFile using the CDR file name as the argument:

(apslab5)/opt/aps/tools %> DispEndFile /Billings/cdr_end.04.9706130745| more

Note that | more directs the output to the screen and will display an End CDR similar to the following example:

The End File format is defined in Table C-3. The Record Type H is the header. The next line Rec, Tag, Sec...is the actual End Record.

Posted: Fri Jan 19 20:24:25 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.