System and method for reporting telecommunication service conditions

0001System and Method for Reporting Telecommunication

0002Service Conditions

0003Background of the Invention

0004Field of the Invention

0005The present invention relates to systems for monitoring call conditions on a telecommunications network. Specifically, a system is described for reporting network events, including alarms and other network conditions affecting a customer's telecommunication service, directly to a customer.

0006Related Art

0007Major customers of telecommunications services have in the past relied upon their telecommunications carrier to identify network problems and take corrective measures. The common carrier conducts a continuous fault monitoring process throughout its network to identify, locate and correct conditions which adversely affect voice and data lines.

0008Common carriers generally make fault information (information regarding network events) available. For example, fault information for data network events is presently available from the DIGINET® forwarding facility of the MCI Corporation. Similarly, MCI's TANDEM® and SENTRY® forwarding facilities provide fault information for voice network events. Various leased services are monitored for events including, for example, 800 service dedicated circuit alarms,

0009900 service dedicated circuit alarms, Prism® dedicated circuit alarms, Vision® dedicated circuit alarms, VNET (MCI virtual private network) service dedicated circuit alarms, ISDN (Integrated Services Digital Network) service dedicated circuit alarms, DDS/DS0 (MCI dedicated data service) circuit alarms and TDS (MCI terrestrial data service) 1.5 and 45 circuit alarms. Customers of leased facilities can take corrective measures to mitigate faults that occur over the leased services. For example, if a particular trunk or trunk group becomes unusable due to a reported fault, the customer can route calls to other facilities until the affected lines are cleared of their faults. If the customer detects the problem before the carrier, the customer can also send a service request to the carrier.

0010However, customers cannot react to mitigate problems associated with network alarms and faults unless they are promptly informed of these events. The delivery of information relating to these service problems to the department or location within a customer's organization that is responsible for managing their leased facilities would permit the customer to analyze various fault conditions and traffic patterns within their portion of the network and manage these facilities more economically.

0011Providing individual telecommunications management information to telecommunications customers is complicated by the fact that different customers lease different types of services. Effective fault management must be configured to match the particular services that individual customers lease, precluding a "one size fits all" solution to network management.

0012What is needed is a way to provide to individual customers of leased telecommunications services information pertaining to facility performance.

0013What is further needed is a way to provide real time-custom event views specific to the services leased by a telecommunications customer. Summary of the Invention

0014The present invention is a system and method for reporting selected telecommunication service conditions to individual customers. A fault management system is provided in accordance with the invention to customers of telecommunications services. A workstation at the customer's location is linked to a fault server of the telecommunications carrier. The fault server is in turn connected to the telecommunications carrier's network management system which collects real time data relating to faults and traffic conditions occurring on the carrier's telecommunications network.

0015The fault server of the network management system is linked to an open server which is configured to receive events, such as alarms and traffic conditions, which describe network conditions. As each customer typically subscribes to a different package of services, the workstation is capable of configuring the server to report only events which are germane to the particular package of leased services.

0016The workstation at the customer's location receives, from the server, event information relating to the services to which that customer subscribes. An event queue within the workstation stores each event as it is reported from the server, including the date and time of the event, the nature of the event, location of the event within the network, etc. A graphical user interface at the workstation permits the data from the event queue to be displayed to the user.

0017The workstation and server interact. When an event is received by the workstation from the server, and the user acknowledges the event, the workstation forwards an acknowledgment to the server indicating that the event has been reported, and the event is displayed as a new event by the workstation. One advantage of the present invention is that it permits a customer to receive fault information regarding the telecommunications services to which he subscribes.

0018Another advantage of the present invention is that it permits a customer to define criteria for reporting telecommunications service conditions.

0019Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digits of a reference number identify the drawing in which the reference number first appears.

0020Brief Description of the Figures

0021The present invention will be described with reference to the accompanying drawings, wherein:

0022FIG. 1 depicts an example fault management system for reporting telecommunication service conditions;

0023FIG. 2 depicts the architecture of a preferred embodiment of a fault manager host and fault manager server;

0024FIG. 3 is a block diagram depicting an example workstation; and

0025FIG. 4 is a flowchart depicting the operation of a preferred embodiment of the present invention. Detailed Description of the Preferred Embodiments

0026FIG. 1 depicts an example fault management system 100 for reporting telecommunication service conditions. Fault management system 100 includes a plurality of fault manager workstations 102, which are linked to a network management system 104. Network management system 104 collects network events, including alarms and traffic densities from a common carrier network 106. All of the events collected by network management system 104 are reported to a fault manager host 108. The common carrier keeps track of the performance and network faults for network 106 through a myriad of network management systems 104 and routes the information real-time to fault manager host 108. In order to provide information regarding a particular customer's leased services, events collected by fault manager host 108 are downloaded to fault manager server 1 10.

