WO1998052321A1

WO1998052321A1 - Improved telecommunications systems and methods

Info

Publication number: WO1998052321A1
Application number: PCT/US1998/009697
Authority: WO
Inventors: James M. Macmillan
Original assignee: Evolving Systems, Inc.
Priority date: 1997-05-12
Filing date: 1998-05-11
Publication date: 1998-11-19
Also published as: AU7383498A

Abstract

Telecommunication system comprises a plurality of platforms (12, 14, 16, 18), each of which includes a defined functional responsibility. A plurality of components (20) are selectively attachable to the platforms. The components (20) of each platform operate together to perform various task within the functional responsibility of the platform. One of the platforms (18) is adapted to be placed in communication with the network element (22) to allow configuration information to be transmitted from the platform (18) to the network element (22).

Description

IMPROVED TELECOMMUNICATIONS SYSTEMS AND METHODS

CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation in part of, and claims the benefit of, U.S. Provisional Patent Application No. 60/046,240, filed May 12, 1997, the complete disclosure of which is herein incorporated by reference.

BACKGROUND OF THE INVENTION This invention relates generally to the field of telecommunications, and in particular to Operational Support Systems and methods for their use.

Operational Support Systems (OSS) are a broad category of systems that support planning, provisioning, installation, maintenance, operation, and engineering and administration of network elements, networks and services.

Additionally, OSSs include systems to negotiate orders, and to rate and bill for usage of services.

Factors such as deregulation, competition, consolidation, convergence and globalization are changing the nature of the telecommunications industry. The result of these factors is that telecommunication companies are finding it increasingly more important to reduce costs, deploy existing products more quickly, and offer more services to maintain and grow market share. The flexibility, scaleability and usability of OSSs directly influences the ability to offer services quickly and cost effectively.

Many existing service providers, such as RBOCs , find that their existing OSSs are too fragile, constraining, and ccstly to meet the demands of a competitive marketplace. Hence, it would be desirable to provide both new and existing service providers with an improved operational support system to enable them to offer their services conveniently, quickly and cost effectively. OBUECTS OF THE INVENTION OSS users include network providers and managers (connectivity providers), network designers and developers, retailers, content providers, service providers and managers, service subscribers (brokers) , service users (consumers) , and operators and administrators. It would be desirable if all such users could share a common user experience when interfacing with an OSS. More particularly, it would be desirable to provide the OSS with intelligent components and data models to integrate heterogeneous elements into a concrete, homogenous view. It would further be desirable if such interfaces were aware of new services, management functions, or resources installed into the system. Such components should also be able to discover, obtain and display an editor or viewer associated with the new service, management function or resource. It would also be desirable to incorporate artificial intelligence to evaluate work in progress and offer suggestions to the user to insure that the work is complete and accurate. Further, it would be desirable if tasks performed within the OSS were configured to be straightforward, consistent, and repeatable. In this way, the learning curve for interfacing with the system would be greatly reduced. Further, the need for systems specific experts would be reduced, as well as the time to implement a new service, management function or resource.

It is another object of the invention to provide an OSS with a single enterprise data model . Such a model should be layered and hierarchial and be configured to support data abstraction and minimize dependency between layers in the model. It would further be desirable if the data model were template based to facilitate introduction of new data models. Further, such a configuration should allow for the rapid introduction of new kinds of data models, to provide a single, common view of data models, and eliminate synchronization inaccuracies between users of the data.

It is still a further object of the invention to provide an OSS with the ability to reflect the service provider's business strategy, policies and standards in work flow and business rules. Also, the ability to rapidly change and validate work flow and business rules in response to changes in strategy, policies and standards should be provided. In another aspect, it would be desirable to collect metrics and measurements throughout the system. The OSS should also support separation and interoperability between business domains and authorities. Such features should allow the service provider to be differentiated in their marketplace as well as to provide control and accountability.

In still a further object, it would be desirable if the invention provided open, standards compliant architecture which includes intelligent (domain aware) components that discover and utilize services, management functions and data models provided by other components. The invention should also support distributed processing and "plug-and-play" scaleability. It would further be desirable if the invention provided a layered, open architecture that supports scaleability through process and data abstraction, permits multi-vendor solutions, and permits integration of different technologies, as well as supporting piece wise replacement of legacy systems. In this way, the invention will allow for rapid introduction of new services and management functions, as well as permitting vendor competition.

SUMMARY OF THE INVENTION The invention provides exemplary systems and methods for overcoming or greatly reducing the drawbacks of prior art telecommunication systems, as well as providing solutions to the objects of the invention. In one exemplary embodiment, a telecommunication system is provided which is useful in connection with at least one network element. The system comprises a plurality of platforms, each of which has a defined functional responsibility. A plurality of components are selectively attachable to the platforms. The components of each platform are configured to operate together to perform various tasks within the functional responsibility of the platform. Further, one of the platforms is adapted to be placed in communication with the network element to allow configuration information to be transmitted from the platform to the network element. In this way, the telecommunication system may be arranged in functional layers (according to the platforms) , with the platforms functioning as a unifying element within each layer to provide common services to its components, to orchestrate work between components, as well as to provide standards, rules, and principles for component granularity and location. In turn, the components are provided to perform the actual work within the platform.

In one particular aspect, a gateway is further provided to interconnect at least some of the platforms . The gateway includes any electronic interface to place the interconnected platforms in communication with other service provider systems. In this way, the system of the invention may easily interface with the systems of other carriers. In a further aspect, mediators are provided to interconnect each of the platforms. The mediators include code to translate information which is transmitted between platforms. In this way, the "view" of a domain may be translated between the platforms .

