WO1994019753A1

WO1994019753A1 - Method and system for sizing a packet switched network

Info

Publication number: WO1994019753A1
Application number: PCT/US1994/002105
Authority: WO
Inventors: Reginald Eugene Saunders
Original assignee: Bell Communications Research, Inc.
Priority date: 1993-02-22
Filing date: 1994-02-14
Publication date: 1994-09-01
Also published as: CA2156056A1; EP0686287A1; JPH08507397A; EP0686287A4

Abstract

Method and system for sizing of an entity, such as a communications network. In the preferred embodiment, the system is a PC-based (10) data-driven interactive computational tool for the sizing of packet switched networks. The method includes the step of defining an input screens text file, a calculation processing text file, and a report format text file, each of which are user-modifiable. The method also includes the steps of entering (42), by a user, network sizing data to the computer in response to predefined input queries (62) related to network requirements contained in the input screens file, and calculating (44) the number of network components according to the process calculation file utilizing the entered network sizing data so as to determine the size of the network. The method also includes generating a network sizing report (46) of the number of network components according to the report format file and configuring the network based on the network sizing report.

Description

METHOD AND SYSTEM FOR SIZING A PACKET SWITCHED NETWORK

Technical Field

The present invention relates generally to communications networks and, more particularly, to a method and system for the sizing of a packet switched communications network.

Background Art

In many businesses and scientific applications, one of the most common tasks performed is "sizing." In the computer hardware industry, each installation must be analyzed to determine, for example, CPU requirements and the number of peripheral devices and workstations needed. Computer software applications are examined to determine the amount of memory required and the amount of storage needed for programs and databases.

In the communication or data switching industry, it is often necessary to determine information such as the number of CPU nodes, interface processors, and access concentrators needed to configure a particular network. The sizing process usually begins by first obtaining the necessary entity requirements or specifications. For example, in the case of the communication or data switching network, it would generally consist of a list of attributes and parameters such as traffic characteristics, response time expectations, and protocols to be supported. In many instances, the information needed to perform the .sizing function may not be intuitively obvious to the end-user of the entity, thus increasing the amount of pre- installation support needed by the end-user.

After these critical requirements or specifications have been obtained, the values are used in a series of decision making and computational algorithms to derive the actual number of entity components (e.g. CPU nodes, interface processors and access concentrators) . These decision making and computational algorithms, often unknown by the end-user, generally would have to be provided by the manufacturer. Since each entity installation would vary from one site to t e" next, either site-specific algorithms would have to be provided, increasing the cost of pre-installation support, or generic algorithms would have to be provided, which may not accurately size the entity.

The final step in the process is to produce a report of the size of the entity — the quantity of entity components — for the entity engineers, who are responsible for acquiring and integrating the components.

Existing entity sizing tools for handling the functions mentioned above have generally applied a more passive than interactive approach. The algorithms were usually delivered to the user on several pages of printed material. As mentioned above, they were either very user-specific and so generic that the user had a hard time interpreting them, or worse yet, they produced sizing results that were highly inaccurate. Although later tools introduced interactive capabilities, they still did little if anything to address the site- specific variability issues.

It has been suggested to use a spreadsheet application, such as Lotus 1-2-3, to develop an entity sizing tool. There are several features it possesses which lend themselves well to a user-adaptable sizing utility. Spreadsheet applications typically provide a fairly easy-to-learn programming language for end-users. However, since it is a programming language, changes (e.g. adding a screen) made to a spreadsheet application sizing tool would require programming changes and spreadsheet Saves. Changes made to the semantic flow of the interactive end-user sessions would also require programming changes and spreadsheet Saves. Finally, in order to run and maintain a spreadsheet application sizing tool, the end-user would have to be licensed to have a copy of the software package on each machine expected to support the tool.

Use of a functional expert shell, such as that disclosed in United States patent number 4,866,634, issued to Reboh et al., has also been proposed. Such a system combines the concepts of expert systems, spreadsheet systems and relational database systems to draw conclusions based on the application of encoded knowledge (cause/effect, situational, and the like) to a specific set of facts.

It is therefore desirable to have a truly versatile entity sizing tool, one which would include an executable program and a set of text files, without the need and overhead of a relational database management system. By utilizing text files, all necessary end-user modifications can be made to the tool without impacting (requiring program changes and/or compilation) the accompanying executable program.

Disclosure OfThe Invention

It is therefore an object of the present invention to provide a method and system for improved interactive data-driven entity sizing.

It is another object of the present invention to provide a method and system for interactive screen- oriented data-driven entity sizing, which allow the entry of sizing attributes and parameters in any order deemed necessary end convenient by the user.

It is a further object of the present invention to provide a method and system for interactive data-driven entity sizing, which allow the user to maintain multiple sets of sizing attributes and parameters for a particular entity so that "sizing studies" can be performed.

