telcordia notes on operator services

Telcordia Notes on Operator Services(A Module of FD-NOTES-SERIES-1)

An SAIC Company

Telcordia Technologies Special ReportSR-NOTES-SERIES-18Issue 1, May 2002

Telcordia Notes on Operator Services Issue 1, May 2002Copyright Page

SR-NOTES-SERIES-18

Telcordia Notes on Operator Services

Prepared for Telcordia Technologies by: Professional Services

Related documents: SR-2275 and the Telcordia SR-NOTES-SERIES; both of which are now packaged together in FD-NOTES-SERIES-1.

Technical contacts: Renee Berkowitz and Loren Lewin, Senior Consultants

To obtain copies of this document, contact your company’s document coordinator or your Telcordia account manager, or call 1.800.521.2673 (USA and Canada) or +1.732.699-5800 (Worldwide), or visit our Web site at http://telecom-info.telcordia.com/. Telcordia employees should call +1.732.699.5802.

Copyright © 2002 Telcordia Technologies, Inc. All rights reserved.

Trademark Acknowledgments

Telcordia is a trademark of Telcordia Technologies, Inc.AXESS is a service mark of Telcordia Technologies, Inc.All other trademarks in this document are the property of their respective companies.

ii

Issue 1, May 2002 Telcordia Notes on Operator Services Special Report Notice of Disclaimer

SR-NOTES-SERIES-18

Special Report Notice of Disclaimer

This Special Report (SR) is published by Telcordia Technologies to inform the industry of Telcordia Notes on Operator Services. Telcordia reserves the right to revise this document for any reason (consistent with applicable provisions of the Telecommunications Act of 1996 and applicable FCC rules).

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,

APPROVAL, CERTIFICATION, WARRANTY, GUARANTY, OR

ENDORSEMENT TO ANYONE.

iii

Telcordia Notes on Operator Services Issue 1, May 2002Special Report Notice of Disclaimer

SR-NOTES-SERIES-18

If further information regarding technical content is required, please contact:

Renee Berkowitz, Senior Consultant331 Newman Springs Road, Rm 3E-208Red Bank, NJ 07701-5699Phone: + 1.732.758.5596Fax: + [email protected]

For general information about this or any other Telcordia documents, please contact:

Telcordia Technologies Customer Service8 Corporate Place, Room 3A-184Piscataway, NJ 08854-41561.800.521.2673 (USA and Canada)+ 1.732.699.5800 (Worldwide)+ 1.732.336.2559 (FAX)http://telecom-info.telcordia.com/ (on-line)

iv

Issue 1, May 2002 Telcordia Notes on Operator ServicesContents

SR-NOTES-SERIES-18

Contents

1 Introduction

1.1 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–11.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–21.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4

2 Current Operator Services System Environment

2.1 Current LEC Operator Services . . . . . . . . . . . . . . . . . . . . . . . . . . 2–32.1.1 Call Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–42.1.2 Listing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–42.1.3 Toll and Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6

2.1.3.1 Alternate Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–62.1.3.2 Alternate Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–82.1.3.3 General Assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–82.1.3.4 Special Needs (1+) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–92.1.3.5 0- Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–112.1.3.6 Busy Line Verification/Interrupt . . . . . . . . . . . . . . . . . . . . 2–11

2.1.4 Intercept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–122.2 Current Dialing Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14

2.2.1 0- Dialing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–162.2.2 0+ DIaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–162.2.3 1+intraLATA DIaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–17

2.3 Current Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–182.3.1 General OSS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18

2.3.1.1 OSS Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–202.3.1.2 OSS Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–222.3.1.3 Voice Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–292.3.1.4 Operator Workstations . . . . . . . . . . . . . . . . . . . . . . . . . 2–312.3.1.5 Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 2–31

2.3.2 AIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–322.4 Current Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–35

2.4.1 Speech Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–352.4.2 LNP and Resale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36

2.4.2.1 Local Number Portability (LNP) . . . . . . . . . . . . . . . . . . . . 2–362.4.2.2 Resale: OSS Identification of Originating and Billed Lines’ Local

Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–392.4.3 Operator System Hold, Ringback, Recall . . . . . . . . . . . . . . . . . . 2–412.4.4 Coin Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–42

2.4.4.1 Inband Coin Control Signals . . . . . . . . . . . . . . . . . . . . . . 2–422.4.4.2 Inband Coin Control Ringback Protocol . . . . . . . . . . . . . . . 2–432.4.4.3 Multiwink Coin Control . . . . . . . . . . . . . . . . . . . . . . . . 2–432.4.4.4 EIS Coin Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–44

2.4.5 Release Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–452.4.5.1 Generic Release-to-Pivot Capability . . . . . . . . . . . . . . . . . . 2–45

v

Telcordia Notes on Operator Services Issue 1, May 2002Contents

SR-NOTES-SERIES-18

2.4.5.2 Nortel Networks DMS TOPS Release Link Trunking . . . . . . . . 2–472.5 Example Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–48

2.5.1 Partially Automated DACC . . . . . . . . . . . . . . . . . . . . . . . . . . 2–482.5.2 Fully Automated Collect Call with Call Completion and a Ported Called

Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–492.6 Signaling to and from LEC OSS Switches . . . . . . . . . . . . . . . . . . . . . 2–52

2.6.1 LEC End Offices to LEC OSS switches . . . . . . . . . . . . . . . . . . . 2–522.6.1.1 Original OS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 2–562.6.1.2 Pre-EAOSS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 2–612.6.1.3 MF EAOSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–642.6.1.4 Basic SS7 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–692.6.1.5 Operator Services SS7 Signaling . . . . . . . . . . . . . . . . . . . . 2–73

2.6.2 Wireless: MSC to LEC OSS Switch . . . . . . . . . . . . . . . . . . . . . . 2–742.6.2.1 MF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–752.6.2.2 SS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–76

2.6.3 LEC OSS Switch to IC Operator System . . . . . . . . . . . . . . . . . . 2–762.6.4 LEC OSS Switch to LEC OSS Switch . . . . . . . . . . . . . . . . . . . . 2–762.6.5 LEC OSS Switch to LEC End Office . . . . . . . . . . . . . . . . . . . . . 2–772.6.6 Wireless: LEC OSS Switch to MSC . . . . . . . . . . . . . . . . . . . . . . 2–77

2.7 Automatic Message Accounting (AMA) . . . . . . . . . . . . . . . . . . . . . . 2–782.8 Force Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–87

3 Operator Services Evolution

3.1 Technology Advancements Desired for Operator Services . . . . . . . . . . . 3–33.1.1 Queuing and Call Distribution . . . . . . . . . . . . . . . . . . . . . . . . 3–33.1.2 Operator Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–43.1.3 Operator Services-Specific Functions - Service Creation Capabilities . . 3–53.1.4 Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–53.1.5 Voice Server Functions - Speech Technology . . . . . . . . . . . . . . . 3–63.1.6 Administrative Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–63.1.7 Multi-Mode Delivery of Information . . . . . . . . . . . . . . . . . . . . . 3–73.1.8 Multi-Media Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–7

3.2 Generic NGN Operator Services Architecture . . . . . . . . . . . . . . . . . . 3–83.2.1 Functional Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–11

3.3 Migration of Existing OSS Technology . . . . . . . . . . . . . . . . . . . . . . 3–17

4 Summary

Appendix A: Bibliography and References

Appendix B: Acronyms

vi

Issue 1, May 2002 Telcordia Notes on Operator ServicesList of Figures

SR-NOTES-SERIES-18

List of Figures

Figure 2-1 OSS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–19Figure 2-2 Nortel Networks Architecture for Operator Centralization . . . . . 2–22Figure 2-3 AIN Architecture for 0- Automation . . . . . . . . . . . . . . . . . . 2–33Figure 2-4 Message Flow for DACC using RTP . . . . . . . . . . . . . . . . . . 2–46Figure 2-5 Example Architecture Components for Partially Automated

DACC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–48Figure 2-6 Architecture Components for Fully Automated Collect Call . . . . 2–50Figure 3-1 NGN/VOP Architecture - High-Level View . . . . . . . . . . . . . . 3–8Figure 3-2 Operator Services in an NGN/VOP Architecture . . . . . . . . . . . 3–11

vii

Telcordia Notes on Operator Services Issue 1, May 2002List of Figures

SR-NOTES-SERIES-18

viii

Issue 1, May 2002 Telcordia Notes on Operator ServicesList of Tables

SR-NOTES-SERIES-18

List of Tables

Table 2-1 Routing Treatment for Operator Services Dialing Sequences . . . 2–14Table 2-2 Multiwink Signals and Their Functions . . . . . . . . . . . . . . . . 2–43Table 2-3 Requirements References for MF and SS7 Signaling Alternatives . 2–55Table 2-4 Pulsing Format from an End Office to an OSS Switch with ANI

Supercombined Coin and Non-Coin Trunk Group Using Original OS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–57

Table 2-5 Pulsing Format — End Office to OSS switch with ANI Combined Coin or Combined Non-coin Trunk Group Using Original OS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–58

Table 2-6 Pulsing Format — End Office to OSS Switch with ANI Using Original OS Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 2–59

Table 2-7 Pulsing Format — Non-Conforming End Office to an OSS Switch without ANI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–60

Table 2-8 Information Digit I . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–61Table 2-9 Pulsing Format from End Office to OSS Switch - Local, IntraLATA

Toll, and InterLATA Calls Using Pre-EAOSS Signaling . . . . . . . 2–62Table 2-10 Pulsing Format from End Office to OSS Switch -International

Calls and Test Calls Using Pre-EAOSS Signaling . . . . . . . . . . . 2–63Table 2-11 Nature of Address Encoding for Basic SS7 Signaling . . . . . . . . 2–72Table 2-12 Nature of Address Encoding for Operator Services SS7 . . . . . . 2–74Table 2-13 MSC to LEC OSS Switch (MF) . . . . . . . . . . . . . . . . . . . . . 2–75

ix

Telcordia Notes on Operator Services Issue 1, May 2002List of Tables

SR-NOTES-SERIES-18

x

Issue 1, May 2002 Telcordia Notes on Operator Services Foreword

SR-NOTES-SERIES-18

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. Telcordia has also now packaged together all documents in the Telcordia Notes on.... series, including SR-2275, on one CD-ROM entitled Telcordia Notes on Technology Series, FD-NOTES-SERIES-CD-1.

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-on-demand. We currently keep more than 100 million lines of code maintained and running efficiently, through more than 150 operations support

xi

Telcordia Notes on Operator Services Issue 1, May 2002Foreword

SR-NOTES-SERIES-18

systems. Our Capability 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: +1.800.521.2673 (United States and Canada) or +1.732.699.5800 (Worldwide).

xii

Issue 1, May 2002 Telcordia Notes on Operator ServicesIntroduction

SR-NOTES-SERIES-18

1 Introduction

Operator Services include a broad range of fully and partially automated, and manual, assistance and information services. For example, Operator Services include directory assistance services typically accessed by dialing 411 or 555-1212, 0- assistance services, 0+ alternately billed and handled services, coin services, and intercept services. Two popular Operator Services include directory assistance and calling card billing. Local Exchange Carriers (LECs), Interexchange Carriers (ICs), and third-party providers to wireline and wireless end users offer various types of Operator Services. The technology used to provide these services and the particular services offered depend on the individual Operator Services provider.

This Telcordia Special Report (SR) describes the current Operator Services and Operator Services technology used in LEC networks. This SR also describes evolutionary options for LEC Operator Services and Operator Services technology.

1.1 Purpose and Scope

This document is intended to describe a comprehensive set of LEC Operator Services to organizations in telecommunications companies that are either responsible for providing Operator Services to end users or for providing equipment to Operator Services providers. Examples of companies in the telecommunications industry that comprise the target audience for this document include:

• Local Exchange Carriers (LECs),

• Interexchange Carriers (ICs),

• Third-party Operator Services and directory assistance (DA) providers (e.g., companies that provide Operator Services on behalf of carriers, such as wireless carriers)

• Wireless Carriers,

• International Carriers,

• Suppliers of Operator Services System (OSS) technology, including switches, workstation applications, voice feature servers, and databases,

• Suppliers of speech recognition engines and applications, which may be useful for Operator Services,

• Suppliers of listings data, and

• Suppliers of contact center technology, which may be useful for Operator Services.

This document describes the current environment of Operator Services and technology based on the latest publicly available information, and includes:

• LEC Operator Services, such as 0- assistance services, alternate billing services, and directory assistance services,

• Dialing Sequences,

1–1

Telcordia Notes on Operator Services Issue 1, May 2002Introduction

SR-NOTES-SERIES-18

• Architectures,

• Capabilities,

• Example Call Flows,

• Signaling to and from OSS switches,

• Automatic Message Accounting (AMA) recorded by OSS switches, and

• Force Measurements recorded by OSS switches and/or force management systems.

This document also describes the anticipated evolution of Operator Services, including:

• General technology advancements desired for Operator Services, such as the support of more automation and a migration to Internet Protocol (IP),

• Generic Next Generation Network (NGN) Operator Services architecture defined to handle existing services and new multimedia services, and

• Discussion of how the existing OSS infrastructure may migrate to the generic NGN Operator Services architecture.

1.2 Background

When many experienced industry members think of the history of Operator Services, they think of a center of operators at a switchboard answering calls and physically connecting an incoming call to an outgoing connection. Years ago, before switching became automated, operators were integral to connecting calling parties to their desired destinations. The calling parties did not need to know the numbers that identified the called party; instead, they could ask for a store down the road by name and the operators would be able to connect them to the desired store. Of course, in the past there were bias issues that were raised by business owners, which encouraged the creation of automatic switching, rather than the use of operators. However, the Operator Services industry still operates with the belief that many customers may prefer to make a connection by simply asking for a name of a person or a type of business and that the Operator Services discipline can still be an integral part in helping the customer make that connection.

The Operator Services industry has since evolved to more of a secondary role when it comes to assisting customers with making their connections. Most people make most of their calls by directly dialing telephone numbers without Operator Services involvement. Operator Services is useful to end users when they do not know the telephone number to be dialed, when they want assistance from a live operator (e.g., by dialing just 0, referred to as “0-”), when they want to bill the call to a number other than the calling line number, and when special capabilities are needed, including real-time rating of the call and complex Intercept treatment. In essence, Operator Services started out as the discipline that completed every call and evolved to become a discipline that offers information (e.g., telephone numbers) to end users, assistance to end users, and complex functions (e.g., real-time rating) that cannot cost-effectively be distributed in every end office.

1–2

Issue 1, May 2002 Telcordia Notes on Operator ServicesIntroduction

SR-NOTES-SERIES-18

Since the introduction of automatic switching, much of the evolution in the Operator Services industry has been focused on making operator centers run more efficiently. Specifically, automation has been introduced for alternate billing services to fully automate many calls resulting in reduced operator work time, and for directory assistance to save operator work time and to fully automate some calls (e.g., calls making inquiries for Frequently Requested Listings [FRLs]). In addition, operators have been centralized to enable a center of operators to serve a wider geographic territory than in the earlier switchboard days. The trend is expected to continue with automation of additional DA calls and geographic independence for operators with the use of the Internet Protocol (IP). The key is to introduce automation and geographic independence without sacrificing the quality of the end user experience.

Recent evolution of Operator Services has focused primarily on DA. Until recently, LEC DA offerings included providing numbers within a local geographic area. In the late 1990s, the LECs began providing numbers from anywhere in the nation as part of their DA offerings. In addition, LECs are beginning to offer enhanced DA (EDA) services to end users on behalf of wireless service providers. Examples of these services include business category searches, directions, and movie listings.

The Operator Services industry is now at a crossroads. In many ways, the discipline is a very traditional voice telephony discipline. Live operators and automated systems continue to be relied on by many end users for traditional services, such as directory assistance, general assistance, and alternate billing. However, the industry is beginning to expand and is becoming more comparable to emerging information services industries, such as voice portals, on-line yellow pages, and telematics1. All of these industries, including the Operator Services industry, are grappling with the challenge of how to provide information to end users in a manner that is both user-friendly and profitable. The evolution and convergence of these industries may result in more competition, partnerships, and technology innovation as a result of the opportunity for suppliers within each industry to support all four industries (Operator Services, voice portals, on-line yellow pages, and telematics). The question remains for Operator Services as well as the other three industries as to whether they will be able to expand their information service offerings in a profitable manner.

It is interesting to note that the trend in the U.S. society continues toward the use of more services to simplify everyone’s busy lives. Many would probably welcome a simpler environment, much like our ancestors had before automatic switching, when a caller could request a connection to a specific type of person or business without providing the name or number. DA Call Completion already provides this for residential and specific business listings, where a caller can ask for a number and then also have the option for the OSS to complete the call to that number. The new EDA services take us a step even closer to this simpler lifestyle where a caller can indicate a type of business and the operator or automated system could provide the telephone number and associated information (e.g., directions, business hours), and make the connection between the caller and business. The Operator

1. From whatis.com: “Telematics is the blending of computers and wireless telecommunications technologies, ostensibly with the goal of efficiently conveying information over vast networks to improve a host of business functions or government-related public services....The term has evolved to refer to automobile systems that combine global positioning satellite (GPS) tracking and other wireless communications for automatic roadside assistance and remote diagnostics. General Motors Corp. first popularized automotive telematics with its OnStar system.”

1–3

Telcordia Notes on Operator Services Issue 1, May 2002Introduction

SR-NOTES-SERIES-18

Services industry will likely find the right business model to enable future generations to experience simpler ways of contacting businesses and people, much like the operator interactions our society benefited from before automatic switching.

1.3 Organization

The remainder of this SR is organized as follows:

• Section 2 provides a description of the current Operator Services environment in a LEC network, including services and technology.

• Section 3 describes desired technology advancements, a generic NGN Operator Services architecture for realizing the desired advancements, and evolutionary options for evolving the existing OSS infrastructure toward the generic NGN Operator Services architecture.

• Section 4 is a summary of the key elements of the document.

• Appendix A is Bibliography and References section.

• Appendix B is a list of Acronyms and their definitions that were used in the document.

1–4

Issue 1, May 2002 Telcordia Notes on Operator ServicesCurrent Operator Services System Environment

SR-NOTES-SERIES-18

2 Current Operator Services System Environment

This section describes the current environment for Operator Services. These services range from manual call assistance services to fully automated information services. Operator Services include:

• Directory assistance,

• Operator assistance,

• Alternate billing,

• Originating restrictions, and

• Person handling options.

Local Exchange Carrier (LEC) Operator Services are currently provided by tandem switches that are equipped with special hardware and software enabling them to process 0-, 0+, and certain types of 1+ calls from its subtending end offices, including database interfaces, announcements, operators, and service call processing capabilities, in addition to basic tandem switch capabilities. These LEC Operator Services platforms plus their associated databases, Voice Servers, other peripherals, and operator workstations are referred to as Operator Services Systems (OSSs).

The voice peripherals’ functions include announcement provision, Dual-Tone Multifrequency (DTMF) digit collection, speech recognition, text to speech, and databases that are accessed by OSS switches such as:

• Intercept Database (INDB),

• Line Information Databases (LIDBs),

• Local Number Portability (LNP) database,

• Listing Services Databases (LSDBs),

• Operator Reference Database (ORDB), and

• Real Time Rating System (RTRS).

The OSS switch is a call-processing switching system from which customers may access operators or automated functionality to complete calls or gain access to information. To provide its services, the OSS performs functions, including signaling, automatic call distribution, recording of billing details, and information retrieval. Generic Requirements for the OSS are documented in FR-271, Operator Services Systems Generic Requirements

(OSSGR). This Family of Requirements is a set of Generic Requirement documents, consisting of Capabilities documents describing technical functionality needed to support Operator Services, and Feature Specification Documents (FSDs) describing how specific services’ call flows utilize those functions.

This section is organized as follows:

• Section 2.1 describes Operator Services that LECS currently implement, including call completion, listing services such as directory assistance, toll and assistance billing, handling, and service options, and intercept.

2–1

Telcordia Notes on Operator Services Issue 1, May 2002Current Operator Services System Environment

SR-NOTES-SERIES-18

• Section 2.2 explains the dialing plans used to access these services.

• Section 2.3 discusses current network architectures, including the general OSS and Advanced Intelligent Network (AIN) architectures.

• Section 2.4 discusses current Operator Services capabilities, including speech recognition, LNP, support for resale, coin control, connection hold, ringback, and Signaling System 7 (SS7) release capabilities.

• Section 2.5 illustrates a sample of call flows.

• Section 2.6 defines the various signaling scenarios used in routing calls to and from OSS switches.

• Section 2.7 describes the usage measurements recorded by OSSs for downstream billing

• Section 2.8 explains the force measurements used at operator offices.

2–2


SR-NOTES-SERIES-18

2.1 Current LEC Operator Services

Operator Services that LECs currently offer can be grouped into the following categories:

• Call Completion

• Listing Services (including Directory Assistance and Enhanced Directory Assistance)

• Toll and Assistance

— Alternate Billing

— Alternate Handling

— General Assistance

— Special Needs (e.g., coin, hotel)

— Transfer

— Busy Line Verification/Interrupt (BLV/I)

• Intercept.

Each of the above Operator Services categories is discussed, in Section 2.1.1 through Section 2.1.4, respectively.

With the exception of Enhanced Directory Assistance (EDA), the LEC Operator Services described in this section are offered to customers that the LEC serves. Due to regulatory reasons, many Incumbent LECs (ILECs) do not offer EDA and information services to their own end-user customers. Depending on contractual agreements between LECs and other carriers, some or all of the Operator Services, including EDA and information services, are offered by LECs on behalf of other carriers to end users served by these other carriers, such as wireless carriers.

The Operator Services category descriptions are based on the requirements in the OSSGR. One of the FSDs contained in the OSSGR, Common Functions (GR-1173-CORE), describes the aspects of service call flows that are common to multiple services; these functions include:

• Determining the calling number from incoming signaling.

• Launching an Originating Line Number Screening (OLNS) query to LIDB if appropriate, to obtain information about the originating line, including whether it should be provided an announcement or an operator should be attached, its billing and service restrictions, and its account owner.

• When the LEC provides wholesale Operator Services on behalf of a wireline or wireless carrier, branding the call by playing a customized announcement specified by the wireline or wireless carrier serving the calling line.

• Determining the called number from dialed digits or from operator interaction with the caller.

• Determining the service type, handling type, and billing type desired by the caller.

2–3


SR-NOTES-SERIES-18

• If it is determined that the call is an alternately billed call, launching a Billed Number Screening (BNS) query to LIDB if appropriate, to obtain information about the billed line, including its billing and service restrictions and its account owner.

• Determining whether the call is able to be completed by the LEC or requires an IntraLATA toll, InterLATA, or International Carrier.

• Recording usage measurements in an Automatic Message Accounting (AMA) record.

2.1.1 Call Completion

The LEC OSS completes Operator Services calls from calling parties to called parties. Call Completion services are needed by callers who dial 0 to request that an operator enter a called number because of an inability to dial (caller disability, service failure, or equipment limitation) or because of a preference not to dial. The service is also needed by callers who do dial the called number, but wish to have a billing option or handling option that requires the call to be processed by an OSS. These billing options are Calling Card, Collect, and Third Number Billing, described in Section 2.1.3.1, and often require call completion from the OSS switch [they may also be used with other services, such as Directory Assistance (DA), e.g. when a DA call is billed to a calling card]. Similarly, Person Service, described in Section 2.1.3.2, is a handling option associated with Call Completion services.

Call Completion may also be provided by the OSS switch subsequent to the provision of another service, such as a DA call that results in DA Call Completion (DACC) service.

Normally, the LEC OSS switch forward routes the calls and remains in the call path for the duration of the calls completed from the OSS switch. In some cases, the LEC OSS switch may release the call back to a previous switch for call completion.

When the LEC provides Operator Services on behalf of a wireline or wireless carrier, the wireline or wireless carrier may select the outgoing route for call completion, so the call is completed via the wireline or wireless carrier’s network. This results in a loop-around trunk configuration when the call is forward routed from the OSS switch.

2.1.2 Listing Services

Listing Services is the set of Operator Services related to customer listing information. Customers call the operator or automated system looking for various pieces of information related to a telephone number. They may request the phone number associated with the following:

• A name and address they provide (DA),

• The name, address, and zip code associated with a phone number they provide (often referred to as “reverse DA” or Customer Name and Address [CNA]),

• The address and zip code associated with a name and locality they provide (Address Provisioning Service [APS]),

2–4


SR-NOTES-SERIES-18

• The name and phone number associated with an address they provide (Name and Telephone Number Provision Service [NTS]),

• The zip code associated with an address they provide (Zip Code Provision Service), and

• The area code associated with a city/state they provide (Area Code Service).

The generic requirements for Listing Services are contained in the OSSGR’s GR-1175-CORE. Each of these services’ generic requirements is contained in an FSD in GR-1175-CORE, starting with the DA requirements in FSD 75-01-0100.

Directory Assistance service prompts a caller for a name and address and then provides the customer with the associated telephone number, via an operator and/or an announcement. The OSS may then offer the caller Call Completion to that retrieved telephone number. Some companies provide their customers with the ability to be returned to an operator after receiving a listing and signaling “*” or another DTMF digit or staying on the line for some amount of time, to request another listing. Directory Assistance service is usually accessed by dialing (1) 411, (101XXXX) 1+NPA-555-1212, and (1) 555-1212 (the parenthetical 1’s are optionally dialed). It can also be accessed by dialing 0- and 0+411.

DA is offered to customers with an increasing amount of automation. Today, many LECs use front-end automation to request the listing and locality. The front-end automation includes a store and forward capability that records the voice and truncates the voice recording (e.g., deletes silence) before providing the recording to the operator. The front-end automation in some LEC networks includes the capability to recognize locality and provide the text on the operator screen. Further, the LECs use back-end automation to provide the found telephone number to the calling party using an announcement. In addition, some LECs fully automate calls to frequently requested listings. Trials exist that can fully automate calls to listings that are not frequently requested, but these applications are not yet deployed by the LECs.

In the past, the LEC DA service offering only provided telephone numbers within a local geographic territory. Now, callers can obtain any telephone number in the United States via (1) 411 or (1) 555-1212 dialing. This service is referred to as National Directory Assistance (NDA).

Enhanced Directory Assistance and Information Services is a term used for the other types of Listing Services listed above as well as for other types of information provision not included in the OSSGR, which DA service providers are offering or planning to offer to customers. Examples of these services include business category search, (sometimes referred to as “Yellow Pages DA” or Area Business Listing [ABL]), weather reports, stock quotes, sports scores, movie listings, weather, and travel directions. Today, when these services are provided by LECs, it is on behalf of wireless providers. Due to regulatory restrictions, these services cannot be provided by many ILECs to their own customers. These services can currently be accessed from mobile phones via 411 dialing.

The enhanced information is provided to customers in the same way as DA currently is, i.e., via a phone call to the OSS. In the future, this information may also be offered using newer technology, such as via WAP-enabled devices or via web browsers with live web-site assistance offered upon request using click-for-assistance technology.

2–5


SR-NOTES-SERIES-18

2.1.3 Toll and Assistance

Toll and Assistance refers to the set of Operator Services accessed by customers dialing 0- and 0+, as well as some special OSS capabilities accessed by dialing 1+. This category includes alternately billed calls (usually dialed 0+ or via a toll-free number, but also dialed 0-); alternately handled calls (i.e., person-to-person, dialed 0+ and 0-); general assistance (dialed 0-); special needs (i.e., coin, hotel dialed 1+ requiring real-time rating); 0- transfer; and, BLV/I (usually dialed 0- but also dialed 0+). Each of these sub-categories is described in Sections 2.1.3.1 through 2.1.3.6, respectively.

2.1.3.1 Alternate Billing

An alternately billed call is one in which the calling party requests that the call be billed to a number other than the billing number associated with the calling line. The call may be billed to a calling card number, the called line number, or a line number different from the calling or called line. These billing options are referred to as Calling Card, Collect, and Third Number, respectively, and as a set are often referred to as alternate billing services, or ABS. The OSS verifies that the calling line is permitted to bill a call in the requested manner, and if so, then validates the calling card number or verifies that the called party or third party will accept the charges for the call. All of these billing options have increasingly been provided by the LECs on a completely automated basis. The automated provision of these services, which relies on receipt of customer-dialed post-seizure-dialing digits and/or speech recognition technology, is called Automated ABS (AABS). The LECs provide ABS and AABS to their end users and to the end users of other service providers for whom the LEC is providing Operator Services.

An OSS switch is capable of formulating and launching SS7 Transaction Capabilities Application Part (TCAP) queries to Line Information Databases (LIDBs) and of receiving and processing LIDB responses. It launches an OLNS query over the SS7 network(s) to the LIDB containing the calling line number to retrieve information about how to prompt the caller and what billing options are allowed from the calling line. Once it determines that a caller is requesting alternate billing of a call, the OSS determines whether the specific billing option is permitted from the particular calling line by comparing it to the information concerning that option in the OLNS response. If the billing option is allowed, the OSS switch then launches a CC query (if Calling Card billing was requested) or a BNS query (if Collect or Third Number billing was requested) over the SS7 network(s) to the LIDB containing the billed line number. The OSS switch then processes the LIDB’s response and continues the call’s processing based on the information contained in the response message. This may include accepting or rejecting a Calling Card number; automatically allowing or denying a Collect call or needing to ask the called party (via an operator or announcement) whether they will accept charges or not; automatically allowing or denying a Third Number call or needing to ask the third party (via an operator or announcement) whether they will accept charges or not. If the requested billing option cannot be used, the OSS asks the caller to supply a different billing number and/or option.

