Abstract:
A rule based capacity management system for an inter office facility is provided. The system includes a presentation layer for providing a graphical user interface to a user. The presentation layer is capable of receiving one or more rules from the user and for providing one or more analytical reports of the equipment based on the rules. The system also includes a data layer for storing rules, including the rules received from the user, and for connecting to an inventory system such as trunks integrated record keeping system (TIRKS). The system also includes a business layer interfacing between the presentation layer and the data layer. The business layer creates the analytical reports responsive to the rules and the raw data.

Description:
CROSS REFERENCE  
       [0001]    This application is a continuation of application Ser. No. 09/687,635 filed on Oct. 13, 2000. 
     
    
     
       BACKGROUND  
         [0002]    The present invention relates generally to monitoring systems and more particularly, to a system and method for monitoring and analyzing one or more pieces of telecommunication network equipment via a rule based system.  
           [0003]    It is often desired to monitor specific pieces of equipment of a telecommunication network. Traditionally, the monitoring has been provided in a flat-file, data dump format. For example, a conventional monitoring system can show if a piece of equipment in a network is up or down.  
           [0004]    However, it is often desired to have a deeper analysis of the equipment. Consider for example an inter-office facility, or “IOF”. An IOF can generically represent any node (or group of nodes) in a telecommunication network, and more specifically identifies one or more pieces of equipment used to interconnect various links or nodes, such as other networks, telephone lines, and/or trunks.  
           [0005]    One way to monitor equipment in an IOF is to use a system called the Trunks Integrated Record Keeping System (“TIRKS”). TIRKS is commonly used to help a regional bell operating company (“RBOC”) determine if facilities exist to provide service, track order completion, fulfill circuit orders, and perform inventory planning.  
           [0006]    Although TIRKS provides a great detail of information, the method of acquiring the information is very long and tedious. For example, in order to review equipment of an IOF, many steps must be performed on TIRKS. The information provided by TIRKS is in a raw-data format, and must be manually complied into a tabular form to represent the desired information (e.g., exhaust conditions of one or more pieces of equipment). If there is an exhaust condition, a new job must be created for TIRKS, and a job story must be manually created to satisfy various RBOC reporting requirements.  
           [0007]    What is desired is a system and method that automatically monitors one or more pieces of equipment, analyzes the pieces of equipment, and creates review and/or reports from the analysis. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]    [0008]FIG. 1 is a simplified description of several typical telecommunication networks and a monitor system according to one or more embodiments of the present invention.  
         [0009]    [0009]FIG. 2 illustrates one embodiment of the monitoring system of FIG. 1.  
         [0010]    [0010]FIG. 3 is a block diagram of an exemplary inter-office facility including several different pieces of equipment, which the present embodiment may monitor.  
         [0011]    FIGS.  4 - 5  provide a simplified diagram and flow chart that illustrates one embodiment of a software program for implementing features of the present invention.  
         [0012]    [0012]FIG. 6 is a flow chart that illustrates one embodiment of an inference engine for the software program of FIGS.  4 - 5 .  
         [0013]    FIGS.  7 - 10 ,  12 - 14  provide screen shots, such as from the computer system of FIG. 2, that illustrate different embodiments of the present invention.  
         [0014]    [0014]FIG. 11 provides a graphical illustration of one embodiment of a rule tree for use by the software program of FIGS.  4 - 5 . 
     
    
     DETAILED DESCRIPTION  
       [0015]    The present disclosure relates to capacity management systems, such as can be used in an inter-office facility or a central office (hereinafter inter-office facility, or “IOF”). It is understood, however, that the following disclosure provides many different embodiments, or examples, for implementing different features of the invention. Specific examples of equipment, connections, and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to limit the invention from that described in the claims.  
         [0016]    The following disclosure is divided into three different sections. First of all, an exemplary network and system is provided. The exemplary network identifies two telecommunication networks that may benefit from the present invention, and the exemplary system provides an example of a system for providing a graphical user interface for monitoring a specific node of either or both of the networks. Secondly, an exemplary software routine is discussed for implementing one embodiment of the graphical user interface. Thirdly, a plurality of screen shots are provided for illustrating the graphical user interface.  
         [0017]    Exemplary Network and System  
         [0018]    Referring to FIG. 1, the reference numerals  10  and  12  designate, in general, two simplified networks. The networks  10 ,  12  include a plurality of nodes  14  and a plurality of links  16 . A node is a point of connection in a network, and can be of any size. For example, an IOF is a node of a telecommunications network. Likewise, the IOF may include many different pieces of equipment (e.g., switches), each of which may also be considered a node of the network.  
         [0019]    In the illustration of FIG. 1, some of the nodes exist in both networks  10 ,  12 , and are therefore considered hubs. In the present example, each node includes a plurality of terminations where a service enters or exits the network  10 ,  12 . In continuance of the example, the nodes  14  are IOF&#39;s and the links  16  are various types of trunks.  
         [0020]    Referring also to FIG. 2, a monitoring system  20  may be connected to one or more nodes of the networks  10 ,  12  for monitoring one or more pieces of equipment of the nodes. In one embodiment, the monitoring system  20  includes a personal computer  21  with a graphics display  22 , a control unit  24 , and user inputs  26  such as a keyboard and pointer device. The computer  21  is connected through a log-on connection  30  to a file server  32 , which also includes hardware equipment found in a typical server computer. The file server  32  is further connected to an inventory system  34 , such as the TIRKS system discussed above. It is well known by those of ordinary skill in the art that various implementations can exist for the monitoring system  20 . For example, in some implementations, the monitoring system  20  may include a larger, mainframe-type computer that is either locally or remotely accessible by a terminal or personal computer. In other implementations, the monitoring system  20  may include a series of computers. In still other implementations, the monitoring system may include or utilize a series of adjunct processors to one or more of the nodes  14 .  
         [0021]    The monitoring system  20  can perform various software routines that can produce a series of graphical output images. The images are arranged in a unique way to illustrate the status of a particular node in the network  10 . For example, the images can be used by network engineers to analyze one or more particular pieces of equipment at the node. The images can also identify exhaust conditions that may occur. The images are produced by a unique software program, discussed below, and may appear on the graphics display  22 .  
         [0022]    Referring now to FIG. 3, for the sake of example, one node  14  of the network  10  or  12  may be an IOF  100 , as illustrated. It is understood, however, that the illustrated IOF of FIG. 3 is simplified for the sake of clarity, and many different configurations are well known in the art.  
         [0023]    The IOF  100  includes many different pieces of equipment that a network engineer may desire to review. In the present example, the IOF includes one or more pieces of equipment described in Table 1, below.  
                   TABLE 1                       Equipment   Description                   D4 102   A multiplexer/de-multiplexer unit for combining multiple           digital lines (e.g., DS0s) 104 into a digital trunk           (e.g., DS1) 106;       ORB 108   An office repeater bay that receives and amplifies a           DS1 signal 110;       M1-3 112   A multiplexer/de-multiplexer unit for combining multiple           DS1s 114 into a DS3 116;       MFT1 118   A 2-wire metallic frame terminal for amplifying           and/or balancing an analog or digital line 120;       MFT2 122   A 4-wire metallic frame terminal for amplifying           and/or balancing an analog or digital line 124;       SMAS 126   A port for allowing access and/or test of a digital line 128;       Switch 130   A trunk-side switch. Examples include a tandem (TMD)           or plain old telephone (POTS) system;       DCS1-0 132   A narrow band electronic cross-connect system that           reconfigures a DS0 134;       DCS3-1 136   A wide band electronic cross-connect system that           reconfigures a DS1 138;       DCS3-3 140   A broad band electronic cross-connect system that           reconfigures a DS3 142;       ATM 144   An asynchronous transfer mode switch for trunks 146;       DSL 148   A digital subscriber line splitter 148 for servicing a           DSL line 150.                  
 
         [0024]    In the present example, it is desired to allow a user such as a network engineer to monitor and review one or more of the pieces of equipment of the IOF  100 .  
         [0025]    Software Description  
         [0026]    Referring now to FIG. 4, a rule based capacity management computer program  200  can be used for creating reviews of various equipment in the IOF  100 . The computer program  200  may be performed by a single component of the monitoring system  20  of FIG. 2, or may have different aspects distributed throughout various processing platforms. In the present embodiment, the computer program  200  is performed by the file server  32 .  
         [0027]    The computer program  200  includes a presentation layer  202 , a business layer,  204 , and a data layer  206 . The presentation layer  202  provides, in the present embodiment, the graphical user interface (“GUI”) to the user (e.g., the network engineer). The GUI allows the user to set specific parameters for specific reviews and forecasts, and also presents the data from the reviews and forecasts. The presentation layer  202  may have many different components, such as listed in Table 2, below.  
                   TABLE 2                       Component   Description                   Review Monitor   A table screen that shows how many reviews a user           has created. It retrieves this information from the           server. It also provides a history of the reviews.       User Preference   This describes user preferences, such as a location and           responsibility, color of charts, and so forth.       D&amp;C Chart   A graph of demand vs. capacity for a particular           location.       Chart Properties   This allows customization of the D&amp;C Chart.       Forecast and   This is a report that allows the user to enter a single       Pending Job   event forecasted demand and/or a published forecast.           Also, the user can enter pending jobs that are not yet           input to the inventory system 208.       Review Details   This provides parameters defined for the review. It           identifies a time frame (e.g., monthly), forecast vs.           trend, warning levels, etc.       Standard   This identifies standard equipment configurations for       Configuration   the equipment. This is used to help determine the best       Selection   combination of equipment, since the equipment           configuration is fairly complex.       Local Office   This assists how the system automatically selects       Profile   equipment for a specific office.       Job Justification   This is a word-processing document automatically       Story   created by the system for specific vendors.           (e.g., RBOCs).       Rule Based   This allows the user (or an administrator) to edit rules.       Editor   For example, if an equipment type changes to a new           model, different rules (with different parameters) may           apply.                  
 
         [0028]    The data layer  206  includes a database of the raw data for the reviews and forecasts. The raw data comes from an inventory control system  208 , such as the TIRKS system discussed above, using conventional techniques. In addition, the data layer  206  includes the rules that have either been predefined or defined by the network engineer. The rules define such things as specific configurations of pieces of equipment, typical equipment performance parameters, equipment endurance estimations, and so forth. An exemplary group of rules is provided in Table 3, below.  
                       TABLE 3                                   Rule                           D4s come in groups of eight.           D4s can handle χ amount of capacity.           D4s last for 2 years.           Each D4 is 7 feet tall.                      
 
         [0029]    The business layer  204  serves as the engine between the presentation layer  202  and the data layer  206 . In the present embodiment, the business layer  204  can predict future capacity situations in one or more pieces of equipment being reviewed, and can predict exhaust conditions among the pieces of equipment. The business layer  204  may have many different components, such as listed in Table 4, below.  
                   TABLE 4                       Component   Description                   Review Database   This accesses the inventory system 208 (TIRKS)       Inference Engine   This is an artificial intelligence engine that performs           the analysis, including the material for the D&amp;C chart.       Job Justification   This creates the job justification story of Table 2 from       Story   the data layer 206.       Detect Equipment   This identifies equipment exhaust conditions, from the       Exhaust   Inference Engine       Generate D&amp;C   This creates the D&amp;C Chart of Table 2 from the data       Chart   layer 206.       Select Standard   This selects the appropriate standard configuration for       Configuration   the review.       Distribution   This distributes the results. For example, an email can           be sent to the user responsive to predetermined           “alarm” conditions.                  
 
         [0030]    Referring now to FIG. 5, the computer program  200  begins execution at step  250 , where the network engineer defines a review. The engineer can define the review by selecting one or more pieces of equipment, and various parameters for the equipment. The engineer can also used predefined rules, or modify rules as desired.  
         [0031]    At step  252 , data relevant for the review is tracked. In the present embodiment, the data may be acquired by the TIRKS inventory system  208 . The data is provided in a raw format. This data acquisition may occur over repeated intervals for a time span specified at step  250 .  
         [0032]    At step  254 , the data is analyzed. The analysis is based on the previously provided rules. For example, the data can be accumulated in a predetermined manner, such as is required by a job justification story.  
         [0033]    Referring also to FIG. 6, in one embodiment, the data can be analyzed using an inference engine  300  to perform certain forecasts. For example, a prediction that the system under review will “exhaust” at a certain point in the future can be made. Execution of the inference engine  300  begins at step  302  where the data acquired at step  252  (FIG. 5) is loaded. This data represents actual equipment status. At step  304 , the rule base is searched for a match. If the equipment matches a rule, then execution proceeds to step  306  where the rule is “fired.” A rule is fired by performing “consequences” of the rule. A consequence is an action or a conclusion that can be made from the particular piece of equipment. At step  308 , the consequence is provided for further analysis or reporting. Upon completion of step  308 , or upon a negative determination at step  304 , execution returns to step  302  until all of the data has been parsed (determined at step  309 ). As a result, each piece of data that has a corresponding rule will be fired on.  
         [0034]    Referring again to FIG. 5, at step  256 , the data is organized into a predetermined format and reported. The data may be reported as a job justification story, in an email notification, and/or in various graphs. Since, in some embodiments, the program  200  may perform over an extended period of time, the data reporting step  256  may be repeated throughout the period of time, in similar or different reporting formats.  
         [0035]    Exemplary Screen Shots  
         [0036]    The program  200  can also be described by showing several different images from the presentation layer  202 . Since the images are dynamic and interactive, screen shots of the images will be further discussed. The screen shots relate to exemplary situations of a node in the network, such as the IOF of FIG. 3. It is understood that different portions of the screen shots can be combined in various manners to produce even more examples of the graphical user interface.  
         [0037]    Referring now to FIG. 7, a screen shot  350  illustrates one example of the user preference component of Table 2, above. The screen  350  includes a menu  352  that allows a user to select one or more possible regions (or “engineering areas”) for review. Once a region is selected, a window  354  lists all the IOF&#39;s for the engineering areas. The user can then transfer specific IOF&#39;s to a window  356  for further review. Specific technologies can be selected in a window  358  and a time period for review can be determined in a window  360 . Once the selections are made, an initial review can be automatically created with a button  362  to create a review for the selected offices and technologies. Further customization is possible by activating a button  364 . This allows the user to choose “Review Monitor” and “D &amp; C Chart” components as well as selecting an engineering function of the user.  
         [0038]    Referring also to FIG. 8, one advanced option is to modify a local office profile with a screen  400 . In the present example, the configuration of an office repeater bay for a particular IOF (e.g. IOF  100  of FIG. 3) is to be modified (e.g., ORB  108 ). Each IOF can have different frame heights, and hold different quantities of equipment. As such, the user can change certain parameters of the equipment in the IOF.  
         [0039]    Referring also to FIG. 9, a standard configuration list  450  may be used to select a standard configuration for a specific IOF. In the present embodiment, the standard configurations are fixed and created by engineering boards and/or various equipment vendors.  
         [0040]    Referring to FIGS. 10 and 11, a rule-base manager screen  500  allows the user to define rules for the rule based capacity management program  200 . The screen  500  allows the user to embed or encode business logic, company guidelines, and equipment properties into the rules.  
         [0041]    The rules are organized in a tree structure  502 . One part of the tree structure  502  is a rule set  504 . The rule set  504  categorizes the different “areas” of rules, which identify where the rules will be applied and helps the inference engine  300  (FIG. 6) to identify which rule set to apply when the need arises. In the example of FIG. 10, a standard configuration rule set requirement (“StdConfigReq-S8”) is one group of rules for a specific IOF. Other examples of rule sets would include a group of rules directed to timing requirements, sizing requirements, and so forth.  
         [0042]    Another part of the tree structure  502  are rules  506 . Each rule includes an antecedent  508  and a consequent  510 . The antecedent  508  serves as a precondition for the rule, and the consequent  510  serves as a conclusion for the rule. In the example of FIG. 10, the rule office repeater bay (“ORB”) has one antecedent basis of:  
         [0043]    TechName is ORB.  
         [0044]    If this antecedent is met, the following three consequents are made:  
         [0045]    Required Feature==TechName;  
         [0046]    Required Feature ==FrameHeight;  
         [0047]    Required Feature ==EquipmentDetail.  
         [0048]    The consequents dictate a name, frame height, and equipment detail description for the ORB.  
         [0049]    By having the above described tree structure, a great deal of flexibility is provided to the rules. For example, if later on the user wants to change the rules for the ORB, the consequent or antecedent can be readily modified. As a result, changes to equipment, company guidelines, or other rule logic does not require the user to rebuild the entire rule based capacity management program  200 .  
         [0050]    Referring now to FIG. 12, another way to create a review is with the review monitor component of Table 2, above. A screen shot  550  illustrates one example of the review monitor component. The screen  550  creates a review (e.g., review “CRLS12DCO-5E M&amp;S ALL T”) for a particular piece of equipment (e.g., “DC0”) of an IOF (e.g., central office “CRLSCA12”). A window  552  allows the user to schedule the review and a window  554  allows the user to select a certain piece of equipment with a HECIG code. The HECIG code identifies a human equipment common interface (HECIG) value. All the HECIGs that were included are shown, and can be sorted by a function  556 .  
         [0051]    A window  558  allows the user to modify the growth rate of the IOF, if certain conditions are known. For example, a population area served by the IOF can be under relatively rapid expansion. A window  560  can allow different growth rate computation methods. A notification window  562  can be used to activate email notification of the user when certain conditions are met. A forecast button  564  causes a forecast and pending jobs window to appear, discussed below.  
         [0052]    Referring to FIG. 13, a forecast and pending job screen  600  is used to illustrate different forecasts and jobs that make up a review. The screen  600  can be divided into two different sections: a forecast section  602  and a pending jobs section  604 . The forecast section  602  indicates the status of a job (e.g., whether the current job is being used), the HECIG code of the exact equipment type, date and quantity for the forecast, and a description of what is causing the demand for forecast. The user (acting as the “owner”) may create a forecast, may “insert” it in the review list, and may “include” or use the forecast in the review. The pending jobs section  604  identifies various equipment modifications that are being performed.  
         [0053]    Referring now to FIG. 14, one type of forecast is a D&amp;C chart, as discussed in Table 2, above. A screen shot  650  illustrates one example of a D&amp;C chart. In continuance with the present example, the D&amp;C chart  650  analyses an office repeater bay (“ORB”). A vertical axis  652  identifies a bit rate level (e.g., DS 1 ) for the ORB, and a horizontal axis  654  identifies time. A curve  656  identifies maximum capacity for the ORB. As can be seen, the maximum capacity has been increased at several times during the previous months, due to various enhancements to the ORB.  
         [0054]    A curve  658  identifies working or consumed capacity of the ORB up until the time of the last review. In the present case, the consumed capacity  658  has always been below the maximum  656 . A curve  660  identifies a projected trend for the consumed capacity  658 . As can be seen, the projected trend  660  intersects the maximum capacity  656  at a point  662 . In the present embodiment, the point  662  identifies a date of September 2002. This identifies to the user that an exhaust condition will probably occur at that date. The user may then respond appropriately, such as by increasing the maximum capacity for the ORB. The user may have requested email notification at a predetermined time before the point  662  (such as through the window  562  of FIG. 12). Since the review is performed for a period of time, more data will become available for analysis and a more accurate intersection point can be determined.  
         [0055]    Conclusion  
         [0056]    Thus, there is disclosed a system and method for monitoring and analyzing one or more pieces of telecommunication network equipment via a rule based system. In some embodiments, the system and method allow a user to quickly determine the status of the equipment. The system may be interactive, and can quickly provide specific information without providing superfluous or unnecessary information to the user. In addition, implementations of the various embodiments described above can be performed very quickly, as compared to conventional techniques, such as running a TIRKS online report facility.  
         [0057]    While the invention has been particularly shown and described with reference to the preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing form the spirit and scope of the invention.