Telcordia Notes on Billing

Transcription

1 Telcordia Notes on Billing Call Detail Recording and Usage Measurements in Local Exchange Networks Telcordia Technologies Special Report SR-NOTES-SERIES-08 Issue 1, May 2001 An SAIC Company

2 Notes on Billing Issue 1, May 2001 Copyright Page Telcordia Notes on Billing Prepared for Telcordia Technologies by: Professional Services Related documents: SR-2275 and the Telcordia SR-NOTES-SERIES Technical contact: William Krall To obtain copies of this document, contact your company s document coordinator or your Telcordia account manager, or call (from the USA and Canada) or (Worldwide), or visit our Web site at Telcordia employees should call Copyright 2001 Telcordia Technologies, Inc. All rights reserved. Trademark Acknowledgments Telcordia is a trademark of Telcordia Technologies, Inc. AXESS and CLASS are service marks of Telcordia Technologies, Inc. Any other companies and products not mentioned herein are trademarks or service marks of their respective trademark and service mark owners. ii

3 Issue 1, May 2001 Notes on Billing Special Report Notice Of Disclaimer Special Report Notice Of Disclaimer This Special Report (SR) is published by Telcordia Technologies to inform the industry of Telcordia Notes on Billing with special emphasis on Call Detail Recording and Usage Measurements in Local Exchange Networks. Telcordia reserves the right to revise this document for any reason (consistent with applicable provisions of the Telecommunications Act of 1996 (TA96) and applicable Federal Communications Commission (FCC) rules). Telcordia specifically advises the reader that this SR does not directly or indirectly address any Year-2000 ( Y2K ) issues that might be raised by the services, systems, equipment, specifications, descriptions, or interfaces addressed or referred to herein. As an example, and not a limitation, neither this SR nor Telcordia is directly or indirectly assessing or determining whether specific services, systems, or equipment, individually or together, in their current form or as they may be implemented, modified, or augmented in the future, will accurately process dates and date-related data within or between the twentieth and twenty-first centuries, in either direction, including elapsed time, time difference, and/or leap year calculations. TELCORDIA MAKES NO REPRESENTATION OR WARRANTY, EXPRESSED OR IMPLIED, WITH RESPECT TO THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN. TELCORDIA EXPRESSLY ADVISES THAT ANY USE OF OR RELIANCE UPON SAID INFORMATION OR OPINION IS AT THE RISK OF THE USER AND THAT TELCORDIA SHALL NOT BE LIABLE FOR ANY DAMAGE OR INJURY INCURRED BY ANY PERSON ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN. This SR is not to be construed as a suggestion to anyone to modify or change any product or service, nor does this SR represent any commitment by anyone, including but not limited to Telcordia, to purchase, manufacture, or sell any product with the described characteristics. Readers are specifically advised that any entity may have needs, specifications, or requirements different from the generic descriptions herein. Therefore, anyone wishing to know any entity s needs, specifications, or requirements should communicate directly with that entity. Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent, whether or not the use of any information herein necessarily employs an invention of any existing or later issued patent. TELCORDIA DOES NOT HEREBY RECOMMEND, APPROVE, CERTIFY, WARRANT, GUARANTEE, OR ENDORSE ANY PRODUCTS, PROCESSES, OR SERVICES, AND NOTHING CONTAINED HEREIN IS INTENDED OR SHOULD BE UNDERSTOOD AS ANY SUCH RECOMMENDATION, iii

4 Notes on Billing Issue 1, May 2001 Special Report Notice Of Disclaimer APPROVAL, CERTIFICATION, WARRANTY, GUARANTY, OR ENDORSEMENT TO ANYONE. If further information regarding technical content is required, please contact: William H. Krall 331 Newman Springs Road, NVC 2X419 Red Bank, NJ (FAX) wkrall@telcordia.com For general information about this or any other Telcordia documents, please contact: Telcordia Technologies Customer Service 8 Corporate Place, Room 3A-184 Piscataway, New Jersey (USA and Canada) (Worldwide) (FAX) (on-line) iv

5 Issue 1, May 2001 Notes on Billing Contents Contents Special Report Notice Of Disclaimer iii List of Figures xi List of Tables xii Foreword xiii 1. Introduction Purpose and Scope Structure and Use of This Document Document Conventions Billing Overview Background Customer (End User) Billing End User Billing Architecture Front-End Processing Error Detection and Correction Rating Guiding and Posting Bill Period Processing Billing and Remittance Data Exchange Carrier Access Billing System (CABS) The Role of AMA in Billing Generating Usage Measurements Automatic Message Accounting (AMA) Background AMA Process Model Call-Related Terms AMA Data Generation AMA Translations Line or Trunk Attributes Directory Number and Billing Number Digits Dialed Call Disposition Long Duration Connection Services and Features LEC-Settable Office Parameters AMA Studies AMA Fundamentals for Studies AMA Data Generated for Specific Studies Complaint Observing Subscriber Line Usage Study (SLUS) Network Completion Billing AMA Format (BAF) BAF-Related Terms v

6 Notes on Billing Issue 1, May 2001 Contents Data Fields Structures Call Type Codes (CTCs) Call Type Code Precedence BAF Tables Modules Generic Modules Flexible Modules Building a BAF Record BAF Procedures for Handling Incorrect or Unusual BAF Data Flag Procedure for Missing Data or Data Fields in Error Fill Procedure for Unused Data Fields Pad Procedure BAF Administration Call Detail Recording Network Recording Points Recording Architecture Centralized AMA (CAMA) Recording for Local Service Flat Rate Service Measured Rate Service Message-Rate Call Types Message-Rate Service with Call Detail Message-Rate Service Without Call Detail Toll Calls Toll Recording - IntraLATA IntraLATA Toll Presubscription LEC as Toll Carrier Calls to N11 Codes AMA for Directory Assistance Recording for Local Interconnection Interfaces Standard Trunk Connections Feature Group D-Like Connecting Network Access (CNA) Other Interfaces Exchange Access Recording Switched Access Service Types of Switched Access Available Feature Group A (FGA) Feature Group B (FGB) FGB AMA XXXX Dialing Over FGD Trunk Groups Feature Group D (FGD) FGD Dialing FGD Recording Originating FGD AMA Records Terminating Recording vi

7 Issue 1, May 2001 Notes on Billing Contents Local Number Portability (LNP) Interaction Wireless Services Providers (WSP) Interfaces Originating WSP Calls Terminating WSP Calls Type 1 - Line-Side Interconnection Originating Type Terminating Type Type 2B - Trunk-Side Direct Interconnection Originating Type 2B Terminating Type 2B Type 2A - Trunk-Side Tandem Interconnection Originating Type 2A Terminating Type 2A WSP Interaction with Local Number Portability AMA Recording for Special Services Recording at Operator Services Systems (OSSs) Population Rules for OSS AMA BAF Modules OSS Originating AMA Originating Calls, No OLNS Query Launched Additional Modules Used with SC Originating Calls, OLNS Query Launched Additional Modules Used with SC 0772 for OLNS Queries OSS Terminating AMA Additional Modules Used with SC LEC-Settable OSS Call Type Codes (CTCs) OSS AMA Examples Line Information Database (LIDB) AMA Recording Aggregate Records LIDB Detailed AMA Toll-Free Recording Background Toll-Free Recording for IN Architecture AMA Record Generation Information Returned from SCP Generation of Structure Codes Toll-Free Recording for AIN Architecture The Pre-Query SDS Record for Toll-Free AIN Architecture The Post-Query SDS Record for Toll-Free AIN Architecture Service Access Code (SAC) Recordings SAC SAC SAC Recording for CLASS SM Services Background Privacy Local Area Signaling Services (LASS) Recording vii

8 Notes on Billing Issue 1, May 2001 Contents Background LASS AMA Advanced Intelligent Network (AIN) Recording Background AIN Conventions Originating Call Model Originating Call Model Triggers/Events Specific_Digit_String AMA AIN Event Processing Terminating Call Model Terminating Call Model Triggers/Events Message Detail Recording (MDR) MDR via the RAO MDR to Customer Premises Unified Messaging AMA Recording for Advanced Digital Services Recording for Integrated Services Digital Network (ISDN) Calls Background ISDN Bearer Capability ISDN Signaling Capability ISDN Capabilities Having No AMA ISDN Record Types ISDN Core Module Application of ISDN Modules Recording of Supplementary Services ISDN Basic Call Recording Originating ISDN Calls Terminating ISDN Calls Terminating Recording at the User Line Termination ISDN Terminating Exchange Access AMA Recording ISDN Aggregate Records The Service Event Module Summary ISDN Inverse Multiplexing Broadband Services Recording Background Usage Measurement Functions Recording for Asynchronous Transfer Mode (ATM) Calls Permanent Virtual Connection (PVC) Services Data Generation AMA Recording for Intranetwork Switched Virtual Connections (SVCs) Short Duration ATM Calls AMA Recording for Internetwork SVCs AMA for PVCs Modules Associated with ATM Recording for SMDS Intranetwork SMDS Recording viii

9 Issue 1, May 2001 Notes on Billing Contents Intranetwork SMDS Audit Records Exchange Access and Internetwork SMDS Recording BAF Tables for Internetwork SMDS Recording Frame Relay Background Usage Measurements AMA Recording for Frame Relay Module Associated with Frame Relay AMA Teleprocessing and Data Networking AMA Teleprocessing Transmitter Functional Description AMA File Structure Transport Capabilities Collector Functional Description Data Handling Administration AMA Data Networking System (AMADNS) Background System Overview AMADNS Data Architecture Dual Data Server-Collector Data Communications Interface System Manager File Structures Standard AMA Files Error Files Test Files AMA Record Flows AMA Record Flows Generating System/Data Server Interface (GDI) Specialized Processing Modules (SPMs) Format Conversion Surveillance Aggregation Correlation Validation Formatting Error Correction Expansion Reduction Developments and Future Trends Alternative Recording Capabilities Recording Capabilities of a Link Monitoring System (LMS) Generating Aggregate AMA Records Generating Call Detail Records (CDRs) Connecting Network Access (CNA) AMA ix

10 Notes on Billing Issue 1, May 2001 Contents Exchange Access Feature Group D (FGD) Interconnection Wireless Service Provider (WSP) Type 2A and 2B Interconnection Tandem Transit Traffic Interconnection Next Generation Network (NGN) Recording Background NGN Accounting Management Architecture NGN Usage Data Generation for Voice Calls Distributed Processing in Telecommunications Networks Call Detail Recording for Global Solutions Convergence of Voice and Data Services Alternative Recording Formats Internet Protocol Data Record (IPDR) Other CDR Formats BAF Limitations Next Steps in Usage Format Evolution Encapsulation Redefinition Coexistence Conclusion Appendix A: Bibliography and References A 1 Ref.1 Generic Requirements Documents (GRs) A 1 Ref.2 Special Reports (SRs) A 4 Ref.3 Technical References (TRs) A 5 Ref.4 Other References A 6 Appendix B: Glossary B 1 Appendix C: Acronyms C 1 x

11 Issue 1, May 2001 Notes on Billing List of Figures List of Figures Figure 2-1 General Billing Architecture Figure 2-2 Sample Architecture for an End User Billing System Figure 2-3 Sample Architecture for an Access Billing System Figure 3-1 AMA Process Model Figure 4-1 Typical LEC Recording Architecture for Toll Calls Figure 4-2 LEC IntraLATA Toll Network Figure 4-3 CNA Recording Example Figure 4-4 Feature Group A -- Line-side Access Service Figure 4-5 Feature Group B -- Trunk-side Access Service Figure 4-6 Feature Group D -- Trunk-side Equal Access Service Figure 4-7 Wireless Service Provider Interfaces Figure 5-1 Network Architecture for Special Services Figure 5-2 AIN Originating Basic Call Model Figure 5-3 AIN Terminating Basic Call Model Figure 6-1 Broadband Switching System Figure 6-2 BSS Functional Reference Model Figure 6-3 SMDS Usage Information Figure 6-4 PVC Frame Relay Service (FRS) Usage Information Figure 7-1 AMATPS Logical Architecture Figure 7-2 AMA File Structure - Category A Figure 7-3 AMA File Structure - Category B Figure 7-4 AMADNS Logical Architecture Figure 7-5 Dual Data Server-Collector Architecture Figure 7-6 Potential System Interface Configurations Figure 7-7 AMADNS AMA Record Flows Figure 8-1 Stand-Alone Adjunct LMS Implementation Figure 8-2 CCS Usage Measurement Process Model Figure 8-3 LMS Recording Overview Figure 8-4 LMS Recording for CNA Interconnection Figure 8-5 LMS Recording for Exchange Access Interconnection Figure 8-6 LMS Recording for WSP Interface Figure 8-7 LMS Transiting Network Architecture Figure 8-8 NGN Architecture Figure 8-9 NGN Accounting Management Components xi

12 Notes on Billing Issue 1, May 2001 List of Tables List of Tables Table 2-1 End User vs. Access Billing Comparison Table 3-1 Characteristics of BAF Data Fields Table 3-2 Call Type Code Precedence List Table 3-3 Module Flexible Length Module - Repetitive Field Table 3-4 Layouts of BAF Records Table 3-5 Flag, Fill, and Pad Procedures for BAF Data Fields Table 3-6 LEC-Assignable Ranges for BAF Elements Table 4-1 Typical Recording Architecture - Call Types and Structures Table 4-2 Common AMA Call Type Codes for Telephony Services Table 4-3 N11 Codes in the North American Numbering Plan Table 4-4 End Office AMA for Calls to Directory Assistance Table 4-5 FGA and FGB Call Type Codes and Structure Codes Table 4-6 FGD Call Type Codes and Structure Codes Table 4-7 WSP Call Type Codes Table 5-1 Originating OSS Calls - No OLNS Query Table 5-2 Additional Modules Appended to Structure Code Table 5-3 Additional Modules Used with SC Table 5-4 Terminating OSS Calls Table 5-5 Additional Modules Used with SC Table 5-6 LIDB Aggregate Records Table 5-7 AMA Recording for Usage Sensitive CLASS SM Features Table 5-8 LASS Features Table 5-9 MDR Billable Events -- BAF Structures and Modules Table 6-1 ISDN Signaling or Supplementary Service Usage Capabilities Table 6-2 ISDN Core Module Table 6-3 Recording for Supplementary Services Table 6-4 ISDN Terminating User Service Module Table 6-5 ISDN Daily Aggregate Service Event (DASE) Module Table 6-6 Recording for ISDN Signaling Capabilities Table 6-7 Recording for ISDN Supplementary Services Table 6-8 Module Codes Appended to ATM Records Table 6-9 Frame Relay Count Module Table 8-1 Applicable Data Items for SCCP and ISUP Messages Table 8-2 LMS Call Type Codes Table 8-3 LMS AMA Generation for Tandem Trunk Groups Table 8-4 Population of Originating Access Record Based on CCA Input Table 8-5 NGN Voice over Packet Structure and Call Type Codes xii

13 Issue 1, May 2001 Notes on Billing Foreword Foreword Technology Webster s New Collegiate Dictionary defines it as a technical method of achieving a practical purpose. A concise, clear definition. But for many, achieving that practical purpose can be more than just a challenge. It can be frustrating, intimidating, time-consuming, and bound to generate the question, Where Do I Start? With the Telcordia Notes on... series, Telcordia Technologies has devised a starting point for your search through the rapidly developing world of telecommunications. Written by the authors of the successful Notes on the Networks document (SR-2275), this series similarly contains technical material of interest to engineering and planning groups, as well as descriptions of the characteristics and background of these subjects in laymans terms. The difference is that Telcordia Notes on... zeroes in on one technology in each document and breaks it down into manageable terms. From the history, background, and basic elements through a discussion of what the future may bring, our subject matter experts cover the important aspects in as few words as possible. Telcordia Notes on... is a series of Special Reports (SRs) providing the Telcordia proposed view of general technical topics. It is not a generic requirements document. No part of the text constitutes or suggests a requirement on the part of any entity. Attempts have been made to ensure that information contained herein is recent and reliable. However, due to the constant evolution in technology and its associated documentation, the most current information available regarding topics of interest should be sought. For your convenience, this document contains a Bibliography that lists numerous sources for additional information on the topics presented. This list contains the related generic requirements documents published by Telcordia for the technology discussed in this document. Ordering information for these products is also included. About Telcordia Technologies Telcordia Technologies traces its history back to the divestiture of the Bell System in 1984 when the Bell Operating Companies created a company later called Bellcore that would be a center for technological expertise and innovation. The work that the employees of Telcordia have done since that time has shaped the telecommunications industry, setting a standard for performance and quality unmatched in the industry. Eighty percent of the United States telecommunications network depends on software invented, developed, implemented, or maintained by us. We hold hundreds of patents, including key patents for broadband data communications technologies such as ADSL, AIN, ATM, ISDN, Frame Relay, SMDS, SONET, DWDM, and video-ondemand. We currently keep more than 100 million lines of code maintained and running efficiently, through more than 150 operations support systems. Our Capability xiii

14 Notes on Billing Issue 1, May 2001 Foreword Maturity Model Level 5 assessment for software quality leads the industry; our ISO 9001 registration also demonstrates our insistence on quality. We share our expertise with others, through training and consulting. As the leading consultants to the telecommunications industry, we offer a broad range of expertise, including systems integration, local number portability, unbundling and interconnection, network integrity and reliability, fraud management, and pricing and cost analysis. We are the world s largest provider of telecommunications training services; each year we train more than 30,000 students from 1,300 companies. Companies and individuals come to us because we understand their businesses. We not only know how to build networks, but also how to optimize those networks for the greatest strategic efficiency and accuracy. And we help our customers transition into the next generation of telecommunications services and equipment. In 1997, Science Applications International Corporation (SAIC), one of the world s largest providers of systems integration and program management, acquired Bellcore and changed our name to Telcordia Technologies. Our new name signals our new status. Our business strategy continues to focus on helping our customers evolve from the current to the next generation of communications technologies. The Telcordia Technologies theme line, Performance from Experience, serves as a reminder of our enormous depth of experience and talent, and our established track record for delivering an exceptional standard of quality. As Telcordia Technologies, we can provide our traditionally high standard of service and innovation to an even wider range of customers. We help our customers anticipate how their businesses will evolve, and we give them the tools to meet the competitive challenge. In fact, our new name emphasizes the accord we have with our customers and strategic partners. We ve demonstrated our ability to achieve accord in complex situations, to keep systems and companies working together efficiently and effectively, and to optimize our customers networks and their businesses. Look for the Telcordia banner; it s a consistent symbol representing our competitive spirit and teamwork as we move forward toward our goals. We know the path to the future. We ve been leading the way there for a long, long time. For more information about Telcordia Technologies, contact your local account executive or call: (USA and Canada) or (Worldwide). xiv

15 Issue 1, May 2001 Notes on Billing Introduction 1 Introduction A chief characteristic of telephony billing in the United States today is that local service providers, long distance carriers, and wireless carriers all provide some level of call detail information for the calls made by their customers on their monthly bills. This Telcordia Special Report (SR) describes, in general terms, how the usage measurements that capture call detail information are generated in circuit switches and other measurement points throughout the Local Exchange portion of the Public Switched Telephone Network (PSTN) in the United States. The process of generating usage measurements in a switching system or other network node is called Automatic Message Accounting (AMA). Telcordia AMA engineers over the years have developed an extensive number of generic requirements documents that serve as the basis for generating AMA in the local switches and tandems of the PSTN. These engineers have now teamed to develop a high-level view of the entire AMA process using the latest information available. This SR will cover the basics, including AMA recording and formatting technologies, the process of generating service-specific AMA recordings, AMA transport to the billing system, and future trends in recording in the Next Generation Network (NGN). 1.1 Purpose and Scope This document contains material of interest to organizational groups responsible for overseeing the generation of usage measurements at recording points in the local exchange network as well as those groups responsible for the collection, transport, and processing of usage measurements as they make their way into the systems that produce customer bills. The material is covered in layman s terms wherever possible. The goal of Telcordia is to bring a reader with little or no prior experience in usage measurements and AMA quickly up to speed in these areas. The subject matter does, however, have some inherent technical complexities that reach beyond the scope of this overview document. Consequently, where detailed technical descriptions are appropriate, a reference will be provided to the appropriate generic requirements document or other reference material. 1 1

16 Notes on Billing Issue 1, May 2001 Introduction 1.2 Structure and Use of This Document This document is organized as follows: Section 2 provides a brief overview of a typical landline telephony billing architecture for local exchange networks, from the establishment of a customer account, through the generation of usage measurements for calls made by a customer, to the rendering of the customer s bill. Section 3 describes the underlying components and technologies used to generate usage measurements in domestic wireline networks, including an overview of Billing AMA Format (BAF), the most widely used format for the generation of usage measurements, and how it is administered. Section 4 provides a comprehensive overview of the switch-based call detail recordings for local service, toll service, and network interconnection, including both exchange access and Connecting Network Access (CNA) recordings. Section 5 provides a description of recording for services calls, specifically calls to an Operator Services System (OSS), toll-free service, and calls dialed to a Service Access Code (SAC). In addition, this section will also cover services invoked either by the end user s terminal equipment such as CLASS SM services, or programmed at the switch itself such as Advanced Intelligent Network (AIN) services. It also describes AMA records generated by the Line Information Database (LIDB). Section 6 provides an overview of usage measurements for advanced digital services, specifically, Integrated Services Digital Network (ISDN) for traditional circuit switches and Asynchronous Transfer Mode (ATM), Switched Multi-Megabit Data Service (SMDS), and Frame Relay service for broadband communications technologies. Section 7 provides an overview of the AMA Teleprocessing System (AMATPS) and AMA Data Networking System (AMADNS). This functionality has become more critical as the AMA volumes have grown as a result of the increase in the number and complexity of usage-based services. Section 8 provides an update on current developments related to Call Detail Recording (CDR), including alternative recording capabilities and alternative recording formats. This section also provides an examination of recording requirements, capabilities, and challenges for the Next Generation Network (NGN) and concludes with some comments on the future of usage-based services. Appendix A is the References and Bibliography section. Appendix B is a Glossary with definitions of technical terms. Appendix C is an Acronym list for this document. Covering the areas listed above is no small task, but Telcordia Technologies, as a leading source of AMA Generic Requirements documents, has a unique legacy of 1 2

17 Issue 1, May 2001 Notes on Billing Introduction expertise in this field. The most experienced experts in AMA generic requirements, teleprocessing/data networking, testing, and usage processing have authored this document. What the reader has, therefore, in this Notes on... document, is a firsthand description of how call detail recording and usage measurements are accomplished by local exchange carriers in the U.S. domestic network. 1.3 Document Conventions Words or terms in color are linked to the Glossary where they are defined in detail. 1 3

18 Notes on Billing Issue 1, May 2001 Introduction 1 4

19 Issue 1, May 2001 Notes on Billing Billing Overview 2 Billing Overview This section provides a brief overview of a typical landline telephony billing architecture for local exchange networks, from the establishment of a customer account, through the generation of usage measurements for calls made by a customer, to the rendering of the customer s bill. 2.1 Background Telecommunications carriers in the U.S. render nearly one billion telephone bills on an annual basis. The scope of the bill preparation is a massive undertaking by each individual Local Exchange Carrier (LEC). Network Operations Remittance $$ Paper Bills Recording Points - End Offices - Tandem - Operator Services - SCPs (Databases) - Broadband Switches Billing AMA Format Billing Mediation AMATPS/ AMADNS End User Billing System (e.g., CRIS) - Account Establishment - Account Maintenance - Usage Processing and Rating - Bill Printing - Remittance Processing - Data Exchange EDI Electronic Media Business Operations Provisioning Process ASR/LSR Work Order Service Order Process Completed Service Orders Access Billing System (e.g., CABS) EMI Data Exchange with other carriers CABS/BOS BILLS to Carriers REPORTS Customer Interface BSC / RSC / ACSC BILLING SYSTEM Figure 2-1 General Billing Architecture Three basic components of a typical telephone company are illustrated in the general billing architecture in Figure 2-1. The business operations component and 2 1

20 Notes on Billing Issue 1, May 2001 Billing Overview the network component provide the information necessary for the billing component to render a bill, process the remittance, and account for the revenue. The business operations component is principally responsible for customer contact. This involves accepting orders for service via an Access Service Request (ASR) or a Local Service Request (LSR) from a customer, communicating the customer s requirements to the provisioning process via a work order of some type, confirming that a customer s service is working as it should, and notifying the billing system that this customer is to receive a bill. There are many hundreds of functions that need to take place in the ordering and provisioning process, but when everything is completed, and the service is working, a completed service order is provided to the billing system which establishes the customer s account and allows billing to proceed. Establishing the customer s account is the most basic and important function of the billing system. Once the account is established, a recurring charge will be billed each month for those services ordered, e.g., basic local service. In addition to the recurring charges there are usage-sensitive charges, e.g., local and long distance telephone calls, that must appear on the bill each month. The responsibility for measuring all of the calls that customers make from all of the recording points in the network falls to Network Operations. The process by which all of these calls are measured is called Automatic Message Accounting (AMA). AMA is recorded, in most instances, in Billing AMA Format (BAF) and transported to the billing system using either an AMA Teleprocessing System (AMATPS) or an AMA Data Networking System (AMADNS). LECs generate two categories of bills from two different billing systems. A retail end user customer subscribing to the LEC s services and features is billed monthly from the Customer Record Information System (CRIS). A wholesale Interexchange Carrier (IC) or International Carrier (INC) interconnected to the LEC is billed from the Carrier Access Billing System (CABS). CRIS and CABS are generic terms used to describe specific types of billing systems. There are currently many system types that are based on the CRIS and CABS general functionality, but they have different names. The names of the billing systems may differ, but they all perform basically the same functions. 2.2 Customer (End User) Billing Service orders are the vehicle used to establish a customer account in most billing systems. Residence or business customers contacting the Business Office to establish new service, or to change existing service, initiate the service order. Basic types of service orders are new connects (establishes new service), change orders (adds, removes, or changes service type or features), disconnects (disconnects existing service), and To and From orders (customer moves geographically within the service area of the same central office). Upon entry, these service orders flow mechanically from the service order system and provide the necessary input to both the network switching system (central office) to create the requested translations, and to CRIS to establish or change the customer s account for billing. Figure

21 Issue 1, May 2001 Notes on Billing Billing Overview illustrates a typical billing architecture for an end user billing system, e.g., a CRIS system. Network Recording of CDRs BAF Mediation and CDR Preparation Carrier Access Records Studies Other Applications Operations Error Processing Rating of CDRs CDRs to be rated Daily Process Rated CDRs Outcollects to Other Carriers (EMI) Service Orders Customer Account Information Customer Records Posting to Customer Account Updates for Next Bill Bill Preparation (Account Info. & CDRs) Monthly Process Incollects from Other Carriers (EMI) Billing and Collection Transactions from Other Carriers (EMI) Paper bills Electronic Media EDI Customized Outputs Figure 2-2 Sample Architecture for an End User Billing System Delays or errors detected in the service order process will affect the changes at a central office that are needed to establish new lines. They may also cause delays in the billing of new services to the customer. Only after all edits have been successfully performed will the appropriate applications receive this information for the necessary updates to either the central office or the customer master file. If errors are detected, the service order will be reprocessed through an error system for correction and re-entry to the service order process. Once the customer s account has been established, residence and business customers are billed monthly (by bill period) based on type of service, number of lines, features, and usage data generated from the network elements. 2 3

22 Notes on Billing Issue 1, May 2001 Billing Overview End User Billing Architecture Front-End Processing The AMA data received from the Network recording points undergoes integrity checks that allow it to be processed further, directed to other applications (such as the Carrier Access Billing System), or directed to an error file for investigation and possible correction. These integrity checks are performed to ensure the AMA data is properly formatted and can be processed. The validations performed include: records contain all valid values in each field; data has not previously been processed; current dates; detection of missing data; and various reasonableness checks. AMA data that fails to pass these edits are directed to error file(s) for investigation, correction, and re-entry into the billing system Error Detection and Correction Errors detected in the AMA records during the front-end validation process can be the result of network software. Incorrect switching system translations can cause incorrect AMA to be generated by the central office. Another cause can be switching system software coding errors not previously identified prior to the software release being deployed in the live network. Revenue Accounting Office (RAO) personnel refer these types of errors back to network organizations responsible for investigation and correction. These network-based organizations are usually referred to as EBACs (Equipment and Billing Accuracy Control) or AMACCs (AMA Control Centers). They are typically staffed with personnel having both network translation and AMA expertise. Error conditions are investigated and translations corrected as quickly as possible to prevent loss of revenue. In cases where it is identified to be a switching system software release coding problem, customer service requests are opened with the vendor for corrections based upon the priority of the error. The vendor has the ability to provide corrections, by way of software patches, and download them into the switching system(s). Errors can also be the result of internal processing within the RAO. For example, delayed service orders can cause the RAO to have no record toll conditions. This occurs when the customer has access to the LEC s telecommunication service, thereby generating billing usage data, but the service order delay prevented the CRIS account from being established. Internal RAO errors are investigated and corrected in a timely fashion to prevent inaccurate and/or delayed customer bills Rating Rating occurs, depending on local tariffs, in a variety of ways. The most common is distance and duration. To determine distance, the LEC may use the Telcordia TPM Data Source. 2 4

23 Issue 1, May 2001 Notes on Billing Billing Overview This contains all the NPA-NXX codes within a network and associates these with Vertical and Horizontal (V&H) coordinates (similar to latitude and longitude). By determining the V&H coordinates of the calling number and called number, calculations will be performed between both sets of V&H coordinates to determine the distance. This, along with duration, and any other service, as well as local tariffs, are used to calculate the cost of a call Guiding and Posting Once the billing records have been rated, they are directed to a toll guide for the customer responsible for the usage. The toll guide is a depository within the CRIS system where the rated usage is stored until the account is processed on the monthly bill period. For originating billable calls, the 10-digit telephone number of the originating party is used by the RAO to direct the rated usage to the toll guide associated with that particular CRIS account. CRIS accounts can have multiple toll guides. Customers that have more than one line have a toll guide for each line, but all are associated with a single CRIS account Bill Period Processing Due to the large volume of data to be billed, LECs must process the data posted to the CRIS accounts many times monthly. It would not be uncommon for a LEC to have 15 or more bill periods each month. This technique is accomplished by designating a specific portion of their customers s accounts (usually by NPA-NXX) to a bill period within a given month. On that particular bill period, only those customers CRIS accounts would run through the billing cycle, at which point all of their monthly recurring and non-recurring charges, usage posted to the toll guides, and applicable taxes and surcharges would be processed to the bill. In the case of larger customers billed out of a CRIS system, LECs can customize billing outputs to meet an individual customer s need. For large business customers served by multiple communications companies throughout the country, an American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X.12 standard, Electronic Data Interchange (EDI), is often used. EDI is an industry-defined electronic interface used by LECs to bill this type of large customer, such as the Federal Government, that wants or needs to coordinate its bills from multiple LEC providers Billing and Remittance The AMA data records received in an accounting office are edited and subjected to various integrity checks. CRIS processes records that are needed for end-user billing. One major step in this processing is to calculate a monetary price, based on applicable tariffs, for each billable occurrence of customer usage. The corresponding customer account is recognized, and the priced usage transactions 2 5

24 Notes on Billing Issue 1, May 2001 Billing Overview are posted for customer billing at regular intervals. Records that are needed for carrier access billing are sent to the CABS, which calculates monetary prices based on applicable tariffs, posts the resulting charges to the carriers accounts, and bills the carriers on a regular basis. In addition to using the AMA data for actual billing purposes, the data is also used for such ancillary functions as maintenance, network operations, studies, and surveillance. For these functions, the data received by the RAO in the normal AMA data stream is spun-off for dissemination to the organization requesting the data Data Exchange In the course of processing end user bills, it is often necessary for one telecommunications carrier to exchange call detail information with another telecommunications carrier. For example, a LEC may offer billing and collection services to an IC where the LEC includes a bill page of IC charges in the bill that is sent to the end user. In most instances, the process for producing IC call detail records on the bill page included in the LEC bill requires that the call detail information be passed from the IC to the LEC. The record format agreed on by the industry for passing messages between carriers is defined in the Exchange Message Interface (EMI) document, currently administered and maintained by the Message Processing Committee of the Ordering and Billing Forum (OBF). The EMI format contains many of the fields defined in BAF and, in general, an EMI record is formatted in the billing system or in the billing mediation platform, using either BAF or a switch-specific Call Detail Recording (CDR) Carrier Access Billing System (CABS) Service orders are also the vehicle used to establish a CABS account. However, the size and complexity of carrier accounts has made it necessary to develop electronic bonding processes to electronically transfer as much information as possible between the interconnecting carriers, the access provider (the LEC) and the access customer (the IC) for ordering Exchange Access services. Electronic bonding is a term used to describe electronic communication between telecommunications providers when each provider has an interface through which its service management applications communicate to others. Electronic bonding increases the speed and accuracy of the ordering process for both new and established accounts and minimizes the work time for the service representatives of both parties. The basic types of service orders also apply for CABS orders, i.e., new connects, change orders, and disconnects. The major difference is that these orders are not for individual lines (except in special instances), but deal with network facilities, such as establishing a feature group; connecting or enhancing a trunk group, entrance facilities, or special access facilities (e.g., private line); and requesting tandem interconnection, database 2 6

25 Issue 1, May 2001 Notes on Billing Billing Overview access, or interconnection to the LEC Common Channel Signaling (CCS) network. Figure 2-3 illustrates a functional architecture for an Access Billing System. Operations Provisioning Access Customers Service Requests ASRs LSRs Service Order Process Customer Records Customer Account Information Bill Preparation (Account Info. & Usage) CABS/BOS Usage Measurements from Mediation Summarization by Carrier Account Rating and Posting Paper bills CSRs Daily Process BDT [Electronic Media] Figure 2-3 Sample Architecture for an Access Billing System Generally, these service orders flow mechanically from the service order system and provide the necessary input to both the network switching system (central office) to create the requested translations, and to the CABS to establish or change the carrier customer s account for billing. Through the OBF, the telecommunications industry has established a number of guidelines, methods, and procedures to ensure that the intervals between the ordering of a service and the turn up of the service are kept to a minimum. In these guidelines, the responsibilities of both the Access Customers (ICs) and the Access Providers (LECs) are clearly defined. Error-free service orders are essential 2 7

26 Notes on Billing Issue 1, May 2001 Billing Overview because it is only after all edits have been successfully performed that the appropriate applications receive this information for the necessary updates to the central office and the CABS billing database. If errors are detected, the service order will be reprocessed through an error system for correction and re-entry to the service order process. Once the CABS account has been established, the IC customers are billed based on type of service: switched access or facility (special) access. For Facility Access, the Access Bill is rendered in advance once a month by the facilities ordered and the features and functions associated with those facilities. For Switched Access, the Access Bill is rendered in advance for the non-usagesensitive portions including features and functions provisioned on each trunk and/ or trunk group ordered. The usage, measured in Minutes of Use (MOU), that is generated from the network elements by the Access Customer is billed monthly in arrears. The MOU are presented on the access bill for each end office that originates and/or terminates calls for the Access Customer. In general, network personnel create and maintain the databases dealing with customer service permissions and charging, in response to the service orders issued when a carrier requests new or changed service. In today s network, such requests often involve special direct interactions between the customer and the Operations Support Systems (OSS) needed to initiate service changes. The outputs for an access billing system have been defined by the industry in the CABS Billing Output Specifications (CABS/BOS). Generally CABS bills consist of an account level summary with balance due information, details on current charges, payments applied, and adjustments applied. For switched access bills, end officeby-end office summaries of usage are displayed with backup information available in case of billing disputes. One particular aspect of access bills is that a detailed Customer Service Record (CSR) is always included with each bill. The CSR contains critical information about the account and details the coded information (Universal Service Order Codes (USOCs) and Field Identifiers (FIDs)) that describes the services provided by the LEC. CSR information is critical for on-going ordering activity. The large volume of data contained on each individual access bill was the major driver for LECs to mechanize the billing output process. Consequently, CABS/BOS has defined a standardized output format called the BDT (Billing Data Tape) 1 that fosters the electronic transfer of billing files. 1. The word tape should not be taken literally. The guidelines and billing outputs defined in CABS/BOS are generic and cover any type of electronic exchange of data. 2 8

27 Issue 1, May 2001 Notes on Billing Billing Overview Table 2-1 provides a high-level comparison of the functions performed by the two billing systems. Table 2-1 End User vs. Access Billing Comparison End User (e.g., CRIS) Retail customer (residential end users, large and small businesses) Millions of Bills per month Low revenue per bill (<$100) Predominately paper bills Usage detailed by message on the bill Usage billing based on originating records Customer Service Record (CSR) provided on a schedule (or on demand) Some large customers but mostly small to intermediate size Older systems but constantly being revised, rewritten, and reinvented Access (e.g., CABS) Wholesale customers (IC/INCs, other LECs, very large businesses) Hundreds of bills per month High revenue per bill (>$1M) Predominately electronic bills Usage summarized by Feature Group for each End Office by type of trunk group Usage billing based on terminating records as well as originating records Customer Service Record (CSR) always provided Practically all large customers Newer systems but constantly being revised, rewritten, and reinvented The Role of AMA in Billing AMA usage measurements support the network capabilities and service offerings that are needed to satisfy the billing requirements for end user customers as well as access customers. The scope of the bill preparation and rendering processes continues to grow and is now a massive undertaking by individual LECs. As the number of services billed on a usage-sensitive basis grows, the volume of AMA data also increases and threatens to overwhelm the billing systems currently in place. Many of the larger LECs face the issue of whether or not to continue with usagesensitive billing. The operative theory behind usage sensitive billing is that revenues will grow as usage on the network grows. With falling per MOU prices, however, some LECs are already facing the situation where the revenue generated by a call may be less than the cost of recording, transporting, processing, and billing that call on the customer s bill. One approach that is being used to address this issue is to establish a fixed monthly price for certain categories of calls. An example might be $29.99 per month for local service that includes 100 minutes of local and intralata toll calling. In this arrangement, there is actually a bit more work that the billing system must perform to generate an accurate bill such as computing the number of billed minutes over and above the 100 minutes included as part of the service. The benefit, however, is that the revenue is guaranteed for all customers with this particular class of service. 2 9

28 Notes on Billing Issue 1, May 2001 Billing Overview For customers that use more than the 100 minutes, the usage is billed at normal rates or at whatever rates are established in the contract for service. Another, more extreme approach, might be to offer unlimited service for all types of calls; local, intralata, and interlata for a flat fee each month. The price for this service would need to be very carefully developed so that consumers would not be put off by the monthly price. This approach has the advantage of guaranteeing revenue from those customers willing to pay. The downside to this approach is that some customers will very likely take full advantage of the unlimited nature of the service. This can be tolerated as long as (enough) other customers do not use their average allotment of usage on the network. Since this balance can almost never be guaranteed over time, billing approaches of this type rarely last very long. Also, regulators are generally more tolerant of telecommunications services and service providers that conform to the general axiom that those customers who incur the costs on the network should pay those costs. A flat rate paid by all users will invariably be priced too high for some users and too low for others. It might all work out in the end, but to the individual paying too much, the big picture is irrelevant. In summary, all LECs need to understand the service capabilities of their switches, their recording capabilities and limitations, the data content of the records generated, and the relative value of usage-sensitive billing. This Special Report provides the basic technical information that LECs need to support anticipated enhancements to existing switch functionality brought about by competition and by a changing regulatory environment. It aims to assist LECs in making the hard decisions of when to use usage-sensitive billing and when to avoid it. 2 10

29 Issue 1, May 2001 Notes on Billing Generating Usage Measurements 3 Generating Usage Measurements Section 3 describes the underlying components and technologies used to generate usage measurements in domestic wireline networks. It includes an overview of Billing AMA Format (BAF), the most widely used format for the generation of telephony usage measurements, and how BAF is administered. 3.1 Automatic Message Accounting (AMA) Automatic Message Accounting (AMA) is the process used by switching systems, packet-switching systems, and other network elements to provide billing usage measurements data. This data is needed to either charge end user customers for network services or to charge another carrier [Interexchange Carrier (IC), International Carrier (INC) or other Local Exchange Carrier (LEC)] for interconnection services whereby those carriers reach end user customers served by the recording company. The specific data items needed for end user billing are determined by a complex interaction between the customer s service request, the customer s service permissions, and local tariffs. The data items needed for billing interconnection services are also determined based on a combination of the services ordered, network configuration, and the access tariffs Background Network elements determine what service to provide by using a customer s service request (for example, dialed digits) and the network s database information about the customer s service permissions. Then, by using AMA call processing, these elements determine whether usage information must be generated for billing and other purposes. If AMA data is generated, the network element outputs the data in a form suitable for processing by a Revenue Accounting Office (RAO) billing system. Because of the tremendous volume of AMA data that typical LEC RAOs must process each day, along with the business requirement for very high integrity billing processes, it is most beneficial that a universal AMA data format be used by all network elements and for all services. For most LECs, the format used is BAF. The generic requirements of BAF for all services are set forth in GR-1100-CORE, Billing Automatic Message Accounting Format (BAF) Generic Requirements. The switching system generic requirements for generating AMA are described in GR-508-CORE, LSSGR: Automatic Message Accounting (AMA). Individual telecommunications services are documented in additional Telcordia documents for the specific service. Typically, more than 70% of a LEC s revenues are the result of recording billing usage measurement data, therefore it is critical that switching equipment suppliers adhere to these requirements. For LECs using formats other than BAF, the billing data generated is often referred to as Call Detail Recording 3 1

30 Notes on Billing Issue 1, May 2001 Generating Usage Measurements (CDR). The format and content of CDRs can vary depending upon the network element generating the data AMA Process Model The AMA process in a switching system provides the LEC RAO with usage-related data to perform the following functions: Bill customers and carriers for use of network services or resources Perform studies on network usage Provide Message Detail Recording (MDR) data to business customers. Figure 3-1 shows a model of the AMA process for switching systems, which is used to define many of the requirements in this document. Each function operates independently of the other and can be operational concurrently. AMA Creation Function AMA Output Function Generate Data + Aggregate/ Correlate AMA Data Files AMA Teleprocessing Nine-Track Magnetic Tape Writing Format BAF Record Form AMA File + Figure 3-1 AMA Process Model The AMA Creation Function begins with the generation of AMA data and ends with the successful delivery of a BAF record to a mass storage device for transport to the RAO. The AMA Creation Function consists of four, serial, near-real-time subfunctions: Generate Data this subfunction produces and collects raw, usage-related data when specified criteria are fulfilled. 3 2

31 Issue 1, May 2001 Notes on Billing Generating Usage Measurements Aggregate/Correlate this subfunction gathers usage-related data and places it in the proper, predefined group. Format BAF Record this subfunction puts raw, usage-related data into a BAF record. Form AMA File this subfunction places BAF records into AMA data blocks and outputs them to a non-volatile storage medium (a mass storage system associated with the switch) for retention until they are output from the switch. Placing the data on a storage medium generally involves organizing the AMA data blocks into AMA files. The definition of an AMA file is switch-dependent. Local storage of AMA data is consistent with current switch implementations. The AMA Output Function determines whether the AMA files are output to the RAO by either AMA Data Networking System (AMADNS) conventions, AMA Teleprocessing System (AMATPS) conventions or hardcopy media such as ninetrack magnetic tape. These are performed as determined by maintenance personnel and are not provided in any near-real-time mode Call-Related Terms This document regards the term call as a common concept. A call is defined as establishing or attempting to establish communications using a telecommunications system or network. In telephony, a call begins when an end user customer sends an address code to a network, and concludes when communication between users has ended or when the attempt is unsuccessful. In the terminology of this document, therefore, the term call is inclusive of attempts unless otherwise stated. Calls are defined to be composed of three basic types: originating calls, terminating calls, and service requests. Call attempt - Any demand for service to which a network element reacts. Originating calls Call origination attempts that result in the system's receipt of at least one digit. Calls that do not (normally) result in digits being dialed become originating calls on determination of the destination. (The term destination refers to the system component type that serves a call in its stable state (e.g., outgoing trunk, intraoffice junctor)) A three-way call results in two originating calls. Terminating calls Incoming call attempts (including those from within the same switching system) intended to complete within the system. Incoming call attempts become terminating calls on the system's recognition of the destination. Service requests Requests by a customer for use of a switching system capability, other than setting up a call, that may potentially generate a BAF record. Examples of service requests are turning call forwarding on/off or receiving information from a remote database (e.g., a Service Control Point (SCP)) that may potentially request to generate a BAF record. One or more service requests may be made on an originating/terminating call. 3 3

32 Notes on Billing Issue 1, May 2001 Generating Usage Measurements A call is an AMA call once the switch determines that the call requires AMA treatment (i.e., requires generation of a BAF record per Telcordia service/ technology requirements [also any vendor-specific specifications] that apply to the type of call that has occurred). An internetwork call is a call that traverses more than a single network from point of origination to point of termination, requiring either a presubscribed or dialed access code (usually involving a carrier). ( Internetwork and interlata are not equivalent terms; a call may be internetwork but intralata. ) An intranetwork call is a call handled within a single LEC network. Usually a LEC network is LATA-wide; in such cases, intranetwork is equivalent to intralata. Calls include packet-switched calls and circuit-switched calls. Calls include any new types of calls resulting from the switching system providing services/features via new capabilities [e.g., Integrated Services Digital Network (ISDN) or Advanced Intelligent Network (AIN) capabilities]. Calls also include calls to which Message Detail Recording (MDR) requirements apply. MDR is considered part of AMA; consequently, the AMA requirements also apply to MDR calls, MDR data, and MDR BAF records. Calls also include any calls that generate a record to be used for study purposes AMA Data Generation Every line and/or trunk that can originate a LEC service is assigned a charge class. This charge class, in conjunction with other supplementary data, determines the service requests that can be originated from the line and/or trunk. The charge class is also a factor in determining whether or not an AMA data record is to be generated for a given service request, and in determining the content and format of AMA data generated for the service request. For each occurrence of service use, AMA data is generated if that use is billable or if the data is required for one of the ancillary AMA data-usage functions. The AMA data is always provided under the premise that all usage of resources associated with the service may be billable. Therefore, in addition to data input that is common to all AMA data records (for example, the identification of the user of the service, the user s service requests, dialed digits, the time and duration of such use), the record for specific network service use contains data specific to that use and the features of the customer s line or trunk that provide access to the service. The following subsections discuss AMA data generation strategies for several services and technologies. These sections do not cover all types of recordings; see GR-1100-CORE for a complete list. 3 4

33 Issue 1, May 2001 Notes on Billing Generating Usage Measurements AMA Translations AMA translations are part of the switching system database needed to control internal call processing functions such as code interpretation, screening, and routing. See GR-505-CORE, LSSGR: Call Processing, for more details on these and other functions. See GR-2932-CORE, LSSGR: Database Functionality, for detailed requirements on the switching system database Line or Trunk Attributes Each line or trunk that can access a LEC s telephone network is assigned a set of attributes by the LEC through translations. Trunk attributes are described in GR- 505-CORE. The following line attributes are essential to AMA data generation: Directory number and billing number Services and features. These line attributes are used to identify the party to be billed for use of a LEC network service, to determine whether AMA data is needed for a given call, and to determine the content, call type, and format of the BAF record generated for the call. The switching system should be capable of using the attributes of a line or trunk to determine whether a call can be allowed and whether AMA data should be generated. For example, if a customer subscribes to a flat-rate service, AMA data is not generated for calls to destinations within the customer s flat-rate local calling area. However, if the same customer subscribes to a message-rate service, AMA data is generated for calls to destinations within the customer s message-rate local calling area. Most intranetwork call types cause AMA data to be generated at the originating switch. However, some call types cause a BAF record to be generated at the terminating switch. For example, an AMA record can be generated at the terminating switch for calls incoming to a Type 1 WSP line or incoming to a Feature Group A (FGA) line. Terminating recordings can also be made at incoming trunk interfaces. Examples would include calls incoming over a Feature Group D (FGD) interface, a Feature Group B (FGB) interface, a Type 2B WSP interface, and a Type 2A WSP interface Directory Number and Billing Number Each individual line and each station on a two-party line are assigned a telephone number normally included as the originating (calling) number in a BAF record. In most cases, the number recorded in the Originating Number field (BAF Table 14) identifies the party to be billed for use of a LEC network service. For some services, a billing number other than the originating number is needed for charging purposes. In such cases, the billing number is also an attribute of the line. 3 5

34 Notes on Billing Issue 1, May 2001 Generating Usage Measurements The billing number is recorded in the Originating NPA and Originating Number fields (BAF Tables 13 and 14, respectively) or in a field specifically designed for recording a billing number. Depending on the assignment made by a LEC, the billing number may or may not be consistent with the North American Numbering Plan (NANP) format Digits Dialed The digits dialed by a customer can be a terminating number, a service access code, a toll-free number, an activation code, and a prefix (e.g., 0-). Based on the digits dialed, the switching system must be capable of determining the AMA treatment needed for the service requested by the customer. For example, a subscriber can dial the access code *66 to activate the Automatic Callback CLASS feature. In this case, a BAF record is generated to provide information about the customer s activation of the Automatic Callback CLASS feature (see GR-215-CORE, LSSGR: CLASSSM Feature: Automatic Callback, FSD , for more detailed information) Call Disposition A call may be connected or unconnected after it is set up by the switching system. In most cases, a BAF record will not be generated for an unconnected intranetwork call. However, if studies are in effect, AMA data may be generated for certain types of unconnected intranetwork calls Long Duration Connection A long duration connection is an intranetwork or internetwork call on which, at a scheduled record generation time, both calling and called parties remain off-hook ( connected for carrier timing) and the elapsed time and/or carrier elapsed time of the call already exceeds 1440 minutes (24 hours). AMA data should be generated for a long duration connection as described in GR-508-CORE, Section 8.3, Long Duration Connection Processing Services and Features Customers must subscribe to most services and features provided by the LEC before using them. A service is a group of capabilities, taken as a whole, to which a customer can subscribe. Example services are coin, message-rate, flat-rate, multiparty, individual, two-party, and Wide Area Telecommunications Service (WATS). A service is usually identified in the call type field (BAF Table 1) of a BAF record. 3 6

35 Issue 1, May 2001 Notes on Billing Generating Usage Measurements A feature is a capability or a group of capabilities that can be offered in conjunction with different services to eligible customers. Example features are custom calling features and bearer capability. A feature may be offered by a LEC on a subscription or usage-sensitive basis. A feature is usually identified in the Service Feature Code field (BAF Table 12) of a BAF record LEC-Settable Office Parameters A LEC-settable office parameter can turn a capability on/off for the entire switch (not for a subset of lines). For AMA purposes, LEC-settable office parameters control the generation of specific BAF records or modules. For example, the generation of the Local Coin Call Type Code (CTC), CTC 041, should be able to be turned on/off by a LEC by means of switching system input. When turned on, local calls originated from all coin stations served by the switching system will generate CTC 041. In this example, the Service Feature Code further identifies the AMA record as being originated from a coin line by populating the value of 001 in BAF Table 12. Another example is that AMA data should be generated for certain types of unconnected calls when parameters for conducting network completion studies are set. The values of some LEC-settable office parameters are recorded in specific fields of a BAF record. Example parameters are recording office identification and sensor identification which are recorded in the Recording Office Identification field (BAF Table 5) and Sensor Identification field (BAF Table 3) of a BAF record, respectively AMA Studies This section presents information on studies for typical services. References to service specific requirements documentation is included as appropriate. For example: Advanced Intelligent Network, AIN (see GR-1298-CORE, AINGR Switching Systems) Local Service Provider Identification, LSPI (see GR-2970-CORE, Service Provider Identification Capability Specification) Local Number Portability, LNP (see TRQ No. 2, Technical Requirements for Number Portability - Switching Systems [Alliance for Telecommunications Industry Solutions (ATIS)]). To present information related to studies, the following definitions are used: Non-study AMA call an AMA call in which the BAF record does not contain study-related data. 3 7

36 Notes on Billing Issue 1, May 2001 Generating Usage Measurements Study-only AMA call an AMA call in which the BAF record can only be used for study purposes. This type of call normally does not generate a BAF record but the LEC has turned on (through translations) record generation for study purposes. Combination AMA call an AMA call in which the BAF record is intended to be used for study and conventional AMA purposes (e.g., billing) AMA Fundamentals for Studies When a study is in effect on an otherwise non-study AMA call (i.e., a combination AMA call has taken place), the resulting BAF record includes study-related data besides the data used for billing. For example, the short-format structures used for high runner call types are replaced by a detailed structure to record the additional AMA details generated for studies. The call type code does not change when an alternate structure (other than the one normally used) is used because a combination AMA call has occurred. That is, if a call would generate only servicerelated data for AMA purposes and the study caused additional data to be generated, the call type code would not be changed because of the added details. A study may be set against an originating or terminating line. When a study is set against an originating line for a study-only AMA call, data should be formatted in the Originating Study Record call type (CTC 067). However, if the originating line is a coin line, the data should be formatted in the Local Coin call type (CTC 041). When a study is set against a terminating line, if AMA data is to be generated solely for study purposes, the data should be formatted in the Terminating Study Record call type (CTC 036). If a study causes AMA data to be generated for an unconnected call, the call type used for such a call should be the one used for recording AMA data when the call is connected AMA Data Generated for Specific Studies The studies data in a BAF record may be used in such instances as division of revenue, investigating customer complaints, and planning tariffs. Requirements for generating AMA data for specific studies are provided in GR-508-CORE. Studies may require generation of BAF records for intralata calls for which called party off-hook is not detected (unanswered call recording) Complaint Observing Complaint observation is used typically for customers questioning their telephone bills. Individual customer lines, identified by the switching system for complaint observing, should have detailed AMA data generated for connected and unconnected calls. In each BAF record, character 2 of the Study Indicator field 3 8

37 Issue 1, May 2001 Notes on Billing Generating Usage Measurements (BAF Table 8) should be set to 1 to indicate complaint observing was in effect. However, if a network completion study is also in effect, character 2 should be set to 3 to indicate both types of studies were in effect. When complaint observing is turned on for a particular line, study-only AMA calls do not occur on that line (i.e., records only used for study purposes are not generated) Subscriber Line Usage Study (SLUS) The Subscriber Line Usage Study (SLUS) generates data that portrays the calling patterns and service usage of customer lines. SLUSs are used in planning measured service tariffs and determining tariff effects SLUS may be simultaneously assigned to any number of lines The assignment of lines for SLUS may be made either on an individual line basis or based on the class of the line SLUS may be assigned to a line for originating calls, terminating calls, or both. These types of SLUSs are referred to in the following text as originating SLUS, terminating SLUS, and originating/terminating SLUS, respectively. Detailed AMA data should be generated for all connected and unconnected calls originating from lines designated for originating or originating/terminating SLUS. These records should be formatted according to the requirements described in GR- 508-CORE, Section 3.3.1, AMA Fundamentals for Studies. For example, an Originating Study Record call type (CTC 067) BAF record should be made for all study-only AMA calls originating from a line designated for originating or originating/terminating SLUS. However, for combination AMA calls originating from such a line, the decision about what call type code is generated follows its normal course (i.e., the Telcordia requirements applicable to the call type dictate the call type code to use). In each record, character 1 of the Study Indicator field (BAF Table 8) should be set to 2 to indicate SLUS was in effect. Detailed AMA data should be generated for all connected and unconnected calls terminating to lines designated for terminating or originating/terminating SLUS. These records should be formatted according to the requirements specified in GR- 508-CORE, Section 3.3.1, AMA Fundamentals for Studies. For example, a Terminating Study Record call type (CTC 036) BAF record should be made for all study-only AMA calls terminating to a line designated for terminating or originating/ terminating SLUS with the HNPA and called number recorded in the Originating NPA and Originating Number fields, respectively (BAF Tables 13 and 14, respectively). In addition, character 1 of the Study Indicator field (BAF Table 8) should be set to 2 in the BAF record to indicate SLUS was in effect. For each line assigned for terminating or originating/terminating SLUS, the switching system should accumulate counts of calls that encounter a busy condition. The counts accumulated in a predetermined period (e.g., counts per day) should be formatted in the Terminating SLUS Overflow Counts call type (CTC 037). 3 9

38 Notes on Billing Issue 1, May 2001 Generating Usage Measurements Network Completion Network completion studies involve the analysis of AMA data for connected and unconnected calls to determine statistics such as percentage of completion and holding time. The switching system should provide the capabilities to allow a LEC to specify, through translations, the call types for which the network completion study is to be conducted. When a network completion study is in effect, AMA data must be generated for those unconnected calls that, if connected, would have generated a BAF record. The call type code used for such a call should be the same call type code used for recording the AMA data when the call is connected. A short-format structure may be used to record AMA data under certain conditions (see GR-1100-CORE). When AMA data for network completion calls is recorded in a short-format structure, a network completion indicator is not included. However, if AMA data generated for network completion calls is to be recorded in a structure that includes the Study Indicator field (BAF Table 8), character 2 of the Study Indicator field should be set to 2. This indicates to the RAO that the call was of a type for which network completion data was generated. However, if a complaint observing study is also in effect, character 2 should be set to 3 to indicate both types of studies were in effect. 3 10

39 Issue 1, May 2001 Notes on Billing Generating Usage Measurements 3.2 Billing AMA Format (BAF) BAF is the preferred format for all AMA data generated for processing by a LEC RAO. AMA information may be generated by Network Elements (NEs) that include operations systems (e.g., a service management system). Elements of BAF records are Tables, Structures, and Modules. Tables are also referred to as data fields. Structures and Modules are built from data fields. The type of service invoked on a call (call type) and applicable call conditions, such as long duration, determine what structure and modules should be generated. BAF records record data associated with use of a LEC s network resources and its services, so that a LEC can render a bill that identifies and charges for the LEC resources used BAF-Related Terms Billing AMA Format (BAF) is a system of abstract syntax and semantics that supports coding of AMA data into data records. Some key BAF-related terms are as follows: table (or data field) A coded, logical group of data characters. The basic element of a BAF record. structure A predefined, ordered set of fields identified by a Structure Code (SC). A structure consists of eight common fields followed by a group of fields that depend on the type of service/technology for which the data is recorded. Two or more modules may be appended to a structure. call type A call type is an indication of the type of service/technology provided to a customer or carrier for a particular call. All call types are identified by call type codes. The Call Type Code (CTC) in a BAF record provides guidance to accounting systems for processing the record. module A predefined set of fields identified by a module code that may be appended to a structure if needed for the specific service/technology or for reporting information connected with specific conditions Data Fields The basic building block of a BAF record is a data field. A BAF data field is a defined object that is a sequence of contiguous octets (eight binary bits). Each BAF data field is defined in terms of its contents, format and length. A common set of data fields are required in all BAF records. Each field within a record is a signed packed decimal number, a status-assigned binary number, or a collection of one or more Extended Binary-Coded Decimal Interchange Code (EBCDIC) characters used to record alphanumeric information. A signed packed decimal number is composed of a Sign character, normally a hexadecimal C (hex-c). A status-assigned binary 3 11

40 Notes on Billing Issue 1, May 2001 Generating Usage Measurements number is composed of a number of binary octets that contain the value of the field and a status octet, normally a binary (hex-cc), that indicates the status of the value. Data fields are divided into two major categories. Each has an associated numbering scheme. These categories are: General, multipurpose data fields General, multipurpose data fields begin with BAF Table 000 and have no limit to their numbering. These data fields convey descriptive, informational aspects of a service or feature. Generic counter data fields Generic counter data fields are identified by an 8XX numbering scheme (i.e., 801, 802, 803, etc.). Counter tables are used when the information to be indicated is the number of counts, events, etc., without need for a semantic table. A definition of the Sign character of a BCD data field is provided in Table 3-1. This table also defines the maximum length of a BCD data field. Note that an EBCDIC data field does not have a Sign character, and that its maximum theoretical length is very large. Table 3-1 Characteristics of BAF Data Fields Sign Character Maximum Length Signed Packed Decimal Data Field The least significant character position (low order 4 bits) of a signed decimal data field is a Sign character. This character is set to hexadecimal value C (hex C) when no character positions of the field contain data known or suspected to be missing or in error. 16 BCD characters (including the Sign character) EBCDIC Data Field (No Sign character) Maximum record length less 22 bytes for the common data fields. The limitation for the maximum allowable length of a BAF record is imposed by either the recording medium or the transport method (e.g., AMATPS - AMA Teleprocessing System). The default maximum allowable length for the recording medium is 32,756 bytes per record. 3 12

41 Issue 1, May 2001 Notes on Billing Generating Usage Measurements Structures A BAF structure is a set of eight common data fields, followed by a group of fields required by the type of service/technology for which the data is recorded. Each structure is a unique, ordered set of fields identified by a structure code, the third data field in the record. A common set of eight fields is needed for nearly every BAF record 1. The NE shall begin every BAF record with an ordered set of eight fields except for the Beginning Of Recording (BOR) and End Of Recording (EOR) records (SC 9036 and SC 9037, respectively). The eight fields and their order are Record Descriptor Word (RDW) (BAF Table 000) Hexadecimal Identifier (BAF Table 00) Structure Code (BAF Table 0) Call Type (BAF Table 1) Sensor Type (BAF Table 2) Sensor Identification (BAF Table 3) Recording Office Type (BAF Table 4) Recording Office Identification (BAF Table 5). The documentation for each structure gives the structure code and a depiction of the layout of the corresponding structure. Each layout contains four columns: Information Ordered list of data fields contained in the structure. Fields in a structure are always present in the indicated order. It is extremely important to note that the name given to a data field in a structure is related to its usage in the structure; this name may differ from the generic name given for the same table. The name is often suggested by AMA data generation requirements in Telcordia requirements documents for network services and technologies. Table Number This number is the same for all applications of a table, even though the table name in column one may change from structure to structure. Number of Characters Number of BCD characters in each data field. 2 To avoid confusion, a character count is not shown for the Record Description Word field (BAF Table 000). 1. Requirements on the suppression of some of these common fields are included in GR-385-CORE, Automatic Message Accounting Teleprocessing Systems (AMATPS) Generic Requirements and GR-1343-CORE, Generic Requirements for the Automatic Message Accounting Data Networking System (AMADNS). 2. For EBCDIC fields, this will indicate the number of EBCDIC characters. Note that an EBCDIC field contains two hexadecimal characters per EBCDIC character. 3 13

42 Notes on Billing Issue 1, May 2001 Generating Usage Measurements Byte Offset Number of the first byte of a data field with the Hexadecimal Identifier field (BAF Table 00) taken as the first field of the record. With this convention, a BAF record s Call Type field (BAF Table 1) starts with byte 4. Byte offsets are provided to assist in formatting and processing BAF records. The Record Descriptor Word field (BAF Table 000) is excluded from the offset calculations because this field is not normally available to high-level computer languages used in processing BAF records. The Hexadecimal Identifier field (BAF Table 00) is the first field that is normally available. If it is necessary to adjust byte offsets for the Record Descriptor Word field, its size-four bytes should be added to all numbers in the Byte Offset column. The total number of bytes in the structure, excluding the 4-byte Record Descriptor Word field (BAF Table 000), is given at the bottom of the Byte Offset column Call Type Codes (CTCs) The network associates the service or capability provided to a customer or carrier with a BAF call type and call type code. The call type code in a BAF record provides processing guidance to accounting systems. Telcordia requirements documents identify, explicitly or implicitly, the call types, call type codes, and call type code used for the services/capabilities they specify. The documentation for each call type gives the call type code and name. It includes usage-oriented text intended to provide helpful explanatory information concerning the meaning and application of the call type. It may also include a reference to explanatory documentation. Several different structures can often be used for a given call type. The correct structure to be used depends on the applicable condition(s). Applicable conditions are given, explicitly or implicitly, in Telcordia requirements documents. For example, the term connected is explained in GR-508-CORE Call Type Code Precedence As a call is made, it may invoke various services (i.e., MDR, AIN, and ISDN) that need to be captured in an AMA record. For calls that normally generate an AMA record, this information can be found within the structure and in the modules that are appended to the record. However, there are calls that do not have any call type codes applicable to the call (i.e., calls that normally would not generate any AMA record), but use services for which a recording is needed. In order to capture that these services were used, a record will be generated using a default call type code. The choice of a default call type code is not always straight-forward. There may be several default call type codes that could be considered a match for a particular call. 3 14

43 Issue 1, May 2001 Notes on Billing Generating Usage Measurements Since only one record should be generated, only one default call type code may be used. This situation poses two different problems. 1. Which call type code to use 2. After the call type code is selected, how will the call information corresponding to the other possible call type codes be represented in the default record. For example, when ISDN recording is turned on and a study is also turned on for the ISDN line but no normal AMA record is generated for the call, should a CTC 045 record be generated (BAF Table 8, Study Indicator, could indicate type of study) or should the Originating Study record, CTC 067, be generated with an ISDN module appended? The second part of the problem may be solved by use of the tables that are included within the structure codes, or by the use of module codes. Module codes are normally appended at the end of a structure, and provide an extra source of information that is needed so that no information on the call may be lost. With that settled, there is still the matter of which default call type code to use. Table 3-2 Call Type Code Precedence List MDR Service Structure Code / Call Type Code (Originating) SC 0001/CTC 159 or SC 0220/CTC 159 Structure Code / Call Type Code (Terminating) SC 0079/CTC 159, SC 0220/CTC 159 or SC 0221/CTC 159 AIN SC 0220/CTC 047 SC 0220/CTC 047 or SC 0221/CTC 047 ISDN SC 0001/CTC 045 SC 0001/CTC 184 or SC 0690/CTC 184 Local Number Portability (LNP) SC 0001/CTC 721 or SC 0500/CTC 721 Originating only Studies SC 0001/CTC 067 SC 0079/CTC 036 Local Service Provider SC 0001/CTC 126 SC 0001/CTC 128 Identification (LSPI) Release to Pivot (RTP) SC 0001/CTC 013 or SC 0500/CTC 013 Originating only To address this issue, BAF requirements specify a precedence of call type codes to be generated as a default when no other call type code is applicable for the call. Table 3-2 lists the services that may be invoked on a call in order of precedence. The call type code associated with the service having the highest precedence on the list will be selected as the default call type code for the generated AMA record. The AMA for the remaining services of the call should be recorded in modules appended at the end of the structure or in a table (e.g., studies are indicated in BAF Table 8). For example: An AIN MDR call would result in an SC 0220/ CTC 159 record, assuming no normal call type code applies to the call. AIN is indicated by the fact 3 15

44 Notes on Billing Issue 1, May 2001 Generating Usage Measurements that the structure code is An interswitch ISDN local flat-rate call from a ported number would record an SC 0001/CTC 045 to indicate ISDN origination and append the appropriate modules to indicate a call from a ported number BAF Tables BAF tables have values partitioned into ranges assigned by the LEC and Telcordia. Public BAF Table values are assigned by Telcordia for uniformity of the network/ accounting interface. The LEC takes full control and responsibility of any values assigned to BAF tables , which are specifically assigned for the LEC. Vendors of new types of sensors and recording offices should contact Telcordia for sensor type code and recording office type code assignments. The following bulleted items summarize the value applications for each of the different groupings of BAF tables: Tables (data fields), structures, and modules that govern the composition of BAF records. Call type, service identification, service feature, and message billing index that govern accounting system processing of a BAF record. These values are related to the type of service/technology provided to customers and carriers. All are translation-settable by the LEC. Sensor type and recording office type used for control of AMA integrity. They are translation-settable by the LEC. Service/technology specific applications. Note that the values for sensor identification and recording office identification (not the type codes) are specified by a LEC and are assigned through translation procedures. The documentation for each table gives the table number and name, and a depiction of the layout of the corresponding data field. Note that the particular meaning that should be associated with a table is suggested in the name given to it in a BAF structure or module that specifies its use. This name and meaning of a table in a structure or module do not necessarily correspond to the generic name and generic meaning. For example, consider BAF Table 6, Date. In SC 0625, BAF Table 6 is used in two different ways. It is labeled Connect Date in one and Carrier Connect Date in the other. Both labels indicate specific realizations of the same abstract concept. The Chars columns of a table layout identifies the character positions that may form subfields. In most cases in which a field is partitioned into subfields, each subfield has a title under the Meaning column. The last character position of signed packed decimal number fields contains a Sign character. It is normally set to hexadecimal C (hex-c). 3 16

45 Issue 1, May 2001 Notes on Billing Generating Usage Measurements The last octet of a status-assigned binary number field indicates the status of the value portion of the field. It is normally set to binary (hex-cc) Modules A BAF module is a predefined group of data fields. A module has a name and is uniquely identified by a 3-digit module code that is the first data field in the module. The BAF module concept expands the BAF recording capability. BAF modules provide the flexibility needed to permit more rapid introduction of AMA data generation for new services, features and network capabilities. It is intended that a BAF module contain data items related to one another and necessary for reporting an aspect of customer usage of network elements. A module may be appended to a structure according to the needs of reporting data for service rendered or for a call condition. This provides flexibility for reporting data for a new service or network capability by permitting existing structures to be used, and avoiding the need to define new structures. Modules may be included in a BAF record in any order. The order is not important except that Module 000 is always the final module in any BAF record that contains modules. Module 000 provides a positive, application-level, end-of-record indication to RAO software. A module may not be used twice in the same record, except for those modules specially noted as repeatable in the appropriate requirements documents. Rules for determining which modules are used with which type of calls can be found in the appropriate requirements documents. Modules in a BAF record are appended as needed. A module is appended to the structure, and succeeding modules are appended to the previous module. This ensures that a BAF record is a sequence of contiguous octets. No limit is placed on the number of modules that may be appended. However, there is a maximum record size. The documentation for each module gives the module code and a depiction of the layout of the corresponding module. Each layout contains four columns: Information Ordered list of data fields contained in the module. Fields in a module are always present in the indicated order. It is extremely important to note that the name given to a data field in a module is related to its usage in the module; this name may differ from the generic name given for the same table. The name is keyed to AMA data generation requirements in Telcordia requirements documents for network services and technologies. Table number This number is the same for all applications of a table, even though the table name in column one may change from module to module. 3 17

46 Notes on Billing Issue 1, May 2001 Generating Usage Measurements Number of Characters Number of BCD characters in each data field. 3 Byte Offset Number of the first byte of a data field, with the Module Code field (BAF Table 88) taken as the first field of the module. Byte offsets are provided to assist in formatting and processing BAF records. The total number of bytes in the module is given at the bottom of the Byte Offset column Generic Modules Generic modules can be used for multiple services. For example, Module 021, Originating Carrier Access Module, is a generic module. It may be included in BAF records created for originating carrier access calls utilizing different services. Module 021 contains data fields usually needed to identify originating IC/INC access, including the carrier s ID and the elapsed time of the carrier s access to the Local Access and Transport Area (LATA) network. In some applications, a general-purpose module needs to contain extra information to differentiate its usage when it is included in different BAF records. This can be achieved by including a context-identification data field in the module Flexible Modules Telcordia has introduced the use of flexible modules. Flexible modules follow the same guidelines as generic modules, however, flexible modules do not have a fixed length. The module is used to hold a variable number of instances in the same field, a variable number of modules, or used to hold a field that has a variable length. Each of the flexible modules uses the value in BAF Table 802 to represent the total length (in bytes) of all BAF Tables in the Module and data that follow BAF Table 802. Table 3-3 gives an example of a flexible module. Table 3-3 Module Flexible Length Module - Repetitive Field Information BAF Table Number Number of Characters Byte Offset Module Code Identification Module Length Flexible Module Descriptor Additional BAF Tables will be included in this Module 3. For EBCDIC fields, this will indicate the number of EBCDIC characters. Note that an EBCDIC field contains two hexadecimal characters per EBCDIC character. 3 18

47 Issue 1, May 2001 Notes on Billing Generating Usage Measurements This module is used to hold a variable number of instances of the same field. The value in BAF Table 802 represents the total length (in bytes) of all tables that follow BAF Table 802. The Flexible Module Descriptor field (BAF Table 575) defines the tables that follow BAF Table 575. The type of data to be stored in these tables and the resultant byte offsets for the tables that follow are implied based on the value encoded in BAF Table Building a BAF Record A BAF record must have one of the two layouts shown in Table 3-4, i.e., a structure only or a structure with modules appended. Table 3-4 Layouts of BAF Records BAF Record (Structure Code Only) Record Descriptor Word Hexadecimal Identifier Structure Code (0)XXXX Call Type Sensor Type Sensor ID Recording Office Type Recording Office ID Other Data Fields for Structure XXXX BAF Record (Structure Code Plus Modules) Record Descriptor Word Hexadecimal Identifier Structure Code (4)XXXX Call Type Sensor Type Sensor ID Recording Office Type Recording Office ID Other Data Fields for Structure XXXX Module Code Module Data Field(s) Module Code Module Data Field(s) Module

48 Notes on Billing Issue 1, May 2001 Generating Usage Measurements The distinction is as follows. BAF Record with Structure Only If the Module Indicator of the Structure Code field (BAF Table 0) is 0, no modules are included in the record. The 4-digit structure code identifies the structure. BAF Record with Structure and Modules If the Module Indicator of the Structure Code field (BAF Table 0) is 4, two or more modules are appended to the record. The last module is always Module 000. The 4-digit structure code identifies the structure to which the modules are appended BAF Procedures for Handling Incorrect or Unusual BAF Data Flag Procedure for Missing Data or Data Fields in Error The flag procedure enables the RAO to quickly recognize each erroneous record; and the data field(s) that contain errors. The flag procedure should be used independently of how the NE determines that a character is missing or in error. The value octets of status-assigned binary number fields are not altered when octets that should be present are known or suspected by the NE to be missing or in error. Fields that contain data errors caused by the network (e.g., digits garbled in the network or information lost because of power loss) are flagged by the flag procedure. Note that, for signed packed decimal number fields and EBCDIC fields, the flag procedure allows a field to be partially populated with hex-fs ( EO for EBCDIC fields). Hence, useful data may still be extracted from a flagged field of these types. If the NE does not have sufficient information for a field as a result of customer actions (e.g., partially dialed calls or call abandonment), the flag procedure is not used. A field for which data is not expected, perhaps because of service/technology requirements, should not have the flag procedure applied. In such a case, the field is unused, and the fill procedure (described in Table 3-5) should be applied instead Fill Procedure for Unused Data Fields When a BAF record is being generated that contains a data field that is no longer used or is not applicable to the service or capability being provided, the fill procedure is applied. This can occur when a BAF field that is no longer used remains in the definition of an existing BAF structure or module. It can also occur when the meaning of a field is not applicable to the particular call. 3 20

49 Issue 1, May 2001 Notes on Billing Generating Usage Measurements Pad Procedure The pad procedure is used for data fields that must be padded out to be completed. Table 3-5 describes the use of the Flag, Fill and Pad procedures. Table 3-5 Flag, Fill, and Pad Procedures for BAF Data Fields Procedure Flag Fill Pad Signed Packed Decimal in Data Field Use the hex-f character for each character that should be present in the field but is known or suspected to be missing or in error. Also set the Sign character of the field to hex-d. Also set the record s Hexadecimal Identifier field (BAF Table 00) to hex-ab. If the field is intentionally not used, use the hex-f character in every position of the field, including the field s sign position. Use of the fill procedure does not affect the record s Hexadecimal Identifier field. Right-justify the information in the data positions of the field and pad out the unused positions, using hex-0 as the pad character. Use of the pad procedure does not affect the field s sign or the record s Hexadecimal Identifier field. EBCDIC Data Field Use the hex-ff character for each character that should be present in the field but is known or suspected to be missing or in error. Also set the record s Hexadecimal Identifier field (BAF Table 00) to hex-ab. If the data field is intentionally not used, use the blank character (hex-40) in every position of the field. Use of the fill procedure does not affect the record s Hexadecimal Identifier field. Left-justify the information in the field and pad out the unused field positions, using the blank character (hex-40) as the pad character. Use of the pad procedure does not affect the record s Hexadecimal Identifier field. 3 21

50 Notes on Billing Issue 1, May 2001 Generating Usage Measurements 3.3 BAF Administration BAF is administered by Telcordia, with the Billing Automatic Message Accounting Format Advisory Group (BAFAG) playing the central role in the overall approval and administration of BAF records. The BAFAG consists of subject matter experts and representatives from the Telcordia Systems Engineering Business Unit who review and authorize any proposed BAF element. A template entitled Billing AMA Format (BAF) Request Form is available for the industry to use as a convenient guide and checklist to ensure that all possible requirements and NEs are addressed in the BAF proposed format. This form is available from the BAF Manager by (m-bafmgr@notes.cc.telcordia.com). The Service Description field on the request form should contain a service/ technology/nes description and the proposed billing strategy. The Explanatory Text fields on the request form should contain further information regarding the billing of the usage aspects of the defined service/technology/nes. Each proposed Table, Structure, Call Type Code, and Module should be accompanied by a statement of the conditions under which each is generated. Table 3-6 identifies the LEC-assignable ranges. The BAF elements assigned within these ranges are not administered by Telcordia. They are specifically reserved for LEC use. Each LEC has full control, discretion, and responsibility for the assignment and administration of the values recorded in the BAF elements within these ranges. Table 3-6 LEC-Assignable Ranges for BAF Elements BAF Element LEC-Assignable Range Structure Codes Call Type Codes Module Codes BAF Tables AMA planners, designers, and those responsible for processing AMA data should be in contact with Telcordia BAF management when working on propositions for new BAF records. The process of requesting new elements involves contacting the BAF Manager to explain the needed elements and the conditions under which they are generated. The appropriate forms will be sent via to the requester for BAF assignments. The BAFAG will discuss the request at the next scheduled monthly BAFAG meeting. Telcordia will review the request to help ensure consistency in the BAF syntax across network services and functions, and to help ensure that the syntax is used in the most efficient way possible. Examples of other considerations requiring discussion are error conditions, use of fill and flag procedures, whether a requested new element is the right size to accommodate potential future growth, whether the 3 22

51 Issue 1, May 2001 Notes on Billing Generating Usage Measurements circumstances calling for a requested new element could instead be served by an existing element, and whether a requested new element could be made more generic to accommodate future use by another service or function. Companies that formally fund the BAF Management project and requesters of BAF assignments will have the opportunity to participate in the BAFAG meeting (for the month in which the requested BAF assignments are made) via conference call. Any and all BAF assignments made by Telcordia are public and will be published in the following version of GR-1100-CORE. In order to effectively formulate BAF records, one must have a thorough understanding of the AMA process. A description of this process can be found in GR-508-CORE. 3 23

52 Notes on Billing Issue 1, May 2001 Generating Usage Measurements 3 24

53 Issue 1, May 2001 Notes on Billing Call Detail Recording 4 Call Detail Recording Section 4 provides a comprehensive overview of the switch-based call detail recordings for local service, toll service, and network interconnection, including both exchange access and Connecting Network Access (CNA) recordings. 4.1 Network Recording Points Network recording for services provided to an end user is generally performed in the end office switch serving that end user. The basic recording philosophy for circuit switches is to generate a single AMA record as close to the network source of the call origination as possible. While this recording philosophy is slowly changing as the Next Generation Network (NGN) switches are introduced and call processing becomes more distributed, by and large, local calls, long distance calls, and service requests are recorded in the switch serving the end user. Other LEC End Office to Local/Toll Other LEC End Office to Local/Toll CNA Like FGD IC/INC IXC- InterLATA PIC1 IntraLATA PIC2 101XXXX FGB FGD LEC Tandem 10 9 CAMA Type 2A WSP or Other LEC End Office Local/Toll LEC Local/Toll/Access Tandem No AMA NCEO LEC End Office to Local/Toll CNA Tandem Trunk Groups Interoffice Trunk Groups Exchange Access Trunk Groups LEC End Office-1 Figure 4-1 Typical LEC Recording Architecture for Toll Calls Any LEC owning end office switches and tandems is required to interconnect with any Interexchange Carrier (IC), International Carrier (INC), or other interconnecting entity such as another LEC or a Competitive Access Provider (CAP). Generally, measurements need to be taken at the interface between the 4 1

54 Notes on Billing Issue 1, May 2001 Call Detail Recording interconnected entity and the LEC so that identification of the appropriate carriers can be assured. Consequently, usage measurement, in the form of AMA recordings, is a critical function of the end office, the Access Tandem (AT), the Toll Tandem, and the Local Tandem switches that serve as the Point of Interconnection (POI) for these interconnecting entities Recording Architecture Figure 4-1 illustrates a high level recording architecture for toll calls that could be considered typical for a LEC in the United States. Note that this illustration does not include any representation for calls that access a database, such as toll-free service calls or Advanced Intelligent Network (AIN) calls. Table 4-1 lists the Call Type Code (CTC) and Structure Code (SC) associated with the recording architecture illustrated in Figure 4-1. Table 4-1 Typical Recording Architecture - Call Types and Structures Recording Location Description 1 End Office Interexchange Toll - FGD 2 End Office Connecting Network Access 3 End Office Connecting Network Access 4 End Office Interoffice Toll IntraLATA LEC 5 End Office WSP / LEC-LEC Type 2B 6 End Office Interexchange Toll - FGB 7 Tandem Interexchange Toll - FGD 8 Tandem WSP /LEC-LEC Type 2A 9 Tandem CAMA - FGD CAMA - Toll 10 Tandem Interoffice Toll IntraLATA LEC 11 Tandem Interoffice Toll IntraLATA LEC Originating (Outgoing) Call Type Code Originating (Outgoing) Structure Code Terminating (Incoming) Call Type Code Terminating (Incoming) Structure Code CTC 110 SC 0625 CTC 119 SC 0625 CTC 006 SC 0001 CTC 720 SC 0625 CTC 720 SC 0625 CTC 063 SC 0625 CTC 065 SC 0625 CTC 134 SC 0625 CTC 119 SC 0625 CTC 064 SC 0625 CTC 066 SC 0625 CTC 110 CTC 006 SC 0625 SC

55 Issue 1, May 2001 Notes on Billing Call Detail Recording Table 4-1 Typical Recording Architecture - Call Types and Structures (Continued) Recording Location Description Originating (Outgoing) Call Type Code Originating (Outgoing) Structure Code Terminating (Incoming) Call Type Code Terminating (Incoming) Structure Code 12 Tandem Connecting Network Access 13 Tandem FGD-like LEC-LEC Interconnection 14 Tandem Interexchange Toll - FGB CTC 720 SC 0625 CTC 119 SC 0625 CTC 135 SC Centralized AMA (CAMA) The AMA data for calls from end offices that lack recording capability is controlled, collected, and recorded at a Centralized Automatic Message Accounting (CAMA) recording location. CAMA calls may originate from a local switching system that does not have local AMA (LAMA) recording capabilities or, they may originate from lines that are located on a local switching system that has the LAMA feature, but for which the switching system cannot automatically identify the directory number of the originator (for example, those calls originated by 4- and 8- party lines served by the local switching system). For these cases, the calls must be connected to an operator for manual identification and input of the originatingstation directory number. To facilitate recording at this centralized point, a CAMA trunk group was established between the end office and the recording switch (usually a tandem), that had Automatic Number Identification (ANI) and/or Operator Number Identification (ONI) signaling capability. The traditional CAMA function has been replaced by the combination of operator services systems and local AMA recording in end offices. However, CAMA trunk groups can still be used for two specific applications: 1. E9-1-1 trunks incoming to the E9-1-1 tandem and 2. trunks with ANI from a Private Branch Exchange (PBX) or from carriers that do not use SS7 trunks. An incoming inband signaling CAMA trunk group is sometimes referred to as a Feature Group C Trunk with ANI. The switching system having the CAMA recording function is typically a tandem switching system that is equipped with the AMA features. The tandem switching system is also equipped with the ANI and ONI features. For operation with CAMA, the local switching system should be capable of outpulsing the calling-line identity of lines requiring ANI of the originating number. AMA data recorded at a CAMA recording location is, in general, identical to that recorded at a LAMA recording location. 4 3

56 Notes on Billing Issue 1, May 2001 Call Detail Recording 4.2 Recording for Local Service Local calling area tariff-implementation parameters refer to parameters that affect the generation of AMA data for calls using services offered within a defined local calling area. A local calling area consisting of a group of destination codes (a destination code is a combination of a Numbering Plan Area (NPA) and NXX Code (NPA-NXX) or simply an NXX) may be defined for a particular NXX served by the local switching system. The set of destination codes is chosen from the Home Numbering Plan Area (HNPA) and the Foreign Numbering Plan Areas (FNPAs). Typical services offered within a local calling area are listed in Table 4-2 and include Flat Rate Service, Message Rate Service, and IntraLATA Toll Service. InterLATA Toll Service is provided by an IC or, in some instances, may be provided by the local service provider. Table 4-2 Common AMA Call Type Codes for Telephony Services Type of Service Basis for Charging Call Type Code(s) Measurement Called Number in AMA Flat Rate Monthly Fee N/A None required No Detailed Measured Service Measured using MBI Toll - IntraLATA Toll - InterLATA time, distance, or time and distance time, distance, or time and distance CTC 001 CTC 003 CTC 005 CTC 006* CTC 002 CTC 004 Detailed Message Rate, Timed, with MBI Detailed Message Rate, Untimed, with MBI Detailed Message Rate, Timed, No MBI Station Paid - Detailed, Timed, No MBI Message Rate, Timed, with MBI Message Rate, Untimed, with MBI time and distance CTC 006 Station Paid - Detailed, Timed Yes time and distance CTC 110 Interexchange Station Paid - Detailed, Timed *CTC 006 is used by some companies for measuring local calls. Yes No Yes Flat Rate Service A flat-rate area is defined by a group of destination codes (NXX or NPA-NXX) and usually includes all the destination codes within a geographic boundary. A flat rate service permits non-coin line customers having the appropriate charge class to make, for a fixed monthly charge, an unlimited number of network uses of services or calls to destinations within a flat-rate area. For calls originated from lines having the flat-rate charge class, AMA data is normally not required for a call to a destination within the originator s flat-rate area. However, capabilities are provided for individual and multi-party lines to generate detailed AMA data for special studies and for supplementary billable features. 4 4

57 Issue 1, May 2001 Notes on Billing Call Detail Recording Note: The potential introduction of location portability outside of the rate center will impact the flat-rate billing model. For more information, see the LNP generic requirements in GR-2936-CORE, Local Number Portability Capability Specification: Service Provider Portability and GR-2982-CORE, Local Number Portability (LNP) Capability Specification: Location Portability Measured Rate Service A measured rate service provides customers, who have the appropriate charge class, with a limited amount of call usage to destinations within a defined messagerate area for a basic monthly charge. All usage for calls to destinations within the defined area that exceed the limit is additionally charged. Computation of the allowed and additional usage may be based on any combination of the following factors: distance called, call duration, frequency of calling, time of day/day of the week (and/or date). The data generated for local message-rate calls is formatted into a message-rate call type. The call type to be used for recording the AMA billing data for a particular call is a function of the data that is necessary for the billing tariffs that determine the charges for that call as illustrated in Table 4-2. For purposes of this document, message-rate calling is differentiated by whether or not the called number (terminating number) is populated in the BAF structure code. Call detail on customer bills is not captured when using certain call type codes Message-Rate Call Types CTC 001 through CTC 005 have been specifically designed for recording AMA data for message-rate calls. They indicate to a Revenue Accounting Office (RAO) whether call duration, distance, and Message Billing Index (MBI) values should be considered for billing treatment. The particular call type code chosen for a given message-rate call is determined by what AMA data is needed for the local tariffs and billing agreements that determine the charges for the call. It is a LEC s responsibility to correctly set translations regarding tariff-implementation parameters so a BAF record with the proper message-rate call type code can be generated, given such factors as local calling areas and dialed digits. To decrease processing time, transmission time, and storage requirements, message-rate calls are frequently recorded using high runner call type codes with short format structure codes Message-Rate Service with Call Detail CTC 001 and associated structures are used if a message-rate call is charged for the elapsed time of the call and distance between the calling and called lines. Both the called number (BAF Tables 16 and 17) and the MBI field (BAF Table 29) are populated in the BAF record. 4 5

58 Notes on Billing Issue 1, May 2001 Call Detail Recording The MBI value can be used by the RAO to determine the billing treatment for the call. For example, an MBI of 023 might be used by a LEC to indicate the following: The call is eligible for an initial connection period of 5 minutes. The number of message units to be charged for the initial period is 2. Every 2 minutes of the call duration after the initial period is calculated as a message unit. The switch performs the calculation of the MBI as the call is in progress and populates the MBI at the end of the call for use by the billing system. The called number is also available if a company desires or is required to supply call detail information on the end user bill. CTC 001 Detailed Message Rate, Timed, with MBI SC 0020 Connected or unconnected SC 0220 Certain AIN calls (see AIN requirements) SC 0502 High runner - connected or unconnected CTC 003 and associated structures are used if local calls are charged for the distance between the calling and called lines, but not for the elapsed time. A specific fixed number of message units is designated for each destination code within the customer's message-rate local calling area. Regardless of the elapsed time, each call to the same destination code (NPA-NXX) is charged for the same number of messages units. The MBI value in the BAF record can be used by the RAO as the specific number of message units to be charged for the call. CTC 003 Detailed Message Rate, Untimed, with MBI SC 0020 Connected or unconnected, full details SC 0024 Connected or unconnected SC 0220 Certain AIN calls (see AIN requirements) SC 0504 High runner - connected or unconnected CTC 005 is used if the call is charged for the distance between the calling and called lines and the elapsed time of the call. However, in this instance the RAO will rely on traditional rating processes and the MBI field is used. Therefore, this call type code will not populate the MBI in the BAF record. CTC 005 itself indicates to the RAO billing treatment for the call. CTC 005 Detailed Message Rate, Timed, No MBI SC 0001 Connected or unconnected SC 0220 Certain AIN calls (see AIN requirements) SC 0500 High runner - connected or unconnected Message-Rate Service Without Call Detail CTC 002 and associated structures are used when local calls to destinations within the customer s message-rate local calling area are to receive the same charge treatment, but are also to be charged based on the elapsed time calculated by the switch. The calculation of time and distance by the switch results in an MBI value 4 6

59 Issue 1, May 2001 Notes on Billing Call Detail Recording that is populated in the MBI field (BAF Table 29) in the BAF record. The MBI value in the BAF record can then be used by the RAO to determine the billing treatment. The called number is not recorded; consequently, no call detail is available for the customer s bill. CTC 002 Message Rate, Timed, with MBI SC 0015 Connected or unconnected SC 0020 Connected or unconnected, full details SC 0220 Certain AIN calls (see AIN requirements) SC 0503 High runner - connected or unconnected. CTC 004 and the accompanying structures are used when local calls to destinations within the customer s message-rate local calling area are charged for the same number of message units regardless of the elapsed time. A specific fixed number of message units is designated for each destination code within the customer's message-rate local calling area. Regardless of the elapsed time, each call to the same destination code (NPA-NXX) is charged for the same number of message units. The MBI value in the BAF record can be used by the RAO to determine the billing treatment. CTC 004 Message Rate, Untimed, with MBI SC 0019 Connected or unconnected SC 0020 Connected or unconnected, full details SC 0220 Certain AIN calls (see AIN requirements) Toll Calls Toll calls are calls to destination codes outside of the originating customer s flatrate or message-rate local calling area but within the LATA. Calls to destination codes outside the originating customer s flat-rate and/or message-rate area are chargeable mainly on the basis of the call destination, the call duration, the day, the date, and the time of the day. For non operator-handled calls originated by 1- and 2-party non-coin lines, the AMA data record is generally generated in the switching office serving the originating customer. The actual form of the record is a function of how the call is to be carried, for example, via the LEC facilities or those of an IC (domestic carrier or INC). For calls that originate from 4- or 8-party lines, the call must route to a centralized point for identification of the calling station. The AMA data record for these calls is made at that point Toll Recording - IntraLATA Normally, a direct-dialed, station-paid, intranetwork toll call (both 7 and 10 digits), should generate a record containing the Station Paid call type (CTC 006 in GR CORE). Requirements for toll calls originated from other than normal telephone lines are covered in various Telcordia service/technology generic requirements documents. 4 7

60 Notes on Billing Issue 1, May 2001 Call Detail Recording For example, requirements for Outward Wide Area Telecommunications Service (OUTWATS) are included in GR-601-CORE, LSSGR: Outward Wide Area Telecommunications Service (OUTWATS), FSD OUTWATS toll calls record unique call type codes (CTC 007 or CTC 068 in GR-1100-CORE) to identify the OUTWATS service to the RAO IntraLATA Toll Presubscription The IntraLATA Toll Presubscription (ITP) switch feature enables the telephone company to associate a carrier for IntraLATA toll calls with each subscriber s line, on a presubscription basis, in a manner similar to Primary (or Presubscribed) Interexchange Carrier (PIC) for InterLATA toll calls. IntraLATA toll calls previously were carried either exclusively by the LEC or, if IntraLATA toll competition was authorized, by alternative carriers only after dialing a Carrier Access Code (CAC) (101XXXX). GR-690-CORE, LSSGR Exchange Access Interconnection, FSD , defines the switching system feature requirements for ITP and calls this feature PIC2. The FCC identified the PIC2 feature as critical to addressing the dialing parity conditions of the Telecommunications Act of 1996 (TA96). Many jurisdictions throughout the United States have had IntraLATA toll competition for some time and the network interface used is switched access Feature Group D (FGD). The PIC2 presubscription feature does not require any AMA modifications when the carrier identified as the PIC2 carrier is other than the LEC LEC as Toll Carrier This section discusses the case where the LEC continues to be designated as the IntraLATA toll carrier. The LEC may be chosen as the PIC2 carrier for any of the following reasons: The end user subscriber has chosen the LEC as the PIC2 carrier. The end user subscriber has consciously chosen not to select a PIC2 carrier and the LEC is designated as the PIC2 carrier because of regulatory requirements that a PIC2 carrier be present for every subscriber -- Mandatory PIC2. A PIC2 designation is not required for every end user subscriber and those subscribers that do not choose to select a PIC2 carrier have their calls carried by the LEC (as they were prior to the PIC2 option) -- Non-mandatory PIC2. An important point for the discussion of PIC2 where the LEC is the carrier, is that the incumbent LEC networks have not had to convert from the present signaling and transmission architecture to a FGD architecture for IntraLATA toll calls. This means that current traditional Multifrequency (MF) signaling or exchange Signaling System 7 (SS7) (as specified in GR-317-CORE, LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP)) will continue to be used to 4 8

61 Issue 1, May 2001 Notes on Billing Call Detail Recording switch IntraLATA toll calls on the LEC networks. The AMA records generated for this type of network arrangement are subscriber-related and do not currently capture carrier-related information. Capturing carrier-related information for IntraLATA toll calls may be necessary depending on regulatory requirements. Single LATA A EAEO-1 LEC Toll Tandem EAEO-2 B Non-EAEO-4 EAEO-3 C Access Tandem LEC IntraLATA Toll TGs Access TGs (FGD) D Inter-tandem TG (Special Purpose) ICs Figure 4-2 LEC IntraLATA Toll Network Figure 4-2 illustrates three situations where IntraLATA competition and PIC2 may or may not be applicable: 1. In a LATA that has not introduced either IntraLATA competition or PIC2, when Subscriber A calls Subscriber B, the call is transported by the LEC over IntraLATA toll trunks, and, in this case, transported through a LEC toll tandem switch. Traditional signaling and trunk transmission specifications are used for this call. The LECs do not use FGD signaling and transmission specifications for intranetwork calls. Consequently, the AMA record for this call recorded at the originating Equal Access End Office (EAEO) switch (EAEO-1) remains CTC 006 in accordance with the latest version of GR-1100-CORE. 4 9

62 Notes on Billing Issue 1, May 2001 Call Detail Recording 2. In LATAs where IntraLATA toll competition has been introduced but PIC2 has not, IntraLATA toll calls dialed by subscribers without a CAC (i.e., 101XXXX) will [continue to] be handled by the LEC and recorded as described above. To date, there has been no request by the LECs to change the AMA generated at the originating end office when IntraLATA toll competition is present. 3. In LATAs where ITP has been mandated as an extension of IntraLATA toll competition, the LEC may be designated as the IntraLATA Toll Carrier by the subscriber or by rule. This designation may take any of the following forms: Presubscription, i.e., the LEC is the PIC2 carrier CAC dialed, i.e., the subscriber dials the 101XXXX code of the LEC Carrier of last resort, i.e., by rule and/or arrangement, the LEC transports the call. Additional carrier related information may need to be appended to the existing AMA record (CTC 006). When ITP is in effect in the LATA, the LEC owning the originating switching system can activate a switching system option that will append Module 021 to the AMA record normally generated for intralata toll calls carried by the LEC. Module 021 provides carrier-related information such as Carrier Identification Code, Carrier Timing (Connect and Elapsed), Trunk Group Number, Routing Indicator, Dialing and Presubscription Indicator, and ANI/Calling Party Number (CPN) Calls to N11 Codes Service codes, commonly called N11 codes because of their format, are used to provide three-digit dialing access to special services. In the U.S., the Federal Communications Commission (FCC) working through the North American Numbering Council (NANC) administers N11 codes, and recognizes only 211, 311, 511, and 711 as nationally assigned. Other codes have traditional uses as shown in Table 4-3 below. Table 4-3 N11 Codes in the North American Numbering Plan N11 CODE DESCRIPTION 211 Community Information and Referral Services (U.S.) 311 Non-Emergency Police and Other Governmental Services (U.S.) 411 Local Directory Assistance 511 Traffic and Transportation Information (U.S.); Reserved (Canada) 611 Repair Service 711 Telecommunications Relay Service (TRS) 811 Business Office 911 Emergency 4 10

63 Issue 1, May 2001 Notes on Billing Call Detail Recording In some states, N11 codes that are not assigned nationally may be assigned locally, provided that these local assignments can be withdrawn promptly if a national assignment is made. There are no industry guidelines for the assignment of N11 codes in these instances. The only N11 code that will normally generate AMA is 411 Local Directory Assistance AMA for Directory Assistance Local calls to Directory Assistance (DA) can be generated at the local end office or at the Operator Services System (OSS) where the DA service is provided. The OSS recording for DA service (CTC 194) is described in Section The local end office should provide the LEC with the capability of turning the generation of DA call BAF records on/off. If end office recording is turned on, the following describes the DA recording in the end office. LECs use a variety of dialing plans to reach DA. DA service may be accessed by one of the following dialing arrangements: A 3-digit code, 411, for local area DA service A 7-digit code, , for HNPA DA service A 10-digit code, NPA , for Home NPA (HNPA) DA service A 10-digit code, NPA , for Foreign NPA (FNPA) DA service when the Foreign NPA is an IntraLATA NPA (considered local) A 10-digit code, NPA , for Foreign NPA (FNPA) DA service when the Foreign NPA is an InterLATA NPA (considered Exchange Access). When an end office option to record local DA calls is turned on, one of the AMA call type codes in Table 4-4 is generated based on the dialing pattern used. Note that when an InterlATA FNPA number is dialed, the end office will always generate SC 0625 / CTC 110. Table 4-4 End Office AMA for Calls to Directory Assistance Call Type Code CTC 009 CTC 033 CTC 006 Dialing Pattern 3-digit code digit code digit code HNPA Structure Code SC 0028 Description CTC 009 indicates to the RAO that a 411 call has been dialed. This record does not capture the terminating number (411). SC 0028 CTC 033 indicates to the RAO that a call has been dialed. This record does not capture the terminating number ( ). SC 0001 CTC 006 is generated for 10-digit calls to HNPA The HNPA number is captured. 4 11

64 Notes on Billing Issue 1, May 2001 Call Detail Recording Table 4-4 End Office AMA for Calls to Directory Assistance (Continued) Call Type Code Dialing Pattern Structure Code Description CTC digit FNPA (Local) 10-digit FNPA (IC Call) SC 0001 CTC 006 is generated for 10-digit calls to FNPA when the FNPA is IntraLATA. The FNPA number is captured. CTC 110 SC 0625 CTC 110 is generated for 10-digit calls to FNPA when the FNPA is InterLATA. The FNPA number is captured. Additional switch-based AMA records may be generated for calls to DA. These can result from calls to DA from certain types of lines or studies. For example, an intrastate OUTWATS line, permitted to call DA, would generate a CTC 007 or CTC 068 (depending upon whether it is translated as a Wide Area Telecommunications Service (WATS) Bill Number or WATS Station Number line) in addition to the DA AMA record. The WATS AMA record is used to bill for WATS usage to the end user, while the DA record is used to bill for the DA service. Another example would be when a flat rate customer with originating Subscriber Line Usage Study (SLUS) activated calls DA. Because no switch-based record is normally generated for the call, a CTC 067 is recorded to provide the study information. Rules for populating the terminating number fields (BAF Tables 15, 16, and 17) of these switch-based records generated for calls to DA are identified in GR CORE. An example of these rules would be an OUTWATS line dialing 411 to reach DA. In addition to the SC 0028/CTC 009 used to bill the DA service, an SC 0020/CTC 068 would also be generated to provide billing capability for the WATS usage. 4 12

65 Issue 1, May 2001 Notes on Billing Call Detail Recording 4.3 Recording for Local Interconnection Interfaces The usage measurement recording performed on call connections between LECs depends on the type of network interconnection being used. Common forms of LEC-to-LEC interconnection are described below Standard Trunk Connections In this case, LEC-to-LEC interconnection is achieved using the same type of trunk arrangements used for calls completed within a LEC network. These trunks are not designed for interconnection or exchange access usage measurement recording, but may be used in situations where interconnecting carriers agree to bill and keep revenue for calls originating within their networks. The bill and keep arrangement avoids the need for intercarrier compensation for calls involving multiple LECs. If the interconnecting trunks use Common Channel Signaling (CCS), a Link Monitoring System (LMS) may be used to monitor and record usage on the internetwork facilities Feature Group D-Like With this interconnection arrangement, incoming trunk groups to a LEC from another LEC are provisioned to generate terminating Feature Group D (FGD) AMA records, i.e., SC 0625 / CTC 119, at either an end office or intermediate switch. The traffic over these groups is generally local traffic or intralata toll traffic and not Exchange Access FGD traffic. Trunk groups were provisioned this way in order to generate AMA call detail records for reciprocal compensation purposes. To generate the CTC 119 records, companies often provision an unassigned CIC on the trunk group to distinguish the AMA records from legitimate FGD access recordings. The billing systems processing FGD AMA records must closely examine each record received to determine whether the call involved an interlata or intralata connection. Many companies have moved away from this approach and now use either Connecting Network Access (CNA) trunk groups or Wireless Services Provider (WSP) trunk groups in order to generate these records Connecting Network Access (CNA) The CNA mode of interconnection was originally designed to address AMA recording needs for LNP. The industry requirements for number portability defined a new AMA capability for recording an incoming call on a trunk group that previously did not generate an incoming recording. 4 13

66 Notes on Billing Issue 1, May 2001 Call Detail Recording FGD Dedicated TG IC LEC-1 End Office FGD Common TG LEC-2 Tandem LEC-2 End Office Local/Toll TG Local/Toll TG CNA Recording of Incoming Calls Figure 4-3 CNA Recording Example As illustrated in Figure 4-3, a Connecting Network Access record is made on an incoming basis on any local/toll trunk group that interconnects with another network. Thus, SC 0625 / CTC 720 is generated at the LEC-2 tandem switch for an incoming call from the LEC-1 end office. In addition, LEC-1 has the capability to record all incoming calls to its end office from the LEC-2 tandem switch. The population rules for the CTC 720 CNA record are detailed in the TRQ No. 2, Technical Requirements for Number Portability - Switching Systems [Alliance for Telecommunications Industry Solutions (ATIS)] requirements document, published by ATIS in 1999, with the stipulation that any field not specifically covered should be populated per GR-1083-CORE, Generic Requirements for Exchange Access Automatic Message Accounting (AMA), FSD It is important to note that the recording requirements for CNA do not apply to usage records generated on FGD, FGB or WSP (Type 2A and Type 2B) trunk groups Other Interfaces Wireless Service Provider (WSP) interconnection In this case, the network interconnections originally designed for access between a LEC and a wireless carrier are used for LEC-to-LEC interconnections. The WSP interconnections consist of Type 1 (line side), Type 2A (trunk side/tandem), and Type 2B (trunk side/ end office). See Section 4.5 for more detail. 4 14

67 Issue 1, May 2001 Notes on Billing Call Detail Recording 4.4 Exchange Access Recording AMA records are generated for Interexchange Carrier (IC) or International Carrier (INC) calls leaving the LATA in the originating direction and IC/INC calls entering the LATA in the terminating direction. This includes calls routed to an Operator Services System (OSS) facility and test calls made by an IC/INC to a LATA Switched Access Service Switched access service provides a two-point communications path between the access customer terminal location and telephone exchange service location. Each path is capable of the transmission of voice with inband signaling or in combination with CCS/SS7 [as defined in GR-394-CORE, LSSGR: Switching System Generic Requirements for Interexchange Carrier Interconnection (ICI) Using the Integrated Services Digital Network User Part (ISDNUP)] and associated telephone signals within the frequency bandwidth of approximately 300 to 3000 Hz. Switched access includes all access arrangements that use an end office switching system to establish public switched connections between the access customer s Point of Presence (POP) and its end user customers Types of Switched Access Available The LECs offer an access customer a choice of several switched access arrangements. The access customers select from the available access arrangements and use the one that meets their technical and business needs. Four separate switched access arrangements, called feature groups, have been defined. Each feature group is distinguished by its standard operational capabilities. Supplemental features are also offered that allow an access customer to customize, within limits, the standard arrangements. Brief descriptions of the feature groups, their various standard arrangements, and their supplemental features follow. Also available as part of Access Service is 900 Access Service, 500 Access Service, and Toll-Free Access Service Feature Group A (FGA) Feature Group A (FGA) is a 2-wire, line-side connection between the access customer and the end office. This includes, but is not limited to, arrangements used to provide Message Telephone Service (MTS)/Wide Area Transmission Service (WATS), internetwork Foreign Exchange (FX) service and internetwork offnetwork access lines from private networks. Subscribers typically dial a 7-digit Directory Number (DN) to reach an access customer; receive a second dial tone from the access customer; enter a password (often needed to satisfy accounting requirements); and dial a second number that is the called-party s directory number. 4 15

68 Notes on Billing Issue 1, May 2001 Call Detail Recording FGA typically uses Dual-Tone Multifrequency (DTMF) signaling in accordance with access customer specifications. The standard features offered by FGA access arrangements are dial tone (originating service), dial-pulse address signaling, and line-side terminating service. Other features offered by FGA access arrangements are DTMF address signaling, multiline hunting, Uniform Call Distribution (UCD), call restriction (toll restriction), and dial-code (3- or 6-digit) screening. LEC Tandem LEC Interoffice Facilities IC End User End User Line Termination LEC End Office FGA Serving Office (LEC) FGA Carrier Line Termination Figure 4-4 Feature Group A -- Line-side Access Service Figure 4-4 illustrates the basic FGA network arrangement. All AMA recordings for FGA are generated at the switch serving the FGA carrier. Originating calls (i.e., to the FGA carrier) are recorded on an incoming basis at the FGA Serving Office. SC 0079 / CTC 131 is generated. Because of the terminating nature of this call and the fact that recording is done on an incoming basis, the only number recorded in the SC 0079 is the FGA number. The CPN is not captured nor is the number the end user ultimately dials after connection to the FGA carrier. For terminating calls (i.e., from the FGA carrier into the local network) SC 0001/ CTC 132 is generated. FGA terminating records have the FGA carrier s number as the originating number. The called party is also available in the CTC 132 structure. FGA calls are measured by the LEC to determine minutes of use. Minutes of use on an originating FGA call start when the FGA carrier's off-hook indication is received by the LEC and end when the call is disconnected. Minutes of Use (MOU) on a terminating FGA call start when the called party off-hook occurs and end when the call is disconnected. For more information on AMA timing, see GR-508-CORE. 4 16

69 Issue 1, May 2001 Notes on Billing Call Detail Recording The generic requirements for FGA are contained in GR-697-CORE, LSSGR Feature Group A, FSD Feature Group B (FGB) Feature Group B (FGB) is a trunk-side connection between a LEC end office or access tandem switch and a FGB carrier. FGB has a universal 7-digit Carrier Access Code (CAC) of 950-XXXX where XXXX is the FGB Carrier Identification Code (CIC) associated with the participating interconnecting entity. Subscribers dial the 950-XXXX number to reach the FGB carrier, receive a second dial tone from the carrier, enter a password (often needed to satisfy accounting requirements), and dial a second number that is the called-party s directory number. The generic requirements for FGB are contained in GR-698-CORE, LSSGR Feature Group B, FSD The standard features offered with FGB access arrangements include multifrequency trunk signaling, trunk protocols, trunk transmission, and trunk testing. The FGB arrangements also provide connect-and-disconnect supervision. FGB includes 2- and 4-wire trunk terminating equipment and both 2-way and directionalized terminating equipment. The principal supplemental features offered by FGB access arrangements are 7-digit-only Automatic Number Identification (ANI) and rotary-dial station access. These features are only available on direct connections from appropriately equipped end offices. Figure 4-5 illustrates that FGB access service can be provided using either direct or tandem trunk groups between the FGB carrier and the LEC end office. LEC Tandem Routed Tandem Dedicated End User LEC End Office Entrance Facilities Tandem Routed Transport Direct Routed Transport Direct Routed S W C Serving Wire Center IC Figure 4-5 Feature Group B -- Trunk-side Access Service 4 17

70 Notes on Billing Issue 1, May 2001 Call Detail Recording FGB AMA Originating FGB calls (i.e., calls dialed using 950-XXXX) are recorded at the originating end office using SC 0625 / CTC 134. Because of the nature of this call, the switch can capture the billing number (ANI for MF signaling /ChN for SS7) in the SC 0625, and the FGB number as the terminating or called party number. The CTC 134 record cannot capture the actual terminating number because this information is not available to the originating switch. An originating FGB call for which no FGB carrier off-hook is received is considered unconnected. For an unconnected FGB call, no AMA record is generated unless it is done for study purposes. For terminating calls (i.e., from the FGB carrier into the local network) SC 0653/ CTC 135 is generated for interconnecting trunk groups using MF signaling. For trunk groups provisioned with SS7, terminating FGB records can be recorded with CTC 135 and SC 0625 in order to capture all available signaling information. FGB terminating records have the FGB carrier s number as the originating number field and the called party in the terminating number field of the CTC 135 structure. FGB calls are also measured by the LEC to determine minutes of use. Minutes of use on an originating FGB call start when the FGB carrier's off-hook indication is received by the LEC and end when the call is disconnected. Minutes of use on a terminating FGB call start when the called party off-hook occurs and end when the call is disconnected XXXX Dialing Over FGD Trunk Groups Some LEC networks may provide a capability for dialing 950-XXXX calls by way of FGD (described in Section 4.4.4) type connections. Originally this capability was intended for carriers that used the 950 dialing plan but wanted to transition over to FGD exchange access. This was called the transition plan. This transition evolved into what now is commonly known as 950-XXXX dialing-over-fgd. As a result of this interaction between FGB and FGD, a special AMA record was developed to distinguish normal originating FGB exchange access records, FGB Transition records, and originating FGD exchange access records. For an originating FGB Transition call, the FGB or FGD serving switch shall generate SC 0625 / CTC 110 (as opposed to CTC 134). The Dialing Indicator field (BAF Table 85) is populated with a value of 3 to indicate a 950-XXXX number was dialed. The Terminating NPA field (BAF Table 16) and Terminating Number field (BAF Table 17) is populated with the 950-XXXX number that was dialed by the user. Finally, the call shall be timed as a FGD call with a Carrier Connect Time and Date generated as specified in GR-1083-CORE and customer Connect Date and Time generated as the time the FGB carrier off-hook is received. Table 4-5 summaries the call type codes and structure codes for FGA and FGB recording. 4 18

71 Issue 1, May 2001 Notes on Billing Call Detail Recording Table 4-5 FGA and FGB Call Type Codes and Structure Codes Description Call Type Code Structure Code Originating FGA Terminating FGA Originating FGB Terminating FGB /0625 Originating 950-XXXX over FGD Feature Group D (FGD) Feature Group D (FGD) access service is the equal access feature group. FGD provides trunk-side access to Telephone Company end office switches for the customer s use in originating and terminating interexchange communications. As illustrated in Figure 4-6, FGD arrangements are provided through appropriately equipped, Stored Program Control (SPC) or electromechanical end offices either on a direct-trunk basis or through access tandem offices. The switch trunk equipment may be provided with multifrequency (MF) wink-start pulsing signals, and answer and disconnect supervisory signaling, or without signaling when CCS is used with the SS7 protocol. FGD allows any telephone served by an appropriately equipped end office to place an interlata call through an IC/INC by dialing a uniform 7-digit access code (101XXXX), followed by prefix digits 0 or 1 when necessary, and then by the standard 7- or 10-digit directory number. Carrier Access Code (CAC) dialing is not required for interlata calls to an IC/INC over FGD service when the end user invokes their Primary Interexchange Carrier (PIC or PIC1) from a line presubscribed to that same IC. The standard FGD offering includes signaling protocol, transmission, and testing associated with trunk-side interconnection. It also includes connect-anddisconnect supervision and, at the LEC s discretion, 2- and 4-wire, trunkterminating equipment, and/or both 2-way and directionalized trunk equipment. Several supplemental features are associated with FGD, such as WATS screening, international dialing options, 10-digit ANI, ANI Information Digit Pairs (ANI II / Originating Line Information parameter for SS7), and features used in connection with operator services FGD Dialing Feature Group D allows the end user to select an IC/INC via presubscription or on a per-call basis. With presubscription, the dialing procedure is the traditional (0/1) 4 19

72 Notes on Billing Issue 1, May 2001 Call Detail Recording + 7/10 digits. The dialing procedure to specify an IC on a per-call basis is 101XXXX + 1/0 + 7/10 digits. An IC/INC must have an assigned CIC to use either FGB or FGD service. For further information on the FGD technical interface, see GR-690-CORE, LSSGR Exchange Access Interconnection, FSD Access Tandem Serving Wire Center End User EAEO Tandem Routed S W C Dedicated IC-1 End User EAEO Direct Routed S W C IC-2 Serving Wire Center End User EAEO Entrance Facilities Tandem Routed Transport Direct Routed Transport Figure 4-6 Feature Group D -- Trunk-side Equal Access Service FGD Recording Detailed billing records are made on a per-call basis whenever an IC/INC exchange accesses the LEC network. This includes calls that originate from the LEC to the IC/ INC and calls that leave the IC/INC network for disposition by the LEC. LECs have the option of providing connections directly to the end offices that have this feature or connection via AT switches. All originating access attempts to the IC/INC are recorded for carrier connect time. The IC/INCs may be assessed usage-sensitive access charges based on the amount of access to and/or from the LEC network. These charges are based on the tariffs and billing agreements arranged by the LEC providing the EAEO services, which provides presubscription capability for end users and capability to use either MF or SS7 equal access signaling or both. LECs may also perform billing functions for the interlata or intralata services of any IC/INC. These billing functions can include all or any recording, RAO entry, rating, bill rendering, collection, and treatment. 4 20

73 Issue 1, May 2001 Notes on Billing Call Detail Recording The approach taken in arriving at the form of the AMA internetwork access records was to combine the information normally recorded in the resulting AMA records (e.g., information recorded for a station paid, WATS, or other type of call) with information that can be used to determine access charges to the IC/INC involved in the call Originating FGD AMA Records Per-Call AMA Data Records In a multifrequency signaling environment, an originating-call AMA record is made for calls that progress to the stage where the carrier-connect signal is received from the IC/INC. The time at which the leading edge of this carrier-connect signal is received from the IC/INC is used as the carrierconnect time for the originating LATA. For call set-up using CCS/SS7, the Initial Address Message (IAM) is sent directly from the Service Switching Point (SSP) end office to the IC/INC to start timing. If an access tandem switch is involved in the call, then the Exit Message (EXM) sent from the access tandem to the end office SP/SSP indicates that the call setup information has actually been sent to the IC/INC. In either the multifrequency or the CCS/SS7 case, the AMA data record contains a called-party answer time as well as the carrier-connect time. In addition, the AMA data record contains the identity of the carrier that is dialed or the presubscribed carrier. The elapsed time from answer time to disconnect is used for billing the customer for the call; the elapsed time from carrier-connect time to disconnect is used for billing the IC/INC access charges. Calls to an IC/INC OSS facility are handled differently. An access record is generated at the EAEO for calls routed directly to an IC/INC operator-service facility. Some IC operator switches do not pass back answer supervision to the EAEO. In these cases, the switch will generate unanswered call records, and will base the call disconnect time for carrier elapsed time calculations on the time of operator release. Originating-LATA overflow record AMA data records are generated for calls that reach the point where the carrier-connect signal is received. AMA records are also generated to provide a count of the number of calls that cannot be delivered to the IC/INC because an outgoing trunk is not available. This overflow record is generated every hour and is output only at the originating LATA. For an IC/INC with only a direct connection from the EAEO, the overflow count is incremented whenever a call cannot be delivered to the IC/INC because an outgoing trunk is not available. For an IC/INC with both a direct connection from the EAEO and an overflow connection to the access tandem, no count of calls that overflow to the access tandem or calls that are blocked (direct and tandemconnection busy) is made at the EAEO. An overflow count is incremented in the hourly record generated at the IC/INC access tandem for calls that do not complete because an outgoing trunk is not available from the access tandem to the IC/INC. 4 21

74 Notes on Billing Issue 1, May 2001 Call Detail Recording The generation of this record is based on the premise that a single LEC will be handling the originating LATA portion of each call. Since competition for intralata call traffic has increased, the LECs will not be the only carriers transporting these calls. There may be other carriers of intralata traffic that do not require this record. It should be noted that another type of record(s) may be needed to address the new intralata carriers. Table 4-6 lists the valid originating and terminating call type codes and structure codes for FGD. Table 4-6 FGD Call Type Codes and Structure Codes Description Call Type Code Structure Code Originating MTS Originating WATS - Station Number Originating WATS - Billing Number Originating Public Switched Digital Service (PSDS) Originating Toll-Free w/ query - InterLATA w/ IC* Originating Toll-Free w/ query - IntraLATA w/o IC* Originating Toll-Free w/o query** Originating InterLATA Directory Assistance (NPA) Originating 900 Service Access Code (SAC) Originating 500 SAC Originating 700 SAC Terminating MTS Terminating PSDS * Toll-Free Records are recorded only at Service Switching Points with access to the Toll- Free database. ** Unqueried Toll-Free calls should be suppressed by the LEC end office switch. If not suppressed these records should be discarded as unbillable. IC/INC Prefix (BAF Table 57) = Terminating Recording All interexchange calls incoming from an IC/INC that terminate to the LEC network generate an AMA record at the First Point of Switching (FPOS) in the network. The network element responsible for creating the AMA record is the same element that contains the interface of internetwork access. For example, calls that enter the network at an AT will have corresponding terminating exchange access records created at the AT. If the call enters the network at the terminating end office, the 4 22

75 Issue 1, May 2001 Notes on Billing Call Detail Recording terminating exchange access record will be created there. Other AMA records that may have to be generated because of the type of terminating service are generated separately as defined by the requirements for that service. A call should not be blocked when the network element is unable to create the appropriate AMA record. The switching system generates a per-call access record for calls that progress to the stage where an incoming-trunk seizure signal from the IC/INC has been recognized. In all records, the leading edge of this seizure signal is used to determine the recorded carrier-connect time for the terminating LATA. However, only the elapsed time from called-party off-hook time to call disconnect time is used for billing the IC/INC access charges. Terminating exchange access records are generated as CTC 119 unless otherwise specified. Terminating exchange access records typically do not contain dialing/ presubscription indicator, or ANI indicator, and until recently, the calling NPA or calling number. With the increased use of SS7 signaling from end-to-end in the PSTN it is now possible to capture the CPN from signaling when passed from the IC/INC network. SC 0625 should be specified for FGD terminating AMA in translations when SS7 interconnection is used with an IC/INC. In those cases where it is not received, zeros will be populated in the originating number field per BAF requirements Local Number Portability (LNP) Interaction In an LNP environment, an originating exchange access call placed from a portedin number results in an originating LNP module (Module 719) being appended to the originating Exchange Access AMA record generated for that call. Procedures for the generation of Module 719 are described in GR-2936-CORE. 1 The procedure for generation of Module 720 is described in TRQ No. 2. In cases where the originating LEC has a contractual agreement with an IC to perform LNP queries on behalf of the IC, the Number Portability (NP) query performed at the originating end office or AT will result in a terminating LNP module (Module 719) being appended to the originating Exchange Access AMA record generated for that call. This module will contain the Location Routing Number (LRN) of the terminating switch. For terminating FGD calls incoming from an IC/INC, it is generally expected that the Number Portability query will have already been performed by the IC/INC. When this is the case, the end office switch or the tandem (whichever is the FPOS in the LATA) appends a Terminating LNP Module to the CTC 119 record. If the query has not been performed and the destination NPA-NXX is a portable NPA-NXX, the entry switch will launch an LNP query per the requirements in TRQ No Supplier development of the number portability feature is based mainly on requirements developed by the industry under the Alliance for Telecommunications Industry Solutions (ATIS). The Telcordia requirements in GR-2936-CORE are referenced only sparingly in deference to the industry requirements. 4 23

76 Notes on Billing Issue 1, May 2001 Call Detail Recording 4.5 Wireless Services Providers (WSP) Interfaces Various switched interconnection alternatives are available for the interconnection of a wireless system with a LEC network. The interconnections are provided using either MF or SS7 signaling. For a detailed description of these interfaces, see the latest issue of GR-145-CORE, Compatibility Information for Interconnection of a Wireless Services Provider and a Local Exchange Carrier Network. These interconnections include the following types: A Type 1 interconnection is a connection through a LEC end office. It provides direct access connections to and from lines, ICs, and other WSPs that terminate within the LEC network. Type 1 also provides a connection with a variation for ISDN interconnection. A Type 2A interconnection is a connection to a LEC tandem. It provides connections to and from lines, ICs, and other WSPs that terminate within the LEC network. A Type 2B interconnection is a connection to a LEC end office and provides connections only to and from directory numbers served by that end office. Generally, a Type 2B interconnection is used by a WSP with a Type 2A tandem interconnection. A Type 2C interconnection is a connection with a LEC tandem arranged for 911 emergency calls. Type 2C calls are routed to a Public Service Access Point (PSAP) to transfer cell site, sector information, and/or subscriber ANI provided by the WSP. A Type 2D interconnection is a connection with a LEC tandem arranged to provide LEC operator assisted calls or DA service. A Type S interconnection is a connection with a LEC Signal Transfer Point (STP). The interconnection interfaces listed were developed to provide the capability to connect Wireless Services Provider (WSP) networks to the wireline PSTN (as illustrated in Figure 4-7). In this document, the network using a Type 1, 2A, or 2B interconnection is referred to as a WSP even though, in some cases, the interfacing networks are both completely wireline. The Type 2A interface is sometimes used for interconnecting a LEC wireline network with another LEC wireline network to take advantage of the usage measurement capabilities that are defined for the Type 2A interface. The LEC owning the tandem will sometimes interconnect another wireline LEC via the Type 2A interface so that both incoming and outgoing usage measurements are generated on the interconnecting trunk groups at the tandem switch. These measurements are used for reciprocal compensation and other intercompany settlements. 4 24

77 Issue 1, May 2001 Notes on Billing Call Detail Recording LEC STP Other LECs Type S OSS/ DA Type 2D E-911 Type 2C Type 1 Other Carriers LEC End Office LEC Tandem Type 2A Type 2B Wireless Switching Office Cell Site Link Radio Links Mobile Unit Points of Interface Trunk Group Signaling Link Cell Site Portable Unit Figure 4-7 Wireless Service Provider Interfaces WSPs provide telephone service to mobile customers via radio links from cell sites connected to mobile telephone switching offices. For these mobile customers to be able to send and receive calls from a LEC and customers of other WSPs, it is necessary to provide an interface between WSPs and telephone company switching systems. LEC charges for WSP access are defined by local tariffs or billing agreements, and any WSP AMA records generated are done so in addition to any AMA records normally made for the service provided. Since the exact nature of charging for WSP calls may vary from network to network, the goal of these specifications is to provide sufficient AMA data to support a variety of arrangements. Table 4-7 lists the AMA call type codes and structure codes applicable for WSP AMA. 4 25

78 Notes on Billing Issue 1, May 2001 Call Detail Recording Type of Call Table 4-7 WSP Call Type Codes Switch AMA Call Type Structure Code Type 1 Originating (Line-side) /0653 Type 1 Terminating (Line-side) Type 2B Originating (Direct TG) /0653 Type 2B Terminating (Direct TG) Type 2A Originating (Tandem TG) Type 2A Terminating (Tandem TG) Originating WSP Calls A call that originates on a LEC network, or is received by a LEC network from an IC/INC (or other interconnecting network), and is routed to a WSP network for final disposition is considered an originating WSP call. WSP calls are considered connected for AMA purposes when the off-hook signal for MF calls or the answer message (ANM) for SS7 calls is received from the WSP at the LEC network element directly connected to the WSP. An originating WSP connection may interact with an existing LEC service before being sent to the WSP. These services are limited only by the business decisions and agreements between the LEC, LEC customers, and the WSP. As a result of this, more than one AMA record may be generated for a call resulting from this type of interaction. For example, the user may use a WATS line to generate a call to a wireless customer. In this scenario, the system that contains the originating user generates a WATS AMA record as defined in the requirements for that service. This condition may result from originating service interaction, a connection interaction with calls that originate on separate networks, or from the connection interaction from carriers accessing the LEC network. If an access call terminates to the LEC network for a connection to a WSP from a FGA, FGB, or FGD carrier, the switch responsible for the interface directly connected to the carrier generates the proper AMA record for that portion of the call according to the latest issue of GR-1083-CORE. The switch connected directly to the WSP also generates an AMA record Terminating WSP Calls Calls that are received from a WSP at the LEC network are considered terminating WSP access calls. A terminating WSP MF call is considered connected for AMA 4 26

79 Issue 1, May 2001 Notes on Billing Call Detail Recording purposes when the off-hook is received at the LEC network element directly connected with the WSP. A terminating SS7 call is considered connected when the ANM is sent to the WSP from the LEC network element directly connected to the WSP. As with originating WSP connections, terminating WSP connections may interact with a variety of services in the LEC network or they may interact with connections to outgoing ICs. This interaction may result in two AMA records being made at the LEC network element directly connected to the WSP, or an AMA record generated at the network element directly connected to the WSP and an AMA record generated at a separate location. When two AMA records are generated, the WSP record will always be generated at the LEC switch directly connected to the WSP. The non-wsp record, if one is to be generated, is generated according to the AMA requirements for that service Type 1 - Line-Side Interconnection Originating Type 1 For Type 1 connections that originate in the LEC network and are routed to a WSP, an AMA record is generated at the LEC switch that controls the point of interface directly connected to the WSP. This AMA record indicates usage over the LEC/WSP interface but may not be the only AMA record generated for the call. The BAF AMA record generated for originating Type 1 connection is a SC 0625 / CTC 063. Older switch generics may still generate SC Terminating Type 1 For Type 1 connections that terminate to the LEC from a WSP, an AMA record is generated at the LEC switch that controls the point of interface directly connected to the WSP. This AMA record indicates usage over the LEC/WSP interface but may not be the only AMA record generated for the call. The BAF AMA record generated for terminating Type 1 connections is a SC 0625 / CTC Type 2B - Trunk-Side Direct Interconnection Originating Type 2B For Type 2B direct connections that originate to a WSP, an AMA record is generated at the LEC switch that controls the point of interface directly connected to the WSP. This AMA record indicates usage over the LEC/WSP interface but may not be the only AMA record generated for the call. When a call originates from a line or a carrier in an office providing Type 2B connections, and all direct trunks to the WSP 4 27

80 Notes on Billing Issue 1, May 2001 Call Detail Recording are busy, the call may overflow to a tandem route provided that there is a Type 2A connection to the WSP from the tandem. The BAF AMA record generated for originating Type 2B connection is a SC 0625 / CTC 063. Older switch generics may still generate SC Terminating Type 2B For Type 2B connections that terminate to the LEC from a WSP, an AMA record is to be generated at the LEC switch that controls the point of interface directly connected to the WSP. This AMA record indicates usage over the LEC/WSP interface but may not be the only AMA record generated for the call. The BAF AMA record generated for terminating Type 2B connections is a SC 0625 / CTC Type 2A - Trunk-Side Tandem Interconnection Originating Type 2A For Type 2A connections, AMA records are generated at the tandem switch responsible for the interface directly connected to the WSP. This AMA record contains the usage data for the connection from the LEC to the WSP but does not contain the usage data from any other connection that resulted from the call, for instance, a connection from another local network, FGB, or FGD carrier. The usage data for these connections must be collected in separate AMA records generated for that purpose at the switch containing the interfaces to that network or carrier. The BAF AMA record generated for originating Type 2A connections is a SC 0625 / CTC Terminating Type 2A For terminating Type 2A connections, AMA records are generated at the tandem switch responsible for the interface directly connected to the WSP. This AMA record contains the usage data for the connection to the LEC from the WSP but does not contain the usage data from any other connection that resulted from the call. For instance, a connection to another local network, FGB, or FGD carrier. The usage data for these connections must be collected in separate AMA records generated for that purpose at the switch containing the interfaces to that network or carrier. The BAF AMA record generated for terminating Type 2A connections is a SC 0625 / CTC 066. For Type 2A connections that terminate to a LEC SSP from a WSP for Toll-Free Service, the system is to generate a SC 0625 / CTC 066 at the SSP directly connected to the WSP. 4 28

81 Issue 1, May 2001 Notes on Billing Call Detail Recording The fields in the SC 0625 / CTC 066 record are to be populated as defined for Type 2A terminating connections except that, for internetwork calls, the IC/INC Prefix field (BAF Table 57) is to contain the CIC of the carrier returned from the Service Control Point (SCP). In addition to the Type 2A records, the SSP generates the proper AMA records for Toll-Free Service. If the call is determined by database query to be Internetwork, the SSP is to generate an AMA record with a SC 0360 / CTC 141 as defined in the latest version of the requirements currently in GR-533- CORE, LSSGR: LSSGR Database Services - Service Switching Points, FSD If the call is determined by a database query to be Intranetwork, the SSP generates an AMA record with a SC 0364 / CTC 142 as defined in the latest version of the requirements currently in GR-533-CORE WSP Interaction with Local Number Portability Calls originating to and terminating from WSPs will incur LNP interaction. Non- WSP exchange carriers using Type 2A and 2B interfaces as a means of interconnection with the LEC will incur the same LNP interaction. Originating and terminating LNP modules (Module 719 or Module 720) must be appended to the WSP AMA records (CTC 063, CTC 064, CTC 065, and CTC 066) generated from these interfaces when LNP is involved. The information recorded in the modules provides the LEC with necessary information to identify and accurately bill customers for charges associated with LNP (e.g., Number Portability Database (NPDB) queries). The rules for populating and appending the LNP modules to WSP AMA records are defined in the TRQ No. 2 document. 4 29

82 Notes on Billing Issue 1, May 2001 Call Detail Recording 4 30

83 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 5 AMA Recording for Special Services Section 5 provides a description of recording for services calls, specifically calls to an Operator Services System (OSS), toll-free service, and calls dialed to a Service Access Code (SAC). In addition, this section covers services invoked either by the end user s terminal equipment, such as CLASS SM services, or programmed at the switch itself, such as Advanced Intelligent Network (AIN) services. It also describes AMA records that the Line Information Database (LIDB) generates. Figure 5-1 illustrates a generic network architecture for special services. SCP SCP SCP Toll-Free Database LIDB Database AIN Database LEC STP OSS/DA LEC LEC End Office Tandem LEC End Office Trunk Group Signaling Link LEC End Office Figure 5-1 Network Architecture for Special Services 5 1

84 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services 5.1 Recording at Operator Services Systems (OSSs) The AMA records generated for calls handled by LEC operator services switching systems are defined in FR-271, Operator Services Systems Generic Requirements (OSSGR). The complexity of the OSS s functions and the unique services and billing options that it provides make it necessary for the OSS to generate an AMA record for each call that it handles. All usage-related data produced by an OSS for processing by a Revenue Accounting Office (RAO) conforms to the Billing AMA Format (BAF) requirements in GR-1100-CORE. The AMA generated for OSS calls is integrated with its call processing. The predefined OSS BAF recording structures, to which modules are appended, contain those parameters common to all or most OSS-provided services. For example, because every call has associated customer-dialed digits, they are recorded in a predefined OSS structure rather than in a service-specific module. Parameters not common to all OSS services are recorded in service-specific, billing-specific, handling-specific, or exchange access modules. Selection of the appropriate predefined recording structure to which modules are appended depends on whether the call arrives at the OSS on an originating or terminating basis, and, for those calls arriving on an originating basis, whether or not an Originating Line Number Screening (OLNS) query is launched. (For detailed information on OLNS, see GR-1173-CORE, OSSGR: Common Functions.) Complete, standalone BAF records are made at the OSS for OSS calls, including calls using Alternate Billing Services (ABS), operator assistance, and listing services calls, for calls originating from and terminating to LEC end offices, an Interexchange Carrier (IC), and an International Carrier (INC). These records can be used for billing the end user (billed number), for billing ICs/INCs for originating access and terminating access charges, and for billing exchange carriers, ICs, and INCs for OSS processing Population Rules for OSS AMA The OSS records the information pertinent to a call on its AMA record, and the RAO determines and applies the appropriate tariff. The parameters that are required to be recorded in the structures and modules allow for, but do not define, likely LEC tariffs. Separate BAF records are made for related calls, each with an indication of how its record relates to the others. As a result, there can be multiple records for a single session of customer use of the OSS. Each record generated for the related calls is a complete, standalone record. For example: For a Call Completion call billed to a third number that is verified, the OSS generates two AMA records. One record is for the Call Completion call to the called number and billed to the third number, and the other record is for the verification call to the third number. 5 2

85 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Calling card sequence calls each have separate BAF records. For each call billed to a calling card, the OSS generates a record. A counter in each of these records indicates which call in the sequence that record corresponds to. When a customer makes multiple Listing Services requests, a record is generated for each individual request. A counter in each record indicates which in the series of requests the record corresponds to. Exchange access modules accommodate all the ways the LEC OSS may be involved in originating and terminating IC/INC calls, as described in GR-1173-CORE BAF Modules BAF structures and associated modules are based on the AMA data needs identified in call flows described in the OSSGR Feature Specific Documents (FSDs). The types of modules used in forming OSS BAF records include: service modules, the alternate billing module, the person handling module, exchange access modules, and others. One or more distinct modules along with an operator services system structure form a complete BAF record; each structure contains a Call Type Code (CTC) field which identifies the basic service being recorded, but the modules must also be examined to understand all the aspects of a call (e.g., a call completion billed to a calling card will have a call type code of call completion service, but the alternate billing aspects of the call will be reflected in the alternate billing module appended to the structure). The use of BAF modules in OSS BAF records is consistent with the OSSGR's modular concept of an OSS service and its associated billing, handling, and exchange or exchange access attributes. The OSS generates modules as appropriate for a particular call's circumstances. The modules that the OSS generates depends on the type of service being requested, the kind of alternate billing and handling being requested (if any), whether exchange access functions are being provided, and whether certain information is received in an OLNS response. For example, a call completion call will have a call completion service module appended to the structure; if this call is alternately billed, there will also be an alternate billing module; and, if it is person-to-person, the person handling module will also be appended. Note that additional modules, such as a Long Duration Call module or a LECadministered module (with module code in the 800 to 999 range), are also recorded if the conditions applicable to them are in effect for a call OSS Originating AMA There are two structure codes for originating OSS calls: SC 0752 is recorded for calls when no OLNS query is launched, and SC 0772 is recorded for calls when an OLNS query is launched (see GR-1173-CORE for the requirements pertaining to 5 3

86 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services OLNS). These two structures are described below in Section and Section , respectively. Note that for originating IC calls routed through a LEC s OSS without undergoing any OSS processing other than its switch s tandem function, the OSS-specific originating Structures 0752/0772 are not used; instead, SC 0625 is recorded with CTC Originating Calls, No OLNS Query Launched Table 5-1 lists the call type codes and module codes associated with SC 0752, which is generated by an OSS when an OLNS query is not launched for a call that it is processing. An OLNS query is not launched by the OSS for one of the following reasons: A. The OSS is not capable of launching OLNS queries B. The OSS determines that OLNS is not necessary based on the ANI II in MF / Originating Line Information Parameter (OLIP) in SS7, and/or incoming trunk group number, or C. The OSS determines OLNS is necessary, but, for reasons such as Automatic Number Identification (ANI) procedures, it does not launch an OLNS query. Table 5-1 Originating OSS Calls - No OLNS Query Call Type Code Call Type Description Required Module for Call Type 189 Credit Recording Service 058/158: Credit Recording Service 1 module 190 Originating Operator Service Carrier Identification 192 Originating Call Completion Service 053: IC/INC Call Delivery module or 054: IC/INC Information 2 module 051/151: Call Completion Service 3 module 194 Originating Listing Service 055: Listing Services Service module 196 Originating General 057: General Assistance Service module Assistance Service 198 Originating Busy Line Verification (BLV) Service 056/156: Busy Line Verification Service 4 module 1. Module 058 is used when the terminating number is 12 digits or less, and Module 158 is used when the terminating number exceeds 12 digits. 2. Module 053 is included in an AMA record if an originating call is transferred to a carrier for call completion or operator services processing. Module 054 is included in an AMA record if an originating IC/INC call is not delivered to a carrier because of failure of the carrier to pass the IC/INC checks, network problems, or if the call is not a call completion call (only recorded for trouble reporting or rate information). 3. Module 051 is used when the terminating number is 12 digits or less, and Module 151 is used when the terminating number exceeds 12 digits. 4. Module 056 is used when the number being verified is 10 digits or less, and Module 156 is used when the number being verified exceeds 10 digits. 5 4

87 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Additional Modules Used with SC 0752 In addition to the modules identified above in Table 5-1, the modules in Table 5-2 may also be appended to SC 0752 when call processing that is reflected in one or more of the modules is performed during a call [e.g., selection of a billing option other than sent-paid (Module 052) or an account owner is returned in a BNS or Calling Card (CC) response (Module 338)]. Table 5-2 Additional Modules Appended to Structure Code 0752 Module Number Module Title 022 Long Duration Call 050 Person Handling 052 Alternate Billing 059 Exchange Access Service Processing Time 060 Charge 062 Notify 087 Directory Number Descriptor module (to record privacy status of CPN when SS7 signaled to OSS and CPN is not identical to Charge Number) 164 E.164/X.121 module (to record CPN when SS7 signaled to OSS and CPN is not identical to Charge Number) 338 Service Provider Information (for billed number) 1 1. Module 338 is generated when an Account Owner (AO) is received in a BNS or CC response. Module 338 is generated when a Billing Service Provider (BSP) is received in a BNS or CC response. If both AO and BSP are received from LIDB in a BNS or CC response, two Module Codes 338 would be appended to the Structure Originating Calls, OLNS Query Launched The call type codes and module codes associated with SC 0772, which is generated by an OSS when an OLNS query is launched for a call that it is processing, are identical to those associated with SC 0752 as identified in Table Additional Modules Used with SC 0772 for OLNS Queries In addition to the modules identified in Table 5-1, the modules in Table 5-3 may also be appended to SC 0772 when call processing that is reflected in one or more of the modules is performed during a call [e.g., selection of a billing option other than sentpaid (Module 052) or an account owner is returned in an OLNS and/or BNS or CC 5 5

88 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services response (Module 338)]. Modules 019 and 219 are appended if the provisioning option to generate them at the OSS is enabled. Table 5-3 Additional Modules Used with SC 0772 Module Number Module Title 019 Originating Billing/Service Information 022 Long Duration Call 050 Person Handling 052 Alternate Billing 059 Exchange Access Service Processing Time 060 Charge 062 Notify 087 Directory Number Descriptor module (to record privacy status of CPN when SS7 signaled to OSS and CPN is not identical to Charge Number) 164 E.164/X.121 module (to record CPN when SS7 signaled to OSS and CPN is not identical to Charge Number) 219 Additional Originating Billing/Services Information 338 Service Provider Information (for billed number and for originating number) 1 1. Module 338 is generated when an Account Owner (AO) is received in a BNS or CC response. Module 338 is generated when a Billing Service Provider (BSP) is received in a BNS or CC response. Module 338 is generated when an AO is received in an OLNS response. Module 338 is generated when a BSP is received in an OLNS response. Therefore, up to four Module Codes 338 would be appended to the Structure, depending upon which (if any) AO s and BSP s are received from LIDB in a BNS, CC, or OLNS response OSS Terminating AMA SC 0751 is generated for calls terminating to the OSS, such as a Listing Services call received from an IC s network. Table 5-4 lists the call type codes and module codes associated with SC 0751 that are generated by an OSS. Table 5-4 Terminating OSS Calls Call Type Call Type Description Code 191 Terminating Operator Service Carrier Identification 193 Terminating Call Completion Service Required Module for Call Type 053: IC/INC Call Delivery module 054: IC/INC Information 1 module 051/151: Call Completion Service 2 module 195 Terminating Listing Service 055: Listing Services Service module 5 6

89 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Table 5-4 Terminating OSS Calls Call Type Code Call Type Description 197 Terminating General Assistance Service 199 Terminating Busy Line Verification Service Required Module for Call Type 057: General Assistance Service module 056/156: Busy Line Verification Service 3 module 215 Terminating Intercept Service 063: Intercept Service module 1. Module 053 is appended to an OSS AMA record if a terminating call is routed directly from a carrier to the OSS. Module 054 is appended if the terminating call is not routed directly from a carrier to the OSS (i.e., the call enters the LEC network at an access tandem other than the OSS and therefore the access tandem generates the terminating access record and the OSS generates the service record). 2. Module 051 is used when the terminating number is 12 digits or less, and Module 151 is used when the terminating number exceeds 12 digits. 3. Module 056 is used when the number being verified is 10 digits or less, and Module 156 is used when the number being verified exceeds 10 digits Additional Modules Used with SC 0751 In addition to the modules identified above in Table 5-4, the modules in Table 5-5 may also be appended to SC 0751 when the call processing that is reflected in one or more of the modules is performed during the call [e.g., selection of a billing option other than sent-paid (Module 052) or an account owner returned in a BNS or CC response (Module 338)]. Table 5-5 Additional Modules Used with SC 0751 Module Number Module Title 022 Long Duration Call 050 Person Handling 052 Alternate Billing 338 Service Provider Information 1 (for billed number) 1. Module 338 is generated when an Account Owner (AO) is received in a BNS or CC response. Module 338 is generated when a Billing Service Provider (BSP) is received in a BNS or CC response. If both AO and BSP are received from LIDB in a BNS or CC response, two Module Codes 338 would be appended to the Structure LEC-Settable OSS Call Type Codes (CTCs) The OSS generates a unique call type code for each type of service and differentiates whether the call reached the OSS on an originating basis or on a terminating basis. 5 7

90 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Table 5-1 and Table 5-4 list the call type codes that have been defined for OSS BAF records. These will be output by the OSS unless the OSS s call type code translation capability is used to override them. The call type code field is a translation-settable data field as described in GR-1100-CORE. A LEC may use its OSS s translation-settable call type code capability to cause LECselected call type codes to be output for specific combinations of services and treatments. For example, if a LEC wanted the call type codes output by its OSSs to indicate the type of billing (station-paid, collect, calling card, or third-number billing) requested for a service in addition to identifying the service provided in the call, the LEC could create LEC-specific call type codes that would identify all possible combinations of services and billing options. Call type code values that are assigned by a LEC via translation input may not correspond to values reserved for other services. It is a LEC s responsibility to apply its OSS s translation capabilities to cause the desired call type code values to be output, whether those codes are the service-specific call type codes defined in generic requirements and listed here in Table 5-1 and Table 5-4, or LEC-specific call type codes, and also to inform the RAO of the call type code values OSS AMA Examples The following examples list the modules that should be recorded with OSS structure codes 0751, 0752, and 0772, for representative call types. Additional modules, such as a Long Duration Call module or a LEC-administered module (with module code in the 800 to 999 range), are also recorded if the conditions applicable to them are in effect for the calls. 1. IntraLATA Rate Information Request Billed to a Calling Card Either: OSS SC 0752 (no OLNS)/0772 (OLNS) if the call is an originating call. The value in the call type code data field should be 196 for this type of call, or OSS SC 0751 if the call is a terminating call. The value in the call type code data field should be 197 for this type of call. General Assistance Services Service module (Module 057) with the Service Identification data field set to Rate Information and the Company Identification data field set to the company identification code of the LEC providing the service. Alternate Billing module (Module 052) with the Billing Type Identification data field set to Calling Card. Service Provider ID module (Module 338) if the calling card s AO or BSP was received in the CC response; two Service Provider ID modules are generated if both AO and BSP were received in the CC response. 5 8

91 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Service Provider ID module (Module 338) if an OLNS query was made and the originating line s AO or BSP was received in the OLNS response; two Service Provider ID modules are generated if both AO and BSP were received in the OLNS response. Final module (Module 000). 2. Sent-Paid Originating IntraLATA Call-Completion Call with OLNS OSS SC 0772 (OLNS launched), with call type code data field value of 192 Call Completion Service module (Module 051) (terminating number is 12 digits or less) Originating Billing/Services Information module (Module 019) (if generation of this module is enabled) Additional Originating Billing/Services Information module (Module 219) (if Additional Originating Billing/Services Indicator parameter was received in the OLNS response and if generation of this module is enabled) Service Provider ID module (Module 338) if the originating line s AO or BSP was received in the OLNS response; two Service Provider ID modules are generated if both an AO and BSP were received in the OLNS response Final module (Module 000). 3. Directory Assistance Request (Not Delivered by an IC/INC) Billed to a Calling Card Either: OSS SC 0752 (no OLNS)/0772 (OLNS) if the call is an originating call. The value in the call type code data field should be 194 for this type of call, or OSS SC 0751 if the call is a terminating call. The value in the call type code data field should be 195 for this type of call. Listing Services Service module (Module 055) with the Service Identification data field set to Directory Assistance Alternate Billing module (Module 052) with the Billing Type Identification data field set to Calling Card Service Provider ID module (Module 338) if the calling card s AO or BSP was received in the CC response; two Service Provider ID modules are generated if both AO and BSP were received in the CC response. Service Provider ID module (Module 338) if an OLNS query was made and the originating line s AO or BSP was received in the OLNS response; two Service Provider ID modules are generated if both AO and BSP were received in the OLNS response. Final module (Module 000). 4. Collect IntraLATA Call-Completion Call 5 9

92 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Either: OSS SC 0752 (no OLNS)/0772 (OLNS) if the call is an originating call. The value in the call type code data field should be 192 for this type of call, or OSS SC 0751 if the call is a terminating call. The value in the call type code data field should be 193 for this type of call. Call Completion Service module (Module 051) (terminating number is 12 digits or less) Alternate Billing module (Module 052) with the Billing Type Identification data field set to Collect Service Provider ID module (Module 338) if the collect line s AO or BSP was received in the BNS response; two Service Provider ID modules are generated if both AO and BSP were received in the BNS response. Service Provider ID module (Module 338) if an OLNS query was made and the originating line s AO or BSP was received in the OLNS response; two Service Provider ID modules are generated if both AO and BSP were received in the OLNS response. Final module (Module 000). 5. InterLATA (dialed 0-) Originating Collect Call (OSS Transfers to IC/INC) OSS SC 0752 (no OLNS)/0772 (OLNS), with call type code data field value of 190. Alternate Billing module (Module 052) with the Billing Type Identification data field set to Collect Either: IC/INC Call Delivery module (Module 053) if the call is successfully delivered to the IC/INC, or IC/INC Information module (Module 054) if the call is not successfully delivered to the IC/INC Final module (Module 000). 5 10

93 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 5.2 Line Information Database (LIDB) AMA Recording Line Information Database (LIDB) is a network database that provides data to support various services. LIDB currently receives and responds to five query types: Calling Card (CC), Billed Number Screening (BNS), Originating Line Number Screening (OLNS), Generic Name (GN), and GetData. CC, BNS, and OLNS support operator services (e.g., calling card validation, originating line billing restrictions); GN supports Calling Name service; and, GetData supports various services by providing data explicitly requested in the query (e.g., zip code to support an Advanced Intelligent Network (AIN) service). LIDB generic requirements, including its generation of AMA records, are documented in GR-1158-CORE, OSSGR: Section 22.3 Line Information Database and in GR-2838-CORE, Generic Requirements for GetData. LIDB generates BAF records for queries it receives in order to bill for access to its data. Records are currently defined for LIDB access via CCS/SS7. Aggregate AMA records contain counts of queries processed and their dispositions, aggregated over a 24-hour period for each Query Originator (QO)/Service Requester (SR)/Account Owner (AO) triplet. A detailed AMA record is generated for each query processed for which detailed AMA recording is enabled. Section and Section discuss aggregate and detailed LIDB AMA records, respectively Aggregate Records Table 5-6 summarizes the aggregate AMA structure codes and module codes that are required to be generated at the LIDB. These aggregate AMA structures serve to capture basic query information and disposition counts, for each possible type of LIDB query as it arrives from a particular query originator on behalf of a particular service requester for a particular account owner s data within the aggregation period. The aggregation should be based on QO/SR/AO; if no SR is received in the query, aggregation is based on QO/AO; if no AO is available, aggregation is based on QO/SR; if neither SR nor AO is available, aggregation is based on QO. LIDB aggregate AMA records use CTC 558, and SC 5060 and SC SC 5060 is generated when CC or BNS queries are received during the aggregation period for a particular QO/SR/AO triplet; counts for other query types received during the period for the same QO/SR/AO are recorded in modules. SC 6060 is generated when no CC or BNS queries are received during the aggregation period for a particular QO/SR/AO triplet but at least one other query type is received; one of the other query types is recorded in the structure code and the counts for any other query types are recorded in modules. In addition to the modules used for the counts, which are described in Table 5-6, there are other types of modules that can be appended to these structure codes, which are described below the table. The left-hand column of Table 5-6 lists each of the possible combinations of queries that can arrive at LIDB from a particular query originator on behalf of a particular SR for a particular account owner (QO/SR/AO triplet) during an aggregation period. 5 11

94 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Each row then identifies, for the given query combination, where the counts for each query type are recorded. For example, the row with query types CC/BNS, OLNS, and GN shows that if these are the query types received in an aggregation period for a given QO/SR/AO triplet, then the counts associated with the CC and BNS queries would be recorded in SC 5060, the counts associated with the OLNS query would be recorded in Module 499 (appended to the SC 5060), and the counts associated with the Generic Name query would be recorded in another Module 499 (appended to the SC 5060). See GR-1158-CORE, and GR-1100-CORE, for details on the contents of each structure and module. Table 5-6 LIDB Aggregate Records What query types are received for QO/AO pairs during aggregation period Where information about each received query type is captured Record CC/BNS Record OLNS Record CNAM Record GetData CC and/or BNS SC 5060 OLNS SC 6060 GN SC 6060 GetData SC 6060, Module 498 CC/BNS and OLNS SC 5060 Module 499 CC/BNS and GN SC 5060 Module 499 CC/BNS and GetData SC 5060 Modules 499 & 498 OLNS and GN Module 499 SC 6060 OLNS and GetData Module 499 SC 6060, Module 498 GN and GetData SC 6060 Modules 499 & 498 CC/BNS, OLNS, and GN SC 5060 Module 499 Module 499 CC/BNS, OLNS, and GetData SC 5060 Module 499 Modules 499 & 498 CC/BNS, GN, and GetData SC 5060 Module 499 Modules 499 & 498 OLNS, GN, and GetData Module 499 SC 6060 Modules 499 & 498 CC/BNS, OLNS, GN, and SC 5060 Module 499 Module 499 Modules 499 & 498 GetData Table Key: BNS = Billed Number Screening Query CC = Calling Card Query GN = Generic Name Query OLNS = Originating Line Number Screening Query There are two other modules that are appended to the LIDB aggregate AMA records when the information they contain is available: Module 338, Service Provider Information module, can be appended to SC 5060 and to SC 6060, to record: 5 12

95 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services the AO of the data being queried, on which the record is being aggregated (when AO is not available, this module is not recorded for AO and aggregation is done on QO/SR basis), and/or the SR received in the query, on which the record is being aggregated (when SR is not available, this module is not recorded for SR and aggregation is done on QO/AO basis). Note that Module 338 can be appended to a LIDB aggregate structure up to two times (one for AO and one for SR). If neither AO nor SR is available for a record, this module is not appended and aggregation is done on QO basis. Module 501, LIDB Query Aggregation Response module, can be appended to SC 5060, to record any of the following error conditions for CC and/or BNS queries: missing group record group status not active query processing indicator not enabled. Note that if all three of these counts are zero, this module is not appended LIDB Detailed AMA The LIDB owner has the ability to enable or disable the generation of LIDB detailed AMA records for a given QO/SR/AO triplet for specific query types. Each detailed BAF record captures query information disposition for one query. LIDB detailed AMA records use CTC 560, and SC 0755 and SC SC 0755 is generated to record information about CC, BNS, and OLNS queries; SC 0555 is generated to record information about GN and GetData queries. Module 338 can be appended to both structures, to record: The AO of the data being queried (when AO is not available, this module is not generated for AO), and/or The BSP of the data being queried (when BSP is not available, this module is not generated for BSP), and/or The SR received in the query (when SR is not available, this module is not generated for SR). Note that Module 338 can be appended to a LIDB detailed structure up to three times (one for AO, one for BSP, and one for SR). If neither AO nor BSP nor SR Identification is available for a record, this module is not appended. 5 13

96 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services 5.3 Toll-Free Recording The term toll-free service, sometimes called 800 Database Service or 8YY Service, is a generic term for access services associated with Toll-Free numbers. The North American Numbering Plan (NANP) has set aside certain NPAs that have been designated as toll-free service access codes. On a call origination basis, originating Toll-Free Service is an exchange access service available to an access customer (e.g., an IC) purchasing Feature Group D (FGD) trunk side arrangements. It provides an identification function on 1+8YY+NXX XXXX calls placed by end users to determine the location to which the call is to be routed and/or the transport carrier (IC) to be used. The transport carrier, whether the IC or the LEC (for IntraLATA Toll-Free service) bills the customer purchasing the Toll-Free transport on the basis of bulk minutes/calls delivered to that customer. Dialed digits determine the routing of the originating call to a specific entity. When an 8YY-NXX-XXXX call is dialed, a database is queried for call routing instructions before the call leaves the LATA of origin. A single 8YY-NXX-XXXX number can be used for optional call routing services. The functional capabilities of the database include: 1. Determining the transport carrier associated with the dialed Toll-Free number 2. Returning the Carrier Identification Code (CIC) of the transport carrier to the querying switch for routing purposes 3. Translating the 8YY-NXX-XXXX dialed number into a standard Directory Number (DN) 4. Returning that number to the querying switching system for use as the destination routing number. Many of the Toll-Free queries performed by the LEC consist of only functions 1 and 2. Once the carrier has been determined, the call is signaled forward to that carrier for the carrier to do number translation in its own database. The 101XXXX CAC dialing procedures cannot be used with Toll-Free Service. Unless prohibited by technical limitations, e.g., different dialing plans, an IC/INC customer may elect to have Toll-Free Access Service traffic combined in the same trunk group arrangement with non Toll-Free Access Service traffic. When required by technical limitations, or at the request of the customer, a separate trunk group will be established for Toll-Free Access Service. Generally, Toll-Free Access Service will be provided in accordance with the technical characteristics available with FGD, e.g., premises interfaces, design blocking criteria, address signaling. For purposes of applying Switched-Access Service usage charges, Toll-Free Access Service usage is measured as follows: 5 14

97 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services In end offices not equipped with equal access capabilities, access minutes are measured based on customer elapsed time. In end offices equipped with equal access capabilities, access minutes are measured in the same manner as FGD access minutes, i.e., from carrier connect to disconnect Background Calls to Toll-Free numbers are dialed without a CAC Identification, and any presubscribed carrier designation is disregarded. If a CAC is dialed, an announcement is returned. Since the CAC cannot be accepted before dialing, the Presubscription Indicator field (BAF Table 85) should be populated with the value 8, indicating that the CAC was not dialed, no presubscription indication was sent to the carrier, and the customer was not presubscribed. The AMA records are generated for Toll-Free calls at the Service Switching Point (SSP) in accordance with the data generation requirements in GR-533-CORE for Toll-Free calls with queries made to an Intelligent Network (IN) database and GR-1298-CORE for calls with queries made to an Advanced Intelligent Network (AIN) database. No records for these calls should be generated at a LEC end office that cannot launch a query to the Toll-Free database. However, if AMA records are made at the non-ssp end office, they should be recognized through the use of a special CIC (0110) populated in BAF Table 57 of the AMA record through translations at the end office. These AMA records will be the same as other records generated for originating exchange access Toll-Free Recording for IN Architecture A Toll-Free call originates at an end office that may or may not be equipped with SSP functionality. As mentioned above, when a Toll-Free call is dialed at a non-ssp end office, the call is routed from the end office to a switch with SSP capability, usually an AT/SSP. On detecting a Toll-Free call, the SSP launches a query to the Service Control Point (SCP) to obtain instructions for handling the Toll-Free call. The SCP response message contains information for routing and billing the call. This section describes the SSP requirements for generation of the originating SSP AMA record on a Toll-Free call, to be used for exchange access billing and possibly end user (i.e., Toll-Free Service subscriber) billing. 5 15

98 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services AMA Record Generation Generation refers to the process that creates the data elements for the AMA record. The SSP generates an AMA record based on information returned from the SCP and associated call conditions Information Returned from SCP The following parameters are returned in an SCP response and are used in AMA record generation: 1. CIC The value of the CIC returned in the SCP response indicates the CIC to which the SSP is to route the call. A CIC equal to 0110 indicates that the call is to be handled by the originating LEC or other non-ic; a CIC not equal to 0110 identifies the IC to which the call is to be routed. 2. Routing Number The routing number returned in the SCP response is determined during query processing based on the dialed Toll-Free number and query processing parameters such as where the call originated, time of day, day of week, and/or calendar date. The routing number included in the SCP response message is the terminating number and may be 1) a 10-digit dialable number to which the call is to be routed, or 2) the Toll-Free number that was originally dialed by the customer. A Toll-Free number may be returned as the routing number if the SCP determines that the call is to be routed to an IC and that IC determines the final destination number. If the routing number indicates a Toll-Free number, the CIC returned in the SCP response message identifies the IC to which the call is to be routed. 3. Billing Indicators The Billing Indicators parameter contains Service Feature Identification and the AMA call type code that are used in AMA record generation. The Service Feature Identification returned from the SCP is a three-digit number indicating SCP information to be recorded in the SSP AMA. This information can be recorded in the Translation Settable module (Module 030). The Service Feature Identification returned in the SCP response should not be recorded in the Service Feature Code field (BAF Table 12) of the SSP structure generated for the Toll-Free call. The Service Feature Code field in the structure should be populated with the Service Feature Code of the originating line causing the record to be generated (e.g., Coin =001, WSP= 023, etc.), per the latest version of GR-1100-CORE. The AMA call type code included in the SCP response message equals a 141 when the call is to be routed to an IC (i.e., the CIC indicates a value other than 0110 ), and a 142 when the call is to be handled by the originating LEC or other non-ic (i.e., the CIC indicates a 0110 ). The AMA call type code included in the SCP response message is used by the SSP to populate the call type code field of the AMA record. 5 16

99 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services The SSP uses the information contained in the response to generate the proper AMA record. The SSP generates an AMA record with the appropriate data elements based on conditions associated with the call Generation of Structure Codes Based on the call conditions leading to the information returned in the SCP response message, the SSP determines the appropriate structure code for the AMA record. The SSP will generate: SC 0360 for Toll-Free calls when the AMA call type code returned from the SCP has the value 141 (i.e., calls to be routed to an IC), and SC 0364 for Toll-Free calls when the AMA call type code returned from the SCP has the value 142 (i.e., calls handled by the originating LEC or other non-ic) for which an AMA record is generated Toll-Free Recording for AIN Architecture The pool of 800 numbers available for assignment to new subscribers is small compared to the recent demand for 800 numbers. In anticipation of 800 number exhaust, Toll-Free numbers in the format of 8YY (888, 877, 866, 855, etc.) have been made available. In addition, local service providers now have the option to provide service for Toll-Free numbers by querying the established IN 800 database or, as an alternative, using an AIN architecture for Toll-Free queries. Toll-Free within the AIN Architecture is somewhat different from that of the IN Architecture. For AIN, the Toll-Free number functions as a Specific_Digit_String (SDS) trigger. By dialing the 1-8YY-NXX-XXXX number, the SDS trigger is encountered, and the SSP sends an SDS query using Transaction Capabilities Application Part (TCAP) messaging to an SCP database. The SCP database could then respond with carrier information if the call is to be routed to a carrier or a routing number if the call is to be handled within the querying network. Once received, the SSP routes the call accordingly. Since the AIN architecture utilizes the SDS trigger, recording for the Toll-Free service is quite different compared to the recording of the IN architecture. The SDS trigger is significant to AMA because it can change routing information and the charge party (responsible monetarily for the outcome of that routing) without having to use physical routing facilities to do so (as opposed to true call forwarding). Therefore, instead of one structure code as done for the IN architecture, the recording for the AIN architecture could result in multiple records (i.e., multiple structure code). Because the Toll-Free number is an SDS trigger number, the AMA recording should follow the standard AMA recording for SDS triggers. Under the generic requirements, encountering an SDS trigger leads to the potential of a pre-query SDS record and a post-query SDS record. 5 17

100 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services The Pre-Query SDS Record for Toll-Free AIN Architecture The pre-query SDS record is there to provide the necessary billing information (if any) for the portion of the call from the Originator to the Toll-Free number. Since normally calls to Toll-Free numbers are not billed to the Originator, it is no surprise that much of the time, there is no pre-query SDS record generated. However, there will be cases when such a record is needed. Such a case could be for services rendered to the Originator that need to be billed. These services can include AIN services, ISDN services, etc. In such cases, the pre-query SDS record provides the necessary data for proper billing. Depending on the type of services provided, the pre-query SDS record could either be a switch-based record or an AIN record (SC 0220). In either case, the concept should be similar in that the fields in the record should be based on the call from the Originator to the Toll-Free SDS trigger number. Please keep in mind that the structure codes that are associated with the 800 Toll-Free IN architecture do not apply, since there was never an IN query The Post-Query SDS Record for Toll-Free AIN Architecture The post-query SDS Record is there to provide the necessary billing information (if any) for the portion of the call from the Toll-Free number to the routing number (the routing number being the number returned by the SCP database in response to the SDS query). The post-query SDS record could be a switch-based record or an AIN AMA record (SC 0220). Whatever the record that is generated, the fields of the record are based on the call from the Toll-Free SDS number to the routing number returned by the SCP database. It should be noted that the SDS number is usually a virtual number (i.e., a number that does not have any line attributes associated with it). Without line attributes, the SSP may not be able to derive, through switch translations, the necessary billing information needed to generate an AMA record. However, the SSP should be able to derive the necessary billing information from the contents of the TCAP messages from the SCP database (e.g., carrier information in the TCAP message). For this reason, the common SC / CTC combinations, normally generated as the post-query SDS record, would be: SC 625 / CTC 110 (as the switch-based record for calls that are routed to a carrier) SC 0220 / CTC 047 (as the AIN AMA record for calls not routed to a carrier) SC 0220 / CTC 110 (as the AIN AMA record for calls that are routed to a carrier). 5 18

101 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 5.4 Service Access Code (SAC) Recordings A Service Access Code (SAC) is a three-digit, non-geographic code (used as an NPA) that is assigned for access to IC or LEC carrier services. Codes currently in use include 8YY (toll-free service), 700 Service (for IC carrier services), 500 Service, and 900 Service SAC ICs that use the 700 SAC are not assigned specific numbers within, what is in effect, the 700 NPA. 700 Service calls are routed to the carrier identified by the carrier code dialed by the customer or to the customer s presubscribed carrier. Note that a 700 call can only be completed if the originating line has a presubscribed carrier or a CAC is dialed for the call. The AMA records generated for calls to a 700 SAC are originating exchange access records, containing SC 0625 and CTC 110, and should be generated in the same way as any other originating exchange access record. Since the CAC may be dialed (or the presubscribed carrier selected) before dialing the SAC, the Dialing/Presubscription Indicator field (BAF Table 85) is set according to the requirements described in GR-1083-CORE. The carrier code in the IC/INC Identification field (BAF Table 57) for these calls should be the CIC of the carrier that transports the call. The AMA records for this type of call should be generated at the LEC end office that originated the call SAC 500 Access Service is an originating offering using trunk-side Switched Access Service. This provides a customer identification function for numbers using the 500 service access code (i.e., NXX-XXXX). Some companies have expanded 500 Access Service to include NXX-XXXX dialing capability with the 0(+) Option. When a NXX-XXXX or NXX-XXXX call is originated by an end user, the LEC uses the 500 NXX dialed digits to determine the customer identification and the customer location where the call is to be routed. If the call originates from an end office not equipped to provide the customer identification function, the call is routed to an office where the function is available. Once customer identification has been established, the call is routed to the customer. The AMA records generated for calls to a 500 SAC are originating exchange access records, containing SC 0625 and CTC 110, and should be generated in the same way as any other originating exchange access record. Since the CAC and presubscription are not applicable, the Dialing/Presubscription Indicator field (BAF Table 85) is set to 8 per the requirements in GR-1083-CORE. 5 19

102 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services The carrier code in the IC/INC Identification field (BAF Table 57) for these calls should be the CIC of the carrier that transports the call SAC 900 Access Service is a LATA-wide offering using originating trunk-side Switched Access Service. The service provides for the forwarding of end-user dialed 900- NXX-XXXX calls to a LEC switch capable of performing a customer identification function. Based on the 900-NXX, the call is forwarded to the appropriate customer using the transport carrier assigned in the switch for the 900-NXX combination. No CAC is required or permitted for 900 Access Service. When a NXX-XXXX call is originated by an end user, the LEC performs the customer identification function based on the dialed digits to determine the customer location or the transport carrier. The customer identification function is available at suitably equipped end office or access tandem switches. If the call originates from an end office switch not equipped to provide the customer identification function, the call is routed to the access tandem at which the function is available. Once customer identification has been established, the call is routed to the customer. The manner in which 900 Access Service is provisioned depends on the status of the end office from which the service is provided (i.e., equipped with equal access capabilities or not equipped with equal access capabilities) and/or the status of the customer (i.e., MTS/WATS provider or MTS/WATS type provider). When 900 Access Service is provided from an end office equipped with equal access capabilities, all such service is provisioned as FGD. When 900 Access Service is provided from an end office not equipped with equal access capabilities, such service is provisioned in the same manner in which the customer s non-900 Switched Access Service from such end office is provisioned. Unless prohibited by network considerations, the customer s 900 Access Service traffic may, at the option of the customer, be combined in the same trunk group arrangement with the customer s other Access Service traffic, or be combined in the same trunk group arrangement with the customer s 800 Access Service traffic of the same Feature Group. Calls to a 900 number originating from LEC-provided coin telephones, Hotel/Motel Service with no on-premises billing system, calls dialed as 0+, calling card, and third number billed calls are usually blocked. The AMA records generated for calls to a 900 SAC are originating exchange access records, containing SC 0625 and CTC 110, and should be generated in the same way as any other originating exchange access record. Since the CAC and presubscription are not applicable, the Dialing/Presubscription Indicator field (BAF Table 85) is set to 8 (CAC was not dialed, no presubscription indication was sent to the carrier, and the customer is not presubscribed) per the requirements in GR-1083-CORE. The carrier code in the IC/INC Identification field (BAF Table 57) for these calls should be the CIC of the carrier that transports the call. 5 20

103 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 5.5 Recording for CLASS SM Services CLASS Services are a group of subscriber services that provide selective-call screening, alerting, and calling-identification delivery functions. CLASS services take advantage of the calling-number information in common-channel signaling. In some cases, CLASS services are invoked apart from call setup and, therefore, use Non-Call-Associated Signaling (NCAS) Background CLASS Features can be provisioned on individual subscribers lines or on an officewide basis. These features are also offered on a subscription basis (flat monthly fee regardless of usage) or on a usage-sensitive basis. Typically, when provisioned on a subscription basis, no BAF records are generated for feature use. When provisioned on a usage-sensitive basis, activations, reactivations, and deactivations generate BAF records (CTC 330 or CTC 264). The CLASS Feature Code (BAF Table 415) is populated with the appropriate value (see GR-1100-CORE) for the feature used, as well as the reason (e.g., activation, reactivation, deactivation, screening list editing, etc.). The BAF record also captures the time and date of the applicable feature use, and number of entries on any given screening list. CLASS features related to calling party identity delivery may also be provisioned on a subscription basis or usage-sensitive basis. These features generate a BAF record (CTC 264 or CTC 331) on a daily basis at the normally scheduled record generation time (default record generation time is midnight). These daily BAF records provide the counts for both calling party identities delivered, as well as counts for calling party identities not delivered because of being marked anonymous or not available. Table 5-7 illustrates the most commonly deployed usage-sensitive CLASS Features, their function, and associated structure codes and CTCs. Detailed descriptions and generic requirements of all CLASS Features may be found in the Telcordia FR-64, LATA Switching Systems Generic Requirements (LSSGR), FSD Families XXXX, XXXX, and XXXX. Table 5-7 AMA Recording for Usage Sensitive CLASS SM Features CLASS SM Feature Function Structure Code Call Type Code Automatic Callback Redials the last outgoing number Automatic Recall Dials the last incoming number Customer Originated Trace Traces the last incoming call Selective Call Acceptance Screens incoming calls for acceptance Selective Call Forwarding Screens incoming calls for forwarding

104 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Table 5-7 AMA Recording for Usage Sensitive CLASS SM Features (Continued) CLASS SM Feature Selective Call Rejection Distinctive Ringing/ Call Waiting Calling Name Delivery Calling Number Delivery Calling Name and Number Delivery Calling Identity Delivery Suppression Anonymous Call Rejection Function Screens incoming calls for rejection to announcement Screens incoming calls to provide distinctive alerting Displays calling name to called party Displays calling number to called party Displays both calling number and name to called party Blocks the deliverance of calling name and/or number to called party Redirects incoming calls where the calling identity is private or anonymous to announcement Structure Code Call Type Code Privacy It is necessary to identify, in BAF records, calls to private or anonymous called numbers, to the RAO. This is to protect the privacy of that called number to its owner. For example, a customer with a private number placed a call to the called party, and the called party returned that call by way of Automatic Recall (activation code *69). The BAF record generated for the CLASS Automatic Recall Feature usage, as well as any switch-based record generated for the call, needs to identify the called number as being private. This will inform the RAO to not post the called number detail on the customers bill. There are two methods of identifying private called numbers in BAF records. The first method is to append a Called Directory Number Description module (Module 068) to the CLASS record and any switch-based record generated for the call. This module informs the RAO of the called party s directory numbers privacy status by way of the Value in BAF Table 70 of the Module 068. The second method is by marking the Study Indicator (BAF Table 8), Character 5 in the switch-based BAF record, if any, to the appropriate value to indicate the privacy status of the called directory number. 5 22

105 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Local Area Signaling Services (LASS) Recording LASS are a group of subscriber services that provide custom calling features. LASS services take advantage of switch-based feature functionality to provide end users with the ability to make conference calls and perform call redirection Background LASS Features are typically provisioned on individual subscriber lines but some can be provisioned on an office-wide basis. These features are also offered on a subscription basis (flat monthly fee regardless of usage) or on a usage-sensitive basis. Typically, when provisioned on a subscription basis, no BAF records are generated for feature use. When provisioned on a usage-sensitive basis, activations and deactivations can generate BAF records. The Service Feature Code (BAF Table 12) is populated with the appropriate value (see GR-1100-CORE) for the feature used LASS AMA LASS Features provisioned on subscriber lines may or may not generate BAF records associated with feature activations/deactivations (initiated by the subscriber by way of an activation/deactivation code being dialed or flashing the switch hooks). The use of these features are also indicated in the switch-based record generated for calls employing LASS Features (see Table 5-8). The indicator identifying the feature use is populated in the Service Feature Code (BAF Table 12) of the switch-based BAF record. Commonly deployed LASS Features include: Call Waiting generates no BAF record when the feature is used Call Forwarding Variable can result in activation and deactivation BAF records (CTC 031) and Service Feature indicator (BAF Table 12 = 012) being set in any switch-based BAF record generated for a forwarded call. In addition to the activation and deactivation records, the Service Feature Code of any switch-based record resulting from a call being forwarded will be identified by the Service Feature Code (BAF Table 12 = 012) Call Forwarding Busy Line/Call Forwarding Don t Answer feature is activated and deactivated by the LEC and results in no BAF records. Switchbased records generated for calls being forwarded as a result of a subscriber s line being busy or not answered will be identified by the Service Feature Code (BAF Table 12 = 014) Three-Way Calling adding a third party onto an existing two party call can result in the generation of a BAF record (CTC 026) for recording conference trunk usage. If the added-on leg of the call generates a normal switch-based BAF record, the Service Feature Code (BAF Table 12 = 010) in the switchbased record would identify the record as the added-on call. 5 23

106 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Usage-Sensitive Three-Way Calling (USTWC) adding a third party onto an existing two party call can result in the generation of multiple BAF records. Flashing the switch hooks or dialing an access code can result in generating a CTC 049 to identify feature activation. Once the third party has been called and is bridged together with the other two parties, a CTC 048 is generated to identify a three-way call. The Service Feature indicator of the CTC 048 will be set to a value of 018. If the added-on leg of the call generates a normal switch-based BAF record, the Service Feature Code would identify the line attribute of the originating line initiating the use of USTWC. The Service Feature Code should not be set to 018 for the normal switch-based record to the added on leg of the call. Table 5-8 LASS Features LASS Feature Call Forwarding Variable Call Forwarding Variable Call Forwarding Variable Call Forwarding Busy Line Call Forwarding Don t Answer Three-Way Calling Usage-Sensitive Three-Way Calling Usage-Sensitive Three-Way Calling Usage-Sensitive Three-Way Calling Function Structure Code Call Type Code Service Feature Code (BAF Table 12) Activation Deactivation Forwarded leg of call Forwarded leg of call Forwarded leg of call Added on leg of call Activation (via flash or activation code) Bridging on the added on leg of call Call to the added on leg of the call Switch-Based Switch-Based 012 Switch-Based Switch-based 014 Switch-Based Switch-Based 014 Switch-Based Switch-Based Switch-Based Switch-Based NOT 018 (Service Feature of originating line) 5 24

107 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 5.6 Advanced Intelligent Network (AIN) Recording With the advent of Advanced Intelligent Network (AIN), the traditional forms of AMA data are changing to some degree. This change comes in the form of enhanced services that allow the SSP end office to generate AMA records for new services without needing a generic update for the new feature. This is accomplished by the AIN service creation environment, which allows LECs to design a new feature and specify the desired AMA data format to be generated by the SSP end office Background The AIN service creation flexibility allows LECs to customize the billing of the new feature based on the LECs current billing formats and applicable tariffs. This method expedites the previous method in which the LEC would go to the supplier and request the design of a new feature. The supplier would, in turn, design the AMA data format to the Telcordia or the supplier s own specifications, and then return the completed feature to the LEC for approval. The requesting LEC had very little control over the design and AMA data format of the new feature. With AIN AMA, the requesting LEC has complete control, utilizing AIN service creation to design the AMA data format to its unique specifications. AIN performs its functions via the CCS/SS7 network. When an AIN feature is activated, the SSP end office sends a database query to the SCP, which in turn looks up the requested information in its database and sends a reply message back to the SSP. The SSP then decodes the message, processes the call, and performs any SCP indicated function (in this case, the appropriate AMA data is generated). In summary, the SCP, not the SSP, is typically the main source of information. This allows for greater AMA data format flexibility for the design and implementation of new customer-focused features AIN Conventions With AIN, the LECs can create a wide variety of services, test them for quality and proper AMA recording, and deploy them quickly and easily. An example of an AIN service could be a service where a caller can be connected to the nearest place of business simply by dialing an easy to remember number. For instance, a caller would like place an order for pizza, but does not know the number of the nearest pizza shop. With AIN, that caller can simply dial pizza, and be connected to the nearest pizza shop. By dialing the number that corresponds to pizza, an SDS trigger is encountered (the concept of Triggers will be explained later on). This tells the SSP to query the SCP database for instructions on how to handle the call. The SCP database then returns the number of the nearest pizza shop, and once the number is received, the SSP can route the call. 5 25

108 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Another AIN service that could be provided is the ability to screen outgoing calls (e.g., to prevent teenagers or children from calling undesirable numbers). This could be done through the use of Off_Hook_Delay (OHD) triggers. After dialing a number, the OHD trigger is encountered and a query is launched to the SCP database. If the number dialed is an acceptable number, the SCP database could return routing instructions, otherwise it could return instructions to block the call. Screening incoming calls is also possible with AIN. Calls coming into the terminating number could encounter the Termination_Attempt trigger (TAT). The SSP then launches a query to the SCP database. If the call is acceptable, the SCP database would return instructions to accept the call. Otherwise, the SCP database would return instructions to block the call. These are just a few examples of the types of services that can be offered through the use of AIN. Switch call processing for these services is governed by the use of expanded call models. These Call Models are further broken into the Originating Call Model (OCM) and the Terminating Call Model (TCM) and are described in Sections and 5.6.4, respectively Originating Call Model Figure 5-2 illustrates the Originating Call Model for AIN services. Within the OCM lies Detection Points (DP) which identify the points in a call that an SCP can receive notification of a given event and influence subsequent call processing (i.e., query the SCP database for further instructions that can affect call processing). If during call processing at a given DP, the SSP determines that AIN processing is not needed, it continues to process the call normally (i.e., it proceeds with the call processing without querying the SCP database). In the OCM, the DPs include Origination_Attempt, Info_Collected, Info_Analyzed, Network_Busy, O_Called_Party_Busy, and O_No_Answer. In each of these DPs lies Trigger and/or Events (which when encountered, is an indication for the SSP to establish communications with the SCP database for further instructions). Typically, when a call begins, the call will pass through each DP. After it passes through a particular DP, the call cannot revisit that DP again (which implies that the call cannot encounter the triggers that lie within the previous DP). That is, unless the SCP database returns a message know as Collect_Information. The Collect_Information message allows the SSP to place the call back into the Info_Collected DP. Therefore, it becomes possible to encounter or re-encounter the Triggers/Events that lie within that DP. This is helpful in such services as when a person telecommuting wishes to place a call, but would like both the call and corresponding charges to appear similar to his or her office line. With the Collect_Information message, the SCP can also include attributes similar to the office line. Thus when the SSP receives all this, it can go back in the call model, and basically restart the call with the attributes that make the line appear as the office line. Of course, re-encountering Trigger/Events brings about significant changes in AMA recording. For further information on such changes, the reader can consult the GR-1298-CORE document. 5 26

109 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services O_Abandon E 1. O_NULL Exception T/E O_Feature_ Origination_Attempt Requested Orig.Denied 2. AUTHORIZE_ORIG._ATTEMPT T Origination_Attempt_Authorized 3. COLLECT_INFORMATION O_Feature_ Requested T 4. ANALYZE_INFORMATION O_Feature_ Requested O_Feature_ Requested T 5. SELECT_ROUTE Information_Collected Information_Analyzed Route Selected 6. AUTHORIZE_CALL_SETUP route busy Collect Timeout Invalid Info. Network_Busy T/E Auth. Failure T/E O_Feature_ Requested O_Mid_Call 7. SEND_CALL E Call Setup Authorized O_Term_Seized route busy O_Called_Party_Busy T/E T/E 8. O_ALERTING E O_Answer O_Mid_Call T/E O_No_ Answer E O_Disconnect (Calling Party disconnects) T/E 9. O_ACTIVE E O_Mid_Call 10. O_SUSPENDED O_Suspended (Called Party disconnects) E (Called Party reconnected) O_DTMF_ Entered T/E O_Mid_Call T = Trigger (Detection Point) E = Event (Detection Point) = DPs not yet included in GR-1298-CORE Figure 5-2 AIN Originating Basic Call Model 5 27

110 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services The difference between the Triggers and Events is that the Trigger is provisioned through switch translations (either to an individual subscriber line, or in an officewide basis), whereas the Event is made active (or armed ) through specific messages from the SCP database during call setup. This implies that for an Event to be armed, the SSP first must encounter a Trigger so that the SCP can reply with that particular message. Although slightly different in that way, the AMA for encountering Triggers is similar to the AMA for encountering Events. Once the Triggers/Events are encountered, the SCP database can return messages that affect the call processing and call routing. The SCP database can also return parameters within the messages that can affect the AMA records that are generated. A very important parameter in AIN AMA is known as the AMAslpID. The AMAslpID contains 9 digits (whose values are settable by the service provider), and is used to identify the AIN service that was provided. Of course, the service provider has the option of whether or not to return the AMAslpID. If the AMAslpID is not returned, that is an indication that recording for the AIN service is not desired. In this case, the SSP resorts to normal switch-based record generation. If the AMAslpID is returned, it is an indication that AMA recording for the AIN service is desired. The general rule is that when AMAslpID is returned, the SSP should generate an AIN AMA record of SC 0220 or SC Like most general rules however, there are a few exceptions. To go through all of these exceptions is beyond the scope of this document. If the reader wishes to learn about these exceptions, the reader can consult the GR-1298-CORE document. Along with the AMAslpID, there are several other parameters that affect the AMA recording. Some examples are the AMABusinessCustomerID parameter that can be used to identify the business customer and whether it is originating or terminating; the AMADigitsDialedWC parameter that can be used to identify the numbers that were dialed; and the AMALineNumber parameter that can be used to identify a line number (e.g., a Calling Party ID or Incoming Terminating Number). There are many other parameters that provide the AIN the flexibility it needs to capture the proper information (all these parameters are covered in GR-1298-CORE) Originating Call Model Triggers/Events An example of a trigger in the OCM is the OHD Trigger. This trigger is located in the Info_Collected DP. This is normally encountered whenever the caller dials a number. When the SSP launches the query for this trigger, the SCP has four potential messages to return: 1. Analyze_Route routes the call to the routing number within the message 2. Continue instructs the SSP to continue with normal call process of the call 3. Disconnect instructs the SSP to disconnect the call 4. Send_To_Resource allows the caller to interact with Information Provider (IP) network services (e.g., entering codes, credit card numbers). 5 28

111 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Depending on the AMA affecting parameters contained within these messages (e.g., AMAslpID), the SSP shall generate either a switch-based record (when no AMAslpID is included in the message), an AIN AMA record (when AMAslpID is included in the message, resulting in a SC 0220), or both. Generating both AIN and switch-based records is a special condition that involves the Send_To_Resource message. If further information is desired on this special condition, the reader should consult GR-1298-CORE. The record that is generated for this trigger will have the caller s number in the originating number fields and the routing number in the terminating number field (the actual dialed number could be recorded in a module code, provided it is returned from the SCP database within one of the AMA affecting parameters). Another example of a trigger in the OCM is the popular Specific_Digits_String (SDS) trigger. The Toll-Free AIN Architecture (mentioned in Section 5.3.3) utilizes the SDS trigger. The SDS trigger lies within the Info_Analyzed Detection Point. The messages that the SCP database can return are: 1. Analyze_Route routes the call to the routing number within the message 2. Continue instructs the SSP to continue with normal call process of the call 3. Disconnect instructs the SSP to disconnect the call 4. Send_To_Resource allows the caller to interact with an IP s network services 5. Collect_Information - places the call back into the Info_Collected DP (as mentioned previously). The SDS trigger is significant to AMA because it can change routing information and the charge party (responsible monetarily for the outcome of that routing) without having to use physical routing facilities to do so (as opposed to true call forwarding). Therefore, the AMA recording is different from that of other triggers (e.g., OHD) Specific_Digit_String AMA Unlike the OHD AMA recording, where the record captures the call from the originator to the routing number, the SDS trigger results in two distinct types of records. The first is known as the Pre-query SDS record, and the second is know as the Post-query SDS record. The Pre-query SDS record is there to provide the necessary billing information (if any) for the portion of the call from the Originator to the SDS trigger number. This record could either be a switch-based record or an AIN record (SC 0220 if AMAslpID is returned). A SC 0220 may occur if a Trigger/ Event (e.g., OHD) is encountered before the SDS trigger is encountered). In either case, the record should be based on the call from the Originator to the SDS trigger number. The post-query SDS Record is there to provide the necessary billing information (if any) for the portion of the call from the SDS trigger number to the routing number returned by the SCP database. The post-query SDS record could be a switch-based 5 29

112 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services record or an AIN AMA record (SC 0220 if AMAslpID is returned). Whatever the record that is generated, the fields of the record shall be based on the call from the SDS trigger number to the routing number returned by the SCP database AIN Event Processing An example of an Event is O_Called_Party_Busy Event, which lies in the O_Called_Party_Busy DP. Once armed, the event is encountered when the SSP detects the called party as busy. When the query is launched, the SCP database can return either of the following: Analyze_Route (similar to OHD trigger), Continue (similar to OHD trigger), Send_To_Resource (similar to OHD trigger), and Collect_Information, which puts the call back into the Info_Collected DP (as mentioned previously). As described earlier, arming an Event requires a Trigger to be first encountered. Once the Event is armed and encountered, AMA recording will vary based on which trigger initiated the arming of the Event and which routing messages are received as part of that Transaction. In other words, if the trigger that armed this event was an OHD trigger, then the AMA record that results from encountering the Event (whether it be a switch-based record or AIN AMA record) will have the originator s (owner of the OHD trigger) number in the originating number fields. If the Trigger was an SDS trigger, then the AMA record for the Event would have the SDS Trigger number in the originating number fields. In either case, the terminating number fields would be populated with the routing number returned by the SCP database. An important note should be mentioned about the DPs known as O_Called_Party_Busy and O_No_Answer. When encountering the Trigger or Events within these DPs, the call is considered to be in a new call originating call model, and therefore, a new record is to be generated (if any). In general, the philosophy of Event recording is to generate a separate record per call routing attempt. Now if there were previous records opened prior to encountering this Event, those records would be closed with the fields populated according to the status of the call at the time the Event was encountered (e.g., if the called party was busy when the O_Called_Party_Busy Event was encountered, any previous record should be closed with the record indicating the called party was busy). These are just a few examples of Triggers/Events that are available in the OCM. As time passes, more Triggers/Events can be established to provide more flexibility and potential. Also, more messages are being established to achieve the same goal. The next section will describe the types of Triggers/Events that can be found in the Terminating Call Model Terminating Call Model Figure 5-3 illustrates the Terminating Call Model for AIN services. 5 30

113 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services 11. T_NULL T Termination_Attempt Exception T_Abandon 12. AUTHORIZE_TERMINATION Call Presented 13. SELECT_FACILITY T/E Resource_Available Term.Denied T_Busy T/E Network_Busy E SS7 failure occurs Call Rejected 14. PRESENT_CALL Call Accepted T_No_Answer E T_Disconnect (Calling Party disconnects) T/E T_Feature_ Requested T_Mid_Call 15. T_ALERTING E 16. T_ACTIVE T_Answer T_Suspended (Called Party disconnects) T/E (Called Party reconnected) E T_DTMF_Entered 17. T_SUSPENDED T = Trigger (Detection Point) E = Event (Detection Point) = DPs not yet included in GR-1298-CORE Figure 5-3 AIN Terminating Basic Call Model 5 31

114 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Similar to the OCM, the Terminating Call Model (TCM) contains DPs which contain Triggers and/or Events. Some examples of DPs within the Terminating Call Model include Termination_Attempt, T_Busy, T_No_Answer, and Term_Resource_Available. In the TCM, AMA recording is also dependent on whether or not an AMAslpID is returned by the SCP database. However, for the TCM, the AIN AMA that is generated is SC The major difference between SC 0220 and SC 0221 is that SC 0221 does not have originating number fields (since originating information is not needed, and at times, not even available). It should be noted that there are particular records within the TCM, that if generated, will be separate from any other records that are generated for the call. These particular records shall remain open as long as the call remains active and will close once the call is torn down (i.e., all the circuits involved with the call become idle). These records include Terminating Access Records (Call Code 119), Feature Group B - Terminating (Call Code 135), Connecting Network Access Records (Call Code 720), Wireless Services Provider - Type 1 or 2B (Terminating, with Call Code 065), and Wireless Services Provider - Type 2A (Terminating, with Call Code 066). These records are for specific billing purposes that need not contain any AIN information. Typically in the Call Model, the call starts in the OCM, and then moves into the TCM. In the TCM, the call can move into the OCM. This is done by a particular message that is returned by the SCP. This particular message is the Forward_Call message. Essentially, this message instructs the SSP to forward the call to the routing number supplied within the message. Here, the terminating party now becomes an originating party, and the call model switches into the OCM. Because the call is now in the OCM, the AIN AMA record that would be generated is the SC Terminating Call Model Triggers/Events In the TCM, it is possible to encounter multiple Triggers/Events within the same TCM. Therefore, the general philosophy in the TCM is to generate a separate record (if any) for each Trigger or Event that was encountered. Also any record from the previous Trigger or Event shall be closed, with the fields populated with the call disposition at the time the next Trigger or Event was encountered. An example could be a called party that has the Termination_Attempt Trigger (TAT, which lies in the Termination_Attempt DP) and T_No_Answer Trigger (which lies in the T_No_Answer DP) assigned to the line. When an incoming call encounters the TAT, an AIN query is launched. The SCP database responds with a message that instructs the SSP to allow the call to continue to the called party. The telephone of the called party begins to ring, but the called party does not answer. Eventually, the T_No_Answer Trigger is encountered. At this point the record for the TAT (if any) would be closed with the record indicating that the call was not answered. This record could be a switch-based record or an AIN record (SC 0221, if AMAslpID was returned). 5 32

115 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services In response to the query for the T_No_Answer Trigger, the SCP responds with a message that instructs the SSP to continue ringing the phone of the called party. Finally the called party answers the call, and when both parties hang up, the record (if any) for the T_No_Answer Trigger is closed with the fields indicating the call is answered and completed. Again, this record could be a switch-based record or an AIN record (SC 0221, provided an AMAslpID is returned). The fields of these records would contain the owner of these triggers in the terminating number fields (which in this case would be the called party number). These are a few examples of the Triggers/Events available in the TCM. As time passes, more and more Triggers/Events, messages, and parameters are established to provide more flexibility and more services. Recent additions into the world of AIN include the ability to encounter an Event while the call is already established (what was described thus far were services that were provided during the attempts to set up a call), the ability to provision Triggers on a trunk group, and the ability for the SCP database to invoke switch-based features (e.g., CLASS features like Automatic Callback, Automatic Recall). In summary, AIN is alternative to designing services as well as AMA recordings. AIN is very flexible and provides the LEC with complete control by which the services are designed, tested, and deployed. This makes AIN a powerful tool in the telecommunications industry. 5 33

116 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services 5.7 Message Detail Recording (MDR) The MDR feature provides detailed data on a customer s calls. The primary user of MDR information is the business customer. As required by the MDR customer, the switch may provide MDR call data for calls originated by the MDR customer (for example, from the customer s line, private facility trunk, attendant, etc.) and/or calls terminating to the MDR customer s facilities (for example, private facility trunk, attendant, etc.). The MDR customer typically uses the call data records for cost allocation and/or telecommunications system management. MDR has evolved to become an umbrella term to describe the recording of usage information for features such as account or authorization codes, queuing, automatic route selection, facility restriction, private facility access, etc. In the past, the MDR feature was broadly termed Station Message Detail Recording (SMDR). Various features in currently deployed switching systems provide the capability for the switching office to provide records of call details to a customer. However, GR- 610-CORE, LSSGR: Message Detail Recording (MDR), FSD , specifies two basic methods for providing MDR data. One method, the MDR via the RAO feature, provides a capability for transmitting MDR information to the LEC RAO in the same data stream that transmits AMA data records for the switching system. As the RAO processes the received data stream, the MDR AMA information is separated from all the AMA data records and forwarded to the customer. An alternative method provides MDR to the customer s premises, whereby the switching system that serves the call forwards the MDR data for the call to the customer on a data link or its equivalent MDR via the RAO MDR information may be generated at the RAO either by deriving MDR data from traditional AMA files, or by processing MDR-specific information that is sometimes received along with AMA record transmission. In the first, more typical method, the source of the data is the actual AMA record in the case where an AMA data record is generated for billing purposes. This AMA data record serves a dual role for billing the call and for MDR purposes. Therefore, the RAO processing has to recognize from the AMA record data itself (for example, originating number, etc.) that MDR data must be derived from AMA data. However, if no AMA data record is generated for the call, such as when a call uses only private customer facilities, the switching system generates a special record that is used for MDR data purposes only. These special records are recorded in the switching system s AMA file along with all other AMA data records. The second method for transmitting the MDR data to the customer via the RAO generates a separate MDR data record whenever MDR data is to be provided for a call. Therefore, if the call is chargeable, two separate records are generated for the call the AMA data record and the MDR data record. This arrangement has limited 5 34

117 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services use only and is not consistent with GR-610-CORE generic requirements. These MDR-data-only records are also inserted into the AMA data record stream for transport to the RAO. The BAF modular concept supports a more efficient method of providing MDR data via the RAO. Instead of creating two records for an MDR customer s calls (an MDR record and an AMA data record), one record can be used for both purposes. MDR data modules (defined in GR-610-CORE) are added to existing AMA data records to record information (needed for MDR data purposes only) that is not otherwise a part of the AMA data record. Regardless of which method provides MDR data via the RAO, the MDR data is output from the network element in the AMA data stream. This data is transported to the LEC RAO either by magnetic tape, AMA Teleprocessing System (AMATPS), or AMA Data Networking System (AMADNS) data collection procedures. RAO processes separate the MDR customer-required data from the AMA call data (whether the MDR data is in the same record as the call data or in a separate record), reformat the MDR data into the form required by the customer (for example, magnetic tape, printed reports, etc.), and forward the MDR data to the MDR customer MDR to Customer Premises If the customer MDR data is to be transmitted by the switch to the customer premises, currently deployed switching systems must generate two different data record types to provide both MDR data to the customer as well as separate AMA data to the RAO. One type transmits the AMA data in the AMA file (if the call is billable or otherwise requires an AMA data record) and another type transmits the MDR data directly to the customer. When MDR data modules are used and the MDR is being transmitted directly to customer premises by the switching system, the MDR data modules are included only in the MDR data record sent to the customer; the normal AMA data record (if required for the call) is transmitted to the RAO without the MDR data-specific modules. The MDR-to-customer-premises data record generated at the switching system is transmitted from the switching system toward the MDR customer s Customer Premises Equipment (CPE). The MDR data flow is entirely from the switching system toward the CPE; however, control messages may be exchanged between the CPE and the switching system. The transmission facility is provided by a LECoffered service that may be analog private line, message telephone service (using a dial-in/dial-back arrangement for security purposes), a digital data system channel, Public Packet-Switched Service (PPSS), or ISDN access (see GR-499-CORE, Transport Systems Generic Requirements (TSGR): Common Requirements). 5 35

118 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services 5.8 Unified Messaging GR-2844-CORE, Billing Measurements for Voice and Fax Messaging, defines billing records that can be generated by a Voice Messaging System (VMS). The billing record formats are flexible enough that they can easily be modified to be used by today s Unified Messaging platforms. The billing records cover the use of many VMS capabilities. GR-2844-CORE does not cover billing for electronic mail ( ) messaging, but the billing records can easily be extended to include it, e.g., Module 197: Flexible Length module - Flexible Length Field, could be appended to record an address. Table 5-9 lists the nine BAF structures and eleven BAF modules that can result from the occurrence of billable events (see GR-2844-CORE). For example, if distribution list editing occurs (see the first row), then a Profile Change structure should be generated and any module with an X in its column should be appended to the structure if it is applicable. Following are definitions of key terms used in describing the billing records: Call A series of events that begins when the VMS port goes off-hook (or receives an equivalent out-of-band signaling message) to 1) receive a call from the telephone network or 2) to initiate an outgoing call (outcall). The call ends when the call is completed and the port goes on-hook (or receives an equivalent out-of-band signaling message). Mailbox A logical abstraction referring to the locations in the VMS in which a subscriber s voice or fax messages are stored, and which are seen by a subscriber as a single logical storage area. Special mailbox types allow different functions to be performed. Outcall There are two types of outcalls: regular and network. A regular outcall is an outgoing call initiated by a VMS that is addressed to a phone number that does not represent another VMS (typically it is associated with a person). A network outcall is an outgoing call initiated by a VMS to a destination VMS with the intention of sending one or more messages to one or more subscribers on the destination VMS. Subscriber A person who has been assigned a mailbox number on a VMS. Subscribers have access to all features allowed by their class of service, and are not required to have an extension. Following is a description of structures or modules in Table 5-9 whose use may not be obvious from their names: Regular outcall versus network outcall billing structures: a regular outcall is a call initiated by a VMS to a person. A network outcall is a VMS-initiated call to another VMS for the purpose of sending a message to a subscriber on the destination VMS. Application Identifier module: records an application identifier used when the VMS accesses another platform to provide capabilities and uses an application identifier to identify the capabilities accessed. 5 36

119 Issue 1, May 2001 Notes on Billing AMA Recording for Special Services Multiple Mailbox Identifier module: identifies the sub-mailboxes of a mailbox. E.164 Number module: contains the 13-digit or longer international number destination of an outcall. Message/Outcall Attributes module: records attributes associated with a message sent or outcall made, e.g.: urgent priority message, wake-up or reminder outcall, distribution list message, and forwarded message. Recording infrequently needed billing information in separate modules which are appended as needed should minimize billing record size and thus facilitate transmission and processing. For example, the Mailbox Identity - Extender Digits module records digits that extend beyond the first ten of a mailbox identity. If the identity is ten or fewer digits, this module is not appended because these digits are recorded in the billing structure. This implementation avoids the overhead associated with frequently recording insignificant digits. The billing records should be provisionable (i.e., their generation should be turned on/off) on a system-wide, group, or subscriber basis for successful or unsuccessful billable events. 5 37

120 Notes on Billing Issue 1, May 2001 AMA Recording for Special Services Table 5-9 MDR Billable Events -- BAF Structures and Modules Billable Events Distribution List Editing Create/delete multiple mailbox Establish new schedule Class-of-service change Listen to voice mail Access informational mailbox Sending intrasystem message Information service message received Regular outcall to send a message Network outcall (using North American Numbering Plan (NANP) addressing) to send one or more messages Network outcall (using X.400 addressing) to send one or more messages Dial 0 for Operator or an extension Resulting BAF Structure Generated Alternate Billing Number Module 029 Application ID Possible BAF Modules Generated Mailbox ID - Extender Digits Destination System ID - Extender Digits Multiple Mailbox ID E.164 Number Module 164 Message/Outcall Attributes Module 270 profile change X X X X X daily count of messages reviewed intrasystem messaging (CTC 430/ SC 0430) regular outcall (CTC 431/ SC 0431) network outcall using NANP addressing network outcall using X.400 addressing dialing 0 or an extension Caller/Callee ID X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Fax Usage Class of Service Change Interexchange Carrier Identifier Port usage measurements port usage X X X X X Storage usage daily storage usage X X X X 5 38

121 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services 6 AMA Recording for Advanced Digital Services Section 6 provides an overview of usage measurements for advanced digital services; specifically, Integrated Services Digital Network (ISDN) for traditional circuit switches and Asynchronous Transfer Mode (ATM), Switched Multi-Megabit Data Service (SMDS), and Frame Relay service for broadband communications technologies. This section includes an overview of the data generation and usage formats that support billing for ATM Permanent Virtual Connection (PVC) and Switched Virtual Connection (SVC). This section also discusses how usage information, in general, is generated by a Broadband Switching System (BSS). 6.1 Recording for Integrated Services Digital Network (ISDN) Calls ISDN is an open-ended plan for organizing digital technology to provide digital services to sophisticated digital terminals. Digital services between user premises can provide voice and data services superior to existing circuit-switched networks, both in transmission quality and call management capabilities. As ISDN capabilities have been added to conventional telephony capabilities, the new billing data capabilities have also been added to existing data recording and transmission systems. Thus, the receiving administrative systems (billing mediation platforms and the billing system itself) receive a mixture of conventional and ISDN data records. The ISDN AMA generic requirements are defined in GR-862-CORE, ISDN Automatic Message Accounting Generic Requirements Background An ISDN call is placed by or received by a user with ISDN access. ISDN provides many new transmission and signaling capabilities, as well as new and expanded call management features. For ISDN calls that require generation of a detailed AMA record based on origin and destination, additional fields of data are added to the applicable, already defined, AMA record structures. For ISDN calls that do not require a detailed record based on origin and destination, an option is provided to make either a detailed record, or an aggregate (non-detailed) record, to permit billing for use of the ISDN capabilities employed on that call. Aggregate recording is provided as an alternate means of identifying the use of a supplementary service. The areas in which ISDN introduces new service and tariff concepts are principally the following:bearer capability, signaling capability, and call management capabilities. In addition, ISDN provides for recording the cause code included in the signaling message to capture how/why the call disconnected. These new capabilities are discussed in the following sections to assist in understanding the basis for the required AMA record provisions. 6 1

122 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services ISDN Bearer Capability Bearer capability identifies the transmission capability provided to the user at the network boundary, either between ISDN users on the same network or between the ISDN user and the interworking point to another network. The following values are defined for ISDN: circuit-mode, 64-kbps Usable for Speech circuit-mode, 64-kbps Usable for 3.1-kHz Audio Information circuit-mode, 64-kbps Unrestricted Digital Transmission circuit-mode, 64-kbps Unrestricted Digital Transmission rate adaption from 56-kbps packet-mode, Unrestricted, virtual call and permanent virtual circuit service. These bearer capabilities are divided into three categories on which most call control parameters and procedures are based. These categories are: voice/voice band data (Speech and 3.1-kHz Audio Information) circuit-mode data (56 and 64-kbps unrestricted) packet-mode data. The network may use different resources in providing these connections and may charge distinctively for them. The network provider may also wish to charge differently from similar services provided by existing networks. For example, an ISDN speech call may not be charged at the same rate as a PSTN call between the same exchanges. It is assumed that all circuit-mode calls will continue to be charged on the basis of time of day, duration and geography, rather than new criteria, e.g., total information bits transmitted. The bearer capability requested by the calling user (or in some cases, an alternate bearer capability) will be provided if the called user is also an ISDN access interface and the Interexchange Carrier (IC) requested provides an ISDN capability. If not, the call may be completed by means of an interworking arrangement that converts the signaling and transmission as appropriate to the connected network or access line. Whether the switch decides to make an AMA record will also depend on the use or non-use of any supplementary services. Circuit-mode billing data may be collected and recorded by different subsystems within the switching system and then integrated into a single data delivery capability to the Revenue Accounting Office (RAO). GR-508-CORE, LSSGR: Automatic Message Accounting (AMA), and GR-385-CORE, Automatic Message Accounting Teleprocessing Systems (AMATPS) Generic Requirements, contain requirements for magnetic tape and data link implementations of AMA data delivery systems; GR-1343-CORE, Generic 6 2

123 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Requirements for the Automatic Message Accounting Data Networking System (AMADNS), contains requirements for AMA data networking ISDN Signaling Capability ISDN provides out-of-band signaling capabilities, both at the user interface and within the network. Therefore, there is a potential for sending signaling information as part of a call establishment signal. Furthermore, it may be delivered before, or in the absence of, call answer. A Local Exchange Carrier (LEC) may wish to charge for use of an ISDN signaling capability, even though the associated call is not charged for, either because of no answer or because it is a local call based on the destination and bearer capability. It is anticipated that these signaling capabilities will be tariffed as services normally billed to the call originator except for Calling Party Number (CPN) and Calling Party Subaddress. The amount of information contained in these information elements can be significantly large in size. Consequently, consideration of the maximum size of these information elements can be important. The signaling capability data is described in Table 6-1. Table 6-1 ISDN Signaling or Supplementary Service Usage Capabilities Parameter Size Calling Party Number 19 octets Calling Party Subaddress 23 octets Called Party Subaddress 23 octets Low-Layer Compatibility 10 octets High-Layer Compatibility 5 octets User-User Signaling Information 131 octets Only the use (yes or no) or other service outcome of each capability will be recorded in AMA. The content of the information elements, other than CPN, is not a concern of the network and is not included in an AMA record. The Signaling or Supplementary Service Capability Usage field (BAF Table 413) specifies how to record the use of these capabilities (except CPN delivery). There are several aspects that affect recording procedures for a signaling capability. The aspects of importance are as follows: Which party subscribes to the service and is to be billed In which switching system the call detail record is made The content of the call detail record. For internetwork circuit-mode calls, whether or not answered, the originating switch always generates a record. 6 3

124 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services For internetwork circuit-mode calls, the terminating switch generates a detailed record if the call is answered. There is an option not to generate detailed records for unanswered calls that do not provide an IC supplementary service. This eliminates unnecessary recording of calls that are not components of IC terminating access billing. If, however, the internetwork circuit-mode call is not answered but provides an IC supplementary service, the switching system will generate a detailed record ISDN Capabilities Having No AMA A supplementary service may or may not have AMA recording requirements. Some services affect only the monthly service charge and have no usage component and therefore no need to make an AMA record, e.g., Basic Business Group (BBG) services such as Direct Inward Dialing (DID). Other services may involve usage charges and therefore require an AMA record, e.g., call forwarding. The following list of services have no AMA impact: A. ISDN Hold Capability B. Basic Business Group for ISDN Lines: Business Group Element Business Group Dialing Plan Single-digit Dialing Attendant Access Speed Dialing Critical Interdigital Timing Business Group Line Restrictions Special Intercept Distinctive Alerting ISDN Record Types ISDN calls that do generate AMA will use SC 0690 when no other currently defined structure is appropriate. The structure consists of the common data fields that identify the source of the record in the usual way, together with four fields that identify the served user, date, and time. SC 0690 is used for Detailed as well as Aggregate Records generated for both Originating and Terminating service types. There are exceptions to the use of this structure and note that it is not to be used for call processing events for which there is an already defined Billing AMA Format (BAF) record (e.g., Automatic Callback and Calling Number Identification services). 6 4

125 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services The ISDN default call type codes used with SC 0690 are: CTC 045 ISDN User Service (detail record) CTC 183 ISDN Daily Aggregate of Service Event Deliveries Per User. This record is generated once each day. CTC 184 ISDN Terminating User Service. This record is generated per terminating event when no other terminating record is generated ISDN Core Module For an ISDN supplementary service or signaling capability, there are three recording options at an originating or terminating switching system. 1. Make no record. 2. Make individual aggregate records per user per day for invocation of the signaling or supplementary service capability and make an aggregate record per user per day for calls that make no use of any signaling or supplementary service capability. 3. Make a detailed record. An ISDN Core module (Module 070) is appended to AMA records to identify the use of ISDN supplementary services on an ISDN call. The ISDN Core module or the abbreviated ISDN Core module (Module 071) will be appended depending on the particular service invoked. The modules are identical except that the abbreviated module does not include BAF Table 413 (Signaling or Supplementary Service Capabilities Usage). Table 6-2 describes the ISDN Core Module (Module 070). Table 6-2 ISDN Core Module Description BAF Table Value or Indication Module Identification Table Module Code Network Interworking Table 410 Indicates ISDN end-to-end or interworking at some point Release Cause Indicator Table 411 Reason for the termination of the call Bearer Capability Table 412 Bearer capabilities and Bearer Call Type delivered to the user Signaling or Supplementary Service Capabilities Usage [Module 070 only] Table = Feature not used or not recorded 2 = Feature used, presumed delivered 3 = (User-to-user only) Feature used, but not delivered 6 5

126 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services Application of ISDN Modules Most, but not all currently defined record structures and call types will be applicable to ISDN records. When a BAF structure code is used for an ISDN call, it will have a ten-thousand digit with value 4. For example, if CTC 001 is generated for an ISDN local measured call, the structure code value will be and Module 070 will be appended. A value of 4 in the ten-thousand digit of the SC field indicates there are 2 or more modules appended. In this case Module 070 and the final Module 000. GR-862-CORE and GR-1100-CORE contain complete information on the association between call type codes and structure codes for ISDN calls Recording of Supplementary Services For each supplementary service or signaling capability, the switching system provides options to generate no record, and/or an aggregate record, and/or a detailed record. Table 6-3 lists the capabilities and the recording options: Key: No = No record Aggregate = Aggregate Detailed = Detailed Table 6-3 Recording for Supplementary Services Capability Intranetwork Internetwork Calling Number Delivery No or Aggregate No or Aggregate Calling Party Subaddress Delivery No or Aggregate No or Detailed or Detailed Called Party Subaddress Delivery No or Aggregate No or Detailed or Detailed Low Layer Compatibility Information No or Aggregate No or Detailed or Detailed High Layer Compatibility Information No or Aggregate No or Detailed or Detailed User-to-User Information/Fast Select No or Aggregate No or Detailed or Detailed Automatic Callback No or Detailed Calling Name Delivery Calling Name Delivery Act./Deact. Calling Name Delivery Blocking Calling Identification Delivery and Suppression Presentation of Calling Name Inspect No or Aggregate No Not Applicable No or Detailed No or Detailed No or Detailed No or Aggregate All Calls 6 6

127 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Table 6-3 Recording for Supplementary Services (Continued) Capability Intranetwork Internetwork EKTS User Bridging No or Detailed EKTS DN Bridging No or Detailed EKTS Intercom Calling No or Detailed EKTS Automatic Bridged Exclusion No or Detailed EKTS Manual Bridged Exclusion No or Detailed EKTS Station Ringing Transfer No or Detailed Additional Call Offering - Offered No or Aggregate Additional Call Offering - Accepted No or Aggregate Call Pickup CPU No or Detailed Call Pickup DPN No or Detailed Call Pickup DPU No or Detailed Flexible Calling No or Detailed CNI Public to Private Activation No or Detailed CNI Private to Public Activation No or Detailed CNI Non-delivery - Number Private/Unavailable No or Aggregate CNI Activation/Deactivation No Stop-hunt Activation/Deactivation No or Detailed Make-busy Activation/Deactivation No or Detailed Call Waiting Originating No or Aggregate Dial Call Waiting No or Aggregate BBG Intercom Calling No or Detailed BBG Private Facility/Network Access No or Detailed Message Service No or Aggregate Selective Call Forwarding No or Detailed Automatic Recall No or Detailed WATS with Call-by-Call Service Selection No or Detailed Multiswitch Business Group No or Detailed ISDN Basic Call Recording Basic ISDN calls are classified into three broad categories: Originating Calls, Terminating Calls, and Inverse Multiplexing. These can be further broken down into Intranetwork calls and Internetwork calls. 6 7

128 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services Originating ISDN Calls For originating ISDN Intranetwork calls, a BAF record may be generated as described in GR-508-CORE. The applicable call type code is determined by the switch. The ISDN Core Module is appended to the BAF record. If a BAF record is not normally generated for the call and an AMA record is needed, then the ISDN SC 0690 will be generated with a switch-based call type code, if available. Otherwise, CTC 045 will be used. For originating internetwork circuit-mode calls, whether or not answered, the originating switch always makes a record. Originating Access for Internetwork Calls is covered in detail in GR-1083-CORE and GR-1298-CORE. There are no other special ISDN requirements for these types of calls Terminating ISDN Calls Terminating Recording at the User Line Termination For Terminating ISDN intranetwork calls, a new record (ISDN SC 0690) may be required depending on the specific service capability and the subscription option of the called user. If a detailed record already exists for a terminating user service, then that record will append the ISDN Terminating User Service Module (Module 073). Module 073 is used in association with a terminating call record (e.g., Terminating Study Record) or with an ISDN SC 0690 to record the usage of supplementary services delivered to a called user with an ISDN line termination. Table 6-4 describes the ISDN Terminating User Service Module (Module 073). Table 6-4 ISDN Terminating User Service Module Description BAF Table Value or Indication Module Identification Table Module Code Terminating Signaling or Supplementary Service Usage Table 409 Indicates the set of supplementary services delivered to the end user Interexchange Carrier Table 57 IC/INC transport carrier (if applicable) Bearer Capability / Call Type Table 412 Bearer capabilities and Bearer Call Type delivered to the user The terminating user service record may have a different entry in the supplementary service use data than the originating user entry or the terminating access entry because the terminating switching system may find the service deactivated (e.g., for Calling Party Subaddress). When a basic call does not otherwise require a detailed record (e.g., for a call within a flat rate area or an unanswered intranetwork call) and the network provider requires a detailed AMA record (including the calling party number) for a call that terminates to a specific end user, the switching system generates the ISDN 6 8

129 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Terminating User Service CTC 184 / SC If there is no need to capture the calling number in a record of service to a called user (e.g., use of the Multi-Line Hunt Group feature), the ISDN SC 0690 is generated instead of SC ISDN Terminating Exchange Access AMA Recording For internetwork ISDN (terminating exchange access) circuit-mode calls, the terminating switch makes a detailed record if the call is answered. There is an option not to make detailed records for unanswered calls that do not provide an IC supplementary service. If, however, the internetwork circuit-mode call is not answered, but provides an IC supplementary service, the switching system will generate a detailed record. This eliminates unnecessary recording of calls that are not components of IC terminating access billing. The recording point for an internetwork call is the switching system where it enters the Local Access and Transport Area (LATA). This could be an Access Tandem or the terminating switching system depending on the routing used. In a switching system that performs both the terminating access and terminating functions, both records may be required, however, at least one record, the terminating access record, will always be recorded. There is an option, but no requirement, to make aggregate records of supplementary service or signaling capability for terminating access calls from an IC/INC ISDN Aggregate Records The cost of generating a detailed record may not be justified or necessary for calls or events for which only small or no charges apply. Aggregate records provide a more efficient alternative. ISDN-capable switches use SC 0690 as the basis for aggregate records for both originating and terminating type services. When the aggregate record option is specified for a supplementary service, the switch will generate an aggregate or detailed record as appropriate. An event is recorded in the ISDN Core Module (Module 070) or the Terminating User Service Module (Module 073) used for the detailed record of the associated call, if there is one. Otherwise, the event is recorded in a Daily Aggregate Service Event Module (Module 072) using SC An event should not be counted in both a detailed and an aggregate record in the same network. 6 9

130 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services The Service Event Module Table 6-5 describes Module 072, Daily Aggregate of Service Event (DASE) module. It identifies the capability for which an aggregate record is made. Table 6-5 ISDN Daily Aggregate Service Event (DASE) Module Description BAF Table Value or Indication Module Identification Table Module Code ISDN Signaling or Supplementary Service Capability Identification Table 414 The capability for which an aggregate record is being made. Intrastate Event Count Table 803 Five-digit number Interstate Event Count Table 803 Five-digit number Charging Indicator Table 64 Identifies the type of call, validity of the call segment count, and the user charged for the call. Interexchange Carrier Table 57 Identifies the IC/INC that transports the call. Bearer Capability/Call Type Table 412 The bearer call type and bearer capabilities delivered to the user Summary Table 6-6 and Table 6-7 provide an overview of the recording capabilities for ISDN calls. Table 6-6 covers Signaling Capabilities. Table 6-6 Recording for ISDN Signaling Capabilities Signaling Capabilities BAF Table 409 or BAF Table 413 Reflecting Usage Requires Additional Record Using SC 690 Aggregate Usage Record with BAF Table 414 Calling Party Number N N Y Called User Subaddress Delivery Y N Y (1) Calling User Subaddress Delivery Y N Y (1) Low Layer Compatibility Delivery Y N Y (1) High Layer Compatibility Delivery Y N Y (1) User-to-User Signaling with Call Y N Y (1) Control Note 1: Intranetwork calls only. 6 10

131 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Table 6-7 covers Supplementary Services. Table 6-7 Recording for ISDN Supplementary Services Supplementary Services BAF Table 409 or BAF Table 413 Reflecting Usage Requires Additional Record Using SC 690 Aggregate Usage Record with BAF Table 414 Basic Business Group N (2) N N ISDN Electronic Key Telephone Service ~~~ User Bridging N (2) N Y ~~~ Directory Number Bridging N (2) N Y ~~~ Intercom Calling N (2) N N ~~~ Automatic Bridged Exclusion N (2) N Y ~~~ Manual Bridged Exclusion N (2) N Y ~~~ Station Ringing Transfer N (2) N N ISDN Flexible Calling Y N Y ISDN Call Forwarding N N Y ISDN Call Pickup N (2) N Y Additional Call Offering Y N Y Call Waiting - Originating Y N N Dial Call Waiting Y N N ISDN Automatic Callback N N Y User-to-User Signaling with Call Y N Y (1) Control ISDN Calling Number Identification N N Y ISDN Multiline Hunt Group N Y N CNI Activation/Deactivation N N N CNI Non-delivery N N Y ISDN Message Service N N Y ISDN Selective Call Forwarding N N (3) N ISDN Automatic Recall N Y N Multiswitch Business Group N (2) N N ISDN Primary Rate Interface N N N Call-by-Call Service Selection N N N ISDN Calling Name Delivery Services N N Y ISDN Calling Identity Delivery and N Y N Suppression Presentation of Calling Name N Y N 6 11

132 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services Table 6-7 Recording for ISDN Supplementary Services (Continued) Supplementary Services BAF Table 409 or BAF Table 413 Reflecting Usage Requires Additional Record Using SC 690 Aggregate Usage Record with BAF Table 414 ISDN Inspect N N Y Note 1: Intranetwork calls only. Note 2: A module specific to this service follows the ISDN Core Module, therefore BAF Table 409 or BAF Table 413 is not used. Note 3: Detailed records of Screening List Editing events ISDN Inverse Multiplexing If an ISDN user wants to use more than the 64-kbps circuit-switched data capacity of a single B-channel (i.e., both B-channels in a Basic Rate Interface (BRI) or two or more channels on a Primary Rate Interface (PRI)) on a connection to a BRI or PRI user, the originating ISDN terminal may place two or more nearsimultaneous calls to that user destination. The originating customer premises equipment may be arranged to demultiplex the original high bit rate data stream and the terminating customer premises equipment may be arranged to re-multiplex the two or more 64-kbps received streams. This operation is sometimes called inverse multiplex. The network should treat these as two or more independent calls from a switching, signaling and AMA recording standpoint. That is, multiple, nearly or exactly identical records may result. Because some RAOs have been programmed to reject identical AMA records as potentially redundant, an AMA element was introduced to distinguish AMA records resulting from inverse multiplex calls. The B-channel Identifier field is used for this purpose in the originating switching system. Terminating access and terminating AMA records are subject to the same phenomenon and the incoming trunk identification is used to distinguish AMA records in the terminating access and terminating switching system. Note that all ISDN circuit-mode calls are affected, because the switching system has no way of recognizing inverse multiplex calls. For originating ISDN circuit-mode calls, the switching system appends the ISDN Channel Identifier module (Module 180) to all originating ISDN call records. The ISDN Channel Identifier field (BAF Table 195) of Module 180 is populated with the identity of the B-channel used for originating access. The switching system also appends Module 180 to detailed records of service delivery by an originating call to a terminating user (i.e., an intranetwork calls). The switching system populates BAF Table 195 with the called party's B-channel assignment, if available. If unavailable, then the switching system populates this field with a unique identifier (e.g., the 6 12

133 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services originator s B-channel [preferred implementation], a random number, or number generated by a counter with at least 1000 values). For incoming (terminating) ISDN calls, the switching system appends the Incoming Trunk Identification module (Module 181) to identify the incoming trunk. The switching system populates the Trunk Identification field (BAF Table 244) of Module 181 with the identity of the incoming trunk. The switching system also appends Module 181 to detailed records of service delivery by an interswitch incoming call to the terminating user. See GR-862-CORE, Section 3, for further information regarding AMA for ISDN Supplementary Services and Signaling Capabilities and Section 4 for the AMA requirements related to Integrated Customer Advanced Networking (ICAN). 6 13

134 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services 6.2 Broadband Services Recording Figure 6-1 illustrates a high-level view of a Broadband Switching System (BSS). The labels and terms included in Figure 6-1 will be discussed throughout this section. The BSS may terminate several transport interfaces, as well as interfaces for network signaling and operations. Some LECs may choose not to support some of these interfaces for particular applications. For example, for Switched Virtual Connection (SVC) service support, signaling functionality and interfaces are required. For Permanent Virtual Connection (PVC) services, the signaling functionality and interfaces are not required. Operations Interface LEC Operations Network User Equipment SMDS SNI Frame Relay UNI ATM UNI CE DS1/DS3 Broadband Switching System CCS Links IISP B-ICI Frame Relay NNI PNNI LEC Broadband Network Service Access Multiplexer CCS Links B-ICI SMDS ICI Frame Relay NNI IISP IC/LEC Broadband Network Figure 6-1 Broadband Switching System Background A BSS may be implemented in an integrated or a modular fashion. An integrated BSS would include all functionality (e.g., call/connection control and switching fabric) in one physical system. A modular BSS would have its functionality divided into separate physical systems where these various physical systems may or may not be dispersed in a geographic area. For example, a modular BSS may consist of a remotely located line termination and multiplexing physical systems with the call/ connection control physical systems centrally located. 6 14

135 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Based on the needs of specific LECs, the BSS may also be required to support service-specific access interfaces for SMDS, FRS, and DS1/DS3 Circuit Emulation Service. Switch to switch communication is accomplished using the Intranetwork protocol (Interim Inter-Switch Protocol (IISP) or Private Network-Network Interface (PNNI)) within a single LEC network. Broadband Network-Network Interface (B- NNI) is used to interconnect a BSS of a LEC with a BSS of an IC or another LEC network within the same LATA. When the B-NNI provides connectivity between a LEC s network and an IC s network to facilitate an IC's offering of interexchange services, a LEC offers the exchange access service to the IC. Previously, the interface for connecting two broadband switches was called a Broadband Inter-Carrier Interface (B-ICI). The term B-ICI is no longer used in the generic sense. Instead it refers specifically to a network to network interface (B- NNI) that supports the B-ICI protocol. BNNI is the generic name for the network to network interface which can support B-ICI or IISP. Again, based on the needs of specific LECs, the BSS may be required to support several service-specific trunk interfaces. Specifically, the BSS must terminate the DS3 rate SMDS-specific ICI, based on the IEEE protocol, for interconnection with an IC or other LEC SMDS switching systems. Similarly, a DS1 rate servicespecific trunk interface for Frame Relay (i.e., the Frame Relay Network-Network Interface (NNI)) is required on the BSS. The functions of the BSS can be divided into Transport-Related Functions, Control- Related Functions, and Traffic Control and Usage Measurement Functions. Figure 6-2 illustrates the BSS Functional Reference Model. This model is implementation independent. The functional boundaries shown do not necessarily indicate physical switching system component interfaces. Not all of the functions shown in Figure 6-2 may be required in particular BSS implementations, depending on such factors as specific LEC applications and service needs. 6 15

136 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services CONTROL-RELATED FUNCTIONS Broadband Signaling, Call/Connection Processing, and Operations Functions TRANSPORT-RELATED FUNCTIONS SMDS Functions User-Network Exchange Termination Service-Dependent Functions Frame Relay Functions ATM Adaption Layer Functions ATM Switching Circuit Emulation Functions Inter-working Functions Network Exchange Termination TRAFFIC CONTROL AND USAGE MEASUREMENT FUNCTIONS Traffic Control and Congestion Control Functions Usage Measurements for Billing Functions Service-Independent Functions Figure 6-2 BSS Functional Reference Model Usage Measurement Functions For owners of BSSs, usage information may be used to analyze customer usage patterns and behavior. These patterns are key to evaluating how customers use ATM/Broadband Network services to satisfy their business goals and are an important component of the product development process. Usage information can also be used to help identify required billing arrangements for customers using these new capabilities. Once appropriate billing arrangements are identified, the usage information can provide the basis for cost studies and other reports that support tariff filings. For customers, access to usage information is an important component of a Customer Network Management (CNM) service. Initially, customers might not have a clear picture of how ATM/Broadband Network services contribute to their business goals and may want to analyze their usage patterns. Consequently, customers could retrieve usage information using CNM to determine how its various business units use these services and how the service capabilities address its business goals. Some customers could use the usage information to charge back networking costs to specific business units. 6 16

137 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services 6.3 Recording for Asynchronous Transfer Mode (ATM) Calls To support billing for services provided by the BSS, functions are performed by both the LEC network and the LEC billing system. Within the LEC network, usage measurement functionality includes: Data generation the process of determining what usage information must be collected and producing the necessary information. In AMA terminology, the data element values provided by the network are formatted into one or more fields or tables. The generation functionality assembles the data elements into an unformatted usage record. Data formatting the process of formatting the unformatted usage records into BAF. Data transmitting the process of outputting BAF records to the AMA data transport systems that will transport the records to the billing system Permanent Virtual Connection (PVC) Services GR-1110-CORE, Broadband Switching System (BSS) Generic Requirements, provides data generation and data formatting requirements for the service-independent usage information generated for an ATM Permanent Virtual Connection (PVC). The requirements apply to both a permanent PVC and a Soft Permanent Virtual Connection (SPVC). A permanent PVC is one for which the connection is permanently established over the entire path of the connection (i.e., from end user to end user). An SPVC is a PVC for which the segment of the connection between the broadband switches serving each end user is switched in nature, and the segments of the connection between the broadband switches and the end users they serve are permanently established. For the purposes of this document, permanent PVCs and SPVCs are considered to be types of PVCs. Any general reference to PVC applies to both types of PVCs. Data generation and data formatting specific to SPVCs will be so noted. The requirements in GR-1110-CORE apply to ATM PVCs that are offered directly to customers (as PVC Cell Relay Service or SPVC Cell Relay Service) and to ATM PVCs that support other services (such as SMDS). The requirements define the serviceindependent functions (such as counting cells) and the interface identifiers (such as the Remote Interface Identifier and the FRS Interface Identifier) that are included in the usage information. Service-specific usage information may also be generated by network nodes that provide service-specific functions. The service-specific usage measurement needs for SMDS is discussed in Section 6.4 and Frame Relay in Section 6.5. Data generation requirements for inter-carrier ATM PVC services are provided in Section 12 of the ATM Forum s B-ICI Specification, Version 2.0. GR-1110-CORE does not repeat those requirements, but refers to them. GR-1110-CORE also defines 6 17

138 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services additional capabilities that must be supported in addition to the ATM Forum s requirements Data Generation The data generation requirements for ATM PVCs are provided in Section 12 of the ATM Forum s B-ICI Specification, Version 2.0. Although the ATM Forum s B-ICI Specification, Version 2.0, specifically addresses inter-carrier ATM PVCs, the capabilities defined in that document may be applied to any ATM PVC supported by the BSS, including both intranetwork and internetwork ATM PVCs. The service-independent usage measurement functionality provides a flexible capability to measure the amount of data transported on an ATM PVC. This amount of data is characterized by the following cell counts: Ingress Total Cells Ingress High Priority Cells Egress Total Cells Egress High Priority Cells. These cell counts may be generated by the LEC network for each ATM PVC at a recording interface. Recording interfaces may be ATM/Broadband User Network Interfaces (UNIs) or Broadband Network-Network Interfaces (B-NNIs). Depending on the usage measurement needs of the LEC, usage information for a Point-to-Point ATM PVC may be generated, respectively, at a single interface for the ATM PVC, at both interfaces for the ATM PVC, or at no interface (i.e., no usage information is generated for the ATM PVC). Similarly, usage information for Point-to-Multipoint ATM PVCs may be generated at the root interface, at one or more leaf interfaces, or at no interface (usage information for Point-to-Multipoint ATM SPVCs requires further study). The LEC controls usage measurement generation by separately specifying ingress and egress usage information as active or inactive for each ATM PVC at each ATM/Broadband UNI or B-NNI. Cell counts are generated during recording intervals, which are LEC-settable. As described in the ATM Forum s B-ICI Specification, Version 2.0, the minimum recording interval is one hour, the maximum is one day, and the default is one hour. The LEC also has the capability to use 15-minute recording intervals for a limited number of ATM PVCs. Each of the aforementioned cell counts is generated for each ATM PVC during each recording interval. The cell counts for a recording interval are assembled with LEC-settable parameters that identify the ATM PVC and the service supported by it. These parameters include Recording Interface Recording Connection Identifier Carrier Identifier (for inter-carrier ATM PVCs only) 6 18

139 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Type of Service Supported (e.g., SMDS, FRS). As described in the ATM Forum s B-ICI Specification, Version 2.0, usage records are generated at scheduled closings and unscheduled closings. Scheduled closings are scheduled conclusions of recording intervals (e.g., at the end of every hour). Unscheduled closings are un-scheduled (i.e., premature or delayed) conclusions of recording intervals, due to factors such as memory exhaust and usage measurement functionality failure. The complete set of usage information (including data elements defined in the following subsections) generated for an ATM PVC at a recording interface during a recording interval is assembled by the generation functionality into an unformatted usage record. These usage records are then provided to the formatting functionality. The ATM Forum s B-ICI Specification, Version 2.0, calls for a usage record to be assembled and forwarded only if one or more of the associated cell counts has a non-zero value. It is vital that the BSS produce a usage record when all of the cell counts have zero values if these values are due to the generation functionality experiencing a problem in counting cells AMA Recording for Intranetwork Switched Virtual Connections (SVCs) SC 0214, and the appropriate BAF modules, as described in GR-1110-CORE and in the latest issue of GR-1100-CORE, is used to represent the detailed usage information for ATM SVCs. SC 0214 with Call Type 610 is used to generate a record for a Point-to-Point originating intranetwork ATM SVC. The structure captures originating intranetwork ATM SVC service usage at the originating BSS UNI. SC 0214 with Call Type 619 is used to generate a record for a Point-to-Point terminating intranetwork ATM SVC. The structure captures terminating intranetwork ATM SVC service usage at the terminating BSS UNI Short Duration ATM Calls SC 218 is used to record short-duration ATM connections. Note that SC 0218 is used for both intranetwork and internetwork short-duration aggregation records. The following call type codes are applicable: CTC 581 Originating Intranetwork Short-Duration ATM SVC Aggregation usage recorded at the Originating BSS UNI. CTC 582 Terminating Intranetwork Short-Duration ATM SVC Aggregation usage recorded at the Terminating BSS UNI. CTC 583 Originating Internetwork Short-Duration ATM SVC Aggregation usage recorded at the Originating BSS UNI 6 19

140 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services CTC 584 Originating Internetwork Short- Duration ATM SVC Aggregation usage recorded at the Originating Network B-NNI. CTC 585 Terminating Internetwork Short-Duration ATM SVC Aggregation usage recorded at the Terminating Network B-NNI. All of these call type codes use SC AMA Recording for Internetwork SVCs SC 0217, and the appropriate BAF modules, as described in GR-1110-CORE and in the latest issue of GR-1100-CORE, is used to represent the detailed usage information for ATM Internetwork SVCs. SC 0217 has the identical fields of SC 0214 in addition to the carrier-related fields added at the end of the structure. SC 0217 with Call Type 611 is used to generate a record for originating Internetwork ATM SVC usage recorded at the originating BSS UNI. SC 0217 with Call Type 612 is used to generate a record for originating Internetwork ATM SVC usage recorded at the originating network B-ICI. SC 0217 with Call Type 613 is used to generate a record for terminating ATM SVC usage recorded at the terminating network B-ICI AMA for PVCs SC 0216, and the appropriate BAF modules, as described in GR-1110-CORE and in the latest issue of GR-1100-CORE, is used to represent the detailed usage information for an ATM PVC. SC 0216 with Call Type 608 is used to generate a record for the usage flowing across an Intranetwork ATM PVC. SC 0216 with Call Type 609 is used to generate a record for he usage flowing across an Internetwork ATM PVC. Generally, this structure code provides Cell Counts over a give interval for a particular PVC Modules Associated with ATM Each of the structure codes applicable to ATM usage measurements have modules that may be appended when circumstances warrant. The modules listed in Table 6-8 are associated with each of the ATM structures. The modules listed are unique to ATM recording, however, they may not be the only modules that are appended to the structure. For example, the Cell Counts module (Module 145) is appended to SC 0216 when three or four non-zero cell counts are generated for the ATM PVC at the recording interface during the recording interval. The Carrier Identifier module 6 20

141 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services (Module 146) is also appended if one carrier is to be identified and a second Carrier Identifier module (Module 146) if two carriers are to be identified. A Generic Module with Elapsed Time (Module 617) may also be appended when one or more disconnects/re-connections occurs during a recording interval, followed by the final module (Module 000). Refer to GR-1110-CORE and GR-1100-CORE for complete information on when modules are appropriately appended. Table 6-8 Module Codes Appended to ATM Records. Structure Code Module Code Meaning 022 Long Duration Connection 128 ATM End System Addresses 141 One ATM Traffic Parameter Two ATM Traffic Parameters 143 ATM Address Format 144 ATM Rate Periods 148 Three ATM Traffic Parameters 611 Generic Module: One Digits String Format 612 Generic Module: Two Digits String Format 142 Two ATM Traffic Parameters 145 Cell Counts Carrier Identifier 148 Three ATM Traffic Parameters 611 Generic Module: One Digits String Format 022 Long Duration Connection 128 ATM End System Addresses 141 One ATM Traffic Parameter Two ATM Traffic Parameters 143 ATM Address Format 144 ATM Rate Periods 148 Three ATM Traffic Parameters 611 Generic Module: One Digits String Format 612 Generic Module: Two Digits String Format 6 21

142 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services 6.4 Recording for SMDS SMDS is a public, connectionless, packet-switched service that provides for the transfer of variable-length data units at a high speed without the need for call establishment procedures (a distinguishing feature of connectionless services). These data units can be transferred from a single source to a single destination (singlecast), or from a single source to multiple destinations (multicast). The integrity of each delivered data unit is provided with a high degree of reliability. Some generic features of SMDS include Source Address Validation, Address Screening, and Group Addressing capabilities. SMDS is specified such that, under normal conditions, subscribers' end-to-end protocols and applications easily ride on top of the SMDS service layer. This provides the capability of supporting user applications such as Local Area Network (LAN) interconnection, data transfer, and image transfer. Service-independent usage information SMDS Specific Functions SMDS-specific usage information SMDS Customer UNI or B-ICI ATM Switching LEC ATM Network Figure 6-3 SMDS Usage Information Exchange SMDS is a service provided entirely within one LEC network. Generic system requirements for Exchange SMDS are defined in TR-TSV , Generic System Requirements in Support of Switched Multi-megabit Data Service and TR-TSV , Usage Measurement Generic Requirements in Support of Billing for Switched Multi-megabit Data Service. 6 22

143 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services Intranetwork SMDS Recording The basic SMDS Intranetwork AMA recording is recorded at the ingress of an SMDS-capable switching system. CTC 220, Intranetwork SMDS Aggregate Usage record, is generated along with SC For SMDS SC 0760, BAF Tables 13, 14, 16, 17, 438, and 439 are populated according to exception requirements listed in GR CORE Intranetwork SMDS Audit Records In addition to aggregate recording for SMDS packets, an AMA record has been designed to capture audit information over an aggregation period (as defined by the switching system or options available to the network provider). CTC 221 / SC 0761 has been defined for this purpose. SC 0761 consists of the first eleven data fields defined for SC 760 plus three instances of BAF Table 808 to capture packet counts for the aggregation period defined: Successfully delivered packets Partially delivered packets Other exceptions Exchange Access and Internetwork SMDS Recording Exchange Access SMDS is an access service provided by a LEC to an Interexchange Carrier (IC) to support the IC s SMDS, when the sending or receiving end-user is directly served by the LEC network. LEC-LEC serving arrangements are agreements between LECs within a single LATA. These agreements define the way each LEC supports the services that the other LEC provides (e.g., exchange and exchange access services). Exchange Access SMDS and LEC-LEC serving arrangements are defined in GR-1060-CORE, Switched Multi-megabit Data Service (SMDS) Generic Requirements for Exchange Access and Intercompany Serving Arrangements. SMDS Exchange Access AMA recordings are made at both the ingress and egress of an SMDS-capable switching system. The following call type codes can be recorded for internetwork SMDS: CTC 222 Originating Exchange Access SMDS Usage CTC 223 Terminating Exchange Access SMDS Usage CTC 224 SMDS Source Network Functions Intercompany Serving Arrangements CTC 225 SMDS Destination Network Functions Intercompany Serving Arrangements CTC 226 SMDS Transit Network Functions 6 23

144 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services CTCs 222 through 225 are generated with SC CTC 226 uses SC BAF Tables for Internetwork SMDS Recording For SMDS SC 0762 and SC 0763, BAF Tables 16, 17, 438, and 439 are populated according to exception requirements listed in GR-1100-CORE. In addition, for SMDS structure codes 0762 and 0763, BAF Table 13 is called Source Address Field 1 and contains the first three digits of the source address. These digits are taken from the Source Address field in the SMDS Level 3 Protocol Data Unit (L3_PDU). In that field, the 12 bits in bit positions 9 through 20 parse into the three Binary-Coded Decimal (BCD) characters recorded in this field in a BAF record. BAF Table 14, Source Address Field 2, contains the last seven digits of the source address. These digits are taken from the Source Address field in the SMDS L3_PDU. In that field, the 28 bits in bit positions 21 through 48 parse into the seven BCD characters recorded in this field in a BAF record. BAF Table 83 - Trunk Group Number / Signaling Type Identifier In SC 0762, this field is called Incoming/Outgoing ICI Transmission Path Set Identification. It indicates whether usage information is for SMDS traffic transmitted across a Subscriber Network Interface (SNI) or an Inter-Carrier Interface (ICI). If the usage information is for SMDS traffic transmitted across an SNI, this field will contain the identification code of the transmission path set associated with the ICI from which an L3_PDU is received; otherwise, this field will contain the identification code of the transmission path set associated with the ICI to which an L3_PDU is sent. In SC 0763, BAF Table 83 appears twice. As Incoming ICI Transmission Path Set Identification, this field contains the identification code of the transmission path set associated with the ICI from which an L3_PDU is received. As Outgoing ICI Transmission Path Set Identification, BAF Table 83 contains the identification code of the transmission path set associated with the ICI to which an L3_PDU is sent. BAF Table Internetwork Carrier Identification This field identifies the type of carrier and its identification code. As Incoming/Outgoing Carrier Identification, it contains either an IC or LEC identification code. For Exchange Access SMDS, it contains the identification code of the IC involved in data transport. For LEC-to- LEC serving arrangements, it contains the identification code of the other LEC involved in data transport. As IC Identification Derived from Protocol in Structure 0762, BAF Table 157 contains an IC identification code. In internetwork SMDS Structure 0763, BAF Table 157 appears as Incoming Carrier Identification and Outgoing Carrier Identification. In both instances, this field contains either an IC or LEC identification code. 1. SC 0763 has one additional field. BAF Table 83 occurs after the second instance of BAF Table 157, resulting in a record that is 77 bytes in length rather than

145 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services 6.5 Frame Relay Frame Relay Service (FRS) is a connection-oriented data transport service that provides for the transfer of variable-length packets for LAN interconnection and terminal-host applications. Standards for the FRS description exist in American National Standards Institute (ANSI) T1.606, Frame Relaying Bearer Service Architectural Framework and Service Description. Other standards relevant to FRS include the Data Transfer Protocol and Congestion Management in ANSI T1.618, Integrated Services Digital Network (ISDN) Core Aspects of Frame Relay Protocol for User with Frame Relay Bearer Service. In contrast to SMDS connectionless service, FRS requires the initial establishment of end-to-end connections, either through provisioning (i.e., a PVC) or call setup procedures (i.e., an SVC). FRS as currently defined is based on PVCs and not SVCs. The BSS may support PVC FRS via service-specific access interfaces, i.e., the Frame Relay UNI, which is an FRS-specific access interface, and the Frame Relay NNI, which is an FRS-specific inter-bss interface. The BSS may also support FRS on an integrated, multi-service ATM/Broadband UNI and B-ICI at speeds of 155 Mbps and greater. For more information on the multi-service ATM/Broadband UNI and B-ICI, see GR CORE, Broadband Multi-Services User-Network Interface Generic Requirements, and GR-1115-CORE, BISDN Inter/Intra-Carrier Interface (B- ICI) Generic Requirements, respectively Background Frame Relay Services use the Link Access Procedures for Frame Relay (LAPF) protocol when transported over a frame-based FRS-specific interface. The LAPF protocol supports the transport of variable length frames. In a non-atm/broadband network, FRS is currently provided over DS0 and DS1 transmission facilities (higher rate interfaces may be defined in the future). The FRS requirements for both the physical layer and the frame layer for FRS UNIs are taken from TR-TSV , Generic Requirements for Frame Relay PVC Exchange Service, which is based on ANSI T1.606 and ANSI T A common method of transporting FRS frames is to use ATM cells to allow switches from different suppliers to exchange FRS information over ATM interfaces Usage Measurements The usage information to support billing for PVC FRS has both service-independent and service-specific aspects. These aspects are illustrated in Figure 6-4. For usage measurement purposes, FRS is provided by a carrier network if it performs the FRS Interworking Function (IWF) as illustrated in Figure 6-4. In this figure, the LEC is 6 25

146 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services providing FRS. This section assumes one-to-one multiplexing between ATM PVCs and FRS PVCs. (A) Frame Relay-UNI Frame Relay Service IWF LEC ATM Network UNI or B-ICI Frame Relay Service Specific Usage Information Service-independent Usage Information Frame Relay-UNI (B) LEC FRS Network Frame Relay Service IWF LEC ATM Network UNI or B-ICI Figure 6-4 PVC Frame Relay Service (FRS) Usage Information The service-independent usage information may be generated by the BSS for any ATM PVC that supports PVC FRS. This usage information may include ingress and egress counts of cells transported on the ATM PVC. The service-independent usage information will indicate that the type of service supported is PVC FRS. It will also include the Frame Relay Interface Identifier and Remote Interface Type. The ATM Forum s B-ICI Specification, Version 2.0, also defines PVC FRS specific usage information. If the PVC FRS end user is served by a Frame Relay network (which is illustrated as case B in Figure 6-4), it is assumed that the FRS network generates service-specific usage information for the FRS PVC. Usage information for PVC FRS is defined in TR-TSV and TR-TSV , Generic Requirements for Exchange Access Frame Relay PVC Service. No additional requirements apply to the BSS. If the PVC FRS end user is directly served by the FRS IWF (which is illustrated as case A in Figure 6-4), then the FRS IWF generates the service-specific usage information for the FRS PVC. The PVC FRS specific usage measurement capabilities defined in the ATM Forum s B-ICI Specification, Version 2.0, are summarized from and are intended to be consistent with TR-TSV and TR-TSV These documents provide 6 26

147 Issue 1, May 2001 Notes on Billing AMA Recording for Advanced Digital Services descriptive text that may help clarify the service-specific data generation requirements and also provide additional conditional requirements that may be needed in specific LEC applications. The PVC FRS specific usage information is formatted into BAF using the procedures defined in TR-TSV and TR-TSV The appropriate BAF layouts are found in the latest version of GR-1110-CORE. Note that the transmitting requirements and the data integrity, quality, and reliability requirements of GR CORE also apply to the PVC FRS specific usage measurement functionality when these functions are provided by the BSS AMA Recording for Frame Relay SC 0212, and the appropriate BAF modules, as described in GR-1110-CORE and in the latest issue of GR-1100-CORE, is used to represent the detailed usage information for Frame Relay PVCs. SC 0212 with Call Type 605 is used to generate a record for a Frame Relay PVC Exchange Service. SC 0212 with Call Type 606 is used to generate a record for an originating Exchange Access Frame Relay PVC Service. SC 0212 with Call Type 607 is used to generate a record for a terminating Exchange Access Frame Relay PVC Service Module Associated with Frame Relay Module 091 Frame Relay Count Module is associated with FRS and SC This module is used for Frame Relay PVC exchange and exchange access services in conjunction with Structure As described in TR-TSV and TR-TSV , it is used to represent optional usage information. The type of optional information is defined by the following fields: Condition Code (BAF Table 439), Count Type (BAF Table 444), and Measurement Unit (BAF Table 466). Table 6-9 Frame Relay Count Module Information BAF Table Number Number of Characters Byte Offset Module Code Condition Code Count Type Measurement Unit Count Validity Check

148 Notes on Billing Issue 1, May 2001 AMA Recording for Advanced Digital Services Table 6-9 Frame Relay Count Module Information BAF Table Number Number of Characters Byte Offset Count Total Bytes 14 In Module 091, BAF Table Condition Code distinguishes between different types of counts in the Count field (BAF Table 806) for Frame Relay PVC exchange and exchange access services. 007 indicates that the Count represents all Frame Relay PVC service end user data. 008 indicates that the Count represents only Frame Relay PVC service discard eligible end-user data. BAF Table 444 Message Direction, is labeled Count Type and is used to describe the Count field (BAF Table 806) in Module 091 as follows. 1 indicates that the count represents the amount of end-user data transported by a customer to a network provider s BSS across a source interface (i.e., data sent by the customer). 2 indicates that the count represents the amount of end-user data transported from the network provider s BSS to a customer across a destination interface (i.e., presumably received by the customer). 9 indicates that the message direction is unknown. BAF Table 466 Measurement Unit, identifies the measurement unit type and size by which counters for Frame Relay PVC exchange and exchange access services usage information are incremented. BAF Table 467 Count Validity Check, is used to indicate the validity of the Count (BAF Table 806). 6 28

149 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking 7 AMA Teleprocessing and Data Networking This section provides an overview of AMA Teleprocessing System (AMATPS) and AMA Data Networking System (AMADNS). This functionality has become more critical as the AMA volumes have grown as a result of the increase in the number and complexity of usage-based services. AMATPS is an AMA recording and downstream collection system architecture. AMATPS provides automatic recording and electronic transfer in lieu of magnetic tape writing and courier operations. AMADNS improves on AMATPS with enhanced processing and data communications capabilities. 7.1 AMA Teleprocessing A network element that is provided with an AMA teleprocessing feature transmits AMA data on a store, poll, and forward basis to a central point for input into the Revenue Accounting Office (RAO) message billing process. The teleprocessing feature is implemented at the network element via hardware and software, which, as a package, is called an AMA Transmitter (AMAT). An AMAT is connected to a central collector through data-transmission facilities to form an end-to-end AMATPS. The circuit switching system and Service Control Point (SCP) are the primary points of data generation, or, Generating Systems. Circuit switching systems generate AMA data for calls, and SCPs generate AMA data for queries to the resident database(s). The AMATPS is specifically designed to support the Billing AMA Format (BAF) and delivery of AMA data to a Billing System, which processes AMA data to bill customers and carriers for their use of services and network resources. Other applications of AMA data must obtain the data through special provisions that are independent of AMATPS. Figure 7-1 illustrates the logical architecture for AMATPS, which is composed of AMATs and Collectors. An AMAT stores AMA data received from a Generating System in the form of blocks. A centralized Collector periodically polls the AMAT for these blocks, which are transferred as a file. The Collector stores the file and subsequently outputs the polled files to a Billing System. AMATPS, as defined in GR- 385-CORE was specified solely to transfer AMA data from a Generating System to a Billing System without enhancing the value of the data through the use of specialized data processing. 7 1

150 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking Generating System AMAT AMATPS Generating System AMAT Collector tape-based transfer Billing System network-based transfer Generating System AMAT Figure 7-1 AMATPS Logical Architecture The three primary interfaces relevant to AMATPS are the Generating System/ AMAT, AMAT/Collector, and Collector/Billing System interfaces. AMA data generated by a Generating System are sent as AMA records to an internal or external AMAT over the Generating System/AMAT interface Transmitter Functional Description The AMAT provides an interface for receiving AMA data from a switching system. Validity checks are provided in the AMAT for the data that it receives from the switching system. The AMAT then processes the data into BAF, if it is not already in that format (depending on the form of the data provided by the Generating System). If necessary, this processing includes assembling multiple call event records pertaining to a single call into a single, stand-alone record as an intermediate step before converting into BAF. An AMAT may be designed to consist of a single Sending Unit (SUN) or of multiple SUNs, as determined by the number of collector interfaces it provides to a maximum of 10. These collector interfaces may be associated with discrete Generating Systems or subsystems, depending on the architecture of the network element or elements that are generating the AMA data. A SUN acts as a logical source of the AMA data that is sent to the Collector. 7 2

151 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking Storage of AMA data depends on the architecture. For an architecture that has one AMAT per switching entity, the data is stored on one or more mass storage devices for later transmission to a Collector. Each transmitted record is a BAF record with as much as 12 common data bytes suppressed for efficient transport. The data may be stored on the mass storage device of the AMAT with the common bytes already suppressed. For a multi-switch architecture (multiple SUNs), storage and transmission of AMA data includes the sensor type and identification. Therefore, only six bytes are suppressed. The data are stored in blocks by each SUN, with each block sequentially numbered for transmission accuracy. Tracer records are added to the AMA files which describe the properties of the AMA file and other information for audit purposes. Tracer records are obtained from the Generating System and/or AMAT and are stored within the AMA data blocks AMA File Structure The AMAT receives call records from the Generating System(s) it serves. The records are assembled by the AMAT into blocks of 512 bytes for Category A AMAT as illustrated in Figure 7-2 or 1531 bytes for Category B AMAT, as illustrated in Figure 7-3. Because the call records vary in length depending on the call type, they may not completely fill the block. Every block contains a 14-byte header, a number of call records, and filler to pad the block out to the required size. Pad characters should be all binary ones. Records are never split across blocks. (These blocks are also called AMA data blocks, or, data blocks.) CATEGORY A AMAT - AMA DATA BLOCK 14 Bytes Block Header 498 Bytes Call Records, Filler (Fixed size: 512 bytes) CATEGORY A AMAT - AMA DATA FILE 20 Bytes File Header 512 Bytes Block Bytes Block Bytes Block 100 (Maximum of 100 blocks) Figure 7-2 AMA File Structure - Category A 7 3

152 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking CATEGORY B AMAT - AMA DATA BLOCK 14 Bytes Block Header 1517 Bytes Call Records, Filler (Fixed size: 1531 bytes) CATEGORY B AMAT - AMA DATA FILE 20 Bytes File Header 1531 Bytes Block Bytes Block Bytes Block 100 (Maximum of 100 blocks) Figure 7-3 AMA File Structure - Category B Blocks are held by the AMAT on mass storage until requested by the Collector. The Collector makes its request by asking for a file of (usually) 100 blocks. This request is called a file poll. The AMAT then transmits a 20-byte file header followed by the next 100 blocks of AMA data. On completion, the Collector confirms receipt of this file and the AMAT marks the blocks as transmitted (secondary) Transport Capabilities Transmission of AMA data by a SUN is prompted by a poll from the Collector. The poll should prompt for all data collected by the SUN since the last SUN polling session. This data is called primary data prior to successful transmission. After groups of AMA data have been successfully transmitted by the SUN and acknowledged by the Collector, the groups are marked as secondary. Secondary data are never erased by the AMAT, but remain available until it is necessary to overwrite them with new primary data. This is referred to as First In First Out (FIFO) with a data storage capacity of five days of recorded traffic. Thus, a copy of secondary data is retained and available for up to five days for retransmission if a loss of data occurs at the Collector or mainframe AMA processing locations. The AMAT never erases primary AMA data. Unlike secondary data, primary data may never be overwritten by the AMAT. Manual procedures enable primary AMA data to be written to magnetic tape during extreme emergency situations. The AMAT/Collector interface is used to transfer files containing AMA records between an AMAT and a Collector. This interface is characterized by the use of the following: BX.25 with the restriction that only one permanent virtual circuit may be used per device port 7 4

153 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking A Telcordia-standard file transfer protocol 4.8- or 9.6-kbps dialup lines, or 56-kbps dedicated lines A dialup/dial-back mechanism to ensure a high degree of security. Overall, the following generalizations can be made about the AMATPS interface: The Physical Interface, Link-layer Logical Interface, and Packet-layer Logical Interface are as defined in MDP , Operations Systems Network Communications Protocol Specifications BX.25, Telcordia, Issue 3, June 1982, Part II, Chapters 1, 2 and 4, with options selected for AMATPS. A small portion of the Session Layer Protocol as defined in Chapter 5 of BX.25, Issue 3 is used. Because there is no transport layer in BX.25, the session layer has added features to assure data integrity above and beyond that provided by the lower levels. Some events from which the session layer usually protects the application layer (for example, session resynchronization) are not provided and the application layer must recover from these errors. The application layer of the AMATPS protocol is designed to provide for the transmission of files of data. Data exchange at this level is always done with this concept of a file. As noted above, the session layer does not protect the application layer from many lower protocol problems; thus, these layers have become entwined and need to share information during error recovery as well as normal transmission. Refer to GR-385-CORE for additional information Collector Functional Description The main features of the Collector are characterized by three discrete functions. The first function is collecting AMA data. The second is auditing and administering AMA data to provide the required level of data accuracy and integrity. The third is outputting AMA data to the RAO s AMA entry process. The AMATPS Collector, here referred to simply as the Collector, is the centrally located component of an AMATPS. It provides a common interface to LEC accounting office AMA entry processing for an AMATPS network. Collection occurs through communication over data facilities (described in the previous section) between the Collector and a SUN subsystem of an AMAT. The Collector provides multiple ports for collecting data from the SUNs associated with each AMAT. Each SUN is assigned to a specific collector port. A polling schedule is established administratively for each SUN. The Collector receives AMA data with specified BAF data fields suppressed for transmission efficiency. For example, each billing record from the same SUN does not need to transmit the SUN identity information. The received data is stored by the Collector for subsequent 7 5

154 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking forwarding to the LEC RAO AMA entry process, at which time the Collector inserts the suppressed data fields to provide BAF records Data Handling SUNs are pre-assigned to collector systems. Typically there may be two Collectors assigned to each SUN, primary and backup. The AMATs employ a store and forward architecture, and the Collector polls the assigned SUNs for AMA data on a non-realtime basis. Polling schedules may be constructed to maximize daily collector throughput. The transmitter sends AMA data with specified BAF data fields suppressed (up to 12 common data bytes) for increased transmission efficiency. Blocks of data transmitted by a SUN are sequentially numbered at the AMAT and checkpoints are performed as they are teleprocessed to the Collector. This sequential numbering scheme provides the ability to audit the data from the point of origination to the point of exit, thus assuring end-to-end data integrity. Polling operations are conducted on the basis of these data blocks and their sequence numbers. A polling session ends when either of the following events occurs: 1. A SUN has no more AMA data to send. 2. A Collector database value that establishes maximum session duration or AMA data volume has been reached. In the event of AMA data loss or mutilation after their initial receipt by the Collector, a re-poll capability is provided. The re-poll for data from a SUN is accomplished through a manual request entered at the Collector for retransmission. Re-polling operations are conducted on the basis of data block sequence numbers, not on a record basis Administration Each Collector must be provisioned with SUN assignments, passwords, etc. Throughout the data collection and forwarding process, the Collector provides administrative and maintenance reports for monitoring and controlling the AMATPS network. Personnel actions are normally limited to the following: tape changing, monitoring overall AMATPS performance including re-polling, administering the Collector database and software, and reporting trouble conditions to the responsible maintenance organizations. The normal polling process involves scheduled events administered by a database within the Collector. The database provides for polling each SUN from 0 to 96 times per day and is arranged to provide a separate polling schedule for weekdays, weekend days, and holidays. 7 6

155 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking 7.2 AMA Data Networking System (AMADNS) AMADNS, like AMATPS, allows transmission of AMA data to a central point for input to the RAO. AMA data networking distinguishes itself from AMATPS by taking advantage of emerging data services and file transfer protocols for the information transport. AMADNS supports the transfer, processing, and management mechanisms required to enable data applications with AMA data. (Detailed information is available in GR-1343-CORE.) Background AMATPS, developed in the late 1970s, has been providing an efficient means of meeting service providers (i.e., companies offering telecommunications services) AMA data transfer needs for the past 20 years. However, changes in the AMA environment have created additional challenges for AMA data transfer, processing, and management that AMATPS cannot efficiently handle. It is this fact that motivated the design of AMADNS. AMADNS is able to manage higher AMA data volumes and supports access to AMA data by new applications, for example, fraud detection and market data systems. Some of these applications are expected to 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 (due to the use of data aggregation, for example), thereby requiring the capability to treat different AMA data in a different manner. AMADNS is designed to support the special needs of multiple applications while retaining the high degree of quality, availability, and security required for AMA data System Overview AMADNS improves on AMATPS to meet current and future service provider needs in the following primary ways: Higher data transmission rates to support large volumes of data Significant 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. The Telecommunications Act of 1996, in particular the provisions regarding expanded carrier interconnection, service wholesaling, and local number portability, has already and is likely to continue to result in substantial volume growth. Due to the growing AMA data volumes, the currently defined transmission alternatives for AMATPS will soon be insufficient. Support for multiple applications for AMA data Invoice processing, the processing of AMA data necessary for billing customers and carriers for their use of network resources, which is performed at a Billing System, is the only application for AMA data supported by current AMATPS generic requirements. 7 7

156 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking Although invoice processing is the most important application for AMA data, additional applications which require or could benefit from access to AMA data have been identified. (For the remainder of this section, the term Application System is used to refer to an end system that processes AMA data.) The new Application Systems include Fraud Detection Systems, Marketing Systems, Customer Network Management Systems for various services, Message Detail Recording (MDR) Systems, and Engineering and Planning Systems for various networks. Hence, multiple Application Systems will have to be provided access to AMA data, a capability which is not supported by AMATPS. Improved data access Many new Application Systems require data transfer capabilities not supported by AMATPS. These capabilities include near-real-time data transfer and sender-initiated data transfer (e.g., to expedite fraud detection), and on-demand data access via remote data requests (e.g., to facilitate marketing analysis). Near-real-time access to AMA data is access that is soon (i.e., on the order of 2 to 5 minutes) after the data is generated. AMADNS has not been designed to address real-time services (i.e., services requiring the availability of AMA data within a few seconds of when the data is generated). Ondemand access to AMA data is access characterized by a request for specific AMA data. Specialized data processing capabilities New Application Systems and new network services require specialized data processing capabilities, which are not supported by AMATPS. Specialized data processing is processing that is beyond the basic operation of AMADNS. Specialized data processing needs include format conversion to handle the many formats expected to be collectively produced by Generating Systems, and correlation to support situations where multiple Generating Systems generate AMA data for the same service instance. Additional information is provided in Section AMADNS is specified to meet these important challenges by incorporating many of the technological advances that have occurred since AMATPS was defined. The emergence of standard protocols 1 will allow greater inter-operability between different components in AMADNS. 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-real-time data access needs of Application Systems to be fulfilled. In addition, advanced mechanisms for remote data access will allow the on-demand access needs of Application Systems to be met. There are numerous other benefits to be derived from the deployment of AMADNS. The use of higher-speed interfaces for data transfer will result in improved cost efficiency. In addition, reductions in cost can be achieved by employing networkbased data transfer to eliminate manual operations (e.g., magnetic tape-based data transfer). AMADNS should also help to increase and protect an operating company s revenue base and reduce costs by providing new Application Systems 1. Standard protocols are considered to be those that are either de facto, national, or international standards. 7 8

157 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking with access to AMA data. AMADNS offers greater flexibility in data transfer and processing to enable rapid support of new or changed Application Systems and Generating Systems. Furthermore, standard system management procedures employed by AMADNS will provide better control of the system AMADNS Data Architecture The logical architecture for AMADNS is illustrated in Figure 7-4. As shown, AMADNS is composed of Data Servers, one (or multiple) Data Processing and Management System (DPMS), one (or multiple) System Managers, and the various interfaces to these components. 2 The Generating Systems and Application Systems connected via AMADNS represent the sources and destinations, respectively, of AMA data. The flow of AMA data from Generating Systems to Application Systems is described below. Generating System Data Server AMADNS Generating System Data Server Data Processing and Management System Application System Application System System Manager Generating System Data Server Application System AMA Data System Management Data Figure 7-4 AMADNS Logical Architecture Generating Systems generate the AMA data. Generating Systems include systems such as Switching Systems, SCPs, and a Link Monitoring System (LMS). 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 2. All of the interfaces shown in Figure 7-4 (i.e., interfaces from an AMADNS component to another AMADNS component or a component which connects to AMADNS) are termed system interfaces. 7 9

158 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking particular format, usually BAF 3. Once formatted (i.e., organized into a defined unit), these data are called AMA records, which are organized collections of AMA data elements. 4 A Generating System transfers AMA records to a Data Server soon after the records are generated. A Data Server can be implemented either internal or external 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. AMA records are transferred between a Generating System and an external Data Server in the form of an AMA file using standard protocols for file transfer and networking. The allowable network-based protocols correspond to those used for a Wide Area Network (WAN) and a Local Area Network (LAN), and are used appropriately to connect Generating Systems and Data Servers. After receiving AMA records from a Generating System, a Data Server processes the records, and stores them in a new AMA file. The Data Server then transfers the AMA file to a DPMS. The System Manager ensures the efficient operation of a system composed of heterogeneous machines and facilitates the reconfiguration and maintenance of such a system Dual Data Server-Collector An approach to interconnecting AMADNS and AMATPS is illustrated in Figure 7-5. With this approach, a Data Server would also support the role of an AMATPS Collector. The Data Server would have to be an external Data Server to support both roles. A Data Server-Collector would receive AMA records from Generating Systems over the Generating System/Data Server Interface (GDI) and collect AMATPS AMA files from AMATs using the AMAT/Collector interface. A Data Server is neither required to support nor prevent from supporting the AMAT/Collector interface. The Data Server-Collector would send all received and collected AMA records in Standard AMA files to a DPMS via the Data Server/DPMS Interface (DDI), and would be managed by a System Manager via the System Manager/Managed Component Interface (SMMCI). 3. AMADNS is capable of supporting formats other than BAF. 4. A particular Generating System could pass to the associated Data Server only the raw data needed to produce AMA records. In this case, the Data Server would have to support the receipt of this raw data and the formatting of the data. While this situation is possible, most Generating Systems are likely to provide formatted AMA records to Data Servers, and Data Servers are said to receive formatted AMA records throughout the rest of this document. An alternative Generating System/Data Server Interface over which raw data could be sent may be defined in the future. 7 10

159 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking AMAT AMAT Generating System AMAT/ Collector Interface GDI Collector Data Server DDI SMMCI Data Processing and Management System System Manager Generating System Figure 7-5 Dual Data Server-Collector Architecture Data Communications Interface This section focuses on the transfer of AMA data, although the transfer of other types of data is also supported. Files are transferred using File Transfer Protocol (FTP) or Trivial File Transfer Protocol (TFTP) over the Transmission Control Protocol/Internet Protocol (TCP/IP) networking. The Data Server also includes support of Telnet, for operators located remotely to login. To support near-real-time data availability, a Data Server makes each received AMA record available for transfer within 1 minute of the receipt of the record. AMADNS data communications can be provided over ATM, SMDS, Frame Relay, ISDN, or X.25 WANs. FDDI, IEEE Standard 802.3, and IEEE Standard are allowable protocols for providing the MAC Sub-layer of the Data Link Layer and the Physical Layer, and Ethernet Version 2.0 is an allowable protocol for providing the Data Link and Physical Layers. 7 11

160 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking Figure 7-6 below illustrates five possible ways in which end systems for AMADNS could be connected. All are potential configurations for the GDI, DDI, DPMS/ Application System Interface (DAI), and SMMCI. 5 LAN WAN End System A LAN R WAN R LAN End System B LAN R WAN R - router Figure 7-6 Potential System Interface Configurations System Manager Standard system management ensures the efficient operation of a system composed of heterogeneous machines and facilitates the reconfiguration 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 AMADNS by a System Manager. A System Manager manages Managed Components, namely Data Servers and DPMSs. A 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 an image of AMADNS. 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. A System Manager s control over components is supported in the areas of configuration, fault, performance, security, and accounting management. A System Manager administers data transfer, data processing, and security information used by Data Servers and DPMSs to perform their functions. In addition, a System 5. The LAN-WAN-LAN configuration will likely be most prevalent for end systems that are remote from each other. 7 12

161 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking Manager supports clock synchronization, file transfer and storage testing, and auditing. Most System Management functions within AMADNS are performed by Management Applications running on a System Manager. A Data Server, which is a Managed Component from a system management perspective, communicates with a System Manager via the Simple Network Management Protocol (SNMP), FTP, and Telnet. SNMP is used by a Data Server to send traps to a System Manager and by the System Manager to set and retrieve a Data Server s management data. FTP is used to exchange program, test and error files. Telnet is used for remote login to Data Servers. System Manager and Management Applications within AMADNS use SNMPv1 via an SNMP Manager to retrieve data defined in Managed Components Management Information Base (MIB) and to request changes to values of certain service provider-setable managed objects. The SNMP Agent running at the Managed Component is responsible for performing the functions requested by the Management Applications. In addition, the SNMP Agent can asynchronously send traps to notify System Managers that certain trouble events have occurred, such as hardware and link failures. The Management Applications in the System Managers and the SNMP Agent at the Managed Component together aid in monitoring and governing the operation of Data Servers File Structures Standard AMA Files AMA data, in the form of Standard AMA files, are transferred from Data Servers to a DPMS, and from DPMSs to all Application Systems except the Billing System. A Standard AMA file consists of one or more AMA records and an AMADNS file header. AMA records are typically represented in BAF. When the AMA records composing a Standard AMA file are formatted in BAF, specific fields of these records may be suppressed for the file s transfer. Unlike AMATPS files, there are blocks within the AMADNS Standard AMA file structure. All communications are sent and received with complete files which contain a file sequence number to assure a complete, ordered sequence of AMA records. Standard AMA Files, not blocks, may be retransmitted when requested Error Files Data Servers and DPMSs are able to detect erroneous AMA records. The following are examples of erroneous AMA records: For a Data Server that formats non-baf records into BAF records, all received records that the Data Server cannot format. 7 13

162 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking For a Data Server and DPMS, all received records that a Data Server or DPMS is unable to interpret. For a Data Server and DPMS that performs AMA data validation processing, all received records with invalid data values. An error record consists of a header and an erroneous AMA record, or parts thereof, that has been captured by a Data Server or DPMS Test Files Test files are used as a maintenance tool to test the transfer and storage capabilities of system components. A system component may send a test file to a destination and then subsequently retrieve the test file and compare it with the copy that was sent. This test procedure may be scheduled on a regular basis or invoked manually. A test file contains pre-defined data and an AMADNS file header. A service provider may specify a test file to be used; otherwise, a default test file is used AMA Record Flows The possible record flows within AMADNS and between AMADNS and other systems are illustrated in Figure 7-7. Arrows leaving a node are outgoing records departing from a component over an interface or eliminated at a component by consolidation. Consolidation is the operation of combining AMA data from multiple AMA records into a single AMA record, thereby reducing the total number of AMA records present. This operation is performed, for example, when an Special Processing Module (SPM) performs aggregation on a set of AMA records. This operation may also occur when correlation is performed on a set of AMA records. Refer to Section for description of generic SPM functions. 7 14

163 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking Application Systems Records Introduced By Duplication or Expansion Records Removed By Consolidation Fraud Detection System Generating Systems Data Server DPMS Marketing System Billing System Other Systems Records Introduced By Duplication or Expansion Records Removed By Consolidation Flow of Records from Source to Destination (Logical) Introduction or Removal of AMA Records Figure 7-7 AMADNS AMA Record Flows AMA Record Flows The possible record flows within AMADNS and between AMADNS and other systems are illustrated in Figure 7-7. Arrows leaving a node are outgoing records departing from a component over an interface or eliminated at a component by consolidation. Consolidation is the operation of combining AMA data from multiple AMA records into a single AMA record, thereby reducing the total number of AMA records present. This operation is performed, for example, when an Station Message Detail Recording (SMDR) performs aggregation on a set of AMA records. This operation may also occur when correlation is performed on a set of AMA records. Refer to Section for description of generic SPM functions Generating System/Data Server Interface (GDI) This section provides the generic requirements for the interface between a Generating System and its associated Data Server. The interface is used to transfer 7 15

164 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking AMA records between the Data Server and a Generating System when they are not residing in the same platform. The GDI is used to transfer AMA records from a Generating System to an external Data Server, which may support multiple Generating Systems. 6 The key aspects of this interface are as follows: Records are sent over the GDI in the form of Streamlined AMA files, ensuring reliable transport. A group of AMA records is placed in a Streamlined AMA file for the purpose of transport over the GDI, permitting a Data Server to identify which files (and thus which groups of AMA records) have been received correctly and which must be retransmitted. Because it uses the Internet TFTP for file transfer, the GDI does not have the complexity of the DDI or the DAI. In contrast to FTP, TFTP does not require a pair of connections to be established before file transfer can begin. TFTP also utilizes a significantly smaller set of possible commands and replies to structure communications. Nevertheless, the GDI achieves a level of reliability and security (via IP security) equivalent to that of both the DDI and DAI. Data transport across the GDI is efficient. The GDI transports AMA records from Generating Systems to Data Servers with minimal overhead and minimal delay, without sacrificing reliability. Streamlined AMA files do not contain the AMADNS file header used for other AMADNS file types, reducing the amount of overhead and improving the efficiency of the interface. The GDI ensures that records are not required to be stored within a Generating System for a long period of time. AMA records are placed into Streamlined AMA files and transmitted across the GDI soon after they are available for transfer. Frequent transfer of small files minimizes the need for large amounts of storage within a Generating System Specialized Processing Modules (SPMs) AMADNS provides a software execution environment in which specialized processing can occur. SPMs are the set of processing modules installed on a particular AMADNS component (e.g., DPMS or Data Server) that enables AMA records to be processed in a desired fashion. The definitions for SPMs are provided in GR-2966-CORE, Module-Specific Generic Requirements for Specialized Processing Modules (SPMs) for the Automatic Message Accounting Data Networking System (AMADNS), for particular AMADNS SPMs that have been identified as critical to meeting carriers AMA data collection needs. These 6. The GDI is the target interface for external Data Servers. However, in cases where a Data Server is needed (e.g., to support growing data volumes or specialized data processing) but the associated Generating System does not yet support the GDI, a Data Server must employ tape emulation via a nonstandard interface (as is done by external AMATs in AMATPS) or use the AMAT/Collector interface (as is done by Collectors in AMATPS) in order to receive AMA data from such a Generating System. Section 2.7 of GR-1343-CORE describes inter-operation between AMADNS and AMATPS. 7 16

165 Issue 1, May 2001 Notes on Billing AMA Teleprocessing and Data Networking capabilities are format conversion, surveillance, aggregation, correlation, validation, formatting, error correction, expansion, and reduction Format Conversion Format Conversion is the transformation of AMA data from one format to another format. Though the dominant format for AMA data among domestic LECs is currently BAF, carriers might also receive AMA records in other formats. Non-BAF formats that LECs could encounter include: Call Detail Recording (CDR) ASN.1 - Abstract Syntax Notation 1 Data Message Handler (DMH) Exchange Message Interface (EMI) Internet Protocol Data Record (IPDR) Surveillance Surveillance is the monitoring of AMA data to detect deviations from established norms. Carriers often deploy surveillance capabilities at the front end of their Billing Systems to track the volume of particular types of AMA records received, in order to detect anomalies that could indicate switch translation errors, AMA recording errors, network routing errors, or general software errors. Surveillance is also used to identify and flag AMA records that contain data that represent potentially fraudulent activity Aggregation Aggregation is the combining and summing of AMA data from multiple input records into a single output record. Aggregation may be applied when full detail is not required by downstream application systems Correlation Correlation is the association of AMA records created, possibly by multiple Generating Systems, for one or more (usually related) usage events. Correlation is performed in order to group the information recorded in multiple AMA records into a single, complete account of service rendered. 7 17

166 Notes on Billing Issue 1, May 2001 AMA Teleprocessing and Data Networking Validation Validation is the inspection of the contents of AMA records for ensuring that the records meet specific integrity checks. Validation is also responsible for reporting errors when recording problems are detected. The kind of processing performed includes checking each data element (e.g., each field in an AMA record) to verify that a valid value has been recorded. It also includes checking an entire AMA record (e.g., cross checking between fields in a record) to ensure that all necessary information is included Formatting Formatting is the conversion of one or more sets of raw usage data elements (unformatted AMA records) representing a given usage event, to a single, formatted AMA record, in order to convey a complete account of the service rendered. It is possible that these associated unformatted AMA records have come from multiple Generating Systems Error Correction Error Correction is the conversion of an invalid AMA record to a valid AMA record by applying automated procedures. This module would be used when an error has been detected within an AMA record, and for which the method of correcting the error is known and can be automated. When used subsequent to a Validation SPM, AMA record errors could be corrected while records remain within the main AMA data stream, adding efficiency to the AMA data collection process Expansion Expansion is the extension of a single AMA record beyond the original content of that record. This module would be used when additional useful information is needed by the Application System Reduction Reduction is the removal or masking of specific data elements in an existing AMA record, or removal of an entire AMA record. This module would be used when unnecessary or undesirable information is to be removed from the AMA record. 7 18

167 Issue 1, May 2001 Notes on Billing Developments and Future Trends 8 Developments and Future Trends Section 8 provides an update on current developments related to call detail recording, including alternative recording capabilities and alternative recording formats. This section also provides an examination of recording requirements, capabilities, and challenges for the Next Generation Network (NGN) and concludes with some comments on the future of usage-based services. 8.1 Alternative Recording Capabilities As local networks evolve and interconnect, it will become increasingly important to determine the amount of time and resources spent while interconnected and interacting with other networks and service providers. Both facilities-based network providers and non-facilities-based service providers will be asking not only for basic connectivity, but also for certain functions to be performed and features to be provided. Consequently, all network providers will need to perform measurements that can capture this expanding spectrum of information. Today, in many situations, there are multiple service providers involved in the completion of local or long distance telephone calls or other types of telecommunications services. The Automatic Message Accounting (AMA) functionality of switching systems has traditionally taken on the task of capturing enough information to allow a service provider to measure the billable aspects of a call. In recent years, the billing function has expanded to include rendering bills to another network provider. To achieve this type of flexible, interoperable network requires that the usage measurements functionality be aware of (i.e., measure) the types and volumes of traffic entering into and exiting from them. Fortunately, with Common Channel Signaling (CCS)/Signaling System 7 (SS7), service providers can tap into a rich source of data to do everything from surveillance and fraud management to customer-specific reports that expedite marketing for new lines and services. 8.2 Recording Capabilities of a Link Monitoring System (LMS) A Link Monitoring System (LMS) can collect AMA data elements carried in each direction on all SS7 signaling links deployed in a service provider s Common Channel Signaling Network (CCSN). A CCSN LMS operates by non-intrusively monitoring the bit streams carried in each direction on SS7 signaling links deployed. Appropriate filters are used to parse the signaling message stream and extract relevant information from each link. The filtered information from each link can be combined and correlated with information from other links to provide a broader network view, as well as network usage measurements for billing new and existing telecommunications services. LMSs can now generate Call Detail Recording (CDR) related to individual circuit switched calls in Billing AMA Format (BAF). The CDRs are populated from data 8 1

168 Notes on Billing Issue 1, May 2001 Developments and Future Trends contained in the signaling messages that traverse the CCS network, specifically the information contained in the Integrated Services Digital Network User Part (ISUP) of the SS7 protocol. The LMS captures call setup messages transported over SS7 signaling link sets between a Signal Transfer Point (STP) and an end office (and/or tandem) switching system. The CCS usage measurement functionality can be implemented solely within an STP or as a stand-alone adjunct. Figure 8-1 shows an example of an LMS implementation (stand-alone adjunct) where data captured at the LMS can be used to bill interconnecting circuit switched network providers, and an Interexchange Carrier (IC) for access to the CCS network. Database Services Query and Response TCAP LMS Network Provider 1 STP B/D-Links ISUP / TCAP POI IC STP A-Links Network Provider 2 End Office Network Provider 1 Tandem Access Network Provider 1 End Office IC Interexchange Carrier (IC) CCS SS7 Signaling Link Sets Monitoring Points ISUP and/ or TCAP TCAP Monitoring Points Figure 8-1 Stand-Alone Adjunct LMS Implementation The decisions on when and how things are measured will have to move from the circuit switched vendor development laboratory to real-time, or near-real-time in the network. This flexible approach to usage measurements may be more easily handled by an LMS than it can be by a traditional circuit switch. 8 2

169 Issue 1, May 2001 Notes on Billing Developments and Future Trends Generating Aggregate AMA Records GR-1087-CORE, Generic Requirements for Common Channel Signaling (CCS) Network Usage Measurement Functionality, addresses the creation of aggregate records that measure the number of signaling messages that have traversed on the SS7 network. The network usage measurement capabilities for CCS can be treated as part of a process that begins with generating usage measurements in the CCS network and ends with downstream processing of the BAF records in a Revenue Accounting Office (RAO), as illustrated in Figure 8-2. CCS Network Usage Measurement Generation Usage Measurement Aggregation BAF Record Formatting RAO BAF Record Transmitting CCS Usage Measurement Functionality Described in GR-1087-CORE RAO Processing Figure 8-2 CCS Usage Measurement Process Model The generation functionality measures a set of data element values for CCS messages that have been determined to require measurement. After usage measurements are generated, the aggregation functionality places them into the proper aggregation groupings so that counts can be made of usage measurements that have the same measurement characteristics. A count for an aggregation grouping represents the number of CCS messages with the same measurement characteristics that were processed during a period of time (e.g., an hour). Also accumulated is the total number of octets (i.e., sum of message sizes) from the CCS messages that are represented in each aggregation grouping. Different criteria are used for generating usage measurements for ISUP messages than are used for generating usage measurements for Signaling Connection Control Part (SCCP) messages. Both ISUP and SCCP include unique message types, and measurements will not be generated for all message types. ISUP message types are indicated in the Message Type parameter, which is the first parameter of ISUP. The SCCP Message Type field specifies the message type for the SCCP. The Message Category provides a high-level description of the type of CCS message being measured. Presently, Transaction Capabilities Application Part (TCAP) is the only user of SCCP (Unitdata) messages. 8 3

170 Notes on Billing Issue 1, May 2001 Developments and Future Trends Table 8-1 provides a summary of the possible data element values for SCCP (Unitdata) messages and ISUP messages. Table 8-1 Applicable Data Items for SCCP and ISUP Messages Data Element SCCP (Unitdata) ISUP Signaling Link Set Identifier Link Set Name 1 Link Set Name 1 Trunk Group Number Not generated for SCCP A provisioned NNNN - four digit number for the generation functionality AMA recording 1 Originating Network Address Full or partial point code Terminating Network Address CCS Service Information Full or partial point code, or the NPA (or NPA-NXX, if provided) of the calling party 2 (ANI used if available) Full or partial point code, or Full or partial point code, or the first three or six digits of the NPA (or NPA-NXX, if provided) Global Title (GT) of the called party 2 Calling, Called Subsystem Not generated for ISUP Number (SSN) or unspecified SSN CCS Parameter Information For each parameter set to For each optional parameter set on for the Message Type and to on for the Message Type and aggregation period: populated or not populated aggregation period: populated or not populated Message Category SCCP Unitdata ISUP Message Type TCAP query, response, unidirectional, conversation, or Abort Any of the ISUP Message Types selected for collection Message Direction Sent or received Sent or received Octet Count Size of message in octets Size of message in octets Time Time message sent or Time message sent or received received Date Date message sent or received Date message sent or received 1 The methods for deriving the Link Set Name and the Trunk Group Number (NNNN - four digit number) are left to the LMS equipment manufacturer to determine. For example, the provisioned NNNN may be derived from a combination of the Trunk Circuit Identification Code, the Originating Point Code, and the Terminating Point Code. 2 International numbers are an exception. The format of an aggregate BAF record depends on the primary and secondary data elements of the aggregation grouping(s). For CCS, the primary data elements are the Originating Network Address, Terminating Network Address, Signaling Link Set Identifier, provisional Trunk Group Number for ISUP messages, and Calling/Called 8 4

171 Issue 1, May 2001 Notes on Billing Developments and Future Trends Party Address Subsystem Numbers (SSNs) when both SSNs are set to record for SCCP messages. These data elements should dictate which BAF record will contain certain aggregation grouping information, since each unique set of primary data element values requires a stand-alone CCS BAF record (SC 0417 with CTC 265). The secondary data elements (i.e., CCS Service Information, CCS Parameter Information, Message Category, Message Type, and Message Direction) dictate how many CCS aggregate modules are needed. For BAF purposes, the Message Category and Message Type data elements are combined into a single BAF Table 443. More specifically, the number of unique combinations of secondary data element values will be equal to the number of aggregate modules that will need to be generated. There are two types of CCS aggregate modules. The CCS Aggregate Usage Module (Module 082) represents secondary data element values from one aggregation grouping when the grouping does not contain a set of CCS Parameter Information. The CCS Parameter Aggregate Usage Module (Module 182) also contains secondary data element values and is used when a set of CCS Parameter Information is included in an aggregation grouping. Two instances of Module 082 should be generated when both SSNs (primary data element) are set to record for SCCP messages. Module 104 is used to record the provisioned Trunk Group Number as a primary data element for aggregate ISUP messages Generating Call Detail Records (CDRs) While the GR-1087-CORE requirements cover most of the aggregation criteria (usersettable parameters) that define the aggregate records generated on a particular link set, these requirements do not address the creation of CDRs that would be equivalent to the AMA records generated at the End Office (EO) or Access Tandem (AT) switching systems. GR-3012-CORE, Generic Requirements for Network Interconnection Signaling System No. 7 (SS7) Link Monitoring System (LMS) Automatic Message Accounting (AMA), provides the LMS-based AMA generic requirements for generating CDRs that are more in line with the current generic requirements used to generate switch-based AMA. The data captured at the LMS can be used to bill interconnecting circuit switched network providers, such as peer networks 1, Interexchange Carriers (ICs), or other CCS network providers for access to or usage of the monitored CCS network. The scope of GR-3012-CORE requirements for LMS is limited to interoffice network interconnection arrangements where circuit switched call information is signaled via the SS7 protocol across signaling links monitored by an LMS. As illustrated in Figure 8-3, these interconnection and database interactions could occur at the EO, AT, or Serving Wire Center (SWC). 1. The term peer network encompasses Incumbent Local Exchange Carriers (ILECs), Independent Company LECs (ICOs), Competitive Local Exchange Carriers (CLECs), Wireless Services Providers (WSPs), Competitive Access Providers (CAPs), and Tandem Switching Providers (TSPs) within a Local Access and Transport Area (LATA). 8 5

172 Notes on Billing Issue 1, May 2001 Developments and Future Trends Query and Response (Q/R) Transactions Database Services LEC 2 STP LMS* IC STP Type 2A LEC 2 FGD CNA FGD Common TG S W IC C FGD Direct TG WSP 1 Type 2B LEC 2 CNA CNA CNA LEC 3 CCS SS7 Signaling Link Sets Voice Trunk Network Figure 8-3 LMS Recording Overview The requirements in GR-3012-CORE support the BAF data generation for the following interconnection arrangements Connecting Network Access (CNA) AMA Figure 8-4 shows an example of the Connecting Network Access (CNA) interconnection architectures for LMS usage measurements. The CNA trunk groups can be provisioned at either an EO or a tandem switch. In Figure 8-4 the trunk groups labeled X, Y, and Z are considered CNA trunks by both of the switches at either end of the trunk group. For example, trunk group X can be provisioned as a CNA trunk group for all calls incoming to the LEC 2 EO from the LEC 1 tandem switch. For trunk group X, it is also true that the LEC 1 tandem switch can provision the same trunk group X as a CNA trunk group for all calls incoming from or outgoing to the LEC 2 EO. The generation of AMA records by the LMS for calls traversing CNA trunk groups will be accomplished, in large part, by using the information contained in the ISUP call setup messages. These call setup messages are transported over the CCS signaling link sets between STPs and the tandem and EO switching systems. In the example below, the signaling interconnection among the three networks is 8 6

173 Issue 1, May 2001 Notes on Billing Developments and Future Trends accomplished using A-links between the switching systems and a single STP pair provided by LEC 1. LEC 1 STP LMS A-Links LEC 1 CNA CNA X CNA LEC 1 Toll Tandem Y CNA LEC 3 End Office LEC 2 End Office CNA Z CNA Exchange CCS Signaling (GR-317-CORE) Voice Trunk Network Figure 8-4 LMS Recording for CNA Interconnection CNA recordings for switch-based AMA are generated for calls that cross local network boundaries, but for which existing access charge recordings (e.g., BAF CTC 119 records for terminating exchange access calls) do not apply. CNA records are generated only for calls over interoffice trunk groups specifically marked for such recording. The switch-based AMA for CNA calls generates a CTC 720 / SC Switch-based AMA requirements limit CNA recording to incoming calls at the EO or AT. The LMS has the capability to record AMA for both incoming and outgoing calls on the CNA trunk group, provided this capability is provisioned at the LMS. Incoming LMS CNA AMA is equivalent to the switch-based CTC 720 / SC 0625 and will use a new CTC 590 / SC LMS outgoing CNA AMA has no switch-based equivalent and will use a new CTC 589 / SC The AMA usage measurements generated at the LMS for CNA trunk groups will append Local Number Portability (LNP) Modules only under certain conditions. In order for a terminating LNP module to be generated, the Location Routing Number (LRN) must be present in the Called Party Number parameter of the Initial Address Message (IAM) and the Generic Address Parameter of the IAM must contain the called (dialed) number. In order to generate an originating LNP module, either an NPA-NXX is provisioned on the CNA trunk group at the LMS, or the Jurisdiction Information Parameter (JIP) is received in signaling. GR

174 Notes on Billing Issue 1, May 2001 Developments and Future Trends CORE requirements do not call for the LMS to launch an LNP query to obtain LRN information for originating (calling) or terminating (called) numbers. For two-way CNA trunk groups recording in both directions, the network identification code is the same for originating (outgoing) CNA calls as it is for incoming CNA calls. Since there is only one trunk group, the same value is used. For outgoing CNA calls, it will be necessary for the LMS to record the originating telephone number information from the various parameters in the IAM and append this information in one or more AMA modules using BAF Module 164 format. All of the switch-based AMA BAF call type codes, along with the LMS equivalent call type codes, are listed in Table 8-2. All LMS AMA records use SC Table 8-2 LMS Call Type Codes Type of Call Switch AMA CTC Structure Code LMS AMA CTC Outgoing CNA Incoming CNA Originating (Outgoing) FGD Terminating (Incoming) FGD Type 2B Originating (Direct TG) Type 2B Terminating (Direct TG) Type 2A Originating (Tandem TG) Type 2A Terminating (Tandem TG) Tandem Transit (Single Record) Exchange Access Feature Group D (FGD) Interconnection Figure 8-5 shows an example of the Exchange Access Interconnection FGD architecture for the SS7 LMS usage measurements. FGD is the trunking interface used by ICs and INCs to access customers on LEC networks. Detailed billing records are made on a per-call basis whenever an end user customer attempts to place a call to an IC network and whenever an end user customer receives a call from an IC network. ICs have the option of establishing connections either directly to the EOs that have this feature or connecting via AT switches. 8 8

175 Issue 1, May 2001 Notes on Billing Developments and Future Trends LMS MP-1 LEC 1 STP B/D-Links POI IC STP A-Links B POI IC MF Signaling X LEC 1 Access Tandem Y A POP LEC 1 Equal Access End Office ILEC 1 End Office ILEC 2 End Office LEC 1 End Office LATA 1 Exchange CCS Signaling (GR-394-CORE) Voice Trunk Network Figure 8-5 LMS Recording for Exchange Access Interconnection There are differences in the signaling information available for FGD AMA depending on which link sets the LMS monitors and whether or not there is signaling message correlation performed. For many LECs, the FGD LMS AMA will be generated from the SS7 messages traversing the signaling link sets between the LEC STP and the IC STP captured at monitoring point 1 (MP-1 in Figure 8-5). The SS7 messages captured here are those associated with the dedicated trunk group between the LEC tandem and the IC, specifically, trunk group B in Figure 8-5. Some LECs may also monitor the link sets that control direct trunk groups between the LEC EOs and the IC, e.g., trunk group A in Figure 8-5. Some companies may record FGD AMA by monitoring the signaling link sets associated with common trunk groups between the EO and the AT (Trunk Group X) and the direct trunk groups between the LEC EO and the IC (Trunk Group A). The switch-based AMA for FGD calls generates a CTC 110 / SC 0625 for originating (outgoing) FGD calls and CTC 119 / SC 0625 for terminating (incoming) FGD calls. LMS FGD AMA will use new BAF call type codes, specifically 591 for originating and 592 for terminating, both with SC The dialed Carrier Identification Code (CIC) may not always be available for originating FGD calls at the LMS. The Carrier Information Parameter (CIP) would have to be populated at the originating EO for this information to be available. The CIC in the originating FGD recording generated at the tandem will be derived from 8 9

176 Notes on Billing Issue 1, May 2001 Developments and Future Trends provisioning at the LMS on the basis of the trunk group over which the call is sent to the IC. For calls monitored on an incoming basis from an originating EO (for example, over Trunk Group X in Figure 8-5), the LMS will populate the CIC in the body of the AMA record from the Transit Network Selection (TNS) parameter sent in the call setup signaling. This is considered the routing CIC. If the CIP is also available in the call setup signaling, it will be captured in Module 054 and appended to the AMA record. The TNS parameter is not detected by the LMS for calls monitored between the tandem switch and the IC (for example, Trunk Group B in Figure 8-5). The TNS parameter is dropped from the IAM by the tandem switch call processing before the call setup signaling is sent to the IC and therefore the parameter is not present in the IAM. This parameter could be available in the future with signaling message correlation of incoming and outgoing messages Wireless Service Provider (WSP) Type 2A and 2B Interconnection In some LECs, interconnection of other facilities-based networks is accomplished using Type 2A or Type 2B interfaces associated with Type S for signaling interconnection as illustrated in Figure 8-6. It is not critical that the company that is interconnecting with the LEC using a Type 2A interface is actually involved with providing wireless services. For example, the Type 2A interface may instead be used for interconnecting two wireline local carriers. The interconnection type is the important point along with the AMA generated by the interface. WSP AMA recordings for switch-based AMA are generated for calls that cross a network boundary between a LEC and a WSP. The switch-based WSP AMA BAF call type codes, along with the LMS equivalent call type codes, are listed in Table 8-2. WSP trunk groups can be provisioned as one-way or two-way trunk groups to tandem switches (Type 2A), or as one-way or two-way trunk groups direct to EO switches (Type 2B). 8 10

177 Issue 1, May 2001 Notes on Billing Developments and Future Trends LEC End Offices or Other Carriers EO LEC STP LEC Tandem Type 2B Type 2A POI POI POI Wireless Switching Office WSP Cell Site Link LMS Type S Radio Links Mobile Unit POI = Point of Interface Cell Site Portable Unit Figure 8-6 LMS Recording for WSP Interface For all Type 2A connections to a LEC tandem switch, the WSP AMA record contains the usage data for the connection from the LEC to the WSP but does not contain the usage data from any other connection that resulted from the call. For instance, a connection from another local network, FGB or FGD Carrier. The usage data for these connections must be generated in separate AMA records. For all calls over a Type 2B direct trunk group from a LEC EO outgoing to a WSP (LEC originated), an AMA record is generated at the LMS. This AMA record indicates usage over the LEC/WSP interface, but may not be the only AMA record generated for the call Tandem Transit Traffic Interconnection Figure 8-7 illustrates a general interconnection architecture that tandem providers see emerging in the Public Switched Telephone Network (PSTN). Table 8-3 in association with Figure 8-7 provides six examples of transiting traffic and the AMA that is generated by the LMS for the Tandem Trunk Groups. Please note that calls 8 11

178 Notes on Billing Issue 1, May 2001 Developments and Future Trends that originate in LEC 1 or terminate to LEC 1 will not generate AMA at the LMS for the trunk group between the LEC 1 EO and the LEC 1 tandem switch. The trunk group 1357, for example, is neither a CNA, FGD, nor a WSP trunk group. LEC 1 STP LMS B/D-Links POI IC STP A-Links LEC 1 Access Tandem 1987 POI IC 1234 POP LEC 1 EAEO LEC 2 EAEO LEC 3 EAEO WSP 4 CCS Signaling Link Set CNA Voice Trunk Group for Local and IntraLATA (LEC-carried) Toll Traffic [1357, 2468, & 3579] FGD Voice Trunk Group for InterLATA Toll and PIC2 (non-lec) Traffic [1234, 2345, 3456 & 1987] Type 2A Voice Trunk Group for Combined Traffic [4567] Figure 8-7 LMS Transiting Network Architecture Of the 24 scenarios discussed in GR-3012-CORE, only the six listed below meet the criteria of a transiting call. The first example is a call from LEC 2 to LEC 3 routed through the tandem. The incoming trunk group to the tandem is a CNA trunk group (2468) and this call will presently generate a CTC 590 record at the LMS for this incoming trunk group. The call will then be routed from the tandem over trunk group 3579 to LEC 3. The LMS will presently generate a CTC 589 for this call on the outgoing CNA trunk group. Table 8-3 LMS AMA Generation for Tandem Trunk Groups Originating LEC Call Types Incoming Trunk Group Incoming LMS record Terminating LEC Outgoing Trunk Group Outgoing LMS AMA Recording LEC 2 1, CTC 590 LEC CTC 589 LEC 2 1, CTC 590 WSP CTC 595 LEC 3 1, CTC 590 LEC CTC

179 Issue 1, May 2001 Notes on Billing Developments and Future Trends Table 8-3 LMS AMA Generation for Tandem Trunk Groups (Continued) Originating LEC Call Types Incoming Trunk Group Incoming LMS record Terminating LEC Outgoing Trunk Group Outgoing LMS AMA Recording LEC 3 1, CTC 590 WSP CTC 595 WSP 4 1, CTC 596 LEC CTC 589 WSP 4 1, CTC 596 LEC CTC 589 Call Types 1 = Local 2 = IntraLATA LEC transported using GR-317-CORE signaling. Currently, only an analysis or lookup on the terminating number for the CTC 590 record would identify whether or not this call was a transiting call. By the same token, only an analysis or lookup of the originating number for the CTC 589 record would identify whether or not this was a transiting call. When the Single Record Option is selected, the desired output is a single AMA record generated at the LMS that identifies LEC 2 as the originator of the call by examining the content of CTC 597 / SC 0625, e.g., the Provisioned Billing Number in BAF Tables 13 and 14, or the trunk group number of 2468 in BAF Table 83. The CTC 597 would also identify the terminator of the call by appending Module 104 with trunk group number 3579, interconnecting network code in Module 054, provisioned billing number of the outgoing trunk group in Module 164 (with a new context ID), the terminating LRN in Module 719. Also appended to the record would be the Calling Party Number (CPN) in Module 164, if available, and originating LNP module (Module 719), if available. The Single Record Option will be an added provisioning feature for every LMS CNA and WSP trunk group. When this option is set ON for a trunk group it applies only for calls incoming to the tandem over that trunk group. The LMS is expected to keep track of incoming calls and check the status of the outgoing trunk group. The LMS is not expected to backtrack outgoing calls to the incoming trunk group. The AMA usage measurements generated at the LMS for trunk groups carrying tandem transit traffic will append LNP Modules under different conditions. Since the tandem switch may perform an LNP query before it routes a transit call onto the terminating switch, it is appropriate to append a terminating LNP module to the single record that is generated. An originating LNP module can be generated using either the JIP received in signaling or the JIP provisioned for the incoming CNA or WSP trunk group at the LMS. As a new source for usage measurements generation, other usage measurement systems connected to the network, such as LMSs, need to be compared and contrasted with existing switch-based AMA. The differences that are found between traditional switch-based AMA recording and these new approaches may eventually have to be accommodated in LEC billing systems. 8 13

180 Notes on Billing Issue 1, May 2001 Developments and Future Trends 8.3 Next Generation Network (NGN) Recording The NGN represents the convergence of multiple independent networks into a single, unified, broadband network. Thus, the NGN is designed to integrate voice and data services over high-capacity, high-speed facilities. NGN transport functions may be provided using Internet Protocol (IP) facilities or, as an option, using other broadband technologies such as Asynchronous Transfer Mode (ATM). Telcordia offers a series of generic requirements related to NGN systems and services. AMA requirements for NGN are presented in GR-3058-CORE, Voice over Packet (VoP) Next Generation Networks (NGN) Accounting Management Generic Requirements Background Before addressing usage measurements and billing capabilities to support NGN, it is useful to have an overview of the NGN Architecture, as shown in Figure 8-8. The NGN will interface to the traditional PSTN through trunk and signaling gateway systems. Usage data for calls originating in the PSTN will continue to be recorded in the PSTN systems, while usage data for calls within the NGN will be recorded using NGN accounting management functions. These functions are described in Section NGN components include: Call Connection Agent (CCA): The call processing center for NGN. A CCA processes messages received from other NGN elements (such as Access Gateways, Trunk Gateways and Signaling Gateways) to determine how to route data packets, manage call states and provide network services. For IP transport networks, the CCA is often referred to as a softswitch. Core Packet Network: Used to deliver packetized information between NGN nodes. The Core Packet Network supports transport of end-user data and call connections over a broadband backbone that may be based on IP, ATM, Frame Relay or other technologies. The Core Packet Network also supports the exchange of control information between the CCA and other NGN elements over IP facilities. Depending on the network configuration adopted, the transport and control communications on the Core Packet Network may either be combined on the same facilities or be routed on physically separate networks. Access Gateway (AGW): Supports line-side and trunk-side interfaces to NGN end users. The AGW packetizes information for transport within the NGN Core Network, and provides local signals such as audible ringing, power ringing, and call waiting tone based on instructions received from the CCA. Trunk Gateway (TGW): Supports trunk interfaces to the PSTN. The TGW packetizes information from PSTN circuit switched trunks for delivery on virtual circuits of the NGN Core Network based on instructions received from the CCA. 8 14

181 Issue 1, May 2001 Notes on Billing Developments and Future Trends Call PSTN Signaling Network Signaling Gateway Connection Agent Billing Agent PSTN Transport & Switching Trunking Gateway Core Packet Network Server Access Gateway Network Mediation NGN PBX Gateway Gateway Analog Access Network (e.g., UNEs) Residential Gateway PBX PBX ISDN/DSL DSL Figure 8-8 NGN Architecture Signaling Gateway (SGW): Provides signaling interconnection between the PSTN and NGN. The SGW transfers SS7 messages between the CCA and PSTN systems such as circuit switching systems and data base systems. Network Mediation Gateway (NMGW): Provides gateway screening functions for interconnection with last mile service providers or end-user private networks. The NMGW ensures the integrity of messages delivered to the NGN and protects the CCA by performing functions such as user authorization, message encryption, toll fraud prevention, and traffic throttling. The NMGW can also enhance interconnection with other service providers by providing 8 15

182 Notes on Billing Issue 1, May 2001 Developments and Future Trends protocol translation, circuit compression, and network announcement functions. Servers: Can be used to support many types of applications such as unified messaging, directory services, and speech recognition. Billing Agent (BA): Supports the assembly and formatting of usage data into call detail records. The billing agent collects usage measurements from the CCA, and creates usage records for transfer to the corporate billing system. The CCA and BA play a key role in supporting the recording and delivery of usage information for NGN services. The CCA is responsible for tracking the overall progress of calls and other services, and delivering usage data to the BA. The BA is responsible for assembling and formatting usage data into call detail records NGN Accounting Management Architecture In comparison to the PSTN model, in which the switching system is generally responsible for generating, assembling and formatting usage measurements, the NGN accounting management architecture is more distributed. NGN accounting management involves one or more CCAs interfacing with a BA to deliver raw usage measurements to the Core Packet Network. After receiving the raw usage measurements from the CCA, the BA performs the processing needed to create a formatted usage record. The BA will then transmit the usage record to downstream application systems such as an AMA Data Networking System (AMADNS) collector, the billing system, or fraud detection systems. The key components and interfaces of the NGN Accounting Management solution are illustrated in Figure

183 Issue 1, May 2001 Notes on Billing Developments and Future Trends Call Connection Agent Call Connection Agent Core Packet Network Billing Agent Corporate Accounting/ Application System Figure 8-9 NGN Accounting Management Components The Call Connection Agent is the central nervous system of the NGN architecture. The CCA provides much of the call processing functionality necessary to support voice calls on the core packet network. The CCA processes messages received from other NGN functional entities (e.g., gateway and server systems) to manage call states. The CCA communicates with other CCAs to setup and manage an end-to-end call. While each gateway (e.g., Access Gateway, Trunk Gateway or Signaling Gateway) is associated with a specific CCA, the CCA would typically interact with multiple and various gateway systems. A CCA instructs the gateways with call control commands, allowing it to keep accurate track of call state and event information. The NGN accounting management depends on the relationship of the CCA to subtending gateway systems in order to allow usage data collection to be focused at the CCA itself. The CCA provides usage measurements to the BA based on call parameters and events. The CCA is the BA s only direct link to call event information elements required by the BA, rather than any information being provided to the BA via another NGN component. As NGN services become more sophisticated, however, it may not be possible to rely exclusively on the CCA for usage data. For example, information may be required from NGN service agents to gain a complete view of call services provided. When this happens, it may be necessary for the BA to correlate and assemble usage data received from multiple NGN systems, as described in Section

184 Notes on Billing Issue 1, May 2001 Developments and Future Trends The Billing Agent provides assembly, processing, formatting and outputting of usage records for delivery to downstream systems. Processing in the BA includes data massaging (e.g., rounding of timing measurements), long duration call processing, determination of record type, and determining when to produce a record. The call event information (i.e., usage measurements) for a given call may be transmitted from the CCA to the BA as one or more unformatted measurements. In cases in which multiple measurements are associated with a single call, the BA will provide the functionality needed to assemble this information into a single call record. In addition, the BA provides accounting administration, which allows the setting of parameters for record data administration, record and file handling administration, communications interface administration, system operations and log administration. The interface between the CCA and BA provides a communication path for the CCA to deliver usage measurements to the BA. Where the CCA and BA reside on different host systems, the communication between the CCA and BA occurs via the core packet network. Several upper layer protocols are available for the information exchange between the CCA and BA. Based on existing industry standards, the most promising potential candidates for the CCA/BA interface include Remote Authentication Dial-In User Service (RADIUS) and Common Object Request Broker Architecture (CORBA). Both the RADIUS and CORBA protocols are based on start and stop messages indicating the initiation and completion of communication sessions. For the NGN call detail recording, this translates into messages related to connect, disconnect, and attempt event messages. The BA is responsible for matching connect and disconnect event messages from the CCA that are associated with a given call in order to formulate a single usage record for the call (this is what is meant by usage record assembly. ) The BA will then deliver the assembled usage records to the application system for further processing. The interface between the BA and Application Systems is dictated by the role of the BA in preparing usage records for delivery to downstream systems. In this regard, the BA is expected to operate in the same manner as an AMADNS Data Server. Therefore, it is anticipated that the interface between the BA and Application Systems will be based on the AMADNS Data Server/Data Processing Management System Interface (DDI), as described in Section NGN Usage Data Generation for Voice Calls GR-3058-CORE focuses specifically on the procedures for recording voice telephone calls in an NGN environment. Since the underlying core network technology to be used to transport the voice call communication is assumed to be either an IP or ATM infrastructure, these calls are referred to as Voice over Packet (VoP) services. As noted in Section 8.3.2, the CCA provides usage data to the BA in the form of Connect, Disconnect and Attempt event messages. The information contained 8 18

185 Issue 1, May 2001 Notes on Billing Developments and Future Trends in these event messages will be used to populate BAF records that are similar to the BAF records created for circuit switched voice calls. For example, a Connect message related to an Originating Access call would contain information related to Call Identifier CCA Identifier Service Type Calling Station ID Called Station ID Terminating NPA/Number Indicator Routing Indicator Carrier ID Operator involvement indicator Call Event Status Signaling Type Trunk Group ID Carrier Connect Date and Time Presubscription Indicator ANI/CPN Indicator Called Party OffHook Study/Test Indicator Timing Guard One of the key objectives set forth in the GR-3058-CORE generic requirements was to minimize the changes required to legacy billing systems in order to process usage records related to VoP calls. As a result, the BA plays a significant role in formatting the usage measurements provided by the CCA in order to create traditional BAF records based on existing structure codes. The Sensor ID (BAF Table 3) in the BAF record will indicate the CCA which provided the usage measurements upon which the BAF record is based, while the Recording Office ID (BAF Table 5) will indicate the BA that created the BAF record. Table 8-4 shows how information would be derived to populate the SC 0625 record for an originating access call. 8 19

186 Notes on Billing Issue 1, May 2001 Developments and Future Trends Table 8-4 Population of Originating Access Record Based on CCA Input BAF Element Derived from CCA Input How Determined by BA Structure Code X Based on Service Type Call Type X Based on Service Type Sensor Type X Based on CCA ID Sensor ID X Based on CCA ID Recording Office Type Preset in BA Recording Office ID Preset in BA Connect Date X Based on Customer Connect Date and Time Timing Indicator X Based on Timing Guard Study Indicator X Based on Study/Test Indicator and Called Station ID Called Party Off-Hook X = Called Party OffHook Indicator Indicator Service Observed/Traffic Default value 0 Sampled Operator Action Default value 0 Service Feature Default value 0 Originating NPA X Based on Calling Station ID Originating Number X Based on Calling Station ID Overseas Indicator X Based on Terminating NPA/Number Indicator Terminating NPA X Based on Called Station ID Terminating Number X Based on Called Station ID Connect Time X Based on Customer Connect Date and Time Elapsed Time X Calculated from Connect and Disconnect timestamps IC/INC Prefix X Based on Carrier ID and Operator Involvement Indicator Carrier Connect Date X Based on Carrier Connect Date and Time Carrier Connect Time X Based on Carrier Connect Date and Time Carrier Elapsed Time Calculated from Connect and Disconnect X timestamps IC/INC Call Event Status X = Call Event Status Trunk Group Number Based on Signaling Type and Trunk Group X Number Routing Indicator X = Routing Indicator Dialing and = Presubscription Indicator X Presubscription Indicator ANI/CPN Indicator X = ANI/CPN Indicator 8 20

187 Issue 1, May 2001 Notes on Billing Developments and Future Trends The one dimension in which VoP usage records are expected to differ from usage records for similar calls transported in the PSTN is in the call type code used. As shown in Table 8-5, the new VoP call codes are available to be used with the traditional BAF structures. The BA determines the call type code to be used by mapping information from the Service Type provided by the CCA. This mapping is user-definable. Therefore, a network provider could (for example) map the VoP call type codes to the call type codes used for PSTN. This would allow the VoP usage measurements to be processed using the very same pre-processing and usage rating algorithms that exist for non-ngn calls. Table 8-5 NGN Voice over Packet Structure and Call Type Codes Type of Call Structure Code Call Type Code VoP Basic Local Service VoP Originating Exchange Access VoP Terminating Exchange Access VoP Originating Connecting Network Access VoP Terminating Connecting Network Access VoP Basic Long Distance/Ingress VoP Basic Long Distance/Egress Distributed Processing in Telecommunications Networks The LMS AMA solutions and NGN accounting management approaches described above are two key examples of the trend to distributed network architectures for telecommunications solutions. In the past, the circuit switching system was the center of control for handling calls and other telephone services. Gradually, the introduction of network databases and application servers resulted in a distribution of service logic across network elements. More recently, the growth in data services has spurred an evolution to packet-switched networks as the basis for supporting a complete spectrum of voice, data and multi-media telecommunications services. The trend in telecommunications networks has been towards the implementation of highly-specialized network components that can be called upon as warranted per each telecommunications service request. As a result, the service logic no longer can be assumed to reside with a single network component that is in control of a call or service request. From a billing perspective, the effect of the distributed processing is that it is often no longer possible to depend on a single network element for an entire view of the service that is being provided. Network elements are now being designed to record individual service events (as opposed to a complete view of a call or service provided). This allows a more complete unbundling of telecommunications services, and should allow for more rapid introduction of new service capabilities in the network. However, the distribution of service processing also creates a great challenge for telecommunications services billing. End-users are generally aware only of the 8 21

188 Notes on Billing Issue 1, May 2001 Developments and Future Trends overall service provided, and not the individual network events that occur in providing the service. This means that accounting systems may need to be able to reconstruct usage event information from multiple network elements in order to identify billable services. Several telecommunications equipment suppliers have responded to the growing need for systems to support the assembly and formatting of usage data into billable records. The new devices, referred to as billing mediation systems, have rules-based procedures for filtering usage data, correlating information across the network systems involved in the service, formatting the information into usage records that are readable by the billing system, and transporting the usage records to the billing system. The impacts of distributed processing on billing capabilities goes beyond billing mediation itself. There will be special challenges in the provisioning of new service capabilities within the telecommunications networks before a service can be provided. This will require special configuration management functions among the network elements. Once the service is in place, there will also be new communication functions required among network systems while the service is being provided. For example, it may be necessary to signal a unique transaction code or correlation identifier with each service request, so the billing mediation device will have explicit information to associate event information received from multiple network systems Call Detail Recording for Global Solutions One limitation of the BAF is that it has traditionally been designed to represent call detail recording capabilities that are specifically tailored to U.S. LEC wireline applications. As a result, the BAF structure codes have been designed to assume use of the North American Numbering Plan (NANP) for telephone addresses. Usage data formats related to network interconnection and LNP are also designed to U.S. telecommunications services. Gradually, equipment suppliers have introduced the use of BAF in international service scenarios. As this has occurred, the suppliers have worked with Telcordia to introduce new usage information formats that are more generic and adaptable to broader applications. These new information formats have been introduced caseby-case, as new needs for usage data elements surface. The results have included the extension of addressing fields to allow greater flexibility in the representation of telephony addresses, typically through the use of generic modules with context identifiers (as described in Section 8.2.1). As global applications increase, however, there may be a need to create a new set of structure codes within BAF that are based on international addresses and services. 8 22

189 Issue 1, May 2001 Notes on Billing Developments and Future Trends Convergence of Voice and Data Services The evolution to international addresses may go well beyond the use of the international E.164 numbering format. With new applications such as Unified Messaging solutions on the forefront, source and destination points will need to include IP and addresses. Other impacts of the migration to data-centric solutions include an increasing emphasis on aggregate usage measurements (e.g., number of packets or bytes of information exchanged between a source and destination node) as opposed to the use of call detail records for billing. The increasing use of data networks to support voice services also has lead to increasing concern for Quality of Service (QoS). These changes are happening at the same time the migration to distributed processing architectures is taking hold. An overall evolution of usage data recording is taking place, with the objective to provide highly competitive telecommunications solutions. In some cases, the result may be low cost, bare bones services that abandon the flexibility offered by usage-sensitive billing. In other cases, the result may be premium services based on extensive repositories of usage information. Stay tuned to see what happens. 8 23

190 Notes on Billing Issue 1, May 2001 Developments and Future Trends 8.4 Alternative Recording Formats Internet Protocol Data Record (IPDR) Internet Protocol Data Record (IPDR) is being defined by the IPDR.org, which was formed in June 1999 through the initiative of TeleStrategies, NARUS, and AT&T. These organizations perceived that there was a need for quick development and deployment of usage measurements that would capture elements within an IP framework. The IPDR.org objective is to facilitate the integration of IP-based network elements with billing, reporting, and assurance systems. Its primary mission is to define a common usage record format and record exchange protocol to facilitate the flow of usage information from IP network element managers to support systems. As of the time of this document s publication, IPDR.org consisted of more than 100 member companies. IPDR defines usage record formats for a variety of IP applications such as Voice over IP (VoIP), services, and Internet access. IPDR record formats are based on the Extensible Markup Language (XML), which is a subset of Standardized General Markup Language (SGML). The format provides flexibility to identify both essential and optional elements that would exist in an IPDR record. This is achieved through the definition of a schema that describes the usage data to be captured for each application supported by IPDR. The schema for each IP application supported by IPDR is designed to record five key components of usage information: Who: Identification of the user involved in the IP service When: Time of events resulting in creation of the usage record What: Service type and service usage, QoS measures, and/or event state information Where: Source and destination addresses related to the network and service elements involved Why: Indication of event triggers causing the usage report to be generated. In some cases, the usage records will also contain pointers to other usage records containing related information. As a specific example of the expected information content in an IPDR record, an IPDR related Internet access service is expected to contain the following information: Who attributes Subscriber ID (phone number, IP address, device ID, etc.) Service Provider ID (service provider for Internet access) When attributes: 8 24

191 Issue 1, May 2001 Notes on Billing Developments and Future Trends Access start time Access end time Duration of access What attributes: Transport Protocol (WAP, TCP, PPPoE, etc.) Connection Type (fixed wire dial-up, DSL, cable modem ) Upstream bandwidth Downstream bandwidth Volume of data uploaded Volume of data downloaded Requested QoS (per Service Level Agreement or dynamic request) QoS delivered Where attributes Internet Access Point (dial-up number, gateway IP address, etc.) Service element used to provide access The XML format supports the explicit representation of usage data attributes using ASCII text representations. While this provides flexibility in allowing information to be included or excluded from the IPDR based on the characteristics of each instance of IP service usage, the IPDR records tend to be very lengthy when compared to the BAF approach of recording of Binary Coded Decimal (BCD) values in fixed-structure fields. Further information on IPDR schema and information transport is available in Network Data Management - Usage (NDM-U) for IP-Based Services, Version 2.0, IPDR.org, October Other CDR Formats There are numerous emerging technologies and new service offerings, some of which may not be optimally suited to BAF as currently defined. Telcordia is currently investigating alternative formatting methods that may be used in the future to describe the format of AMA records in the network. These methods are being studied for their possible role as an enhancement to BAF, or, perhaps, a replacement for BAF. One focus is on format definition languages (FDLs), which are used to describe the format, or layout, of a data stream. A data stream is typically a regular data file, or sometimes a direct transmission, of data from one computer program to another. The following are some examples of FDLs: BAF is the current method of describing the format of AMA records; 8 25

192 Notes on Billing Issue 1, May 2001 Developments and Future Trends ASN.1 (Abstract Syntax Notation 1) is used in data communications systems; Electronic transactions are used for data interchange among businesses and government agencies. The ANSI X.12 standard is the most commonly used method for defining the format of the data streams (files or transmissions) for the exchange of information between business data processing systems. Given the major changes taking place in telecommunications equipment, service offerings, and telecommunications entities, Telcordia believes it is necessary to evaluate other data formatting technologies along with BAF. For example, how might either ASN.1 or ANSI X.12 be used to define the format of AMA records. Some specific areas of industry growth that may stretch the limits of BAF include: 1. A greater variety in the kinds of equipment in the network that will be generating usage measurement records, such as broadband switches, soft switches, database servers, and PCS equipment. 2. More participants in the marketplace, some who will record their own usage measurements, and some who will ask others to record usage measurements on their behalf. 3. An increasing number of service offerings, some that will require more sophisticated kinds of usage measurement records. 4. With an increase in the number of services comes the need for a much shorter development cycle for billing solutions. 5. There will be more applications, or ways to use the usage measurement records, such as market analysis and business negotiations BAF Limitations BAF has been sufficiently flexible in the past to represent the necessary kinds of AMA records. But difficulties are becoming more common in representing new kinds of usage measurements. The following describe some specific examples of where BAF is beginning to show some signs of weakness. 1. Large Number of Fields and Optional Fields. 2. Although it is possible to define new kinds of information in a BAF record (using BAF Tables and BAF Modules), there are some practical limitations. For instance, to date, BAF Modules have not easily accommodated a very large number of fields of varying data types, or fields that are optional. This is being addressed with the introduction of flexible modules as mentioned in Section 3. The LIDB GetData function was the first to be greatly hindered by this limitation in BAF. The solution for GetData eventually involved using a different format definition language (ASN.1) and a technique called encapsulation, wherein the new format is stored in a specially designed BAF Module. 8 26

193 Issue 1, May 2001 Notes on Billing Developments and Future Trends It might be possible, in principle, to use the encapsulation approach to solve all future recording needs in BAF, but it might prove cumbersome to implement, for both the sender and the receiver, and it would be difficult to manage. It would also be inefficient, from the standpoint of computing and storage resources, to routinely use a first formatting facility like ASN.1 or X.12, and then encapsulate (i.e., store) the result using a second formatting facility (i.e., BAF). 3. Scarcity of structure codes and module codes -- BAF depends on the use of unique structure codes and module codes. The codes are defined with a fixed number of decimal digits, and the range of possible code numbers is small. Consequently, the code numbers represent a scarce resource that could eventually exhaust. The code scarcity also increases the complexity of managing the codes, because there is pressure to identify and reuse an existing data type or module for some new purpose, if it can be made to work at all. The use of codes to identify structures and modules is not the problem in itself, and indeed other formatting architectures do something similar, and call it by a different name; ASN.1 speaks of tags, and X.12 speaks of reference numbers. It is the particular BAF implementation of codes, as well as structures and modules, that may eventually prove to be too limiting. 4. Non-Automated Translation -- BAF is a natural language FDL, which means a format definition is maintained in a natural language, like English, along with some supporting graphics. Individual users of the definition, especially software developers, have to read and understand the meaning of the definition. Hopefully they will all come to the same understanding. A formal language FDL, such as ASN.1 or X.12, is one that is machine translatable. This means the format definition (for the data stream) can be compiled along with the rest of the program. The format can be centrally managed, just as BAF is managed, and distributed to the users in a format than can be compiled. This reduces the amount of human effort, and it reduces the likelihood of errors in interpretation or implementation. When the BAF format changes, all areas of the software that interact with the data stream have to be inspected for possible changes. But when a formal language FDL is used to define a data stream, the compiler automatically generates those parts of the program that interact with the data stream, such as reading from and writing to the data stream, parsing record fields, recognizing when optional data is absent, and converting between external and internal formats. The software developer still has to write the data processing aspects of the program, but the finished program automatically conforms to the data stream format Next Steps in Usage Format Evolution The limiting characteristics of BAF, the apparent inability to effectively support a large number of optional fields, or fields of varying data types, the fact that BAF is a natural language (as opposed to a programming language like ASN.1) that does not facilitate automatic programming, and the scarcity of BAF codes (call type, 8 27

194 Notes on Billing Issue 1, May 2001 Developments and Future Trends structure, and module), are being investigated by Telcordia with an eye toward evolving the BAF format. There are several approaches that are being considered, including those discussed below Encapsulation Encapsulation is a formatting process that uses two different formats in the same data stream. The usual reason for using encapsulation is that certain exceptional information cannot be adequately represented in the primary format and, therefore, must be represented in the secondary format. Information would be formatted in the following manner using encapsulation: The most common information is formatted according to the primary format, and then written to the data stream. The exceptional information goes through a two-step process: it is initially formatted according to the secondary format, and stored into an intermediate data element (internal to the producer program). The intermediate data element is then formatted according to the primary format, and written to the data stream. The receiver program must be prepared to process a data stream that contains encapsulated information. Decoding the data stream is a two-step process for the encapsulated information (just the reverse process of two-step encoding), and a one-step process for the non-encapsulated information Redefinition This approach would redefine the BAF-FDL. For example, the BAF-FDL could be redefined to allow variable-length BAF Tables. If redefinition of the BAF-FDL were the long-term goal, some arrangements would be necessary during the transition, for the benefit of existing software. If the BAF-FDL were redefined, newer generating systems would be implemented, where possible, according to the new BAF-FDL. However, there would be a period in which newer generating systems would produce AMA records based on the new BAF-FDL, while older generating systems would produce AMA records based on the current BAF-FDL Coexistence The coexistence scenario presumes that various definitions of the AMA data stream will continue to be used indefinitely. For example, newer generating systems would produce data streams according to the newest FDL, perhaps ASN.1, X.12, or IPDR, 8 28

195 Issue 1, May 2001 Notes on Billing Developments and Future Trends and older generating systems would (perhaps forever) produce vintage BAF data streams. There are some advantages to this approach: 1. It offers maximum flexibility in defining a new AMA recording architecture. With the assumption that the BAF-FDL and new FDLs will coexist indefinitely, the focus can be on optimizing format definitions based on these new FDLs to meet future needs, without being unduly constrained by legacy systems. 2. It minimizes the impact of BAF evolution on existing generating systems and billing systems. 3. It enables the use of an ASN.1-based definition for some applications, and an X.12-based definition for other applications, and so on. The choice of implementation can be adjusted to the needs of the generating system or billing system, or other application. Coexistence seems to be the most likely evolution scenario. It is particularly appropriate to any technology that is as complex and widely deployed as BAF Conclusion BAF will continue to evolve and Telcordia will continue to explore how this can best be accomplished, by: evaluating alternative FDLs such as ASN.1, X.12, and IPDR for technical feasibility (for example, in terms of efficiency of computing resources, compactness of the data stream, and availability of development platforms) working with clients and industry to understand the benefits and costs of the alternative FDLs and evolution scenarios producing recommendations on evolving BAF. 8 29

196 Notes on Billing Issue 1, May 2001 Developments and Future Trends 8 30

197 Issue 1, May 2001 Notes on Billing Bibliography and References Appendix A: Bibliography and References Ref.1 Generic Requirements Documents (GRs) FR-12, Analog Display Services Interface (ADSI) FR-64, LATA Switching Systems Generic Requirements (LSSGR) FR-271, Operator Services Systems Generic Requirements (OSSGR) GR-145-CORE, Compatibility Information for Interconnection of a Wireless Services Provider and a Local Exchange Carrier Network GR-215-CORE, LSSGR: CLASS SM Feature: Automatic Callback, FSD GR-220-CORE, LSSGR: CLASS SM Feature: Screening List Editing, FSD GR-227-CORE, LSSGR: CLASS SM Feature: Automatic Recall, FSD GR-301-CORE, Public Packet Switched Network Generic Requirements (PPSNGR) GR-317-CORE, LSSGR: Switching System Generic Requirements for Call Control Using the Integrated Services Digital Network User Part (ISDNUP) GR-385-CORE, Automatic Message Accounting Teleprocessing Systems (AMATPS) Generic Requirements GR-391-CORE, LSSGR: CLASS SM Feature: Calling Identity Delivery Blocking Features, FSD GR-394-CORE, LSSGR: Switching System Generic Requirements for Interexchange Carrier Interconnection (ICI) Using the Integrated Services Digital Network User Part (ISDNUP) GR-416-CORE, LSSGR: CLASS SM Feature: Call Waiting Deluxe, FSD GR-446-CORE, Generic Requirements for the Administrative System (AS)/Line Information Database (LIDB) - LIDB Interface GR-499-CORE, Transport Systems Generic Requirements (TSGR): Common Requirements GR-505-CORE, LSSGR: Call Processing GR-508-CORE, LSSGR: Automatic Message Accounting (AMA) GR-512-CORE, LSSGR: Reliability, Section 12 A 1

198 Notes on Billing Issue 1, May 2001 Bibliography and References GR-528-CORE, LSSGR: Public Telecommunications Service, FSD GR-532-CORE, LSSGR: Call Processing Features, FSD through GR-533-CORE, LSSGR: LSSGR Database Services - Service Switching Points, FSD GR-534-CORE, LSSGR: Public Switched Digital Service, FSD GR-567-CORE, LSSGR: CLASS SM Feature: Anonymous Call Rejection, FSD GR-575-CORE, LSSGR: CLASS SM Feature: Calling Identity Delivery on Call Waiting, FSD GR-577-CORE, LSSGR: Three-Way Calling, FSD GR-578-CORE, LSSGR: Usage-Sensitive Three-Way Calling GR-580-CORE, LSSGR: Call Forwarding Variable, FSD GR-581-CORE, LSSGR: Remote Call Forwarding, FSD GR-601-CORE, LSSGR: Outward Wide Area Telecommunications Service (OUTWATS), FSD GR-604-CORE, LSSGR: Automatic Flexible Routing, FSD GR-605-CORE, LSSGR: Authorization Codes for Automatic Flexible Routing (AFR) and Account Codes for Basic Business Group and AFR, FSD GR-610-CORE, LSSGR: Message Detail Recording (MDR), FSD GR-615-CORE, LSSGR: Generic Requirements for Message Detail Recording (MDR) Access Interfaces, (FSD ) GR-690-CORE, LSSGR Exchange Access Interconnection, FSD GR-697-CORE, LSSGR Feature Group A, FSD GR-698-CORE, LSSGR Feature Group B, FSD GR-862-CORE, ISDN Automatic Message Accounting Generic Requirements GR-954-CORE, Common Channel Signaling (CCS) Network Interface Specification (CCSNIS) Supporting Line Information Database (LIDB) Services GR-1060-CORE, Switched Multi-megabit Data Service (SMDS) Generic Requirements for Exchange Access and Intercompany Serving Arrangements A 2

199 Issue 1, May 2001 Notes on Billing Bibliography and References GR-1083-CORE, Generic Requirements for Exchange Access Automatic Message Accounting (AMA), FSD GR-1087-CORE, Generic Requirements for Common Channel Signaling (CCS) Network Usage Measurement Functionality GR-1100-CORE, Billing Automatic Message Accounting Format (BAF) Generic Requirements GR-1110-CORE, Broadband Switching System (BSS) Generic Requirements GR-1115-CORE, BISDN Inter/Intra-Carrier Interface (B-ICI) Generic Requirements GR-1144-CORE, OSSGR: Signaling GR-1147-CORE, OSSGR: Section 8 Administration GR-1149-CORE, OSSGR: Section 10 System Interfaces GR-1158-CORE, OSSGR: Section 22.3 Line Information Database GR-1173-CORE, OSSGR: Common Functions GR-1175-CORE, OSSGR: Customer Listing Information (FSD 75 Series) GR-1176-CORE, OSSGR: Custom Call Handling Features (FSD 80 Series) GR-1177-CORE, OSSGR: Special Billing Features (FSD 85 Series) GR-1188-CORE, LSSGR: CLASS SM Feature: Calling Name Delivery Generic Requirements, FSD GR-1242-CORE, ISDN Selective Call Rejection GR-1280-CORE, Advanced Intelligent Network (AIN) Service Control Point (SCP) Generic Requirements GR-1298-CORE, AINGR Switching Systems GR-1310-CORE, ISDN Call Deflection for Primary Rate Interfaces Generic Requirements GR-1337-CORE, Multipoint Multimedia Conferencing Control Unit GR-1343-CORE, Generic Requirements for the Automatic Message Accounting Data Networking System (AMADNS) GR-1504-CORE, Generic Requirements for Wireless Service Provider AMA GR-1509-CORE, Generic Requirements for Call-By-Call Service Selection Access to Interexchange Carrier Services Via Signaling System No 7 (SS7) GR-2801-CORE, Switching and Signaling Generic Requirements to Support 1 8 GHz Personal Communications Services (PCS) Providers A 3

200 Notes on Billing Issue 1, May 2001 Bibliography and References GR-2838-CORE, Generic Requirements for GetData GR-2844-CORE, Billing Measurements for Voice and Fax Messaging GR-2848-CORE, Broadband Multi-Services User-Network Interface Generic Requirements GR-2877-CORE, Switching System AMA Requirements for Translations Audit Records (TARs) GR-2932-CORE, LSSGR: Database Functionality GR-2936-CORE, Local Number Portability Capability Specification: Service Provider Portability GR-2966-CORE, Module-Specific Generic Requirements for Specialized Processing Modules (SPMs) for the Automatic Message Accounting Data Networking System (AMADNS) GR-2970-CORE, Service Provider Identification Capability Specification GR-2974-CORE, Directory Assistance Call Completion (DACC) Generic Requirements for the use of the Signaling System 7 (SS7) Release To Pivot (RTP) Network Capability GR-2982-CORE, Local Number Portability (LNP) Capability Specification: Location Portability GR-3006-CORE, CLASS SM Feature: Audible Voice Identity Delivery Generic Requirements GR-3012-CORE, Generic Requirements for Network Interconnection Signaling System No. 7 (SS7) Link Monitoring System (LMS) Automatic Message Accounting (AMA) GR-3058-CORE, Voice over Packet (VoP) Next Generation Networks (NGN) Accounting Management Generic Requirements Ref.2 Special Reports (SRs) SR-69, Comptrollers Automatic Message Accounting Format Description (CAFD) SR-3895, Preliminary Requirements for Support of Service Provider Identification for Alternate Billing Services (ABS) SR-3974, Preliminary Requirements for Support of Service Provider Identification for Originating Line Number Screening (OLNS) SR-NWT , Proposed Requirements for Advanced Intelligent Network (AIN) Service Management System (SMS) Usage Measurements and an SMS/Billing Interface SR-2275, Telcordia Notes on the Networks A 4

201 Issue 1, May 2001 Notes on Billing Bibliography and References Ref.3 Technical References (TRs) TA-TSY , CLASS SM Feature: Selective Call Acceptance TR-NWT , Generic Requirements for the Switched DS1/Switched Fractional DS1 Service Capability from a non-isdn Interface (SWF-DS1/ non-isdn) TR-NWT , Advanced Intelligent Network (AIN) Adjunct Generic Requirements TR-NWT , OSSGR: Customer Access Features (FSD 70 Series) TR-NWT , Generic Requirements for the Switched DS1/Switched Fractional DS1 Service Capability from an ISDN Interface (SWF-DS1/ ISDN) TR-NWT , Network User Identification (NUI) Capabilities Requirements TR-NWT , X 25 Call Redirection and Call Deflection Generic Requirements TR-NWT , Automatic Message Accounting (AMA) for Public Packet Switched Networks TR-NWT , Advanced Intelligent Network (AIN) 0.1 Switching Systems Generic Requirements TR-TSV , Generic System Requirements in Support of Switched Multi-megabit Data Service TR-TSV , Usage Measurement Generic Requirements in Support of Billing for Switched Multi-megabit Data Service TR-TSV , Generic Requirements for Frame Relay PVC Exchange Service TR-TSV , Generic Requirements for Exchange Access Frame Relay PVC Service TR-TSY , Additional Service Switching Point and Related End Office Capabilities (Including Private Virtual Network Services) TR-TSY , ISDN Routing and Digit Analysis A 5

202 Notes on Billing Issue 1, May 2001 Bibliography and References Ref.4 Other References Note TRQ No. 2, Technical Requirements for Number Portability - Switching Systems [Alliance for Telecommunications Industry Solutions (ATIS)] ITU-T Recommendation E.164, Numbering Plan for the ISDN Era, ITU- T, Update integrating former E.163, 1991 ITU-T Recommendation X.121, International Numbering Plan for Public Data Networks MDP , Operations Systems Network Communications Protocol Specifications BX.25, Telcordia, Issue 3, June 1982 All Telcordia documents are subject to change, and their citations in this document reflect the most current information available at the time of this printing. Readers are advised to check current status and availability of all documents. To Contact Telcordia Customer Service Telcordia Customer Service 8 Corporate Place, Room 3A-184 Piscataway, NJ (USA and Canada) (Worldwide) (FAX) To Order Documents From Outside Telcordia External customers should perform the following steps to order from the on-line Information SuperStore: 1. Enter the URL line: then choose Store (top right) 2. Click on Search located on top 3. In the Keywords field, enter the document number (or keywords), then scroll down and click on Submit Search, or 1. Enter the URL line: then choose Store (top right) 2. Click on Browse located on top, then click on the subject of interest. To Order Documents Within Telcordia Telcordia employees should access the Telcordia Internal Home Page (i.e., InSite) and perform the following steps: 1. Click on Services on the blue horizontal bar A 6

203 Issue 1, May 2001 Notes on Billing Bibliography and References 2. Click on AXESS SM Point Service You may choose from the vertical list to perform a variety of AXESS Point tasks. However, to obtain a document by document number 1. Click on Basic Search to obtain the Basic Search Criteria box 2. In the Search by Document Number field, enter the document number (e.g., GR-X-CORE), then scroll down to click on Submit Search 3. In the Basic Search Navigation List, select Click for Abstract to order an available document, or select Click for Document to view an available document. A 7

204 Notes on Billing Issue 1, May 2001 Bibliography and References A 8

205 Issue 1, May 2001 Notes on Billing Glossary Appendix B: Glossary This section provides a detailed definition of AMA-related and BAF-related terms. It is designed as a reference tool. Hyperlinks to these definitions have been established and are spread throughout the document. 500 Service One of three non-geographic Numbering Plan Area (NPA) codes, this one dedicated to personal communications services. See Service Access Code. 700 Service One of three non-geographic Numbering Plan Area (NPA) codes, this one reserved for Interexchange Carrier use. See Service Access Code. 900 Service One of three non-geographic Numbering Plan Area (NPA) codes, this one designated for special services, such as information services, polling, or fund raising. See Service Access Code. access customer Any carrier or end user that purchases exchange access services (switched access or facility (special) access) from a Local Exchange Carrier (LEC) out of an access tariff. Access Service Request (ASR) An order from an access customer (e.g., an interexchange carrier) for connection to a Local Exchange Carrier (LEC) network. Access Tandem (AT) A switching system that concentrates and distributes traffic for interlata traffic originating or terminating within a Local Access and Transport Area (LATA). An access tandem can also provide equal access for non-conforming end offices. Advanced Intelligent Network (AIN) A network in which: (1) service logic providing advanced services beyond traditional switch-based features is stored in Service Control Point (SCP) nodes; (2) a Service Switching Point (SSP) encounters triggers during call processing, which indicate that call processing should be suspended; and (3)Signaling System 7 (SS7) Transaction Capabilities Application Part (TCAP) queries are launched by SSPs (based on encountering triggers) to access this service logic. Alternate Billing Services (ABS) Services offered using an intelligent network that allows subscribers to charge a call to a number or telephone other than the one they are using (e.g., calling card, bill-to-third-party). AMA Data Networking System (AMADNS) A system that supports the transfer, processing, and management mechanisms required to enable data applications with Automatic Message Accounting (AMA) data. AMA file A logical collection of Automatic Message Accounting (AMA) records and is not intended to in any way dictate an implementation. For example, an AMA record could actually be copied into an open file, or a reference to that record could be recorded and the record could be accessed when the file is to be transferred. B 1

206 Notes on Billing Issue 1, May 2001 Glossary AMA Teleprocessing System (AMATPS) A system with features that transmit Automatic Message Accounting (AMA) data on a store, poll, and forward basis to a central point for input into the Revenue Accounting Office (RAO) message billing process. AMA Transmitter (AMAT) The AMATPS subsystem that receives Automatic Message Accounting (AMA) data from generating systems and transmits AMA files in Billing AMA Format (BAF) to the AMATPS Collector. AMAslpID A nine (9) digit value returned from an Advanced Intelligent Network (AIN) database to an AIN Service Switching Point (SSP) used to identify the AIN service that was provided. The value for the AMAslpID can be set by the owner of the database. analog 1. A continuously varying physical variable, such as sound or electrical current. 2. A category of devices and circuits in which a signal varies continuously in amplitude or frequency. See digital. ANSI X.12 The most commonly used method for defining the format of the data streams (files or transmissions) for the exchange of information between business data processing systems. application systems Operations support systems such as Billing Systems, Fraud Reduction Systems, Marketing Systems, and Message Detail Recording (MDR) that require access to Automatic Message Accounting (AMA) data to provide a service to customers or to support internal carrier operations. ASN.1 Abbreviation for Abstract Syntax Notation 1; a machine-translatable language for defining the data type aspects of a data stream, but not the encoding aspects (hence, the term abstract). Defined in ISO 8824:1987, Information Processing Systems - Open System Interconnection Specification of Abstract Syntax Notation (ASN.1). Asynchronous Transfer Mode (ATM) A multiplexing and switching technique that organizes information into fixed-length cells with each cell consisting of an identification header field and an information field. The transfer mode is asynchronous in that the recurrence of cells depends on the instantaneously required bit rate. attempt Any demand for service to which a network element reacts. Automatic Message Accounting (AMA) The process that generates data in a switching system from which customers and carriers are billed for their use of network services and capabilities. Automatic Number Identification (ANI) The automatic identification of a calling-station number by a switching system rather than an operator. Automatic number identification facilitates Automatic Message Accounting (AMA) for toll or message-rate service. The identification includes additional digits that identify the type of call, as well as the number itself. ANI is sometimes, but not always, equivalent to the Calling Number. B 2

207 Issue 1, May 2001 Notes on Billing Glossary BAF element Any field, parameters, structure, call type, or module associated with Billing AMA Format (BAF). Basic Business Group (BBG) A collection of non-isdn lines, Integrated Services Digital Network (ISDN) Basic Rate Interfaces (BRIs), and private facilities (physical or simulated) served by a single switching system and providing shared features, such as the Business Group Dialing Plan (BGDP), to this collection. Basic Rate Interface (BRI) The Integrated Services Digital Network (ISDN) BRI provides three bidirectional, symmetric digital channels to the user s premises. Two of the channels are referred to as B-channels and each supports a 64-kbps information flow in each direction. The third channel is referred to as the D-channel and supports 16-kbps of signaling and user information flow in each direction. The D-channel has a message-oriented protocol that supports call control signaling and packet data. Thus, ISDN BRI provides for 2B+D, two B-channels and one D-channel, providing for 144-kbps of user information in each direction. bearer call type A grouping of bearer capabilities on which common service parameters and call control procedures are usually based. bearer capability The transmission and signaling capability provided to the user, either between Integrated Services Digital Network (ISDN) users or between the calling user and an interworking point to another network. Billing AMA Format (BAF) A system of abstract syntax and semantics that supports coding of Automatic Message Accounting (AMA) data into data records. The BAF format is administered by Telcordia Technologies, Inc. broadband communications Voice, data, and/or video communications at rates greater than megabits per second, that is, greater than wideband communications rates. Broadband Switching System (BSS) A general term applied to any switching system that is capable of switching voice, data, and/or video communications at rates greater than megabits per second. Busy Line Verification (BLV) A service provided at an operator services switch, involving operator intervention to determine whether a line is busy. One application of this service would be to ascertain whether a line may be out of service. call Establishing or attempting to establish communications using a telecommunications system or network. Call Detail Recording (CDR) A proprietary recording format produced by a Switching System. CDRs for switching systems in the U.S. Public Switched Telephone Network (PSTN) generally record CDRs using Billing AMA Format (BAF). Overseas, CDRs generally do not use BAF. call routing In circuit switching, determining the engineered path of a call from origination to destination. B 3

208 Notes on Billing Issue 1, May 2001 Glossary call type An indication of the type of service/technology provided to a customer or carrier for a particular call. All call types are identified by call type codes. Call Type Code (CTC) The Billing AMA Format (BAF) element generated by a switching system that identifies a particular service/technology provided to a customer or carrier for AMA recording purposes. The CTC in a BAF record provides guidance to accounting systems for processing the record. Call Type is also the name of a BAF field. called number The telephone number of the station to which a call terminated. Also called the terminating or to number. calling number The telephone number of the station from which a call originated. Also called the originating or from number. carrier Generally denotes a network transport provider that can be selected directly by the end user. Two major subdivisions of Carriers are Access Carriers (AC), which are inter-network carriers, and Local Exchange Carriers (LECs) which are intra-network carriers. ACs may be further subdivided into Interexchange (IC) and/or International Carriers (INC). ACs may utilize competitive local exchange carriers or competitive access providers to transport traffic from the LEC to their Point of Interconnection (POI). Carrier Access Code (CAC) A four digit Carrier Identification Code, preceded by the digits 101 (for FGD) or 950 (for FGB), that end users dial to select an interexchange carrier. Carrier Identification Code (CIC) A four digit code that uniquely identifies a telecommunications carrier within the North American Numbering Plan. The CIC is indicated by an XXXX in a Carrier Access Code where X can be any digit, 0 through 9. After an XXXX code has been assigned to a carrier, the code is retained for use by either Feature Groups B (950-XXXX) or D (101XXXX) throughout the area served by the North American Numbering Plan. See also Carrier Access Code. cause code A Signaling System 7 (SS7) parameter, typically found in a RELease message, that indicates the reason for the release of the call connection. Centralized Automatic Message Accounting (CAMA) An arrangement that enables an operator (or a computer) on a customer-dialed station-to-station call to secure a calling number from the customer and enter that number into the centralized accounting system. circuit-mode A type of communication in which certain network transmission resources are totally devoted to the served user for a prearranged or indefinite period. Common Channel Signaling (CCS) The method for providing call setup information in out-of-band communication pathways, rather than using the voice channel itself to carry signaling information (compare with Multifrequency (MF) signaling). A common channel may carry call setup B 4

209 Issue 1, May 2001 Notes on Billing Glossary information for many calls simultaneously. Today s CCS system is Signaling System Number 7 (SS7). common data fields An ordered set of eight data fields placed at the beginning of Billing AMA Format (BAF) records. Competitive Access Provider (CAP) A company that competes with a local exchange carrier to provide point-to-point special access-type services to interexchange carriers, large business customers, and government agencies. Such providers also can offer network management and network reconfiguration services. Connecting Network Access (CNA) A trunk type defined in the Number Portability generic requirements and used for local interconnection that provides Automatic Message Accounting (AMA) recordings for calls received from an interconnecting local network, for which no other AMA recording (e.g., Feature Group B, Feature Group D, Wireless Service Provider) would typically apply. Connecting Network Access record A recording designed to support call detail measurement of incoming calls from another network. This record may be generated for calls incoming to the intermediate or end office switch when no other terminating access record is generated (e.g., for calls incoming over traditional, non-equal access inter-office trunks). Country Code In terms of E.164, identifies the destination country and can vary between one and three digits. Data Message Handler (DMH) Recording format defined in EIA/TIA Interim Standard IS-124, Cellular Radio Telecommunication Intersystem Nonsignalling Data Communications Handler (DMH). Data Processing and Management System (DPMS) The system component that receives the Automatic Message Accounting (AMA) data transferred from Data Servers, processes these data, stores the data in files and (optionally) a database, and provides application systems with the desired AMA data. digital 1. A physical variable, such as sound or electrical current that is expressed in discrete steps. 2. In telecommunications, a category of devices or circuits in which the signal amplitude, frequency, or polarity varies in discrete steps. See analog. Digital Cross-connect System (DCS) A centrally controlled data-channel switching system that provides per-channel cross-connection and test access for digital signals terminating at various data rates. Examples include crossconnection of individual DS0 signals between DS1 streams, or of individual DS1 signals between DS3 streams. Unlike conventional voice switching systems, the digital cross-connect system does not make connections in response to an enduser call. Direct Inward Dialing (DID) DID Service allows callers to reach individual stations without the call going through a Private Branch Exchange (PBX) B 5

210 Notes on Billing Issue 1, May 2001 Glossary attendant. The call is routed to trunks that will route the call directly to the station. DID customers usually buy DID lines in blocks of telephone numbers. Directory Assistance (DA) A manual or automated service that provides customer directory listing information. Directory Number (DN) A telephone number. In the U.S., a number that conforms to the North American Numbering Plan (i.e., a number that is of the form NPA-NXX-XXXX). electronic bonding A a term used to describe electronic communication between telecommunications providers when each provider has an interface through which its service management applications communicate to others. Electronic Data Interchange (EDI) American National Standards Institute (ANSI) X.12 standard used to define the structure and content of business transactions for computer-to-computer interchange. end user A user of telecommunication services. equal access An exchange carrier service that gives a customer an equal choice of trunk-side access to public switched interexchange-carrier telephone networks in terms of such things as dialing plan and transmission quality. Equal Access End Office (EAEO) Refers to a Local Exchange Carrier (LEC) switching system which is equipped with presubscription capability for end users and capability to use either Multifrequency (MF) or Signaling System 7 (SS7) equal access signaling or both. exchange access Tariffed service offerings that provide switched and facilityoriented communications paths between a customer s (interexchange carrier or an end user) point of interconnection and the premises of its end users for the purpose of interexchange telecommunications. Exchange Message Interface (EMI) Industry format used to exchange incollect/outcollect data between carriers. facility (special) access A tariffed service of a Local Exchange Carrier (LEC) that provides a non-switched communications path between an access customer s point of termination and the premises of end users connected to the LEC network. The service includes all Local Access and Transport Area (LATA) access services that do not use an exchange-carrier switching system. fast select An X.25 facility that indicates an extended user data field is in use on some packet types, e.g., 128 octets in a call request packet. May also indicate restricted response. feature group Switched-access service offered by local exchange carriers to interexchange carriers. Feature Group A (FGA) A line-side connection associated with a local telephone number that provides interexchange carriers with both originating and terminating switched access interconnection to the local network. B 6

211 Issue 1, May 2001 Notes on Billing Glossary Feature Group B (FGB) A trunk-side connection associated with a uniform dialing code 950-XXXX, that provides interexchange carriers with both originating and terminating switched access interconnection to the local network. Feature Group D (FGD) A trunk-side connection associated with equal access signaling, 101XXXX dialing, and presubscription, that provides interexchange carriers with both originating and terminating switched access interconnection to the local network. Federal Communications Commission (FCC) The federal agency empowered by law to regulate all interstate radio and wireline communications services originating in the U.S., including radio, television, facsimile, telegraph, data transmission, and telephone systems. field A coded, logical group of data characters. The basic element of a Billing AMA Format (BAF) record. First In First Out (FIFO) The logical access procedure for sending Automatic Message Accounting (AMA) files from the AMA Transmitter (AMAT) to the Collector, assuring the oldest files are sent first to maintain sequences for AMA record streams. First Point of Switching (FPOS) The switching system that immediately interconnects with another switching system in another network. For exchange access services, the FPOS is the recording point for all terminating (incoming) calls. flat rate service A billing arrangement in which specific services are provided for a fixed monthly rate, independent of actual use. Frame Relay A high-speed, packet-switching technology that achieves greater throughput and delay performance than existing X.25 packet-switching networks, yet uses essentially the same hardware. Frame Relay dispenses with the overhead and error correction of X.25 to transmit at up to DS1 speeds. It assumes that errors will be few, and that those that do occur will be detected in the receiving equipment. Generating System/Data Server Interface (GDI) Interface used to transfer Automatic Message Accounting (AMA) records between the Data Server and a Generating System when they are not residing in the same platform. hexadecimal The coding of the unit digits 0-9 into the binary codes , with the remaining binary codes referred to as hex-a through hex- F. high runner Billing AMA Format (BAF) call type codes that record with short-format Structure Code (SC)s when certain conditions are satisfied. inband signaling Call control information uses the same analog, logical or assigned time slot channel as user information, and thus only one kind of information can be sent at a time. B 7

212 Notes on Billing Issue 1, May 2001 Glossary Initial Address Message (IAM) The first Integrated Services Digital Network User Part (ISUP) message that an originating switch sends in the setup of a call involving another switch. Integrated Services Digital Network (ISDN) A network architecture that enables end-to-end digital connections. The network supports diverse services through integrated access arrangements and defines a limited set of standard, multipurpose interfaces for equipment vendors, network providers, and customers. Interworking with a public switched telephone network is retained. Integrated Services Digital Network User Part (ISUP) The part of Signaling System 7 (SS7) that encompasses the signaling functions required to provide voice and non-voice services in ISDN and pre-isdn architectures. The basic service the ISUP offers is the control of circuit-switched connections between subscriber line exchange terminations. Intelligent Network (IN) A telecommunications network architecture in which processing capabilities for call control and related functions are distributed among specialized network nodes rather than concentrated in a switching system. interexchange Services and functions relating to telecommunication originating in a Local Access and Transport Area (LATA) and terminating elsewhere. Interexchange Carrier (IC) A carrier company in the U.S. that is engaged in the provision of interlata, interstate, and/or international telecommunications over its own transmission facilities or facilities provided by other interexchange carriers. intermediate switch A tandem switch. International Carrier (INC) A carrier that transports a call between a U.S. international operating center and a telephone administration in another country. Internet Protocol Data Record (IPDR) A recording format defined for creating usage measurements to support billing of IP services. internetwork call A call that traverses two or more networks. Interexchange calls are often both internetwork calls and InterLATA calls. interworking The capabilities needed to connect a call among networks without the same transmission or signaling capabilities. Also, communication between dissimilar components, such as inband Multifrequency signaling and out-of-band Signaling System 7 (SS7) for call setup. intranetwork call A call handled within a single Local Exchange Carrier (LEC) network. Usually a LEC network is Local Access and Transport Area (LATA)-wide; in such cases, intranetwork is equivalent to intralata. ITU-T Recommendation E.164 The document that defines the currently-used and future structure of an international telephone number. B 8

213 Issue 1, May 2001 Notes on Billing Glossary ITU-T Recommendation X.121 The document that contains the International Numbering Plan for Public Data Networks (PDNs). junctor Any service circuit internal to a switching system that is used for a special-purpose function, such as coin control. In three-stage switching, the internal, or middle switched link connection between incoming and outgoing frames. Jurisdiction Information Parameter (JIP) An Integrated Services Digital Network User Part (ISUP) parameter containing an NPA-NXX representative of the switch from which a call (or call leg) has originated. Wireline service providers generally populate the JIP with a value taken from a Location Routing Number (LRN) (i.e., its first six digits) associated with that switch. Wireless service providers often populate the JIP to identify the jurisdiction of the mobile switch of call origination. Population of this parameter is not consistent between wireline and wireless carriers. Line Information Database (LIDB) A database of information about individual Directory Numbers (DNs), used to provide services such as calling card authorization and originating line number screening, as well as determination of an end user s local service provider for routing to proper service agents. line-side connection A connection of a transmission path to the side of a local exchange switching system that provides dial-tone and ringing connections. Link Monitoring System (LMS) A non-intrusive monitoring system that attaches to the link sets of a Signaling System 7 (SS7) network and monitors the bit streams carried in both directions. The monitoring system has the capability to generate usage measurements on the data it monitors. Local Access and Transport Area (LATA) An area in which a Local Exchange Carrier (LEC) is permitted to provide service. A defined geographic area that contains one or more local exchange areas, usually serving areas with common social, economic, or other interests. Local Area Network (LAN) A network for connectivity between systems within a small geographic location like a building or campus. Local Exchange Carrier (LEC) A telecommunications company that provides local service. Local Service Request (LSR) An order from one local telecommunications company or end user for interconnection services from another local telecommunications company. location portability Allows the end-user to retain the same Directory Number (DN) when changing geographical locations outside of the rate center in which the DN was originally assigned. Location Routing Number (LRN) A 10-digit number, in the format NPA- NXX-XXXX. The first 6 digits of the LRN identify the switch. B 9

214 Notes on Billing Issue 1, May 2001 Glossary measured rate service A usage-sensitive telephone service for which a customer pays a reduced monthly charge in exchange for a set amount of service. Usage beyond the set amount is billed at a specified rate. Also called measured local service. Message Billing Index (MBI) A data field that identifies services, such as local measured services. The specification for each MBI value is administered by each Local Exchange Carrier (LEC) according to its internal procedures. Message Transfer Part (MTP) The lowest level in the Signaling System 7 (SS7) protocol hierarchy that serves as a reliable transport system between two signaling points. The MTP includes functions equivalent to the physical, link, and network layers of the Open Systems Interconnection (OSI) Reference Model. Minutes of Use (MOU) In the access service tariffs, the unit for measuring and billing traffic-sensitive equipment and facilities. module A predefined set of data fields that may be appended to a structure according to the service/technology rendered or to report information connected with specific conditions. The set is identified by a module code, which is contained in the Module Code Field. Multifrequency (MF) The transmission of address signals at voice frequencies. Ten decimal digits and five auxiliary signals are each represented by two of the following frequencies: 700, 900, 1100, 1300, 1500, and 1700 hertz. Multifrequency pulsing is used for interoffice signaling and requires a separate supervisory signaling system. N11 codes NXX Codes used to provide three-digit dialing access to special services. network configuration A particular network arrangement, such as single tandem or originating-sector tandem. network management A set of procedures, equipment, and operations that keep a traffic network operating near maximum efficiency despite unusual loads or equipment failures. Next Generation Network (NGN) The convergence of multiple independent networks into a single, unified broadband network. The NGN is designed to integrate voice and data services over high-capacity, high-speed facilities. Non-Call-Associated Signaling (NCAS) Signaling messages associated with network functions other than call setup (e.g., CLASS messages). North American Numbering Council (NANC) Committee operating under the auspices of the Federal Communications Commission (FCC), to provide advice to the FCC on numbering policy. Author of the process flows that govern intercarrier communications for Number Portability order processing. B 10

215 Issue 1, May 2001 Notes on Billing Glossary North American Numbering Plan (NANP) Method for describing valid Directory Numbers (DNs) in the U.S. and Canada. Numbers in the NANP are of the form NPA-NXX-XXXX, where N is a digit from 2 through 9, and other digits range from 0 through 9. Number Portability Database (NPDB) An application that is usually housed at the Service Control Point (SCP) that responds to Number Portability queries with data about the customer s ported service. Number Portability information associated with a ported Directory Number (DN) that Automatic Message Accounting (AMA) recording uses to identify the Recipient Switch (e.g., the switch s Location Routing Number (LRN)) of the ported DN to assist in billing. Number Portability (NP) query A request for call routing information sent from the switch to the Number Portability Database (NPDB) when a call encounters an NP trigger. Numbering Plan Area (NPA) The first three digits of a telephone number. Also known as an area code. NXX Code A numeric identification code that represents groups of up to 10,000 Directory Numbers (DNs) in a central office. 2. Loosely, any central office code. NXX codes are assigned to identify local central offices and are used for routing and billing purposes. N represents any number from 2 through 9 and X any number from 0 to 9. off-hook A signal used on lines and trunks to indicate in-use or request-forservice states. The off-hook signal is generated when a receiver or handset is removed from its hook, thus closing a switch that enables current to flow in a loop. The current signals a central office that service is requested. on-hook A signal used to indicate that a line or trunk is not currently in use and is available for service. The signal is transmitted to a central office by replacing the receiver on its hook. When a receiver or handset is replaced in its hook, the current flow on the loop stops, which signals the central office to initiate the tear-down of the call. Operations Support Systems (OSS) General-purpose software systems that support the operations of a telecommunications company. Operations supported include planning, engineering, ordering, inventory tracking, automated designs, provisioning, assignment, installation, maintenance, and testing. The billing system is also considered in some contexts to be an OSS. Operator Number Identification (ONI) The manual identification of the calling number of a customer-dialed toll call and its entry by an operator onto an Automatic Message Accounting (AMA) tape for billing. Operator Services System (OSS) A specialized operator access system for customer direct-dialed special toll calls, such as person-to-person, collect, credit-card, charge-to-third-number, and coin distance dialing. Service desks and their operators are used for any special handling of the calls, e.g., B 11

216 Notes on Billing Issue 1, May 2001 Glossary identification of the person called, or the third number to which the call is charged. originating direction The use of access service for the origination of calls from an end-user location to an access-customer location, such as an Interexchange Carrier or International Carrier (IC/INC) Point of Presence (POP). originating LNP module A Local Number Portability (LNP) module that contains Number Portability information for an originating party. originating switch The switch serving the calling party. out-of-band signaling Call control information uses different analog, logical or assigned time slot channels than user information, and thus both kinds of information can be sent simultaneously. Outward Wide Area Telecommunications Service (OUTWATS) A Wide Area Telecommunications Service that permits customers to make high-volume long-distance calls within designated geographic areas. The calls are bulk billed rather than individually billed. overflow A measure of the number of attempts that fail to find an idle circuit in a particular circuit group. Overflow calls can be completed on an alternate trunk group or can be blocked. packet-mode A type of communication in which certain network transmission resources are available to a served user on a statistical basis. A group of bits is sent as an integral unit and may be subject to delays. parameters Specific units of information contained within a message. permanent virtual circuit For Integrated Services Digital Network (ISDN), an X.25 virtual connection maintained between two endpoints for a period of time to be determined by the user and the administration of that network. Permanent Virtual Connection (PVC) In Asynchronous Transfer Mode (ATM) switches, a virtual connection permanently established over the entire path of the connection (i.e., between two endpoints from end user to end user) for a period of time to be determined by the user and the administration of that network. PIC Generically denotes the Presubscribed Interexchange Carrier of the end user. PIC1 Denotes the Carrier presubscribed to transport the end users switched access interlata toll traffic. PIC2 Denotes the Carrier presubscribed to transport the end users switched access intralata toll traffic. Point of Interconnection (POI) The point within a Local Access and Transport Area (LATA) at which one carrier s responsibility for a particular service ends and another carrier s responsibility for that same service begins. B 12

217 Issue 1, May 2001 Notes on Billing Glossary For example, the point where a Local Exchange Carrier s responsibility for access service ends and an Interexchange Carrier s responsibility begins. Point of Presence (POP) A physical location established by an Interexchange Carrier (IC) within a Local Access and Transport Area (LATA) for the purpose of gaining LATA access. The POP is usually a building that houses switching and/or transmission equipment, as well as the point of termination. portable NPA-NXX An NPA-NXX designated as open for portability. No numbers may have actually ported. Primary (or Presubscribed) Interexchange Carrier (PIC) The long distance carrier designated by a subscriber to provide interlata and international service automatically, that is, without the need for a carrier access code. Similar terms are primary interlata carrier and principal interlata carrier. Primary Rate Interface (PRI) In an Integrated Services Digital Network (ISDN), a DS1 channel that provides digital transmission capacity of up to megabits per second (1.984 Mbps in Europe) in each direction. The interface supports combinations of one 64-kbps D channel (for signaling) and up to twenty-three (23) 64-kbps B channels. Thus, ISDN PRI provides for 23B+D or Mbps of user information in each direction. Private Branch Exchange (PBX) A private switching system, usually located on a customer s premises. rate adaption The conversion by user equipment of low-speed data to the 64- kbps transmission rate offered by the network, using a standard procedure. rate center A rate center denotes a geographic area used to distinguish rate boundaries. {Note: In this document rate center denotes the smallest geographic area used to distinguish rate boundaries. In other contexts, rate centers may contain even smaller geographic areas used for rating (e.g., rate districts, wire centers, rate areas).] Record Descriptor Word (RDW) A Billing AMA Format (BAF) field that provides the total number of octets in the record. Revenue Accounting Office (RAO) The customer billing/invoicing center. route 1. A set of interconnected channels used to establish the path for a call. 2. A path taken by a feeder cable from a central office to the point where it connects with a distribution cable, or a comparable path taken by interoffice facilities. Sending Unit (SUN) A SUN is contained within an AMA Transmitter (AMAT) and associated with an Automatic Message Accounting (AMA) generating source such as a network element or subsystem. Service Access Code (SAC) A three-digit, non-geographic code that is assigned for access to interexchange or local exchange carrier services. Codes B 13

218 Notes on Billing Issue 1, May 2001 Glossary currently in use include 700 (for interexchange carrier services), 8YY (Toll-Free Number Service), 500 Service, and 900 service. Service Control Point (SCP) Remote databases within the Signaling System 7 (SS7) network that store service logic capable of providing translation and routing data needed to support Advanced Intelligent Network (AIN) services. Service Switching Point (SSP) In an Intelligent Network, a stored-programcontrolled switching system that has the functional capability to temporarily suspend call processing to launch queries to remote databases (Service Control Points (SCPs)) that provide additional service logic. SCP databases are accessed by the SSP in providing database query-oriented services such as the toll-free service and Advanced Intelligent Network (AIN) Services. Serving Wire Center (SWC) The Local Exchange Carrier (LEC) location (usually a central office) that connects with the facilities serving an access customer location. short format structure A Billing AMA Format (BAF) structure that omits certain data fields that are not required when certain conditions apply. The data fields are Timing Indicator (BAF Table 7), Study Indicator (BAF Table 8), Service Observed/Traffic Sampled (BAF Table 10), and Operator Action (BAF Table 11). Only BAF records for calls in which these fields would be zero can be shortened. Signal Transfer Point (STP) In a Common Channel Signaling (CCS) network, a packet switch that uses the Signaling System 7 (SS7) protocol to connect signaling links to network switching systems and other STPs. signaling The transmission of address, supervision, or other switching information between stations and switching systems and between switching systems to establish, monitor, or release connections, provide network control, and support internal operations. signaling capability One of several capabilities, integral to the access protocol, that give the user greater control over call establishment. Signaling Connection Control Part (SCCP) Part of the Signaling System 7 (SS7) protocol residing between the Message Transfer Part (MTP) and Transaction Capabilities Application Part (TCAP) that provides communication between signaling nodes by adding circuit and routing information to the signaling message. Signaling System 7 (SS7) An American National Standards Institute (ANSI) standard protocol that service provider networks deploy to support out-of-band Common Channel Signaling (CCS) architectures. The protocol divides signaling specifications into the Message Transfer Part (MTP), the Signaling Connection Control Part (SCCP), the Integrated Services Digital Network User Part (ISUP), the Operations and Maintenance Application Part, the Application Service Part, and the Transaction Capabilities Application Part (TCAP). B 14

219 Issue 1, May 2001 Notes on Billing Glossary Soft Permanent Virtual Connection (SPVC) A Permanent Virtual Connection (PVC) for which the segment of the connection between the broadband switches serving each end user is switched in nature, and the segments of the connection between the end broadband switches and the end users they serve are permanently established. Special Processing Module (SPM) An AMA Data Networking System (AMADNS) component (e.g., Data Processing and Management System (DPMS) or Data Server) that enables Automatic Message Accounting (AMA) records to be processed in a desired fashion. Specific_Digit_String (SDS) trigger An Advanced Intelligent Network (AIN) trigger. A mechanism for deciding whether to launch a query to an AIN Service Control Point (SCP) based on comparing some or all of the digits of the called number with a predefined digit string. A query is launched when the first N (N may range from three through ten) digits of the called number match the trigger s target digit string. Station Message Detail Recording (SMDR) A feature of a Centrex, Private Branch Exchange (PBX), or electronic-key system that generates a chronological listing of every call leaving the system. structure A predefined, ordered set of data fields identified by a Structure Code (SC). The set consists of eight common data fields followed by a group of fields that depend on the type of service/technology for which the data is recorded. Two or more modules may be appended to a structure. Structure Code (SC) A Billing AMA Format (BAF) field that indicates whether modules are appended to the structure, and identifies the ordered list of fields in the structure. A five-digit number that identifies a particular Automatic Message Accounting (AMA) record structure. Subscriber Line Usage Study (SLUS) A study performed in a switching system that generates data that portrays the calling patterns and service usage of customer lines. supplementary service An optional call management capability in addition to the basic capability of establishing a call between two users. switched access A tariffed service of a Local Exchange Carrier (LEC) that provides a switched communications path between an access customer s point of termination and the premises of end users connected to the LEC network. Switched Multi-Megabit Data Service (SMDS) A high-speed data transport service by which public networks can transport information quickly across areas wider than those served by local-area networks. Typically, such a network would serve a metropolitan area. Switched Virtual Connection (SVC) In an Asynchronous Transfer Mode (ATM) switch, on-demand connections based on standard signaling protocols over the User-Network Interface (UNI) and the intra-network interswitch interface. B 15

220 Notes on Billing Issue 1, May 2001 Glossary table Synonym for Billing AMA Format (BAF) data field. It refers to the documentation of a field in a table in Telcordia requirements documents such as GR-1100-CORE. tandem In a message network, a switching system that establishes trunk-totrunk connections but has no subscriber lines connected to it. Tandem types include local tandems, Local Access and Transport Area (LATA) tandems, or access tandems. Telecommunications Act of 1996 (TA96) Legislation that the U.S. government created, intended to provide increased competition in the telecommunications industry. terminating direction The use of access service for the completion of calls from an access-customer location, such as an Interexchange Carrier terminal, to an end-user location. terminating LNP module A Local Number Portability (LNP) module that contains Number Portability information for a terminating party. terminating switch The switch serving the called party. toll-free service A toll-free Wide Area Telecommunications Service (WATS) that provides exchange and exchange-access service to callers located in service areas for which the Toll-Free Service subscriber has paid. toll-free service access codes A non-geographic Numbering Plan Area (NPA) code that indicates that a called party, rather than a calling party, will be charged for a call. Available codes are designated as 8YY codes and currently include 800, 888, 877, and 866 with plans to open other 8YY codes in the future. Transaction Capabilities Application Part (TCAP) The highest layer in the Signaling System 7 (SS7) protocol suite. Transaction Capabilities in the SS7 protocol are functions that control non-circuit related information transferred between two or more signaling nodes. translations In switching systems, the conversion of all or part of a telephone address destination code (dialed digits) to routing instructions or routing digits. trunk A single transmission path connecting two switching systems. Trunks can be shared by many users but serve one call at a time. trunk group A number of trunks that can be used interchangeably between two switching systems. trunk-side connection The connection of a transmission path to the trunk side of a local switching system. usage-sensitive Rate setting based on actual usage of the telephony network by a customer. Usage is measured on the basis of frequency, duration, distance, and time of day and/or day of week, and may be billed in any combination. Vertical and Horizontal (V&H) coordinates A numerical method of determining airline mileage between locations. Geographic locations of rate B 16

221 Issue 1, May 2001 Notes on Billing Glossary centers are expressed in V&H coordinates; this mapping forms the basis of typical residential customer billing tariffs. Geographic locations of wire centers are also expressed in V&H coordinates; this mapping forms the basis of typical access billing tariffs. virtual call A call in which packet-mode transmission, i.e., a switched virtual circuit, is used. Wide Area Network (WAN) A network capable of transporting data over distances greater than a few kilometers. Examples of WANs include Asynchronous Transfer Mode (ATM) networks and Public Packet Switched Networks (PPSNs). Wide Area Telecommunications Service (WATS) A bulk-billed service for customers who make or receive many long-distance calls. wideband communications Voice, data, or video communications at digital rates from 64- to 1544-kbps per second. wink-start pulsing A method of pulsing control and of checking trunk integrity in which the transmission of address pulses is delayed until a sender receives a momentary off-hook signal from the far-end of a connection. Wireless Services Provider (WSP) A carrier who is authorized to provide wireless communications exchange services. Examples of a WSP include, but are not limited to, cellular carriers, paging service providers, and personal communications services (PCS) carriers. work order A detailed drawing or print that indicates the addition, removal, or rearrangement of outside plant. B 17

222 Notes on Billing Issue 1, May 2001 Glossary B 18

223 Issue 1, May 2001 Notes on Billing Acronyms Appendix C: Acronyms ABS Alternate Billing Services ACM Address Complete Message ACO Additional Call Offering ACSC Access Customer Service Center AFR Automatic Flexible Routing AIN Advanced Intelligent Network AMA Automatic Message Accounting AMACC AMA Control Center AMADNS AMA Data Networking System AMAT AMA Transmitter AMATPS AMA Teleprocessing System ANI Automatic Number Identification ANM Answer Message ANSI American National Standards Institute AO Account Owner ASCII American Standard Code for Information Interchange ASN.1 Abstract Syntax Notation One AT Access Tandem ATM Asynchronous Transfer Mode BAF Billing AMA Format BBG-I Basic Business Group ISDN BCD Binary Coded Decimal BDT Billing Data Tape BDW Block Descriptor Word BLV Busy Line Verification BNS Billed Number Screening BRI Basic Rate Interface BSC Business Service Center BSP Billing Service Provider BSS Broadband Switching System CABS Carrier Access Billing System CABS/BOS Carrier Access Billing System / Billing Output Specifications CAC Carrier Access Code CAMA Centralized Automatic Message Accounting CAP Competitive Access Provider CC Country Code / Calling Card CCS Common Channel Signaling CCT Carrier Connect Time CDR Call Detail Record CIC Carrier Identification Code CIP Carrier Identification Parameter CLEC Competitive Local Exchange Carrier CMD Circuit-Mode Data CNA Connecting Network Access CND Calling Number Delivery CNI Calling Number Identification CNM Customer Network Management CO Central Office CPE Customer Premises Equipment CPN Calling Party Number C 1

224 Notes on Billing Issue 1, May 2001 Acronyms CPSA Calling Party Subaddress CPU Central Processing Unit / Call Pickup CSR Customer Service Record CT (Bearer) Call Type CTC Call Type Code CXC Call-by-Call DA Directory Assistance DASE Daily Aggregate Service Events DCE Data Circuit Terminating Equipment DCS Digital Cross-Connect Switch DDD Direct Distance Dialing DDI Data Server/DPMS Interface DES Data Encryption Standard DID Direct Inward Dialing DMH Data Message Handler DN Directory Number DP Dial Pulse / Detection Point DPMS Data Processing and Management System DPN Directed Call Pickup Nonbarge-in DPU Directed Call Pickup Barge-in DS0 Digital Signal (level 0-64-kbps) DS1 Digital Signal (level Mbps) DS3 Digital Signal (level Mbps) EA Equal Access EAEO Equal Access End Office EBAC Equipment and Billing Accuracy Control EBCDIC Extended Binary Coded Decimal Interchange Code EC Exchange Carrier ECT Early Cut-Through EDI Electronic Data Interchange EF Entrance Facilities EKTS Electronic Key Telephone Service EMI Exchange Message Interface EO End Office EXM Exit Message FG Feature Group FGA Feature Group A FGASO Feature Group A Serving Office FGB Feature Group B FGD Feature Group D FID Field Identifier (Service Orders) FIFO First In-First Out FN Forwarding Number FPOS First Point of Switching FR Family of Requirements FRS Frame Relay Service FSD Feature Specific Document FTP File Transfer Protocol FX Foreign Exchange GDI Generating System/Data Server Interface GN Generic Name GR Generic Requirements I-ACB ISDN Automatic Callback IAM Initial Address Message I-AR ISDN Automatic Recall C 2

225 Issue 1, May 2001 Notes on Billing Acronyms IC Interexchange Carrier ICI Inter-Carrier Interface ICMP Internet Control Message Protocol ICO Independent Company IDDD International Direct Distance Dialing IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force ILEC Incumbent Local Exchange Carrier IN Intelligent Network INC International Carrier IP Internet Protocol / Information Provider IPDR Internet Protocol Data Record ISDN Integrated Services Digital Network ISO International Organization for Standardization ISUP Integrated Services Digital Network User Part ITP IntraLATA Toll Presubscription JIP Jurisdiction Information Parameter KP Key Pulse L3_PDU Level 3 Protocol Data Unit LAMA Local AMA recording LAN Local Area Network LAP B Link Access Protocol on an X.25 Access LAP D Link Access Protocol on D channel LATA Local Access and Transport Area LDC Long Duration Call LDS Logical Data Set LEC Local Exchange Carrier LIDB Line Information Database LMS Link Monitoring System LNP Local Number Portability LRN Location Routing Number LSPI Local Service Provider Identification LSSGR LATA Switching Systems Generic Requirements MBG Multiswitch Business Group MBI Message Billing Index MDR Message Detail Recording MF Multi-frequency [signaling] MIB Management Information Base MOU Minutes of Use MSR Message Storage and Retrieval MTP Message Transfer Part MTS Message Telephone Service MWI Message Waiting Indicator NANC North American Numbering Council NANP North American Numbering Plan NCAS Non-Call Associated Signaling ND Number Delivery NDUB Network-Defined User Busy NGN Next Generation Network C 3

226 Notes on Billing Issue 1, May 2001 Acronyms NNI Network-Network Interface NP Number Portability / Number Privacy NPA Numbering Plan Area NPAC Number Portability Administration Center NPDB Number Portability Database N(S)N National (Significant) Number NUI Network User Identification NVT Network Virtual Terminal OBF Ordering and Billing Forum OCM Originating Call Model (AIN) OHD Off_Hook_Delay trigger OLIP Originating Line Information parameter (SS7) OLNS Originating Line Number Screening OSI Open Systems Interconnection OSS Operator Services System / Operations Support System OTGR Operations Technology Generic Requirements PBX Private Branch Exchange PCM Pulse Code Modulation PDM Packet Data Mode PDU Protocol Data Unit PIC Primary (Presubscribed) Interexchange Carrier PLP Packet Layer Protocol PNNI Private Network-Network Interface PNR Private Number Rejection POI Point of Interface POP Point of Presence PPSN Public Packet Switched Network PRI Primary Rate Interface PSDS Public Switched Digital Service PSTN Public Switched Telephone Network PVC Permanent Virtual Circuit / Permanent Virtual Connection PVN Private Virtual Network QO Query Originator RAO Revenue Accounting Office REL Release message RLC Release Complete message RPOA Registered Private Operating Agency RPSA Redirecting Party Subaddress RQGR Reliability and Quality Generic Requirements RQSSGR Reliability and Quality Switching Systems Generic Requirements RSC Residence Service Center RTP Release to Pivot SAC Service Access Code SC Structure Code SCCP Signaling Connection Control Part SCF Selective Call Forwarding SCM Selective Call Management SCP Service Control Point SDS Specific_Digit_String SFG Simulated Facility Group C 4

227 Issue 1, May 2001 Notes on Billing Acronyms SIP Simple Internet Protocol / SMDS Interface Protocol SLE Screening List Editing SMDS Switched Multi-Megabit Data Service SMI Structure of Management Information SMMCI System Manager/Managed Component Interface SMS Service Management System SNI Subscriber Network Interface SNMP Simple Network Management Protocol SONET Synchronous Optical Network SPI Security Parameter Index SPM Special Processing Module SPVC Switched Permanent Virtual Connection SQL Structured Query Language SR Service Requestor / Special Report SS7 Signaling System Number 7 SSGR Supplier Support Generic Requirements SSN Subsystem Number SSP Service Switching Point ST Start Pulse STP Signal Transfer Point SUN Sending Unit SVC Switched Virtual Circuit / Switched Virtual Connection SWC Serving Wire Center TA Technical Advisory TAT Termination Attempt Trigger TCAP Transaction Capabilities Application Part TCM Terminating Call Model TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol TG Trunk Group TGN Trunk Group Number TNN Trunk Network Number TNS Transit Network Selection TP4 Transport Protocol Class 4 TR Technical Reference TSP Tandem Switching Provider UDP User Datagram Protocol UNI User Network Interface USOC Universal Service Order Code UUS User-to-User Signaling VBD Voiceband Data VMS Voice Messaging System V&H Vertical and Horizontal coordinates WAN Wide Area Network WATS Wide Area Telecommunications Service WSP Wireless Services Provider C 5

228 Notes on Billing Issue 1, May 2001 Acronyms C 6

229 Enterprise License Agreement For Telcordia Technical Documents consisting of Generic Requirements (GRs), Special Reports (SRs), Technical References (TRs), Technical Advisories (TAs), Family of Requirements (FRs), Family of Documents (FDs) (collectively Licensed Product(s) ) IMPORTANT! PLEASE READ CAREFULLY. USE OF THIS LICENSED PRODUCT INDICATES THAT YOU ( LICENSEE ) HAVE READ AND ACCEPT THE TERMS OF THIS AGREEMENT. 1. LICENSE GRANT Ericsson Inc. ( Ericsson ) grants to Licensee under this Enterprise License Agreement ( Agreement ) a personal, non-exclusive, non-transferable, limited license to use this Licensed Product by employees of Licensee for internal business purposes only. All intellectual property rights, title and interest in all Licensed Product(s) furnished to Licensee remain in Ericsson. This License does not preclude the execution of additional license agreements with Licensee for the Licensed Product(s). Ericsson has exclusive rights to all Licensed Product(s) which are protected by United States and international copyright laws. 2. LICENSEE'S USE: a) Licensee may place the Licensed Product(s) on a server, internal web site, or other electronic computing platform shared or accessible to employees or affiliates of Licensee. Licensee may make paper and electronic copies of Licensed Product(s) as determined by Licensee to be necessary for Licensee s internal purposes; provided all copies of the Licensed Product(s) shall bear the same copyright and disclaimer notices legend as appear on the Licensed Product(s) originally furnished to Licensee by Ericsson. b) Subject to the preceding paragraph, and conditioned upon Licensee sublicensing the rights as set forth herein, Licensee may reproduce and distribute Licensed Product(s) to Affiliates defined as (i) the parent entity (corporation or partnership) which directly or indirectly owns the majority of the outstanding shares or interests of Licensee, (ii) a sibling entity (corporation or partnership) the majority of whose outstanding shares or interests are owned by its parent entity, or (iii) a subsidiary entity (corporation or partnership) the majority of whose outstanding shares or interests are owned by Licensee, provided, however, that such entity shall continue to remain an Affiliate hereunder only as long as the applicable ownership interest as described above exists. Licensee may sublicense the rights granted in this section to an Affiliate, provided Licensee shall remain responsible for any breach by such Affiliate. Licensee shall ensure that such Affiliate agrees to be bound by the rights, obligations and limitations set forth herein, and Licensee shall ensure that Ericsson shall have the right of direct enforcement of such obligations against such Affiliate. If a direct enforcement claim is denied, for any reason, it is agreed that Ericsson may assert such claim against Licensee. c) Licensee must treat the Licensed Product(s) like any other copyrighted material. d) Licensee may make reference to the Licensed Products in creating specifications and related documentation (the Licensee Documentation ). e) Licensee may, in marketing or in conjunction with the sale of a product or related services (collectively, Licensee Product ), make reference to the Licensed Product utilized in the development of Licensee Product; provided that Licensee shall make no statement, representation or warranty on behalf of Ericsson, including but not limited to, a certification by Ericsson of a product s or related service s compliance with the Licensed Product, unless otherwise agreed to by the parties in writing.