Method and apparatus for network service assurance

Trouble ticket management automates existing institutional operational processes by engaging various external trouble ticketing systems. These systems feed correlated alarm events, trouble analysis results, and trouble ticket information to a particular institutional network. Correlated alarm feeds, including trouble ticket information, are correlated and sent to institutional trouble ticket management systems. The alarms are processed and remedy tickets are created. The remedy tickets interact with remedy tickets at the institutional trouble ticket management systems. These remedy tickets are bonded with maintenance platform tickets.

BACKGROUND OF THE INVENTION

The present invention relates generally to trouble ticket management systems, and more particularly to trouble ticket management systems in secure environments.

Institutional clients (e.g., government agencies, etc.) of telephone service providers may employ secure, closed, or otherwise restricted networks or portions of networks. In such cases, the institutional client's networks operations center often maintains its own trouble ticket management system (TMS). These TMSs are associated with the secure network and are themselves secure. This does not allow ready access to or coordination with external trouble ticket management systems, such as those used by telephone service providers.

Accordingly, systems and methods for coordinating trouble ticketing management systems are needed.

BRIEF SUMMARY OF THE INVENTION

Coordinating electronic trouble ticketing systems includes receiving circuit information from one or more inventory systems, retrieving a plurality of alarms, correlating the plurality of alarms to the circuit information, determining one or more network problems based on the correlated plurality of alarms related to the circuit information, and transmitting information related to the determined network problems to a user.

In at least one embodiment, retrieving the plurality of alarms includes retrieving one or more physical layer alarms, retrieving one or more data link layer alarms, and retrieving one or more network layer alarms. Correlating the plurality of alarms to the circuit information involves correlating the one or more network layer alarms to the one or more physical layer alarms and the one or more data link layer alarms.

Correlating the one or more network layer alarms to the one or more physical layer alarms and the one or more data link layer alarms includes correlating the one or more network layer alarms to the one or more physical layer alarms and the one or more data link layer alarms by matching the common language facilities identifiers of the one or more network layer alarms to the common language facilities identifiers of the one or more physical layer alarms and to the common language facilities identifiers of the one or more data link layer alarms.

In some embodiments, retrieving the plurality of alarms related to the circuit information includes retrieving the one or more data link layer alarms and the one or more network layer alarms from a global fault platform and retrieving the one or more physical layer alarms from a physical layer platform.

DETAILED DESCRIPTION

The proposed systems and methods of trouble ticket management described herein automate existing institutional operational processes by engaging various external trouble ticketing systems. These systems feed correlated alarm events, trouble analysis results, and trouble ticket information to a particular institutional network. Correlated alarm feeds, including trouble ticket information, are correlated and sent to institutional trouble ticket management systems. The alarms are processed and remedy tickets are created. The remedy tickets interact with remedy tickets at the institutional trouble ticket management systems. In some embodiments, these remedy tickets are bonded with maintenance platform tickets. The institutions may then use the externally created remedy ticket for trouble management and additionally have access to the source tickets, alarms, etc.

FIG. 1is a schematic drawing of a global trouble ticket management system (TMS)100according to an embodiment of the present invention. Global TMS100includes a trouble ticket management system controller102in communication with one or more local ticket management systems, such as business maintenance platform104and/or ticket manager106, and one or more customers108. Business maintenance platform104and/or ticket manager106may also be coupled to one or more workcenters110. Additionally, TMS controller102is in communication with an institutional network112and/or its constituent components.

Institutional network112may include an institutional remedy ticket system114, an electronic maintenance system116, and/or an institutional workcenter118, each configured to communicate with one another. In at least one embodiment, electronic maintenance system116is also coupled to one or more customers108.

TMS controller102may be any appropriate server or controller, such as the controller depicted inFIG. 3. Accordingly, TMS controller102is adapted to be configurable (e.g., by an institution, user, client, server, etc.) to coordinate and/or communicate with various alarm systems, communications systems, ticket management systems, and the like to provide any appropriate communication and transfer of information therebetween.