During call setup or after the called party disconnects, the calling party may request (e.g., by depressing #) the OSS switch to set up another call to a different number without having to re-enter the billing number. This capability is referred to as sequence calling.

2–6


SR-NOTES-SERIES-18

The following summarizes each billing option an OSS switch provides:

• Calling Card Billing - enables a calling party to bill a call to a calling card number. The calling party provides the calling card number to an automated system or to an operator. The OSS switch determines whether calling card is a billing option allowed from the calling line by examining the response from the LIDB containing the calling line’s OLNS to the query it had launched upon receipt of the call request. In a pre-OLNS environment, internal OSS switch tables are examined to determine the billing restrictions on the originating line. If calling card billing is allowed from the originating line, the OSS switch then validates the calling card number by launching a Calling Card (CC) query and examining the response information from the LIDB containing the number. If the calling card number is valid, the OSS switch sets up the intraLATA call between the calling party and called number.

• Collect Billing - enables a calling party to bill a call to the called line number. The calling party indicates to an automated system or to an operator that collect billing is desired. The OSS switch determines whether collect is a billing option allowed from the calling line by examining the OLNS response from the LIDB containing the calling line to the query it had launched upon receipt of the call request. In a pre-OLNS environment, internal OSS switch tables are examined to determine the billing restrictions on the originating line. If collect billing is allowed from the originating line, the OSS switch then verifies whether the called party will accept the charges by launching a Billed Number Screening (BNS) query and examining the response information from the LIDB containing the called number. The LIDB response may indicate that the called line automatically accepts or rejects collect calls, or that real-time acceptance needs to be determined. If the latter, the OSS switch sets up the call to the called line and an operator or automated system interacts with the called party to determine whether the call’s charges will be accepted. If verification is successful, the OSS switch cuts through the intraLATA call between the calling party and called party.

• Third Number Billing - enables a calling party to bill a call to a line number other than the calling or called line numbers. The calling party indicates to an automated system or to an operator that third number billing is desired. The OSS switch determines whether third number is a billing option allowed from the calling line by examining the OLNS response from the LIDB containing the calling line to the query it had launched upon receipt of the call request. In a pre-OLNS environment, internal OSS switch tables are examined to determine the billing restrictions on the originating line. If third number billing is allowed from the originating line, the OSS switch then verifies whether the third party will accept the charges by launching a BNS query and examining the response information from the LIDB containing the third number. The LIDB response may indicate that the third number automatically accepts or rejects third number calls, or that real-time acceptance needs to be determined. If the latter, the OSS switch sets up a call to the third number and an operator or automated system interacts with the third party to determine whether the call’s charges will be accepted. If verification is successful, the OSS switch sets up the intraLATA call between the calling party and called number.

2–7


SR-NOTES-SERIES-18

2.1.3.2 Alternate Handling

Standard handling of calls refers to “station-to-station” calling, where the caller wishes a call to be completed to any person answering the phone at the called line; this is the way the vast majority of phone calls are made. Alternate handling of calls refers to “person-to-person” calling, where the caller wishes a call to be completed only if a particular person is available at the called line. A customer dials 0+ or 0- and interacts with an operator to request this handling. The OSS switch completes the intraLATA call to the called party, and the operator remains bridged on the call and asks for the particular requested person. If he/she is available, the OSS switch cuts through the intraLATA call between the calling party and called party. If the requested person is not available, the operator reports that fact to the caller and the call is disconnected.

2.1.3.3 General Assistance

General Assistance is a category of services accessed via 0- by a caller wishing help in completing a call or desiring some other type of assistance or information. Currently, a customer’s request for general assistance may be by talking to an operator or by inputting DTMF digits to an automated system. The latter is referred to as 0- automation.

Customers may access the OSS for many different types of information, such as dialing instructions and rate information, as well as other services that a LEC may offer including providing the current time and date, providing the name of the rate center town serving an NPA-NXX, and providing the name of the telephone company(ies) serving an NPA-NXX exchange.

Customers can request operators to complete calls on their behalf, for cases where the caller does not wish to dial the called number and/or an alternate billing number. In many cases, the customer must be willing to pay an operator surcharge for this operator handling.

Transfer to emergency services is another operator service under the general assistance category. If a customer dials 0- rather than 911 in an emergency, an operator can transfer the caller to the Public Safety Answering Position (PSAP) or E911 tandem that is responsible for the geographic area of the calling line. The operator may obtain the PSAP or E911 tandem routing information from an OSS database or the OSS switch automatically routes the emergency call to the E911 tandem. As part of the service, an operator may ring back the calling line after the calling party disconnects or even when the calling line is off hook (using a special alerting tone). The ringback capability requires the use of the connection hold capability, in which the OSS switch remains in control of the call even after the calling line disconnects from the call; with this capability, the end office does not release the trunk between the end office and OSS switch when the calling line goes on-hook.

Language assistance may be provided to an OSS’s customers; LIDB may contain a Foreign Language field. If the OSS launches an OLNS query, the response information from the LIDB containing the calling line may contain that parameter, indicating to the OSS a language associated with the line other than English. The OSS could then attach an operator or announcement in the customer's preferred language. Alternatively, the caller can make a

2–8


SR-NOTES-SERIES-18

language selection by verbally requesting the language or requesting the language via DTMF digit input.

Dialing instructions are provided to customers as part of the general assistance offering. This can include NPA codes, IC access codes, International Direct Distance Dialing (IDDD) country codes, dialing instruction information for all services provided by the OSS, and dialing instructions for reaching specific locations.

Operators provide rate information to a calling party about a call being made or a call that may be made in the future. The customer must provide the calling and called phone numbers or locations in order to receive the cost of a call between two points. The caller speaks to an operator to request information about the cost of a call placed via the LEC network, and possibly over other service providers’ and/or ICs’ networks if the LEC has an arrangement with those companies to provide rate information to their customers. A customer may also request an operator to be notified when a certain time period has elapsed during a call.

2.1.3.4 Special Needs (1+)

The codes typically thought of as being associated with Toll and Assistance Services are 0+ or 0-; OSSs also serve special types of calls that are not accessed by dialing “zero”. These calls are dialed 1+ just as direct-dialed calls are, but due to the special need to rate them at the time of the call (i.e., real-time rating) rather than downstream as is done for direct dialed calls, they are routed to OSSs because the OSSs are capable of performing the real-time rating functionality. The special-need calls requiring OSS processing are those from network-controlled coin phones being paid for at the time of the call with coins (i.e., not alternately billed), calls from hotels/motels resulting in charges being placed on the hotel/motel’s customer’s room bill, and time and charges requests where a customer wishes to be alerted during a call in progress after a requested number of minutes has expired and/or money has been charged1. All three of these types of calls are handled by the OSS’s real-time rating function to determine the amount of money that a call costs at the time it is occurring. In the case of coin calls, the customer is then requested to deposit that amount in the coin station; for hotel/motel calls, that amount is then transmitted to the hotel/motel; and, for time and charges requests, that amount is then reported to the caller. The remainder of this subsection uses the example of coin calls to describe the OSS’s provision of real-time rating.

Unlike home or business telephones, coin phones are available to many end users and not associated with a particular customer’s billing name, number, and address. Therefore, calls from these phones must be paid for on a per-call basis, either in real time or subsequent to the call. If paid in real time by the caller before, during, or immediately after the call, it is via coins or a pre-paid method such as a cash card; customer identification is not required because payment is immediate. If the payment is to be deferred, the cost of the call is billed to an account selected by the caller, such as a calling card, credit card, or a home or business

1. The Time and Charges capability deployed in LEC networks supports alerting during a call in progress after a requested number of minutes expired, but does not currently support alerting after a requested amount of money has been charged.

2–9


SR-NOTES-SERIES-18

telephone line (i.e., collect or third number billing); this type of billing is handled by an OSS in the same way it handles an alternate billing request from a non-coin line.

OSSs provide real-time rating for 1+ intraLATA toll calls from network-controlled coin stations. Based on the real-time rating, the OSS exchanges messages with the end office to control the coin stations (e.g., request coin collect or return). To provide coin services, the OSS switch must use its connection hold capability that enables it to retain control of the call even after the calling line disconnects, to be able to ring back the coin telephone to request additional coins when necessary. The connection hold and ringback capabilities are also used for emergency services.

Any public telephone that can handle real-time payment can also handle deferred payment. A “coinless” public station, sometimes called a Charge-a-Call station, can only handle deferred payment and cannot accept real-time payment. Coinless terminals do not accept coins and are intended for alternately-billed (calling card, credit card, collect, and third number) calls as well as certain non-chargeable calls.

A public telephone communicates with the network using one of two types of interfaces: the standard interface and the alternate interface. The standard interface involves a relatively unintelligent public station that communicates with a local switching system and/or an OSS switch via a set of analog Direct Current (DC) and Alternating Current (AC) signals. The local switch and OSS switch provide the majority of call control and coin phone functionality, including rating the call, requesting the coins, and monitoring for the customer’s input of the coins. The coin station associated with the standard interface is referred to as a network-controlled coin station. The standard interface involves a special type of line called a coin line, which, by means of various switch-based signaling and test conditions, controls many of the functions of the public station. The standard interface requires DC and AC signals for coin control, coin tests, coin deposit signals, and line polarity changes for OSS switch interworking. Intersystem DC signaling capabilities include flashes (both customer and interoffice) and multiwink signals needed for communication between public terminals, local switches, and OSS switches. Intersystem AC signaling capabilities include in-band and expanded in-band signals needed for communication between local switches and operator systems.

The alternate interface involves an intelligent public station providing the majority of call control and coin phone functionality, rather than the network providing it. Compared to the standard interface, significantly fewer signals are sent between the station and the local network, since coin control signals such as coin collect and coin return do not need to be provided by the network. Coinless stations have, for some time, used this type of interface, and also many coin stations have been designed and deployed to work with this alternate interface. The alternate interface, unlike the standard interface, uses a line with attributes similar to those of a conventional, measured-usage line. The public stations used with this interface do not require many of the signaling and test functions provided on the standard interface. There are three types of stations that use the alternate interface: coinless (Charge-a-Call) stations, non-network-controlled (intelligent) stations, and restricted-access coinless public telephones such as those used in prisons. The signaling type may be MF or SS7 signaling.

Public stations can use multiwink, expanded in-band, and Operator Services SS7 signaling. Multiwink signaling is an older signaling method that OSS switches use to control dial-tone-first coin telephones, and although it is becoming uncommon, this signaling may still be used

2–10


SR-NOTES-SERIES-18

in certain areas. Multiwink coin control signals consist of one to five on-hook wink signals (a momentary change from off-hook to on-hook to off-hook). After sending a multiwink signal, an OSS switch allows an end office time to complete the requested action before sending another multiwink signal.

Expanded in-band signaling, which uses MF signaling, is the main method that OSS switches use to control dial-tone first coin telephones. It replaced an older signaling method called In-Band Signaling, and is therefore called “expanded”.

Operator services SS7 signaling is not yet deployed. It is an “enhancement” of SS7 used for direct dialed calls that accommodates routing of Operator Services calls and the operator system hold, ringback, and coin control capabilities needed to support sent-paid calls from coin stations.

2.1.3.5 0- Transfer

If a customer dials 0- and subsequently provides an operator with a called number, the LEC OSS can complete the call only if it is to an intraLATA destination. If the OSS compares the calling and called numbers and determines that the call would be interLATA, the OSS can either ask the caller to hang up and redial 00- or 0+ to reach their IC, or can transfer the call to the IC, depending on local methods and procedures.

“0- Transfer” refers to the case where the LEC OSS transfers the 0- interLATA call to the caller’s IC. The IC may be determined by asking the caller for their IC’s identity.

2.1.3.6 Busy Line Verification/Interrupt

Busy Line Verification/Interrupt (BLV/I) is a service usually accessed via 0- (it could also be accessed via 0+), where a customer can request that an operator verify whether or not a line, referred to as a “target line”, is busy talking and, if necessary, have the operator interrupt the target party’s conversation. The operator may request the target party to hang up to enable the calling party to call the target line, or to enable the operator to connect the calling party to the target party. The provision of BLV/I for Competitive Local Exchange Carriers (CLECs) is a critical regulatory issue raised by the Telecommunications Act of 1996; some states may require that an ILEC providing Operator Services to a CLEC offer BLV/I if the CLEC requests it.

The OSS switch that is capable of interacting with the end office serving the target line determines whether the target line is busy talking. This OSS switch may or may not be the same OSS that serves the calling line requesting the BLV/I. The target line’s OSS seizes a no-test trunk (i.e., an MF trunk dedicated to BLV/I) and signals the target line’s digits to the end office serving the target line; OSSs and end offices currently interface via MF signaling for BLV/I. The end office connects to the line via test access when the line is busy and via normal access when the line is idle.

LECs implement BLV/I via several architectural arrangements. These became more complicated due to local service competition. If the calling line and the target line are within the same LATA (i.e., a call from the calling line to the target line would be intraLATA), the Operator Services provider serving the calling line for the BLV/I request is the same as, or is

2–11


SR-NOTES-SERIES-18

selected by, the calling line’s local service provider. If the calling line and the target line are in different LATAs (i.e., a call from the calling line to the target line would be interLATA), the Operator Services provider serving the calling line for the BLV/I request is the same as, or is selected by, the calling party's presubscribed IC.

The Operator Services provider serving the target line may or may not own the end office serving the target line. For example, a CLEC may own the end office serving the target line and outsource its Operator Services to an ILEC that provides Operator Services, including BLV/I, on its behalf.

The OSS that serves the target line has a dedicated trunk group for BLV/I that directly connects to the end office serving the target line. In the past, OSSs sometimes provided BLV/I via a tandem switch, or BLV hub, owned by the Operator Services provider, prior to local competition and Local Number Portability (LNP). BLV hubs are now rarely, if ever, used in ILEC networks, due to complications resulting from LNP. See Section 2.4.2 for further information on LNP and BLV/I.

2.1.4 Intercept

Intercept Service informs a calling party that a line number is no longer in service and whether that number has just been disconnected or has been changed to another number. It may also inform the calling party of a new working line number where the party formerly associated with the intercepted line number may be reached. Some OSSs may also offer call completion to the new number. When Intercept service is provided, the calling line is notified via the appropriate intercept tone as described in GR-674-CORE, LSSGR: Special Information Tones

(SITs), FSD 20-06-0500.

When a line number is placed on intercept, its serving end office either provides a recording with basic intercept information to the caller, or routes the caller to an intercept-capable OSS or to a dedicated intercept system. An OSS or other intercept system provides the customer with a recorded announcement containing pertinent information regarding the status of the dialed number, or connects the caller to an operator when more detailed information needs to be provided. The operator interaction is needed for special situations such as when an intercepted number that had been shared by multiple people (e.g., a doctor’s practice or a family that has split up) has been replaced with multiple numbers, and the operator needs to ask the customer which particular party is trying to be reached to provide the correct new number.

There are three categories of intercepted calls:

1. Regular Intercept: a call to a recently changed or disconnected number.

2. Blank Number Intercept: a call to a vacant number (a number for which there is no terminating equipment in the end office) or unassigned number (a number for which there is terminating equipment in the end office, but the number has not been assigned to any customer).

3. Trouble or Special Intercept: a local service provider may place any line on trouble or special intercept, in which case calls to that line receive special treatment from the OSS or

2–12


SR-NOTES-SERIES-18

dedicated intercept system. Conditions for placing a line on trouble or special intercept are determined by the local company and may differ from company to company.

Three signaling schemes may be used for Intercept: Exchange Access Operator Services System (EAOSS) combined trunks, dedicated trunks, and Operator Services SS7 signaling. See Section 2.6 for details on OSS signaling schemes. Note that the operator system hold capability is not used on intercept calls; an on-hook from the calling line or the incoming trunk should cause the connection to be released.

GR-692-CORE, FSD 20-24-0030 describes the interface to an OSS providing intercept service using MF EAOSS; GR-532-CORE, FSD 30-21-0300 describes the MF dedicated direct trunk group interface to an intercept system; and, GR-1277-CORE describes the interface to an OSS providing intercept service for combined trunk groups using Operator Services SS7 signaling.

When Intercept service is provided using MF EAOSS, the following ANI information digits should be used for intercept calls routed to intercept-capable OSSs to identify the specific type of intercept to the receiving switch:

• 30 - Blank Number Intercept

• 31 - Trouble Intercept

• 32 - Regular Intercept.

Providing Intercept service using Operator Services SS7 is a future scenario; this signaling is currently implemented (e.g., Nortel Networks’ DMS Traffic Operator Position System [TOPS] Operator Services Network Capability [OSNC] Feature), but has not been deployed. There is currently no reliable forecast for the deployment of Operator Services SS7 signaling. If and when it is deployed and used for Intercept, the called party’s end office would establish an Operator Services connection for intercept services (OSC/I), as described in GR-1277-CORE and send an SS7 Initial Address Message (IAM) message including an appropriately populated SAP parameter. The SAP parameter would indicate: “intercept-regular,” “intercept-blank number,” or “intercept-trouble.” The IAM would also include other information, such as the intercepted number in the called party number parameter.

When a stand-alone intercept system is used to provide intercept service, the connection to the intercept system is via dedicated one-way intercept trunks; the interface is described in GR-532-CORE, LSSGR: Interface to Intercept System (FSD 30-21-0300).

2–13


SR-NOTES-SERIES-18

2.2 Current Dialing Sequences

Table 2-1 summarizes dialing sequences that customers use to access various Operator Services. Not all the dialing sequences may be allowable in every company or geographical area, or necessarily treated as defined below in every company or area. For example, some areas may not allow 1+7-digit dialing or 0+7-digit dialing. In addition, some areas may allow 101XXXX (i.e., Carrier Access Code [CAC]) dialing for local calls, while others may not permit dialing a CAC for local calls, based on local regulatory environments.

Also, when a caller does not dial a CAC for an interLATA call, the end office routes the call based on the calling line’s presubscription information, referred to as a Primary Interexchange Carrier 1 (PIC1). This is described in GR-690-CORE, which requires two PICs: PIC1 and PIC2. PIC2 is for intraLATA toll presubscription. According to GR-690-CORE, the following options exist for PIC1: (1) PIC1 may support only domestic interLATA toll traffic, (2) PIC1 may be a consolidated Carrier and support domestic interLATA toll traffic and international traffic, or (3) PIC1 may support only international traffic.

In the discussion of the current LEC Operator Services in Section 2.1, the dialing sequences used to access each of the services is identified, and they are summarized in Sections 2.2.1, 2.2.2, and 2.2.3. The permissible dialing sequences, and how calls dialed with each of them are routed, are summarized below.

Table 2-1 Routing Treatment for Operator Services Dialing Sequences (Sheet 1 of 2)

Operator Services Dialing Sequence Routing Treatment

01+CC+NN International PIC (PIC1)f operator trunk101XXXX+01+CC+NN Operator trunk of carrier identified by dialed carrier

access code (i.e., XXXX after 101)101XXXX+0+NPA-NXX-XXXX(NXX is not 555)

Operator trunk of carrier identified by dialed carrier access code

0+NPA-NXX-XXXX(NXX is not 555; interLATA call)

PIC1 operator trunk

0+NPA-NXX-XXXX(NXX is not 555; intraLATA toll calla)

PIC2 operator trunk

0+NPA-NXX-XXXX(NXX is not 555; intraLATA callb)

Local service provider operator trunk

0+NXX-XXXX (intraLATA tollb) PIC2 operator trunk 0+NXX-XXXXc Local service provider operator trunk0 Local service provider operator trunk

00 PIC1 operator trunk101XXXX+0 Operator trunk of carrier identified by carrier access

code101XXXX+0+NPA-555-XXXXc Operator trunk of carrier identified by carrier access

code

0+NPA-555-XXXX(interLATA)

PIC1 operator trunk(0+ typically takes precedence)

0+NPA-555-XXXX(intraLATA tollb)

PIC2 operator trunk(0+ typically takes precedence)

2–14


SR-NOTES-SERIES-18

0+NPA-555-XXXX(intraLATAc)

Local service provider operator trunk(0+ typically takes precedence)

0+411d

0+555-XXXXLocal service provider operator trunk (0+ typically takes precedence)

1+NPA-555-XXXX(interLATA)

PIC1 operator trunk

(1)+NPA-555-XXXX(intraLATA tollbe)

PIC2 operator trunk

(1)+NPA-555-XXXX (intraLATAc) Local service provider operator trunk

(1)+555-XXXX Local service provider operator trunk(1)+411 Local service provider operator trunk011+CC+NN(from special lines, e.g. coin, hotel/motel)

International PIC (PIC1)a operator trunk

101XXXX+011+CC+NN(from special lines, e.g. coin, hotel/motel)

Operator trunk of carrier identified by carrier access code

101XXXX+1+NPA-NXX-XXXX (from special lines, e.g. coin, hotel/motel)

Operator trunk of carrier identified by carrier access code

1+NPA-NXX-XXXX(interLATA)(from special lines, e.g. coin, hotel/motel)

PIC1 operator trunk

1+NPA-NXX-XXXX(intraLATA tollb)(from special lines, e.g. coin, hotel/motel)

PIC2 operator trunk

(1)+NPA-NXX-XXXX (intraLATAc)(from special lines, e.g., coin, hotel/motel)


(1)+NXX-XXXX(intraLATA tollb)(from special lines, e.g., coin, hotel/motel)

PIC2 operator trunk

(1)+NXX-XXXX(intraLATAc)(from special lines, e.g., coin, hotel/motel)


a. The treatment applies to intraLATA toll calls when the caller presubscribes to an IC for intraLATA toll calls in states that support intraLATA toll presubscription (i.e., PIC2).

b. This treatment applies to intraLATA local calls, to intraLATA toll calls when the caller does not presubscribe to an IC in states that support intraLATA toll presubscription, and to all intraLATA toll calls in states that do not support intraLATA toll presubscription.

c. The 555-XXXX dialing sequence refers to the codes that identify Operator Services (e.g., 555-1212).

d. GR-505-CORE defines the requirements for interpreting dialing sequences, and states that 0+N11 is undefined or is a vacant code. However, as a result of industry input, 0+411 is included in GR-1277-CORE, and may be valid in some areas while treated as vacant in other areas.

e. The dialed numbers (e.g., 1) shown in parenthesis are optionally dialed.

f. The international PIC in this table refers to PIC1 when the carrier in PIC1 handles international traffic.

Table 2-1 Routing Treatment for Operator Services Dialing Sequences (Sheet 2 of 2)

2–15


SR-NOTES-SERIES-18

Note that (101XXXX)+1+NPA+555-XXXX from a line not identified as special (e.g., Plain Old Telephone Service [POTS] line) is routed as are other calls dialed (101XXXX)+1+NPA+NXX-XXXX.

Local calls are routed to an Operator Services trunk group destined to a LEC, as indicated in Table 2-1. Note that when an ILEC switch serves the calling line, the ILEC may or may not be the calling line’s local service provider, because the service provider may be a CLEC unbundler or reseller that uses the ILEC’s switch facilities. That CLEC may or may not select the ILEC as the Operator Services provider; it could provide its own Operator Services or select an Operator Services provider other than the ILEC, such as an IC. When a CLEC on an ILEC switch selects an Operator Services provider other than the ILEC, the Operator Services calls that are to be routed to a local Operator Services provider operator trunk (as shown in Table 2-1) would be routed to an operator trunk destined to the OSS switch owned by, or selected by, the CLEC.

Also note that calls to a PIC1 or PIC2 operator trunk may be routed to a trunk destined to the PIC1 or PIC2 or to an Operator Services provider selected by PIC1 or PIC2. When the PIC1 or PIC2 selects an ILEC to provide its Operator Services, the call would be routed to an ILEC OSS switch.

2.2.1 0- Dialing

Customers can request any of the originating Operator Services, such as call completion, listing services, general assistance, or alternate billing, by dialing 0- (i.e., only a “0”). One reason customers dial 0- is to request call completion assistance (see Section 2.1.1). For call completion assistance, the customer requests an operator to dial the called number; this could result in an intra- or interLATA call. If interLATA, the customer could then receive 0-transfer service (see Section 2.1.3.5) from the OSS, which would transfer the customer to an IC’s operator system. Alternatively, the operator may ask the customer to hang up and dial 00- to be routed directly to the IC. 0- dialing is also used to access general assistance services (see Section 2.1.3.3), and to request alternate billing (see Section 2.1.3.1) and/or alternate (person) handling (see Section 2.1.3.2) of an intraLATA call. BLV/I service (see Section 2.1.3.6) is usually accessed via 0- dialing. If 0- is used for emergency services, the operator/OSS transfers the call to emergency personnel.

2.2.2 0+ DIaling

“0+” dialing refers to customers dialing 0 followed by a 3-, 7-, or 10-digit called number. A call dialed 0 followed by 411 or a local number is routed to a LEC OSS; 0 followed by an intraLATA toll number is routed to a LEC OSS in states that do not support intraLATA toll presubscription and when the caller does not presubscribe to an IC for intraLATA toll calls in states that support intraLATA toll presubscription; 0 followed by an intraLATA toll number is routed to an IC’s operator system when a caller presubscribes to an IC for intraLATA toll calls in states that support intraLATA toll presubscription; 0 followed by an interLATA number is routed to an IC’s operator system. Calls received by the OSS that were dialed 0+ are usually requesting a Toll and Assistance service (see Section 2.1.3) such as alternate billing (see Section 2.1.3.1)

2–16


SR-NOTES-SERIES-18

on a call completion or other service (e.g., DA) and/or alternate (person) handling (see Section 2.1.3.2). Customers may also request BLV/I (see Section 2.1.3.6) via 0+ dialing, though this service is more frequently accessed via 0-. Customers may also request some of the general assistance services (see Section 2.1.3.3), such as rating requests.

2.2.3 1+intraLATA DIaling

Calls referred to as “1+” may or may not actually be dialed with a 1, depending on the location of the called number and the local dialing procedures. These calls are usually direct dialed calls, but there are cases where they require the services of an OSS. When the called number following the “1” is a Listing Services Code (see Section 2.1.2), the call is routed to an OSS. The codes for accessing DA are 411, NPA-555-1212, and 555-1212, and for other listing services may take the form of (NPA)-555-XXXX. Calls dialed 1+ that are routed to an OSS can also be Toll and Assistance calls with the special need (see Section 2.1.3.4) to undergo the real-time rating processing the OSS provides, such as sent-paid calls from coin stations and hotels. The other type of operator service provided to calls dialed 1+ is Intercept (see Section 2.1.4), which is not requested by the caller but rather is encountered by the caller when the call reaches the terminating end office. As indicated in Table 2-1, 1+ local calls, 1+intraLATA toll calls when the calling party does not presubscribe to an IC for intraLATA toll calls in states that support intraLATA toll presubscription, and 1+ intraLATA toll calls in states that do not support intraLATA toll presubscription are routed to LEC OSSs, but 1+ intraLATA toll calls from calling party’s that presubscribe to ICs in states that support intraLATA toll presubscription are routed to the IC’s OSS.

2–17


SR-NOTES-SERIES-18

2.3 Current Architectures2

Currently, an OSS switch is a tandem switch with special Operator Services capabilities. An OSS consists of an OSS switch, databases, Voice Servers, peripherals, and operator workstations that all interact to provide many types of Operator Services to end users. Some OSS switches serve only Operator Services traffic in a stand-alone environment, where tandem functions are not provided for non-Operator Services calls. Others reside on access tandem (AT) switches that also serve non-Operator Services traffic. An OSS switch needs additional hardware and software to provide Operator Services, including interfaces to external databases and other external systems, such as operator workstations.

The major LECs mostly use Nortel Networks’ Operator Services architecture, which includes the DMS Traffic Operator Position Switch (TOPS), to provide services. Lucent’s Operator Services Position System (OSPS) is also used by major LECs to provide Operator Services. The most common architecture for major LECs is an “IN1” model, where much of the call processing takes place in the switch. Nortel Networks also supports an Advanced Intelligent Network (AIN)-like architecture, referred to as the Intelligent Services Environment, where the service logic begins to migrate to services nodes. The capability used to facilitate open communications between DMS TOPS and services nodes is referred to as Operator Services System Advanced Intelligent Network (OSSAIN) and is similar to AIN, but includes many features specific to Operator Services.

A key architecture arrangement that LECs use is referred to as Operator Centralization. With Operator Centralization, operators in one location are able to serve users in the same location and in different locations. Nortel Networks’ Operator Services architecture provides Operator Centralization with the use of fully automated remote TOPS switches and host TOPS switches that support operators.

This section discusses the general OSS architecture, as well as the AIN architecture that is currently used to provide an operator service. Section 2.3.1 discusses the general OSS architecture, including the OSS switch functions, the interfaces to various databases that the OSS switch needs to support to retrieve information necessary for processing Operator Services calls, voice feature server functions, operator workstation functions, and management system functions. Section 2.3.2 discusses the AIN architecture.

2.3.1 General OSS Architecture

The existing general OSS architecture is illustrated in Figure 2-1.

2. TELCORDIA DOES NOT PROVIDE COMPARATIVE ANALYSIS OR EVALUATION OF PRODUCTS OR SUPPLIERS. ANY MENTION OF PRODUCTS OR SUPPLIERS IN THIS SECTION SHOULD NOT BE CONSTRUED AS EITHER POSITIVE OR NEGATIVE COMMENTARY ON THAT PRODUCT OR SUPPLIER, NEITHER SHOULD THE OMISSION OF A PRODUCT OR A SUPPLIER BE REGARDED AS ANY FORM OF COMMENTARY ON THE PART OF TELCORDIA OR THE AUTHORS OF THIS DOCUMENT. TELCORDIA IS NOT MAKING ANY PURCHASING RECOMMENDATIONS AND ANY USE OF THIS INFORMATION IS AT THE RISK OF THE READER. TELCORDIA SHALL NOT BE RESPONSIBLE FOR ANY DAMAGE ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY INFORMATION OR OPINIONS CONTAINED HEREIN.

2–18


SR-NOTES-SERIES-18

Figure 2-1 OSS Architecture

The current OSS architecture includes the following components that are described in subsequent sections:

1. OSS Switch - The OSS switch performs the basic call processing functions and the queuing and call distribution functions to distribute an incoming call to an available operator with the right skills. The major LECs mostly use Nortel Networks’ DMS TOPS switch. Lucent Technologies’ OSPS is also used.

2. Databases - The primary databases involved with OSS processing include:

• Line Information Database (LIDB) (see Section 2.3.1.2.1)

• Local Number Portability (LNP) Database (see Section 2.3.1.2.2)

• Listing Services Database (LSDB) (see Section 2.3.1.2.3)

• Enhanced Directory Assistance (EDA) Database (see Section 2.3.1.2.4)

Operator Services System Switch

Operator Services System Switch Network

Databases(e.g., LIDB,

LSDB,LNP)

Databases(e.g., ORDB,

LSDB)

VoiceNetwork

DataNetworks(e.g., SS7,

X.25)Management Systems

Workstations/Voice Servers

IC POT

IC

OperatorSystem

DataNetworks

(e.g., X.25)

EndOffices/MSCs

2–19


SR-NOTES-SERIES-18

• Intercept Database (INDB) (see Section 2.3.1.2.5)

• Operator Reference Database (ORDB) (see Section 2.3.1.2.6)

• Real Time Rating System (RTRS) (see Section 2.3.1.2.7).

The databases are used for originating line screening, resale, alternate billing services, number portability, directory assistance (DA), enhanced directory services (EDA), intercept service, general assistance, and real-time rating services, such as coin sent-paid calls and time and charges.

3. Voice Servers - The Voice Servers support front-end, back-end, and full automation for alternate billing services, 0-/ automation services, DA, EDA, intercept services, and real-time rating services. In some cases, the Voice Servers process the service logic, rather than the OSS switch (see Section 2.3.1.3).

4. Operator Workstations - The workstations contain many sophisticated applications to enable information from the OSS switch to be displayed to the operator, enable the operators to access many different databases, and enable the operator workstations to request the OSS switch to perform various call control functions, such as call completion (see Section 2.3.1.4).

5. Management Systems - Using data from the OSS switch, the management systems generate reports for LEC personnel, and process complex algorithms to help LEC personnel efficiently manage the network and operator centers. The management systems are also involved with administering data. (see Section 2.3.1.5).

2.3.1.1 OSS Switch

An OSS switch has access to operator workstations, databases, Voice Servers, end offices, tandem offices, and other OSS switches. It identifies the requested service based on dialed digits, trunk groups, and/or signaling information, and is capable of distributing calls to operator positions and automated peripherals during its provision of call processing. OSS switches receive calls from end offices, from Mobile Switching Centers (MSCs), from LEC tandems, and from other operator systems (both LEC and IC). Some OSS-provided services terminate at the system, such as some listing service calls, and others require call completion by the OSS switch to LEC end offices or MSCs, or require routing to ICs’ Points of Presence, other OSSs, or E911 tandems.

After recognizing a request for service, an OSS switch begins initial call processing to determine call type and originating line restrictions. If the call requests a service that the LEC OSS can provide (e.g., directory assistance), the OSS switch will apply the appropriate call processing and generate an Automatic Message Accounting (AMA) record for the call (see Section 2.7). If the call is interLATA (e.g., a call routed to the LEC OSS because it is dialed 0- and the subsequently-provided called number results in it being an interLATA call), either the OSS transfers it to a customer-selected IC, or the customer is asked to re-initiate the call and dial 00- or 0+ the interLATA number to reach the IC.

A key OSS switch function is queuing and call distribution. Upon call arrival, the initial call processing decides the treatment, which often results in a connection to a Voice Server (e.g.,

2–20


SR-NOTES-SERIES-18

to provide a branding announcement). If it is determined that an operator needs to be attached to the call, the OSS switch uses its queuing and call distribution functions to distribute the call to an available operator with the right set of skills. Complex functions are used to ensure that the call distribution occurs in a manner that conforms to the LECs’ business objective (e.g., answer speed objectives).

Other OSS switch functions include administration, maintenance, network management, and reporting functions. In addition to AMA recording, the OSS collects data for traffic measurements, which are sent to management systems that compile various types of traffic data summaries to fit the needs of various users (e.g., facilities manager, network manager, and force manager). These management systems may support complex algorithms to assist the LECs in managing the network or the operator centers. For example, Force Management Systems include forcing algorithms that help the LECs staff the right number of operators with the right skills that are necessary to cost-effectively run an operator center that meets the target business objectives for Operator Services (e.g., answer speed, etc.) The measurements include systems measurements (e.g., total position calls), component measurements (e.g., server usage or total time all servers within a group of services are in use), traffic measurements (e.g., count specific types of calls, such as calls requiring connection to an operator position, toll and assistance), and force measurements (e.g., initial calls, reconnected calls, outgoing calls, supervisor calls from an operator to a supervisor, positions occupied; see Section 2.8).

Service measurements that show the quality of service provided to customers are also taken, including answer speed, operator accuracy/courtesy, and equipment faults. Supervisor monitoring is used for service evaluation functions, where supervisors are allowed to bridge onto a call and talk to an operator without impacting the customer, and view operator screens. Another key administrative area is maintenance; the OSS quickly recovers from hardware and software failures without service interruption by detecting failures, recovering from failures, and reporting failures. The OSS also records maintenance data, such as expiration of timers and query failures.

Network Management is another important administrative area that OSSs support. In addition to supporting tandem switches’ network management, OSS switches support procedures specific to TCAP and SS7 due to its interfaces with LIDBs via SS7 TCAP, and the network management procedures also isolate network management troubles specific to ICs and CLECs that interact with the OSS switch.

OSSs also provide administrative data reports to all the administrative centers involved in managing the OSS, including the Operator Services center, which is responsible for operators’ performance; data is generated describing the performance of individual operators and groups of operators. The force management center maintains a balance between service to the customer and the cost of operators by continuously monitoring statistics related to operator force provisioning.

The facilities administration center continuously monitors the OSS switch performance to ensure that it processes calls consistently with service objectives. The switching control center maintains the OSS and its components by receiving reports of maintenance-related data. The database management center receives reports on the OSS’s database query activity.

2–21


SR-NOTES-SERIES-18

The objectives for OSS switch reliability are that the total system downtime is 3 minutes per year, and the individual line or trunk downtime is 28 minutes per year. The call processing capacity depends on several factors, including call mix, amount of automation, call holding time, position holding time, facility engineering, position occupancy, and tandem traffic.

As indicated previously, DMS TOPS switches are widely deployed for Operator Services. Two types of DMS TOPS switches are used: host TOPS switches and remote TOPS switches. The host TOPS switches directly serve operators and the remote TOPS switches provide the fully automated Operator Services functions.

The host and remote TOPS switches are designed for Operator Centralization, which enables operators from one location to interact with end users that are within the same location or a different location. The ILECs have more remote TOPS switches than host TOPS switches to enable an operator center to serve many end users.

Figure 2-2 illustrates the Operator Services architecture with host and remote TOPS switches.

Figure 2-2 Nortel Networks Architecture for Operator Centralization

With the architecture for Operator Centralization, the end office may directly connect to a remote or host TOPS switch or may connect with either switch via another intermediate switch. Voice and data links reside between the remote and host TOPS switch. When a remote TOPS switch is involved in a call, examples of data passed from the remote TOPS switch to the host TOPS switch include: calling card number, third party number, and calling party number. Examples of data sent from the host TOPS switch to the remote TOPS switch include the found listing number and alternate-billing-specific information for AMA recording purposes. Call completion is handled by the remote TOPS switch, so the host TOPS switch does not need to remain in the call path for the duration of the call.

2.3.1.2 OSS Databases

The OSS depends on its switching and call processing capabilities, as well as on additional hardware and software that is outside of the switch. The external hardware and software is contained in workstations, Voice Servers, and databases that are accessed when needed by the switch. The various workstations, servers, and databases are sometimes developed and provided by multiple suppliers, so open non-proprietary interfaces between the components are preferred. Many of these non-proprietary interfaces are specified in FR-271, OSSGR. The major databases are discussed in this section, the Voice Servers are described in

Remote TOPS

HostTOPS

End OfficeRemote TOPS

Remote TOPS

2–22


SR-NOTES-SERIES-18

Section 2.3.1.3, the workstations are described in Section 2.3.1.4, and the management systems are described in Section 2.3.1.5.

Databases are used to store information that is needed for call processing, such as billing number validation information and directory listings. A particular database may be accessed directly or indirectly by the switch as part of call processing, by the operator workstation at the request of an operator, or as directed by other OSS servers or peripherals. The main databases involved in OSS call processing are:

• Line Information Database (LIDB) (see Section 2.3.1.2.1)

• Local Number Portability (LNP) Database (see Section 2.3.1.2.2)

• Listing Services Database (LSDB) (see Section 2.3.1.2.3)

• EDA Database (see Section 2.3.1.2.4)

• Intercept Database (INDB) (see Section 2.3.1.2.5)

• Operator Reference Database (ORDB) (see Section 2.3.1.2.6)

• Real Time Rating System (RTRS) (see Section 2.3.1.2.7).

The database interfaces that OSSs support include:

• SS7 TCAP for LIDB queries

— Originating Line Number Screening (OLNS) queries for some or all service types, to obtain data on originating line, such as billing and service restrictions, account owner for branding and AMA recording, automated vs. operator handling information, etc. OLNS is not deployed by all LECs. Some LECs may use internal OSS switch tables to accomplish the functions provided by OLNS. This may require additional trunk groups (e.g., to identify the account owner using trunk groups).

— Billing Number Screening (BNS) queries for third number and collect calls, to obtain data on billed line, such as automatic billing acceptance or rejection, account owner for AMA recording, etc.

— Calling Card (CC) queries for calling card calls, to obtain data on billed number, such as validation of calling card number, account owner for AMA recording, etc.

• SS7 TCAP for LNP to obtain the Location Routing Number (LRN) associated with a number that had been ported from one switch to a different switch.

• Proprietary interfaces to required LSDB(s) for Directory Assistance services and other related services, such as Calling Name and Address.

• Proprietary interfaces (using Hypertext Machine Language [HTML]) to an EDA database that caches information.

• Proprietary interface (over X.25) to INDB for Intercept service.

• Proprietary interface (over X.25) to ORDB for general assistance, such as dialing instructions and codes (e.g., NPAs, IC access codes, country codes).

• SS7 TCAP to Real Time Rating System (RTRS) to support real-time rating for coin and hotel/motel sent-paid calls.

2–23


SR-NOTES-SERIES-18

2.3.1.2.1 Line Information Database (LIDB)

The LIDB is a real-time transaction processing database containing valid line and billing numbers for specific data owners. It resides on a Service Control Point (SCP) node that provides the network interface for LIDB to the CCS/SS7 network. LIDBs are accessible to OSS switches and other network elements in their own and other CCS/SS7 networks. Since each LIDB contains unique line number and billing number data specific to a given set of end users, LIDB data is not replicated in more than one LIDB (other than its mated pair). Therefore, when a LEC (e.g., LEC A) needs to obtain information associated with a line or billing number belonging to a different LEC (e.g., LEC B), LEC A sends a LIDB TCAP query to the CCS/SS7 network. The CCS/SS7 network then routes the LIDB TCAP query to the LIDB in which LEC B’s lines and billing numbers are stored. LEC B’s numbers’ LIDB provides LEC A with a TCAP response containing the information (e.g., billing authorization) about the queried line or billing number that LEC A is authorized to receive. Note that in this general scenario LEC A and LEC B may each be a CLEC or an ILEC and may reside in the same LATA or different LATAs.

Generic Requirements for LIDB are in GR-1158-CORE, OSSGR Section 22.3: Line

Information Database. The technical interface specification for LIDB access from LEC OSSs is in GR-1149-CORE, OSSGR Section 10: System Interfaces.

LIDB supports the following query types, the first three of which OSS switches use:

• Calling Card (CC): to validate that a calling card number, consisting of a 10-digit billing number and a 4-digit Personal Identification Number (PIN), can be used to bill a particular call. OSS switches access calling card numbers’ information by launching CC queries over the CCS network using the SS7 protocol to the LIDB containing the calling card number. The calling and called number associated with a calling card call are required to be included in the LIDB CC query, which improves fraud detection processes and enables features that rely on this information. LIDB validation is a tariffed offering that enables LECs, ICs, and other industry participants to have access to LEC calling card information contained in LIDBs.

• Billed Number Screening (BNS): to determine if collect or third-number billing is allowed, not allowed, or in need of real-time verification, for the particular billing number. OSSs access collect and third numbers’ line information by launching BNS queries over the CCS network using the SS7 protocol to the LIDB containing the billed line. The calling and called number associated with a collect and a third number call are required to be included in the LIDB BNS query, which improves fraud detection processes and enables features that rely on this information. LIDB validation is a tariffed offering that enables LECs, ICs, and other industry participants to have access to LEC billing information contained in LIDBs.

• Originating Line Number Screening (OLNS): to obtain information about the line originating the call, including billing restrictions and the line’s service provider. OSSs access originating line information by launching OLNS queries over the CCS network using the SS7 protocol to the LIDB containing the originating line. OLNS deployment schedules vary by company. First implemented in 1996, various companies deployed the OLNS capability in their OSS switches and LIDBs during 1997-2000. Companies not deploying OLNS continue to provide Operator Services using originating line

2–24


SR-NOTES-SERIES-18

information stored internally in OSS switches. Companies with OLNS capability may choose to launch OLNS queries to LIDBs on every call received by the OSS switch, or just on a subset of calls based on ANI Information Digits (ANI II) and/or incoming trunk group.

Before the implementation of OLNS, when a 0-, 0+, or DA call was received at the OSS switch, the OSS switch determined whether or not originating line screening was necessary based on the ANI II digits received. If the OSS switch determined screening was needed, limited originating line information needed by the OSS switch was derived from local screening tables maintained and administered at each OSS switch. These internal OSS switch screening tables stored a limited number of screen codes. The screen codes representing originating line information were limited in their granularity of billing and service restriction information, and were not standard from one OSS switch to another. The OSS switch performed a 10-digit match of the originating line number in its screening table to determine the screening for that originating line. Updating of the internal tables at each LEC OSS switch and IC operator system is time- and labor-intensive, and information in the OSS switch is not current until the update (which may be manual and does not occur immediately) is performed. OLNS eliminates or reduces the need to use internal OSS switch screening tables. With OLNS, LEC OSS switches and, potentially, other Service Provider operator systems access the LIDB containing the originating line via the CCS network using the SS7 protocol. The LIDB then returns the information associated with the originating line in the form of multiple parameters, rather than one screen code, to the querying OSS switch. The OSS switch then continues call processing based on the information received in the OLNS response message. Line-based data is stored at centralized LIDBs as multiple, independent parameters. Data passed from the LIDB in the OLNS response is greatly expanded from the internal OSS switch screening code information. When one new screening condition occurs in a pre-OLNS environment, every existing condition that can interact with the new one needs an additional, new screening code assigned to account for the multiplier effect of the new condition with each existing applicable condition. OLNS eliminates this effect by allowing each line number to have each of its associated parameters independently set; the complete set of parameter values then defines the line’s conditions.

The LEC OSS switch may be provisioned with criteria for launching or not launching OLNS based on the ANI II/incoming trunk group. This enables the OSS switch owner to choose for which calls OLNS queries should be launched if launching OLNS queries on all calls is not desired. Default parameter values are stored in OSS switches to continue call processing for cases where an OLNS query is launched but a screened response is received or an error is encountered.

• GetData: to request specific LIDB data elements, specified in the query, associated with a given line number. OSS switches do not currently launch GetData queries, but other network elements do. A Query Originator (QO, for example, an AIN SCP) may need line information from the LIDB to process a call. This information could be standard data that is associated with every line, such as originating line screening information that is also returned in an OLNS response, or it may be customized data that the LIDB owner has created for a subset of lines it stores, e.g., quantification of the dollar value of account sizes for business customers. Based on the information provided in the GetData query, the LIDB

2–25


SR-NOTES-SERIES-18

then returns a response containing information associated with the requested data elements to the QO.

• Generic Name: to obtain the name associated with a line number originating a call, used in the Calling Name CLASS feature. OSS switches do not launch Generic Name queries. The CNAM service provided by end offices is implemented in many companies by associating a name with a line number in the LIDB; although LIDBs were first defined and deployed to support Operator Services, companies saw the value of the centralized resource of line numbers and CNAM was the first non-operator service to utilize LIDB data. When the CLASS CNAM service is implemented so that the LIDB is the source for the name, a called end office accesses the LIDB containing the calling number via a Generic Name query. The LIDB then returns the name associated with the queried number to the QO (the end office). Note that most, but not all, CNAM implementations obtain the name from the LIDB; in some companies, a different database is accessed. In the future, MSCs/Wireless Intelligent Network (WIN) Service Control Points (SCPs)/Home Location Registers (HLRs) may query LIDB for the calling name (i.e., CNAP service), so the calling name can be delivered with the calling number to mobile customers. It is anticipated that an IS-41 message, rather than the Generic Name query type, will be used by the wireless providers to access LIDB.

2.3.1.2.2 Local Number Portability (LNP) Database

The OSS switch supports LNP for call completion and for AMA recording. The OSS switch follows the requirements in Committee T1 Technical Requirement No. 1, Number Portability Operator Services Switching Systems. See Section 2.4.2.1 of this SR for further information on LNP.

The OSS switch sends an LNP TCAP query via the CCS/SS7 network for portable calling party numbers, portable billed numbers, and portable called numbers. Note that numbers with NPA-NXXs that have at least one ported number are portable numbers. When the OSS switch sends an LNP query to an LNP Service Control Point (SCP), the LNP SCP returns an LRN when the number is ported and returns the original number sent in the LNP query when the number is not ported.

The OSS switch sends an LNP query for portable calling party numbers to find out whether or not the calling party number is ported, and if it is ported, to request the LRN associated with the calling party number for AMA recording purposes. In addition, for calling card calls, collect calls, and third number billed calls, the OSS switch sends an LNP query for the portable billed numbers for AMA recording purposes. When the call is to be completed from the OSS to a called number (e.g., for 0-/call completion, alternately billed services, and DACC), the OSS switch sends an LNP query for portable called numbers for routing and AMA recording purposes. The OSS switch also sends an LNP query for Busy Line Verification (BLV)/Interrupt target numbers. When the target number is ported, the OSS switch needs the LRN associated with the target number to determine whether or not the OSS switch serves the target number and to select the right outgoing trunk to the end office serving the target number. The OSS switch signals the target number to that end office over a special BLV/I trunk group using MF signaling.

2–26


SR-NOTES-SERIES-18

The OSS switch sends an LNP query for called numbers when the call is not to be routed via an IC. As a result, both the calling and called numbers are within the OSS’s geographic territory (also referred to as a zone) and the LNP query for calling and called numbers is sent to a local LNP database. However, the billing number may belong (and often will belong) to a different geographic territory (e.g., when the calling party bills the call to a third number that is in a state other than the calling party number). As a result, the OSS switch may send an LNP query for billed numbers to a local LNP database or to an LNP database in another Carrier’s network. As with LIDB TCAP messages, the LNP TCAP message is routed through the CCS/SS7 network to the correct LNP database. Ten-digit translation is needed to enable the TCAP message to be routed to the proper LNP database, as described in Section 2.4.2.1 for the LIDB queries.

2.3.1.2.3 Listing Services Database (LSDB)

Listing Services Database (LSDB) is a generic name for databases that store directory information the OSSs retrieve when providing listing services, such as directory assistance, to customers. A commonly used term is a Directory Assistance System (DAS). DAS contains LSDB data and functions, as well as Integrated Voice Response (IVR) capabilities.

The LEC operators access local and national listings for directory assistance. Local listings are listings within a given local area. National listings are nationwide listings.

The listings information stored in the LSDB contains telephone numbers, names, and addresses. LSDBs provide storage and high-speed retrieval of customer listing information. LSDBs are accessed by operators on behalf of customers to retrieve a telephone number based on name and address (for DA), or other listing information such as name and address based on telephone number (for CNA). An LSDB has interfaces to one or more OSSs. More specifically, the LSDB interfaces with the OSS switch, operator workstation, and Voice Server (to support DA automation).

The listings within LSDBs are divided into three categories: residential, business and government. Although today’s listings have only wireline telephone numbers, the LSDBs can be extended in the future to include other numbers, such as pager numbers, wireless telephone numbers, fax numbers, and other identifiers, including URLs and e-mail addresses. The key issue with including this type of information in LEC LSDBs is the sourcing of the information.

LSDBs retrieve customer listing data that match attributes entered by the operator or recognized by a Voice Server and populated in the query, and return the information in the query response. If no attached listings are found, the operator may request another search based on slightly modified query information such as alternate spellings or a search within a wider geographic area. Restricted access is provided to certain information, such as nonpublished telephone numbers.

LSDBs from Nortel Networks (Directory One, or D1), Volt Delta (Directory Express) and ISx, Inc. (Listing Services Inquiry Program, or LSIP), are deployed by the major LECs. The databases contain sophisticated mechanisms for simplifying operator searches and therefore reducing operator work time. For example, the LSDBs support capabilities to automatically extend the search by eliminating search information and by using keyword searches and abbreviations.

2–27


SR-NOTES-SERIES-18

The current LSDB interfaces include proprietary messages exchanged over X.25. Operator workstations access the LSDBs through supplier-specific interfaces using X.25. The Nortel Networks Operator Services architecture also includes a simple call control interface between the DAS and DMS TOPS to enable the database to request call completion. Currently, Voice Servers access the listings data to recognize locality and Frequently Requested Listings (FRLs). In the future, Voice Servers may access the listings to handle fully automated call completion for more listings than just the FRLs.

2.3.1.2.4 EDA Database

Examples of EDA Services and Information Services include business category search, travel directions, location-based business category search, weather, and stock quotes. Currently, some EDA services are offered on behalf of wireless providers. One supplier that handles EDA services is Volt Delta. It obtains the data from information providers, and caches that data to enable quick access to the data by the operators. The operator workstation accesses Volt Delta’s EDA database via an HTML interface. Many Incumbent Local Exchange Carriers (ILECs) cannot offer EDA services as part of their 411 service offering to their wireline customers, due to regulatory restrictions. However, they can offer EDA services on behalf of other carriers and service providers (e.g., wireless carriers).

2.3.1.2.5 Intercept Database (INDB)

An Intercept Database (INDB) contains information about intercepted telephone numbers. These numbers can be blank numbers (valid NPA-NXX but invalid line number); vacant numbers (valid but unassigned 10-digit numbers); disconnected numbers (valid, previously assigned 10-digit numbers recently disconnected; may become vacant after some locally defined time period); numbers out of service; and, pseudo-numbers (invalid NPA, service access code, or NXX).

An INDB provides information to a querying OSS providing intercept information to a caller at the time that a call is made to an intercepted line. The INDB data is used when the intercepted line’s end office cannot provide the intercept information because it is too complex to store and announce from there or because more information is needed from the caller. INDBs can support regular intercept, customized announcements, split referrals, and multiple entries. The INDB can provide new number(s) where the customer(s) formerly associated with the intercepted number can be reached. Depending on the circumstances of an intercepted number, the information is provided to the caller via announcement (with no operator interaction or following operator interaction) or by an operator. Operator interaction is needed for cases where more information is needed from the caller (e.g., 2 parties formerly associated with the intercepted number now each are associated with his/her own number, and the operator must determine which party the caller wishes to reach).

2–28


SR-NOTES-SERIES-18

2.3.1.2.6 Operator Reference Database (ORDB)

An Operator Reference Database (ORDB) stores reference material that is retrieved by operators for display on operator positions. This information includes items such as dialing instructions and codes (e.g., NPAs, IC access codes, country codes), emergency numbers, and internal company numbers (e.g., business office). Such information used to be written on paper at the operator positions in the form of multileaf bulletins and sheets on the positions and tacked up on the walls. Storing this data in a database is more efficient and results in more up-to-date information. Operators use their operator workstations to access ORDB.

2.3.1.2.7 Real-Time Rating System (RTRS) Database

A real-time rating system (RTRS) provides the functions needed to rate calls at the time they are made. Services that need real-time rating are discussed in Section 2.1.3.4 and include coin sent-paid calls, sent-paid hotel/motel calls, and Time and Charges. Real-time rating was traditionally performed by the OSS switch; an external real-time rating system is more flexible and is used by LECs. The advantages of an external RTRS include the fact that modifications can be made to it with minimal changes to the OSS switch’s software, so new services and modified existing services can be introduced more easily and quickly; OSS switches do not need to store rating tables and these resources can be used for call processing instead; one RTRS can support the real-time rating needs of multiple OSS switches, resulting in simpler and more cost-effective administration than when maintaining separate rating systems at each OSS switch; and, if desired, in the future, the RTRS deployed to support OSS switch can be a network resource, supporting real-time rating needs of other network elements in addition to OSSs.

A query to an RTRS includes key pieces of data such as calling and called numbers, service type, and time of day. The response includes a charge amount and other parameters.

2.3.1.3 Voice Servers

OSS switches need hardware beyond that needed for an access tandem that does not handle Operator Services calls. Some of the additional hardware is contained at the OSS switch itself, adding to the basic access tandem hardware to make it an OSS switch. However, some needed hardware is instead contained in databases (see Section 2.3.1.2), Voice Servers, and workstations (see Section 2.3.1.4). This section discusses the Voice Servers.

The Voice Servers provide audio information to customers on an automated basis, and detect customer input via post-seizure dialing using DTMF digits and via speech recognition. Today, speech recognition is used in Operator Services primarily for alternate billing services. In addition, speech recognition is beginning to be used for Directory Assistance for locality recognition and recognition of frequently requested listings (FRLs). The industry is also looking at full DA automation for calls making inquiries for any listing, not just FRLs.

The announcements provided by the Voice Servers are of various types, such as prerecorded words and digits included with the system, locally recorded announcements, maintenance and services tones (e.g., to prompt for post-seizure dialing), and text-to-speech announcements.

2–29


SR-NOTES-SERIES-18

Voice Servers support customized announcements, which is an important capability for Operator Services. For example, branding announcements are customized and are usually specific to the caller’s local service provider.

The Voice Servers’ detection capability is used during interactive announcements to detect and decode DTMF and verbal input. The Voice Server passes decoded information to the OSS switch for its call processing and to the operator workstation (via the operator switch or via LSDB) for operator display.

Voice Servers’ detection and other functions are used for many types of Operator Services, such as 0- automation, alternate billing services, directory assistance, directory assistance call completion, reverse directory assistance, and intercept service.

The Voice Server functions include front-end automation, such as:

1. branding announcements,

2. 0-/announcements and DTMF digit collection (e.g., press “X” for business office, “Y” for repair office, etc.),

3. announcements with DTMF digit collection and/or speech recognition to request type of alternate billing and billing number,

4. announcements indicating that a number is no longer in service and possibly indicating a new number,

5. announcements for DA (e.g., to request city, state, and listing),

6. voice store and forward capabilities including capabilities to truncate the voice recording, such as silence deletion,

7. speech recognition for locality and frequently requested listings (FRLs),

8. text-to-speech for CNA.

Examples of back-end automation provided by Voice Servers include:

1. announcing the found listing number for DA,

2. call completion for DA if requested by caller via DTMF digits or possibly via verbal input, and

3. call completion for 0- and for alternately billed services.

Alternately billed calls, 0-/calls, and, in some cases, calls to FRLs, are often fully automated. To provide the speech recognition functions for DA (e.g., locality recognition, FRL recognition), the Voice Servers access the listings in the Listing Services Database. Advancements are anticipated in the Voice Server industry to enable more DA calls to be fully automated.

2–30


SR-NOTES-SERIES-18

2.3.1.4 Operator Workstations

Operator workstations provide the means by which the OSS switch attaches operators to calls. Many of the major LEC’s operators are now using intelligent windows-based operator workstations. Specifically, many operators use Nortel Networks’ Intelligent Workstations (IWSs). Volt Delta Liberty workstations are also used. When the operators use the IWS workstations to access the Information Services eXtended, Inc. (ISx) LSDB, an ISx workstation application is integrated with the other IWS applications.

The IWS and other intelligent windows-based operator workstations often support special keyboards and keys for Operator Services. The workstations include complex intelligence to process data received from many databases, such as:

• Local and National Listings in LSDBs

• Information services accessed from EDA Servers (many LECs do not support this access)

• Reference information (e.g., zip codes) in ORDB.

The workstations access local databases using supplier-specific protocols. They also exchange intelligent messaging with the OSS switch to retrieve data associated with a call for operator display and to make call control requests, such as for call completion or transfer. The workstations can also use the OSS switch protocol to exchange information with other operators and Voice Servers.

The operator workstations are used by supervisors for monitoring purposes. The supervisors use their workstations to monitor operators’ conversations and operators’ screens. The supervisors can also whisper to the operators.

Each operator workstation consists of a video display terminal, keyboard, computer, and other hardware and software including data and audio interfaces, controllers, and printers. There are various screen formats for the services provided by operators. The workstations have voice and data interfaces to the OSS switch.

The intelligent workstations have advantages over the operator positions previously used for Operator Services. Specifically, the intelligent workstations provide the ability to buy more off-the-shelf hardware rather than hardware specifically designed for Operator Services.

Evolution toward Internet Protocol (IP) is anticipated for operator workstations to enable calls to be distributed to any operator independent of the geographic location of the operator, and to enable any supervisor to monitor any operator independent of their respective geographic locations.

2.3.1.5 Management Systems

LECs use management systems to enable them to cost-effectively manage their networks and operator centers. The management systems contain sophisticated algorithms and generate reports for system administrators and/or provide data for downstream processing and report generation. The management systems provide administrative data reports to all the administrative centers involved in managing the OSS. The management systems include data processing, storage facilities, and terminal facilities used to input, receive, store, and generate

2–31


SR-NOTES-SERIES-18

statistical reports on system operation. The management systems’ functions include the capability to receive and store data that the OSS generates; accept and store data inputs; perform calculations on data; and, output data as periodic reports, exception reports, and reports in response to user requests. The reports may include items such as operator performance; system performance; traffic; call processing performance; and, financial performance. The reports are generated for personnel in Operator Services Centers, Force Management Centers, Facilities Administration Centers, Switching Control Centers, Database Management Centers; and, Network Management Centers.

2.3.2 AIN

The Advanced Intelligent Network (AIN) is the current state-of-the-art architecture for deploying advanced voice services. AIN was designed to provide network service providers with the ability to create and deploy custom services rapidly and efficiently. AIN builds on the Intelligent Network (IN) architecture that centralizes functionality in a Service Control Point (SCP). AIN capabilities within the SCP, switching system, and CCS/SS7 network support a set of functions (e.g., routing calls, playing announcements, connecting end users to Voice Servers, and collecting information from end users) common to many voice services. AIN allows network service providers to create new services by arranging these functions in various sequences and by changing various information (e.g., announcements, routing numbers) associated with the functions.

With AIN, the service logic is contained in a programmable SCP. Thus, the service logic needs to be installed and/or modified only in the SCP. The SCP, along with additional AIN capabilities in the switching system and CCS/SS7 network, provides flexible network capabilities that the network service providers need to deploy new services.

Similar to AIN having its service logic centralized in SCPs, the Operator Services logic is centralized in OSS switches, rather than placing this logic in every end office. A key difference between the AIN architecture and the current Operator Services architecture is that the OSS switches are accessed from the end offices via trunk connections, while the SCPs are accessed from the end offices via the CCS/SS7 network. With AIN, the voice connection remains at the end office and call completion occurs from the end office.

With the introduction of AIN, the natural question arose as to whether or not it makes sense to use the AIN architecture to provide Operator Services by centralizing the operator service logic in AIN SCPs, rather than in OSS switches. Although it may have made sense to design Operator Services using AIN if AIN were available when the services were first introduced, it could not be cost-justified to recreate services using AIN that were already deployed in the OSS switch.

Instead, it does make sense on a case-by-case basis to consider whether existing or new Operator Services and capabilities should utilize the AIN architecture. In particular, new Operator Services and capabilities that involve connecting calling parties to announcements and routing calls, are candidates. The decision as to whether or not it makes sense to use AIN for an Operator Service varies for each LEC.

2–32


SR-NOTES-SERIES-18

One such service that is a good fit for AIN is 0- automation. 0- automation is deployed using the AIN architecture in some areas, and deployed using Nortel Networks’ Operator Services architecture in other areas.

The 0- automation service connects a customer to an announcement when the customer dials 0. The announcement requests the customer to dial a specific DTMF digit for certain options. For example, the customer is requested to dial a particular DTMF digit for an emergency, another DTMF digit for the business office, a different DTMF digit for alternate billing services, 0 for the operator, etc.

0- automation saves operator work time by fully automating many calls that would otherwise be handled by operators. In addition, implementing 0- automation via AIN saves OSS switch processing as well as trunks. This is because the OSS switch does not process many of the 0- calls, such as the calls destined to the business office or emergency services, and because the calls are completed from the end office, rather than from the OSS switch.

Figure 2-3 illustrates how AIN may be used to provide 0- automation. The text following Figure 2-3 describes the AIN systems involved with providing 0- automation.

Figure 2-3 AIN Architecture for 0- Automation

AIN includes the following systems:

• AIN Service Switching Point (SSP) determines when AIN involvement is needed based on the dialed digits or received signaling information. End offices and access tandems may be SSPs. When AIN involvement is needed, the AIN SSP sends a message to an AIN SCP and processes requests from the AIN SCP.

• AIN SCP contains the service logic, receives messages from the AIN SCP, and sends requests to the AIN SSP.

• AIN Intelligent Peripheral (IP) contains voice resource functions, such as announcements, DTMF digit collection, and speech recognition. The AIN IP is connected to the SSP via an Integrated Services Digital Network (ISDN) interface. The AIN IP may be directly

EndOffice/SSP

SCP

Business Office,Repair Bureau,Emergency PSAP, etc.

IP

SSP

(1), (5)

(2), (6)OSSSwitch

(3)

(4)

(7)

2–33


SR-NOTES-SERIES-18

connected to the SSP/end office that serves the end user and interacts with the AIN SCP or may interact with that SSP/end office via another SSP, as is shown in Figure 2-3.

The following provides an example call flow to illustrate how AIN could be used to provide 0- automation. This call flow is provided as an example and is not intended to reflect the actual flow used in particular AIN deployments for 0- automation.

1. After the caller dials 0, the end office/SSP determines that AIN involvement is needed and sends an AIN message to the AIN SCP.

2. The AIN SCP invokes the 0-/automation service logic and requests the AIN SSP/end office to connect the end user to the AIN IP. If desired, the AIN SCP can pass service-specific information to the AIN IP via the AIN SSP.

3. The AIN SSP/end office sets up the call to the AIN IP and passes information received from the AIN SCP to the AIN IP.

4. The AIN IP plays announcements (e.g., press ‘A’ for business office, press ‘B’ for repair bureau, etc.). The AIN IP collects the DTMF digit (or verbal input) and provides the information to the AIN SSP/end office.

5. The AIN SSP/end office provides the information to the AIN SCP.

6. The AIN SCP may then request the SSP/end office to complete the call to the appropriate place (e.g., toward the business office, toward the repair bureau, toward emergency personnel, or to the OSS switch).

7. The SSP/end office then completes the call.

2–34


SR-NOTES-SERIES-18

2.4 Current Capabilities

Sections 2.4.1 through 2.4.4 describe some of the key capabilities that OSSs support. These include speech recognition, text-to-speech, Local Number Portability (LNP), and operator system hold/ringback/recall.

The Call Completion services discussed in Section 2.1.1 may be provided by forward routing a call from the OSS switch as is normally done today, or may be released back to a previous switch for call completion. The standard network capability for releasing a call to a previous switch for call completion is named Release to Pivot. Nortel Networks’ comparable capability is referred to as Release Link Trunking. With both of these release capabilities, the OSS does call processing and rather than then forward routing the call, the OSS “releases” the call back to the originating end office, which then processes the call completion aspects of the call. The Release to Pivot and Release Link Trunking features are described in Section 2.4.5.

2.4.1 Speech Technology

Speech technology is an important area for Operator Services. Alternate Billing Services have simple speech recognition (SR) capabilities to recognize the type of alternate billing service requested from the customer, including calling card, collect, and third number, as well as to get input from the billed party as to whether a collect or third number call is accepted or rejected. This speech recognition enables full automation of the majority of the alternately billed calls. Note that DTMF digit collection is also used to fully automate many alternately billed calls.

Using speech technology to automate directory assistance is more challenging. Some companies have automated the initial inquiry between the customer and the operator for a DA request. Usually, an announcement asks the customer for a city and listing, city and state, or city, state, and listing. Some of the automation capabilities record the customer’s voice, truncate the voice recording (e.g., by deleting silence), and then play the recorded voice for the operator. In addition to this front-end DA automation, a back-end announcement is usually provided to automatically provide the found telephone number. Many seconds of work time are saved with this front-end and back-end automation. However, the operators still are involved in the call because they listen to the voice recording, query the database, interact with the customer (if necessary), and release the call to an audio announcement.

Some LECs save additional work time on DA calls using speech recognition capabilities in addition to the automated announcements and voice store and forward. The recognition capabilities recognize the city and state (referred to as locality) and deliver the information to the operator screen. Some companies may automatically route the call to a local or national operator center, based on the locality. The speech recognition capability available on Operator Services technology also includes full automation of DA calls looking for frequently requested listings (FRLs) as well as DACC to those numbers.

Two different speech technology systems are deployed using Nortel Networks’ Automated Directory Assistance Service (ADAS) and ADAS Plus. ADAS has front-end announcements and store and forward capabilities, while ADAS Plus supports SR capabilities, including locality recognition and FRLs. A DA automation application, which supports locality

2–35


SR-NOTES-SERIES-18

recognition and is from Fifth Generation Computer Corporation (FGC), is also deployed in the United States.

Many industry efforts exist to fully automate DA inquiries for all listings (not just FRLs), as well as to fully automate the call completion to those numbers. Although trials exist to fully automate more calls than just FRLs, system upgrades are needed to provide this capability with the existing OSS infrastructure.

Another important speech capability is text to speech (TTS). Some LECs use TTS capabilities to provide Calling Name and Address (CNA) (also known as Reverse DA), which provides the name and address for a requested telephone number.

2.4.2 LNP and Resale

Local Number Portability (LNP) is a capability that enables users to move from one switch to another, while keeping their original directory number. The following three types of LNP are described in various LNP documentation: Local Service Provider Portability (LSPP), Location Portability, and Service Portability. LSPP allows users to port their numbers to another Local Service Provider. Location Portability allows users to port their numbers when changing physical locations, and may or may not include a change of Service Provider and may or may not involve a rate center change. Service Portability allows users to port their numbers from one type of service to another (e.g., Plain Old Telephone Service [POTS] to Integrated Services Digital Network [ISDN]). Committee T1 Technical Requirements No. 1, Number Portability

Operator Services Switching Systems contains the LNP requirements, including the LNP requirements for OSSs, for LSPP without a rate center change and Location Portability without a rate center change. Portability Outside the Rate Center (PORC) is defined in generic requirements (Section 8 of GR-2936-CORE), but the requirements have not been implemented and full industry acceptance has not been achieved for PORC.

Section 2.4.2.1 discusses the impact of LNP on the routing of calls from OSS switches and on the routing of SS7 queries from OSS switches. Section 2.4.2.2 describes the impact that LNP and resale have on the OSS switches’ ability to determine the service providers of calling and billed lines, and the LIDB parameter that provides this information to the OSS switch, because the OSS switch can no longer deduce it from the lines’ NPA-NXXs.

2.4.2.1 Local Number Portability (LNP)

In the environment that preceded LNP, a calling party dialed a number and made an operator service request for toll and assistance or for directory assistance. The request may or may not have resulted in call completion. In this environment, for a call completion call, the OSS switch would route the call to a called number that was either provided by the calling party or obtained from the LSDB. The OSS switch would also record the calling number, billed number (when the call was alternately billed), and called number in an Automatic Message Accounting (AMA) record for billing and other purposes.

The introduction of LNP significantly complicates OSS switch processing. With LNP, the calling number may be ported to a different switch than the one associated with the NPA-NXX

2–36


SR-NOTES-SERIES-18

of the calling number or to a different service provider on the same switch, the billed number may be ported, and the called number may be ported.

If the called number is ported, then the called number does not contain sufficient information to enable the OSS switch to route the call. The industry solved this problem in general by defining a new ten-digit number, the Location Routing Number (LRN), which can be used to route the call to the switch that serves the ported called party. The LRN is stored in an LNP database.

Switches, including end offices, OSS switches, and IC switches, are not expected to know whether or not each called number is ported, because this would be too much information to store and maintain at every switch. Instead, the switches are expected to know whether or not the called number is “portable.” The called number is defined to be portable when at least one number within the NPA-NXX of the called number is ported. The OSS switch must store the necessary data to know which numbers are portable. As an alternative, the OSS switch could send an LNP query for every number, if desired.

When the OSS switch attempts to route a call to a portable called number, the OSS switch follows similar requirements to end offices, and sends an LNP query to request an LRN. The OSS switch then uses the LRN it receives from the LNP database to route the call and for AMA recording.

LNP significantly complicates the OSS switch processing because not only does the OSS switch need to change processing to handle portable called numbers, but it also is impacted by portable calling numbers and portable billed numbers. In addition, when the number is portable, the number may be stored in a different LIDB than the one that would have previously been identified by the NPA-NXX of the billed number, so it is now harder for the SS7 network to route the TCAP message to the correct LIDB.

If the calling number is ported to a different service provider, it is important for the AMA record to include the service provider of the calling number, so the LEC can properly handle billing settlements through downstream systems. Ideally, the OSS switch obtains the local service provider for AMA recording by querying LIDB, as discussed further in Section 2.4.2.2. However, in case the local service provider is not available to the OSS switch, the OSS switch can send an LNP query to the LNP database for portable calling numbers to request the LRN associated with the calling number for AMA recording purposes. The reason for doing this is that the industry agreed that the inclusion of the LRN could help the LECs with their settlements processes when the local service provider identifier is not available to the OSS switch.

The OSS switches often send an Originating Line Number Screening (OLNS) TCAP query to LIDB. Before LNP, the LIDB OLNS queries were routed through the CCS/SS7 network using the NPA-NXX of the calling line number. The OSS placed the NPA-NXX of the calling line number in the appropriate place in the Signaling Connection Control Part (SCCP) of SS7. Through global title translation, the Signal Transfer Points (STPs) used these six digits to route the TCAP message to the LIDB that stored the calling line number.

Now, with LNP, if a calling number has been ported from one local service provider to another, it may also be stored in a different LIDB. For this reason, all 10 digits of the calling number are needed to find the LIDB that stores the calling line number. As a result, the OSS switch is now required to place all 10 digits of the calling number in the appropriate place in the SCCP part

2–37


SR-NOTES-SERIES-18

of SS7. The STPs may either perform a 10-digit global title translation or may route the TCAP message to an SCP to handle the 10-digit global title translation. After the global title translation, the TCAP message is routed through the CCS/SS7 network to the LIDB that stores the calling line number.

Some OSS switches may not have been upgraded and may still place only the NPA-NXX of the calling number in the SCCP part of SS7. In this case, the STPs route the TCAP message to an SCP. Rather than just looking at the information in the SCCP layer, the SCP examines the TCAP part of SS7, which contains the 10-digit calling number, and then performs the 10-digit global title translation and routes the call via the CCS/SS7 network to the LIDB that stores the calling line number.

In addition to the called number and calling number potentially being portable, the billed number may be portable. Portable billed numbers add many complications to alternate billing services. A billed number is applicable for calling card, collect, and third number billed calls. In these cases, the billed number is either a calling card, the called line number, or a line number other than the calling and called line numbers, respectively.

Normally, when a calling party requests a call to be billed to a number other than the calling number, the OSS switch sends a Calling Card query (for calling card calls) or Billed Number Screening query (for collect calls or third number billed calls) to LIDB to authorize the call. However, sometimes, before LNP, internal tables were used to block the LIDB query for all calls that were attempted to be billed to certain NPA-NXXs. With LNP, the OSS switch now needs to send the LIDB query for all portable billed numbers.

As with LIDB OLNS queries, before LNP, the LIDB Calling Card and Billed Number Screening queries were routed through the CCS/SS7 network using the NPA-NXX of the billed number. The OSS placed the NPA-NXX of the billed number in the appropriate place in the SCCP of SS7. Through global title translation, the STPs used these six digits to route the TCAP message to the LIDB that stored the billed number.

Now, with LNP, if a billed number has been ported from one local service provider to another, it may also be stored in a different LIDB. For this reason, all 10 digits of the billed number are needed to find the LIDB that stores the billed number. As a result, the OSS switch is now required to place all 10 digits of the billed number in the appropriate place in the SCCP part of SS7. As with the LIDB OLNS queries, the STPs may either perform a 10-digit global title translation or may route the TCAP message to an SCP to handle the 10-digit global title translation. After the global title translation, the TCAP message is routed through the CCS/SS7 network to the LIDB that stores the billed number.

Some OSS switches may not have been upgraded and may still place only the NPA-NXX of the billed number in the SCCP part of SS7. In this case, the STPs route the TCAP message to an SCP. Rather than just looking at the information in the SCCP layer, the SCP examines the TCAP part of SS7, which contains the 10-digit billed number, and then performs the 10-digit global title translation and routes the call via the CCS/SS7 network to the LIDB that stores the billed number.

After the correct LIDB receives the TCAP CC or BNS query, the LIDB returns its normal response, which may or may not result in authorization for the call. After the OSS switch receives the response, there are two additional issues that result from LNP.

2–38


SR-NOTES-SERIES-18

1. If the type of alternate billing is collect or third number, the operator or automated system may need to call the billed party to verify the charges for the call. In this case, the OSS switch needs to send an LNP query, so that it can properly route the call to the end office serving the billed party. The response from the LNP database would be used for call routing and AMA recording purposes.

2. Even if the operator or automated system does not need to call the billed party, the OSS switch needs to record on its AMA record the local service provider identifier associated with the billed number to enable downstream systems to appropriately handle billing settlements. The way in which the local service provider identifier is obtained is discussed in Section 2.4.2.2. As with the calling party number, in case the identity of the local service provider is not available to the OSS switch, it can send an LNP query to the LNP database for portable billed numbers to request the LRN associated with the billed number. The reason for doing this is that the industry agreed that the inclusion of the LRN could help the LECs with their settlement processes when the local service provider identifier is not available to the OSS switch.

LNP also impacted the BLV/I service. With BLV/I, as described in Section 2.1.3.6, the calling party requests the operator to verify that a target party’s line is busy. The calling party may also request the operator to interrupt the call. Before LNP, the operator or OSS first determined whether or not the OSS switch could make a BLV/I request directly to the end office that served the target number, using the NPA-NXX of the target number. If the OSS switch could not directly make the BLV/I request to the end office, the operator would use the NPA-NXX of the target line number to obtain the terminating toll center code (TTC) of the OSS switch that could directly make the BLV/I request to the end office. The operator would obtain the TTC by querying a database, such as ORDB. The OSS switch serving the calling party then would make the inward call to the OSS serving the target line and the calling party’s operator would request the operator associated with the target line to perform the BLV/I service.

With LNP, the OSS can no longer use the NPA-NXX of the target number to identify whether or not the OSS switch can directly make the BLV/I to the end office serving the target line. Instead, the OSS switch now needs to send an LNP query to request the LRN associated with the target number. The OSS and operator can now use the LRN to determine whether or not the OSS switch can directly make the BLV/I request. When it is determined that the OSS switch cannot directly request the BLV/I request, the operator can use the LRN to obtain the TTC code of the OSS switch that can directly make the BLV/I request.

2.4.2.2 Resale: OSS Identification of Originating and Billed Lines’ Local Service Providers

OSSs need the identity of calling lines’ and billed lines’ local service providers. The service providers’ identities are recorded on AMA records for down-stream settlements of alternately billed calls between originating and billing companies and for branding calls, and can be used for input to other call processing decisions such as whether a call should be completed based on whether billing agreements exist between the various service providers involved in a call. Without local service provider portability and reselling, the service provider information can be derived from the NPA-NXX of a line number. Local service provider portability refers to the ability for an end user to change service providers without changing telephone numbers; in a local service provider portability environment, NPA-NXX is not sufficient to determine the

2–39


SR-NOTES-SERIES-18

true service provider because an end user with that NPA-NXX may have switched to another service provider without changing the telephone number. Reselling is an arrangement where a line may have a different service provider than the owner of the switch, retaining the same telephone number as when the line was served by the switch owner, and therefore NPA-NXX is also not sufficient to determine the true service provider because an end user with that NPA-NXX may have switched to another service provider without changing the telephone number. Therefore, in today’s environment that includes LSPP and resale, OSSs need another way to determine the identity of calling lines’ and billed lines’ service providers.

The solution to this problem is that LIDBs (see Section 2.3.1.2.1) contain a parameter called the Account Owner (AO) for each line number stored. An AO represents the company that is responsible for the line’s service. Since the company owning the OSS may be performing Operator Services for lines it “owns” as well as lines “owned” by other service providers, the OSS must obtain the AO associated with the originating line to provide branding to the calling line as well as to record that AO on the AMA record for proper downstream processing, and to obtain the AO associated with the billing line (for alternately-billed calls) to record that AO on the AMA record for proper downstream processing.

When an OSS switch launches an OLNS query to the originating line’s LIDB to retrieve originating line information, the AO associated with the originating line is included in the OLNS response message if it is populated for the queried line. The OSS uses this AO to brand calls being served both manually by operators and automated via announcements. This branding determination based on AO is necessary for OSSs serving lines of more than one service provider; in a local service provider portability and resale environment, neither originating NPA-NXX nor incoming trunk group can be used to determine who the account owner is for branding purposes, since multiple service providers can share NPA-NXX’s and trunk groups. The OSS switch also records the originating line’s AO in the AMA record for each call for which an OLNS query was launched and response received containing an AO. Before LSPP and resale, the downstream billing system can determine the originating line’s service provider from the originating NPA-NXX, but in those environments, the service provider cannot be derived from the NPA-NXX. Therefore, the originating line’s AO received from LIDB needs to be recorded in the AMA record, because the billing system needs the identity of the originating line’s service provider for billing processing.

When an OSS switch launches a BNS or CC query to the billed line’s LIDB to retrieve billed line information, the AO associated with the billed line is included in the BNS/CC response message if it is populated for the queried line. The OSS switch records the billed line’s AO in the AMA record for each call for which a BNS or CC query was launched and response received containing an AO. Before LSPP and resale, the downstream billing system can determine the billed line’s service provider from the billed line’s NPA-NXX, but in those environments, the service provider cannot be derived from the NPA-NXX. Therefore, the billed line’s AO received from LIDB needs to be recorded in the AMA record, because the billing system needs the identity of the billing line’s service provider for billing processing.

2–40


SR-NOTES-SERIES-18

2.4.3 Operator System Hold, Ringback, Recall

The operator system hold capability, also referred to as connection hold, allows the OSS switch to remain in control of the call rather than the usual arrangement where the originating end office controls the call. This means that the OSS switch can still control the call even after the calling party disconnects. The OSS switch can then use its ringback capability to ring back the calling party. The hold and ringback capabilities are used for 0- emergency services and coin control.

After an OSS switch completes a call from a calling line to a called line for services such as operator-assisted call completion, alternate billing call completion, or directory assistance call completion, the calling party can request to be reconnected to an operator by depressing the switch hook or flash button. The end office detects the flash and sends the flashhook signal to the OSS switch to inform the OSS switch of the reconnection request. This is referred to as the operator recall capability. An issue with the operator recall capability is that the flashhook signal is used for other services, such as three-way calling. These other services take precedence over operator recall.

The operator system hold, ringback, and operator recall capabilities are used with various MF signaling schemes and with Operator Services SS7 signaling. Currently, the MF signaling schemes are deployed.

For MF signaling, the OSS switch sends the ringback tone (700 or 1700 Hz) to the originating end office. As part of the operator system hold capability, the end office sends on-hook and off-hook signals to the OSS switch after the calling party goes on-hook (or ISDN Customer Premise Equipment [CPE] sends a Disconnect message) and after the calling party goes off-hook, respectively. With an analog line, the end office retains the connection between the line and trunk after the calling party goes on-hook and before receipt of an on-hook over the MF trunk from the OSS switch. If the calling party then goes off-hook before receipt of an on-hook from the OSS switch, the end office signals this off-hook to the OSS switch (see GR-505-CORE, Section 6.3).

For MF signaling, when the originating end office detects a flash-hook from the end user and determines that it is an operator recall request, it sends a flash-hook signal (see GR-506-CORE, Section 11.4) to the OSS switch.

For Operator Services SS7 signaling, the end office informs the OSS switch of the availability of the operator system hold capability by including an appropriately populated Service Activation Parameter (SAP) in the IAM (see GR-1277-CORE, Section 3). The OSS switch sends an Operator Services SS7 ISUP Address Complete Message (ACM) or Facility (FAC) message with an appropriately populated SAP parameter to the end office, which then invokes the operator system hold capability. While operator system hold is activated, the end office notifies the OSS switch of on-hook and off-hook conditions by sending a FAC message with an appropriately populated SAP parameter.

When the OSS switch sends a FAC message with an appropriately populated SAP parameter, the end office processes a ringback request using the same procedures used to process the MF ringback signal.

2–41


SR-NOTES-SERIES-18

For Operator Services SS7 ISUP signaling, the end office supports the operator recall capability by sending a FAC message with an appropriately populated SAP parameter when it detects a flash-hook and determines that it is an operator recall request.

2.4.4 Coin Control

Although the use of coin stations is less prevalent than it used to be, two types of coin stations are still used: Station-controlled coin phones and Network-controlled coin phones. The Station-controlled coin phones use normal access interfaces and do not require any special network functions, since the special functions needed for calls paid with coins are contained in these types of coin phones. The Network-controlled coin phones cannot use normal access interfaces and do require special network functions.

When 1+ sent-paid local calls are placed from network-controlled coin phones, coin control functions in the end offices exchange coin control signaling with the coin phones. For example, the end office requests the coin phone to collect coins or return coins.

When 1+ sent-paid toll calls are placed from network-controlled coin phones, the OSS switch exchanges coin control signaling using MF or Operator Services SS7 signalling to request the end offices to exchange coin control signaling with the coin phones. Currently, MF signaling is deployed.

Over the years, several different methods of coin control have evolved to meet changing needs. In addition to coin collect, coin return, and ringback, the multiwink and expanded inband methods provide signals to control the polarity of the battery applied to the coin telephone by the end office. There are three different methods of coin control signaling used from the OSS switch to the end office. They are inband, multiwink, and Expanded Inband Signaling (EIS) coin control. All can be used from host or remote local exchange company locations and can be used with E&M lead signaling on either physical or carrier facilities. All three types of coin control can be used with 2-wire physical facilities employing loop signaling. However, with Calling Card and other types of alternate billing, which potentially require callers to input DTMF digits and therefore require enabled keypads for post-seizure dialing, only multiwink and EIS coin control can provide DTMF pad and totalizer control without station set modifications. Coin-control signaling is covered in GR-528-CORE.

2.4.4.1 Inband Coin Control Signals

Inband coin control uses multifrequency signals to control coins and ring back the coin station using signals for “collect,” “return,” and “ringback”. An on-hook wink (off-, on-, off-hook) of 70 to 130 ms is sent (50 to 150 ms in duration when received) from the OSS switch to alert the end office to prepare a receiver for the multifrequency signal that begins 95 to 195 ms after the end of the wink. The multifrequency signal will persist for approximately 1 second for collect and return, and 2 seconds for ringback.

2–42


SR-NOTES-SERIES-18

2.4.4.2 Inband Coin Control Ringback Protocol

The OSS switch sends one ringback signal. The end office applies standard ringing (2 seconds on, 4 seconds off) to the station and audible ring toward the OSS switch until the station answers or the OSS switch release is received. The OSS switch times for 30 to 36 seconds waiting for answer. If answer is not received, it releases back. The end office performs a coin return before releasing the coin station. If answer is received and a coin-control signal sent, release-back will not occur until at least 300 ms after completion of the signal.

2.4.4.3 Multiwink Coin Control

Multiwink coin control uses multiple on-hook wink signals sent from an OSS switch to an end office. In addition to coin collect, coin return, and ringback signals, this signaling format provides signals called operator-attached and operator-released. The operator-attached signal is used with dial-tone-first coin telephones to instruct the end office to change the mode of the coin totalizer or coin signaling priority to the toll mode by application of positive battery to the coin telephone. It is not sent the first time a coin call is forwarded to the OSS switch because the end office is expected to connect a coin call to the OSS switch in the operator-attached condition. However, the operator-attached signal is sent before each subsequent OSS switch attachment requiring a coin deposit. The operator-released signal (negative battery supplied to the coin telephone) restores the coin totalizer or coin signaling priority to the local mode and enables the DTMF pad on certain coin telephones. The operator-released signal is sent whenever the OSS switch releases from a connection having positive battery applied to the coin telephone. It is also sent upon initial connection to a 0+ coin call on a dial-tone-first trunk when the trunk provides for Calling Card and other billing options requiring DTMF input.

2.4.4.3.1 Signals

The multiwink signaling format employs a series of one to five supervisory on-hook winks from the OSS switch to the end office outgoing trunks (as shown in Table 2-2).

Table 2-2 Multiwink Signals and Their Functions

Number of On-Hook Winks

FunctionSubsequent OSS switch Guard Interval

End Office Work Time (Maximum)

1

2

3

4

5

Operator - Released

Operator - Attached

Coin Collect

Coin Return

Ringback

500 ms

500 ms

1.1 seconds

1.1 seconds

2.4 seconds

380 ms

380 ms

880 ms

880 ms

2.1 seconds

2–43


SR-NOTES-SERIES-18

The wink on-hook intervals, as sent by the OSS switch, are 70 to 130 ms and the wink off-hook intervals are 95 to 150 ms. To allow for pulse distortion, the end office trunk circuit should be capable of operating with on-hook intervals from 50 to 150 ms spaced from 75 to 185 ms apart when received. At the end of a wink signal, the OSS switch will allow time for the end office to complete detection and application of the signal before sending a new signal. The minimum interval after sending a signal by the OSS switch, and the maximum time in which the end office must detect and apply the signal, are shown in Table 2-2.

2.4.4.3.2 Ringback Protocol

The Ringback Protocol for Inband Coin Control as described in Section 2.4.4.2 applies to Multiwink Coin Control.

2.4.4.4 EIS Coin Control

As with inband coin control, EIS coin control employs an on-hook wink to alert the end office that multifrequency tones will be sent. With EIS, the wink is extended to produce an on-hook of between 325 and 425 ms (300 and 450 ms when received). In addition, the interval between the end of the wink signal and the start of the multifrequency tones is lengthened to between 770 and 850 ms, while the duration of the tones is reduced to between 480 and 700 ms.

2.4.4.4.1 Signals

OSS switches are able to work with EIS. EIS provides operator-attached and operator-released signals as does multiwink coin control. However, in EIS a coin station initiating a 0+, 0-, or nonchargeable call on a trunk providing Calling Card Service is initially connected to the OSS switch with negative battery applied to the station. As with the other signaling methods, 1+ calls are initially connected with positive battery applied. The operator-attached signal is sent whenever the OSS switch is connected for a coin deposit, and the operator-released signal is sent whenever the OSS switch is released from a connection having positive battery applied to the coin station. A signal, not available with multiwink, is combined coin-collect and operator-released. This signal, which causes the end office to collect coins and then apply negative battery to the coin station, is currently used for interim overtime collections on calls still in the talking state. The guard intervals following the operator-released and operator-attached signals are 600 ms. Guard intervals following the other signals are 2 seconds.

2.4.4.4.2 Ringback Protocol

The Ringback Protocol for Inband Coin Control as described in Section 2.4.4.2 applies to EIS Coin Control.

2–44


SR-NOTES-SERIES-18

2.4.5 Release Capability

Currently, most Operator Services call completion calls are forward routed from the OSS switch to the called number. The incoming and outgoing trunk group as well as the OSS switch resources remain in the call path for the duration of the call. A more efficient architecture for Operator Services would be for the OSS to perform its operator service, provide the results to a previous switch in the network, and release the call to that switch for call completion. For this reason as well as other comparable network efficiency reasons, a new Integrated Services Digital Network User Part (ISUP) network capability was defined in Telcordia generic requirements and in ANSI and ITU Standards. In addition, Nortel Networks developed an ISUP release capability. The generic capability is referred to as Release-to-Pivot (RTP) and is described in Section 2.4.5.1. Nortel Networks’ ISUP release capability is referred to as Release Link Trunking and is discussed in Section 2.4.5.2.

2.4.5.1 Generic Release-to-Pivot Capability

The RTP Network Capability is an SS7 ISUP network capability that permits the OSS switch to optionally release a call back to a switch earlier in the call path for call completion, rather than forward routing the call from the OSS switch. Sufficient information is provided in the release to enable the new connection to be established from the earlier switch. For RTP, when the call is originally routed from a LEC end office to the OSS switch directly or via a LEC tandem switch without the involvement of an Interexchange Carrier (IC), it is assumed that the RTP network capability will always begin at the originating end office and the call will always be released all the way back to the originating end office. Initially, a LEC intermediate switch is not expected to pivot the call and therefore is not required to implement the RTP network capability.

GR-3015-CORE and GR-3016-CORE define RTP for the following Operator Services. ANSI T1.661-2000, SS7-Release to Pivot (RTP), also defines the RTP network capability. The GR is aligned with the ANSI standard:

• Local Directory Assistance Call Completion (DACC)

• National DACC

• Calling Card

• Third Number Billing

• Operator Assisted Call Completion

• 0-/Transfer

• 1-800/alternate access.

The initial service driver for RTP was DACC. With DACC, the OSS switch provides the found telephone number to the previous switch with the Release message used to release the trunk group and OSS switch from the call, so that the previous switch can perform the call completion aspect of the call after the OSS has provided the DA portion of the service.

2–45


SR-NOTES-SERIES-18

Figure 2-4 and the call steps below illustrate a scenario in which a DACC service uses RTP for call completion.

Figure 2-4 Message Flow for DACC using RTP

1. Calling Party dials 411.

2. The end office (EO) uses SS7 ISUP signaling to set up the call toward the OSS switch. To set up the call, the end office sends an ISUP Initial Address Message (IAM), including a Redirect Capability Parameter (CP). The IAM including this CP parameter is referred to as an IAM+CP message in Figure 2-4. The CP parameter identifies the call as being eligible for RTP call processing. The OSS switch cannot release a call back for call completion that was set up using an IAM message that excludes the CP parameter.

3. The tandem switching system signals the IAM+CP message forward to the OSS switch.

4. The OSS switch processes the IAM+CP message and performs the DA service. As part of the DA service, the OSS switch obtains the desired telephone number, provides the telephone number to the customer, and determines, based on customer interaction, that the call is to be completed to the found listing.

5. The OSS switch then releases the incoming trunk group by sending an SS7 ISUP Release message in the backward direction. The OSS switch includes an RTP-specific cause code and includes the found telephone number in the SS7 ISUP Release message. The SS7 ISUP Release message with this RTP-specific information is referred to as a REL+RI (Release with Redirection Information) message. The OSS records the appropriate Automatic Message Accounting (AMA) information for the DA service. If desired, the OSS switch can also include a Carrier Identifier in the Release message to request call completion via a specified carrier’s network. The recorded AMA information is used to bill the calling line for the DA service.

6. The tandem switch signals the received REL+RI message in the backward direction to the originating EO.

7. The EO processes the received REL+RI message and sets up the call toward the EO serving the found telephone number by sending an IAM message in the forward direction. The EO records the appropriate AMA information for the call completion. The recorded AMA information is used to bill the calling party for the call between the calling and called lines.

EO

OSS

EO411

IAM+CP REL+RI

IAM

Tandem

IAM+CP(3)

(1)

(2)(4)

(5)

(6)

REL+RI

(7)Calling Party Called Party(7)

2–46


SR-NOTES-SERIES-18

The use of RTP becomes much more complicated for alternately billed calls due to two added components:

1. Operator Services-specific data, such as the billing number (i.e., calling card, called number, or third party number), needs to be recorded with the call completion AMA record. This is difficult because the call completion AMA record is generated at the originating EO, not at the OSS switch that has the information.

2. Sequence Calling needs to be supported for calling card calls. With sequence calling, the calling party can place a subsequent call without reentering the calling card number. The calling party depresses the ‘#’ key after hearing a busy tone or after the called party disconnects, but before the call is released. Sequence calling is simpler when the OSS switch remains in the call path for the duration of the call because the OSS switch detects the ‘#’ and performs subsequent processing based on the detection of the ‘#’ during the appropriate points in call processing. When the calling party depresses ‘#’ after the OSS switch releases itself from the call, the originating EO needs to detect the ‘#’ and reconnect the calling party to the OSS switch. The originating EO needs to provide the OSS switch with sufficient information to enable the OSS switch to perform the calling card service processing without requiring the calling party to reenter the calling card number.

GR-3015-CORE and GR-3016-CORE includes the more complex signaling and processing to handle alternate billing services using RTP.

The RTP network capability is not currently deployed in LEC networks.

2.4.5.2 Nortel Networks DMS TOPS Release Link Trunking

Some LECs have deployed a capability comparable to RTP, referred to as Release Link Trunking (RLT). RLT is sometimes used to release wireless DA calls from the LEC OSS switch to the wireless network for call completion. RLT is a Nortel Networks proprietary SS7 ISUP release network capability that is supported in DMS TOPS switches and some additional switches, such as some MSCs.

RLT works in a similar way to how RTP is defined. With RLT, the OSS switch releases the call to the previous switch for call completion. The primary difference between RLT and RTP is the protocol. RLT does not include a CP parameter in the IAM message sent from the originating switch to the OSS. The incoming trunk group identifies the call as eligible for RLT processing. The implication of this is that the call must be released back to the previous switch that is directly connected to the OSS switch, unless additional signaling is used (e.g., via FAC messages) to negotiate acceptance of the release with the end office. RLT supports alternate billing services as well as DACC.

2–47


SR-NOTES-SERIES-18

2.5 Example Call Flows

This section provides example call flows to illustrate how the general OSS architecture is used to provide several services.

2.5.1 Partially Automated DACC

Figure 2-5 illustrates example architecture components used for DA. A call flow follows the text. The call flow is provided as an example, and does not necessarily reflect actual deployment. In addition, the call flow is provided at a high level. All the details related to the protocol interactions among the systems are not provided. For example, an initial Originating Line Number Screening (OLNS) query may be performed, although it is not included in the call flow.

Figure 2-5 Example Architecture Components for Partially Automated DACC

Example call flow steps are provided below:

1. The caller dials 1+411 or 411.

2. The end office sets up the call to the OSS switch using MF or ISUP signaling.

3. The OSS switch then connects the calling party to a front-end Voice Server.

4. The Voice Server provides the branding announcement and front-end DA announcement (e.g., “Enter City and Listing”). The Voice Server may provide speech compression and silence deletion to shorten the time it takes to playback the recorded voice. Speech

End OfficeSwitch

OSS

VoiceServer

Front-EndVoiceServer

Back-End

LSDB

(1) (2)

(3)

(4)

(5)

(6) (7)(10)

(9)

(11)

(8)

End Office

2–48


SR-NOTES-SERIES-18

compression algorithms may compress sounds that have redundancies (e.g., “aaaah” to “ah”).

5. The OSS switch uses its queuing and call distribution functions to find an available operator with the appropriate skill set and sets up the call between the calling party and operator. The OSS switch also sets up a voice path between the front-end Voice Server and operator to enable the front-end Voice Server to play the voice recording to the operator.

6. The operator requests the LSDB for this listing.

7. The LSDB provides one or more listing(s) to the operator.

8. Possibly through additional interaction with the caller, the operator finds the correct telephone number and provides the found telephone number to the OSS switch.

9. The OSS switch connects the caller to the back-end Voice Server, which announces the telephone number to the caller. The Voice Server also offers the caller the option for automatic call completion. In this case, the caller requests automatic call completion.

10. The Voice Server requests the OSS switch to complete the call.

11. The OSS switch then completes the call by forward routing the call to the terminating end office that serves the found telephone number.

2.5.2 Fully Automated Collect Call with Call Completion and a Ported Called Number

This section provides an example call flow for a call that is billed collect. In this example, the billed number (in this case the called number) is ported from one switch to another switch and from one LIDB to another LIDB. Figure 2-6 illustrates the architecture components used for collect calls with ported called numbers. A call flow follows the text. The call flow is provided as an example, and does not necessarily reflect actual deployment. In addition, the call flow is provided at a high level. All the details related to the protocol interactions among the systems are not provided. For example, an initial Originating Line Number Screening (OLNS) query may be performed, although it is not included in the call flow.

2–49


SR-NOTES-SERIES-18

Figure 2-6 Architecture Components for Fully Automated Collect Call

Example call flow steps are provided below:

1. The caller dials 0+NPA-NXX-XXXX.

2. The end office sets up the call to the OSS switch using MF or ISUP signaling.

3. The OSS switch then connects the calling party to a Voice Server.

4. The Voice Server provides the branding announcement and front-end alternate billing announcement (e.g., “To obtain rate information, enter..., for collect calls, enter..., for calling card or third number, enter...”).

5. After determining that the call is a collect call, the OSS switch sends a BNS query to LIDB. Following the procedures of an LNP-capable OSS switch, the OSS switch places all ten digits of the called number in the appropriate place in the SS7 message sent to LIDB.

6. The CCS/SS7 network routes the TCAP message to an LNP database that can perform the 10-digit translation to find the right destination LIDB. (As an alternative, the STPs could provide the 10-digit global title translation).

7. The LNP database performs the translation and requests the CCS/SS7 network to route the TCAP message.

8. The CCS/SS7 network routes the TCAP message to the right LIDB.

9. LIDB checks the authorization of the billed number and provides a successful response back to the OSS switch.

10. The OSS switch then determines that it should set up a call to the called party to verify charges (This step may be skipped, depending on the response from LIDB).

End Office SwitchOSS

VoiceServer

(1) (2)(3)

(4) (5), (6)

(8)

(13)

LNPLIDB

End Office

(9)

(7)

(10)

(11) (12)

2–50


SR-NOTES-SERIES-18

11. The OSS switch determines that the called party number is portable and sends an LNP query to the LNP database to request the LRN associated with the called party number (if the called party number is ported).

12. The LNP database provides the LRN and other relevant information to the OSS switch.

13. The OSS switch adds the called party to the connection between the calling party and Voice Server, the Voice Server requests billing verification from the called party, and the called party complies. The Voice Server is then released from the call.

2–51


SR-NOTES-SERIES-18

2.6 Signaling to and from LEC OSS Switches

This section describes the MF and SS7 signaling used and defined for Operator Services. The signaling is used for the following types of calls:

1. Originating Operator Services calls established from LEC end offices to LEC OSS switches (see Section 2.6.1).

2. Intercepted calls from LEC intercepting switches (i.e., switches serving the intercepted number) to LEC OSS switches (see Section 2.6.1).

3. Originating Operator Services calls established from MSCs to LEC OSS switches (see Section 2.6.2).

4. Transferred calls from LEC OSS switches to IC OSS switches (see Section 2.6.3).

5. Inward Calls from LEC OSS switches to other LEC OSS switches (see Section 2.6.4).

6. Terminating Calls from LEC OSS switches to LEC end offices (see Section 2.6.5).

7. Terminating Calls from LEC OSS switches to MSCs (see Section 2.6.6).

2.6.1 LEC End Offices to LEC OSS switches

Operator Services calls routed from a LEC end office to a LEC OSS switch include originating Operator Services calls from an originating end office to the LEC OSS switch, and intercept calls from an intercepting end office (i.e., the switch that serves the intercepted called number) to the LEC OSS switch. Originating Operator Services calls are also routed from an originating MSC to the LEC OSS switch. MF and SS7 signaling may be used between originating switches and OSS switches.

The most common signaling currently used for Operator Services calls is referred to in this document as pre-EAOSS signaling. Another name used for this signaling is “Bell II” signaling.

Another MF signaling alternative is referred to in this document as original Operator Services (OS) signaling, also known as “Bell I” signaling.

A third MF signaling alternative is Exchange Access Operator Services Signaling (EAOSS), which is defined in GR-692-CORE.

Basic SS7 signaling that was defined for direct-dialed (i.e., not Operator Services) calls is used between some wireless MSCs and OSS switches, but it does not support the operator hold, ringback, or coin control functions.

A second SS7 alternative is referred to as Operator Services SS7, and is defined in GR-1277-CORE and GR-1144-CORE. Operator Services SS7 adds extensions to basic SS7 signaling to support the operator hold, ringback, and coin control functions, and to identify Operator Services calls to enable Operator Services calls and non-Operator Services calls to be routed over the same trunk group. Note that basic SS7 signaling identifies 0- and 0+ dialed calls as operator-assisted calls, but does not include a way of identifying 1+ calls that require Operator Services handling as Operator Services calls.

2–52


SR-NOTES-SERIES-18

The five signaling alternatives that may be used by end offices to signal Operator Services calls to OSS switches are listed below, along with requirements references:

• MF: Original Operator Services (OS) signaling

— requirements in GR-531-CORE, FSD-25-06-0502

• MF: Pre-EAOSS

— requirements in GR-1143-CORE for LEC calls; GR-690-CORE for IC Operator Services calls.

• MF: EAOSS

— requirements in GR-692-CORE

• SS7: Basic Signaling

— requirements in GR-317-CORE and GR-394-CORE

• SS7: Operator Services Signaling

— requirements in GR-1277-CORE.

Before the 1984 AT&T divestiture, MF signaling was used for Operator Services. This signaling is referred to in this document as original OS signaling. The signaling is defined in Section 3.3.5 of GR-531-CORE, FSD 25-06-0502, and described in Section 2.6.1.1 of this document. Today, the original OS signaling is minimally used in ILEC switches. The original OS signaling includes the dialed digits, Automatic Number Identification (ANI), ANI I (i.e., one ANI information digit that identifies the class of service for the calling line), and special signaling (e.g., for coin control, ringback, and hook flash).

To meet the needs of equal access, this original OS signaling was modified slightly. In addition, a more complete equal access signaling for Operator Services, known as Exchange Access Operator Services Signaling (EAOSS), was defined. The slightly modified OS signaling is referred to in this document as pre-EAOSS signaling. In the mid-1980s, pre-EAOSS was thought of as an interim plan prior to implementation of the full EAOSS signaling. However, pre-EAOSS signaling is still widely used. Pre-EAOSS is described in Section 5 of GR-1143-CORE and in Section 2.6.1.2 of this document.

The differences between pre-EAOSS and the original OS signaling are as follows:

• A two-digit Automatic Number Identification (ANI) information code (ANI II) is sent rather than a 1-digit information code (ANI I)

• ST’ is sent in the ANI portion for LEC calls and ST is sent in the ANI portion for IC/International Carrier (INC) calls in pre-EAOSS. ST is always sent in the ANI portion with the original OS signaling alternative.

• InterLATA restricted indications are supported using the two-digit code (ANI II) digits.

2–53


SR-NOTES-SERIES-18

EAOSS, defined in GR-692-CORE, fully supports equal access and signals enough information to enable all types of calls and traffic to be signaled over the same trunk group. For example, the carrier identifier is signaled, so it does not have to be derived by the OSS switch from an incoming dedicated trunk group 3. More specifically, EAOSS extends pre-EAOSS signaling by including additional information, such as carrier identifier and routing code, an indication of whether the identified carrier was dialed or presubscribed, and an indication of whether dial pulse or DTMF was used.

Another alternative for signaling is the use of basic SS7 signaling, which is widely used for direct dialed calls. Operator Services and DA traffic can be routed using the SS7 signaling defined in GR-317-CORE and GR-394-CORE for basic call processing. Some ICs use basic SS7 signaling for their Operator Services traffic. The basic SS7 signaling does not support connection hold, ringback, operator recall, coin control, and intercept.

GR-1277-CORE defines Operator Services SS7 signaling, which adds parameters and parameter values to ISUP messages to support connection hold, ringback, operator recall, coin control, and intercept. The extension also facilitates trunk group sharing among Operator Services and non-Operator Services calls by explicitly identifying Operator Services calls. Operator services SS7 signaling has been implemented in some OSS switches, but is not currently deployed.

The type of signaling used by the OSS switch is available on a trunk group basis so that the end offices can be converted office-by-office.

Table 2-3 summarizes the signaling schemes discussed above and includes requirements references.

3. Other alternatives, such as using Originating Line Number Screening (OLNS), also enable traffic from multiple carriers to be signaled over the same trunk group. With the OLNS alternative, for example, the OSS switch queries a LIDB database for the calling line’s PIC, rather than retrieving the PIC from signaling or deriving it from the trunk group.

2–54


SR-NOTES-SERIES-18

Table 2-3 Requirements References for MF and SS7 Signaling Alternatives

Signaling Scheme Requirement(s) Reference Synopsis

MF – original Operator Services signaling

For calls routed to an IC or LEC OSS switch using original OS signaling, see GR-531-CORE, FSD 25-06-0502. See GR-506-CORE for a definition of the MF signals specified in GR-531-CORE.

This document describes the original OS signaling used by AT&T before the 1984 divestiture. The original OS signaling is minimally used in ILEC networks today.

MF – pre-EAOSS signaling

For calls routed to an IC or local service provider OSS switch using pre-EAOSS, see Section 5 of GR-1143-CORE. Also see Section 3.3.5 of GR-690-CORE for the pre-EAOSS between an end office and IC OSS switch. See GR-506-CORE for a definition of the MF signals specified in GR-1143-CORE and GR-690-CORE.

Pre-EAOSS includes extensions to facilitate the routing of Operator Services calls to IC Operator Services providers and to enable IC and LEC traffic to be signaled on the same trunk group. Pre-EAOSS signaling is used extensively in ILEC networks today.

MF – EAOSS For EAOSS, see GR-692-CORE.

See GR-506-CORE for a definition of the MF signals specified in GR-692-CORE.

EAOSS extends pre-EAOSS signaling by including additional information, such as an identifier for the IC associated with the calling line.

Basic SS7 For basic SS7 signaling, see GR-317-CORE and GR-394-CORE.

Basic SS7 signaling includes the out-of-band ISUP basic call processing procedures for signaling normal direct dialed calls. This signaling lacks the support of operator system-specific capabilities, such as coin control.

Operator Services SS7 For Operator Services SS7 signaling, see GR-1277-CORE.

GR-1277-CORE extends the basic ISUP signaling to support Operator Services-specific capabilities, such as connection hold, ringback, operator recall, coin control, and intercept. Extensions are also included to facilitate trunk sharing and routing calls between end offices and OSS switches via tandem switches.

2–55


SR-NOTES-SERIES-18

2.6.1.1 Original OS Signaling

Although a pre-divestiture scheme, this signaling may still exist between end offices and OSS switches in some locations, but it is not prevalent. It is similar to the pre-EAOSS signaling described in Section 2.6.1.2, but uses just one ANI Information Digit and a non-variable ST signal on the multifrequency ANI information.

2.6.1.1.1 Outpulsing Format

The end office identifies the type of call to OSS switches by using four different multifrequency start signals. On calls where the end office uses MF signaling for the called number, the appropriate start signal is sent with the called number. On calls where the end office uses dial pulsing, the appropriate start signal is sent with the ANI information. In addition, timing is used to identify the type of call. For example, when it is desired to reach an operator (0- call), 0 is dialed. When special handling or alternate billing is desired (for example, collect, person-to-person, calling card, etc. [0+ call]), 0 followed by the called number is dialed. The 0- and 0+ calls use the same ST pulse for identification. As a result, other means must be used to separate these two categories of calls. OSS switches consider a caller’s dialing pause of over 4 to 5 seconds4 after dialing 0 to be a 0- call. In multifrequency pulsing calls, KP followed by a start signal of ST’ or ST’’’, depending on the trunking plan, but with no called number, is outpulsed to identify a 0 call.

OSS switches currently initiate timing following the receipt of a leading 0 dial-pulse digit to determine if additional digits follow. Timing is performed by the OSS switch processor and is not terminated until a complete digit (consisting of two to nine pulses) is registered by a dial-pulse receiver and reported to the processor. The time interval is 4 to 5 seconds for receipt of a complete digit. This change will allow the 0+ customer a minimum of approximately 3 seconds to begin dialing a second digit, while requiring the 0- customer to wait no longer than 5 seconds. When it is determined that the call is a 0- call, the OSS switch returns the off-hook ANI request signal.

2.6.1.1.2 Trunking Plans

OSS switches using Original OS signaling can have a variety of trunking plans. They can:

• Combine all coin and non-coin traffic on one supercombined trunk group. The pulsing format for this arrangement with ANI is shown in Table 2-4.

• Combine all coin traffic on one trunk group and all non-coin traffic on another. The pulsing format for this arrangement with ANI is shown in Table 2-5.

• Combine all 0-, 0+ coin traffic on one trunk group and all 0-, 0+ non-coin traffic on another. The pulsing format for this arrangement with ANI is shown in Table 2-6. The 1+ coin and 1+ non-coin traffic would be handled on two additional trunk groups, also shown in Table 2-6.

4. Nortel Network’s DMS TOPS system is adjustable from 2 to 30 seconds.

2–56


SR-NOTES-SERIES-18

• Use six individual trunk groups for 0-, 0+, 1+ coin and 0-, 0+, 1+ non-coin traffic. The pulsing format for this arrangement with ANI is shown in Tables 2-4 to 2-6 and without ANI in Table 2-7.

In each case where more than one type of traffic is carried on a single trunk group, the type of call is identified by distinctive multifrequency ST digits or an ANI information (I) digit transmitted from the end office with the called/calling number. For dial-pulsing calls, the identifying ST pulse is associated with the ANI information. For MF signaled calls, the identifying ST pulse is associated with the address information. For both MF and dial-pulsing calls, the information digit is with the ANI information. To separate traffic, a different information digit is used with each call to indicate whether it has been subject to local service observing and also whether it was processed by automatic identification, operator identification, or identification failure procedures. Tables 2-4 through 2-7 show this information.

Table 2-4 Pulsing Format from an End Office to an OSS Switch with ANI Supercombined Coin and Non-Coin Trunk Group Using Original OS Signaling

0-, 0+, 1+ Coin; 0-, 0+, 1+ Non-coin; and 0-, 0+, 1+ Screened Traffic

Multifrequency Pulsing

Type ofCall

CustomerDials

Multifrequency-PulsedCalled Number

ANICalling Number

Non-coin

Direct dialed Operator assistance Special toll

(1) + 7 or 10 digits0 (zero)0 + 7 or 10 digits

KP-7 or 10 digits-ST’’KP-ST’’’KP-7 or 10 digits-ST’’’

KP-I-7 digits-STKP-I-7 digits-STKP-I-7 digits-ST

Coin



KP-7 or 10 digits-STKP-STPKP-7 or 10 digits-ST’


Dial Pulsing

Type ofCall

CustomerDials

Dial-PulsedCalled Number

ANICalling Number

Non-coin



7 or 10 digitsSeizure no digits7 or 10 digits

KP-I-7 digits-ST”KP-I-7 digits-ST’’’KP-I-7 digits-ST’’’

Coin



7 or 10 digitsSeizure no digits7 or 10 digits

KP-I-7 digits-STKP-I-7 digits-ST’KP-I-7 digits-ST’

Note: See Table 2-8 for the meaning of information digit I.

2–57


SR-NOTES-SERIES-18

Table 2-5 Pulsing Format — End Office to OSS switch with ANI Combined Coin or Combined Non-coin Trunk Group Using Original OS Signaling

Combined Coin

0-, 0+, & 1+ Coin

Combined Non-coin

0-, 0+, & 1+ Non-coin

0-, 0+, & 1+ Post-pay coin

0-, 0+, & 1+ Screened traffic

0-, 0+, & 1+ Non-coin combined with 0-, 0+, & 1+ post-pay coin and/or 0-, 0+, & 1+ screened traffic


Type ofCall

CustomerDials

Multifrequency-Pulsed Called Number

ANICalling Number

Direct dialed

Operator assistance

Special toll

(1) + 7 or 10 digits

0 (zero)

0 + 7 or 10 digits

KP-7 or 10 digits-ST

KP-ST’

KP-7 or 10 digits-ST’

KP-I-7 digits-ST

KP-I-7 digits-ST

KP-I-7 digits-ST

Dial Pulsing

Type ofCall

CustomerDials

Dial-Pulsed Called Number

ANICalling Number



7 or 10 digitsSeizure-no digits7 or 10 digits

KP-I-7 digits-STKP-I-7 digits-ST’KP-I-7 digits-ST’


2–58


SR-NOTES-SERIES-18

Table 2-6 Pulsing Format — End Office to OSS Switch with ANI Using Original OS Signaling

Individual

0-, 0+, & 1+ Coin

0-, 0+, & 1+ Non-coin



Combined

0- & 0+ Coin

0- & 0+ Non-coin

0- & 0+ Post-pay coin

0- & 0+ Screened traffic

0- & 0+ Non-coin combined with 0- & 0+ post-pay coin and/or 0- & 0+ screened traffic

1+ Non-coin combined with 1+ post-pay coin and/or 1+ screened traffic


Type ofCall

CustomerDials


ANICalling Number


(1) + 7 or 10 digits0 (zero)0 (zero)0 + 7 or 10 digits

KP-7 or 10 digits-STKP-STSeizure-no digitsKP-7 or 10 digits-ST

KP-I-7 digits-STKP-I-7 digits-STKP-I-7 digits-STKP-I-7 digits-ST

Dial Pulsing

Type ofCall

CustomerDials

Dial-Pulsed Called Number

ANICalling Number






2–59


SR-NOTES-SERIES-18

Because the identifying ST pulse is associated with the called number, each of the above multifrequency pulsing formats can be used without ANI from the end office. The only usable situation under which the dial-pulsing format without ANI could be used is when an individual trunk group is used for each type of service.

2.6.1.1.3 ANI Information Digits

A single ANI information digit is used for Operator Services calls using original OS signaling. Tables 2-4 through 2-7 identify this signaling.

The information in this section covers operation with OSS switches. Some Carriers may continue to use this mode of operation indefinitely. Note that a dual information digit format

Table 2-7 Pulsing Format — Non-Conforming End Office to an OSS Switch without ANI

Individual Trunk Groups

0-, 0+, & 1+ Coin

0-, 0+, & 1+ Non-coin



Combined Trunk Groups

0- & 0+ Coin

0- & 0+ Non-coin

0- & 0+ Post-pay coin

0- & 0+ Non-coin and

0- & 0+ post-pay coin with service tone identification


Type ofCall

CustomerDials



(1) + 7 or 10 digits0 (zero)0 (zero)0 + 7 or 10 digits

KP-7 or 10 digits-ST*Seizure-no digitsKP-ST**KP-7 or 10 digits-ST*

Dial Pulsing

Type ofCall

CustomerDials

Dial-PulsedCalled Number




* ST indicates that any of the usable ST signals will be accepted.

2–60


SR-NOTES-SERIES-18

is associated with equal access signaling, and with pre-EAOSS signaling described in Section 2.6.1.2.

The ANI Information digits’ definitions are listed in Table 2-8. Digits 0, 1, and 2 identify nonobserved calls while digits 3, 4, and 5 identify observed calls. These information digits will continue to be used with Original OS signaling. Note that the information digits for equal access are now Standard (see Section 2.6.1.2 and Section 2.6.1.3).

2.6.1.2 Pre-EAOSS Signaling

Pre-EAOSS signaling is available in TOPS and OSPS switches and is widely used today.

Pre-EAOSS signaling extends the Original OS Signaling discussed in Section 2.6.1.1. The differences are as follows:

• Two information digits are used in the ANI information sequence, rather than the one in Original OS signaling.

• The MF signaling start digit on the ANI information can be either ST (IC/INC calls) or ST’ (non-IC/INC calls). This permits identification of IC/INC calls versus non-IC/INC calls without translating the dialed digits at the OSS switch. Previously, only the start signal ST was used with ANI information.

Pre-EAOSS signaling can support 1+, 0-, and 0+ Operator Services traffic. Pre-EAOSS signaling can handle and identify local, intraLATA toll, interLATA, and international traffic. OSS switch trunks are usually 2-way.

On calls to be routed to an OSS switch using pre-EAOSS signaling, the following will occur:

1. The customer dials 101XXXX + (1) + 7 or 10 digits, or 101XXXX + 0 + 7 or 10 digits.

2. The end office seizes an outgoing trunk.

3. The operator service facility responds with a standard wink.

4. The end office outpulses the called number after a delay of 40 to 200 ms. The outpulsing is KP + 7/10 digits + ST (ST’, ST”, ST’’’).

5. Any time after the start of the ST pulse, the OSS switch will come off-hook to indicate readiness to receive ANI information.

Table 2-8 Information Digit I

Service Nonobserved Observed

Automatic Identification (AI) 0 3

Operator Identified (OI) 1 4

Identification Failure (IF) 2 5

Hotel/Motel 6 6

Special Screening (for example, Charge-a-Call) 7 7

2–61


SR-NOTES-SERIES-18

6. The end office outpulses the ANI information after a delay of 40 to 200 ms. The outpulsing is KP + II + 7 digits + ST (ST’). On ANI failures, KP + 02 + ST (ST’) will be sent. Pre-EAOSS Signaling always includes an ANI portion.

If a time-out occurs waiting for the start-pulsing wink or the ANI request off-hook signal, a reorder announcement is connected. If all trunks to the IC/INC are busy, a no-circuit announcement is connected. If a trunk cannot be seized for any other reason, reorder tone should be returned.

Tables 2-9 and 2-10 show the various outpulsing formats for pulsing between an end office and OSS switch using pre-EAOSS signaling. There is great similarity between Table 2-9 (pre-EAOSS signaling) and Table 2-6 (Original OS signaling) for OSS switches. In both cases, supercombined 0-, 0+, and 1+ coin; 0-, 0+, and 1+ non-coin; and 0-, 0+, and 1+ screened traffic can be routed over a single trunk group. Post-pay coin cannot be routed on the same trunk group as prepay coin.

All trunk groups between an end office and an OSS switch can always use the supercombined format. However, the OSS switch can also use pulsing formats analogous to those in

Table 2-9 Pulsing Format from End Office to OSS Switch - Local, IntraLATA Toll, and InterLATA Calls Using Pre-EAOSS Signaling

0-, 0+, 1+ Coin; 0-, 0+, 1+ Non-coin; and 0-, 0+, 1+ Screened Traffic

Type ofCall

CustomerDials


ANICalling Number

Non-coin:

Direct dialedPredesignated CarrierOverride Predesignation

(1) + 7 or 10 digits101XXXX + (1) + 7 or 10 digits

KP-7 or 10 digits-ST”KP-7 or 10 digits-ST”

KP-II-7 digits-ST*KP-II-7 digits-ST*

Operator assistance (0-)Predesignated carrierOverride Predesignation

00101XXXX + 0

KP-ST’’’KP-ST’’’


Operator assistance (0+)Override Predesignation

101XXXX + 0 + 7 or 10 digits

KP-7 or 10 digits-ST’’’ KP-II-7 digits-ST*

Coin:

Direct dialed

Operator assistance (0-)Operator assistance (0+)

101XXXX + (1) + 7 or 10 digits101XXXX + 0 (zero)101XXXX + 0 + 7 or 10 digits

KP-7 or 10 digits-ST

KP-ST’KP-7 or 10 digits-ST’

KP-II-7 digits-ST*


*ST for IC calls; ST’ for non-IC calls.

2–62


SR-NOTES-SERIES-18

Tables 2-5, 2-6, and 2-7 for the OSS switch if the LEC and IC agree. International and test call dialing are covered in Table 2-10.

The three special ANI information digit pairs (II) 08, 68, and 78 (explained below) are required for the OSS switch to handle calls from interLATA-restricted lines. These information digit pairs are sent only on calls to the OSS switch serving the carrier for which interLATA restriction applies. Other ANI pairs (II) used with this signaling are as shown later in this section.

Table 2-10 Pulsing Format from End Office to OSS Switch -International Calls and Test Calls Using Pre-EAOSS Signaling

0-, 0+, 1+Coin — 0-, 0+, 1+ Non-coin — and 0-, 0+, 1+ Screened Traffic

International Calls

Type ofCall

CustomerDials


ANICalling Number

Non-coin

Direct dialedPredesignated CarrierOverride Predesignation

011 + CC + NN101XXXX + 011 + CC + NN

KP + 1 + CC + NN-ST”KP + 1 + CC + NN-ST”

KP-II-7 digits-STKP-II-7 digits-ST

Operator assistance (0-)Predesignated carrierOverride Predesignation

00 (zero minus)101XXXX + 0

KP + 0 + STKP + 0 + ST


Operator assistance (0+)Predesignated carrierOverride Predesignation

01 + CC + NN101XXXX + 01 + CC + NN

KP + 1 + CC + NN-ST’’’KP + 1 + CC + NN-ST’’’


Coin

Direct dialed

Special toll handling

101XXXX + 011 + CC + NN101XXXX + 01 + CC + NN

KP + 1 + CC + NN-ST

KP + 1 + CC + NN-ST’

KP-II-7 digits-ST

KP-II-7 digits-ST’

Typical Test Calls

Type ofCall

TesterDials


ANICalling Number*

Test

Test

Test

10X

958 + XXXX

959 + XXXX

KP-10X-ST

KP-958 + XXXX-ST

KP-959 + XXXX-ST

—

—

—

2–63


SR-NOTES-SERIES-18

2.6.1.3 MF EAOSS

The MF EAOSS signaling alternative extends the pre-EAOSS signaling by outpulsing more information, such as Carrier ID, 0ZZ code, and an indication of whether a particular call was dialed using dial-pulse or DTMF digits. With EAOSS, the type of traffic is indicated in the digits outpulsed as described in the following text. To permit transition from pre-EAOSS signaling to EAOSS, the type of signaling can be associated with specific trunk groups.

The steps an end office performs using EAOSS are provided below:

A. Non-IC Operator Services Calls

1. 0+ Local or IntraLATA Toll5 or 0- Calls

A. Outpulse KP+0/3/7/10D(Called No.)+ST’ (ST’ indicates that the call was dialed 0- or 0+)

B. Receive off-hook Automatic Number Identification (ANI) request signal

C. Outpulse KP”+II+3/10D(ANI No.)+ST.

2. (1+) Local or IntraLATA Toll4 Operator System Calls (e.g., Coin, Hotel, Multiparty, etc.)

A. Outpulse KP+3/7/10D+ST’ (ST” indicates that the call requires operator system functions but was not dialed 0- or 0+)

B. Receive off-hook ANI request signal

C. Outpulse KP”+II+3/10D(ANI No.)+ST.

3. (1+) Listing Services (e.g., directory assistance) Calls

A. Outpulse KP+411+ST” or KP+555+XXXX+ST’’’ or KP+NPA+555+XXXX+ST”


C. Outpulse KP”+II+ANI No.+ST.

4. 0+ Listing Services (e.g., directory assistance) Calls

A. Outpulse KP+411+ST’ or KP+555+XXXX+ST’ or KP+NPA+555+XXXX+ST’


C. Outpulse KP”+II+ANI No.+ST.

5. Intercept Calls

A. Outpulse KP+10D(Called Number)+ ST”

B. Receive off-hook ANI request

C. Outpulse KP+II+ST (Special II digits indicate an intercept call)

B. IC Calls - LEC Operator Exchange Access Services Required

1. 0+IntraLATA Toll6 and InterLATA Calls - Presubscribed Line

5. The signaling is applicable when a LEC carries the intraLATA toll call.

2–64


SR-NOTES-SERIES-18

A. Outpulse KP+0ZZ+XXXX+ST’ to AT (ST’ indicates that LEC operator exchange access services are required, XXXX corresponds to the calling station's PIC)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+0+Called No.+ST

D. Receive acknowledgment wink or off-hook.

2. 0+ InterLATA Calls - Line Not Presubscribed to an IC

A. Outpulse KP+0ZZ+ST’ (ST’ and absence of XXXX sequence indicate a call requiring LEC operator exchange access services from a line that is not presubscribed)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+0+Called No.+ST


3. 101XXXX+0+IntraLATA toll Calls5 and InterLATA Calls (LEC provides operator exchange access services for XXXX carrier)

A. Outpulse KP+0ZZ+XXXX+ST’ (ST’ indicates that LEC operator exchange access services are required)

B. Receive wink

C. Outpulse KP’’’+II+ANI No.+ST+KP+0+Called No.+ST to AT (KP’ on ANI sequence indicates that customer dialed 101XXXX code)


4. (1+) InterLATA Operator System Calls (e.g., Coin, Hotel, etc.) (LEC provides operator exchange access services for presubscribed carrier)

A. Outpulse KP+0ZZ+XXXX+ST’ (ST’ indicates that LEC OSS is required, XXXX corresponds to the calling station's PIC)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+Called No.+ST


5. (1+) IntraLATA toll5 or InterLATA Operator System Call (e.g., Coin, Hotel, etc.) - Line Not Presubscribed to an IC

A. Outpulse KP+0ZZ+ST’ to AT (ST’ and absence of XXX sequence indicates a call requiring LEC operator exchange access services from a line that is not presubscribed)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+Called No.+ST


6. The signaling is applicable when an IC carries the intraLATA toll call.

2–65


SR-NOTES-SERIES-18

6. 101XXXX+(1+) IntraLATA toll or InterLATA Operator System Calls (e.g., Coin, Hotel, etc.) (LEC provides operator exchange access services for XXXX carrier)

A. Outpulse KP+0ZZ+XXXX+ST’(ST’ indicates that LEC OSS is required)

B. Receive wink

C. Outpulse KP’’’+II+ANI No.+ST+KP+Called No.+ST to AT (KP’ on ANI sequence indicates that the customer dialed 101XXXX code)


7. 00- Calls (LEC provides operator exchange access services for presubscribed carrier)

A. Outpulse KP+0ZZ+XXXX+ST’ to AT (ST’ indicates that LEC operator exchange access services are required, XXXX corresponds to the calling station's PIC)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+0+ST


8. 101XXXX+0- Calls (LEC provides operator exchange access services for XXXX carrier)

A. Outpulse KP+0ZZ+XXXX+ST’(ST’ indicates that LEC operator exchange access services are required)

B. Receive wink

C. Outpulse KP’’’+II+ANI No.+ST+KP+0+ST (KP’ on ANI sequence indicates that customer dialed 101XXXX code)


9. 00- Calls - Line Not Presubscribed

A. Outpulse KP+0ZZ+ST’(ST’ and absence of XXXX sequence indicates a call requiring LEC operator exchange access services from a line that is not presubscribed)

B. Receive wink

C. Outpulse KP”+II+ANI+ST+KP+0+ST

D. Receive acknowledgement wink or off-hook from AT.

C. International Calls (LEC Operator Exchange Access Services Required)

1. 01+ International Calls - Presubscribed Line to an International or Consolidated Carrier

A. Outpulse KP+1N’X+XXX+XCCC+ST’(ST’ indicates that LEC operator exchange access services are required; N’ indicates call was dialed with a 01 prefix, XXXX corresponds to the calling station's PIC)

B. Receive wink

C. Outpulse KP”+II+ANI No.+ST+KP+CC+NN+ST

2–66


SR-NOTES-SERIES-18


2. 01+ International Calls - Line not Presubscribed to an International or Consolidated Carrier

A. Outpulse KP+1N’X+CCC+ST’ (N’ and absence of XXXX code indicate a 01 call from a line that is not presubscribed)

B. Receive wink

C. Outpulse KP’’+II+ANI No.+ST+KP+CC+NN+ST


3. 101XXXX+01+ International Calls (LEC provides operator exchange access services for XXXX carrier)

A. Outpulse KP+1N’X+XXXX+CCC+ST’ (ST’ indicates that LEC operator exchange access services are required)

B. Receive wink

C. Outpulse KP’’’+II+ANI No.+ST+KP+CC+NN+ST (KP’ on the ANI sequence indicates that the customer dialed a 101XXXX code)


4. 011+ International Operator System Calls (e.g., Coin, Hotel, etc.) (LEC provides operator exchange access services for presubscribed carrier)

A. Outpulse KP+1NX+XXXX+CCC+ST’ (ST’ indicates that LEC operator exchange access services are required, N indicates prefix 011 dialed, XXXX corresponds to the calling station's PIC)

B. Receive wink



5. 011+ International Operator System Calls (e.g., Coin, Hotel, etc.) - Line Not Presubscribed to an International or Consolidated Carrier

A. Outpulse KP+1NX+CCC+ST’ (ST’ and absence of XXXX code indicates a call requiring LEC operator exchange access services from a line that is not presubscribed)

B. Receive wink



6. 101XXXX+011+ International Operator System Calls (e.g., Coin, Hotel, etc.) (LEC provides operator exchange access services for XXXX carrier)

A. Outpulse KP+1NX+XXXX+CCC+ST’ (ST’ indicates that LEC operator exchange access services are required)

2–67


SR-NOTES-SERIES-18

B. Receive wink

C. Outpulse KP’’’+II+ANI No.+ST+KP+CC+NN+ST (KP’ on the ANI sequence indicates that customer dialed 101XXXX code)


7. 00- Calls (LEC provides operator exchange access services for presubscribed international carrier)

A. Outpulse KP+1N’X+XXXX+000+ST’ to AT (ST’ indicates that LEC operator exchange access services are required, XXXX corresponds to the calling station's PIC)

B. Receive wink

C. Outpulse KP’’+II+ANI No.+ST+KP+0+ST


8. 101XXXX+0- Calls (LEC provides operator exchange access services for international carrier)

A. Outpulse KP+1N’X+XXXX+000+ST’ to AT (ST’ indicates that LEC operator exchange access services are required)

B. Receive wink from AT

C. Outpulse KP’’’+II+ANI No.+ST+KP+0+ST to AT (KP’ on ANI sequence indicates that customer dialed 101XXXX code)

D. Receive acknowledgment wink or off-hook from AT.

ANI is transmitted on all calls routed to the OSS switch and consists of two information digits and the entire 10-digit number of the calling line, if available. On calls from lines that cannot be identified (e.g., four- and eight-party lines) the NPA code is sent instead of the full 10-digit line number.

The signaling sequences from the end office identified above are used on calls originated with DTMF signaling. For dial pulse calls, a KP” signal in the ANI sequences (except on intercept calls) should be changed to a KP signal, and a KP’’’ signal in the ANI sequences should be changed to a KP” signal. Thus, the KP signals in the ANI sequences provide the following information:

Likewise, on calls routed to an IC/INC instead of a LEC OSS switch, the capability exists to vary the KP signal of the ANI sequence to indicate certain call characteristics. When the end office determines that a call is to be routed to an IC/INC, a check is made to determine if the particular IC/INC has arranged to receive such indications. If not, the KP signal in the ANI

KP Dial pulse signaling - Customer did not dial 101XXXX prefix

KP’ Dial pulse signaling - Customer dialed 101XXXX prefix

KP” DTMF signaling - Customer did not dial 101XXXX prefix

KP”’ DTMF signaling - Customer dialed 101XXXX prefix.

2–68


SR-NOTES-SERIES-18

sequence to the IC/INC should always be KP (unprimed). If the IC/INC has arranged to receive this information, the KP signal would be sent as follows:

A. If the IC has requested to know only whether the call was originated with dial pulse signaling or DTMF signaling, then

B. If the IC has requested to know only whether or not the calling party is presubscribed to this IC, then

C. If the IC has requested both A and B, above, then

Note that the KP signal in the ANI sequence is used differently on calls to a LEC OSS switch than on calls to an IC/INC. In addition to providing a Dial Pulse/DTMF indication, it indicates to a LEC OSS switch whether or not the caller dialed a 101XXXX prefix, while on calls to an IC/INC it indicates whether or not the calling station was presubscribed to the IC/INC. This was defined this way in response to the different needs of the LECs and the ICs/INCs.

The signaling for Intercept calls using EAOSS is provided above. The following ANI information digits should be used on these calls:

See Section 2.1.4 for the descriptions of blank number, trouble, and regular intercept.

Operator system hold does not apply on intercept calls. An on-hook from the calling line or the incoming trunk should cause the connection to be released.

2.6.1.4 Basic SS7 Signaling

Common Channel Signaling/Signaling System 7 (CCS/SS7) is an out-of-band signaling scheme that is widely deployed for direct dialed calls that do not require Operator Services handling. It is deployed for some Operator Services calls (e.g., some wireless Operator Services calls), but it is not widely deployed for Operator Services in general.

Dial pulse KP

DTMF KP”

Presubscribed KP

Not presubscribed, or don't know KP’

Dial pulse and presubscribed KP

Dial pulse and not presubscribed/don't know KP’

DTMF and presubscribed KP”

DTMF and not presubscribed/don't know KP”’

30 Blank Number Intercept

31 Trouble Intercept

32 Regular Intercept

2–69


SR-NOTES-SERIES-18

SS7 has many parts including parts that carry the signaling messages from one system to another. These parts are Message Transfer Part (MTP) and Signaling Connection Control Part (SCCP). Other parts of SS7 are used to exchange information between two systems. These parts are the Transaction Capabilities Application Part (TCAP) and Integrated Services Digital Network User Part (ISUP). TCAP is used for non-call-associated signaling, such as the queries between the OSS switch and LIDB (see Section 2.3.1.2.1). ISUP is the part of SS7 that handles call control signaling and replaces the MF signaling between end offices and LEC OSSs and end offices and ICs/INCs, discussed in Sections 2.6.1.1, 2.6.1.2, and 2.6.1.3.

The basic SS7 signaling scheme is defined in GR-317-CORE and GR-394-CORE. This scheme is designed for direct dialed calls, but is sometimes used for Operator Services calls. Basic SS7 signaling excludes support for connection hold, ringback, and coin control, and does not include a way to distinguish 1+calls that require Operator Services handling from 1+calls that do not require Operator Services handling (resulting in the need to differentiate this traffic using trunk groups).

GR-317-CORE and GR-394-CORE discuss the SS7 ISUP messages that are sent between two systems (in this case, the end office and OSS switch). The basic steps are as follows:

1. The calling party dials a valid number (e.g., 1-411 or 411).

2. The end office sends an initial address message (IAM) to the OSS switch, including many parameters.

3. With basic SS7 signaling, the OSS switch may either send an Address Complete Message (ACM) (with the User Network Interaction [UNI] bit set) or an Answer Message (ANM) to the end office. The sending of the ACM with the UNI bit set results in the establishment of the voice path in the forward and backward direction without starting the billing timer at the end office. The ANM message also results in the establishment of the voice path in the forward and backward direction, but the billing timer at the end office would begin at the end office upon receipt of the ANM message.

The end office includes many parameters in the IAM message. The basic parameters are described in GR-317-CORE. Examples of the parameters that are not directly impacted by Operator Services include:

• Message Type

• Nature of Connection Indicators

• Forward Call Indicators

• Calling Party’s Category

• User Service Information

• Jurisdiction Information Parameter (JIP).

For calls that do not involve an IC (i.e., local calls and intraLATA toll calls destined to a LEC), the following parameters would be included in the message:

• Calling Party Number

• Called Party Number

2–70


SR-NOTES-SERIES-18

According to GR-317-CORE, on a per-trunk-group basis, the end office may also include the following parameters that were originally defined for IC calls:

• Charge Number (equivalent to the MF ANI and only included when it is different from the Calling Party Number)

• Originating Line Information Parameter (OLIP) (equivalent to the MF II digits)

Note that a key issue with using the basic SS7 signaling scheme, rather than Operator Services SS7 signaling, is that the Charge Number parameter and Originating Line Information Parameters are not normally sent for non-IC calls. However, the information contained in these two parameters are very important for Operator Services and are received with the MF signaling schemes. As a result, the end offices (and MSCs) should send these parameters to the OSS switch for Operator Services calls with and without IC involvement.

In addition to the above parameters, IC calls include the following:

• Carrier Identification (Presubscribed Carrier Identification Code [CIC] or dialed CAC)

• Transit Network Selection (CIC of Operator Services carrier and circuit code equivalent to 0ZZ code)

• Carrier Selection (e.g., indicates whether Carrier Identification contains presubscribed carrier or dialed CAC)

The Calling Party Number and Called Party Number include information in addition to the digits that is very important to Operator Services. More specifically, the Calling Party Number parameter contains the 10-digit NPA-NXX-XXXX of the Calling Party Number and an indication as to whether or not the number is private (e.g., should not be displayed to called parties, provided to third parties, or recorded on bills, etc.).

The Called Party Number contains the n11 number or NPA-NXX-XXXX number corresponding to the dialed digits or a translated number received from a database (e.g., if AIN processing occurs before setting up the call to the OSS switch). In addition, the Called Party Number parameter contains a Nature of Address field. The coding of this field depends on the dialed digits (or translated number) as defined in Table 2-11.

2–71


SR-NOTES-SERIES-18

Table 2-11 Nature of Address Encoding for Basic SS7 Signaling

Calling Line Class Dialing CdPN/NOA

01+CC+NN “international number,operator requested”

(101XXXX)a+0+NPA+NXX-XXXX(NXX is not 555)

a. Items in parenthesis are optionally dialed.

“national (significant)number, operator requested”

All 0+NXX-XXXX “subscriber number, operator requested”

000 or 101XXXX+0

“no number present, operator requested”

(101XXXX)+0+NPA+555-XXXXb

b. The 555-XXXX dialing sequence refers to the codes which identify Operator Services (e.g., 555-1212).


0+4110+555-XXXX

“subscriber number, operatorrequested”

(101XXXX)+011+CC+NN “international number”

(101XXXX)+1+NPA+NXX-XXXX(NXX is not 555)

“national (significant)number”

Restricted or special lines(e.g., coin, hotel/motel)

NXX-XXXX “subscriber number”

(101XXXX)+1+NPA+555-XXXX

“national (significant) number”

(1)+411555-XXXX

“subscriber number”

Non-restricted or non-special lines(e.g., POTS lines)

(101XXXX)+l+NPA+555-XXXX “national (significant)number”

(1)+411

555-XXXX

“subscriber number”

2–72


SR-NOTES-SERIES-18

2.6.1.5 Operator Services SS7 Signaling

Operator Services SS7 signaling extends the Basic SS7 signaling so that the special needs of Operator Services calls can be accommodated. Operator Services SS7 is not currently deployed.

Operator Services SS7 includes new SS7 ISUP parameters, fields, and values to support connection hold, ringback, coin control, and a way to identify all Operator Services calls, including 1+ calls that require Operator Services handling. Operator Services SS7 also defines the OSS switch handling of the SS7 signaling.

Upon receipt of an Operator Services dialing sequence, the end office includes the following parameters in the IAM message in addition to other parameters needed for basic call processing as described in GR-317-CORE and GR-394-CORE and other parameters needed for other SS7 ISUP features and network capabilities, such as LNP and RTP:

• Calling Party Number

• Called Party Number

• Operator Services Information (e.g., to indicate whether or not ‘0’ was dialed and whether the calling party’s CPE handles dial-pulse or DTMF)

• Originating Line Information Parameter (equivalent to the MF II digits)

• Carrier Identification

• Transit Network Selection (equivalent to 0ZZ code)

• Carrier Selection (e.g., presubscribed or override)

• Service Activation Parameter (for connection hold).

The Nature of Address field in the Called Party Number parameter is encoded differently in the Operator Services SS7 signaling scheme than in the Basic SS7 signaling scheme. In the Basic SS7 signaling scheme, an “operator requested” Nature of Address codepoint indicates that a 0 was dialed (either 0- or 0+). In the Operator Services SS7 signaling scheme, an “operator requested” codepoint indicates that the call requires Operator Services handling. A separate parameter (Operator Services Information) is used to indicated whether or not a 0 was dialed.

Table 2-12 provides the encoding of the Nature of Address for the Operator Services SS7 signaling scheme.

2–73


SR-NOTES-SERIES-18

2.6.2 Wireless: MSC to LEC OSS Switch

Similar to wireline customers, wireless customers are also able to access Operator Services. The most common operator service offered to wireless customers is directory assistance through 411 dialing.

Table 2-12 Nature of Address Encoding for Operator Services SS7

Calling Line Class Dialing CdPN/NOA

01+CC+NN “international number,operator requested”

(101XXXX)a+0+NPA+NXX-XXXX(NXX is not 555)

a. Items in parenthesis are optionally dialed.


All 0+NXX-XXXX “subscriber number, operator requested”

000 or 101XXXX+0

“no number present, operator requested”

(101XXXX)+0+NPA+555-XXXXb

b. The 555-XXXX dialing sequence refers to the codes which identify Operator Services (e.g., 555-1212).


0+4110+555 XXXX

“subscriber number, operator requested”

(101XXXX)+011+CC+NN “international number,operator requested”

(101XXXX)+1+NPA+NXX-XXXX(NXX is not 555)


Restricted or special lines (e.g., coin, hotel/motel)

NXX-XXXX “subscriber number, operator requested”

(101XXXX)+1+NPA+555-XXXX “national (significant) number, operator requested”

1+411 “subscriber number, operator requested”

411

555-XXXX

“subscriber number, operator requested”

Non-restricted or non-special lines (e.g., POTS lines)

(101XXXX)+l+NPA+555-XXXX “national (significant)number”

1+411 “subscriber number, operator requested”

2–74


SR-NOTES-SERIES-18

The wireless service provider usually provides Operator Services to wireless customers by outsourcing the Operator Services to an Operator Services provider. When the wireless service provider outsources Operator Services to a LEC, the wireless service provider routes Operator Services calls to LEC OSS switches. More specifically, the wireless service provider routes the Operator Services calls from a Mobile Switching Center (MSC) in the wireless service provider’s network to the LEC OSS switch. The MSCs are functionally similar to wireline end offices. The key difference is that MSCs serve wireless customers and end offices serve wireline customers.

The signaling used from the MSC to the OSS switch is defined in TR45 Wireless

Telecommunication Ai-Di Interfaces Standard, TIA/EIA-95-B. TIA/EIA-95-B defines the signaling between wireless networks and other networks, including Operator Services.

The wireless carriers use MF and SS7 signaling for interconnection with OSS switches. Section 2.6.2.1 contains a table that lists the MF signaling between an MSC and OSS Switch, and Section 2.6.2.2 describes the SS7 interface.

2.6.2.1 MF

Table 2-13 describes the MF signaling between an MSC in a wireless network and a LEC OSS switch. The MF signaling described in Table 2-13 is from TR45 Wireless Telecommunication

Ai-Di Interfaces Standard, TIA/EIA-95-B. TIA/EIA-95-B refers to the MF Operator Services interface as: Point of Interface[POI]-T10.

Table 2-13 MSC to LEC OSS Switch (MF)

Number Dialed Called Number Portion ANI Portion

411 KP+411+ST’’ KP+II+ANI (7/10D)+ST

0- KP+0+ST KP+II+ANI (7/10D)+ST

0+ KP+4-10D+ST’ KP+II+ANI (7/10D)+ST

IC 0- KP+(CAC)+ST’’’ KP+II+ANI (7/10D)+ST

IC 0+ KP+(CAC)+7/10D+ST’’’ KP+II+ANI (7/10D)+ST

IC 1+ KP+(CAC)+7/10D+ST’’ KP+II+ANI (7/10D)+ST

IC 0- Cut-Through KP+(CAC)+ST’’’ KP+II+ANI (7/10D)+ST’

IC 0+ Cut-Through KP+(CAC)+3/7/10D+ST’’’ KP+II+ANI (7/10D)+ST’

IC 1+ Cut-Through KP+(CAC)+3/7/10D+ST’’ KP+II+ANI (7/10D)+ST’

INC 0- KP+(CAC)+ST’’’ KP+II+ANI (7/10D)+ST

IC 0+ (WZ1) KP+(CAC)+10D+ST’’’ KP+II+ANI (7/10D)+ST

IC 1+ (WZ1) KP+(CAC)+10D+ST’’ KP+II+ANI (7/10D)+ST

IC 0+ (not WZ1) KP+(CAC)+1+CC+NN+ST’’’ KP+II+ANI (7/10D)+ST

IC 1+ (not WZ1) KP+(CAC)+1+CC+NN+ST’’ KP+II+ANI (7/10D)+ST

2–75


SR-NOTES-SERIES-18

2.6.2.2 SS7

This section discusses the SS7 ISUP signaling between an MSC in a wireless network and a LEC OSS switch. The SS7 ISUP signaling discussed in this section is from TR45 Wireless

Telecommunication Ai-Di Interfaces Standard, TIA/EIA-95-B. TIA/EIA-95-B refers to the SS7 ISUP Operator Services interface as: Point of Interface[POI]-S11.

The MSC sends the following SS7 ISUP parameters to the OSS Switch:

• Message Type

• Nature of Connection Indicators

• Forward Call Indicators

• Calling Party’s Category

• User Service Information

• Called Party Number (null contents for 0-, 411, or 4-10D)

• Charge Number (ANI)

• Originating Line Information (II)

• Jurisdiction Information Parameter (JIP)

• Transit Network Selection (CIC).

See GR-317-CORE and GR-394-CORE for descriptions of these SS7 ISUP parameters.

2.6.3 LEC OSS Switch to IC Operator System

The signaling from LEC OSS switches to IC Operator Systems that do not support connection hold, ringback, or coin control capabilities is usually basic SS7 signaling as described in Section 2.6.1.4.

Operator Services SS7 signaling could be used for interactions with IC Operator Systems, but it is not currently deployed.

MF signaling (e.g., pre-EAOSS signaling) is also used between LEC OSS switches and IC Operator Systems.

2.6.4 LEC OSS Switch to LEC OSS Switch

Inward calls require that calls be established from one LEC OSS switch to a different LEC OSS switch. For example, sometimes inward call routing may be used for Busy Line Verification/Interrupt (BLV/I). With BLV/I, a calling party requests an operator to verify whether or not a target number is busy and may also ask the operator to interrupt the target party’s calls. Inward routing is needed when the OSS switch and operator serving the calling party cannot interact directly with the target party’s end office to request the end office to enable the OSS switch to verify the busy/idle condition of the target party’s line. In this case, the operator that servers the calling party (i.e., Operator A) places an inward call to the operator that is

2–76


SR-NOTES-SERIES-18

associated with the target party (i.e., Operator B). Operator B then requests its OSS switch (i.e., OSS switch B) to make a BLV/I request to the end office serving the target party.

MF signaling is currently used for inward calls. A number is signaled from the calling line’s OSS switch to the target number’s OSS switch. The number includes not only the target number, but also identifies the OSS switch that serves the target number using that OSS switch’s Terminating Toll Center (TTC) code. The originating OSS switch may prepend an NPA to the TTC code, and may add digits to the end that identify the type of service (e.g., BLV/I) being requested. The 3, 4, and 5 digits that may be added after the TTC code are provided in Table 12-6 of GR-1144-CORE.

2.6.5 LEC OSS Switch to LEC End Office

When an OSS switch determines that it needs to complete a call to a called number to a terminating end office (without routing to an IC), it routes the call using one of the following signaling alternatives:

• MF signaling

• Basic SS7 signaling

• Operator Services SS7 signaling.

Operator Services SS7 signaling is not yet deployed.

For MF signaling and basic SS7 signaling, the call is not identified as an Operator Services call because the remainder of the call completion of the call is simply to complete the call and, therefore, normal call processing applies. The MF signaling only needs to include the called number. The basic SS7 signaling would include the normal SS7 parameters, such as the message type, calling party number, forward call indicators, nature of connection indicators, JIP, and called party number.

In general, Operator Services SS7 signaling used for call completion from an OSS switch to an end office is identical to basic SS7 signaling. The one extension made for call completion is related to billing verification calls (i.e., calls placed to called parties and third parties to verify charges). With Operator Services SS7 signaling, the OSS switch identifies billing verification calls by including a Service Activation Parameter (SAP) in the SS7 ISUP IAM message sent from the OSS Switch to the end office. According to GR-1144-CORE, the OSS switch identifies the billing verification call by populating the SAP parameter with the billing verification value.

2.6.6 Wireless: LEC OSS Switch to MSC

MF signaling or basic SS7 signaling may be used between the LEC OSS switch and the MSC for terminating calls. For MF signaling, the LEC OSS switch only needs to signal the called number. The LEC OSS switch includes additional parameters with basic SS7 signaling, such as the calling number.

2–77


SR-NOTES-SERIES-18

2.7 Automatic Message Accounting (AMA)

Automatic Message Accounting (AMA) is the process that generates data from which customers and carriers are billed for their use of network services and capabilities; AMA data may be used for other purposes as well. The Billing Automatic Message Accounting Format (BAF) is a system of abstract syntax and semantics that supports coding of AMA data into data records. BAF is the preferred format for all AMA data generated for processing by a LEC Revenue Accounting Office (RAO), and is administered by Telcordia.

The basic element of a BAF record is a data field, also known as a “table” and referred to by its table number. BAF tables are arranged in fixed structures and modules. An OSS switch BAF record contains a predefined “structure” of fields, to which “module(s)” of fields are appended to enable additional information to be recorded along with the structure. The key to the network’s choice of the proper structure for coding BAF data is the type of call, or “call type”. Fields (tables), structures, call types, and modules are referred to as BAF elements.

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 are recorded. Each structure is a unique, ordered set of fields identified by a structure code, the third data field in the record. 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. Modules are appended to a structure according to the service/technology being recorded or to capture information connected with specific conditions. BAF modules provide the flexibility needed to permit rapid introduction of AMA data generation for new services, features, and network capabilities. Modules capture extra information pertinent to the service/technology provided. The data element generating the BAF record associates the service or capability provided with a BAF “call type” and call type code, which is used by RAOs in processing the BAF record.

The requirements for AMA data generation by an OSS switch are contained in GR-1147-CORE. OSS switches output BAF records; BAF specifications are in GR-1100-CORE, Billing

Automatic Message Accounting Format (BAF) Requirements, including the format of each BAF element (i.e., data fields, structures, call types, and modules). The call detail recording functions include all the AMA recording necessary for Operator Services, as GR-1147-CORE requires. AMA includes the usage data associated with automated and manual LEC Operator Services defined throughout the OSSGR. LECs use the AMA data as the basis for billing end users and other entities, such as wireless service providers, Competitive Local Exchange Carrier (CLECs), or Interexchange Carrier (ICs), for their use of the LEC’s network and its services.

For Operator Services, the AMA data common to all or most services are recorded in OSS switch structures. Service-specific, billing-option-specific, and handling-specific data are recorded in service-specific, alternate billing, and person handling modules.

• Examples of data in Operator Services structures include:

— Recording Office Identification

— Date

— Timing Indicator

2–78


SR-NOTES-SERIES-18

— Study Indicator

— Originating NPA

— Originating Number

— Time

— Elapsed Time

— Operator Identification

— Accumulated Operator Work Time

— Service Feature Code.

• Examples of modules recorded at the OSS switch include:

— Call Completion module

— Listing Services Module

— Alternate Billing module

— Person Handling module

— Exchange access modules

— Local Number Portability (LNP) module

— Local Service Provider Module.

• Examples of information recorded in the modules include:

— Account Owner

— Billing number information

— Call Completion conditions

— Information about the calling line from an OLNS query

— Listing Services Database (LSDB) information

— LNP information

— Restrictions information

— Service Identification.

The philosophies underlying the AMA requirements of the OSS switch include the following:

A. AMA is integrated with call processing; BAF modules are based on AMA data needs identified in call flows described in OSSGR FSDs.

B. BAF modules that record service, billing, handling, and exchange access aspects of a BAF record correspond to the OSSGR's modular description of OSS switch call processing. The types of modules used in forming OSS switch BAF records include service modules, the Alternate Billing module, the Person Handling module, and exchange access modules.

C. The predefined OSS switch BAF structures, to which modules are appended, contain those parameters common to all or most OSS-provided services. For example, because every call

2–79


SR-NOTES-SERIES-18

has associated customer-dialed digits, they are recorded in a predefined OSS switch structure rather than in a service-specific module. Parameters not common to all Operator Services are recorded in service-specific, billing-specific, handling-specific, or exchange access modules.

D. Selection of the appropriate BAF structure to which modules are appended depends on whether the call arrives at the OSS switch 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 [see GR-1173-CORE, OSSGR: Common Functions

(FSD 65 Series), FSD 65-01-0100].

E. Complete, standalone BAF records are made at the OSS switch for all Operator Services calls, including Listing Services calls, calls originating from all types of end offices and MSCs, and calls terminating from exchange carriers, ICs, and International Carriers (INCs). These records are used for billing the end user, for billing IC/INCs for originating access and terminating access charges, and for billing exchange carriers, ICs, INCs, and wireless services providers for OSS processing.

F. The parameters that are required to be recorded in the modules allow for, but do not define, likely tariffs. The OSS switch records the information pertinent to a call, and the RAO determines and applies the appropriate tariff. Pertinent information is recorded for certain non-completed Call Completion calls, such as person-attempt and collect-attempt calls, and for all interLATA attempts.

G. Separate BAF records are made for related calls, each with an indication of how each record relates to the others. As a result, there can be multiple records for a single “session” of customer use of the OSS switch. 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 switch 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.

• Calling Card sequence calls each generate separate BAF records. For each call billed to a calling card, the OSS switch generates a record. A counter in each of these records indicates to which call in the sequence that record corresponds.

• When a customer makes multiple Listing Services requests on one call to the OSS switch, a BAF record is generated for each individual request. A counter in each record indicates to which in the series of requests that record corresponds to.

• For a Directory Assistance call followed by Call Completion, the OSS switch generates two BAF records. The first record generated is for the Listing Service call; the second is for the subsequent Call Completion. The record for the Call Completion call contains a table value indicating that the call is “subsequent to Directory Assistance.”

H. 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, FSD 65-01-0100. The OSS switch generates per-call billing records for LEC intraLATA Operator Services calls and for IC/INC exchange access Operator Services calls.

2–80


SR-NOTES-SERIES-18

The format elements generated for a particular record depend on the capabilities the OSS switch uses for call processing. For example, if an OSS switch is not capable of launching OLNS queries, or is capable of launching, but does not launch an OLNS query (either is not capable of launching OLNS queries, determines that OLNS is not necessary based on the ANI II (in MF)/OLIP (in SS7) and/or incoming trunk group number, or determines OLNS is necessary, but, for reasons such as ACG procedures, does not launch an OLNS query), then a different AMA structure is generated than when an OLNS query is launched.

In addition to generating AMA records for LEC intraLATA completed calls or services, the OSS switch generates a BAF record for each originating and terminating exchange access call for which some type of processing is done, such as 0- transfer to an IC. The OSS switch owner also has the ability to have the OSS switch generate BAF records for all or some subset of intraLATA originating call attempts for study and/or attempt charging purposes.

AMA records that an OSS switch produces for RAO processing conforms to BAF requirements in GR-1100-CORE, Billing Automatic Message Accounting Format (BAF) Requirements. FR-271, OSSGR, contains AMA data generation requirements for the following Operator Services, billing options, and handling options, and for when the OSS provides exchange access functions.

• Services:

— Call Completion Service (FSD 80-01-0500), GR-1176-CORE

— Directory Assistance (FSD 75-01-0100), GR-1175-CORE

— Customer Name and Address (FSD 75-01-0200), GR-1175-CORE

— Address Provision (FSD 75-01-0300), GR-1175-CORE

— Name and Telephone Number Provision (FSD 75-01-0400), GR-1175-CORE

— Zip Code Provision (FSD 75-01-0500), GR-1175-CORE

— Area Code Service (FSD 75-01-0700), GR-1175-CORE

— Area Business Listing (FSD 75-01-0900), GR-1175-CORE

— Dialing Instruction (FSD 70-01-0100), GR-1174-CORE

— Rate Information (FSD 70-01-0200), GR-1174-CORE

— Credit Recording (FSD 70-01-0400), GR-1174-CORE

— Trouble Reporting (FSD 70-01-0500), GR-1174-CORE

— General Information (FSD 70-01-0900), GR-1174-CORE

— Intercept Services (FSD 70-01-1200), GR-1174-CORE

— Busy Line Verification and Operator Interrupt (FSD 80-01-0300), GR-1176-CORE.

• Billing Options:

— Calling Card Billing (FSD 85-01-0100), GR-1177-CORE

— Collect Billing (FSD 85-01-0200), GR-1177-CORE

— Third Number Billing (FSD 85-01-0300), GR-1177-CORE.

2–81


SR-NOTES-SERIES-18

• Handling Option:

— Person Handling (FSD 80-01-0600), GR-1176-CORE.

• Exchange Access:

— Exchange Access (Common Functions, FSD 65-01-0100), GR-1173-CORE.

When an OLNS query is not launched for a call that arrives on an originating basis, the OSS switch generates Structure Code 0752 for that call’s AMA record. When a call arrives on a terminating basis, the OSS switch generates Structure Code 0751. When an OLNS query is launched for a call that arrives on an originating basis, the OSS switch generates Structure Code 0772. The OSS switch then appends the appropriate module(s) to the Structure to reflect the service and/or handling options provided on that call.

The following examples of calls that OSSs process illustrate the corresponding AMA records that would be generated:

A. Originating Directory Assistance Request Billed to a Calling Card

• Structure Code 0752 (no OLNS)/0772 (OLNS); the value in the Call Type Code data field would be 194 for this type of call,

• Listing Services Service Module (Module Code 055), with its Service Identification data field set to “Directory Assistance”

• Alternate Billing Module (Module Code 052), with its Billing Type Identification data field set to “Calling Card”

• Final Module (Module Code 000).

B. IntraLATA Person Collect Call-Originating Call Completion

• Structure Code 0752 (no OLNS)/0772 (OLNS); the value in the Call Type Code data field would be 192 for this type of call,

• Call Completion Service Module (Module Code 051) (terminating number is 12 digits or less)

• Alternate Billing Module (Module Code 052), with its Billing Type Identification data field set to “Collect”

• Person Handling Module (Module Code 050)

• SPID Module (Module Code 338) if an OLNS query was made and the originating line’s Account Owner (AO) or Billing Service Provider (BSP) was received in the OLNS response; two SPID Modules are generated if both AO and BSP were received in the OLNS response.

• SPID Module (Module Code 338) if the billing line’s AO or BSP was received in the BNS response; two SPID Modules are generated if both AO and BSP were received in the BNS response.

• Final module (Module Code 000).

2–82


SR-NOTES-SERIES-18

In summary, the use of BAF Modules in OSS switch BAF records is consistent with the OSSGR’s modular concept of an Operator Service and its associated billing, handling, and exchange or exchange access attributes. The OSS switch generates modules as appropriate for a particular call’s circumstances. The modules that the OSS switch generates depend on the type of service being requested, the kind of alternate billing and alternate handling being requested (if any), whether exchange access functions are being provided, and whether certain information is received in an OLNS response. In addition, requirements support the ability for generation of certain modules to be based on an OSS-owner-settable option for that OSS. One or more distinct modules along with an OSS switch structure form a complete BAF record; each structure contains a call type code field that 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”, and the alternate billing aspects of the call will be reflected in the ABS Module appended to the structure).

The following three tables summarize the AMA that is defined for OSS switches, identifying when the three OSS AMA structures are used. They illustrate what modules are used with each structure for each type of call, including the required module for each call type plus additional modules that may be appended depending on specific call circumstances.

2–83


SR-NOTES-SERIES-18

1. M

( .

( g any O 752/0772a

1 Module 052 Module 05 ded in an AMA record not a call completion 3 Module 054 Module 055 A Module (BSP) is received in a

Operator Services System AMA Structures, Modules, Call Types

odules and Call Types: Originating Calls, OLNS Query Not Launched

Structure Code 0752 is used, with the following Call Types and Modules:

Call Type Code Call Type Required Module for Call Type 189 Credit Recording Service 058/158: Credit Recording Service Module1 190 Originating Operator Service Carrier

Identification 053: IC/INC Call Delivery Module, or 054: IC/INC Information2 Module

192 Originating Call Completion Service 051/151: Call Completion Service3 Module 194 Originating Listing Service 055: Listing Services Service Module 196 Originating General Assistance

Service 057: General Assistance Service Module

198 Originating Busy Line Verification Service

056/156: Busy Line Verification Service Module4

Additional Modules may be used with SC 0752:

The following Modules are also appended to SC 0752 when the particular call processing they record e.g., billing option other than sent-paid; account owner returned in BNS/CC response) is performed for a call

022 Long Duration Call Module 050 Person Handling Module 052 Alternate Billing Module 059 Exchange Access Service Processing Time Module 060 Charge Module 062 Notify Module 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 Module (s)5 (for billed number)

Note re originating OSS calls: For originating IC calls routed through a LEC’s OSS switch without undergoinperator Services processing other than its switch’s tandem function, the OSS-specific originating Structures 0

re not used. Instead, Structure Code 0625 is recorded with Call Type Code 251).

8 is used when the terminating number is 12 digits or less, and Module 158 is used when the terminating number exceeds 12 digits. 3 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 inclu 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

call (only recorded for trouble reporting or rate information). 1 is used when the terminating number is 12 digits or less, and Module 151 is used when the terminating number exceeds 12 digits 6 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. 338 is generated when an Account Owner (AO) is received in a BNS or CC response, and a Module 338 is generated when a Billing Service Provider BNS or CC response; therefore, if both are received from LIDB in a BNS or CC response, two Module 338’s would be appended to the Structure.

2–84


SR-NOTES-SERIES-18

2. M

(

1 Module 052 Module 05 ded in an AMA record ot a call completion 3 Module 054 Module 055 A Module SP) is received in a n a Billing Service Prov O’s and BSP’s are re

odules and Call Types: Originating Calls, OLNS Query Launched


Call Type Code Call Type Required Module for Call Type 189 Credit Recording Service 058/158: Credit Recording Service Module1 190 Originating Operator Service

Carrier Identification 053: IC/INC Call Delivery Module, or 054: IC/INC Information2 Module

192 Originating Call Completion Service

051/151: Call Completion Service3 Module; 104: Trunk Identification Module (When local call completion)

194 Originating Listing Service 055: Listing Services Service Module 196 Originating General Assistance

Service 057: General Assistance Service Module

198 Originating Busy Line Verification Service

056/156: Busy Line Verification Service Module4


The following Modules are also appended to SC 0772 when the particular call processing they record (e.g., billing option other than sent-paid; account owner returned in OLNS response) is performed for a call and, in the case of Modules 019 and 219, if the capability to generate them is “turned on” at the OSS switch).

019 Originating Billing/Services Information Module 022 Long Duration Call Module 050 Person Handling Module 052 Alternate Billing Module 059 Exchange Access Service Processing Time Module 060 Charge Module 062 Notify Module 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 Module 338 Service Provider Information Module (s)5 (for billed number and/or originating number)

8 is used when the terminating number is 12 digits or less, and Module 158 is used when the terminating number exceeds 12 digits. 3 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 inclu 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 n

call (only recorded for trouble reporting or rate information). 1 is used when the terminating number is 12 digits or less, and Module 151 is used when the terminating number exceeds 12 digits. 6 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. 338 is generated when an Account Owner (AO) is received in a BNS or CC response, and a Module 338 is generated when a Billing Service Provider (B BNS or CC response; a Module 338 is generated when an Account Owner (AO) is received in an OLNS response, and a Module 338 is generated wheider (BSP) is received in an OLNS response; therefore, up to four Module 338’s would be appended to the Structure, depending upon which (if any) Aceived from LIDB in a BNS or CC, and OLNS, response.

2–85


SR-NOTES-SERIES-18

3. M

(

1 Module 0 inatingcall is not ro record andthe operator2 Module 053 Module 054 A Module SP) isreceived in a

odules and Call Types: Terminating Calls


Call Type Code Call Type Required Module for Call Type191 Terminating Operator Service

Carrier Identification053 IC/INC: Call Delivery Module, or054 IC/INC: Information1 Module

193 Terminating Call CompletionService

051/151: Call Completion Service2 Module

195 Terminating Listing Service 055: Listing Services Service Module197 Terminating General Assistance

Service057: General Assistance Service Module

199 Terminating Busy Line VerificationService

056/156: Busy Line Verification ServiceModule3

215 Terminating Intercept Service 063: Intercept Services Module


The following Modules are also appended to SC 0751 when the particular call processing they recorde.g., billing option other than sent-paid; account owner returned in BNS/CC response) is performed for a call.

022 Long Duration Call Module050 Person Handling Module052 Alternate Billing Module338 Service Provider Information Module (s)4 (for billed number)

53 is included in an AMA record if a terminating call is routed directly from a carrier to the OSS. Module 054 is included in an AMA record if the termuted directly from a carrier to the OSS (i.e, enters the network at an access tandem other than the OSS; the access tandem makes the terminating access services system makes the service record).1 is used when the terminating number is 12 digits or less, and Module 151 is used when the terminating number exceeds 12 digits.6 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.338 is generated when an Account Owner (AO) is received in a BNS or CC response, and a Module 338 is generated when a Billing Service Provider (B BNS or CC response; therefore, if both are received from LIDB in a BNS or CC response, two Module 338’s would be appended to the Structure.

2–86


SR-NOTES-SERIES-18

2.8 Force Measurements

The goal of Operator Services Force Management is to provide the correct number of operators at positions at any given time. These operators need to be capable of processing calls at the expected rate that LEC standards define. To enable LEC Force Managers to meet their objectives, they must obtain data describing the performance of administrative groups of operators. Each administrative group is referred to as a Forcing Entity. Data is provided to Force Managers in the form of Force Reports, which are generated by Force Management Systems using force measurements.

The force measurements may be generated by the OSS switch and/or by a Force Management System connected to the OSS switch. The OSS switch can send the force measurements to the Force Management System and can continuously send events to the Force Management System to enable the system to generate its own force measurements.

The force measurements are generated for specific types of calls for the Forcing Entity. For example, force measurements can be generated for DA calls and for toll and assistance calls. The type of call is derived from a variety of information based on the incoming signaling, information retrieved from a database, and/or information obtained from the caller, such as:

• Class of Service - identifies the service or equipment associated with the calling party’s line. The OSS obtains this information from the MF ANI II digits, SS7 ISUP Originating Line Information Parameter (OLIP), provisioned information in the OSS, or the Service or Equipment Identifier parameter from a Line Information Database (LIDB) Originating Line Number Screening (OLNS) Response. Examples include POTS, different types of cellular, coin, hotel/motel, restricted - prison, restricted - hospital, identified line, and unknown.

• Billing/Service Indicator - identifies the type of billing that is allowed for the calling line. This information is obtained from the billing/service indicator and additional billing/service indicator parameters from the LIDB OLNS response or, in a pre-OLNS environment, from information at the OSS switch.

• Carrier Identifier - identifies the carrier that is associated with the calling line for an intraLATA toll or interLATA call. The Carrier Identifier is applicable when the LEC provides Operator Services on behalf of an IC. The Carrier Identifier may be received in signaling information or obtained from a LIDB OLNS response or, in a pre-OLNS environment, from information at the OSS.

• Prefix Indicator - identifies whether the dialed digits are 0+, 0-, or direct dialed (1+ or no prefix).

• Dialed Digits - include numbers, such as 411, NPA-555-1212, NPA-555-1313, that correspond to specific Operator Services (if dialed 0-, service can be determined via customer interaction with the caller).

• Incoming Trunk Group - the trunk group on which the Operator Services call arrives to the OSS switch. This trunk group is relevant because different types of Operator Services traffic may be separated onto different trunk groups to enable the OSS switch to distinguish the traffic.

2–87


SR-NOTES-SERIES-18

• Language Identifier - identifies the desired foreign language associated with the calling line. This information may be obtained from the Foreign language indicator from the LIDB OLNS response or from user input provided to an operator or automated system.

• Time of Day/Day of Week- may be used to determine the call type.

• Treatment - indicates whether or not manual treatment is required and the type of manual or automated treatment. The treatment is obtained from the Treatment Indicator parameter received in the LIDB OLNS response or, in a pre-OLNS environment, from information at the OSS switch.

• Calling Party Number - refers to any NPA, NPA-NXX, or NPA-NXX-XXXX numbers that are used for call distribution to operators. For example, calls from NPA-NXXs of wireless numbers may be routed to a different queue than calls from wireline NPA-NXXs.

The queue to which a call is distributed is also determined by the same information used to derived the type of call. The force measurements are often generated on a per-queue basis.

Two types of force measurements are generated: peg counts (PC) and usage (U) measurements. Peg Counts provide the number of times a particular event occurs. The usage measurements measure the total time a system or facility is performing a function, not performing any function, or waiting for an event to occur.

The following identifies examples of force measurements generated by the OSS switch or by the Force Management System:

• Initial Calls (PC) -The number of incoming facility seizures for which the system initially establishes a connection to an operator position. This count should be provided for each call type and for each Forcing Entity.

• Abandoned Initial Calls (PC) - The number of incoming facility seizures destined for a connection to an operator position but terminated prematurely. This count should be provided for each call type and for each Forcing Entity.

• Position Busy Attempts (PC) - The number of times an occupied operator position is manually made busy. This measurement should be provided for each Forcing Entity.

• Initial Calls Waiting (U) - The total time generated by an incoming facility waiting for a connection to an operator position. This measurement includes calls that are connected to an operator position and excludes calls that terminated prematurely. This measurement should be provided for each call type and for each Forcing Entity.

• Initial Work Volume (U) - The total time generated by an occupied operator position busy serving initial calls. This measurement should be provided for each call type and for each Forcing Entity.

• Busy Work Volume (U) - The total time generated by an occupied position that is unavailable to handle incoming calls, recalls, reconnected calls, supervisory calls, or outgoing calls. This measurement should be provided for each Forcing Entity.

• Positions Occupied (U) - The total time generated by an operator position from the time the operator headset is plugged in until the time the headset is removed. This measurement should be provided for each Forcing Entity.

2–88

Issue 1, May 2002 Telcordia Notes on Operator ServicesOperator Services Evolution

SR-NOTES-SERIES-18

3 Operator Services Evolution

Section 2 discussed the currently implemented Operator Services technology and services. This section explores the future direction to which Operator Services may be heading. Operator Services evolution is currently focused on advancing the type of information provided to end users on behalf of wireless providers, adopting new ways of providing the information to all end users, integrating state-of-the art speech technology, and migrating to packet technology. Much of the service focus is on directory assistance (DA)-related services, and therefore this section addresses Listing Services evolution and does not describe the evolutionary strategies of other Operator Services.

An important trend with DA relates to the information that is provided. For many years, callers dialed 1+411 or 411 to request a local listing, meaning a listing contained in the database serving the OSS serving the calling line. In the late 1990s, LECs began to extend the DA service to provide national listings in addition to local listings, meaning that end users could call their local DA provider via (1+)411 and request and receive a number associated with a line anywhere in the country. Further, some LECs are providing enhanced DA services (e.g., business category search, travel directions, and movie listings) to end users on behalf of wireless services providers. Additional advanced information services are anticipated to be provided by LECs on behalf of wireless service providers.

Another trend for DA and information services is the way in which the information is provided to end users. Currently, the LECs provide the found telephone number to end users verbally via operators or announcements. The extensive public adoption of personal computers (PCs) and Internet access as a popular means of obtaining data, along with the technology advancements associated with information access from mobile phones, Personal Digital Assistants (PDAs), and other Customer Premise Equipment (CPE), substantiate the need for LECs to consider ways other than verbal methods to provide listings and additional information to end users. In the future, the information may be provided using whatever mode that each end user desires, such as Short Message Service (SMS), Wireless Application Protocol (WAP), e-mail, fax, as well as voice announcements and personalized operator-customer interactions.

A trend for call centers is the migration to contact centers to handle incoming requests through many channels, including telephone calls, requests for assistance made from a web page, and incoming messages, including incoming e-mail, voice mail, and fax. As with other call centers, in the future, the operator centers may evolve to providing information and assistance to customers that arrive to the operator center using other means besides telephone calls.

Not only are the LECs grappling with the challenge of providing more information in new ways to wireless customers (and possibly customers accessing the Internet), the LECs are also challenged with advancing their service offerings using more cost-effective operator centers. Technology evolution is needed to enable the LEC operator centers to become even more efficient.

One way to become more cost-effective in any labor-intensive center, including operator centers, is through automation. As indicated in Section 2 of this document, many LECs already support automation for DA, such as front-end announcements, voice store and forward,

3–1

Telcordia Notes on Operator Services Issue 1, May 2002Operator Services Evolution

SR-NOTES-SERIES-18

silence deletion, some speech recognition for locality and frequently requested listings (FRLs), back-end announcements, and text-to-speech (for reverse DA). They also already support automation for alternate billing, including support for callers’ DTMF and/or voice entry of billing options and billing numbers, and billed parties’ DTMF and/or voice entry of billing acceptance or rejection. In addition, some locations provide automated 0- front-end processing.

Embracing speech recognition and text-to-speech advancements for DA is a near-term focus for the industry. Automated DA applications that are able to fully automate a relatively high percentage of calls exist in a lab environment, but questions still remain about the percentage of automated calls that can be achieved for actual deployments. Uncertainty surrounding the end users’ acceptance of new automation in the DA industry influences an expected cautious introduction of the speech technology advancements.

In addition to more automation, to improve the cost effectiveness of their operator centers, LECs are seeking additional efficiencies through more flexible queuing and call distribution, supervisor monitoring, and operator center rearrangements. It is desirable to be able to distribute calls to any operator within a given LEC independent of geographic location, and to enable any supervisor to monitor any operator independent of the geographic locations of the supervisors and operators. The LECs may also want to experiment with large centralized operator centers versus many distributed smaller operator centers that are located near the end users. Efficient ways of rearranging operator centers are needed to enable LECs to experiment with these different types of operator centers.

The increased flexibility in the areas of queuing and call distribution, supervisor monitoring, and operator center rearrangement, can be realized with packet connectivity to the operator workstations and between switches. Internet Protocol (IP) connectivity to operator workstations is the current state-of-the art method for enabling this type of flexibility for any call center, including operator centers.

Overall, to enable LECs to provide more information services in a more efficient manner, technology advancements are needed and are being considered in the following areas:

• Queuing and Call Distribution Advancements using IP Connectivity

• Operator Workstation Flexibility including support for IP

• Operator Services - Specific Functions - Service Creation Capabilities

• Database Advancements, including wireless location support

• Voice Server Functions - Speech Technology Advancements

• Administrative Advancements, especially in the areas of Supervisor Monitoring, Force Measurements, and AMA recording

• Multi Mode Delivery of Information

• Multi Media Services, including ways of assisting customers browse through the Internet.

Telcordia Special Report SR-5093, Voice Over Packet (VOP): Operator Services in a Next

Generation Network (NGN), defines a generic NGN Operator Services architecture that supports the above desired technology advancements. In addition, alternative evolution

3–2


SR-NOTES-SERIES-18

options from the existing OSS infrastructure begin to realize many of the concepts associated with the generic NGN Operator Services architecture.

The remainder of this section is organized as follows:

• Section 3.1 discusses many technology advancements desired for Operator Services.

• Section 3.2 describes a generic NGN Operator Services architecture based on SR-5093. The generic NGN Operator Services architecture supports existing Operator Services and the desired technology advancements.

• Section 3.3 discusses possible migration paths for the Operator Services technology.

3.1 Technology Advancements Desired for Operator Services

This subsection discusses the technology advancements desired for Operator Services for each of the following categories:

• Queuing and Call Distribution

• Operator Workstation

• Operator Services - Specific Functions - Service Creation Capabilities

• Databases

• Voice Server Functions - Speech Technology

• Administrative Functions

• Multi Mode Delivery of Information

• Multi Media Services.

3.1.1 Queuing and Call Distribution

Queuing and call distribution functions are critical functions for any contact center, including operator centers. When a call arrives, the queuing and call distribution functions distribute the call to an available operator with the appropriate skill set. When no operators are available, the call is queued and alerting tones or announcements may be provided to the calling party.

The current queuing and call distribution functions flexibly match types of calls to an available operator with the necessary skill. Capabilities exist today to determine the type of call based on a large set of criteria, such as incoming trunk, carrier identifier, class of service, and dialed digits. Although the current capabilities are flexible, advancements are desired to be able to distribute calls to any operator, independent of geography. Efficiencies can be realized by managing all operators within a company as one large team.

These advancements require increases in capacity and require IP connectivity from the workstations to the OSS switch. Note that with future technology the “OSS switch” as we currently know it today may no longer exist. The OSS switch may be replaced by several servers and systems, such as a queuing and call distribution server, a server providing Operator Services-specific processing, and other systems that provide the bearer control

3–3


SR-NOTES-SERIES-18

functions. See Section 3.2 for a description of a generic NGN Operator Services architecture that supports separate systems for queuing and call distribution functions, Operator Services-specific functions, and bearer control functions. In this case, the IP connectivity would reside between the operator workstations and one or more server(s) providing the queuing and call distribution functions and Operator Services processing, and between the operator workstations and the system providing the bearer connection for the voice connectivity.

3.1.2 Operator Workstation

The current operator workstations have sufficient sophistication to appropriately display information received from the OSS switch and to enable the operators to make many different types of call control requests to the OSS switch. The screens are specific to the type of Operator Service and are designed with many years of Operator Services experience to optimize the operators’ activities.

Key potentially useful features that are missing from the current workstation implementations include service creation environment, flexibility, and a modular design of the operator workstation itself. Many of the current challenges with advancing new Operator Services and capabilities relate to the workstations.

The LECs want the capability to make changes to the screen layout and to the content of the screen for a given service. Some of the existing workstations can support this flexibility, but increased flexibility is desired.

A modular architecture is critical to be able to simplify the process of supporting many new types of interfaces, such as the international E.115 interfaces, Hypertext Markup Language (HTML) interfaces, eXtensible Markup Language (XML) interfaces, Open Database Connectivity (ODBC) interfaces, and various interfaces to existing Listing Services Databases. The workstations should have several modular capabilities, such as administration, service creation, and release to audio, that could be used with any of the interfaces. Extension mechanisms should be supported on the operator workstations to simplify the process of adding new information to the interfaces (e.g., by setting up functions to automatically pass new information to other systems without having to process the new information).

In addition, a user-friendly service creation environment is very desirable to enable the LECs to add extensions to existing services/screens and to create new services/screens, such as new information services or screens for new information services, without supplier involvement.

Another critical capability for operator workstations is the support of IP connectivity to enable operators and supervisors to be located anywhere. IP connectivity may be supported using H.323 or Session Initiation Protocol (SIP).

Multi-mode delivery is also a desired operator workstation capability. It could enable operators to request delivery of the requested information to end users using Short Message Service (SMS), Wireless Application Protocol (WAP), e-mail, and fax.

Multi-media services are also desired in the future to enable the operators to assist customers while they are on a web site, such as a LEC’s yellow pages web site. Another important multi-media capability is to process incoming e-mail, voice mail, or fax messages received from customers as a way of them making requests in addition to today’s voice requests.

3–4


SR-NOTES-SERIES-18

3.1.3 Operator Services-Specific Functions - Service Creation Capabilities

The current OSS supports a very rich set of existing Operator Services, as Section 2 of this document discusses.

As with the workstation, a service creation environment is critical for the evolution of Operator Services. LECs need an environment to make changes to existing services, such as changing the point in service processing where certain database queries occur or where connections to specific announcements occur. Ideally, these capabilities would not be “hard-coded” for a service, but rather they would be settable and changeable by the LECs.

The type of service creation capabilities desired for directory assistance automation is discussed in Section 3 of GR-2867-CORE, Generic Functional Requirements for an SPP to

Support DAA. For example, LECs desire the capability to create and modify a service process flow, referred to as a capability flow in GR-2867-CORE.

All the automation services need to perform certain fundamental capabilities, including:

• Accessing Data

• Collecting DTMF digits

• Establishing connections (e.g., between calling and called parties, between calling parties and operators, and between operators and called parties); this capability includes the exchange of context data, such as locality, name, and any information accessed as part of an EDA service.

• Playing announcements

• Processing voice (e.g., voice store and forward and speech recognition).

The service creation capabilities are anticipated to enable the LECs to specify the sequence of these fundamental capabilities (e.g., (1) play specified announcement, (2) process voice, (3) access data, (4) establish connection) and to specify information associated with the capabilities. For example, the service creation environment is anticipated to provide a way for the LECs to indicate which data and which databases need to be accessed for a service and to identify the specific context information, such as locality and name, that needs to be passed to an operator workstation or another system. Note that the database interfaces are not anticipated to be defined as part of the service creation process. These interfaces need to be developed by the supplier.

3.1.4 Databases

The current listing services databases provide requested listings with a high degree of accuracy. Contributing to this accuracy is the capability that LECs can extend the fields of the databases, including the search fields.

Extensions are desired to add new communications addresses, such as wireless listings, pager numbers, e-mail addresses, and URLs, to the databases. Extensions are also desired to be able to search on new fields, for example to support reverse searches, to query for another

3–5


SR-NOTES-SERIES-18

communication address based on telephone number, and to perform business category searches.

Extensions are desired to support geocoding of the database to enable the searches based on the location of a wireless subscriber. The wireless subscriber may either verbally inform the operator or automated system of his/her location or the OSS may automatically access the location of the wireless end user from the wireless service provider. The wireless service provider may use the Global Positioning System [GPS] to track the wireless end user’s location.

IP connectivity to listing services databases is also desirable to reduce costs from the costs of the current X.25 connections.

The other database advancements include the support of new types of data, such as maps, weather, and movie listings.

3.1.5 Voice Server Functions - Speech Technology

Increased automation is currently widely discussed in the DA industry. Opportunities for full DA and EDA automation of many calls (possibly over 20% of the DA calls) are anticipated from automation applications, although this will need to be confirmed for actual deployments.

Currently, as indicated in Section 2, the industry has experience with automation achieved through speech recognition for locality recognition and recognition of Frequently Requested Listings (FRLs) for DA, and for acceptance/rejection of alternately billed calls. Many seconds of work time are saved with sophisticated store and forward capabilities and with front-end locality recognition. Calls to FRLs can be fully automated today with Nortel Networks’ ADAS plus. However, the administration of FRLs can be difficult. Work time is also saved with the automation of the acceptance/rejection of collect and Third Number calls.

In the future, the desire is to have full automation for more residential and business listings than just FRLs. The automation capabilities would benefit from tools that simplify the administration of the “grammars” and listings needed for the automation.

New text-to-speech capabilities are needed for EDA in addition to the existing text-to-speech capabilities used for reverse DA. For example, text to speech capabilities may be used to provide travel directions to end users.

3.1.6 Administrative Functions

One important administrative function in the provision of Operator Services is the ability for supervisors to monitor operator conversations and operator screens. The future vision is to have any supervisor monitor any operator independent of their geographic locations. Ultimately, IP connectivity to the operator and supervisor workstations is the anticipated method for achieving full geographic independence among operators and supervisors.

Another very important administrative function is force management. To efficiently and cost-effectively manage the operator centers, the LECs need to ensure that they consistently

3–6


SR-NOTES-SERIES-18

schedule the minimum number of operators with the required skill sets that are necessary to achieve the desired business objectives (e.g., speed of answer).

Detailed measurements for new services need to be provided to the Force Management Systems to enable them to generate customized Force Management Reports for the LECs. Basic measurements have been provided in the past, and GR-1147-CORE, Section 2 defines new required force measurements and GR-1163-CORE, Section 2 defines the corresponding Force Data Elements for the Force Data Reports.

A third critical administrative capability is call detail recording. Additional Automatic Message Accounting (AMA) needs to be recorded to capture new service identifiers and new service-specific information for the information services and multi-media services.

3.1.7 Multi-Mode Delivery of Information

Some DA providers are beginning to provide found telephone numbers to mobile phones using Short Message Service (SMS). It is desirable for this trend to continue with other information, such as travel directions and movie listings. More specifically, it would be beneficial to DA providers if their operators and automated systems would be able to provide information to end users in any mode desired by the end users, such as verbally, SMS, Wireless Application Protocol (WAP), e-mail, and fax.

3.1.8 Multi-Media Services

The current model for DA is voice in, voice out. Callers dial 411 or 1+411 and verbally request a listing, and the found telephone number is spoken to the caller by an operator or an announcement.

In the future, the LECs may provide advanced information to callers. On behalf of other service providers (e.g., wireless service providers), LECs can provide new types of information to customers, such as travel directions, weather, moving listings, and restaurant information. This too will initially likely be a voice in, voice out approach where the request will be made verbally and the information will be provided verbally.

Another desired migration, as discussed in Section 3.1.7, is to deliver the telephone number and other advanced information to end users using multiple modes, such as SMS, WAP, e-mail, and fax. This migration supports a voice in, voice out model as well as a voice in, data out model. More specifically, callers would dial 411 or 1+411 and verbally request information, and the information would be provided verbally by the operator or announcement and/or the information would be provided as data to the end user using SMS, WAP, e-mail, or fax.

Another possible evolution is to allow end users to request the information using different modes, such as via the Internet or e-mail, via voice mail, or by fax requests. For example, end users could look for information or order a service on a LEC’s corporate web site or a LEC’s yellow pages web site. A possible future evolution is to have LEC operators assist end users with their web browsing experiences. In addition, end users could request information by sending an e-mail message, voice mail message, or fax to the LEC. If this occurs, the LEC operators would need to process these incoming messages in addition to the telephone calls.

3–7


SR-NOTES-SERIES-18

The response from the operators to the customers could be via the same mode the request came in on or via a different mode (e.g., the end user may request information through the web and receive a response through e-mail).

3.2 Generic NGN Operator Services Architecture

Ideally, to support the desired technology advancements discussed in Section 3.1 of this document, the current Operator Services infrastructure should migrate to a full NGN architecture based on IP and/or ATM protocols.

SR-5093, Voice Over Packet (VOP): Operator Services in a Next Generation Network (NGN), defines a new generic NGN architecture that supports the existing Operator Services and the desired Operator Services capability extensions described in Section 3.1. SR-5093 extends the NGN/VOP architecture originally defined in SR-4717, Voice Over Packet in Next Generation

Networks - An Architectural Framework and SR-5074, Integrating Voice and Data Services

in Next Generation Networks - An Architectural Framework. The NGN Operator Services architecture, defined in SR-5093, is described below in this section.

Figure 3-1 illustrates a high-level view of the NGN Operator Services architecture.

Figure 3-1 NGN/VOP Architecture - High-Level View

To provide Operator Services in an NGN/VOP architecture, Servers, Agents, Call Mediation Nodes, Gateways, Bearer Termination Nodes (BTNs), Management Systems, Databases, and workstations are required. All of these entities are anticipated to communicate with each other via the core network. The core network may use ATM or IP as the transport protocol.

The NGN Operator Services architecture is based on a model used with Bearer Independent Call Control (BICC). BICC is a new protocol planned to be used for establishment of calls, including Operator Services calls, over an Asynchronous Transfer Mode (ATM) or Internet

Core Network

Gateways

Databases

Servers

Call Mediation

Nodes

Agents

PSTN

Internet

BearerTermination

Nodes

ManagementSystems

Workstation

3–8


SR-NOTES-SERIES-18

Protocol (IP) backbone network. BICC is closely based on SS7 ISUP and is capable of carrying the SS7 ISUP service-specific parameters, such as Operator Services-specific parameters.

Servers are entities that perform service processing and may contain resources needed for Operator Services, such as announcements, DTMF digit collection, and speech recognition. A server may or may not have the capability to terminate bearer connections.

Agents include Call Connection Agents (CCAs), Services Agents, and Billing Agents. As described in Section 2 of SR-5093, CCAs are anticipated to control bearer connections by interacting with bearer entities (i.e., entities that terminate bearer connections) and perform basic call processing. Services Agents are expected to interact with CCAs to define the service-specific processing that results in bearer connections. Billing Agents are defined to process usage records from CCAs and send the information to billing systems in the appropriate format (e.g., Billing AMA Format [BAF]).

Call Mediation Nodes (CMNs) are defined as standard BICC nodes that are in the call-associated signaling path but do not terminate bearer connections. A CMN may interact with Services Agents to modify call processing. Specifically, CMNs are defined to exchange BICC signaling with CCAs and possibly other CMNs. CMNs are anticipated to be needed to provide queuing and call distribution functions for Operator Services, but are not yet defined in SR-5074.

Gateways interconnect systems within the NGN/VOP network to systems outside the NGN/VOP network. Examples of gateways include:

• Access Gateways that terminate Plain Old Telephone Service (POTS) lines and ISDN interfaces and

• Trunk Gateways that terminate Time Division Multiplexing (TDM) trunks.

Bearer Termination Nodes (BTNs) are defined as generic nodes that have been introduced in SR-5093 for Operator Services. A BTN is expected to terminate bearer connections under the control of a single CCA. BTNs are anticipated to be needed whenever an intermediate CCA needs to control bearer connections, such as when transferring the bearer connection from one entity (e.g., announcements) to another (e.g., an operator).

Management systems, such as element management systems (EMSs) and Force Management Systems, are defined to have direct packet connectivity through the core network to exchange management information with the NGN/VOP entities.

Depending on the transport layer protocol supported, a database such as LIDB or LSDB may directly connect to the core network. Alternatively, these databases may interconnect with the NGN/VOP entities via gateways.

Depending on the transport layer protocol supported, workstations may directly connect to the core network or may interconnect with NGN/VOP systems via gateways. The NGN Operator Services architecture defined in SR-5093 assumes that the operator workstations are directly connected to the core network.

In general, the existing Operator Services are anticipated to be defined in and controlled by a Services Agent, referred to as the Operator Services (OS) Services Agent (SA). One exception is the queuing and call distribution functions.

3–9


SR-NOTES-SERIES-18

The queuing and call distribution functions should be able to distribute incoming calls among operators served by different CCAs. To meet this objective, SR-5093 proposes to place the queuing and call distribution functions in a CMN, referred to as Queuing and Call Distribution (QCD-CMN). The queuing and call distribution functions are placed in a CMN, rather than a server, because the CMN will process the BICC call-associated signaling, enabling the QCD-CMN to be aware of the status of the operator workstations, avoiding the need to define a new, or upgrade an existing, non-call associated signaling application protocol between the CCA and queuing and call distribution server. Other design alternatives that place the queuing and call distribution functions in a server, rather than a CMN, may meet LECs’ queuing and call distribution objectives in an acceptable manner.

New Operator Services capabilities that are not necessarily extensions of existing Operator Services are expected to be controlled by service-specific servers. For example, live web-site assistance and messaging (e-mail, voice mail, facsimile) capabilities are defined in service-specific servers, while querying new EDA databases is defined in SR-5093 as part of the OS SA.

Figure 3-2 illustrates a preliminary view of the NGN/VOP architecture, including the additional components needed in the NGN/VOP architecture to support Operator Services. The non-shaded entities are defined in SR-4717 for NGN/VOP architectures. Figure 3-2 expands on the high-level architecture provided in Figure 3-1 by defining specific Agents, Servers, and additional entities proposed for Operator Services. The shaded entities are the entities added in SR-5093 for Operator Services. Figure 3-2 shows a functional architecture rather than a physical architecture. SR-5093 allows for the functions described below to be in separate systems and describes information flows and protocol alternatives for the interfaces between the functions when they are in separate systems. Generic interfaces between the functional entities described in SR-5093 facilitate an open and flexible multi-supplier environment. However, a LEC can choose to combine any of the functions together, alleviating the need for a generic interface between the functions.

3–10


SR-NOTES-SERIES-18

Figure 3-2 Operator Services in an NGN/VOP Architecture

It is worth noting that SR-5093 defines the functional entities under the assumption that a given functional entity is entirely within one node. That is, there is no need to define standard interfaces among elements of the functional entity. However, Figure 3-2 is just a model and is used to simplify discussion of the required interfaces. In fact, the activity of a functional entity could be distributed over several physical nodes, as long as there is one node where all the interfaces to the functional entity shown in Figure 3-2 reside. As a result, it is possible to correlate the functional entities of Figure 3-2 with the physical entities of a system of systems providing Operator Services, even when the creator of the system of systems does not describe it in these terms and when the interfaces between systems may differ from those shown in Figure 3-2.

3.2.1 Functional Entities

This section describes the functional entities used for Operator Services as illustrated in Figure 3-2.

• Operator Services (OS) Services Agent (SA). The OS SA is expected to support the existing OSS switch capabilities, except the queuing and call distribution capability. The CCA/OS SA is anticipated to interact with a separate Queuing and Call Distribution-Call Mediation Node (QCD-CMN) to provide skills-based routing for all operators.

Different Operator Services functions may reside in different OS SAs. For example, one CCA/OS SA could perform Directory Assistance services and another CCA/OS SA could

BillingAgent

TrunkGateway

SignalingGateway

EMS

AccessGateway

CorePacket

Network

NGN PBXGateway

ResidentialGateway

PBX LAN

CCA

RTSSA

CCA

RTSOSSA

BTNNMG

QCDCMN

WCSAgent

MessageHandler

VFS

PacketGateway

Internet

AMS FMS

OSDBGateways

Operator ServicesDatabases


OperatorWorkstations

PSTN

BillingAgent

TrunkGateway

SignalingGateway

EMS

AccessGateway

CorePacket

Network

NGN PBXGateway

ResidentialGateway

PBX LAN

CCA

RTSSA

CCA

RTSSA

CCA

RTSOSSA

CCA

RTSOSSA

BTNNMG

QCDCMN

WCSAgent

MessageHandler

VFS

PacketGateway

Internet

AMS FMS

OSDBGateways



OperatorWorkstations

PSTN

3–11


SR-NOTES-SERIES-18

perform 0-/assist and calling card services. As another example, one CCA/OS SA could perform fully automated Operator Services and another CCA/OS SA could serve operator workstations as well as perform fully automated Operator Services.

When a calling party is connected to an operator, the CCA/OS SA performing a particular operator service sends relevant call-related data to the operator workstations via the core network. For efficiency purposes, SR-5093 models Operator Services such that the CCA/OS SA performing the operator service sends the call-related data through the core network to the operator workstation, even when the CCA/OS SA performing the operator service does not serve that particular operator workstation.

An alternative model is for the CCA/OS SA performing the operator service to send the call-related data to the CCA/OS SA serving the operator workstation. This second alternative adds some complexity by requiring interaction between the two CCA/OS SAs in the message flow, but allows calls to be distributed among operators served by different CCAs.

Another defined function of the OS SA is to make requests to and exchange information with a network entity that includes Operator Services resources, referred to as a Voice Feature Server (VFS). When a calling party is connected to a VFS, the OS SA is expected to make requests to the VFS, e.g., to play specific announcements. Further study is needed to determine this application protocol; possibilities include Hypertext Transfer Protocol (HTTP) or TCAP.

• Call Connection Agent (CCA). The CCA is expected to perform basic call processing functions and the following Operator Services-specific functions:

— Interact with one OS SA to perform a given operator service.

— Process MF signaling received from the Trunk Gateway and send MF signaling to Trunk Gateways that terminate MF trunk groups to existing OSS switches or end offices (e.g., for coin calls).

— Initially exchange messages with H.323-capable operator workstations to set up calls to the operator workstations. In the future, it may exchange SIP and H.248 messages with operator workstations.

— Exchange BICC messages with other CCAs, including the Operator Services-specific ISUP information defined in GR-1277-CORE and GR-1144-CORE, and the Release to Pivot information defined in GR-3015-CORE and GR-3016-CORE.

— For incoming calls from the PSTN and outgoing calls to the PSTN, interact with the Trunk Gateway and Signaling Gateway that are served by the CCA. Each Trunk Gateway is served by one and only one CCA.

• Trunk Gateway. The trunk gateway is expected to perform the functions described in Section 2 of SR-5093. The trunk gateway is expected to support both SS7 and MF interfaces. The trunk gateway is expected to support Operator Services signaling for the MF interfaces, including coin signals.

• Bearer Termination Node (BTN). The Bearer Termination Node is expected to:

— Interpret H.248 messages received from the CCA and establish bearer paths in accordance with the messages. The BTN is expected to enable the CCA/OS SA to

3–12


SR-NOTES-SERIES-18

control the bearer connection to the calling party without involving other CCAs. For example, a CCA/OS SA may request the BTN to redirect the calling party from an announcement to an operator and may request the BTN to transfer the calling party from an operator to a supervisor. The supervisor could monitor the operator’s conversation by bridging onto the conversation at the BTN.

— Upon request from the CCA, detect DTMF digits (including # and *) in the user information stream.

— Perform echo cancellation, silence detection, comfort noise insertion, and plays tones and announcements in accordance with default service provisioning criteria and instructions received from the CCA. The echo cancellation, silence detection, and comfort noise insertion are performed when the BTN provides announcements.

— Bridge multiple voice calls, e.g., to enable supervisors to monitor operator calls.

— Include the same type of Operator Services resources, such as announcements, as are found in existing OSSs. The Operator Services resources within VFSs are expected to be more flexible than those that the BTN provides.

The BTN is defined to exchange messages with only one CCA.

• Queuing and Call Distribution - Call Mediation Node (QCD-CMN). For Operator Services, a key function is queuing and call distribution, including skills-based routing. The QCD-CMN, or QCD for short, is defined to provide this function by interacting with one or more CCAs/SAs. As a CMN, the QCD is not defined to directly control any bearer resources; its call control functions are expected to:

— Track the availability of resources (operator workstations and VFSs in particular).

— Track calls currently connected to those resources.

— Route call control messages for incoming calls to the available resources.

For example, all operators and supervisors are assumed to log on to the QCD. As a result, the QCD knows which operators are working, and the association of the operator identifiers to operator workstations.

Section 4 of SR-5093 provides further detail on the call flows involving operators and QCDs.

An external system may request the CCA/OS SA to set up a call between the calling party and operator workstation. For example, a new server, referred to as the Web Collaboration Server (WCS), is expected to request call setup between the calling party and operator when the calling party requests live assistance while web browsing. To maintain the operator availability status, the QCD is expected to process the call setup messages exchanged between the WCS and CCA/OS SA.

Since asynchronous communications (i.e., e-mail, voice mail, and facsimile) do not use a separate call-associated signaling protocol for communication establishment, the CCA/OS SA is expected to exchange non-call-associated application protocol messages with the QCD to request the QCD to find an available operator with the appropriate skill set (rather than having the QCD in the bearer path).

3–13


SR-NOTES-SERIES-18

Because the operators log on directly to the QCD, the QCD is expected to store the following information, as examples:

— Association of Operators and Operator Workstations

— Operator Workstation Availability

— Association of Operators and Teams

— Call-related criteria, such as call type derived from dialed digits and language, priority customers, type of function (e.g., web assistance, voice calls, and e-mail), mapped to Queuing Category

— Teams associated with Queuing Categories.

By having the queuing and call distribution functions in a QCD, which is an external server, the queuing and call distribution can be provided for thousands of operators geographically dispersed throughout the network. The operators may be served by different CCAs.

The architecture defined in SR-5093 supports the capability for a supervisor to monitor operators served by any CCA in the NGN/VOP network. The supervisor’s workstation is expected to inform the QCD of the desire to monitor. The QCD is expected to inform the OS SA providing a particular operator service of the request for the supervisor to monitor the call. Section 4.14.1 of SR-5093 describes the call flows for supervisor monitoring of an operator’s calls.

The QCD is also expected to record statistical data, such as average work time for voice calls, and reports this data to the Force Management System via the core network and possibly a gateway.

• Web Collaboration Server (WCS). The WCS is a service-specific server that is expected to enable operators and agents to provide live assistance to end users while they are browsing the web. More specifically, the WCS enables an end user and operator to engage in a text chat session and to view the same web pages.

To initiate this capability, the end user would first request live assistance by clicking an icon from a web site. This web server is expected to inform the WCS of this request using a proprietary application protocol. If the request is for a VOP call, the WCS is expected to request that the QCD find an available operator with the appropriate skill set and set up the call (through the CCA/OS SA that serves the selected operator). The QCD is expected to include the IP address of the operator workstation in the BICC message to enable the CCA/OS SA to send relevant call data to the operator workstation.

If the request is for a text chat, the WCS is expected to mediate the text chat session. For VOP calls and text chat sessions, the WCS is expected to provide the web collaboration between the end user and operator.

• Agent Message Handler. The Agent Message Handler is a service-specific server that is expected to receive e-mail and voice mail messages and faxes and provide them to the operator using the same QCD used for telephone calls and web assistance. The operator may also send messages via the Agent Message Handler. The Agent Message Handler may interact with a Unified Messaging Server (UMS) to obtain the messages or may be a UMS.

3–14


SR-NOTES-SERIES-18

When the Agent Message Handler receives a message (e.g., an e-mail message from a web server), the Agent Message Handler is expected to inform the QCD. At the appropriate time, the QCD is expected to inform the CCA/OS SA involved with the messaging service that the operator should process the message (e.g., e-mail). The CCA/OS SA then is expected to interact with the operator workstation and Agent Message Handler to request the operator to process the messages (e.g., e-mail, voice mail, or facsimile messages).

• Automated Monitoring System (AMS). The AMS is a system that is expected to provide real-time monitoring of operators’ conversations and operator workstation screens. Further study is needed to determine how often the operator screen should be captured. Efficient encoding schemes could be utilized to deliver the information when minimal changes are made to the screen. The AMS captures the screens from the operator workstation via the core network and possibly a gateway. Further study is needed to determine the most appropriate way to bridge onto the operator conversation to record the voice. Possibilities include bridging onto a conversation at the BTN or at each operator workstation.

• Force Management System (FMS). Based on GR-1163-CORE, OSSGR Section 25: Report

Subsystem, the FMS is expected to generate reports to enable operator service provider personnel to:

— Analyze the quality of service provided

— Monitor and plan control of the traffic volume to be handled

— Determine staffing needs

— Determine effectiveness of current serving team assignments.

Examples of data that is expected to be provided in reports include: the average number of seconds that customers wait before reaching an operator, Average Work Time (AWT), and the amount of time that occupied operator positions are busy processing calls.

The QCD is expected to provide the appropriate data to the FMS either directly or via a gateway.

• Voice Feature Server (VFS). Sophisticated resources are critical components of Operator Services. New announcements as well as more automation using advanced speech recognition and text-to-speech are continuously needed for Operator Services. For this reason, it is desirable to use VFSs rather than BTNs to provide the necessary flexibility and programmability for the Operator Services resources, including announcements, speech recording, speech recognition, speech compression, silence deletion, text-to-speech capabilities, and DTMF digit collection. The Voice Feature Server may provide speech compression and silence deletion to shorten the time it takes to playback the recorded voice. Speech compression algorithms may compress sounds that have redundancies (e.g., “aaaah” to “ah”). The CCA/OS SA is expected to send application protocol messages to the VFSs to make requests, e.g., to play specific announcements. While playing announcements or providing text-to-speech conversion, the VFS is expected to perform echo cancellation, silence detection, and comfort noise insertion.

• Billing Agent (BA). The BA is expected to collect usage data (i.e., automatic messaging accounting [AMA] information) from the CCA, process the data, and translate the data into

3–15


SR-NOTES-SERIES-18

Billing AMA Format (BAF) for downstream billing systems. One or more CCAs, including direct dialed and Operator Services CCAs, may send raw usage data to the same BA. The BA is expected to be capable of formatting any BAF structures, modules, and tables, including Operator Services-specific structures, modules, and tables.

• Element Management System (EMS). An EMS is expected to serve as a single point of reference between all of the Functional Elements (FEs) within a specific NGN/VOP operations domain (e.g., FEs from a particular supplier may be managed by an EMS from the same supplier) and the NGN/VOP Network Management System (NMS). An Operator Services CCA/SA and direct dialed CCA/SA from the same supplier may share the same EMS for a given NGN/VOP operations domain, such as configuration management.

• Packet Gateway. The Packet Gateway is expected to terminate logical connections from the Internet and the NGN.

• Operator Services Database (OSDB) Gateway. The OSDB Gateway is expected to enable NGN systems to exchange messages with Operator Services databases that do not directly connect to the core network.

• Operator Services Databases. The Operator Services databases include the existing databases, such as Operator Reference Database (ORDB), External Real-Time System (ERTS), Listing Services Database (LSDB), Enhanced Directory Assistance (EDA) databases, and Line Information Database (LIDB). Although not shown in Figure 3-2, the interactions with LIDB may be via a Signaling Gateway or a Packet Gateway. All of the Operator Services databases, including LIDB, may or may not directly connect to the core network.

• Operator Workstations. The operator workstations support the interfaces to the CCA/OS SAs and additional systems, such as the WCS. The operator workstations are expected to process information and place it in a user-friendly manner on the screen. The operator workstations are defined to directly connect to the core network and are assumed to initially support H.323. After the initial support of H.323, the operator workstations may support SIP and possibly H.248.

3–16


SR-NOTES-SERIES-18

3.3 Migration of Existing OSS Technology

Further study is needed to determine the best way to migrate the existing OSS infrastructure toward the generic NGN Operator Services architecture. The migration path depends on the service providers’ priorities of the Operator Services technology advancements discussed in Section 3.1. This section discusses several possible migration paths for the Operator Services technology.

For LECs that currently use DMS TOPS, one possibility is to begin the advancements through an open interface from DMS TOPS to a new service node that incorporates a service creation environment, languages such as C++, Java, ActiveX, and VXML, modular architecture, state-of-the-art speech recognition engines and text-to-speech capabilities, and the best-in-class DA and EDA automation capabilities and applications. Through integration with this existing OSS infrastructure, faster creation of new desired services can be achieved.

Along with the service node integration, it is important to also migrate the operator workstation forward to achieve full service creation flexibility at the workstation as well, so the operators can efficiently access the advanced information from new databases and additional context information from the new service node.

Among the services that could be supported with new flexible, modular service nodes and operator workstations integrated with the existing OSS infrastructure is multi-mode delivery of information.

EDA services, including business category searches and searches based on wireless calling party’s location, can be supported with this architecture as long as the necessary database extensions are also supported.

Further migration is needed to support the desired flexible call distribution capabilities and supervisor capabilities where the operators and supervisors can be located anywhere independent of their geographic location (e.g., with the use of IP interconnection). In addition, technology migration is needed for multimedia services, such as live assistance with web browsing and the processing of e-mail, fax, and voice mail.

Many alternative migration paths are possible for realizing the desired technology advancements, while maintaining the existing Operator Services. One possibility for the full support of the desired advancements, including the IP interconnection and multimedia services, is a revolutionary change to IP contact center technology. A key advantage associated with the use of IP contact center technology is that the LECs could use the same technology for operator centers and other centers, such as business offices and repair centers. The IP contact center technology could be customized to support the specific needs of Operator Services. In general, this technology supports the IP connectivity, multimedia capabilities, and flexible service creation capabilities desired for Operator Services as well as for all contact centers. However, work is needed to support the Operator Services-specific SS7 interface procedures and protocol and to create all the existing Operator Services that the current OSS infrastructure already supports.

For LECs that currently use DMS TOPS, another way of realizing the desired technology advancements is to migrate the current DMS TOPS switch to the Nortel Networks Succession architecture, retaining DMS TOPS interfaces to new flexible, modular service nodes with user-

3–17


SR-NOTES-SERIES-18

friendly service creation environments, and retaining DMS TOPS interfaces to new IP-capable workstations with user-friendly service creation environments and modular designs. The advantage of this alternative is that the existing operator service logic and Operator Services-specific SS7 interface procedures and protocols can be retained, rather than recreated on new technology. Another advantage is that the underlying bearer entities and basic call processing entities can be shared with network services.

A third possibility is to develop Operator Services logic on servers that are integrated with new softswitches or programmable switches (which may eventually migrate to new softswitches). The servers may be associated with IP contact center technology. This alternative is especially beneficial when the softswitch or programmable switch is used for network services in addition to Operator Services. In addition, if the new switch supports Operator Services through integration with IP contact centers, the LECs can gain advantages by sharing the softswitch with other network services and sharing the IP contact center technology with other contact centers.

Other migration paths not discussed in this section are also possible.

The specific migration path taken by each LEC depends on the individual priorities associated with the desired technology advancements.

3–18

Issue 1, May 2002 Telcordia Notes on Operator ServicesSummary

SR-NOTES-SERIES-18

4 Summary

This SR provides an overview of the United States Local Exchange Carriers (LECs) current Operator Services offerings. Its contents are useful to organizations responsible for providing Operator Services to end users and other companies, and for providing equipment to Operator Services providers. It documents the services provided and the technology used to offer those services. LEC Operator Services include a broad range of fully and partially automated, and manual, assistance and information services, accessed by dialing 411 and 555-1212 (directory assistance), 0- (general assistance), 0+ (alternate billing, handling), and 1+ (coin and intercept). The technology description includes the architectural components that make up the access tandem Operator Services System (OSS), the signaling used to communicate with it, and the data generated for downstream billing and for force management.

This document also describes the potential evolutionary paths that the Operator Services industry may take, including service enhancements and the use of new technology. It includes a description of technology advancements desired for Operator Services, such as the support of more automation and a migration to the Internet Protocol (IP). In addition, a Next Generation Network (NGN) Operator Services architecture to handle existing services and new multimedia services is discussed, as well as how today’s existing OSS infrastructure could evolve to that architecture.

In the early days of telephony, prior to automatic switching and direct dialing, operators were integral to connecting calling parties to their desired destinations. The Operator Services industry has evolved to assisting customers with making their connections when they do not know the telephone number to be dialed, when they want assistance from a live operator, when they want to bill the call to a number other than the calling line number, and when special capabilities are needed, including real-time rating of the call and complex Intercept treatment. Operator Services originated as a function that completed every call and has evolved to the place in the network that provides information, assistance, and complex functions that cannot cost-effectively be distributed in every end office. The evolution of Operator Services has focused on making operator centers run more efficiently by incorporating automation into the provision of services and by centralizing operators. This is expected to continue with automation of additional DA calls and geographic independence for operators with the use of the IP, without sacrificing the quality of the end user experience.

The Operator Services industry is evolving as are emerging information services industries, such as voice portals, on-line yellow pages, and telematics. The challenge to all of these types of industries is how to provide information to end users in a manner that is both user-friendly and profitable. The evolution and convergence of these industries may result in more competition, partnerships, and technology innovation as a result of the opportunity for suppliers within each industry to eventually support them all.

Operator Services was once viewed as a cost center, with the focus on minimizing costs. Though that is always a goal, it is now understood that it has the growing potential to be a revenue producer when meeting the varied needs of a diverse customer base. Many customers continue to prefer to do things themselves, with an automated interface to the OSSs; however, service providers also recognize that there is a significant, perhaps growing, set of customers who would welcome more personalized, operator-provided service to help them with traditional telephony as well as newer-technology services, and be willing to pay for it. In both

4–1

Telcordia Notes on Operator Services Issue 1, May 2002Summary

SR-NOTES-SERIES-18

cases, people today welcome services that can simplify their lives, such as new EDA services enabling callers to indicate a type of business and the operator or automated system making connections between callers and businesses without the caller having to bother to learn the telephone number. As Operator Services continues its never-ending evolution, and service providers consider future services as revenue sources, the changing needs of all types of customers must always be addressed.

4–2

Issue 1, May 2002 Telcordia Notes on Operator Services Bibliography and References

SR-NOTES-SERIES-18

Appendix A: Bibliography and References

A.1 Telcordia Documents

• FR-271, Operator Services Systems Generic Requirements (OSSGR).

• GR-317-CORE, LSSGR: Switching System Generic Requirements for Call

Control Using the Integrated Services Digital Network User Part (ISDNUP) (A

Module of LSSGR, FR-64).

• GR-394-CORE, LSSGR: Switching System Generic Requirements for

Interexchange Carrier Interconnection (ICI) Using the Integrated Services

Digital Network User Part (ISDNUP) (A Module of LSSGR, FR-64).

• GR-505-CORE, LSSGR: Call Processing (A Module of LSSGR, FR-64).

• GR-506-CORE, LSSGR: Signaling for Analog Interfaces (A Module of LSSGR,

FR-64).

• GR-528-CORE, LSSGR: Public Telecommunications Service, FSD 10-01-0000

(A Module of LSSGR, FR-64).

• GR-531-CORE, LSSGR: Interoffice, FSDs 25-05-0903, 25-06-0501, 25-06-

0502, 25-06-0506 (A Module of LSSGR, FR-64).

• GR-532-CORE, LSSGR: Call Processing Features, FSDs 30-16-0000 Through

30-23-0000 (A Module of LSSGR, FR-64).

• GR-674-CORE, LSSGR: Special Information Tones (FSD 20-06-0500) (A

Module of LSSGR, FR-64).

• GR-690-CORE, Exchange Access Interconnection FSD 20-24-0000 (A Module

of LSSGR, FR-64).

• GR-692-CORE, LSSGR: Exchange Access Operator Services System

Signaling, FSD 20-24-0030 (A Module of LSSGR, FR-64).

• GR-1100-CORE, Billing Automatic Message Accounting Format (BAF)

Generic Requirements.

• GR-1143-CORE, OSSGR Sections 2-5: Overview of Network Plan, Features,

and Call Processing (A Module of OSSGR, FR-271, and FD-LECKIT-CD-01).

• GR-1144-CORE, OSSGR Section 6: Signaling (A Module of OSSGR, FR-271,

and FD-LECKIT-CD-01).

• GR-1147-CORE, OSSGR Section 8: Administration (A Module of OSSGR, FR-

271, and FD-LECKIT-CD-01).

• GR-1149-CORE, OSSGR Section 10: System Interfaces (A Module of OSSGR,

FR-271, and FD-LECKIT-CD-01).

• GR-1158-CORE, OSSGR Section 22.3: Line Information Database (A Module

of OSSGR, FR-271, and FD-LECKIT-CD-01).

A–1

Telcordia Notes on Operator Services Issue 1, May 2002Bibliography and References

SR-NOTES-SERIES-18

• GR-1163-CORE, OSSGR Section 25: Report Subsystem (A Module of OSSGR,

FR-271, and FD-LECKIT-CD-01).

• GR-1173-CORE, OSSGR FSD 65-01-0100: Common Functions (A Module of

OSSGR, FR-271, and FD-LECKIT-CD-01).

• GR-1174-CORE, OSSGR Customer Access Features (FSD 70 Series) (A

Module of OSSGR, FR-271, and FD-LECKIT-CD-01).

• GR-1175-CORE, OSSGR Customer Listing Information (FSD 75 Series) (A


• GR-1176-CORE, OSSGR Customer Call-Handling Features (FSD 80 Series)

(A Module of OSSGR, FR-271, and FD-LECKIT-CD-01).

• GR-1177-CORE, OSSGR Special Billing Features (FSD 85 Series) (A Module

of OSSGR, FR-271, and FD-LECKIT-CD-01).

• GR-1277-CORE, Operator Services: Switching system Generic Requirements

Using Integrated Services Digital Network User Part (ISUP).

• GR-2867-CORE, Generic Functional Requirements for a Speech Processing

Peripheral (SPP) to Support Directory Assistance Automation (DAA) (A


• GR-2936-CORE, Local Number Portability (LNP) Capability Specification:

Service Provider Portability.

• GR-3015-CORE, RTPFR: Generic Requirements for the Signaling System 7

(SS7) Release to Pivot (RTP) Phase II Network Capability (A Module of

RTPFR, FR-RTP-1).

• GR-3016-CORE, RTPFR: Operator Services Generic Requirements for the Use

of Signaling System 7 (SS7) Release to Pivot (RTP) Phase II Network

Capability (A Module of RTPFR, FR-RTP-1).

• SR-2275, Telcordia Notes on the Networks.

• SR-4717, Voice Over Packet in Next Generation Networks: An Architectural

Framework.

• SR-5074, Integrating Voice and Data Services in Next Generation Networks -

An Architectural Framework.

• SR-5093, VOP: Operator Services in an NGN.

A–2

Issue 1, May 2002 Telcordia Notes on Operator Services Bibliography and References

SR-NOTES-SERIES-18

Note

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 or to Order Documents

Telcordia Customer Service8 Corporate Place, Room 3A-184Piscataway, NJ 08854-41561.800.521.2673 (USA and Canada)+ 1.732.699.5800 (worldwide)+ 1.732.336.2559 (FAX)http://telecom-info.telcordia.com

At the Information SuperStore website http://telecom-info.telcordia.com, the Search and Browse selections (top left) provide access to the Telcordia catalog of technical information. When searching, you may enter a document number (e.g., GR-454) in the Keyword box to retrieve the abstract and ordering information for any available document.

To Order Documents From Within Telcordia (Employees Only)

1. Access the Telcordia Internal Home Page (InSite)

2. Click on Services on the blue horizontal bar

3. Click on AXESSSM Point Service

4. Click on Basic Search to obtain the Basic Search Criteria box

5. In the Search by Document Number field, enter the document number (e.g., GR-454), then scroll down to click on Submit Search

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

The Telcordia DIGEST of Technical Information (A Monthly Publication)

To view the latest documents published by Telcordia visit the Digest website at:http://www.telcordia.com/resources/genericreq/digest (Then, click on “Latest Documents” on the left.)

A–3

http://telecom-info.telcordia.com

Telcordia Notes on Operator Services Issue 1, May 2002Bibliography and References

SR-NOTES-SERIES-18

A.2 ANSI Documents, etc.

These publications are available from:

American National Standards Institute, Inc.11 West 42nd StreetNew York, NY 10036

http://web.ansi.org/public/std_info.html

• Technical Requirement No. 1, Number Portability Operator Services

Switching Systems.

• TIA/EIA-95-B, TR45 Wireless Telecommunication Ai-Di Interfaces Standard.

• T1.661-2000, SS7-Release to Pivot (RTP).

• T1.666-1999, SS7-Operator Services Network Capabilities.

A–4

Issue 1, May 2002 Telcordia Notes on Operator Services Acronyms

SR-NOTES-SERIES-18

Appendix B: Acronyms

AABS — Automated Alternate Billing Services

ABL — Area Business Listing

ABS — Alternate Billing Services

AC — Alternating Current

ACM — Address Complete Message

ADAS — Automated Directory Assistance Service

AI — Automatic Identification

AIN — Advanced Intelligent Network

AMA — Automatic Message Accounting

AMS — Automated Monitoring System

ANI — Automatic Number Identification

ANI II — ANI Information Digits

ANM — Answer Message

AO — Account Owner

AT — Access Tandem

ATM — Asynchronous Transfer Mode

AWT — Average Work Time

BA — Billing Agent

BAF — Billing Automatic Message Accounting Format

BICC — Bearer Independent Call Control

BLV — Busy Line Verification

BLV/I — Busy Line Verification/Interrupt

BNS — Billed Number Screening

BSP — Billing Service Provider

BTN — Bearer Termination Node

CAC — Carrier Access Code

CC — Calling Card

CCA — Call Connection Agent

CCS — Common Channel Signaling

CIC — Carrier Identification Code

CLEC — Competitive Local Exchange Carrier

B–1

Telcordia Notes on Operator Services Issue 1, May 2002Acronyms

SR-NOTES-SERIES-18

CMN — Call Mediation Node

CNA — Customer Name and Address

CP — Capability Parameter

CPE — Customer Premise Equipment

CPN — Calling Party Number

DC — Direct Current

D1 — Directory One

DA — Directory Assistance

DACC — Directory Assistance Call Completion

DAS — Directory Assistance System

DN — Directory Number

DTMF — Dual Tone Multifrequency

EAOSS — Exchange Access Operator Services Signaling

EDA — Enhanced Directory Assistance

EIS — Expanded Inband Signaling

EMS — Element Management System

EO — End Office

ERTS — External Real-Time System

FAC — Facility Message

FCC — Federal Communications Commission

FE — Functional Element

FGC — Fifth Generation Computer Corporation

FMS — Force Management System

FRL — Frequently Requested Listings

FSD — Feature Specification Document

GTT — Global Title Translation

HLR — Home Location Register

HTML — Hypertext Markup Language

HTTP — Hypertext Transfer Protocol

IAM — Initial Address Message

IC — Interexchange Carrier

IDDD — International Direct Distance Dialing

B–2


SR-NOTES-SERIES-18

IF — Identification Failure

ILEC — Incumbent Local Exchange Carrier

IN — Intelligent Network

INC — International Carrier

INDB — Intercept Database

IP — Internet Protocol, Intelligent Peripheral

ISDN — Integrated Services Digital Network

ISUP — Integrated Services Digital Network User Part

ISx — Information Services eXtended, Inc.

ITU — International Telecommunication Union Telecommunication Standardization Sector (formerly the CCITT)

IVR — Integrated Voice Response

IWS — Intelligent Workstation

JIP — Jurisdiction Information Parameter

LEC — Local Exchange Carrier

LIDB — Line Information Database

LNP — Local Number Portability

LRN — Location Routing Number

LSDB — Listing Services Database

LSIP — Listing Services Inquiry Program

LSPP — Local Service Provider Portability

MF — Multifrequency

MSC — Mobile Switching Center

MTP — Message Transfer Part

NDA — National Directory Assistance

NGN — Next Generation Network

NMS — Network Management System

NPA — Numbering Plan Area

NTS — Name and Telephone Number Provision Service

ODBC — Open Database Connectivity

OI — Operator Identified

OLIP — Originating Line Information Parameter

B–3


SR-NOTES-SERIES-18

OLNS — Originating Line Number Screening

ORDB — Operator Reference Database

OS — Operator Services

OSC/I — Operator Services Connection for Intercept

OSDB — Operator Services Database

OSNC — Operator Services Network Capability

OSPS — Operator Services Position System

OSS — Operator Services System

OSSAIN — Operator Services System Advanced Intelligent Network

OSSGR — Operator Services Systems Generic Requirements

PC — Peg Count, Personal Computer

PDA — Personal Digital Assistant

PIC — Primary Interexchange Carrier

PIN — Personal Identification Number

PORC — Portability Outside the Rate Center

POTS — Plain Old Telephone Service

PSAP — Public Safety Answering Position

PSTN — Public Switched Telephone Network

QCD-CMN — Queuing and Call Distribution-Call Mediation Node

QO — Query Originator

RAO — Revenue Accounting Office

RBOC — Regional Bell Operating Company

REL+RI — Release with Redirection Information message

RLT — Release Link Trunking

RTP — Release-to-Pivot

RTRS — Real Time Rating System

SA — Services Agent

SAP — Service Activation Parameter

SCCP — Signaling Connection Control Part

SCP — Service Control Point

SGW — Signaling Gateway

SIP — Session Initiation Protocol

B–4


SR-NOTES-SERIES-18

SIT — Special Information Tone

SMS — Short Message Service

SR — Special Report, Speech Recognition

SS7 — Signaling System 7

SSP — Service Switching Point

STP — Signaling Transfer Point

TCAP — Transaction Capabilities Application Part

TDM — Time Division Multiplexing

TGW — Trunking Gateway

TOPS — Traffic Operator Position System

TTC — Terminating Toll Center Code

TTS — Text to Speech

UMS — Unified Messaging Server

UNI — User Network Interaction

VFS — Voice Feature Server

VOP — Voice over Packet

VPN — Virtual Private Network

VXML — Voice eXtensible Markup Language

WAP — Wireless Application Protocol

WCS — Web Collaboration Server

WIN — Wireless Intelligent Network

XML — eXtensible Markup Language

B–5


SR-NOTES-SERIES-18

B–6

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.

f) The foregoing license does not include the right to (i) make copies of the Licensed Product(s) for sale, or (ii) transfer to third parties other than Affiliates as provided above, or (iii) copy or incorporate any portions of the Licensed Product into Licensee Documentation, or (iv) create derivative works for sale.

g) It is understood that nothing in this Agreement grants or is intended to grant any license, express or implied, to any patents, or software.

h) Licensee shall immediately notify Ericsson (i) of any unauthorized attempt by a third party to access the Licensed Product, or (ii) if Licensee becomes aware of any unauthorized use or disclosure of any Licensed Product.

3. AUDITS

Upon reasonable written notice to Licensee, Ericsson shall have the right to review Licensee’s compliance with the terms and conditions of this Agreement. If such review reveals a violation of the requirements set forth herein, in addition to any other remedies it may have, Ericsson may terminate this Agreement in accordance with the Termination section of this Agreement.

4. FEES AND PAYMENTS

All fees and charges due hereunder shall be paid in full within thirty (30) days of the date of the invoice. All payments required hereunder shall be nonrefundable. Overdue payments are subject to a late payment charge, calculated and compounded monthly, and calculated at an annual rate of either (1) one percent (1%) over the prime rate available in New York City, as published in The Wall Street Journal on the first Monday (or the next bank business day) following the payment due date; or (2) 18 percent (18%), whichever shall be higher. If the amount of the late payment charge exceeds the maximum permitted by law, the charge will be reduced to that maximum amount.

Licensee shall pay or reimburse Ericsson for all sales or use taxes, duties, or levies imposed by any authority, government or government agency (other than those levied on the net income of Ericsson) in connection with this Agreement. If Ericsson is required to collect a tax to be paid by Licensee, Licensee shall pay this tax on demand. If Licensee fails to pay these taxes, duties or levies, Licensee shall pay all reasonable expenses incurred by Ericsson, including reasonable attorney’s fees, to collect such taxes, duties or levies.

Ericsson shall provide Licensee with one (1) copy of the Licensed Product. Upon request, an additional copy in electronic media will be provided to Licensee at a cost of $150.00. Additional copies will be limited to one copy at the latter fee. Please contact our Customer Service Center at [email protected], 1.844.251.0201 (USA and Canada), or 1.913.241.6682 (All others).

5. DISCLAIMER OF WARRANTIES

THE LICENSED PRODUCT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, EVEN IF ERICSSON HAS BEEN MADE AWARE OF SUCH PURPOSE, OR ANY WARRANTY AGAINST INFRINGEMENT OF PATENTS OR OTHER INTELLECTUAL PROPERTY RIGHTS. LICENSEE ASSUMES RESPONSIBILITY FOR THE SELECTION OF THE LICENSED PRODUCT TO ACHIEVE ITS INTENDED RESULTS, AND FOR THE USE AND RESULTS OBTAINED FROM THE LICENSED PRODUCT.

6. LIMITATION OF LIABILITY

IN NO EVENT WILL ERICSSON BE LIABLE TO LICENSEE FOR ANY DAMAGES, INCLUDING DIRECT DAMAGES, LOST PROFITS, OR OTHER INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, EVEN IF ERICSSON HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

7. THIRD PARTY PRODUCTS AND INFORMATION WARRANTY

Ericsson does not warrant third party products or information which Ericsson may use to prepare the Licensed Product. Third party products or information may be warranted by third parties as expressly provided in the documentation accompanying the third party product or information, if any. Licensee’s exclusive remedy under any third party warranty is as provided in the third party documentation accompanying the third party product or information, if any.

8. RETURN POLICY

Licensed Product(s) that have been delivered electronically (downloaded from the SuperStore or received via email) are not eligible for credits, refunds or returns, even if duplicative with Licensed Product(s) that are the subject of prior or contemporaneous orders. Licensee assumes all responsibility for managing its inventory of Licensed Product(s).

9. TERMINATION

If Licensee breaches one or more of its obligations under this Agreement, Ericsson may elect at any time, in addition to any other remedy, to terminate the license and rights granted. Prior to the termination, Ericsson must give Licensee two (2) months written notice specifying the breach. Ericsson may terminate the license and rights granted if Licensee does not remedy all breaches specified in the written notice within the two (2) month notice period. Upon termination of the license and rights granted, Licensee shall destroy or return all Licensed Product(s), including all copies, and certify in writing to Ericsson the destruction or return.

10. PUBLICITY

Notwithstanding anything herein to the contrary, each party is prohibited from using in advertising, publicity, promotion, marketing, or other similar activity, any name, trade name, trademark, or other designation including any abbreviation, contraction or simulation of the other without the prior, express, written permission of the other.

11. ASSIGNMENT

Neither this Agreement nor any license, rights or obligations hereunder shall be assignable or transferable (in insolvency proceedings, by mergers, by purchase, by operation of law or otherwise) by Licensee without the written consent of Ericsson. Any such purported assignment or transfer shall be void without such written consent.

12. GENERAL

Export/Re-export. Licensee acknowledges that any commodities and/or technical data provided under this Agreement may be subject to the Export Administration Regulations (http://www.ecfr.gov, Title 15-Commerce and Foreign Trade, Volume 2, Section VII, Subchapter C-Export Administration Regulations, collectively, “the EAR”) administered by the Bureau of Industry and Security of the U.S. Department of Commerce (http://www.bis.doc.gov) and that any export or re-export thereof must be in compliance with the EAR, either through license or appropriate license exception. Licensee agrees that it shall not export or re-export, directly or indirectly, either during the term of this Agreement or after its termination or expiration, any commodities and/or technical data (or direct products thereof) received from Ericsson under this Agreement in any form to destinations in Country Group E (as specified in Supplement No. 1 to Part 740 of the EAR, as modified from time to time by the U.S. Department of Commerce), or to destinations, entities or persons that are otherwise controlled or embargoed under U.S. law. Licensee acknowledges it is not a foreign national of Country Group E or a denied party on U.S. export regulations.

Foreign Tax Payment. For a Licensee which is not a United States corporation, Ericsson will not accept remittance of less than the full amount billed to Licensee as full payment unless:

a. Licensee withholds that amount to satisfy tax withholding requirements imposed by the country (other than the United States) in which Licensee resides or in which Licensee has accepted delivery of the Licensed Product; and

b. Licensee furnishes a receipt issued by the withholding tax jurisdiction and certifying deposit of the withheld amount into its treasury or other tax depository to Ericsson’s sole credit, or a certification on Licensee’s stationery that Licensee has deposited the withheld amount into its tax jurisdiction’s treasury or other tax depository to Ericsson's sole credit.

Further, to ensure the orderly processing of Ericsson tax returns, Licensee shall provide to Ericsson a summary of all amounts withheld during the year no later than ten business days after December 31 of each year addressed to: Ericsson Inc., 6300 Legacy Dr., Plano, Texas 75024, Attn: Tax Management Department.

Governing Law. This Agreement is a contract between Ericsson and the Licensee of the Licensed Product. This contract is to be interpreted in the federal and state courts of New Jersey, in accordance with the laws of the State of New Jersey without regard to its conflict of laws principles, and the parties consent to the jurisdiction of such courts for this purpose.

Entire Agreement. Licensee further agrees that this is the complete and exclusive statement of the Agreement between Licensee and Ericsson and supersedes any proposal or prior Agreement, oral or written, or any other communication between us relating to the subject matter of this Agreement.

All questions about this Agreement should be directed to:

Ericsson Inc. Customer Service Center (IDO) One Ericsson Drive Piscataway, NJ 08854 Phone: +1.844.251.0201 (USA and Canada) or +1.913.241.6682 (All others) Email: [email protected]

END OF TERMS AND CONDITIONS

Rev. 01/2017