According to a preferred embodiment of the present tool, the user is presented with a high-level menu screen which allows the selection of one of three entity sizing functions. The user may input a particular set of attributes and parameters for an entity, perform the necessary sizing calculations based on the specified set of attributes and parameters, or produce a report of the results of the calculations performed using the specified set of attributes and parameters. If the user selects the input function, a series of data entry screens are displayed. These screens contain textual inquiries requesting the entry of specific data items, such as a "yes" or "no," or a data quantity. The text, presentation sequence, and format of each screen are preferably determined primarily by a user-adaptable screens definition file and secondarily by the user responses entered on prior screens. Each screen data item is assigned a unique data item number in the screen definition file. The user has the ability to escape at any point to the high- level menu screen and resume on any screen in the series or start with the first screen. After the last screen in the series, the user is preferably returned to the first screen.

If the user selects the calculation function, the user remains on the high-level menu screen while the following is performed. A predefined user-adaptable calculation definition file is read and processed. It contains a list of working variables and a series of decision making and computational algorithms. These algorithms reference by number the data items entered during the input function. The working variables are used to store the interim and final results of the calculations defined by the algorithms. Upon successful completion of processing, a completion message is displayed. Otherwise, an appropriate error message is displayed.

If the user selects the reporting function, the user remains on the high-level menu screen while the following is performed. A predefined user-adaptable report definition file is read and processed. It -6-

contains a series of text strings (literals) , carriage control characters, and working variables. The text strings are used to produce the heading and keyword entries on the report. The carriage control characters enable the user to tabularize the output. Lastly, the working variables are those created during the calculation function. Upon successful completion of processing, the report output is sent to the local printer. Otherwise, an appropriate error message is displayed.

In carrying out the above objects and other objects and features of the present invention, a method is provided, for use with a communications network and a computer, for sizing the network. The method comprises defining an input screens text file, a calculation processing text file and a report format text file, each of which are user-modifiable. The method also comprises inputting by a user network sizing data to the computer in response to predefined input queries relating to network requirements contained in the input screens file, and calculating by the computer the number of network components according to the process calculation file utilizing the inputted network sizing data so as to determine the size of the network. The method also comprises generating a network sizing report of the number of network components according to the report format file and configuring the network based on the network sizing report.

A system is also provided for carrying out the method. The advantages accruing to the present invention are numerous. For example, the present invention employs flexible entity sizing functions to support a complicated engineering process with a practical user programmable tool.

The above objects and other objects, features, and advantages of the present invention will be readily appreciated by one of ordinary skill in the art from the following detailed description of the best mode for carrying out the invention when taken in connection with the accompanying drawings.

BriefDescription ofthe Drawings

FIGURE 1 is an illustration of a system for carrying out the methodology of interactive, data-driven entity sizing of a packet switched network according to the present invention;

FIGURE 2 is a flowchart illustrating the methodology of a first entity sizing function associated with interactive, data-driven entity sizing of a packet switched network according to the present invention;

FIGURE 3 is a functional representation of the input screens module utilized by the present invention;

FIGURES 4a-4c are representations of logical screen types, quantitative screen types and protocol quantitative screen types, respectively, for use with the present invention; FIGURE 5 is a flowchart illustrating the methodology of a second entity sizing function associated with interactive, user-adaptable, data-driven entity sizing according to the present invention;

FIGURE 6 is a functional representation of the calculation module utilized by the present invention;

FIGURE 7 is a flowchart illustrating the methodology of a third entity sizing function associated with interactive, user-adaptable, data-driven entity sizing according to the present invention; and

FIGURE 8 is a functional representation of the report module utilized by the present invention.

BestMode For Carrying Out The Invention

Referring now to Figure 1, there is shown a system 10 for implementing the methodology for interactive, user-adaptable, data-driven entity sizing of a packet switched network of the present invention. As shown, the system 10 includes a personal computer 12 for performing necessary computations, an input means, such as a keyboard 14, a mouse 16 or the like, through which a user interacts with and provides information to the computer 12, a display 18 through which the computer communicates with the user and an output/storage means, such as a printer 20 or the like.

Most preferably, the computer 12 includes a hard disk, as well as random access memory (RAM) and read-only memory (ROM) . The present invention contemplates use of an executable program, which could be written in the C programming language, with a window interface supported by an appropriate software package, such as the Beechwood Screen Generator software package. Of course, any suitable programming language can be used coupled with an appropriate window interface software package (e.g. X-Windows) . Instead of a relational database, the present invention also contemplates use of "flat files" which preferably can be modified with a simple text editor, such that the data structures can be easily tuned by an end-user without the need and overhead of a relational database management system.

The present invention provides a method and system, or tool, for performing an entity sizing function in an interactive, user-variable fashion, as illustrated by the flowcharts shown in Figures 2, 5 and 7. In the preferred embodiment, the entity is a packet switched communication network and the tool utilizes three basic modules, i.e. an input module, a calculation module, and a report module, which are implemented as functions to perform entity sizing. As shown in Figure 2, at step 40 the user is invited to select one of the three functions to begin the process for sizing the packet switched network. At steps 42, 44 and 46, the computer determines which function was selected and executes the appropriate module, as described in greater detail below. If the user selected the "Quit" option instead of selecting a sizing function, at step 48 entity sizing is ceased.

