Rule based capacity management system for an inter office facility

[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.

[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] FIG. 2 illustrates one embodiment of the monitoring system of FIG. 1.

[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] 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] FIG. 11 provides a graphical illustration of one embodiment of a rule tree for use by the software program of FIGS. 4-5.

[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] 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.

[0018] 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's and the links 16 are various types of trunks.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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 10 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] Exemplary Screen Shots

[0034] 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.

[0035] 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's for the engineering areas. The user can then transfer specific IOF'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 & C Chart” components as well as selecting an engineering function of the user.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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:

[0041] TechName is ORB.

[0042] If this antecedent is met, the following three consequents are made:

[0043] Required Feature==TechName;

[0044] Required Feature==FrameHeight;

[0045] Required Feature==EquipmentDetail.

[0046] The consequents dictate a name, frame height, and equipment detail description for the ORB.

[0047] 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.

[0048] 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&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.

[0049] 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.

[0050] 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.

[0051] Referring now to FIG. 14, one type of forecast is a D&C chart, as discussed in Table 2, above. A screen shot 650 illustrates one example of a D&C chart. In continuance with the present example, the D&C chart 650 analyses an office repeater bay (“ORB”). A vertical axis 652 identifies a bit rate level (e.g., DS1) 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.

[0052] 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.

[0053] Conclusion

[0054] 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.

[0055] 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.