Abstract:
An element management system (“EMS”) interfaces between a telephone company computer or a terminal for use by a telephone company system administrator or customer service representative, and a telephone network element such as a central office or a group of central offices. In order to store and process subscriber data during the time periods when a telephone computer system is busy controlling telephone switching functions and therefore giving low priority to such data, the EMS contains a proxy database and maintains it between the periods when access to the telephone computer system is desired and available, without detrimentally involving the telephone computer system, the telephone switching network or any elements thereof. The EMS is capable of operating as the sole repository of subscriber data in a telephone computer system configured to operate in such an environment. The proxy database effectively mirrors subscriber data in one or more central offices and/or other network elements of the telephone computer system. By utilizing the proxy database, the EMS (i) provides relatively current subscriber data to telephone company personnel and systems, and (ii) accepts telephone network configuration commands from such personnel and systems, communicates the commands to the corresponding network elements, and upon receiving information indicating that the commands have been carried out, provides verification information to the client personnel and systems.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    This invention relates to an improved element management system for interfacing between a telephone system and a service provider such as a telephone company, to maintain information as to subscriber services and subscriber line configurations. A telephone system is a type of network, and includes network elements such as central offices or groups thereof in which telephone computer systems control corresponding portions of a telephone switching network in accordance with subscriber requirements and subscriber line configurations.  
           [0002]    Subscriber services information may include such items as class of service (e.g. business or residential), call waiting, call forwarding, caller ID, the billing plan desired, the long distance carrier desired, the maintenance plan desired, etc. Subscriber line configurations may include such items as the number and types of lines at the subscriber&#39;s home or business, which equipment at the subscriber&#39;s home or business is owned by the subscriber and which equipment is owned by the telephone company, the type and location of the equipment, information as to leased lines, etc.  
           [0003]    In a typical telephone system, well over a hundred, and sometimes a few hundred parameters may be needed to describe the services and line configurations for a single subscriber.  
           [0004]    As telephone networks normally have large numbers of subscribers, the amount of data as to subscriber requirements and subscriber line characteristics (“subscriber data”) is large. Since the telephone computer systems must give priority to controlling switching functions so that the telephone system operates with high efficiency and minimal “busy” time, access by telephone company customer service representatives and other personnel to subscriber data is relatively slow, and the subscriber data is updated at relatively long intervals. Thus the information available as to subscriber data does not reflect recent changes and may therefore be inaccurate, and there is sometimes an inordinate delay in implementing changes desired by a subscriber.  
           [0005]    To provide a more responsive interface between one or more (in some cases as many as several hundred) central offices of a telephone network and telephone company customer service representatives or other telephone company personnel or systems, an Element Management System (“EMS”) is frequently utilized. Such an EMS maintains subscriber data in a database which can more quickly and accurately respond to queries from telephone company personnel or automated systems without significantly degrading the switching performance of the telephone network. However, existing EMS units lack sufficient responsiveness to meet desired performance levels.  
           [0006]    Accordingly, an object of the present invention is to provide an improved Element Management System and method for interfacing between a telephone system and a service provider such as a telephone company, to more expeditiously maintain and change information as to subscriber services and subscriber line configurations.  
           [0007]    A further object of the invention is to provide a database in the EMS which reflects up-to-date data respecting the network element(s) that the EMS manages, such that the data contained in the EMS database is a functional copy of corresponding data utilized by those elements of the telephone switching network which are managed, at least in part, by the EMS.  
           [0008]    A further object of the invention is to provide a capability for synchronizing the data stored in the database of a particular EMS with the corresponding data utilized in the network element(s) involved, when the network element data is changed by portions of the telephone network, or associated personnel, independently of the particular EMS.  
           [0009]    A further object of the invention is to automatically detect changes in the data stored in or utilized by the managed element(s) of the telephone switching network which corresponds to the data stored in the EMS, and to update the EMS database accordingly; with the frequency of detection of such changes and the frequency of updating the EMS database being separately configurable for each network element.  
         SUMMARY OF THE INVENTION  
         [0010]    The present invention provides an improvement to a network element management system which communicates information from a telephone switching network to a client system.  
           [0011]    A proxy database stores data respecting subscriber requirements and subscriber line information. A bidirectional network interface arrangement couples information from at least one element of the network to the proxy database, such element having an associated subscriber data storage means.  
           [0012]    Initialization means initializes the proxy database by storing in said proxy database subscriber data corresponding to subscriber requirements and subscriber line characteristics received from the associated subscriber data storage means via the network interface means.  
           [0013]    Database updating means is coupled to the network interface means for repopulating the proxy database with, current subscriber data stored in the subscriber data storage means associated with the network element to update the data in the proxy database.  
           [0014]    Query means is responsive to a query signal from the client system to retrieve corresponding data from the proxy database and communicate the same to the client system.  
           [0015]    Database synchronization means serves to synchronize the subscriber data stored in the proxy database with the corresponding subscriber data stored in the network element.  
         SUMMARY OF PREFERRED EMBODIMENT OF THE INVENTION  
         [0016]    As herein described, according to a preferred embodiment of the invention there is provided, in a network element management system for a telephone switching network, an arrangement for communicating information from a telephone switching network to a client system, and for communicating configuration commands from a client system to the network. The arrangement includes a proxy database for storing data respecting subscriber services and subscriber line configurations, and a bidirectional network interface for coupling information and command signals from and to at least one element of the network.  
           [0017]    Initialization means is provided for initializing the proxy database in a bulk mode at the startup of the element management system, by storing in the proxy database data corresponding to subscriber services and subscriber line configurations received from at least one network element via the network interface means. In response to command signals from the client system, database updating means causes the proxy database to be repopulated with current subscriber data stored in or for at least one network element, to update the data in the proxy database.  
           [0018]    Query means responsive to a query signal from the client system retrieves corresponding subscriber data from the proxy database and communicates the data to the client system.  
           [0019]    Configuration means responsive to a network element configuration command signal from the client system translates the configuration command signal into a corresponding network element command signal, and communicates the network element command signal to a corresponding network element via the network interface means. The configuration means, upon receiving a corresponding item of subscriber data from the network element via the network interface means, (i) stores the corresponding item of subscriber data in the proxy database to update the database, and (ii) communicates a corresponding response message back to the client system.  
           [0020]    Database synchronization means synchronizes the subscriber data stored in the proxy database with the corresponding subscriber data stored in or for the corresponding network element, by (i) downloading log files from the network element, (ii) parsing the log files to detect any changes in the corresponding subscriber data made by systems other than the element management system, (iii) transmitting network element commands to the network elements to retrieve the corresponding subscriber data from them, and (iv) updating the proxy database with the retrieved corresponding subscriber data.  
       
    
    
     IN THE DRAWING  
       [0021]    [0021]FIG. 1 is a functional block diagram of an element management system incorporating a proxy database arrangement according to the present invention, showing connections between the element management system, a telephone network element, a client system, and related elements.  
         [0022]    [0022]FIG. 2 is a functional block diagram showing the element management system signal flow involved in initialization of the proxy database.  
         [0023]    [0023]FIGS. 3A and 3B constitute a high level flow chart of the initialization process.  
         [0024]    [0024]FIG. 4 is a functional block diagram showing the element management system signal flow involved in providing responses to queries from a client system requesting subscriber data.  
         [0025]    [0025]FIGS. 5A and 5B constitute a high level flow chart of the client query process.  
         [0026]    [0026]FIG. 6 is a functional block diagram showing the element management system signal flow involved in communicating configuration commands to network elements in response to configuration command signals from a client system.  
         [0027]    [0027]FIGS. 7A and 7B constitute a high level flow chart of the configuration change request process.  
         [0028]    [0028]FIG. 8 is a functional block diagram showing the element management system signal flow involved in synchronization of the proxy database with a corresponding network element.  
         [0029]    [0029]FIGS. 9A and 9B constitute a high level flow chart of the synchronization process. 
     
    
     GENERAL DESCRIPTION  
       [0030]    In order to store and process subscriber data during the time periods when a telephone computer system is busy controlling telephone switching functions, i.e. most of the time, an Element Management System (“EMS”) is provided in the form of an auxiliary computer system that contains and maintains a database (the “proxy database”) of subscriber data.  
         [0031]    The EMS interfaces between (i) a client system such as a telephone company computer or a terminal for use by a telephone company customer service representative; and (ii) a telephone network element having an associated facility for storage of subscriber data, such as a central office [which includes a corresponding telephone computer system and telephone switching network portion] or a group of central offices.  
         [0032]    The EMS maintains the proxy database between the periods when access to the telephone computer system is available, without detrimentally involving the telephone computer system, the telephone switching network or any elements thereof. The EMS is capable of operating as the sole repository of subscriber data in a telephone computer system configured to operate in such an environment.  
         [0033]    With its proxy database, which effectively mirrors subscriber data in one or more central offices and/or other network elements of the telephone computer system, the EMS (i) provides relatively current subscriber data to telephone company personnel and systems, including automatic detection and incorporation of changes in such data made by systems or personnel associated with the telephone network but independent of the EMS, and (ii) accepts telephone network configuration commands from personnel and systems served by the EMS, communicates the commands to the corresponding network elements, and upon receiving information indicating that the commands have been carried out, provides verification information to the client personnel and systems.  
       DETAILED DESCRIPTION  
       [0034]    Overview  
         [0035]    Telephone switching systems are designed primarily to handle switching functions. While they do store data detailing the configurations of the telephone lines connected to the switches and can provide that information on request, such information handling tasks are conducted at a very low level of priority. Consequently, responses to requests for information are generally slow.  
         [0036]    Proxy Database  
         [0037]    The element management system (“EMS”)  100  according to a preferred embodiment of the present invention, shown functionally in FIG. 1, contains and maintains a proxy database subsystem or proxy database  20  which reflects substantially up-to-date subscriber data as to the services being provided to customers, viz. subscriber requirements and corresponding subscriber line configurations of the central offices and/or other network elements managed by the EMS.  
         [0038]    The managed data is fetched from the managed network elements  31 ,  31 ′,  31 ″ etc. via network connections and stored in the proxy database  20 . The EMS  100  also has the capability to populate the proxy database in bulk or single unit mode. The signal flow involved in initialization of the proxy database is shown in FIG. 2.  
         [0039]    Subscriber data respecting the network element  31  is stored in an associated subscriber data storage means  31 A. Similarly, subscriber data respecting each of the other network elements  31 ′,  31 ″ etc. is stored in corresponding associated subscriber data storage means (not shown). The subscriber data storage means associated with a particular network element may be physically situated at the location of said network element or at a remote site. Reference herein to a network element implicitly includes reference to the associated subscriber data storage means.  
         [0040]    Query Process  
         [0041]    The proxy database  20  of the EMS mirrors, i.e. contains and maintains on an essentially current basis, a functional copy of the subscriber data (i.e., data as to subscriber requirements and subscriber line configurations) of the managed network elements  31 ,  31 ′,  31 ″ etc. Thus clients such as telephone company personnel and systems can obtain up-to-date subscriber data by querying the EMS rather than querying the central offices or other network elements and waiting a relatively long time for response. The signal flow involved in the query process is shown in FIG. 4.  
         [0042]    Network Element Configuration Change Process  
         [0043]    The clients will also send requests to the EMS for configuration changes, i.e. to change certain data in the network elements. A subsystem of the EMS then translates the requests into corresponding network element commands and communicates the commands to the appropriate network elements. Upon receiving responses from the network elements indicating the requested changes have been made, the response messages are sent to the clients, and the proxy database is updated accordingly. The signal flow involved in this configuration changing process is shown in FIG. 6.  
         [0044]    Network Element—Proxy Database Synchronization Process  
         [0045]    A synchronization subsystem  22  in the EMS  100  keeps the subscriber data in the proxy database  20  synchronized with the network element subscriber data. This subsystem informs the managed network elements  31 ,  31 ′,  31 ″ etc. as to which data needs to be monitored for the EMS. The network elements input changes in such data into log files, and the synchronization subsystem obtains the log files from the network elements at scheduled time intervals, or in real time. For improved data transfer efficiency, information as to which records have been changed in the time interval since the last accessing of the log files can be parsed out therefrom. The EMS sends commands to retrieve the changed data from the network elements and store the changed data in the proxy database. The signal flow involved in the synchronization process is shown in FIG. 8.  
         [0046]    Features and Functions  
         [0047]    The proxy database in the EMS keeps a functional copy of the network element subscriber data. The clients of the EMS communicate with the EMS instead of accessing the network elements directly.  
         [0048]    In a telephone system, an element management system is a type of operations support system (“OSS”) and part of a telecommunication management network (“TMN”), namely that portion which performs configuration management and security management functions. The present invention relates to the configuration management part of the element management system.  
         [0049]    Overall Architecture of Element Management System  
         [0050]    As shown in FIG. 1, the EMS  100  has the following subsystems, i.e. software modules:  
         [0051]    Proxy Database Subsystem  20   
         [0052]    Database Initialization Subsystem  21   
         [0053]    Database Synchronization Subsystem  22   
         [0054]    Network Resources Subsystem  23   
         [0055]    Network Interface Subsystem  24   
         [0056]    Operation, Administration and Maintenance (OA&amp;M) Subsystem  26   
         [0057]    Application Programming Interfaces (APIs)  25   
         [0058]    Log/Archive  27   
         [0059]    User Interfaces (“UI”) Server  28   
         [0060]    Operations Support System (“OSS”) Gateway  29   
         [0061]    Parser  30   
         [0062]    Proxy Database  
         [0063]    The proxy database subsystem  20  contains a functional copy of the data in network elements  31 ,  31 ′,  31 ″ etc. which are managed by the EMS, and reflects essentially up-to-date subscriber data of the network elements. The network elements may, for example, be telephone central offices. The proxy database subsystem has the following features and functions:  
         [0064]    a. The proxy database is initialized at the startup of the EMS.  
         [0065]    b. The proxy database can be populated with fresh data in either single unit or bulk mode; and is preferably initially populated in a bulk mode and thereafter populated in a single unit mode.  
         [0066]    c. Any changes in the network elements  31  made by sources outside the EMS are detected in such a way that the proxy database is updated by the synchronization subsystem  22 ; which automatically detects changes made to subscriber data by sources independent of the EMS, and stores the changed data in the proxy database.  
         [0067]    d. To query the data of the network elements  31 , the clients of the EMS only need to query the proxy database, thus optimizing the current status of the data available to the clients for a given allocation of network element resources.  
         [0068]    e. When the clients  32  of the EMS send configuration requests to the EMS to change the network element data, the network resources subsystem  23  validates the requests and translates the requests into corresponding network element commands. These translated commands are then sent to the network elements. If the commands are successfully executed, the proxy database is updated accordingly. By thus keeping the EMS “in the loop” as to such changes, the current status of the information in the proxy database as to such requested changes is maintained.  
         [0069]    Database Initialization Subsystem  
         [0070]    The proxy database needs to be initialized at the startup of the EMS  100 , using data obtained from the network elements  31 ,  31 ′,  31 ″ etc. The clients  32  can also repopulate the proxy database in single unit or bulk mode. The initialization and re-population can be scheduled by the OA&amp;M subsystem  26  or manually started by the system administrators.  
         [0071]    Database Synchronization Subsystem  
         [0072]    To maintain the data contained therein as current as is feasible consistent with the relatively low priority availability of network element resources for data exchange, the proxy database subsystem  20  needs to be kept synchronized with the data of the network elements  31 ,  31 ′,  31 ″ etc. This subsystem therefore has a mechanism to (i) detect changes made by sources independent of the EMS, and (ii) automatically update the proxy database based on the changes detected. The synchronization process can be scheduled or manually started from the OA&amp;M subsystem  26 .  
         [0073]    Network Resources Subsystem  
         [0074]    The network resources subsystem  23  takes care of data change requests from the clients  32  of the EMS. The requests are validated and translated into network element commands. The validated network element commands are sent to the network elements  31 ,  31 ′,  31 ″ etc. via the network interface subsystem  24 .  
         [0075]    After getting successful responses from the network elements  31 , the subsystem  23  (i) updates the proxy database accordingly. (ii) sends corresponding response messages back to the clients  32 , (iii) compares the old values with the new values in the proxy database, and (iv) sends the differences to the Log/Archive subsystem  27 .  
         [0076]    Parser  
         [0077]    The parser  30  performs two distinct functions. First, it parses log files from the network elements  31 . Second, it extracts changed subscriber data from the response sent back from the network elements.  
         [0078]    Log files are files that reside in each network element or the associated subscriber data storage means and/or an associated control system and contain information about data that has been changed in or for the network element. Since the log files obtained from a network element vary in format depending on the network element type, they need to be parsed to identify the data records that contain the changed data. The parser  30 , for instance, examines these log files to determine what data to retrieve from the corresponding network element for updating of the proxy database  20 .  
         [0079]    Since the changed data records retrieved from the network element are presented in different formats depending on the network element type, relevant data needs to be extracted, by the parser, from said records before being stored in the proxy database.  
         [0080]    Network Interface Subsystem  
         [0081]    The network interface subsystem  24  supports interfaces with different network elements based on specific protocols such as TCP/IP, X.25, for example.  
         [0082]    Operation, Administration and Maintenance Subsystem  
         [0083]    The operation, administration and maintenance (“OA&amp;M”) subsystem  26  provides services to both EMS clients and internal EMS subsystems for management of the EMS application system resources. Features and functions of the OA&amp;M subsystem include:  
         [0084]    a. Providing OA&amp;M resource management services to EMS clients. For example, such services allow telephone company system administrators to establish and change (i) the frequency of backup of EMS files, (ii) the frequency of interrogation of network elements by the synchronization subsystem, and (iii) security levels, user identification codes and passwords for access to and/or control of various aspects of the EMS and the network elements with which it is associated.  
         [0085]    b. Management of a configuration database incorporated in the EMS and containing information such as login identification codes and network addresses.  
         [0086]    c. Access protection of the OA&amp;M resources stored in the log/archive subsystem  27 .  
         [0087]    d. Management of the archive of the log/archive subsystem  27 .  
         [0088]    Log/Archive Subsystem  
         [0089]    The log/archive subsystem  27  provides services to both EMS clients and internal EMS subsystems for the management of the EMS logs (i.e., the recent change history logs) and archives, and functions as the gateway into the EMS Log database and archive within said subsystem.  
         [0090]    Application Programming Interfaces  
         [0091]    The application programming interfaces (APIs)  25  provide a communication infrastructure between the EMS  100  and its clients  32  across distributed and heterogeneous computing environments. Two categories of interfaces are included, namely (i) common object request broker architecture (“CORBA”) APIs and (ii) customizable APIS. Features and functions of the Application Programming Interfaces include:  
         [0092]    a. Determining where specific network resource objects (such as concentrators, satellite links, etc.) are.  
         [0093]    b. Access protection of the network resources.  
         [0094]    c. Directing requests from the EMS clients to the appropriate EMS subsystems and redirecting the responses from said subsystems back to the EMS clients.  
         [0095]    User Interfaces Server  
         [0096]    The user interfaces (“UI”) server  28  acts to couple the EMS to an external web to enable clients and remote users to utilize the web or wide area network  33  to provide services that the EMS cannot provide directly. Functions of the user interfaces server include:  
         [0097]    a. Providing a web based browser interface for EMS services.  
         [0098]    b. Converting user interface configuration requests into CORBA interface requests.  
         [0099]    c. Converting responses received via the web to a form usable by the EMS.  
         [0100]    d. Managing data communication sessions (open, closed, etc.) between the EMS and web based browsers.  
         [0101]    Operations Support Systems Gateway Subsystem  
         [0102]    The operations support systems (“OSS”) gateway subsystem  29  acts as a gateway between the EMS and other operations support systems such as Legacy OSS  34  that need access to the EMS services but are not supported by the CORBA interfaces. The features and functions of the operations support systems gateway subsystem include:  
         [0103]    a. Converting OSS-specific configuration requests into one or more EMS CORBA interface requests.  
         [0104]    b. Converting the responses back to the OSS-specific format.  
         [0105]    c. Managing data communication sessions (open, close, etc.) between the OSS and EMS CORBA interfaces.  
         [0106]    Operation of the Proxy Database  
         [0107]    The proxy database  20  has four principal modes of operation, namely: (1) Initialization; (2) Client query; (3) Network element data change request; and (4) Synchronization.  
         [0108]    Initialization  
         [0109]    When a new circuit (telephone line) is added to a telephone network switch or when the EMS starts up initially, the data in the proxy database must be initialized. FIG. 2 illustrates the operation of the software modules of the EMS when initialization is performed.  
         [0110]    First, the OA&amp;M module  26  requests an initialization to occur. This request is coupled to the initialization subsystem  21  via line  1 . The initialization subsystem issues a command on line  2  to the network interface subsystem  24 , which issues a corresponding command to the network element(s)  31  on line  3 . The network element(s) provides either the data, if it is available, or an error message, if a communication or other error occurs; and sends the data or error message on line  4  to the network interface subsystem  24 , which issues a corresponding response signal back to the initialization subsystem  21  on line  5 . The response signal is passed to the parser  30  on line  6 , for further data filtering, and then forwarded to the proxy database on line  7   a . Then the initialization subsystem  21  sends the response messages to the OA&amp;M module  26  via line  7   b.    
         [0111]    Details of the Initialization process  
         [0112]    This section describes, in more detail, the interaction between the different subsystems involved in the initialization process. FIGS. 3A and 3B illustrate the step-wise process flow of the initialization process.  
         [0113]    In Step 1, the OA&amp;M module sends a request to the initialization subsystem for initialization of a particular resource, for example, a telephone number. In Step 2, the initialization subsystem receives this request. In Step 3, the initialization subsystem issues a verify command to the network interface subsystem. The verify command is a switch command, which returns the data associated with a particular resource, specified as part of the command.  
         [0114]    In Step 4, the network interface subsystem issues a corresponding command, which wraps the verify command, to the network element. For example, if the network interface subsystem uses X.25 protocol to communicate with the network element, then it opens a session with the network element host. The network interface subsystem then sends the verify command, which is the data to be sent, through the session and then closes the session.  
         [0115]    In Step 5, the network element receives the verify command and provides either the resource data or an error message to the network interface subsystem as the response. In Step 6, the network interface subsystem passes the resource data or the error message back to the initialization subsystem after converting the data or error message back from the transmission format to the original format.  
         [0116]    In Step 7, the availability of the data is checked. If the data is available the program proceeds to Step 8. If the data is not available then the program proceeds to Step 12. In Step 8, the initialization subsystem passes the resource data to the parser for further data filtering, based on the verify translation table entries. The parser uses the resource data and the entries in the verify translation table to get the value for the features and functions associated with the resource.  
         [0117]    In Step 9, the parser determines whether it needs to send additional verify commands to the initialization subsystem. Most of the time, due to the low priority given to such data exchanges by network elements, all the data associated with a resource cannot be retrieved in response to a single verify command.  
         [0118]    In Step 10, the program either proceeds to Step 11 or loops back to Step 3 based on whether more verify commands need to be sent.  
         [0119]    In Step 11, the initialization subsystem has all the data pertaining to the resource and it then forwards this data to the proxy database by issuing database commands. In Step 12, the initialization subsystem sends the response message, i.e. whether the initialization was successful or not, to the OA&amp;M module.  
         [0120]    Client Query  
         [0121]    At times, a client, such as a user, an administrator, a service representative, or another system, will need to determine the status or configuration of, for example, a particular telephone line. Since such information resides in the proxy database, it can be obtained directly from that database without the necessity to access a network element such as the central office to which the particular telephone line is connected. The manner in which software modules of the EMS process a client query is shown in FIG. 4.  
         [0122]    Initially, the client  32  sends a query request to the appropriate application programming interface of the APIs  25  on line  1 , seeking subscriber data information associated with a particular network element of the elements  31 ,  31 ′,  31 ″ etc. (FIG. 1); such information being also contained in the proxy database.  
         [0123]    The application programming interface forwards the query request to the network resources subsystem  23  via line  2 . The network resources subsystem parses the request and translates it into a corresponding database query command, which is communicated to the proxy database via line  3 . The proxy database then searches for the requested information.  
         [0124]    Since the proxy database is concerned solely with data management, it responds much more quickly than would the network element itself. The query result, which may be the requested information or an error message if the requested information is not available or an error is encountered during the database search, is sent back to the network resources subsystem  23  via line  4 . The network resources subsystem then passes the query result to the originating application programming interface of the APIs  25  via line  5 ; and that application programming interface converts the result to an appropriate interface format and transfers it to the client  32  via line  6 .  
         [0125]    Details of the Client Query Process  
         [0126]    This section describes, in more detail, the interaction between the different subsystems involved in the client query process. FIGS. 5A and 5B illustrate the step-by-step process flow of the client query process.  
         [0127]    In Step 1, the EMS client sends a query request to the appropriate application programming interface, seeking subscriber data information associated with a particular network element. The application programming interface can be thought of as a server module that communicates with the EMS client.  
         [0128]    For example, the API could be a CORBA server, a Web Server, or any customized server that can service the EMS client. This server receives the requests from the client and sends responses from the EMS back to the client.  
         [0129]    In Step 2, the application programming interface forwards the query request to the network resources subsystem after removing the transmission information, such as the protocol headers and trailers, from the query. At this stage, the query is in the appropriate interface format as needed by the EMS.  
         [0130]    In Step 3, the network resources subsystem parses the request and translates it into a corresponding database query command. In Step 4, the network resources subsystem executes the database query command on the proxy database. In Step 5, a check is made on the availability of the requested information. If the requested information is available, the program goes to Step 6. If the requested information is not available, then the program proceeds to Step 7.  
         [0131]    The query result may be the requested information or an error message. If either the requested information is not available or an error is encountered during the database search, an error message is received as a result of the execution of the query command.  
         [0132]    In Step 6, the proxy database sends back the requested information to the network resources subsystem. In Step 7, the proxy database sends back an error message to the network resources subsystem. The program reaches Step 8 either through Step 6 or Step 7.  
         [0133]    In Step 8, the network resources subsystem parses the query result, translates it to the appropriate interface format and sends it to the originating application programming interface. In Step 9, the originating application programming interface transfers the translated query result to the EMS client and then the program exits.  
         [0134]    Since the proxy database is concerned solely with data management, it responds more quickly to a client query than the actual network element. Without such a proxy database, substantially more time would be required to process the client query, due to the additional steps described below:  
         [0135]    a. The query would have to be sent to the network element across the network;  
         [0136]    b. The network element would have to process the query and respond to it in addition to the other work it does; and  
         [0137]    c. The response would have to be received from the network element across the network.  
         [0138]    Network Element Data Change Request  
         [0139]    From time to time, the status or configuration of one or more telephone lines (or other components) associated with a network element needs to be modified, usually to reflect changes in subscriber data. In such an instance, the change is relayed to the corresponding network element, where the change actually occurs; and upon verification that the change has occurred, the proxy database is updated to reflect the change. FIG. 6 illustrates the operation of the cognizant software modules of the EMS when a data change is requested.  
         [0140]    First, a client  32  sends a data change request for a particular network element of the elements  31  to the appropriate application programming interface of the APIs  25  via line  1 . The application programming interface forwards the change request to the network resources subsystem  23  via line  2 . The network resources subsystem validates the request, based on the information in the proxy database. If successfully validated, the request is translated into a command or commands understandable by the particular network element. The network resources subsystem then issues the translated command to the network interface subsystem  24  via line  3 .  
         [0141]    The network interface subsystem is the module that actually communicates with the network element by taking the data change command from the network resources subsystem, converting it to an appropriate transmission format, such as TCP/IP or X.25, and forwarding it to the particular network element of the elements  31  on line  4 .  
         [0142]    If the change is successfully executed, the particular network element will send back a response to the network interface subsystem  24  via line  5 , where the response is converted back from the transmission format and sent back to the network resources subsystem  23  via line  6 . If there was an error, the network element will, instead of sending a positive response indicating the requested change was made or will be made, send an error message as a (negative) response.  
         [0143]    If the response is positive, the network resources subsystem  23  updates the proxy database accordingly via line  7   a,  to reflect the change made to the network element. Regardless of the nature of the response (positive or error), the network resources subsystem always communicates the response back to the client  32  on line  8  via the originating application programming interface, to which the response is communicated on line  7   b.    
         [0144]    Details of the Network Element Data Change Request Process  
         [0145]    This section describes, in more detail, the interaction between the different subsystems involved in the network element data change request process. FIGS. 7A and 7B illustrate the step-by-step process flow of the data change request process.  
         [0146]    In Step 1, the EMS client sends a data change request for a particular network element to the appropriate application programming interface. In Step 2, the application programming interface forwards the change request to the network resources subsystem. In Step 3, the network resources subsystem validates the request based on the information in the proxy database.  
         [0147]    Examples of the different types of validation are checks across different tables in the database (cross-datafile checks), checks across different records in the same table (cross-record checks), and checks across different fields in the same record (cross-field checks). For example, if telephone number 555-1212 has the feature called Call Forward Busy turned on then its Call Forward Busy Telephone Number must be set to a valid telephone number for the call to be successfully forwarded when telephone number 555-1212 is busy. This is an example of a cross-field check.  
         [0148]    In Step 4, a check is made as to whether the validation was successful. If the validation was successful, the program proceeds to Step 5. If the validation was not successful then the program proceeds to Step 13.  
         [0149]    In Step 5, the request is translated into command(s) understandable by the network element. Each network element has a specific set of commands that can be used to manipulate the data of that network element.  
         [0150]    In Step 6, the network resources subsystem issues the translated command to the network interface subsystem. In Step 7, the network interface subsystem, which is the module that actually communicates with the network element, takes the data change command from the network resources subsystem and converts it into an appropriate format (e.g., TCP/IP, X.25) [see Step 4 of the Initialization process—FIG. 3A—for more detail in this respect]. In Step 8, the network interface subsystem forwards the data change command to the network element.  
         [0151]    In Step 9, the network element sends back a response to the network interface subsystem. In Step 10, the network interface subsystem converts the response back from the transmission format and sends it to the network resources subsystem.  
         [0152]    In Step 11, a check is made as to whether the change was successfully executed or not. If the change was successfully executed, then the program proceeds to Step 12. If the change was not successfully executed, the program proceeds to Step 13.  
         [0153]    In Step 12, the network resources subsystem updates the proxy database accordingly, to reflect the change made to the network element. In Step 13, the network resources subsystem sends a response, indicating whether the data change request was successful or not, back to the EMS client through the originating API; and then the program exits.  
         [0154]    Synchronization of the Proxy Database  
         [0155]    The data in the proxy database  20  must be periodically updated to accurately reflect the status or configuration of the network elements  31 ,  31 ′,  31 ″, etc. FIG. 8 illustrates the operation of the cognizant software modules of the EMS  100  when the contents of the proxy database are synchronized with the subscriber data of a network element.  
         [0156]    The synchronization process starts when the OA&amp;M module  26  sends an update request to the synchronization subsystem  22  via line  1 . Upon receiving the request, the synchronization subsystem sends a request to the network interface subsystem  24  on line  2 ; and the network interface subsystem sends a corresponding request to the corresponding one or more of the network elements  31 ,  31 ′,  31 ″ etc. for downloading a log file to the network interface subsystem on line  4 , which routes the log file being downloaded to the synchronization subsystem  22  via line  5 .  
         [0157]    Once the log file is received, the synchronization subsystem sends it to the parser  30  via line  6  for identifying they are identified by a signal from the parser to the synchronization subsystem on line  11 ; and the synchronization subsystem requests the changed data from the network elements  31  on line  7  to the network interface subsystem  24 , which communicates the request to the network elements  31  via line  8 .  
         [0158]    The network elements  31  reply by sending the changed data back to the network interface subsystem  24  on line  9 , which routes the changed data to the synchronization subsystem  22  on line  10 . Thereafter the synchronization subsystem transfers the changed data to the parser  30  via line  11  for further data filtering, and then stores the filtered data in the proxy database via line  12 . Then the synchronization subsystem  22  sends a reply signal to the OA&amp;M module  26 , either confirming that the subscriber data has been updated in the proxy database, or delivering an error message.  
         [0159]    Details of the Synchronization process  
         [0160]    This section describes, in more detail, the Interaction between the different subsystems involved in the synchronization process. FIGS. 9A and 9B illustrate the step-by-step process flow of the synchronization process. In Step 1, the synchronization process starts when the OA&amp;M module sends an update request to the synchronization subsystem.  
         [0161]    In Step 2, the synchronization subsystem sends a request to the network interface subsystem to download the log file from the network element. The log file contains the changes made to the data in the network element.  
         [0162]    In Step 3, the network interface subsystem converts the request to an appropriate transmission format, such as TCP/IP or X.25, and sends it to the network element [see Step 4 of the Initialization process—FIG. 3A—for more detail in this respect].  
         [0163]    In Step 4, the network interface subsystem routes the downloaded log file to the synchronization subsystem. In Step 5, the synchronization subsystem sends the log file to the parser for identifying data changes in the network element. The parser looks only for the data changes made since the last time the log file was downloaded.  
         [0164]    In Step 6, a check is made to find whether there are any data changes made by systems outside of the EMS. The parser does not consider the changes made through the requests by the EMS because those changes would have already been incorporated in the proxy database during the data change request process [refer, to step 12 of the network element data change request process—FIG. 7B]. If there are any changes, the program proceeds to Step 9. If there are no data changes, then the program proceeds to Step 7.  
         [0165]    In Step 7, the parser sends a response to the synchronization subsystem notifying it that there were no data changes. In Step 8, the synchronization subsystem sends an appropriate reply to the OA&amp;M module and the program exits.  
         [0166]    In Step 9, the parser sends a list of resources that have changed to the synchronization subsystem. In Step 10, a check is made to find whether there are any resources left to be synchronized. If there are any resources left to be synchronized, then the program proceeds to Step 11. If not, then the program proceeds to Step 15.  
         [0167]    In Step 11, the synchronization subsystem sends a request to the initialization subsystem to initialize that particular resource. The Initialization process takes place as previously described; except that the request for initialization comes from the synchronization subsystem instead of the OA&amp;M module.  
         [0168]    In Step 12, a check is made to find whether the initialization was successful. If the initialization was successful the program proceeds to Step 14. If not, then it proceeds to Step 13.  
         [0169]    In Step 13, the synchronization subsystem adds the current resource to the list of resources whose initialization failed. Then the program loops back to Step 10.  
         [0170]    In Step 14, the synchronization subsystem adds the current resource to the list of resources whose initialization succeeded. Then the program loops back to Step 10. In Step 15, the synchronization subsystem sends a report of both the list of resources whose initialization succeeded and the list of resources whose initialization failed to the OA&amp;M module.  
         [0171]    By means of synchronization, the proxy database is updated with the changes made to the network element data by systems independent of the EMS. Due to the proxy database being synchronized, there is no need to contact the network elements to obtain such network element data; thus enabling faster response to client queries as described in the previous Client Query section.  
         [0172]    Advantages of the Proxy Database  
         [0173]    The proxy database system of the present invention provides substantially faster response times for client queries, as was discussed in the section on Client Query.  
         [0174]    Since the data in the proxy database is synchronized frequently, it matches the data in the corresponding network elements on a reasonably current basis and eliminates the need to directly access the network elements to retrieve data; thus lessening the burden on the network elements and avoiding the degradation in network performance which would otherwise result.  
         [0175]    Since the data in the proxy database is centralized, it is possible to utilize the EMS to do administration of the telephone network itself in addition to administration of individual network elements.