■inyu* Mogul With continuing reference to Figure 2, if the user selected the Input function, wherein the input module is executed by the computer beginning at step 50. A functional representation of the input module is shown in Figure 3. The most practical means of collecting the entity's attributes is via a "screen-form." Therefore, the entire user input interface is preferably accomplished with an interactive data-driven design.

In a typical design, the end-user is presented a series of input screens which request the entry of specific information relating to network requirements. To collect the large amounts of data needed to configure a given entity, a large number of input screens would be necessary. In some cases, the number of screens required could exceed one hundred. Screen definitions and screen handler code would have to be created for each of these screens, and each would have to be compiled with the input module. A minor change to one screen would result in the need to recompile and/or remap the input module. Since there are often quite a few variations in entity configuration from one site to another, site dependent screen software would have to be developed, making releases of the tool site dependent. Accordingly, the present invention utilizes a flexible screen management approach to eliminate the above-noted problems.

IBM* gcrunt rilt In the preferred embodiment, three (3) basic screen categories are defined and used to design six (6) generic screen types, rather than defining individual screens for each set of input data. The first category consists of logical screens which require a true or false (e.g. yes/no) response. The second category consists of quantitative screens which require specific numeric values, and the third category consists of protocol quantitative screens which require specific numeric values for a group of protocols. Screen types one and two correspond to categories one and two, respectively, and screen types three through six correspond to category three. Each of the screens is considered generic because the text portions of the screens are entry-protected software-populated fields. In the preferred embodiment, the text displayed in these fields is extracted from a user-defined and populated input screens file (ISF) . A typical ISF is as follows:

5:24,5,NUMBER OF 9.6 KBPS TRUNKS;25,5, NUMBER OF 56 KBPS TRUNKS;

5:26,5, UMBER OF 9.6 KBPS TRUNKS PER INTERFACE UNIT;27,5,NUMBER OF

56 KBPS TRUNKS PER INTERFACE UNIT

1:28,1,CAN 9.6 KBPS AND 56 KBPS TRUNKS BE COMBINED ON THE SAME INTERFACE UNIT (YES OR NO);29,1,CAN ACCESS LINES AND TRUNKS BE

COMBINED ON THE SAME FEP (YES OR NO);52,l,CAN DIFFERENT PROTOCOLS

BE COMBINED ON THE SAME FEP (YES OR NO)

4130,4,TRANSMIT PACKETS PER SECOND LOAD PER 9.6 KBPS DATA BASE

ACCESS LINE;31,4,RECEIVE PACKETS PER SECOND LOAD PER 9.6 KBPS DATA BASE ACCESS LINE

4.32, ,TRANSMIT PACKETS PER SECOND LOAD PER 56 KBPS DATA BASE

ACCESS LINE;33, ,RECEIVE PACKETS PER SECOND LOAD PER 56 KBPS DATA

BASE ACCESS LINE.

Each screen type allows a specific maximum number of input values. Screen Type l allows a maximum of four "yes/no" input values. Figure 4a illustrates a sample screen Type l including two possible logical inputs. Screen Type 2 allows a maximum of six (6) numeric input values. Figure 4b illustrates a sample screen Type 2 including two possible inputs. Screen types 3 through 6 allow a maximum of two protocol sections each of which accepts either six or seven numeric input values. Figure 4c illustrates a sample protocol quantitative screen including two protocol sections, each with four input values.

In the preferred embodiment, an original sequential number is assigned to each input. The need to be able to define composite type screens in the future has been anticipated in the input module design. A new screen type could be defined (type 6 + n) and a type assigned to each input field of the new screen. The input type will have a value between 1 and 6 representing values corresponding to the screen types described earlier. The screen type and input type will be identical for types 1 through 6. In the preferred embodiment, there are three attributes associated with each screen: screen type, input number, and input type.

The text (i.e. the questions) for each screen is preferably contained in the ISF, previously described and shown above. Each screen is defined in the order in which it is to be presented to the end-user. One screen is defined per file entry, or record. As shown above, the format of each entry is screen type followed by a colon and at least one input segment, which includes an input number, an input type, and the input text string separated by commas. All input segments consisting of number, type, and text are terminated by a semi-coIon except the last segment, which is terminated by a new- line character. A predetermined maximum number of characters (e.g. 160) may be specified for the text of each input segment.

In addition to the screen entries, the present invention allows conditional constructs to be placed in the ISF. A typical conditional construct is as follows:

IF [1]