Preferably, the defined functional responsibilities for the platform will include customer service management, network service management , network management , network element management and the like. One advantage of the invention is that a variety of components may be selectively placed into the platforms. Such components may include, for example, network management systems, service order management systems, order entry systems, monitoring systems, rating and billing systems, inventory systems, work force administration systems, rating systems, capacity planning systems, network operation systems and the like. Preferably, each platform will include a bus to channel information between each of the components in the platform. In a specific aspect, one of the platforms comprises a network element management platform which is adapted to interface with a plurality of network elements, such as STPs, SCPs, SSPs and the like. The system will also preferably further include a data model which is placed in communication with at least some of the platforms. The data model includes code for providing the state, attributes and behavior of telecommunications domain objects. In this way, various information regarding telecommunications domain objects will be accessible to the components when performing a task. In a further aspect, at least one of the platforms will include at least one user interface, such as graphically user interfaces to allow a user to access the information within the system. The invention further provides an exemplary method for providing telecommunication services. According to the method, a plurality of platforms are provided which are each assigned a functional responsibility. At least one component is selectively placed into each of the platforms so that the component may perform a task within the functional responsibility of the platform. In this way, components in the platforms translate the services as understood by the consumer of the service into the information necessary to configure a network and network elements to deliver the service.

Each of the platforms is preferably configured to provide common services to each of its components to allow the components to perform their given tasks. For example, the platforms will preferably facilitate work flow between the components to allow the components to cooperate together to perform various tasks within the functional responsibility of the platform. Such functional responsibilities may include, for example, customer service management, network service management, network management, network element management and the like. The platforms will also preferably be configured so that they will be able to determine the type of component upon placement into a platform. In this way, a variety of components may be easily introduced into a platform.

As one example, the components may be selected to provide a local number portability task. The transmitted information will then comprise call routing information which provisions the network elements. In another aspect of the method, at least some of the telecommunications information will preferably be translated when transmitted between platforms.

Telecommunications information which is transmitted to another service provider's telecommunication system will preferably also be translated. Conversely, telecommunications information received from another service provider will preferably be translated before being transmitted to the platforms . Conveniently, information from the components and business rules associated with the operation of the components may be accessed with a graphical user interface. In still another aspect, the state, behavior and usage information relating to telecommunications domain objects will preferably be transmitted to at least one of the platforms to assist the components in performing a task. Such information may include, for example, network element requirements, facilities requirements, work force requirements, and the like that are needed to accomplish a task. In still yet another embodiment, an exemplary method is recited for providing telecommunications services. According to the method, a telecommunication service is ordered and entered into an order entry component that is interfaced with a service management (customer facing) platform. A data model is queried through the service management (customer facing) platform to determine if the product is available for order. If available, information relating to the order is transmitted to a service management (network facing) platform having an order management component. The data model is again queried through the service management (network facing) platform to determine the particular resources that will be required to service the order. Information relating to the order is then transmitted to a network management platform to determine if the particular resources are in fact available to service the order. Finally, information relating to the order is transmitted to network element management platform to provision or configure the service on a network element. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates a conceptual model of an exemplary telecommunications system according to the invention. Fig. 2 illustrates a schematic view of one embodiment of an exemplary telecommunications system according to the invention.

Figs. 3A-3D illustrate four types of components that may be coupled to the telecommunications systems of Figs. 4-6. Fig. 4 is a schematic view of an embodiment of a telecommunications system illustrating various products and services which are coupled to the system according to the invention.

Fig. 5 is a detailed view of a service management (customer facing) platform and a service management (network facing) platform of a telecommunications system according to the invention.

Fig. 6 is a detailed view of a service management (customer facing) platform and a service management (network facing) platform of a telecommunications system to which a local service request management product is coupled according to the invention.

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS The invention provides exemplary telecommunication systems and methods for their use. The systems comprise an OSS having layers of platforms and components that may be selectively interfaced with each of the platforms to perform various tasks. The OSS of the invention is based on telecommunication management network (TMN) architecture that organizes service and management functions into layers. Each layer of the OSS abstracts and comprehends the use of the services and management functions available in the next lower level, enabling scaleability and flexibility by promoting data and process abstraction.

According to the invention, OSS applications comprise collections of components that provide services and ^" management functions necessary to automate telecommunications business processes. The components are organized into the layers of the TMN architecture and collaborate to perform a kind of task. Further, such applications are typically not independent, i.e., the components of an application may rely on other services and management functions which in turn are provided by other components within the same layer. To facilitate such cooperation, the OSS of the invention includes a management platform within each layer to establish interface and functionality standards, to apply business rules and logic, and to provide common services to all components within a layer.

The OSS of the invention further includes an enterprise data model that maintains information and resource models (products, services, equipment and the like) that are accessible by multiple OSS applications or decision support systems. The enterprise data model is hierarchial in the same manner as the TMN architecture such that the data models available to components within a level are at the appropriate level of abstraction. The OSS of the invention further includes integration with work flow managers to provide a flexible mechanism to define business processes. Optionally, integrated user interfaces may be employed to tie diverse information into a common presentation for a user.

