WO1999030247A1

WO1999030247A1 - Enhanced virtual access services platform

Info

Publication number: WO1999030247A1
Application number: PCT/US1998/025530
Authority: WO
Inventors: Timothy C. Chandler; Michael G. Mclaughlin; William M. Sund; John T. Lagrand; Anthony Zaide
Original assignee: Telehub Communications Corporation
Priority date: 1997-12-05
Filing date: 1998-12-02
Publication date: 1999-06-17
Also published as: AU1618399A; EP1034485A1; TW391111B

Abstract

A method and apparatus for providing enhanced communications services in conjunction with a communications network is disclosed. The method and apparatus includes collecting information in real-time concerning a transaction traversing the network (337) and storing the transaction information in a database (330). The method and apparatus also includes accessing the stored information from the database in real time (160).

Description

ENHANCED VIRTUAL ACCESS SERVICES PLATFORM

FIELD OF THE INVENTION

The present invention relates to telecommunications and, more particularly, to a universal communication network platform providing services on a virtual basis, with integrated management, billing, and control capabilities at the transaction level.

BACKGROUND OF THE INVENTION

The U.S. telecommunications industry serves more than 90 million households and 25 million businesses (158 million lines), and generated revenues approaching $400 billion in 1996. Technological advancement in this market, however, has been relatively slow, in part, due to a restrictive regulatory climate. Accordingly, the current environment evinces a number of serious shortcomings.

Until 1984, telephone services in the United States were largely monopolized by AT&T. In 1984, AT&T was required to divest its local telephone systems, creating seven Regional Bell Operating Companies ("RBOCs"). The separation of the RBOCs from AT&T's long distance services created two distinct telecommunications market segments, local exchange and long distance.

While vigorous competition existed in the long distance market, significant market entry barriers impeded the emergence of competition in the local exchange market. In addition to the large capital outlays required to build redundant competing networks, these market barriers include legally mandated local monopolies and the inability of competitors easily to interconnect with local exchange networks. Additionally, Incumbent Local Exchange Carriers ("ILECs") (including the RBOCs) often refused to "unbundle" their networks in order to provide third parties access to non- wire parts of their systems such as billing administration, network management and provisioning resources.

The Communications Act of 1996 (the "Act") establishes a statutory program for the development of competitive local markets, with a particular emphasis on eliminating the entry barriers that have impeded local exchange competition. The Act contemplates three paths of entry into the local market: construction of new networks, the use of unbundled elements of the incumbent's network, and resale. Today, under the Act, RBOCs may only offer long distance services within their respective local exchange regions if and when they satisfy the requirements of a 14-point checklist contained in the Act. Among other things, the RBOCs must prove that they face effective competition from facilities-based companies that use independent networks and switches to offer an alternate local service and that the RBOCs have offered competitors access to local services for resale at "fair and reasonable" resale rates, "unbundled" their networks to allow competitors to buy basic non-wire service elements (from which to build their own service packages), and established rules that allow competitors to interconnect to their network.

In an effort to protect proprietary features of their networks, local exchange carriers have attempted to interpret the scope of the unbundling and interconnection rules narrowly. As a result, competitors have not been able fully to utilize the features of existing local exchange networks, thereby hampering competition and forcing new entrants to expend enormous amounts of time and capital to duplicate local exchange facilities.

Another shortcoming in existing networks is the inability efficiently to link traditional narrow-band networks with newer, faster broad-band networks. Leased lines (or narrow-band lines), with their fixed point-to-point or multi-point configurations, have been the mainstay of data transport for many years. While dominant and still growing, leased lines have begun giving way to the faster, more economical packet-based higher bandwidth methods of moving data, such as cell or frame-based methods (broad-band lines). These are more efficient generally because they permit multiple users to share the same transport. Despite the clear advantages of broad-band technology in transporting voice, video and data information, to date, it has not been possible to establish a universal broad-band-based public switched network. Nor has it been possible to link such a broad-band network to existing narrow-band public switch networks. This is because the current public-switched network environment lacks the management, billing and control means necessary to operate such a network.

Current networks also fail to utilize call processing information in the most efficient manner. Conventional telephone switches transmit information required for processing telephone calls via normal voice trunk circuits using tones, simple relay logic or other electrical devices (i.e., in-band signaling). In contrast, Signaling System 7 ("SS7"), a more recently developed digital signaling system and the most common system used currently, carries processing information over data links separate from the voice trunk network - commonly referred to as "out-of-band signaling." By storing information, such as routing data, billing information and technical system data and controls at the service control point ("SCP") level, an SS7 network allows call set-up and routing to be accomplished independently of the voice circuits. The result is enhanced speed and efficiency of the telecommunications voice network.

SS7 technology also allows a portion of the intelligence component of the telecommunications network to be removed from the physical switching apparatus and located in centralized Services Management System (SMS) databases. Messages, such as telephone number, calling card validation, 800 number routing, and calling name delivery are transmitted to signal transfer points ("STPs") that route the messages to the proper SCPs where call processing information is stored. These SCPs also house line information databases ("LIDBs") that provide billing and calling card validation, 800 number portability, and other database services.

Whether using conventional telephone switches or SS7 technology, current networks collect call processing information in a switch-centric, afiter-the-fact manner, capturing information pertaining only to a portion of the call transaction that was visible to the switch after the call entered the switch and before it was forwarded out of the switch. Traditional switches store the collected information as a Call Detail Record ("CDR") in the local exchange carrier central office, typically on some magnetic storage medium (e.g., tape or disk). Although CDRs share many standard elements, each switch generates CDRs according to its own specific format, which may or may not correspond to the CDR format used in other switches. Thus, CDRs are archived in a dispersed, non- standardized, after-the-fact manner among numerous local switches such that it is not accessible or easily aggregated for real-time analysis or use in providing certain valuable services either to users or telecommunications providers, including network management, network engineering, billing administration, system administration or resource provisioning. For example, if a caller wanted to investigate the history of a particular call to assess his billing obligations, the call information is not available in real-time. CDRs must first be recovered from storage within the local switches. That information is then forwarded to a billing interface processor where it is processed. It may take up to two billing cycles before the caller actually sees the desired billing information.

Similarly, in the course of using SS7 technology, a substantial amount of transaction information such as data, billing information, and technical system data and controls passes through the system. Typically, such SS7 information is discarded entirely after the transaction occurs. While some SS7 networks and services are currently being implemented by companies utilizing certain SS7 processing information, such information has only been collected, stored and utilized in a relatively dispersed, switch-centric, fragmented manner. SS7 information has not been collected and stored for entire call transactions nor has that information been accessible in real-time to provide enhanced services to users.

Another shortcoming of existing telecommunications systems is their inability to allocate bandwidth resources efficiently or accurately determine bandwidth usage. For example, a user of narrow-band leased lines is typically billed for the circuit capacity and the distance between the two points. When the circuit is not fully used, its idle capacity is unusable for any other purpose or customer. Additionally, there is no means to take an accounting of the bandwidth specifically used.

The alternatives to leased lines are using packet networks such as Frame Relay and ATM. Even these broad-band networks, as currently implemented, involve charging the customer a flat monthly fee based on the bandwidth the customer desires - called a Committed Information Rate ("CIR"). Because the ability to track actual bandwidth used or the amount of data actually transported accurately is severely limited, any underuse of bandwidth (i.e., less than the CIR) cannot be credited to the user. Moreover, as the only transport bandwidth that is guaranteed to the customer is the original CIR, the customer can actually use more bandwidth than was contracted for up to their Peak Information Rate ("PIR") only if more bandwidth is available on the network.

Accordingly, there is a need for an improved telecommunications system which will allow local exchange carriers to comply with the Act without compromising their proprietary network information or imposing large capital outlays and time delays on new entrants. Furthermore, there is a need for an improved telecommunications system which serves as a universal interface between narrow-band and broad-band networks. There is also a need for an improved telecommunications system that can access, aggregate and analyze call processing information in a more timely and efficient manner. Finally, there is a need for an improved telecommunications system that can efficiently allocate and track the use of bandwidth resources.