0027Fault manager server 110 accumulates in real time a database of events pertinent to each customer's leased services. The accumulated data is viewable on one or more fault manager workstations 102. Because individual customers may subscribe to various different services which may experience different events, fault manager server 110 must not only collect different sets of data on a real-time basis from fault manager host 108, but a fault manager workstation 102 must present the data in a format relevant to the particular services to which the customer subscribes. This data is organized for display to the user of workstation 102 in an event queue 112.

0028In a preferred embodiment of the present invention, fault manager host

0029108 is an Integrated Network Management System (INMS) host implemented as an IBM S/370 mainframe and fault manager server 1 10 is implemented as an

0030IBM RS6000 computer; the architecture of this embodiment is depicted in FIG. 2. The present invention may be implemented in other ways, as would be apparent to one skilled in the relevant art.

0031Referring to FIG. 2, INMS host 108 operates in an IBM Customer Information Control System (CICS) environment and includes an IBM virtual telecommunications access method/network control program (VTAM/NCP) interface 202 for making an IBM Systems Network Architecture/Logical Unit interface version 6.2 (SNA LU6.2) connection to a mainframe client gateway (MCG) 204 of INMS host 108. MCG 204 in turn makes a Transport Control Protocol/Internet Protocol (TCP/IP) connection to IBM RS6000 fault manager server 1 10, which operates under the IBM Advanced Interactive Executive (AIX)

00323.2.5 operating system.

0033Server 110 comprises two servers: a Structure Query Language (SQL) server 206 and an open server 208. Open server 208 receives events from INMS host 108 and stores them on a database 210 stored on server 1 10. SQL server 206 is a database engine providing access to and managing database 210. In a preferred embodiment, database 210 is a Sybase® database and SQL server 206 is a Sybase® SQL server.

0034Database 210 compiles information that is sent on a regular basis by INMS host 108. The data stored in the SQL server can be queried at will by a workstation 102 for analysis. Database 210 is a relational database using SQL server 206 as the database management system (DBMS). In a preferred embodiment, database 210 comprises three databases. The first database includes information relevant to other network management applications (for example, MCI ServiceView®), such as facilities and circuit prefixes, and a customer mapping table for all customers subscribing to the fault manager service. The second database is the customer database. It contains specific event information such as alarms, reporting and user information. It also tracks the users who log on from the various fault manager workstations 210, including the user's log-on passwords, access security, and the various alarm descriptions and their status as reported by network management system 104.

0035The third database contains statistics relating to the various facilities monitored by network management system 104. In a preferred embodiment, these statistics are compiled , and are updated on a regular basis, by MCI Extended Super Frame Monitoring Units.

0036Database 210 includes a number of tables of data which are accessed by fault manager workstations 102 to event displays, including alarm displays, alarm reports, facilities cross-references and event log displays. User access to database 210 is by way of password security handled by SQL server 206; levels of security can also be provided to permit tiers of access to different levels of information within database 210, as would be apparent to one skilled in the relevant art.

0037The data within database 210 is organized in views. For example, an alarm view provides an alarm description, an alarm severity representing the degree of consequence for the alarm, and selected conditions associated with the alarm.

0038The interface between INMS host 108 and server 1 10 is one-way, from the INMS host only. In this scenario, the INMS host 108 is a client, issuing calls for stored procedures to SQL server 206 via MCG 204 when there is an event to report.

0039When MCG 204 receives a request from INMS host 108, it accepts an LU6.2 conversation and creates a local-area-network-based connection to SQL server 206. The request is then forwarded to SQL server 206, which updates database 210 with the information sent by INMS host 108.

0040Fault manager workstations 102 access database 210 via SQL server 206.

0041In a preferred embodiment of the present invention, this access takes place over a dial-up modem connection. Other methods of access can be employed without departing from the spirit and scope of the present invention, as would be apparent to one skilled in the relevant art.

0042FIG. 3 is a block diagram depicting an example workstation 102. Workstation 102 includes one or more processors, such as processor 304. The processor 304 is connected to a communications bus 306. Various software embodiments are described in terms of this example workstation 102. After reading this description, it will be apparent to a person skilled in the relevant art how to implement the invention using other computer systems and/or computer architectures.

0043Workstation 102 also includes a main memory 308, preferably random access memory (RAM), and can also include a secondary memory 310. The secondary memory 310 can include, for example, a hard disk drive 312 and/or a removable storage drive 314, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 314 reads from and or writes to a removable storage unit 318 in a well known manner. Removable storage unit 318 represents a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by removable storage drive 314. As will be appreciated, the removable storage unit 318 includes a computer usable storage medium having stored therein computer software and/or data.