A conceptual model of an OSS 8 is illustrated in Fig. 1. As shown, the various platforms or software buses are arranged into layers which conform generally to the TMN layers, i.e. a service management layer (customer/retail), a service management layer (network/wholesale) , a network management layer, and an element management layer. The various platforms may communicate with each other through a mediator. Further, the platforms may communicate with external systems, including other service provider systems, through adapter components, such as fax, e-mail, EDI, and the like. The platforms are configured such that various OSS application components and/or common service components may be coupled to the platforms. Information from each of these components may be accessed and/or transferred through the platforms and mediators. Further, each platform includes an enterprise data model . This enterprise data model includes information model service components and domain model components. The service components can include databases for storing data received or extracted from other components in a relational representation, report tools and facilities, and the like. The domain model components include services that model entities involved in telecommunication business processes for operations, planning and engineering, service provisioning, and customer care and billing. These entities, which are presented by objects, model both state (attributes) and behavior, and can include, for example, customer, product, service, order and network elements.

As previously mentioned, the platforms provide access to common software services for applications through a software bus, using Application Programming Interfaces (APIs), to facilitate efficient development and integration of OSS application components for service providers into a common run-time environment. This is accomplished by providing easy access to reusable common services that allow application development efforts to focus on improved functionality rather than the underlying common processes of such applications. The published APIs for the common software services also facilitate adaptation of existing applications to this common run-time environment which, in conjunction with the enterprise data model, provides consolidated information sharing and reporting with various products, including products offered by other application developers (vendors) .

The software bus thus enable various OSS application components, which are appropriately compliant with published standards and APIs, to access and utilize common software service components, as well as to utilize the enterprise data model to retrieve information from and share information with other applications within the OSS. Further, such information may be received from or shared with other OSS's and external applications. The software bus preferably enables layering of software applications in accordance with the ITU-T TMN architectural modal and utilizes a widely accepted or industry standard Object Request Broker, e.g. CORBA-compliant .

Referring now to Fig. 2, an exemplary embodiment of an OSS 10 will be described. OSS 10 comprises a plurality of platforms, including a service management (customer facing) platform 12, a service management (network facing) platform 14, a network management platform 16, and a network element management platform 18. Interfaced with the various platforms are different components 20 which are responsible for performing various tasks as described in greater detail hereinafter.

The various platforms are the unifying element within each layer of OSS 10. As such, the platforms comprise various software services, middleware, frameworks and standards. Each of the platforms has a defined functional responsibility. For example, platform 12 is responsible for customer facing service management. Platform 14 is responsible for network facing service management, while platform 18 is responsible for network management. Finally, platform 18 is responsible for network element management. A plurality of network element management systems 22 are interfaced with platform 18 to assist in provisioning or configuring various network elements 24.

The specific functional responsibilities of the platforms may include, for example, the collection and evaluation of metrics and measurements, and the collection and evaluation of alarms, status, and error information. The platforms may further provide access to components 20 and to resources from an enterprise data model 26 at the platform's level. The platforms further encapsulate and enforce business rules, e.g., validation and verification, applicable to a platforms level. The platforms further provide communication (transport) between components 20 and data model 26 at the platform's level. Further, the platforms enforce layered architectural principals by defining standards for the construction of components 20 for each layer of OSS 10. The platforms further provide APIs, protocol stacks, frameworks, and the like. The platforms are also employed to produce standards for implementation, integration and migration of components 20 and data model 26 into the platforms.

The platforms are further configured to provide a variety of common services including: security, persistence, transaction management, naming and directory services, underlying protocol transparency, alternate messaging routing, resource discovery, and the like. Such platforms further provide standard interfaces or gateways to work flow management and to data model 26. Such platforms also provide access to services and resources for presentation, i.e., user interfaces .

Another specific function of the platforms is to provide for work flow management. Work flow provides a mechanism to orchestrate a wide variety of actions to accomplish a task. This is particularly important when a situation requires human intervention. Hence, work flow provides a mechanism to hand-off and track a task assigned to an individual or organization. Additionally, work flow also provides a mechanism for defining and implementing business processes, particularly in regard to handling exception cases.

Accessible through each platform, each component 20 will preferably have an API that permits integration with a work flow manager. In instances where work flow management is not required, the platform will preferably orchestrate work in accordance with imbedded rules.

The application areas provide an organizing principle for the development and integration of components that perform a kind of task. Components within each application do not necessarily function in isolation, rather they may rely on services and management function provided by other components within the layer. Such application areas preferably include operations, planning and engineering, service provisioning, and customer care and billing. The operations applications can include, for example, Advanced Intelligent Network (AIN) services, human resources, payroll, financials, network operations and fault management, field service and repair, security and work force management, and the like. Planning and engineering is focused on network design, decision support, product planning and development, and the like. Some areas of service provisioning include configuration management, inventory management, provisioning, service activation, service order processing and the like. Finally, customer care and billing includes applications for billing, customer support and service, pricing, rating, sales and marketing, and the like.

The following table lists examples of applications within each category mapped to the TMN layers.

TABLE 1

A wide variety of components 20 may be provided to accomplish the various tasks required to provide the OSS services. Exemplary components which may be used with the invention include: network management systems, service order management systems, order entry systems, monitoring systems, billing systems, inventory management systems, work force administration systems, rating systems, capacity planning systems, network operations systems, service provisioning management systems, and the like. Exemplary network management systems, service order management systems and order entry systems are described in copending U.S. Provisional Applications Serial Nos. 60/033,421, 60/033,422 and