SUMMARY OF THE INVENTION

According to the invention, the system for providing telecommunications services offers substantial improvements over prior systems. A wide variety of embodiments of the present invention exist and will be understood by those skilled in the art based on the present disclosure. Certain embodiments of the present invention offer services on a virtual basis with integrated management billing and control capabilities. Certain embodiments of the invention support bandwidth-on-demand services. Certain embodiments of the invention enable remote Service Management System ("SMS") database access. Certain embodiments of the invention provide a way for ILECs to comply with the Act in an efficient and secure manner. Certain embodiments serve as a universal interface between narrowband and broadband networks. These and other embodiments of the invention will be understood by those skilled in the art based on the present disclosure.

Certain embodiments of the invention offer many advantages including, without limitation, the following: • a system providing narrow to broadband internetworking;

• a system for efficiently using existing ATM transport bandwidth;

• a system for provisioning accurate bandwidth-on-demand;

• a system enabling billing based on the actual bandwidth used and the actual amount of data transported; • a system for collecting all detailed records concerning transactions and converting the data to customer required CDRs in real time; a system providing customer access for such functions as real-time billing data, network status, Primary Interexchange Carrier/Customer Account Record Exchange ("PIC/CARE"), and customer updates to the SMS database;

• a system supporting real-time network engineering and management, subscriber and customer service provisioning, and billing and system administration;

• a system for providing Mediated Access Services ("MAS"), which allows carriers and service providers to exchange key information without compromising their proprietary databases;

• a system for transporting voice, data, video, and other services on one network; and

• a system for providing fixed-segment services (e.g., permanent virtual circuits ("PVCs") and soft permanent virtual circuits ("S-PVCs")) on demand.

These and many other advantages of certain embodiments of the invention will become apparent to those skilled in the art from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

An understanding of one or more embodiments of the invention may be gained by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a high level diagram of a portion of a communication network incorporating an embodiment of the invention.

FIG. 2 shows an embodiment of an Element Manager.

FIG. 3 shows an embodiment of a Master Service Management System. FIG. 4 shows an embodiment of an Interface Element Manager.

FIG. 5 illustrates an example of how a call flows through the network from origin to destination in an embodiment of the invention.

FIG. 6 illustrates an example of server architecture and switching center configuration in an embodiment of the invention. FIG. 7 illustrates an example of a typical data transmission pattern over time in an embodiment of the invention.

FIG. 8 illustrates an example of the communication architecture in an embodiment of the invention.

FIG. 9 illustrates an example of mediated access services in an embodiment of the invention.

DETAILED DESCRIPTION

FIG. 1 illustrates a high level diagram of a portion of a communication network incorporating an embodiment of a Virtual Access Services Platform ("VASP") system according to the present invention. The VASP system is used to build a broadband communication network, as might be operated by a service provider, that is referred to herein as a "network."

Using certain embodiments of the VASP system, traditional narrow-band networks can be efficiently linked with newer, faster broad-band networks. VASP system components, referred to as element managers, perform the system functions to achieve this link. The various element managers are discussed in detail below. Using certain embodiments of the VASP system, a mediating carrier (i.e., neutral third party) could support the exchange of key information between subscribing carriers and service providers, without compromising their proprietary databases. As described below, access to data stored in a mediating carrier's master relational database could be regulated through the definition of views. For example, a subscribing carrier could view data relating to the subscribing carrier's customers, and a providing carrier could view data relating to the providing carrier's equipment. The subscribing carrier and the providing carrier, however, would not be able to view each other's data.

Certain embodiments of the VASP system support enhanced services. One enhanced service is a telecommunications voice network with increased speed and efficiency. By carrying call processing information over data links that are separate from the voice trunk network, call set-up and routing is accomplished independently of the voice circuits. Another VASP system enhanced service is network provisioning. As described below, a service provider would have more detailed data than is typically available regarding available network capacity and network usage. Using this detailed data, a service provider could allocate bandwidth resources efficiently and could accurately determine bandwidth usage. This would allow the service provider to maximize the use of a given line and to bill for the actual bandwidth used, based on the actual amount of data transported.

Referring to FIG. 1, the VASP system comprises three logical components: an Element Manager ("EM") 101, a Service Management System ("SMS") 305, and an Interface Element Manager ("IEM") 405. Each of these components is described briefly now, with detailed descriptions provided in the following sections.

As illustrated in FIGS. 1 and 2, the first VASP component, EM 101, is a set of "element managers." Element managers perform many VASP system functions such as interfacing, protocol conversion, and general management and control. EM 101 includes a Signaling Element Manager ("SEM") 110, a Master Element Manager ("MEM") 105, and a Transport Element Manager ("TEM") 115. SEM 110 manages the signaling layer of the network via legacy SS7 and other advanced signaling protocols, while TEM 115 manages the transport layer of the network via legacy interfaces (DS-0 through OC-12) to the ATM network. MEM 105, located between SEM 110 and TEM 115, executes service logic and functions, as well as manages the communication and synchronization functions of SEM 110 and TEM 115. In some embodiments EM 101 also includes additional element managers to perform other functions, such as an Intelligent Peripheral Element Manager ("IPEM") to handle voice processing (e.g., voice recognition and tone playing). As illustrated in FIG. 3, the second VASP system component, SMS 305, provides support for various VASP system functionality. This functionality includes several SMS applications 325 such as billing administration 335, network management 337, service provisioning 339, network engineering 341, and system administration 343. SMS applications 325 access data in a master SMS database (e.g., Master SMS DB 330) via Data Access Layer 160. Both Master SMS DB 330 and Data Access Layer 160 are discussed below.

As illustrated in FIG. 4, the third VASP system component, IEM 405, manages the interface layer for systems that interface with Master SMS DB 330. Managing the interface layer includes enabling and disabling a particular interface and regulating which systems are connected. External systems interface 482 manages the flow of information to and from external systems 480. User interface 472 provides access to SMS applications 325 from client 470. IEM 405 is described in further detail below.

TECHNICAL ARCHITECTURE SS7 Interface Referring to FIG. 2, SS7 interface 224 performs the tasks of managing the connection and transporting messages between SS7 network 220 and MEM 105, as follows. Incoming ISDN User Part ("ISUP") messages pass via an A-link through ISUP interface 222 to SS7 interface 224. SS7 interface 224 extracts the details (e.g., parameters) from the messages and passes these parameters to MEM 105 for processing. For outgoing messages, SS7 interface 224 receives the parameter values from MEM 105 and constructs the ISUP messages to be forwarded through ISUP interface 222 to SS7 network 220. SS7 interface 224 uses commercially available DGM&S OMNI software that supports all layers of the SS7 protocol and which runs in an active/backup fault resilient mode. As those skilled in the art will appreciate, the SS7 interface could use any software based on an industry standard SS7 protocol API (e.g., as would be provided by Trillium Digital Systems Inc.).

ATM Interface

Referring to FIG. 2, ATM interface 234 performs the tasks of managing the connection and transporting messages between TEM 115 and ATM node 230. As those skilled in the art understand, most networks would contain more than one node. Messages are transmitted between TEM 115 and ATM node 230 using the Simple Network Management Protocol ("SNMP") protocol, via Ethernet and IP relay. ATM interface 234 is responsible for constructing the outgoing SNMP protocol messages based on the parameters sent from TEM 115 and for decoding the incoming SNMP error and status messages. The SNMP messages pass from ATM interface 234 through SNMP Manager 232 to ATM node 230. SNMP Manager 232 can be implemented with a public domain SNMP library.

Data Access Layer

