 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to an Advanced Intelligent Network having a network node, referred to as a Maintenance Operations Console (MOC), that monitors and controls operations of the elements of the Advanced Intelligent Network.
2. Description of the Related Art
In recent years, a number of new service features have been provided by an enhanced public communications telephone network, referred to as an Advanced Intelligent Network (AIN). In an AIN type system, local and/or toll offices of the public
telephone network detect one of a number of call processing events identified as AIN "triggers". For ordinary telephone service calls, there would be no event to trigger AIN processing, and the local and toll office switches would function normally and
process such calls without referring to the central database for instructions. An office which detects a trigger will suspend call processing, compile a call data message and forward that message via a common channel interoffice signaling (CCIS) link to
an Integrated Service Control Point (ISCP) which includes a Multi-Services Application Platform (MSAP) database. If needed, the ISCP can instruct the central office to obtain and forward additional information. Once sufficient information about the
call has reached the ISCP, the ISCP accesses its stored data tables in the MSAP database to translate the received message data into a call control message and returns the call control message to the office of the network via CCIS link. The network
offices then use the call control message to complete the particular call. An AIN type network for providing an Area Wide Centrex service was disclosed and described in detail in commonly assigned U.S. Pat. No. 5,247,571 to Kay et al., the disclosure
of which is herein incorporated in its entirety by reference. In AIN type systems such as disclosed in Kay et al., announcement and digit functions may be required for certain specific services. For example, a caller may be prompted by a tone or speech
announcement to enter a personal identification number (PIN) before obtaining a selected service or modifying certain stored parameters relating to the subscriber's AIN service. In prior art AIN systems, a switching office of the public telephone
network would generate the announcements from some internal platform.
Intelligent Peripherals (IPs) have been proposed as an AIN network node that provides a platform to provide readily adaptable means to add and change announcements to an AIN, without direct addition of equipment in each central office switching
system. By centralizing announcement capabilities in the IP, announcement changes can be performed without reprogramming every switch in the network offering an enhanced service. The IP also provides a flexible platform to accommodate the addition of
future service enhancements, such as speech recognition, mail services, etc., without requiring addition to or modification of equipment within the central office switching systems.
Telephone networks have historically required a high level of reliability in the services provided to its subscribers. Accordingly, it is highly desirable that the enhanced service features provided by AIN networks have the same high level of
reliability as conventional public switched telephone networks. Thus, AIN elements have been equipped with dedicated maintenance and operations consoles (MOCs) to monitor operations of the respective AIN element. For example, Bellcore has developed an
ISCP that has a dedicated maintenance and operations console (MOC) for monitoring the operations of the ISCP. Each Bellcore ISCP is mated with a dedicated Bellcore provisioning system, known as the SPACE provisioning system, that also has its own
dedicated MOC. The SPACE provisioning system programs the databases in the specific ISCP, for example by communicating via a packet switched network, such as Transmission Control Protocol/Internet Protocol (TCP/IP) network. A more detailed description
of an exemplary implementation of the SPACE provisioning system 54 is found in U.S. Pat. No. 5,241,588 to Babson, III et al., the disclosure of which is incorporated in its entirety by reference.
A protocol known as Simplified Network Management Protocol (SNMP) has been specified for the communication of management information in data networks using TCP/IP protocol. This protocol is designed to be simple but flexible so that management
applications of some complexity can be built, while still retaining support for the lowest common denominator of managed systems.
However, the maintenance and operations systems in the telephone networks have not adopted SNMP due to the perceived inability of SNMP to accommodate the relative complexity of the telephone network functions. Moreover, existing MOCs such as the
Bellcore ISCP MOC and SPACE MOC use proprietary software and technology that is incompatible with SNMP. The incompatibility of the ISCP MOC and the SPACE MOC with SNMP prevents the transport of management information from the ISCP MOC or the SPACE MOC
to another AIN element via the TCP/IP network.
Hence, each AIN element requires its own dedicated MOC, often at the physical location of that AIN element. Thus, the addition of another AIN element, such as an IP, will require the addition of a dedicated MOC to ensure reliability of the new
AIN element. For example, commonly-assigned, copending application No. 08/248,980, filed May 25, 1994, entitled Advanced Intelligent Network with Intelligent Peripherals Interfaced to the Integrated Services Control Point (attorney No. 680-076), the
disclosure of which is incorporated in its entirety by reference, discloses an IP that has its own dedicated MOC. Thus, MOCs are unable to communicate with each other in order to share resources or compare different errors from different AIN elements,
thereby complicating efforts to identify faults in AIN systems failures.
DISCLOSURE OF THE INVENTION
There is a need for a Maintenance Operations Console (MOC) that can perform management functions for any network element in a public communications network.
There is also a need for a MOC that can be located separate from a managed programmable node of the public communications network.
There is also a need for a MOC which is able to monitor hardware, software, and software subsystems of a programmable node of a public communications network via a data network.
There is also a need for a MOC that monitors and detects errors in hardware, software, and software subsystems of an Advanced Intelligent Network (AIN) element by receiving SNMP protocol messages from the AIN element via a packet switched network
having TCP/IP protocol.
There is also a need for a MOC that uses a data network to monitor errors in the program-controlled nodes of the public communications network, and to output corrective measures to eliminate the detected errors.
These and other needs are met by the present invention, whereby a network maintenance and operations console (MOC) sends and receives messages in a standardized network management message format to and from a data network using a standardized
transport protocol, such as TCP/IP. A public communications network has a plurality of program-controlled nodes that are connected to the data network and output error status messages for maintenance, error detection and failure recovery operations of
software and hardware subsystems. Each program-controlled node includes a monitoring subsystem and a communications subsystem. The monitoring subsystem identifies errors in the hardware and software subsystems of the corresponding program-controlled
node and supplies the status of the identified error to a communications subsystem, which outputs the status of the identified error onto the data network as objects of a standardized network management message format.
The network maintenance and operations console receives the objects output from the respective program-controlled node, assigns operational priorities to the received objects based on identified object relationships stored in a management
information base (MIB), and presents the status of the identified errors on a graphical user interface in accordance with a relational hierarchy of the received objects with respect to the program-controlled nodes elements and the respective operational
priorities.
Thus, the maintenance and operations console of the present invention uses a standardized network management message format and a standardized transport protocol to receive management information from any program-controlled node connected to the
data network. Hence, the network maintenance and operations console of the present invention is able to monitor a number of different network nodes from virtually any location, and can locally and remotely monitor, administer, and troubleshoot any
problems that may be present in an program-controlled node, including software subsystems of the program-controlled node.
The present invention also provides a system for performing corrective action on detected errors within software subsystems of the program-controlled nodes, also referred to as public communications network elements connected, to the data network
using a standardized network management protocol. According to the present invention, the maintenance operations console comprises an error correction module that outputs to the data network an SNMP object that represents a correction message for one of
the AIN elements. The correction message can be used to perform disaster recovery techniques, such as aborting and restarting a software module, resetting the software module, or loading new software into the software module. Alternatively, the
correction message may be sent to a different network element that manages network assignments in order to perform fail-over, i.e., reassigning network resources to compensate for the failed subsystem of an AIN element.
Thus, the present invention provides a generic system for monitoring any AIN network element using a standardized network management message format and a data network having a standardized transport protocol. In addition, the maintenance
operations console of the present invention is able to easily accommodate newly added AIN elements that are installed on the advanced intelligent network. Thus, the present invention provides the flexibility to manage a large number of AIN elements from
a remote location, and initiate corrective measures as necessary, without the necessity for dedicated consoles that use proprietary technology.
These and other advantages of the present invention will become more readily apparent upon a review of the attached drawings and the accompanying description and the appended claims.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a block diagram of an exemplary Advanced Intelligent Network architecture for a public switched telephone communications network.
FIG. 2 is a block diagram of an arrangement for monitoring and controlling operations for the Advanced Intelligent Network of FIG. 1 according to an embodiment of the present invention.
FIG. 3 is a block diagram of an alternative system architecture for monitoring and controlling operations in an AIN according to another embodiment of the present invention.
FIGS. 4A, 4B and 4C are diagrams illustrating the software architecture of the Intelligent Peripheral (IP) and the Maintenance Operations Console (MOC) of FIGS. 2 and 3.
FIG. 5 is a block diagram of the error monitoring architecture of the IP of FIG. 4A.
FIG. 6 is a block diagram of the software architecture of the MOC alarm subsystem of FIG. 4B.
FIG. 7 is a block diagram of the software architecture of the MOC topology subsystem of FIG. 4B.
FIG. 8 is a protocol diagram of the Simplified Network Management Protocol.
FIGS. 9A-9J are diagrams illustrating a graphic user interface for the MOC of FIGS. 2, 3 and 4.
BEST MODE FOR CARRYING OUT THE INVENTION
The present invention provides a system for managing the maintenance and operations of a program-controlled node of a public communications network by outputting from each node error status messages that identify the operational status of the
node hardware and software subsystems. The error status messages are output as objects of a standardized network management message format, such as Simplified Network Management Protocol (SNMP), to a Maintenance and Operations Console (MOC) via a data
network using a standardized transport protocol, such as TCP/IP. The MOC includes a Management Information Base (MIB) that identifies the received objects, a mapping module that determines the priority of the node performance based on the received MIB
objects, a topology module for organizing the MIB objects for presentation on a graphic user interface (GUI), and a corrective action module that outputs objects using the standardized network management message format, such as SNMP, to at least one
program-controlled node to respond to a detected error. An overview of the public communications network will first be provided, followed by a detailed description of the preferred embodiment of the MOC of the present invention.
FIG. 1 provides a simplified block diagram of a public telephone type communications network having program-controlled nodes to provide advanced service capabilities. The network shown in FIG. 1 resembles the type shown in U.S. Pat. No.
5,247,571 to Kay et al., the disclosure of which is incorporated in its entirety by reference, and is thus also referred to as an Advanced Intelligent Network (AIN), wherein the program-controlled nodes are also referred to as "AIN nodes" or "AIN
elements". The telephone network of FIG. 1 includes a switched traffic network and a common channel signaling network used to carry control signaling and the like between nodes of the switched traffic network.
The network of FIG. 1 includes a number of end office switching systems 10, also referred to as service switching points (SSPs) for reasons discussed later. The switching systems 10 provide connections to and from local communication lines
coupled to end users equipment. Although the end users equipment may consist of telephone station sets 12a connected to POTS or ISDN lines 14a, the end users equipment may be arranged as customer premises equipment 16 serving users 12b and 12c. In
addition, an end user 12d may have a wireless link 14b to the SSP 10 via, for example, a cellular transmission system.
The end offices 10 are typically arranged into a local exchange carrier network typically including one or more tandem switching offices (not shown) providing trunk connections between end offices. As such, the local exchange carrier network
comprises a series of switching offices 10 interconnected by voice grade trunks 18. One or more trunks 18' will typically connect one or more switching offices to at least one switch 10' in other carrier networks.
Each switching office 10 has at least minimal SS7 signaling capability, which is conventionally referred to as a signaling point (SP) in reference to the SS7 network. In the local exchange network, at least one of the switching offices 10, and
preferably all, are programmed to recognize identified events or points in call (PICs). In response to a PIC, the switching office 10 triggers a Transaction Capabilities Applications Protocol (TCAP) query message through the signaling network to an
Integrated Service Control Point (ISCP) 22 for instructions relating to AIN type services. Switching offices having the full PIC recognition and signaling capabilities are referred to as service switching points (SSPs).
The ISCP 22 offers AIN routing control functionalities to customers of the local exchange carrier. For example, the ISCP includes a database (not shown) containing call processing records (CPRs) for controlling that carrier's AIN routing
services. The ISCP 22 may also access a separate database, for example, to supplement its routing tables for certain services. In the preferred system, a second function of the ISCP is to serve as a mediation point. Specifically, the ISCP mediates
queries and responses between the local exchange carrier network components and databases operated by other carriers.
The ISCP 22 is an integrated system, and includes a Service Management System (SMS), a Data and Reporting System (DRS) and the actual database referred to as a Service Control Point (SCP). The ISCP also typically includes a terminal subsystem
referred to as a Service Creation Environment or SCE for programming the database in the SCP for the services subscribed to by each individual business customer. The components of the ISCP are connected by an internal, high-speed data network, such as a
token ring network.
The switches 10 typically comprise programmable digital switches with CCIS communications capabilities. One example of such a switch is a SESS type switch manufactured by AT&T, although other vendors, such as Northern Telecom and Seimens,
manufacture comparable digital switches which could serve as the SSPs and SPs. The SSP type implementation of such switches differs from the SP type implementation of such switches in that the SSP switch includes additional software to recognize the
full set of AIN triggers and launch appropriate queries.
Within the local exchange network, the common channel interoffice signaling (CCIS) network includes one or more Signaling Transfer Points (STPs) 20 and data links shown as dotted lines between the STP(s) 20 and the switching offices 10.
Typically, STPs 20 are implemented as matching or mated pairs, to provide a high level of redundancy. A data link also connects each of the STPs of pair 20 to the ISCP 22. One or more data links also connect the STPs 20 in the local exchange carrier
network to mated pairs of STPs 26 in networks of a second carrier.
The local exchange carrier network may also include one or more intelligent peripherals (IPs) 24. The IP 24 provides enhanced announcement and digit collection capabilities and/or speech recognition. The IP 24 connects to the switch 10 of the
local exchange carrier network via an appropriate line circuit. The IP 24 communicates with the ISCP 22 through a data communication network 30 separate from the telephone company switching offices and associated interoffice signaling network. As
discussed in detail below, the data communication network 30 is preferably a packet switched network that serves as a signaling network (SINET) enabling communications between AIN elements including the IP and the ISCP. The SINET network 30 transports
messages using a standardized transport protocol, such as TCP/IP, and may be implemented using X.25, frame relay, SMDS, or ATM technologies.
Commonly assigned copending application Ser. No. 08/248,980, filed May 24, 1994, entitled "Advanced Intelligent Network with Intelligent Peripherals Interfaced to the Integrated Services Control Point" (attorney docket no. 680-076) provides a
detailed disclosure of an AIN type network, including the structure of an SSP switch, the structure of an ISCP and the structure of an IP, and the disclosure of that application is incorporated herein in its entirety by reference.
As shown in FIG. 1, the STP's 20 in the local exchange carrier network are connected by data links, such as SS7, to the STP's 26 of a second regional serving area, which may be another local exchange carrier, or an inter-exchange carrier. As
shown in FIG. 1, the second carrier network comprises a Services Control Point (SCP) 28 in communication with the SINET 30. In such cases, the carrier at the second regional serving area would have a cooperative arrangement with the first local exchange
carrier (having the ISCP 22 and the IP 24) to share network resources via the SINET 30. The SCP 28 includes databases storing routing tables, which typically are more limited than those in the ISCP 17. Although the range of trigger events is limited,
the switching systems 10' in the second carrier network can query the corresponding SCP 28 via the STP 26 for routing information.
An end office switching system 10 shown in FIG. 1 normally responds to a service request on a local communication line connected thereto, for example an off-hook from station 12 followed by dialed digit information, to selectively connect the
requesting line to another selected local communication line, for example to the line to station 12a. The connection can be made locally through only the connected end office switching system but typically will go through a number of switching systems.
In the normal call processing, the central office switching system responds to an off-hook and receives dialed digits from the calling station. The central office switching system analyzes the received digits to determine if the call is local or
not. If the called station is local and the call can be completed through the one central office (intraoffice call), the central office switching system connects the calling station to the called station. If, however, the called station is not local,
the call must be completed through one or more distant central offices (interoffice call), and further processing is necessary. If at this point the call were connected serially through the trunks and appropriate central offices between the caller and
the called party using in-band signaling, the trunks would be engaged before a determination is made that the called line is available or busy. Particularly if the called line is busy, this would unnecessarily tie up limited voice trunk circuit
capacity. The CCIS system through the STP's was developed to alleviate this problem.
In the CCIS type call processing method, the originating end office switching system suspends the call and sends a message through the CCIS network to the end office switching system serving the destination telephone line. The terminating end
office determines whether or not the called station is busy. If the called station is busy, the terminating end office so informs the originating end office via CCIS message, and the originating end office provides a busy signal to the calling station.
If the called station is not busy, the terminating end office so informs the originating end central office. The originating office provides ringback to the caller, and the terminating office applies ringing current to the line to the called party.
When the telephone station connected to the called line goes off-hook, the terminating switching office informs the originating switching office, and the two offices establish a telephone connection via the trunks and end offices (and/or tandem offices)
of the network between the calling and called stations.
For an AIN type service, such as call redirection based on data stored in the ISCP 22, the end offices and/or tandems are SSP capable and detect one of a number of call processing events, each identified as a `point in call` (PIC), to trigger AIN
type processing. Specifically, in response to such a PIC, a switching system such as switch 10 suspends call processing, compiles a call data message, also referred to as a TCAP query message, and forwards that message via common channel interoffice
signaling (CCIS) links and one or more STPs 20 to an ISCP 22. If needed, the ISCP 22 can instruct the particular switching office to obtain and forward additional information. Once sufficient information has reached the ISCP 22, the ISCP 22 accesses
its stored data tables and or data in external databases to translate the received data into a call control message and returns the call control message to the switching office via the STP 20 and the appropriate CCIS links. The switching office 10 uses
the call control message to complete the particular call through the public switched network in the manner specified by the subscriber's data file in the ISCP 22.
The SCP 28 offers similar capabilities in the network of the other carrier, but the range of service features offered by that database is more limited. For example, the SCP 28 may offer 800 number calling services with a limited number of
related call routing options. If a caller at station 12 dials an 800 number corresponding to the other carrier, the switch 10 routes the call to a switch in the other carrier, which recognizes the 800 number in the CCIS information provided with the
call and launches a CCIS query to the SCP 28. The SCP 28 translates the dialed 800 number into an actual destination number, and transmits a CCIS response message back to the switch generating the CCIS query, which then routes the call through the
public network to the station identified by the number sent back by the SCP 28, using CCIS call routing procedures of the type discussed above.
In a mediated call processing operation, a switch such as SSP switch 10 reaches a point in call (PIC) in processing a particular call which triggers AIN type processing. A variety of triggers are known including the full range of AIN triggers,
such as off-hook, off-hook delay, private dialing plan, virtual numbers (e.g. 500, 800, 900), terminating attempt, etc. In response to the PIC trigger, the switch 10 launches a TCAP query through the STP 20 to the ISCP 22. The ISCP 22 accesses the
relevant call processing record (CPR) for the subscriber. In a mediated service the CPR will identify a plurality of carriers and/or the carriers' databases, for calls satisfying different predetermined criteria.
The ISCP 22 proceeds to obtain call control or routing information that the switch 10 needs to process the call. If conditions relating to the present call conform to criteria for processing of the call by the local exchange carrier, then the
ISCP 22 retrieves a CPR from its own internal SCP database to determine how to process the call and provides an appropriate response message back to the switch 10. If the call meets other criteria, then the ISCP 22 communicates with a selected one of a
plurality of other SCPs, such as SCP 28 through the SS7 network (i.e., via STP 26). Alternatively, the ISCP 22 may communicate with the SCP 28 via the SINET 30. The ISCP 22 may access a separate database to obtain information needed to direct messages
through the SS7 network to the appropriate SCP.
The one SCP 28 will contain a call processing record (CPR) for providing the subscriber a customized service on the particular type of call. The subscriber has previously communicated to the carrier how certain calls should be processed, and the
carrier's personnel will have established the appropriate CPR in the SCP 28.
The SCP 28 accesses the CPR to determine how to process the particular call and returns an appropriate instruction, in a TCAP response message, to the ISCP 22. The ISCP 22 in turn performs a mediation function. Specifically, the ISCP 22
processes the instructions from the alternate carrier's SCP to insure validity and compatibility with the processes of the elements of the local exchanged network that will handle the call. Based on validated instructions, the ISCP formulates an
appropriate TCAP response message. The ISCP 22 transmits that message through SS7 links and one or more | | |