60/033,423, all filed on December 24, 1996, and U.S. Patent Application Serial Nos. 08/907,323, filed August 6, 1997 and 08/906,751, filed August 6, 1997. The complete disclosures of all these applications are herein incorporated by reference. Enterprise data model 26 provides a single (logical! repository of shared data and resource models used in OSS applications and decision support systems. The shared data and resource models are preferably hierarchial in the same fashion as the TMN layers providing the appropriate level of abstraction for components within a layer. The following table illustrates the kinds of models that may be present within each layer of the TMN architecture.

TABLE 2

The enterprise data model is configured to provide the current state, behavior and usage constraints. Such information is made available to the components 20 to perform their various tasks.

To enhance useability, selective user interfaces 28 may be provided. Due to the nature of the OSS architecture, a task or a similar set of tasks may involve multiple components and resources. Interface 28 provides a common framework to unite the presentations of multiple components and to data model 26, providing a common look and feel through consistent presentation, navigation and help.

Positioned between some of the platforms is a mediator 30 which includes code to translate information which is transmitted between the platforms. In this way, a particular "view" of a domain may be translated between the various platforms. OSS 10 further includes a gateway 32 which interconnects other service provider systems, such as system 34, with platform 12, and acts as a mediator between platforms 12 and 14. An exemplary method for employing OSS 10 to provide various telecommunications services will now be described. In a typical application, a customer will order a telecommunication service which will be entered into one of components 20 in platform 12. Such a component will preferably be an order entry component which is employed to query data model 26 through platform 12 to determine of the ordered product is available for order. If available, information relating to the order is then transmitted to platform 14, which will preferably include an order management component. The order management component will then query data model 26 through platform 14 to determine the particular resources that will be required to service the order. Upon determining this information, the information will be transmitted and translated to network management platform 16 via mediator 30. Platform 16 will include various components which are employed to determine if the particular resources are actually available to fulfill the order and the steps necessary to fulfill the order. For example, the components on platform 16 may comprise a service activation component, an inventory component and a work force component. If everything is in order, the steps determined to fulfill the order are executed and information relating to the order is then transmitted to network element management platform 18 via mediator 30 so that the service may be delivered or configured by network elements 24.

Hence, OSS 10 provides users with enhanced flexibility by allowing a wide variety of components to be inserted into the various platforms in order to accommodate various services provided by service carriers. Over time, as new services are added or old services are replaced, OSS 10 is able to easily accommodate such changes by simply allowing different components and objects to be replaced. Each of the platforms will preferably include middleware that will be able to determine the type of added component so that it may easily be configured into the system. Hence, both scaleability and flexibility are provided to allow service providers to effectively compete in the telecommunications market. Referring now to Figs. 3A-3D, various components which may be coupled to the telecommunications systems of Figs. 4-6 will be described. Shown in Fig. 3A is an OSS application component 40. Figs. 3B-3D illustrate an adapter 42, a service or facility 44, and a domain object resource model 46, respectively. OSS application component 40 represents a software application component which implements one or more activities of a business process. Adapter 42 is a component that allows an OSS to communicate externally, such as with another service provider's system. For example, adapter 42 may support protocols such as facsimile, e-mail, EDI, FTP, CMIP, and the like. Service or facility component 44 is a component that provides functionality common to application components. Components 44 are common so that they can be shared by different products. Domain object resource models 46 are services which model entities involved in telecommunication business processes for operations, planning and engineering, service provisioning, customer care and billing, and the like. These entities, represented by objects, model both state (attributes) and behavior.

Exemplary domain object resource models 46 include customer, product, service, order, and network elements.

Shown in Fig 4. is one particular embodiment of an OSS 50 and is included to illustrate various OSS application components which may be coupled to the various platforms. For example, an order entry component 52 is a component which facilitates the entering of various order information into the system as described in greater detail hereinafter. A service management layer (network facing) platform 54 includes the following components: a local service management component 56, an order management component 58, a mutual compensation rater component 60, a mutual compensation biller component 62 and a mutual compensation reconciliation component 64. The order entry component 52 is coupled to a service management layer (customer facing) platform 53. Exemplary uses of these components are described hereinafter.

Coupled to a network management layer platform 66 fs a service activation component 68, an inventory management component 70, a workforce management component 72 and a usage mediation component 74. Finally, coupled to an element management layer platform 76 is a usage collection component 78. The various components coupled to platforms 53, 54, 66 and 76 are particularly useful in facilitating a local service request and for the exchange of billing information between different service providers as described in greater detail hereinafter. As such, it will be appreciated that the various components coupled to OSS 50 are merely representative of the various components may be coupled to the OSS to provide various services to customers.

OSS 50 further includes various mediators which provide access control, translation and filtering of data between the various platforms. An output manager 80 is further provided and is coupled to various adapters which allow for external communication. Output manager 80 is similar to the Inter-SP Gateway of Fig. 1 and gateway 32 of Fig. 2. Exemplary adapters which may be coupled to output manager 80 include an EDI adaptor 82, an e-mail adaptor 84, a fax adaptor 86, a FTP adaptor 88, as well as other adapters, such as adaptor 90 which are useful in transferring data from OSS 50 to another OSS.

Coupled to each of the platforms via an information bus are one or more domain object resource models. For example, coupled to platform 53 is a customer model 82, a product model 84 and an order model 86. Customer model 82 is a service that is employed to store information associated with a customer and provides a set of screens on a user interface computer 87. Such screens, in turn, are employed to solicit and record information regarding a customer. Product model 84 includes information on the various telecommunications products that a customer may order. Order model 86 cooperates with customer model 82 and product model 84 and is employed to produce a series of screens on computer 87 which solicit and record information necessary to fulfill a particular order for a customer.

Coupled to platform 54 is a service provider model ^~ 88, and order fulfillment model 90, a service model 92 and a local service request^" model 94. Service provider model 88 includes information regarding which services are offered by which service providers and typically includes the intraconnection agreements between service providers . Service model 92 contains information on the services that comprise the products, as well as the tasks and dependencies that are necessary to deliver the service. Order fulfillment model 90 is created by order management component 58 to contain a list of tasks and dependencies necessary to fulfill an order. Order management component 58 uses information from order fulfillment model 90 and appropriate service models 92 to create this list. Local service request model 94 is employed to store information from customer model 82, order model 86, service provider model 88 and service model 92 so that a local service request may be sent to another service provider.

Coupled to network management platform 66 is a network topology model 96, a network element model 98, a service elements model 100, a workforce model 102, a physical inventory model 104 and a virtual inventory model 106. Physical inventory model 104 represents a collections of items that comprise the physical plant (e.g., cable pairs, communication cards and the like) . Virtual inventory model 106 includes a collection of virtual resources available within the network (e.g., bandwidth). Resource models 96-106 work in cooperation with components 68-74 on network management layer platform 66 to assist in fulfilling a particular order. For instance, service activation component 68 is provided to assist in configuring or provisioning one or more network elements 108 to provide the service requested by the customer. Inventory management component 70 identifies the resources, physical and virtual, that are necessary to deliver the requested services and adjust the inventory levels appropriately. Once the resources have been identified, this may spawn additional tasks to order replacement stock, notify facilities planning of band width exhaustion and the like.

Work force management component 72 dispatches technicians to install hardware, lay cable or otherwise modify the physical ^" plant. Usage mediation component 74 is employed to normalize call records received from various network elements into a common format .

Resource models 96-106 include data that may be accessed by components 68-74. For example, network topology model 96 includes a description of the interconnection of network elements and their location. Network element model 98 includes information on the actual network elements 98 that are available for use. Service elements 100 include information on the elements that comprise a service. A service element may be reused in one or more services.

Workforce model 102 includes information on the needed and available technicians which will install or modify the hardware or physical plant to deliver the product. Physical inventory model 106 includes a list of available inventory as well as required inventory for a particular product. Virtual inventory model 106 includes a list of available virtual inventory as well as the needed inventory required to implement a given product .

Coupled to element management layer platform 76 is a functional entity model 110. Functional entity model 110 includes detailed information necessary to provision a service element on a particular network element. In turn, such information is used by the network element management components to provision a network element . Usage collection component 78 collects call records from network elements.

Referring now to Fig. 5, one particular arrangement of an OSS 120 will be described. For convenience of illustration, only a service management layer (customer facing) software platform or bus 122 and a service management layer (network facing) software bus or platform 124 are shown. It will be appreciated that a network management layer software bus or platform and an element management layer software bus or platform which are similar to those previously described herein will be coupled to OSS 120 by a mediator in a manner similar to that previously described. OSS 120 includes an output manager 126 to which various adapters may be coupled similar to the embodiment previously described in Fig. 4. Also similar to the embodiment of Fig. 4, a variety of domain object resource models are coupled to the various software buses. Further, various components may be coupled to software buses 122 and 124 similar to the other embodiments described herein. Each of the components preferably includes a server to facilitate the transfer of information between the component and the software bus as is known in the art. Conveniently, a Legacy adaptor 128 may be coupled to software buses 122 and 124 to provide communication to external applications 130. For example, such external applications may include service order entry systems, trunk group assignment systems, such as SOAC and TIRKS, available from Bellcore. Coupled to layers 122 and 124 are a variety of services or facilities. For example, a user interface tool 132 provides various tools and facilities to support the creation and running of human interfaces 134, such as GUIs, for various OSS applications. User interface tools 132 preferably include client service standards and models which provide documentation of standards and conventions for creating and partitioning client-server applications. For example, these standards may include detailed descriptions of how thin a client should be, including descriptions of what function should normally be performed in the server and what functions in the client. User interface tools 132 preferably also include look and feel standards on models which provide documentation of look and feel standards, including GUI style guides. They may also include code frameworks that implement the standards, or support easy implementation. User interface tools 132 may further include tools and facilities to support the integration of test tools, and for testing GUIs. Tools and facilities may also be included to support integration of on-line help and documentation into application GUIs. Further, tools may be provided to support printing of any GUI screen, as displayed, along with any data on the screen. A distribution service 136 includes a directory service to provide the capability to locate services, facilities and other components, either by name or by services offered. As one example, CORBA Trader and CORBA Naming services provide directory services and may be used with the invention. Distribution service 136 further allows for the determination of what services are wanted based on incomplete information about that service. For example, it may accomplished by allowing access to the CORBA Interface Repository.

A security service 138 is further provided to verify the identity of a user by comparing a user ID and password with previously stored account information. The security service further uses information provided by an account management service (described hereinafter) to verify that a user has the appropriate privileges to access an application. Security service 138 may be based on existing CORBA security products .

Transaction management service 140 synchronizes a unit of work, called a transaction which involves multiple components (applications, facilities or services) . In this way, all actions against individual components must be successful in order for the transaction to be successful. Any action that fails will cause all actions to be rolled back to restore to a previously known state. Transaction management service 140 may be based on a CORBA Object Transaction Service product .

A business process management service 142 includes tools to aid in the definition, modification, execution and tracking of work processes. It also allows a user to define the order in which work will be done in response to given inputs or events. It further requires that the work being performed is divided into units that can be assembled in workflow. This service may be based on Workflow Management Consortium (WfMC) standards.

Further coupled to layers 122 and 124 is a process management service 144 which includes tools and other facilities to support the administration of the pieces of the processes, data and other parts of individual applications. For example, it may include facilities to start, stop, restart and otherwise manage the processes that make up an application. It also includes the ability to configure those processes, including the restart characteristics. Process management service 144 further includes facilities to monitor aspects of an application, including the status of the processes. It may further extend the process management capabilities listed above to distributed applications, where the processes and data of an application are distributed across the network.

A tunable management service 146 is included to provide facilities, including GUI, to browse tunables and sets of tunable values used to configure applications. It also includes facilities to effect updates at run time.

A deployment service 148 is provided to support aspects of the deployment process. For example, this may cover deployment of OSS applications (i.e., applications built on the OSS framework) to the purchasers of those applications. However, the same tools are also applicable to the deployment of releases of the OSS itself. For instance, deployment service 148 may be configured to support the initial installation of a new product by providing tools which aid in the installation process, beyond what is provided by standard UNIX tools. It also allows for the installation of upgraded versions of existing products. Deployment service 148 further provides support for packaging of releases, as well as in providing tools to aid in creation of patch releases. A patch may not contain the entire system, but only patches those few files that need to be patched to address a specific problem. Further, deployment service 148 may include tools to aid in organizing and managing multiple simultaneous releases or patches. It may further include tools to support and automate aspects of the distribution of releases for patches for applications.

An exception handling service 150 provides generic services to deal with exceptional conditions encountered at run-time. Although not all exceptional conditions are necessarily errors, this preferably includes the capability to define levels of error criticality. Exception handling service 150 may provide access to the generic log management capabilities (described hereinafter) to manage the error log. It may further include an object model for exceptions. By defining a hierarchy of exiting exception class for use by OSS applications, functionality is allowed to be encapsulated and reused. Further, exception handling service 150 includes an object model for errors. A local time support service 152 includes tools to support the coordination of data and processes across multiple time zones. For example, this might include the ability for a GUI to display the local time of a time-stamp on a data object regardless of where the time-stamp was recorded. A log management service 154 is a generic feature that provides tools and facilities to manage any log maintained by the system. For example, it may provide a process of initially recording events for later use. It may also provide tools, typically GUI-based, to allow a user to scan through a section of a specified log, searching for events that match a desired set of criteria. Further, an interface may be provided to the reporting subsystem that allows selected entries from the log to be output in a formatted way and redirected to some output device. Log management service 154 further includes tools and facilities for organizing the data in the log according to a user- specified set of criteria. Further, log management service 154 may be employed to send a formatted and human readable version of a log to different devices/locations. For example, this might support redirecting the formatted log to the terminal, a printer, a file, e-mail, fax or the like.

A login/logout service provides tools, including GUI and access to authentication information, to support logging in and logging out of users of the OSS applications. An account management service 158 provides administrative services for managing users of OSS applications. The service includes functions for creating, modifying, retrieving and deleting user accounts. It also provides for the administration of both authentication information e.g., user- ID and password) and authorization information, i.e., what the user is allowed to do. Account management service 158 further provides functions for creating, modifying, retrieving and deleting user group definitions. A trace log service 160 provides tools and facilities to support debugging and tracing application code. It also includes the ability to dynamically alter trace level at run-time. A report management service 162 provides tools and facilities to support the creation, scheduling and management of reports. For example, it may include a set of standard queries, or reports, for reporting on data associated with other OSS services and facilities. As one example, if a user administration function is provided, then the standard reports may include user, user group and related reports. Report management service 162 further includes tools and facilities to allow the user to define their own reports, and then schedule the reports, redirect output and otherwise treat the reports as additional standard reports. It further includes tools to support scheduling of reports to be run at a specified time, at a specified frequency, with specified selection and sort criteria. The tools also allow changing of the scheduled attributes of existing schedule reports, as well as cancellation of those reports. It further provides an interface to generic output redirection tools to support redirection of report output to a selected output device, such as a fax, system file, e-mail, a named printer, the user screen or the like. A data store management service 163 maps data received or extracted from other components into a relational representation. It further encapsulates and presents a standard interface to allow access to the relational data.