As will be understood by those skilled in the art based on the present disclosure, Data Access Layer 160 is a generic data access API and various VASP system components have their own instances (i.e., copies) of Data Access Layer 160. For example, as illustrated in FIG. 1 and FIG. 3, an instance of Data Access Layer 160 sits between SMS applications 325 and Master SMS DB-A 620. The inquiry and update calls to Master SMS DB-A 620 are encapsulated using the Oracle Call Interface ("OCI"), with the communication with Master SMS DB-A 620 taking place over a TCP/IP

LAN/WAN, using SQL*Net as middleware.

Another example of Data Access Layer 160 is illustrated in FIG. 2. In this example, an instance of Data Access Layer 160 sits between a distributed EM database (e.g., EM DB 210 (described below in the section entitled "Data Distribution") and the MEM 105 and TEM 115 components of EM 101.

In a conventional manner, Data Access Layer 160 provides firewall security, transaction benchmarking, and change flexibility (e.g., for SQL code). Data Access Layer 160 also isolates the Oracle Call Interface and SQL code from VASP system application code. This reduces the complexity of integrating SQL code with application code and enables significantly easier and more timely maintenance of the VASP system.

User Interface

User interface 472 is a graphical user interface ("GUI") that provides access to SMS applications 325 (discussed below) from client 470. Client 470 can be any appropriate platform, including the Windows95, Windows NT 4.0, and Java platforms.

As would be understood by one skilled in the art, user interface 472 could be any appropriate type of interface (e.g., voiced command or menu based) running on any appropriate platform (e.g., OS/2 or Unix).

External Systems Interface

External systems interface 482 manages the flow of information to and from external systems 480. External systems interface 482 allows external systems 480 to access Master SMS DB 330 for managing the flow of information to and from Subscribing Carriers; Customer Care and Billing Systems; and other providing carriers, provisioning centers, and information sources (e.g., NPAC and Bellcore Local Exchange

Routing Guide ("LERG")/LIDB Access Routing Guide ("LARG"). Examples of the communication with external systems 480 also include EDI, data transfer with external systems, and messaging with network equipment.

Network Element Management Interfaces

The interfaces to network elements (e.g., STP, 600E switches) support the operation, maintenance, administration, and provisioning (i.e., OAM&P) functions required for proper operation of the network. These functions include error monitoring, status monitoring, and control operations not supported by the SS7 and ATM Interfaces. These interfaces are not specific to the VASP system. Rather, these interfaces are either standard interfaces or interfaces that are proprietary to an equipment provider. Those skilled in the art would be familiar with management protocols, such as Common

Management Information Protocol ("CMIP"), Simple Network Management Protocol ("SNMP"), or Transaction Languagel ("TL1").

VASP APPLICATION ARCHITECTURE This section refers to several system components that are discussed further herein.

One component, an "EM server," supports several VASP system processes and the associated data storage. The other components, the "ATM backbone" and "switching centers" are generally known to those skilled in the art. Switching centers contain the equipment responsible for routing information from the point of origin to the destination.

MEM

The network is controlled by one EM server (e.g., EM server-A 605). In certain embodiments, the EM server is located in a Chicago switch center, with a backup located in a New York switch center (e.g., EM server-B 625). Class 4 switch functionality is built into MEM 105, which performs SS7 message routing, destination routing logic, and transaction logging. All call transactions in the network, whether transported over the ATM backbone or not, are handled by the single EM server.

Within the SS7 network, MEM 105 is represented as a distinct signaling node, to which ISUP messages are routed from either the Access Tandem switches that are serviced by the network, or by 600E switches located within the switching centers. In the basic call model for this architecture, MEM 105 will process all ISUP messages, originating messages from Access Tandems, inter-network messages between 600Es, and terminating messages to Access Tandems or third-party service providers. For example, the IAM message for a call from New York to Chicago, transported over the ATM backbone, would be routed in the following sequence: ATNY - MEM - 600ENY - MEM - 600ECHI - MEM - ATCHI, where AT refers to an Access Tandem switch. In performing this routing activity, MEM 105 performs a database lookup, translating the actual called party number to a Virtual Routing Number ("VRN"). The VRNs serve to remove call routing logic from the 600E switches and place this logic in MEM 105.

The basic call model example, described above, represents the base set of service logic that resides on MEM 105. As will be understood by those skilled in the art based on the present disclosure, the present invention permits additional modules of service logic to be incrementally added to MEM 105 to support the following services:

• Basic Call (1+)

• 800/888

• 10XXX • International

• Operator Services (0 & 00)

• 0+

• Calling Card

• NPA-555 • Dedicated Voice

Throughout the life of a call, MEM 105 logs the circuit-related ISUP messages that it receives, as well as the transaction data, such as timestamps used for billing purposes. Since MEM 105 components can process a call transaction at more than one point for each ISUP message, multiple message and transaction log entries are generated. A summarization function takes place within SMS 305 to deliver the billing functionality.

TEM

In a conventional manner, TEM 115 manages call traffic that is carried over the ATM backbone trunks and sets up and tears down bandwidth in response to changes in the traffic flow. The 600E switches in the network preferably are configured such that the circuits and ports used are selected in a specified order. Because of this, the number of calls out of each switch port can be tracked, and when a threshold point is reached, an additional ATM backbone trunk can be dynamically configured in preparation for the use of an additional switch port. In order to speed up the processing time, the data used by TEM 115 during the backbone management and virtual trunk set up and tear down is referenced from static, memory resident, data structures in memory resident data 205. Additionally, TEM 115 responds to the incoming error and status messages received from the BPX switches. As will be understood by those skilled in the art, TEM 115 functionality described in this section is common in communication networks.

SEM

SEM 110 manages the signaling layer of the network via legacy SS7 and other advanced signaling protocols. Those skilled in the art would be familiar with signaling protocols, such as ISDN User Part ("ISUP"), Transaction Capabilities Application Part ("TC AP"), Message Transfer Part ("MTP"), and Signaling Connection Control Part

("SCCP"). In some embodiments the TR-303, Q.931, and Q.2931 signaling protocols are used.

IEM IEM 405 is the generic interface between Master SMS DB 330 and external systems or customers (e.g., subscribing carriers) and facilitates the transfer of information into and out of Master SMS DB 330. Referring again to Fig. 4, IEM 405 comprises user interface 472 accessible to clients 470 and external systems interface 480 accessible to external systems 480. IEM 405 further includes data transform function 488 that translates incoming data received from external systems 480 or clients 470 into formats compatible for use within Master SMS DB 330 and transforms outgoing data from Master SMS DB 330 into formats compatible for use by clients 470 or external systems 480. Data transfer function 484 facilitates the movement of incoming and outgoing data to and from data transform function 488 to its final destination. Data audit function 486 checks data translated by data transform function 488 to ensure that the data has been converted to a form usable by the destination system (i.e., Master SMS DB 330, clients 470 or external systems 480).

IEM 405 provides the customer interface to the communication network for such functions as real-time billing data, network status, Primary Interexchange Carrier/Customer Account Record Exchange ("PIC/CARE"), and customer updates to Master SMS DB 330. It also is used to collect Transaction Detail Records ("TDRs") from Master SMS DB 330, converts TDRs to client/subscribing carrier required Call Detail Records ("CDRs"). TDRs and the creation of customer CDRs are more fully described below in conjunction with the Master SMS DB 330.

Data interfacing and interpretation between central databases and external systems is well-known to the art. The generic functionality of IEM 405 described above may be achieved using those prior art means.

SMS Applications

SMS applications 325 access Master SMS DB 330 to support internal VASP system functionality. This functionality is primarily implemented through the use of

TDRs and falls into broad categories such as Billing Administration, Network Management, Service Provisioning, Network Engineering, and System Administration. Examples of functionality in each of these categories are provided below. As those skilled in the art understand, SMS 305 can easily support additional functionality, such as Trouble Management, PIC/CARE, and telephone number-based long-distance debit services.

Transaction Detail Records ("TDRs")

TDRs are defined as the real-time collection of network transaction information

(e.g., network signaling messages, access/transport/exit routing information, network resource usage and consumption data, etc.) that can be used for providing enhanced functionality such as resource provisioning, control of AIN services, billing and maintenance of those services, and network management. Preferably, TDRs encompass information traditionally generated and contained in CDRs and also include information generated in the course of using SS7 technology and other network signaling technology (e.g., SNMP) and additional relevant transaction information about messages traveling through the VASP system. Thus, in contrast to CDRs and other switch-centric collections of call processing information, TDRs include information relevant to the entire transaction, not just the fragment available to a particular switch. This is possible because embodiments of the present invention are able to "see" and control the entire network transaction from beginning to end.

In one embodiment, TDRs comprise a collection of data tables making up a highly normalized relational database within Master SMS DB 330. Using data structures and methods known in the art, transaction processing information is collected in realtime and stored in a standardized format in this database. Moreover, the transaction information may be analyzed to derive other information that may be stored in TDRs.

For example, the transaction processing information may be taken from TDRs, used to determine error conditions and the error condition information can then also be collected in TDRs.

The following is a representative list of some types of information collected and stored in TDRs although those skilled in the art will appreciate that there are numerous other types of information that may be stored in TDRs which could be useful in the provision of communications services:

Network Signaling Messages: time of transaction, type of message, and optional parameters such as calling number, dialed number, charge number, and ported number;

Routing Information: access and exit paths, transport paths, trunk and circuit connections, and re-routing information;

Network Resource Usage: circuit bandwidth used and processing elements (SEM, TEM, etc.) used;

Additional Information: error conditions regarding the transaction, originating carrier, originating city; total connection time, and type of information transmitted (i.e., voice, data, video).

The real-time collection of information in TDRs allows for real-time analysis and acquisition of the information. Using the information in TDRs, one can see the status of a call in progress and assess the route that call has traveled within the system. By collecting the above types of information in real-time as taught herein and analyzing it, one skilled in the art would be able to determine patterns in the information, derive important details about the transactions (e.g., the message failed to route, there was no answer, the answer was incomplete, the address was incomplete, etc.) and define relationships within the TDR database that allow for the provision of enhanced communications services. For example, the table below illustrates the relationship between Access ("A"), Transport ("T"), and Exit ("E") SS7 routing messages collected for each transaction in the TDRs and the status of transactions, individually and overall, in the network. This table represents a report that may be routinely generated for the purpose of assessing and maintaining the network.

NETWORKHEALTH REPORT

As discussed above in conjunction with the IEM 405, the information from TDRs may be used to create CDRs for use by customers because TDRs either directly include the information traditionally contained in CDRs or may be used to derive the required or surrogate CDR information. Furthermore, as TDRs are standardized internally and encompass call processing information for entire transactions, a customer may be efficiently provided with CDR information for entire transactions in a CDR format of the customer's choosing. Currently, CDR information for an entire transaction may only be obtained by the extremely slow and inefficient procedure of collecting the non- standardized CDRs from each switch involved in that transaction and translating the CDRs into a format usable by the customer. Similarly, the real-time accessibility of TDR information and control of the entire network transaction allows for efficient service provisioning. One strength of the present invention is that it allows for the efficient control and use of network resources by providing enough bandwidth for any overflow traffic. Embodiments of the present invention are capable of controlling the ATM switches and, via TDRs, the real-time utilization of the network trunk and its routing. By monitoring network traffic in realtime, the system is able dynamically to route overflow traffic to other paths on the network, and consequently process data that would be lost with normal ATM switching in the prior art legacy network environment. For example, referring to FIG. 7, the graph depicts a typical data transmission pattern over time. All traffic up to the Sustainable

Cell Rate ("SCR") 705 is processed without delay. In Bl 740, because of the short duration of the burst, all traffic up to the Cell Delay Variation Tolerance ("CDVT") 710 is processed with the segment above, Discarded segment 715, being lost. In B2 745, all traffic up to the Peak Cell Rate ("PCR") 720 whose duration is less than the Maximum Burst Size ("MBS") 725 is admitted (Admitted segment 730). That traffic exceeding

MBS 725 is tagged (Tagged segment 735) and could be discarded. Utilizing the VASP system technology solution, the management function would permit all but the excess bandwidth above CDVT 710 to be processed. This proactive approach preempts the discarding of any cells. The VASP system technology controls how such traffic is optimized on the ATM network and dynamically allocates bandwidth-on-demand. The result is the ability to offer an almost guaranteed network bandwidth availability to it users. These and other enhanced services enabled through the use of TDRs are further discussed below.

Billing Administration 335

• Master SMS DB 330 is the master data repository of all network transaction information.

• Manages the flow of data, such as billing data to wholesale billing systems and subscriber customer CDRs to subscribing carriers.

• Provides for the management of transaction record summarization, archival, and deletion. Network Management 337

• Analyzes transaction and error data collected from network components.

• Provides a network control center with the capability to monitor and control network equipment, facilities, routes, and systems.

• Provides a network control center with reports and alarms for managing the network.

• Provides for the management of error record summarization, archival, and deletion.

Subscriber and Customer Service Provisioning 339

• Provides an interface to manage the subscribing carriers' records and services provided to their customers.

• Provides import capabilities for subscribing carrier customer service requests (i.e., orders) and the user interface for manual input of orders.

• Provides reports for service provisioning administration and order ercor resolution.

Network Engineering 341

• Provides an engineering interface to configure locations, equipment, routes, facilities, services, and systems.

• Includes import and provisioning for Bellcore LERG/LARG data and Regional NPAC local portability subscription data.

• Provides usage reports for engineering inventory, capacity management, and growth planning.

System Administration 343

• Provides user and system security administration.

• Provides database maintenance interface for analyzing and maintaining VASP system data tables.

• Provides reports for VASP system application transaction and administration tools. Mediated Access Services

In certain embodiments that will be understood by those skilled in the art based on the present disclosure, the Master SMS DB 330 is used in the provision of Mediated Access Services in the telecommunications industry. This capability provides neutral "third-party" access to the various SMS databases throughout the industry. For example, in a mediated access services system, any service provider (virtual or facilities-based) will be able to obtain the key call treatment information necessary to properly process its customers' calls while the proprietary information of the database owner is protected from compromise. For example, a requirement for mediation results from the FCC's Local Number Portability (LNP) order. That order requires the RBOCs and GTE to provide their customers who desire another competitive carrier the ability to change local service providers within the exchange and retain their same telephone number.

Mediated Access Services will greatly improve the LECs capability to offer unbundled local service elements to other carriers in compliance with the requirements of the Telecommunications Act. Mediated Access Services also provides a beneficial solution for unbundling the local exchange network and promoting local service competition.

Referring now to FIG. 9, Subscriber 905 (a subscribing carrier) interfaces (via IEM 405 - not shown) with Master SMS DB 330 to place orders for voice/data services on behalf of its customers. The interface also allows Subscriber 905 to obtain real-time status information and CDRs (to effectuate billing administration) regarding its orders from Master SMS DB 330. Similarly, Provider 910 (a providing carrier) is linked to Master SMS DB 330 to receive queries regarding service requests and to provide status information back to Master SMS DB 330. Provider 910 includes a service provider database.

The mediating role is effectuated by restricting access to data stored within Master SMS DB 330 through the definition of views. For example, Subscriber 905 will only have access to the data that pertains to its network equipment and call traffic. Provider 910 will have access to the data that pertains to its network equipment, but not to the details about the call traffic that is carried on the equipment. Call traffic data is available in summary form only. The VASP system, via the Master SMS DB 330, has access to, and is able to maintain, all of the data on the network.

Master SMS DB 330 receives the Calling Party Number ("CPN") from Subscriber 905, and, using its class of service information, identifies the appropriate Provider 910. The query is then routed to the Provider 910 service provider database where the details of the customer and services are maintained. Provider 910 then generally provides the services directly to customers of Subscriber 905, under the brand- name of Subscriber 905.

Embodiments of a mediated access services system permit LEC Providers 910 to offer fully unbundled local exchange capabilities, utilizing existing network facilities and switches, while protecting access to their proprietary and customer databases. In this multi-layered architecture, the Master SMS DB 330 contains only the logic required to control the basic service elements. All carrier and customer-specific data are maintained externally.

Responses to the local switch queries instruct the switch how to apply the next local service elements without disclosing the nature of the service, or identifying the customer being served. This architecture provides a full set of local switching capabilities to external service providers without the cost of owning and operating a local switch, while maintaining complete isolation of the Subscriber 905 and Provider 910 databases. The net result of this multi-layered service offering is that it enables any service provider, that elects to use the capabilities, the potential to become a virtual carrier. Competitive providers then have the ability to offer the same types of services presently available only from the IXCs and LECs.

BASIC CALL MODEL FLOW Given a communication network based on a VASP system according to the present invention, the following describes a "Basic Call Model" in terms of a typical two party voice call. The model holds for two party calls with bit rates for voice, data, and video. However, the bit rate of the media must match the bit rate of the signal, i.e., standard DS-0 trunks used for voice rate signals cannot handle video signals. Each call requires communication and signaling facilities that provide a path for voice signals and call control signals respectively. EM 101 call processing allocates media (i.e., facilities or trunks to carry the communication signals, such as voice signals in this case) between the parties of a call. Trunks are allocated on a per call basis. Signaling links carry out-of-band call control messages between the signaling and switching components of the system. Owing to the nature of common channel signaling, the signaling channels are separate from the communication channels. Signaling links process all messages to and from a signaling point according to a load sharing mechanism inherent in the link and network level protocols of SS7.

The Basic Call Model consists of three portions, an originating portion, a terminating portion, and, as required, a transport portion. For a VASP-enabled network, each of these portions of the call also has originating and terminating portions. Each portion appears to the switching and signaling components, as unrelated calls segments. One of the functions of the service logic in EM 101 is to analyze and manipulate signaling messages to provide correlation between the call segments. A similar function is performed by the SSPs (e.g., SSP1 517 and SSP2 533) for the calls they process. This correlation function is common to switching systems, although the implementation varies.

Access trunks are associated with the originating call portion, and exit trunks are associated with the terminating call portion. Transport trunks, also called backbone trunks, are associated with the transport portion. One of the functions of EM 101 call processing is to "switch," that is, to cross-connect access trunks to exit trunks to create an end-to-end path over which communication between users takes place. Under certain circumstances, a transport trunk may be required to effect the requested cross-connection. Trunks are normally configured as a two-way medium. This means that for different calls, the same trunk may be used as either an access trunk (originating) or an exit trunk (terminating).

Referring to FIG. 5, access and exit trunks (e.g., access-exit trunks 553) consist of sections of DS-1 (1.544 Mbps) Time Division Multiplexed ("TDM") media configured for SS7 and Feature Group D ("FGD") operation. Transport trunks consist of sections of DS-1 TDM media (e.g., transport trunk 555) and DS-3 or OC3 ATM media (e.g., transport trunk 557) configured for SS7 and inter-machine operation.

Service Access Modules ("SAMs") (e.g., SAM 519 and SAM 531) adapt the TDM network to the ATM network with circuit emulation functions that maintain frame synchronization of the TDM Intermachine Trunk ("IMTs"), and convert TDM signals to ATM signals and vice versa. Circuit emulation functions are used because of differences in the transmission and timing characteristics between TDM and ATM. TDM is a continuous, nearly synchronous, frame-based transmission mode, and ATM is synchronously or asynchronously timed, packet-based transmission mode. These dissimilar modes of transmission cannot be directly inter-connected.

SAM media interworking converts TDM signals (channels and frames) to ATM signals (53-byte cells) and vice versa. Additional SAM functions provide loopback connections on the SAM TDM ports that maintain timing synchronization in the absence of connections on the corresponding ATM virtual circuits ("VCs"), such as is the case when the TDM circuits are not in use.

Current networks utilize two primary trunk transmission configurations, end-to- end TDM sections, or TDM sections cross-connected by ATM permanent virtual circuits ("PVCs"). In the first configuration, TDM paths between two switching points are terminated by digital transmission equipment at the switches. The digital transmission equipment maintains timing and frame synchronization required for proper operation of the end-to-end TDM circuit.

In the second configuration, TDM circuits are terminated by circuit emulation service modules of an ATM node are and cross-connected by an ATM permanent virtual circuit, i.e., a virtual circuit that is pre-configured and always "connected." The result is an end-to-end frame synchronized TDM path. The ATM cross-connect section is transparent to the TDM portion of the path. In these two configurations the paths are present whether or not calls are active on the trunks. ATM resources associated with the cross-connects are dedicated to the PVCs and are not available for allocation to other services or applications, not even for other cross connects (in a typical application). The trunk configuration of a VASP-enabled network is similar to the second configuration except that the ATM virtual circuits are created on demand, as required to cross-connect TDM access and exit trunks when calls are active on the trunks. VASP virtual circuits are so-called "soft" PVCs ("S-PVCs"). S-PVCs differ from PVCs in that the request for a S-PVC requires only the endpoints of the VC at the time of the request. A protocol in the ATM backbone network determines the path for the VC. The ATM nodes may dynamically adjust the path depending on factors, such as bandwidth demands of other applications. The S-PVCs are configured with capacity to carry one DS-1, i.e., 24 TDM channels (1.544 Mbps). The VASP system currently uses an S-PVC capacity of DS-1 because that is the level of channelizing available in the SAMs; however S-PVCs may be configured for capacity of DS-0, DS-1, or DS-3 (higher for optical media) if the proper channelizing is available in the SAMs and ATM nodes. DS-0 channelization is preferred for voice applications. DS-1 multiples up to DS-3 are suitable for data and other non-voice applications. The S-PVCs are torn down when there are no calls on the associated TDM trunks. When the S-PVC is torn down, the end- to-end path no longer exists, resulting in a loss of frame synchronization on the associated TDM circuits. To maintain synchronization, TEM 115, managing the ATM trunks, applies a loopback connection to endpoints of the ATM VC, which causes the associated TDM channels to maintain frame synchronization. The loopback connection is removed by TEM 115 logic during call setup when the TDM trunk is to be used in a call.

When there are no calls on a virtual circuit, its ATM resources can be allocated to other services or applications. This results in more efficient use of ATM resources because resources are not consumed when there is no demand (traffic). The operator of a VASP-enabled network can "over subscribe" the services of the network, that is, offer more services than can be handled simultaneously by the available ATM resources (bandwidth); however, as expected, all services can not be requested at once.

An SS7 link 551 is a signaling link that carries Common Channel Signaling Number 7 ("SS7") ISDN User Part ("ISUP") messages. Signaling links are sections of TDM media operating in a dedicated or "clear channel" mode of 56 or 64 KB/s. Higher rates (e.g., 1.544 MB/s) may be used for signaling links between EM 101 signaling points within a VASP-enabled network; however, standards for high-speed links are not mature for general use in public networks. SS7 ISUP messages to setup and tear down calls are exchanged over SS7 links 551 that run between signal transfer points (e.g., STP-A 501, STP-B 503, and STP-C 505), as well as between signal transfer points and

Access Tandems (e.g., AT 515 and AT 535), service switching points (e.g., SSP1 517 and SSP2 533), and EM 101 components (e.g., SEMs).

There are variants for national and international applications of ISUP. EM 101 components are programmed to use the ANSI 88, 92, or 96 variants of the ISUP protocol. ANSI variants are used mainly in North America. EM 101 components can be programmed to use most of the ISUP variants in use nationally and internationally. The various EM 101 element managers (e.g., MEM 105, access SEM 123, exit SEM 125, and TEM 115) communicate over TCP/IP connections, such as TCP/IP paths 120. SEM 110 was described generally in connection with FIG. 1. Embodiments of SEM 110 include originating SEMs (e.g., access SEM 123) and terminating SEMs (e.g., exit SEM 125). All SS7 nodes (signaling points) are assigned addresses called point codes that allow nodes to designate and identify one another as the source or destination of messages. The source of an ISUP message is the Originating Point Code ("OPC"); the destination is the Destination Point Code ("DPC"). As SS7 nodes, each AT (e.g., AT 515, AT 535), SSP (e.g., SSP1 517, SSP2 533), SEM (e.g., access SEM 123, exit SEM 125), and TEM 115 is assigned a point code. Within a VASP-enabled network, the point codes assigned to access SEM 123 and exit SEM 125 are visible to the external SS7 network; TEM and SSP point codes are not. The VASP system logic determines how messages received from external networks are routed between signaling points within the network. Within a VASP-enabled network, SEM and TEM point codes are known to SSPs (e.g., SSP1517, SSP2533).

Access SEM 123, exit SEM 125, and TEM 115 are signaling points that receive, interpret, manipulate, and transmit ISUP messages. The SEMs and TEM write the ISUP messages to transaction files in a format understood by an IEM 405 transaction reader. A transaction reader parses the message files and writes out the messages to Master SMS DB 330. These messages are the foundation for the VASP system transaction detail records ("TDRs"). SMS applications 325 process ISUP messages to enhance service management functions, such as billing administration 335, network management 337, service provisioning 339, network engineering 341, and system administration 343. Access SEM 123 and exit SEM 125 process ISUP messages associated with the access trunks between SSPs and Access Tandems. TEMs process

ISUP messages associated with transport trunks 557 between the SSPs (e.g., SSP1 517, SSP2 533). SEM and TEM components maintain mapping of AT and SSP point codes and circuit identification codes ("CICs") of the trunks of their associations. This means that ISUP messages to and from a particular AT are handled by the same SEM. The same relationship exists between TEM and SSPs. The following describes an example of a voice communication path for a basic two way call originating at a line, which could be a telephone or another type of subscriber terminal (e.g., line 507). Line 507 is connected via subscriber loop 509 to EO 511, an End Office. EO 511 is connected via interoffice/toll trunk 513 to AT 515, an Access Tandem. An access-exit trunk 553, functioning as an access trunk, carries voice rate signals from the originating AT (e.g., AT 515) to the originating service switching point (e.g., SSPl 517). If the call needs to exit at another SSP (i.e., not at the originating SSP), a connection over an ATM virtual circuit is built between the originating SSP (e.g., SSPl 517) and the terminating SSP (e.g., SSP2 533). If the call exits at the same SSP (i.e., at the originating SSP), then that SSP is the terminating SSP and no ATM backbone virtual circuit is established. For a given call, the originating Access Tandem, End

Office, and trunks could be the same as for the terminating portion; however, the subscriber terminal is almost always different, i.e., one does not usually call oneself.

On the terminating portion, access-exit trunk 553, functioning as an exit trunk, carries voice rate signals from the terminating SSP (e.g., SSPl 517 or SSP2 533) to the terminating Access Tandem (e.g. , AT 515 or AT 535). From this point, the connection to the terminating subscriber terminal (e.g., line 539) is similar to the originating connections. The terminating AT (e.g., AT 515 or AT 535) is connected via interoffice/toll trunk 513 to the terminating End Office (e.g., EO 511 or EO 537), which is connected via subscriber loop 509 to line 539. It should be noted that SSP 1 517, SAM 519, and ATM node 521 are typically in a switching center, such as Switch center-A 650 on FIG 6. Similarly, SSP2 533, SAM 531, and ATM node 529 are typically in a switching center, such as Switch center-C 670 on FIG. 6. It should also be noted that the configuration described above is for voice; however, a configuration for data or video calls in a VASP-enabled network would be similar. The differences would be in the nature of the access and exit facilities, which would have to match the bit rates of the data and video signals. Also, the subscriber terminal device would have to have functions that could originate and terminate data and video calls.

The signaling flow of a basic two-party call begins when access SEM 123 receives an SS7 Initial Address Message ("IAM") from originating AT 515 via STP-A 501 and STP-B 503 over SS7 links 551 and sends a VASP-specific message along TCP/IP path 120 requesting routing and control information from MEM 105 in order to process the call. MEM 105 performs a query of its internal data (e.g., memory resident data 205) and executes service logic to determine how or if the call should be handled. MEM 105 sends a response message along TCP/IP path 120 to access SEM 123 that contains instructions on how to handle the call.

Two pieces of data are returned from the MEM 105 query. One datum is a context indicator (i.e., a key) that links a set of messages to a particular call. This key, which is inserted in the ISDN User Part ("ISUP") IAM messages, is used by the SEMs and TEMs to keep track of the ISUP messages for each call. The other datum returned to access SEM 123 is a Virtual Routing Number ("VRN") which determines how the call is routed in the network. The VRN is used by one or more SSPs (e.g., SSPl 517) to select a trunk for the terminating portion of the call. Access SEM 123 prepares a modified IAM to initiate the terminating portion of the call. Access SEM 123 modifies the IAM by replacing the "Called Number Parameter" field with the VRN, which SSPl 517 interprets as the called number. Access SEM 123 sends the IAM to SSPl 517 via SS7 link 551. SSPl 517 then performs its normal routing function as programmed by its internal translation and routing database, as is common with service switching points.

The receipt of the IAM from access SEM 123 by SSPl 517 triggers a call event in the SSPl 517 similar to the call event in access SEM 123, i.e., a call with an originating and terminating portion. The interpretation of the VRN by SSP 1 517 determines if SSPl 517 signals TEM 115 or exit SEM 125 to handle the terminating portion of its call. If SSPl 517 determines that a connection to an AT (e.g., AT 535) connected to SSP2 533 is required, TEM 115 is signaled. If SSPl 517 determines that a connection to an AT (e.g., AT 515) connected to SSPl 517 is required, exit SEM 125 is signaled. For the latter case, the originating SEM (e.g., access SEM 123) may be signaled to perform the role of a terminating SEM. If TEM 115 is signaled, the call requires a transport trunk implemented as a soft permanent virtual circuit ("S-PVC") in the ATM network to cross-connect the access trunk to the exit trunk. To service the terminating portion of the call in SSPl 517, TEM 115 queries an internal data map of SSP trunks to ATM trunks to acquire the endpoints of the S-PVC. TEM 115 also prepares and sends an IAM toward exit SSP2 533. TEM 115 examines the ISUP message to select a terminating SSP. TEM 115 modifies the destination point code and circuit identification code ("CIC") to address the selected SSP and sends the ISUP message to the selected SSP.

The receipt of the IAM by SSP2 533 from TEM 115 triggers a call event in SSP2 533 similar to the call event in access SEM 123 and SSPl 517, i.e., a call with an originating and terminating portion. The terminating SSP performs a routing function similar to that performed by SSPl 517; however, the destination is a terminating Access Tandem. SSP2 533 signals exit SEM 125 to handle the call. Exit SEM 125 receives the IAM and restores the original called party number, selects a trunk based on the originating point code ("OPC") and CIC received from the terminating SSP and sends the ISUP message to the terminating Access Tandem which signals the terminating End Office.

If the call is answerable (e.g., valid called number, available trunks along the terminating path) the terminating signaling points (e.g., EO 537, AT 535, and SSP2 533) respond with ISUP address complete messages ("ACMs"). The ACMs pass from the exit AT (e.g., AT 535) back through EM signaling points to the originating AT (e.g., AT 515). TEM 115 uses the ACM as an indication to construct the ATM VC by signaling the ATM nodes to tear down loopback connections and build a VC between the endpoints selected earlier. Upon receipt of an Address Complete Message ("ACM") from exit SEM 125,

TEM 115 selects an ATM VC to carry the call between SSPl 517 and SSP2 533. The VC is selected based on a mapping in MEM 105 that maps TDM trunks to ATM trunks. This is a key interworking function that converts a narrowband facility address to a broadband facility address at the transport layer. The VC is not established until successful call setup has completed through to the end of the call path at the terminating subscriber line (e.g., line 539). This setup is signaled by the receipt of ANM messages from exit SEM 125, which has gone through originating and terminating call setup sequences just as have access SEM 123 and TEM 115. TEM 115 sets up the VC by issuing SNMP commands to the ATM nodes. The call is established when the SS7 ANM message has been propagated from AT 535 back along the SS7 links 551 through all STPs and back to exit SEM 125 and access SEM 123.

The construction of VCs could also be done on receipt of an ISUP Answer Message ("ANM"), which means the call has been answered by the called party or by a device on behalf of the called party. The ACM is selected because it occurs earlier in the call and allows more time for TEM 115 to signal the ATM nodes. The ANM, like the ACM, passes backwards from the terminating signaling points through the EM signaling points, back to the originating AT, and on to the originating End Office (e.g., EO 511). At this time the voice path is "cut-through," i.e., the voice path is set up end-to-end.

In a typical scenario, the call exists until one of the parties to the call hangs up, which generates an ISUP release message ("REL") which is propagated through the signaling points on the other side of the call. The REL message is an indication that the call should be torn down in all signaling points along the path. TEM 115 tears down the ATM VC if there are no other calls active on any of the DS-0 trunks of the same VC. The SEMs release resources (e.g., call registers, call contexts, and circuit identification codes) and send release complete messages to an AT which forwards them on to the an EO. Release procedures in the AT and EO are similar. Once every signaling point has completed its release functions, an ISUP release complete message is provided, which indicates the call has been dropped in all signaling points.

DATA ARCHITECTURE

Data Distribution

The main data storage location for the VASP system is Master SMS DB 330. Tables in this database support SMS applications 325, LERG/LARG, transaction logs, SS7 and error messages, and ATM routing, network, and customer service configuration. Master SMS DB 330 is conceptually one database, but as those skilled in the art understand, the data stored in Master SMS DB 330 could easily be distributed among multiple databases.

Data to support MEM 105 and TEM 115 components resides in distributed databases (e.g., EM DB-A 610 and EM DB-B 630 described herein as active and backup embodiments, respectively, of EM DB 210), which coexist on servers with EM 101 application logic. The distributed configuration of EM 101 databases provides higher performance data access and database fault resilience for logging activity.

Several data structures are stored in memory resident data 205 to provide faster access to the routing data. These tables represent a de-normalized view of the routing tables stored in Master SMS DB 330 and are synchronized with Master SMS DB 330 by known memory replication techniques such as background data transfers or store-and- forward. The data refresh process is performed on scheduled time intervals or upon user request.

Database Sizing Estimates and Transaction Volumes

The following table summarizes the storage requirements for the EM and the master SMS databases in an embodiment of the invention. In such an embodiment, Oracle products, such as Oracle Server (RDBMS), Common Oracle Runtime Environment ("CORE"), and PL/SQL, are preferably used. Each row in the table includes the type of data that is stored, the location of storage (Oracle database vs. memory resident tables), which database it is stored in (EM and/or master SMS), and notes concerning the duration of storage.

GB per Server TYPE OF DATA RDBMS EM SMS

(3 active (1 active servers) server)

Transaction (Current Month) Oracle 0.82 10.51 * EM capable of 7 days Fault Resilience Storage

Transaction (Full History) Oracle 63.06 * 6 month

Transaction (Summary History) Oracle 1.26 * 2 year (1/50 of Full History) Billing Administration Oracle 0.03

* 2 year (1/50 of Full History)

Error (Current Month) Oracle 0.01 0.1 1 * 1 error for every 100 transactions

Error (Full History) Oracle 0.63 * 6 month

Error (Summary History) Oracle 0.01

* 2 year (1/50 of Full History)

LERG/LARG Oracle 0.03 0.03

LNP (SOA & Subscriptions) Oracle 0.04 0.04

Customer Oracle 0.27

Order Oracle 0.27

Equipment and Facilities Oracle 0.02 0.02

Route Oracle 0.47 0.47

Security Oracle • 0.05 0.05

Route In Memory 0.47

Total - GB 1.91 76.76

The following tables are provided as examples of the estimated distribution of transaction processing among the various VASP system components in one embodiment of the invention. In these estimates, a transaction refers to one database select, insert, update, or delete operation, or to one message. The estimates are based on the traffic volume indicated in the first row of the tables and assume an even distribution of call traffic over the network.

CONTROL PROCESSORS

Transactions per month (in millions)

MEM TEM BPX 600E STP/SCP

1,857.143 1 ,142.857 71.429 642.857 1,000.000

Transactions per call

TASK MEM TEM BPX 600E STP/SCP

SS7/SNMP 13 7 13

External

SNMP Internal 8 1

Routing 3 1 1

Log/Status 8 1

Setup 8

EM Inter-Module 2

Total - Con trol 26 16 I 9 14 ADMINISTRATIVE

Data Archival

As call traffic is carried over the network, the transaction, message, and error logs increase in size. In order to manage the amount of disk storage for supporting the log tables, an archival procedure transfers the data to different media (e.g., tape) and summarizes the historical log entries into a less space intensive statistical format.

SECURITY INFRASTRUCTURE

Master SMS Database Access

Access to Master SMS DB 330 is controlled through the definition of discrete views of the database. These discrete views correspond to different types of carriers, and provide an individual carrier access to only the data that carrier is meant to see. This allows an individual carrier's proprietary data to remain secure while residing on a network that is utilized by several different carriers. Some examples of views based on type of carrier are as follows: Subscribing carriers only have access to the data that pertains to their network equipment and call traffic.

Mediating carriers have access to, and are able to maintain, all of the data on the network. Providing carriers have access to the data that pertains to their network equipment, but not to the details about the call traffic that is carried on the equipment. Call traffic data is available in summary form only.

System Access There are several levels of access into the VASP system. On the client side, there is an application/network level of access, based on user ID/password combinations. On the server side, there is both a general database level of access, and a more specific table/view level of access. Any password information that is sent across the network from client to server is encrypted to provide further security.

SERVER ARCHITECTURE

Switching Centers

Referring to FIG. 6, the network includes three switching centers, such as Switch center-A 650, Switch center-B 660, and Switch center-C 670. In some embodiments of the invention, Switch center-A 650 is located in Chicago, Switch center-B 660 is located in New York, and Switch center-C 670 is located in Los Angeles. When Chicago, New York, and Los Angeles are referred to herein, those skilled in the art will understand that these particular cities are used only as examples of switching center locations.

Server Configuration

As illustrated in FIG. 6, there are two types of servers in the VASP system, EM servers and master SMS database servers. An EM server, such as EM server- A 605, supports the processes that provide MEM 105, SEM 110, and TEM 115 functionality and holds a database, such as EM DB-A 610, that supports these processes. A master SMS database server, such as Master SMS DB server- A 615, supports the processes that provide IEM 405 functionality and holds the master copy of the SMS database.

As shown in FIG 6, in Switch center-A 650, the EM server-A 605 and Master SMS DB server-A 615 reside on different physical hardware. However, as those skilled in the art will appreciate, any number of hardware configurations could support the EM and master SMS database servers. For example, both EM server-A 605 and Master SMS DB server-A 615 could exist on the same physical platform. Alternatively, either EM server-A 605 or Master SMS DB server-A 615 could be distributed across multiple physical platforms. In addition, element managers do not necessarily have to run on the servers specified above (e.g., IEM 405 could run on an EM server.)

Fault Resilience Support

The VASP system achieves fault resilience as a system through a combination of hardware and software solutions. One active EM server is located in Switch center-A 650. A backup (i.e., standby) EM server, such as EM server-B 625, is located in Switch center-B 660. A backup of EM DB-A 610 is maintained in EM DB-B 630, which resides on EM server-B 625. In one embodiment of the invention EM relies on the DGM&S OMNI platform to provide the architecture for active/backup fault resilience and switchover of processing control. Also in this embodiment, Sun E6000 servers are utilized at both the active and backup sites. As those skilled in the art know, other server hardware and methods for achieving fault resilience are possible.

Similarly, one active master SMS database server is located in Switch center-A 650 (e.g., in Chicago), with one backup master SMS database server, such as Master SMS DB server-B 635 located in Switch center-B 660. Embodiments of Master SMS DB 330 include an active master SMS database (e.g., Master SMS DB-A 620) and backup master SMS database (e.g., Master SMS DB-B 640). Thus, a backup of Master

SMS DB-A 620, which resides on Master SMS DB server-A 615, is maintained in Master SMS DB-B 640, which resides on Master SMS DB server-B 635. In one embodiment of the invention, Unix utilities and standard backup features of relational database management systems provide the architecture for active/backup fault resilience and switchover of processing control. Also in this embodiment, Sun E6000 servers are utilized at both the active and backup sites. As those skilled in the art know, other server hardware and methods for achieving fault resilience are possible.

As with the active EM and master SMS database servers, those skilled in the art will appreciate that other hardware configurations could support the backup EM and master SMS database servers. Further, other geographic locations for the backup servers are possible. For example, the backup servers could be at Switch center-C 670 or, as an another alternative, the backup servers could be at the same location as the active servers.

VASP PRODUCTION ENVIRONMENT

ATM Network Configuration Three primary switching centers (NY, Los Angeles, Chicago) and five remote switching centers exist in the network. Each switching center contains a BPX switch, which is linked to the MFS Worldcom network, in a ring of bandwidth, through a BPX switch at both a collocate space and a Worldcom POP. The three main backbone trunks between the primary switching centers exist as pre-provisioned PVCs across the network. Each Access Tandem switch is serviced by one of the 600E switches, such that the 600E performs the routing for all of its call traffic. Calls that are routed between primary switching centers are carried over one of the backbone trunks, while those that originate and terminate within the same switching center are not.

The SS7 traffic on the network is routed by a mated pair of STPs located in Chicago and New York. Messages routed between switching centers is carried over the backbone trunks, on a PVC that is dedicated to SS7 traffic, while all other messages are carried over an external SS7 network.

The EM components are distributed such that an active MEM 105/ TEM 115 exists in the Chicago switch center, and a backup MEM 105/ TEM 115 exists in the New York switch center. Master SMS DB 330 is also deployed in an active/backup configuration, with the active database in Chicago and the backup in New York.

Communication Architecture

The following describes an embodiment of the invention, with reference to FIG. 8. Each primary communication network switching center (e.g., Switch center-A 650) links into a Worldcom POP (e.g., POP 813) through a collocate space 815. BPX switches (e.g., ATM node 521 and ATM node 529) are located in each of the three switching centers (e.g., Chicago, Los Angeles, New York) and in collocate space 815 and the Worldcom POP (e.g., POP 813). An OC3 (e.g., optical 155 Mbs) connection (e.g., transport trunk 557) runs between the switching center and collocate space 815, and a

DS3 connection (e.g., transport trunk 557) runs between collocate space 815 and the Worldcom POP (e.g., POP 813). Bandwidth for these connections over the Worldcom ring (e.g., ring 811), are pre-provisioned into PVCs to provide the main ATM backbone trunks for carrying the call traffic and to support LAN/WAN and SS7 communication between the switching centers.

The communication network switching centers and the collocate spaces contain a number of AXIS shelves (e.g., SAMs 519 and SAMs 531) with DS3 connections (e.g., transport trunk 557) to a BPX switch (e.g., ATM node 521 and ATM node 529). The AXIS shelves (e.g., SAMs 519) in the switching centers have several DSl connections (e.g., access-exit trunks 553) into a 600E switch (e.g., SSPl 517), while the AXIS shelves (e.g., SAMs 531) in collocate space 815 have DSl connections (e.g., access-exit trunks 553) to a multiplexer (e.g., MUX 809). The MUX 809 functions to group the DSl connections into DS3 connections to the Access Tandem (e.g., AT 515 and AT 535) switches that are serviced by the switching center. The BPX and 600E switches and the AXIS shelves are pre-provisioned to create access trunks, such that a CIC on the Access

Tandem will map directly to a CIC on the 600E. Additional pre-provisioning is performed such that a CIC on the 600E maps directly to a CIC on a 600E in another switching center, with the backbone trunk management to support this path being controlled dynamically by VASP system components. The STPs (e.g., STP-B 503) in the switching centers (e.g., Chicago and New

York) route the SS7 message traffic between the Access Tandem and 600E switches and MEM 105 components. These messages are received either from a gateway to the SS7 network 220 or over the network, through a PVC dedicated to SS7 traffic between the switching centers. SS7 links 551 connect STPs (e.g., STP-B 503) to SS7 network 220, 600E switches (e.g., SSPl 517), and EM server-A 605. An ATM connection provided by an AXIS shelf (e.g., SAM 519) provides the transport for SS7 link 551. A dedicated WAN, including router 805 and hub 807, supports communication between an active EM in Chicago and a backup EM in New York, as required for fault resilience by the distributed OMNI architecture. An additional, and logically separate, WAN is in place between TEM 115 and the BPX switches for ATM route set up and tear down, and between VASP system components and Master SMS DB-A 620 for transaction logging and data synchronization. OAM&P functions performed at a Network Control Center 801 are enabled by User interface 472 (accessed at client 470) and WAN TCP/IP links and LAN TCP/TP links. TCP/IP paths 120 connect Network Control Center 801, router 805, hub 807, and ATM node 521. TCP/IP paths 120 also connect hub 807 to Master SMS DB Server-A 615 (including Master SMS DB-A 620) and to EM server-A 605 (including EM DB-A 610). Access to Master SMS DB-A 620 is supported by a TCP/IP WAN, using Data Access Layer 160 to provide messaging and middleware.

It will be appreciated by those skilled in the art that further embodiments of the invention may be made without departing from the spirit and scope of the invention as described herein. Such embodiments are intended to be within the scope of the appended claims.

Claims

What is claimed is:

l. A method for providing enhanced communications services in conjunction with a communications network, comprising the steps of: collecting information in real-time concerning a transaction traversing the network; storing the transaction information in a database; and accessing the stored information from the database in real time.

2. The method of claim 1 , further comprising the step of analyzing a portion of the stored information in real-time.

3. The method of claim 1 , wherein the collected information relates to an entire transaction, from beginning to end.

4. The method of claim 1, wherein the stored information includes all of the information contained in Call Detail Records.

5. The method of claim 4, further comprising the step of creating a Call Detail Record from the stored information.

6. The method of claim 2, wherein the stored information is analyzed in order to effectuate the maintenance of the network.

7. The method of claim 2, wherein the stored information is analyzed in order to effectuate billing administration.

8. The method of claim 7, wherein the stored information is analyzed to determine the billing for an entire transaction.

9. The method of claim 8, wherein the step of analyzing the stored information to determine the billing for an entire transaction is done immediately after the transaction occurs.

10. The method of claim 2, wherein the stored information is analyzed to determine real-time usage of the network resources.

11. The method of claim 10, further comprising the step of re-routing overflow traffic on the network based on the analyzed information.

12. The method of claim 1, wherein the database is a normalized relational database.

13. The method of claim 2, wherein the information is analyzed in order to effectuate network engineering.

14. An apparatus for providing enhanced communications services in conjunction with a communications network, comprising: a network for carrying transaction data; an element manager coupled to the network for collecting, in real-time, information concerning the transaction as it traverses the network; a database linked to the element manager for storing the information collected by the element manager; and an interface for accessing the stored information from the database in real-time.

15. The apparatus of claim 14, further comprising a processor coupled to the interface for analyzing the stored information.