{ 3:2,3,NUMBER OF DIRECT ACCESS TERMINALS;3,3,NUMBER OF DIAL-UP ACCESS

TERMINALS

3: ,3,DIAL-UP ACCESS USAGE PER TERMINAL (CCS/TERM) ;5,3, PERCENT ALL

TERMINALS BUSY IN BUSY PERIOD

3:6,3,TRANSMIT PACKET PER SECOND LOAD PER TERMINAL;7,3, RECEIVE PACKET PER SECOND LOAD PER TERMINAL

3:8,3,TRANSMIT AVERAGE PACKET SIZE;9,3, ECEIVE AVERAGE PACKET SIZE 3:10, ,CALL ATTEMPTS PER TERMINAL;11,3,NUMBER OF TERMINATIONS PER PORT

3:12 ,3,NUMBER OF PORTS PER INTERFACE UNIT;13,3,NUMBER OF INTERFACE UNITS PER (AC) FEP 2:16,2,OVERHEAD PACKET LOAD AS A PERCENT OF DATA PACKETS;17,2,PACKET LOAD ADJUSTMENT PER CALL SET-UP }

4:18,4,FORECAST OF 9.6 KBPS DATABASE ACCESS LINES;19,4,FORECAST OF

56 KBPS DATABASE ACCESS LINES 4:20,4,FORECAST OF 9.6 KBPS NETWORK ACCESS LINES (INCLUDING

LANS);21,4,FORECAST OF 9.6 KBPS NETWORK ACCESS LINES (INCLUDING

LANS)

4:22,4,NUMBER OF 9.6 KBPS ACCESS LINES PER INTERFACE

UNIT;23,4,NUMBER OF 56 KBPS ACCESS LINES PER INTERFACE UNIT 5:24,5,NUMBER OF 9.6 KBPS TRUNKS;25,5,NUMBER OF 56 KBPS TRUNKS.

These conditional constructs allow the presentation of the screens to be end-user response driven. The user can then define the screen universe and only the screens pertinent to a particular sizing activity will be displayed, based on the placement of the conditional constructs. As shown above, the format of the conditional construct is ^MiF" (starting at column 1) followed by at least one blank space, an open bracket "[", an input number, a close bracket "]", a blank space, and a skip argument. The construct is terminated by a new-line character.

The conditional construct is preferably interpreted in the following manner. If the response to the input identified by the input number is affirmative ["yes" for type l or non-zero for all others], the screen(s) immediately following the construct are displayed. If, however, the response to the input is not affirmative, a skip of the specified number of screens is performed. If the skip argument is omitted, a default skip of one screen is performed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability. input Processing

Referring once again to Figures 2 and 3, at step 50 the computer determines whether or not an entity data file, which is stored on the hard disk, exists. Typically, the entity data file includes the results of a screen population of a prior invocation of the entity sizing tool. In the preferred embodiment, the entity data file also includes the questions asked and the answers provided by the user. If an entity data file does exist, at step 52 the computer loads the contents of the entity file into the RAM memory at step 52a. As shown in Figure 3, this includes allocating screen control tables and associated data structures at step 52b, and allocating an aggregate data structure for each input at step 56c.

Screen control tables contain information which dictates the order in which input screens are presented to the user. The screen control tables are user-defined and created from the ISF itself. More specifically, the screen control tables are created from the conditional constructs of an ISF. The data structure is referred to as "aggregate" in that it contains an element for each of the three input categories (i.e. logical, quantitative, and protocol quantitative) . The data structures also contain elements to store the associated input number, input type and input text string.

If an entity file does not exist, at steps 54 and 56 the computer creates an entity file and loads a user-defined ISF. It should be appreciated that an entity file is created for the specified entity and the information contained in the input screens file is loaded into the data structures during the first invocation of the input module. As best shown in Figure 3, the loading of the ISF includes several steps. First, a series of edits and validations are performed on the information in the ISF at step 56a. This includes parsing the input screen records and checking for proper syntax at steps 56b and 56c, respectively. If there are problems, an appropriate message can be displayed to the user at step 56d. The input module also allocates an aggregate data structure for each input at step 56e and allocates a set of data- structures for the screen control tables at step 56f. The conditional construct information of the ISF is loaded in the data structures used for the screen control tables.

With continuing reference to Figures 2 and 3, at step 58 the computer examines the screen control tables to determine which input screen to display to the user. At step 60 the computer determines whether or not to display the next input screen based on the screen control table. If the next screen should not be displayed, at step 62 that input screen is skipped and control returns to step 58, wherein the computer examines the screen control tables to determine the next screen to display. If the next screen should be displayed, at step 64 the screen is displayed to the user. The design then allows the end-user to populate the screen (i.e. answer the questions geared toward site-specific variability issues) using standard type, over-type, tab, and erase conventions.

As shown in Figure 2, at step 66 the computer processes the screen input. As best shown in Figure 3, this entails several steps. For example, input processing includes managing keyboard entry at step 66a, e.g., such that striking the "Enter" key, or some other confirmatory action, causes the inputted information on the current screen to be placed into the appropriate input data structure. Input processing also includes editing/validating screen entries at step 66b, so as to ensure that quality data is entered. This can be accomplished by parsing screen entry fields at step 66c and checking syntax at step 66d. If improper information has been entered, the inputted information is rejected and an appropriate message is displayed to the user at step 66e.

After screen input processing is complete, at step 68 the computer awaits the entry of a defined