OSS 120 further includes an operational (Ops) data store 164 which is a temporary relational store to facilitate integration of existing (non OSS 120 compliant) systems. A data warehouse 166 is a long-term relational store that is optimized for reporting and decision support.

As mentioned above, output manager 126 is responsible for managing the process of transferring information to and from another service provider or trading partner. The adapters convert the information into required formats { e . g. , EDI, fax, e-mail and the like as specified by various standard bodies such as OBF and ECIC) .

Referring now to Fig. 6, a particular implementation of OSS 120 to support a scenario where a new customer requests a product and where another service provider provides one or more services that comprise the product will be described. For convenience of discussion, the elements in Fig. 6 which are essentially identical to those in Fig. 5 will use the same referenced numerals. It will further be appreciated that the particular components included within Fig. 6 are merely representative of one set of components that may be coupled to the OSS system, and that other components, including those previously described in connection with Fig. 4, may also be coupled to the various layers to provide other services . In the following scenario, a new customer requests a telecommunications retail product. Such a product is typically a group of packaged services such as caller ID, call forwarding, and the like. Such services are typically bundled together by service providers into the telecommunications retail product. The particular service is described by a set of service elements which are independent of network element . A service element in turn is described by a set of functional elements which are network elements specific. In the scenario, another service provider provides one or more of the services that comprise the telecommunications retail product, thereby requiring the generation and transmittal of a local service request (LSR) to fulfill the order.