In at least one embodiment, TMS controller102is a platform for dynamic generation and management of expert rules that automates critical operations such as customer care, network care, and billing disputes. Such a TMS controller102can process hundreds of thousands network alarms, orders, and tickets each day. The TMS controller102, which adopts the object-oriented design, is more complex than standard servers due to the scale of the associated systems and the dependency amongst rules. Since most of the rules are created manually (e.g., by an institution, user, client, server, etc.) by different “rule managers” across different domains, TMS controller102may include a framework for automatic verification and optimization. In these ways, TMS controller102may be set-up or otherwise configured to perform various functions of trouble ticket management, as described below in further detail with respect toFIG. 2.

Business maintenance platform104may be any appropriate maintenance platform, such as a carrier (e.g., telephone carrier, etc.) maintenance platform. Similarly, ticket manager106may be any appropriate carrier ticket manager.

Institutional network112may be any communication network used by an institution, organization, government agency, or the like. Generally, institutional network is a closed network including traditional voice telephony components, internet protocol network components, Ethernet components, and/or other similar network components. Institutional network112may also include institutional remedy ticket system114, electronic maintenance system116, institutional workcenter118and/or any other appropriate components for operating a trouble ticket system on the institutional (e.g., local, organizational, etc.) network. Institutional network112manages and maintains lists of issues (e.g., alarms, trouble tickets, alerts, etc.) as needed by an organization. Institutional network112may include a knowledge base (e.g., actualized as a database) containing information on each customer108, resolutions to common problems, and other such data.

Components of institutional network112, such as electronic maintenance system116may manage the business logic layer of the application. This layer gives data received from TMS controller102, ticket manager106, business maintenance platform104, and/or customer108structure and context, preparing it for use by institutional network112and/or any other part of global TMS100.

In at least one embodiment, institutional network112may operate a manual trouble ticket management system. In such a manual system, data are presented to the support technicians at institutional workcenter118, generally by a software application, web page, or the like. The end-user of the trouble ticket management system (e.g., customer108) can create entirely new issues, read existing issues, add details to existing issues, or resolve an issue. The institutional network112may also record such actions to maintain a history of the actions taken.

FIG. 2is a flowchart of a method200of trouble ticket management according to an embodiment of the present invention. The steps of method200may be performed by one or more components of global TMS100as described below. The method starts at step202.

In step204, troubled circuit information is retrieved from inventory systems. That is, information associated with problems and/or failures in a network are retrieved from one or more sources. In at least one embodiment, the troubled circuit information is retrieved from one or more components of institutional network112or another network (e.g., a telephone network, a packet network, etc.).

In step206, alarms are retrieved. One or more alarms are retrieved from throughout global TMS100. The alarms may be retrieved at TMS controller102. Physical layer (e.g., layer1) alarms may be retrieved from business maintenance platform104and/or other platforms in a network such as a common test platform, a network alarm convergent agent, or the like. Data link layer (e.g., layer2) and/or network layer (e.g., layer3) alarms may be retrieved from a global fault platform or the like. Of course, other alarms may be retrieved from any location in a packet or telephone network as described above. In some embodiments, retrieval of alarms includes collecting alarm clear events.

In step208, the alarms are correlated. In at least one embodiment, the alarms are correlated at TMS controller102. Alarms from different levels may be correlated with each other using any appropriate method. For example, network layer alarms may be correlated to corresponding data link layer and/or physical layer alarms retrieved in step206. The alarms may be correlated by matching Common Language Facility Identifiers (CLFIs) at various levels. Of course, other correlation methods may be used by TMS controller102.

In step210, a network problem is determined. The network problem is determined based on the correlated alarms in step208. The network problem may be determined by isolating a problem at customer premises equipment (e.g. equipment at customer108and/or in institutional network112), in a local exchange carrier (LEC), in an interexchange carrier (IXC), or in another network, device, or carrier. The isolation may be performed by analyzing outage on a network (e.g., within the purview of global TMS100). In other words, network and/or data link layer alarms are correlated with physical layer root causes by mapping physical channels to logical channels.