"Escape" function key, or some other similar confirmatory action, to indicate to the computer that no additional screen input is forthcoming. If the key is not depressed, control flow returns to step 58, wherein the computer examines the screen control tables to determine the next screen to display. If the key is depressed, at step 70 the input on the current screen is preferably stored in the appropriate input data structure, the input data and screen control structures are written to the entity file, and the input module is exited, with control flow returning to step 40 as shown in Figure 2.

g-ftl9 .l t.i9B Moflult

If the user selected the Calculation Module at step 40 of Figure 2, at step 44 the computer would execute the calculation module, a flowchart of which is shown in greater detail in Figure 5. A functional representation of the Calculation Module is shown in Figure 6. There is a seemingly limitless variety of calculations which the end-user may wish to perform. The difficulty arises deciding which calculations should be implemented. As mentioned earlier, there are often many variations in entity configuration from one site to another. Although some commonality would exist in many of the calculations, there would no doubt be a large number of calculations which would be site dependent. This would also require maintaining multiple versions of a site dependent tool. For these reasons, the present invention utilizes a flexible calculation processing design to compensate for the above-noted problems.

Process Calculation Pile Instead of coding each calculation directly into the module, the calculations to be performed are placed in a user-defined and populated process calcula¬ tion file (PCF) . In addition to calculation entries, conditional constructs may be placed in the PCF. These constructs allow the calculations performed to be driven by end-user responses. The universe of entity calculations can therefore be defined and only those calculations pertinent to a particular sizing activity will be performed, based on the placement of the conditional constructs in the PCF. A sample PCF with an associated conditional construct is as follows:

VAR ■

T1,T2,T3,AA,BB,CC,DD,DD2,EE,FF,GG,HH,II,JJ,MM,NN,00,PP,QQ,RR,SS, TT,UU,W,WW,XX,YY,ZZ,AAA,BBB,CCC,DDD,EEE,FFF,GGG,HHH,III,JJJ,KKK, IΛL,MMM,NNN,000,PPP,QM,RRR,SSS,TTT,UUU,VVV,WWW,XXX,YYY,ZZZ,AAAA, BBBB,CCCC,DDDD,EEEE,FFFF,GGGG,HHHH,IIII,JJJJ,KKKK,LLLL,MMMM,NNNN, 0O0O,PPPP,QQQQ,RRRR,SSSS,TTTT,UUUU,XL,X2,X3$

IF [1]

{ AA » [3] * [4] * [5] * .01 BB - AA * 1.325 CC - BB + [2] / (11) DD CC / [ 12 ] }