To request the product, the customer contacts a customer service representative (CSR) . In turn, the CSR logs into an order entry component or application 170. The login screen seen by the CSR (and provided by login/logout service 156) collects the user ID and password from the CSR and passes the information to security service 138. In turn, security service 138 authenticates the identity of the CSR by comparing the user ID and password with those stored in a user account resource model 172. Once verified, security service 138 checks an access control list resource model 174 to authorized the CSR's access to order entry component 170. If authentication and authorization is successful, security service 138 notifies login/logout service 154 that the CSR is an approved user of order entry component 170. Otherwise, security service 138 notifies login/logout service 156 to deny the CSR access to the application. In this scenario, the CSR is an approved user of order entry component 170. Therefore, login/logout service 156 passes control to order entry component 170. In turn, order entry component 170 presents its main screen via terminal 171 to the CSR. Once logged in, the customer may contact the CSR to request a telecommunications retail product. The CSR determines that the customer is new, and uses the user interface provided by order entry component 170 to create a new instance of the customer model 82. In turn, the customer model 82 presents a series of screens to the CSR to solicit and record information from the customer.

To create an order, the CSR describes the available telecommunications retail products to the customer from descriptive information presented to the CSR by product model 84. The customer then selects a desired telecommunications retail product. The CSR selects the "take order" process from the user interface provided by order entry component 170. Order entry component 170 then creates an instance of order model 86 to hold the association between the customer and the selected product. Order model 86 presents a series of screens