In step212, a determination is made as to whether an alarm is correlated to a customer (e.g., customer108) or equipment location (e.g., equipment in a network outside of institutional network112). Such a determination is based on the determination step210above. If an alarm is correlated to a customer or equipment location, the method proceeds to step214and processing is stopped since the alarm is not related to institutional network112.

If an alarm is not correlated to a customer or equipment location, the method proceeds to step216and service and/or element tickets are queried. TMS controller102queries ticket manage106and/or business maintenance platform106for service and/or element tickets. In the case of service tickets, the query may be based on a customer circuit identification. In the case of element tickets, the query may be based on a node, shelf, slot, and/or port.

In step218, the alarms are logged according to a determined fault location. That is, based on the tickets of step216and the alarm retrieval of step206, a determination is made as to where the problem is (e.g., a LEC network outage, a CPE network outage, an IXC network outage, an unknown network outage, etc.). Such information is then logged at TMS controller102or another appropriate location.

In step220, a facility status message is created. In at least one embodiment, the facility status message is a real-time Extensible Markup Language (XML) message with alarm information, circuit identification information, event information, ticket information, and/or other trouble information determined and/or retrieved in the prior method steps.

In step222, the facility status message is sent to the institutional network112. Specifically, the facility status message may be sent to the institutional remedy ticket system114.

A remedy ticket is created at TMS controller102in step224. The remedy ticket may be a trouble and/or remedy ticket that interacts with a trouble and/or remedy ticket used in institutional remedy ticket system114. In step226, the remedy ticket is electronically bonded (e-bonded) to the LEC if an LEC problem has been identified.

In step228, a check is performed to determine if an alarm has been cleared or service is restored. If the alarm has been cleared or service has been restored in the network, the trouble ticket is automatically closed in step230. The method then ends at step232. If the alarm has not been cleared or service has not been restored in the network, further troubleshooting may be performed in step234. Various method steps of method200may be repeated or other trouble ticket remedy solutions may be implemented. The method then ends at step232.

FIG. 3is a schematic drawing of a controller300according to an embodiment of the present invention.

Controller300contains devices that form a controller including a processor302that controls the overall operation of the controller300by executing computer program instructions, which define such operation. The computer program instructions may be stored in a storage device304(e.g., magnetic disk, database, etc.) and loaded into memory306when execution of the computer program instructions is desired. Thus, applications for performing the herein-described method steps, such as those described above with respect to method200are defined by the computer program instructions stored in the memory306and/or storage304and controlled by the processor302executing the computer program instructions. The controller300may also include one or more network interfaces308for communicating with other devices via a network (e.g., global TMS100). The controller300also includes input/output devices310that enable operator interaction with the controller300. Controller300and/or processor3202may include one or more central processing units, read only memory (ROM) devices and/or random access memory (RAM) devices. One skilled in the art will recognize that an implementation of an actual computer for use in a portable communication device could contain other components as well, and that the controller ofFIG. 3is a high level representation of some of the components of such a portable communication device for illustrative purposes.

According to some embodiments of the present invention, instructions of a program (e.g., controller software) may be read into memory306, such as from a ROM device to a RAM device or from a LAN adapter to a RAM device. Execution of sequences of the instructions in the program may cause the controller300to perform one or more of the method steps described herein. In alternative embodiments, hard-wired circuitry or integrated circuits may be used in place of, or in combination with, software instructions for implementation of the processes of the present invention. Thus, embodiments of the present invention are not limited to any specific combination of hardware, firmware, and/or software. The memory306may store the software for the controller300, which may be adapted to execute the software program and thereby operate in accordance with the present invention and particularly in accordance with the methods described in detail below. However, it would be understood by one of ordinary skill in the art that the invention as described herein could be implemented in many different ways using a wide range of programming techniques as well as general-purpose hardware sub-systems or dedicated controllers.

Such programs may be stored in a compressed, uncompiled, and/or encrypted format. The programs furthermore may include program elements that may be generally useful, such as an operating system, a database management system, and device drivers for allowing the portable communication device to interface with peripheral devices and other equipment/components. Appropriate general-purpose program elements are known to those skilled in the art, and need not be described in detail herein.