0044In alternative embodiments, secondary memory 310 may include other similar means for allowing computer programs or other instructions to be loaded into workstation 102. Such means can include, for example, a removable storage unit 322 and an interface 320. Examples can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 322 and interfaces 320 which allow software and data to be transferred from the removable storage unit 322 to workstation 102.

0045Workstation 102 can also include a communications interface 324. Communications interface 324 allows software and data to be transferred between workstation 102 and external devices through communications path 326. Examples of communications interface 324 can include a modem, a network interface (such as an Ethernet card), a communications port, etc. Software and data transferred through communications interface 324 are in the form of signals which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 324 through communications path 326.

0046Workstation 102 is described in these terms for convenience only. It is not intended that the present invention be limited to application in this example environment. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.

0047FIG. 4 is a flowchart depicting the operation of a preferred embodiment of the present invention. Typically, a customer subscribes to several particular leased services. In order to limit data collection to data germane to those particular services, the user must specify the data to be collected. The user does this by defining an event view of data to be collected, as shown in a step 402. The event view specifies, for example, which services are to be monitored and what data is to be collected and reported for those services. For example, the event view may include the following items:

0048Severity Critical, Major, Minor, Informational, No Alert

0049Service Types (MCI): 800, 900, TDS 1.5, TDS 45, VNET, Prism®, Vision®,

0050ISDN, SW56 and DDS/DD0

0051Corporate Identifiers: A list of corporate identifiers related to the customer's enterprise and for which the user is authorized access.

0052Facilities All elements of a physical telephone plant required to provide a service and to which the user is authorized access (for example, trunk groups and circuits).

0053Data Elements The user can configure a customized event view by selecting the data fields to be displayed.

0054Date and Time Elements The user can configure a customized event view by selecting the date and time period for the custom event view

0055Sort Order The user can configure a customized event view by selecting, for example, the data fields on which the data to be displayed is sorted

0056Once the event view has been defined, workstation 102 generates an SQL statement which will command server 1 10 to create the event view from data stored m database 210. In a preferred embodiment, the SQL statement is constructed such that each element/field is joined by an "AND" and values within each element field are joined by an "OR " Thus, a partial SQL statement would be similar to Severity = critical OR severity = Major

0057AND Service Type = VNET

0058AND CORP ID = 123434 OR CORP ID = 32432423

0059AND ... etc.

0060Once the SQL statement has been generated, workstation 102 connects to fault manager server 110, as shown in a step 404. In a preferred embodiment, the connection is made via a dial-up modem connection. Other connection methods and protocols can be employed without departing from the spirit and scope of the present invention, as would be apparent to one skilled in the relevant art.

0061Once the physical connection has been made between workstation 102 and server 110, the user enters a valid name and password. Server 110 then checks the credentials of the user before starting a session with workstation 102. This is accomplished via a connection between open server 208 and an external server (not shown) that contains user account information (for example, user name and password).

0062Once the session has been established, the SQL statement created in step

0063402 is forwarded to SQL server 206. The SQL statement identifies to SQL server 206 the particular stored procedure to be activated to obtain event view specified by the SQL statement. SQL server 206 then executes the stored procedure and builds a report of event data specified by the event view, as shown in a step 408.

0064Once the event report is built, it is sent to workstation 102. Events which are reported from server 1 10 to workstation 102 are loaded in event queue 1 12. The events in event queue 112 are sorted by sort criteria entered by the user when defining the event view, as shown in a step 412. In a preferred embodiment, the primary sort criterium is severity. The sorted events are displayed to the user on the workstation monitor in a step 414. Each event displayed is accompanied by an acknowledgment field for the user to indicate his acknowledgment of the event; for example, the user can acknowledge an event by entering an asterisk in the associated acknowledgment field. When the user acknowledges an event, as indicated by the "Y" branch from step 416, workstation 102 reports the acknowledgment to server 1 10, as shown in a step 418. When the user has acknowledged the last event in event queue 1 12, as indicated by the "Y" branch from step 420, event processing ends. At this point, the user may either retain the session or close it.

0065If the session remains open, server 110 will report new events defined by the event view as they are received by server 110. When server 1 10 receives a new event, as indicated by the "Y" branch from step 422, processing resumes at step 408, as shown in FIG. 4.

0066Thus, in accordance with the event view defined by the user and communicated to fault manager server 1 10, reports of events identified in the event view will be continuously forwarded to workstation 102, and made available in event queue 112 for display to the user in order of the severity of the event.