(derived from customer model 82 and product model 84) to the CSR to solicit and record information necessary to fulfill the order from the customer. The products available to the customer is a function of the services that are available at the central office serving the delivery location.

Order entry component 170 then passes the completed order model 86 to an order management component 176. Order management component 176, using the service models 92 that comprise the telecommunications retail product, decompose the order into a set of tasks and dependencies necessary to fulfill the order and uses this information to create an instance of the order fulfillment model 90 (which also includes an association with the originating order model 86) . For the purposes of this scenario, another service provider provides one of the services to be delivered as part of the product. Although not described in reference to this scenario, it will be appreciated that other tasks will be necessary to fulfill the order, including service activation

(provisioning) , inventory management and work force management as previously described.

Order management component 176 passes order fulfillment model 90 to business process management service 142 to orchestrate the completion of the tasks. Business process management service 142 initiates tasks on various other applications and components, coordinating the work in accordance with the dependencies. As mentioned above, one task is to request another service provider to deliver a service to the customer. This task is passed to local service request management component 178, which, in turn, creates an instance of the local service request model 94 and populates the model with information from the customer model 82, order model 86, service provider model 92 (which contains interconnection agreement information) and the appropriate service model 92. Local service request management component 178 passes the local service request model 94 and service provider model 88 to output manager 126 via a mediator 180.

Output manager 126, using rules provided by service provider model 88, translates the local service request model 94 into the LSR format required by the service provider, and manages delivery of the LSR through the appropriate interconnection adaptor (e.g., the EDI adaptor) . In this manner, a LSR may be sent to another service provider to provide at least a portion of the service to the customer in a manner similar to that described in copending U.S Application Serial No. 60/068,166, previously incorporated by reference. Because various services will be provided by other service providers, a need will exist for exchanging billing information between the various service providers. Various components which may be used to implement a system for exchanging billing information are illustrated in Fig. 4. In particular, OSS 50 utilizes usage collection component 78, usage mediation component 74, mutual compensation rater 60, mutual compensation biller 62, and mutual compensation reconciliation component 64, among others, to exchange billing information with one or more OSSs. As described in greater detail hereinafter, usage collection component 78 stores call records, such as Automated Message Accounting (AMA) records, from the network elements. Usage mediation component 74 utilizes the raw data in the call records to create normalized call record objects. Mutual compensation rater 60 associates a fee structure with a call record. Mutual compensation biller 62 is employed to apply volume discounts, calculate taxes, and the like on an invoice basis to provide invoices for each account. Finally, mutual compensation reconciliation component 64 is employed to compare an incoming invoice received from another service provider via output manager 80, and an outgoing invoice to determine the financial obligations of each service provider.

Still referring to Fig. 4, an exemplary method for processing mutual compensation billing information will be described. For convenience of discussion, the service provider operating OSS 50 will be referred to as service provider A (SPA) . Typically, SPA will bill another service provider, referred to as service provider B (SPB) , for termination of calls originated by SPB's customers. To do so, SPB produces a record of every call they either originate or terminate. Each of these records has sufficient routing information to determine which originated calls were terminated by SPA. Similarly, SPA has the same information as regards to SPB. The method begins with the input of the call records from SPA's switches into usage collection component 78. This information can be automatically downloaded via an X.25 OSS connection or can be manually loaded via switch tapes. Usage collection component 78 continues to load the data provided by SPB to validate their invoice, typically provided in summary format via switch tape, or electronically via output manager 80. Usage mediation component 74 retrieves the raw data from usage collection component 78 through a mediator. Usage mediation component 74 creates call record objects out of the individual call records. Each of these call record objects is then stored in Ops data store 164 (see Fig. 5) .

A user then logs in through user interface 87 and completes the process of identification and authorization to allow the user to use the billing system as described in connection with the previous scenario. Once logged in, the user begins the billing application and enters SPB as the billing/billed entity.

Mutual compensation rater 60 and mutual compensation biller 62 retrieve the accounts receivable portion of the interconnection agreement for SPB from service provider model 88. Components 60 and 62 load the relevant rating information, volume discounts, and the like from service provider model 88, and access Ops data store 164 (see Fig. 5) to collect all records that represent terminated calls that were originated by SPB. Components 60 and 62 apply the rating information to the call records and create an electronic invoice to be paid by SPB.

Mutual compensation rater 60 and mutual compensation biller 62 further retrieve the accounts payable portion of the interconnection agreement for SPB from service provider model 88. Components 60 and 62 load the relevant rating information, volume discount, and the like, and access Ops data store 164 to collect all records that represent originated calls that were terminated by SPB. Components 60 and 62 apply the rating information to the call records and create an electronic invoice to be paid to SPB.