EE [ 18 ] + [20] FF [ 19 ] + [211 GG EE / [22] HH FF / [23] II [ 24 ] / [26] JJ [ 25 ] / [27]

As shown above, the first line that appears in the PCF is the working variables definition record. As shown above, the format of the definition entry is "VAR" (column 1) followed by a blank space and an equal sign ("■")•> Immediately after the equal sign and any intervening blank spaces comes the list of working variable names, preferably separated by commas. Each variable name can be up to three characters (preferably alphanumeric) in length and a predefined maximum number of variables (e.g. 85) may be specified. The variable list is terminated by a dollar sign ("$") and the entry is terminated by a new-line character. Of course, other delimiters or symbols may be utilized. Preferably, calculation entries follow the definition entry, and only one calculation is allowed per line. The design supports the full range of arithmetic operations (i.e. addition, subtraction, multiplication, division and exponentiation) . The operands of each calculation are the screen inputs and/or the working variables described above. The PCF can contain numerous operators. For example, the '&' operator is valid only for protocol quantitative entries and variables. It indicates that a summation of the individual protocol quantities is to be performed. The '>' operator indicates that the maximum of the operands is to be determined. If the operands are protocol entries or variables, the maximum operation is performed individually for each adjacent protocol. Another operator is the '<' , which indicates that a minimum of the operands should be selected. If the operands are protocol entries or variables, the minimum operation is performed individually for each adjacent protocol, when a screen input is referenced in a calculation, the preferred format is: blank space, open bracket ("["), input number, close bracket ("]"), and blank space (or new-line character) . The results of each calculation are preferably assigned to a working variable by preceding the operands and operator(s) with 'variable

The format of the PCF conditional construct is substantially similar to the conditional construct for the ISF discussed above, i.e. "IF" (column 1) followed by a blank space, an open bracket, an input number, a close bracket, a blank space and a skip argument. The construct can be terminated by a new-line character.

The PCF conditional construct is interpreted in the following manner. If the response to the input identified by the input number is affirmative (i.e. "yes" for type 1 or non-zero for all others) , the calculation(s) immediately following the construct are performed. A skip of the specified number of calculations is performed if the response is not affirmative. If the skip argument is omitted from the construct, a default skip of one calculation is per¬ formed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability.

calculation Processing

Referring now to Figures 5 and 6, at step 78 the computer begins interpreting the process calculation file. As shown, this includes reading and interpreting the working variables definition record of the PCF at step 80. As best shown in Figure 6, this process entails several procedures. Processing of the working variable definition record includes editing/validating the record entries at step 80a. This is accomplished by parsing the record and checking syntax at steps 80b and 80c, respectively. Appropriate messages can be displayed to the user at step 80d if there are errors.

Processing of the working variable definition record also includes allocating a variable aggregate data structure at step 80e for each variable in the definition list. This data structure is substantially similar to the data structure described above with reference to the ISF, with the exception of the inclusion of a screen text element. As shown above, the working variable definition record is user-defined and is basically a string of valid variable names, defining the names to be used in subsequent calculations to be performed.

With continuing reference to Figures 5 and 6, at step 82 the computer allocates at least one temporary aggregate data structure within which interim computational values associated with compound computations and the like are stored. At step 84, the computer continues its interpretation of the PCF, by processing the conditional constructs. As shown in Figure 6, this includes editing/validating the conditional constructs at step 84a by parsing the construct and checking the construct for proper syntax at steps 84b and 84c, respectively. Appropriate messages can be displayed to the user at step 84d if errors are found in the construct contents.

As shown in Figure 5, at step 86 the computer determines whether or not to process the next record based on the conditional construct. If the next record should not be processed, at step 88 the computer performs a conditional record skip, and control flow returns to step 84, as shown in Figure 5. If, however, the next record should be processed, at step 90 the computer edits/validates that calculation record. As with previously described edit/validations, this includes parsing the calculation record at step 90a, checking the record for proper syntax at step 90b and issuing appropriate messages at step 90c if errors are found.

With continuing reference to Figures 5 and 6, the computer next processes the calculation record at step 92. At step 94, the computer performs the calculation operation. In the preferred embodiment, each calculation entry is read and interpreted, being evaluated from left to right. Compound calculations, i.e. those consisting of multiple operations, preferably utilize the temporary aggregate data structures to store interim computational results. The value(s) in each temporary structure becomes the operand for the next right-most operation.

In the preferred embodiment, if a single value operand and a multiple value (i.e. protocol input) operand appear in an operation, the operation of the single value is applied to each multiple value, and the result is a multiple value. If, however, two multiple valued operands appear in an operation, the operation is performed using adjacent multiple value pairs, and the result is a multiple value. Furthermore, if two single value operands appear in an operation, the operation is performed using the single values, and the result is a single value. It should be noted that this design also includes an auxiliary summation operator, which sums the values of a multiple value operand and produces a single value, which can then be assigned to a working variable or used further in the calculation. Each working variable preferably has a value assigned to it before it can be used in a calculation.

Some calculations will consist of multiple operations. Accordingly, at step 96 the computer determines if the calculation being performed includes multiple operations. If so, at step 98 interim results are stored in the temporary data structure and control returns to step 94 for further calculations. If there are no more operations to perform, at step 100 the computer stores the end result in the appropriate variable aggregate data structure. At step 102, the computer determines whether the interpretation of the PCF is complete. If it is not, control flow skips to step 84, and steps 84-102 are repeated, as described above.

Report Module

If the user selected the Report Module at step 40 of Figure 2, at step 46 the computer would execute the report module, a flowchart of which is shown in greater detail in Figure 7. A functional representation of the Report Module is shown in Figure 8. Generally, once the input data has been obtained and the network sizing calculations have been performed using the data, the results are reported to the user. It would not be practical to code the formatting and reporting criteria directly into the module because of its site dependent nature. Again, flexibility is employed to allow the calculation results to be formatted and reported in a manner that best meets the needs of the user. The following describes the design approach used to accommodate the above.

Report Format Pile

In the preferred embodiment, the information used to control the production of each report is placed in a user-defined and populated report format file (RFF) . There are two basic types of report field designations that appear in the RFF. The first is a literal (e.g. header) type designation and the second is a working variable type designation. Each may have one or more associated carriage control characters (i.e. "!", "tab", ";" and the like) for line and page control. In addition to report file entries, conditional constructs may be placed in the RFF. These constructs allow the reporting performed to be driven by end-user responses. The universe of report output lines can therefore be defined and only those report lines pertinent to a particular sizing activity will be output, based on the placement of the conditional constructs within the RFF. A typical RFF with a conditional construct is as follows:

IF [1] {

NUMBER OF MLGH LINES>BB

NUMBER OF INTERFACE UNITS REQUIRED FOR DIAL-UP & DIRECT TERMINALS>DD MIXED>DD2 NUMBER OF INTERFACE UNITS REQUIRED FOR TRUNKS ONLY

>

ELSE

{

NUMBER OF INTERFACE UNITS REQUIRED FOR TRUNKS ONLY }

9.6 KBPS>II;

56 KBPS>JJ;

MIXEDX∞G

TOTAL>LLL NUMBER OF INTERFACE UNITS REQUIRED FOR ACCESS LINES ONLY

NETWORK ACCESS LINES>III;

DATA BASE ACCESS LINESXJJJ;

MIXED>KKK

TOTAL>MMM TOTAL NUMBER OF INTERFACE UNITS REQUIRED (ADD ALL PROTOCOLS, SPEEDS,

NUMBER OF FEPβ - TRUNKS ONLY>QQQ

COMBINED>RRR

IF[29] {

NUMBER OF FEP* - LINES & TRUNKS COMBINED>SSS

COMBINED>TTT

NUMBER OF FEPβ REQUIRED BASED ON LOAD (PPS)>ZZZ

ESTIMATED NUMBER OF FEPa REQUIRED BASED ON MEMORY>EEEE MAXIMUM NUMBER OF FEPs REQUIRED>FFFF

}

CPU* REQUIRED BASED ON PHYSICAL LIMITATIONS>GGGG CPUS REQUIRED BASED ON LOAD>KKKK CPU* REQUIRED BASED ON MEMORY>QQQQ MAXIMUM NUMBER OF CPUs REQUIRED>RRRR

NUMBER OF PACKET SWITCHES REQUIRED>UUUU

The literal and working variable fields are preferably placed in the RFF positions corresponding to the areas of the report page. Working variable names which have been defined in the PCF become reserved words and, therefore, are preferably not used within literal fields. If a working variable does appear within a literal field, the variable's numeric value will be substituted at the time the report is generated. Literal fields and working variables may appear on the same line.

The format of the conditional construct is substantially similar to the conditional constructs previously described above with reference to the ISF and the PCF. Accordingly, the preferred format is "IF" (column 1) followed by at least one blank space, an open bracket, an input number, a close bracket, at least one blank space, and a skip argument. The construct is terminated by a new-line character. When interpreting the conditional construct, if the response to the input identified by the input number is affirmative (i.e. "yes" for Type 1 or non-zero for all others], the report line(s) immediately following the construct are output. If, however, the response is not affirmative, a skip of the specified number of report lines is performed. If the skip argument is omitted from the construct, a default skip of one report line is performed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability.

Report Processing

During report processing, the computer performs two basic functions: interpreting the RFF 108 and writing the report output structure. As shown in

Figures 7 and 8, during interpretation of the RFF, the computer first allocates the report output structure at step 110. The report output structure is a data structure which will contain the report line(s) and results which make up the report. At step 112, the RFF conditional construct is processed. This includes editing/validating the conditional construct at step 112a by parsing the construct at step 112b and checking for properly syntax at step 112c. Appropriate messages can be displayed to the user at step 112d if errors are discovered.

With continuing reference to Figures 7 and 8, at step 114 the computer determines whether or not to process the next record in the RFF, based on the response to the input identified by the input number. As noted above, if the response is not affirmative, at step 116 the specified number of report lines are skipped and control flow returns to step 112 for further processing of the conditional construct. If, however, the response is affirmative (calculations were performed) , the computer processes the report line format at step 118. As best shown in Figure 8, this includes editing/validating the report line format at step 118a by parsing the calculation records, checking the records syntax and issuing appropriate messages at steps 118b, 118c and 118d, respectively. At steps 120 and 122 of Figure 7, the computer processes the carriage control functions and populates the report output structure with the information to be printed out, respectively.

Thus, as the report module reads and interprets each record entry in the RFF, the literal fields are written to the report output file, while the associated carriage control functions are performed. For each working variable, the variable value is written to the report output file, while the associated carriage control functions are performed. In the preferred embodiment, if the working variable has a single value, the value is written, whereas if the working variable has multiple values, each is written to the report output file preceded by an identifier (e.g. protocol) . The tab carriage control character is usually used to produce an output of columns.

With continuing reference to Figure 7, at step

124 the computer determines whether or not a new report page should be started. Typically, the page break carriage control character is associated with the first literal field (e.g. header) of each report page. If a page break character has not been encountered, at step 126 the literal fields for that particular page are printed. If there are additional records to be processed at step 128, control flow returns to step 112.

If a page break character was encountered as step 124, the computer determines at step 130 whether or not there are additional records in the RFF to be processed. If there are, control flow skips to step 112 and steps 114 through 128 are repeated as described above, i.e., records are processed and the report output structure is populated. If there are no more records to be processed, at step 132, report processing is complete, and the literal fields are printed. Control flow returns to step 40 of Figure 2.

Due to the complexity of and rapid changes in today's software systems, software is sometimes outmoded and in need of modification by the time it reaches the user. In other cases, there is such diversity in the user community that it is often necessary to develop and maintain site dependent software. An alternative to the above is to design and develop software that has a certain degree of user tunability or programmability. Therefore, the present invention contemplates a "generic" version of the software which can be tailored to meet the needs of the user.

It is understood, of course, that while the form of the invention herein shown and described constitutes the preferred embodiment of the invention, it is not intended to illustrate all possible forms thereof. It will also be understood that the words used are words of description rather than limitation, and that various changes may be made without departing from the spirit and scope of the invention as disclosed.

Claims

What is claimed is:

1. A computerized method of sizing a communications network, the method comprising: defining an input screens text file, a calculation processing text file and a report format text file, each of the text files being user-modifiable, the input screens file containing predefined input queries relating to network requirements, the calculation processing text file containing calculation entries for determining the size of the network, the report format text file containing report file entries for indicating the size of the network; inputting to the computer by a user network sizing data in response to the predefined input queries; calculating by the computer the number of network components according to the process calculation file utilizing the entered network sizing data so as to determine the size of the network; and generating a network sizing report of the number of network components according to the report format file.

2. The method of claim 1 wherein the step of defining an input screens file includes the step of defining a plurality of screen types, each screen type being useful for inputting an associated type of input data.

3. The method of claim 2 wherein the step of defining an input screens file includes the step of defining at least one input screens conditional construct, the conditional construct determining the order of input screens displayed to the user based on the entered network sizing data.

4. The method of claim 3 wherein the step of defining an input screens file includes the step of defining at least one data structure for storing the entered network sizing data.

5. The method of claim 1 wherein the step of defining a calculation processing file includes the step of defining at least one calculation entry for determining the size of the network based on the entered network sizing data.

6. The method of claim 5 wherein the step of defining a calculation processing file includes the step of defining at least one calculation processing conditional construct, the calculation processing conditional construct determining which calculation entries are performed based on the entered network sizing data.

7. The method of claim 6 wherein the step of defining a calculation processing file includes the step of defining at least two data structures, one of the two data structure for storing final calculation results, the other data structure for storing interim calculation results associated with compound calculations.

8. The method of claim 1 wherein the step of defining a report format file includes the step of defining at least one report file entry for defining the report format.

9. The method of claim 8 wherein the step of defining a report format file includes the step of defining at least one report format conditional construct, the report format conditional construct for determining the content of the report based on the entered network sizing data.

10. A computerized method of sizing a communications network, the method comprising: defining an input screens text file, a calculation processing text file and a report format text file, the input screens file containing predefined input queries relating to network requirements, the calculation processing text file containing calculation entries for determining the size of the network, the report format text file containing report file entries for indicating the size of the network; prompting a user to enter network sizing data to a computer in response to the predefined input queries; capturing by the computer the entered network sizing data in at least one data structure associated with the input screens file; calculating by the computer the number of network components according to the process calculation file utilizing the entered network sizing data so as to determine the size of the network; and generating a network sizing report of the number of network components according to the report format file.

11. The method of claim 10 wherein the step of defining an input screens file further comprises the steps of: defining a plurality of screen types, each screen type being useful for inputting an associated type of input data; defining at least one input screens conditional construct, the conditional construct determining the order of input screens displayed to the user based on the entered network sizing data; and defining at least one data structure for storing the entered network sizing data.

12. The method of claim 10 wherein the step of defining a calculation processing file further comprises: defining at least one calculation entry for determining the size of the network based on the entered network sizing data; defining at least one calculation processing conditional construct, the calculation processing conditional construct determining which calculation entries are performed based on the entered network sizing data; and defining at least two data structures, one of the two data structure for storing final calculation results, the other data structure for storing interim calculation results associated with compound calculations.

13. The method of claim 10 wherein the step of defining a report format file further comprises: defining at least one report file entry for defining the report format; and defining at least one report format conditional construct, the report format conditional construct for determining the content of the report based on the entered network sizing data.

14. A system for sizing a communications network, the system comprising: means for defining an input screens text file, a calculation processing text file and a report format text file, each of the text files being user-modifiable; input means for inputting by a user network sizing data to the computer in response to predefined input queries relating to network requirements contained in the input screens file; calculating means for calculating the number of network components according to the process calculation file utilizing the entered network sizing data so as to determine the size of the network; and generating means for generating a network sizing report of the number of network components according to the report format file, the network being configured according to the network sizing report.

15. The system of claim 14 wherein the means for defining an input screens file includes means for defining a plurality of screen types, each screen type being useful for inputting an associated type of input data.

16. The system of claim 15 wherein means for defining an input screens file includes means for defining at least one input screens conditional construct, the conditional construct determining the order of input screens displayed to the user based on the entered network sizing data.

17. The system of claim 16 wherein the means for defining an input screens file includes means for defining at least one data structure for storing the entered network sizing data.

18. The system of claim 14 wherein the means for defining a calculation processing file includes means for defining at least one calculation entry for determining the size of the network based on the entered network sizing data.

19. The system of claim 18 wherein the means for defining a calculation processing file includes means for defining at least one calculation processing conditional construct, the calculation processing conditional construct determining which calculation entries are performed based on the entered network sizing data.

20. The system of claim 19 wherein the means for defining a calculation processing file includes means for defining at least two data structures, one of the two data structure for storing final calculation results, the other data structure for storing interim calculation results associated with compound calculations.

21. The system of claim 14 wherein the means for defining a report format file includes means for defining at least one report file entry for defining the report format.

22. The system of claim 21 wherein the means for defining a report format file includes means for defining at least one report format conditional construct, the report format conditional construct for determining the content of the report based on the entered network sizing data.