Mutual compensation reconciliation component 64 then compares the two invoices and determines which service provider owes more. The service provider which owes more will then be credited the amount owed to it and component 64 creates a bill for the remainder. This bill is forwarded to an accounts receivable or accounts payable portion of the service provider's accounting system as appropriate. The invention has now been described in detail for purposes of clarity of understanding. However, it will be appreciated that certain changes and modifications may be practiced within the scope of the appended claims.

Claims

WHAT IS CLAIMED IS: ^" 1. A telecommunications system for use with at least one network element, the system comprising: a plurality of platforms, each platform having a defined functional responsibility; a plurality of components selectively attachable to the platforms, wherein the components of each platform operate together to perform various tasks within the functional responsibility of the platform, and wherein one of the platforms is adapted to be placed in communication with the network element to allow configuration information to be transmitted from the platform to the network element.

2. A system as in claim 1, further comprising a gateway interconnecting at least some of the platforms, wherein the gateway includes an electronic interface to place the interconnected platforms in communication with other service provider systems.

3. A system as in claim 1, further comprising mediators interconnecting each of the platforms, wherein the mediators include code to translate information which is transmitted between platforms.

4. A system as in claim 1, wherein the defined functional responsibilities are selected from the group consisting of service management (customer facing) , service management (network facing), network management, and network element management.

5. A system as in claim 1, wherein the components are selected from the group of components consisting of network management systems, service order management systems, order entry systems, monitoring systems, billing systems, inventory systems, work force administration systems, rating systems, capacity planning systems, and network operations systems .

6. A system as in claim 1, wherein each platform includes a bus to channel information between each of the components.

7. A system as in claim 1, wherein one of the platforms comprises a network element manager platform which is adapted to interface with a plurality of network elements.

8. A system as in claim 7, wherein the network elements are selected from the group consisting of STPs, SCPs and SSPs.

9. A system as in claim 1, further comprising a data model which is in communication with at least some of the platforms, wherein the data model includes code for providing the state, attributes and behavior of telecommunications domain objects.

10. A system as in claim 1, wherein at least one of the platforms includes at least one user interface.

11. A telecommunications system, comprising: a plurality of platforms, each platform having a defined functional responsibility; a plurality of components selectively attachable to the platforms, wherein the components of each platform operate together to perform various tasks within the functional responsibility of the platform; and at least one network element in communication with one of the platforms to allow configuration information to be transmitted from the platform to the network element.

12. A method for providing telecommunications services, comprising: providing a plurality of platforms, wherein each platform is assigned a functional responsibility; selectively placing at least one component into each of the platforms, wherein each component performs a task within the functional responsibility of the platform; processing telecommunications information relating to a service with the components; and transmitting at least some of the processed information to networks responsible for the delivery of telecommunications services.

13. A method as in claim 12, wherein each platform provides common services to each of its components to perform the task.

14. A method as in claim 12, wherein some of the components comprise application components, wherein one of the components comprises a service component, and further comprising determining with the service component the type of application components upon placement of the application components into a platform.

15. A method as in claim 12, further comprising selectively placing a plurality of different components into each of the platforms, wherein the components in each platform cooperate together to perform various tasks within the functional responsibility of the platform.

16. A method as in claim 15, wherein the functional responsibilities are selected from the group consisting of service management (customer facing) , service management (network facing), network management, and network element management .

17. A method as in claim 15, wherein the component is selected from the group of components consisting of order entry systems, order management systems, service provisioning management systems, inventory management systems, and work force administration systems.

18. A method as in claim 15, wherein the components are selected to provide a local number portability task, and wherein the transmitted information comprises call routing information which provisions the network elements.

19. A method as in claim 15, further comprising translating at least some of the telecommunications information from one of the platforms and transmitting the translated information to at least one other platform.

20. A method as in claim 15, further comprising translating at least some of the telecommunications information and transmitting the translated information to another service provider telecommunications system.

21. A method as in claim 15, further comprising receiving telecommunications information from another service provider, translating the received information and transmitting the translated information to at least some of the platforms.

22. A method as in claim 15, further comprising accessing information from at least one of the components with a graphical user interface.

23. A method as in claim 15, further comprising transmitting state, behavior and usage information relating to telecommunications domain objects to at least one of the platforms to assist the components in performing a task.

24. A method as in claim 23, wherein the state, behavior and usage information comprises network element requirements, facilities requirements and work force requirements needed to accomplish a task.

25. A method for providing telecommunications services, comprising: ordering a telecommunications service and entering the order into an order entry component interfaced with a service management (customer facing) platform; querying a data model through the service management (customer facing) platform to determine if the product is available for order; transmitting information relating to the order to a service management (network facing) platform having an order management component; querying the data model through the service management (network facing) platform to determine the particular resources that are required to service the order; transmitting information relating to the order to a network management platform to determine if the particular resources are available to service the order; and transmitting information relating to the order to a network element management platform to service the order on a network element.

26. An engine for use in a telecommunications system, comprising: a component which is adapted to selectively interface with a platform having a defined functional responsibility within the telecommunications system, wherein the component includes code to assist in performing a task within the functional responsibility of the platform, whereby configuration information may be transmitted from the platform to a network element .

27. An engine as in claim 26, wherein the component is selected from the group of components consisting of network management systems, service order management systems, order entry systems, monitoring systems, billing systems, inventory systems, work force administration systems, rating systems, capacity planning systems, and network operations systems.