CA2156056A1 - Method and system for sizing a packet switched network - Google Patents

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 whichare 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 calculating 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

WO94/19753 PCT~S94/02105 ~ 215~D56 l!~HOD AND SYSTE~ FOR SIZING
~- A PA(~KI~;'1' ~iW~ ;'l ~ORK

TeChn;(`~l Fjel~l The ~ ~ ~nt invention relate~ g~nerally to communication~ network~ and, more particularly, to a method and system for the ~izing of a packet switched communication~ network R~

In many bu~ines~es and scientific applications, one Or the most common tasks performed is ~gizing. n In the computQr hardware indu~try, each in~tallation mu~t be analyzed to determine, for example, CPU requiremcnt~ and the number of peripheral devices and work~tation~ ne~e~ Computer ~oftware applications ar~ examin-d to determine the amount of memory required and the amount of ~torag~ n99~ for ~ G~L ams and databa~

In the communication or data switching indu~try, it $~ oft~n ,c~ ~ry to determine information uch a- th- numb~r of CPU nodeq, interfac~ ~LO~ crs, and acce~ ronc~ntrator~ to configure a particular network The sizing ~o_roq usually begins by first obta~nin~ tha neces~ary entity requirements or specification~ For example, in the case of the communication or data swi~ch~g network, it would g~n~rally consist of a list of attribut~s and parameters such as traffic characteristics, response time expectation~, and protocols to be ~U~G~ ~ed In many WO94/19753 PCT~S94/02105 .; . ~

inst~n~e~, 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 su~o~L needed by the end-user After these critical requirements or specifications have been obtained, th~ values are used in a scri~s of decision making and computational algorithms to derive the actual number of entity components (e g CPU nodes, interface y or~ors and ar-~ q CG~ trators)- The~e deciQion making and computational algorithm~, often unknown by the end-user, ~c~Jlally would hava to be provided by the manufacturer SincQ ~ach Qntity installation would vary from one site to thQ nQxt, ith-r sit~-sp~cific algorithm3 would have to b~ provid~d, increa~ing the cost of pre-installation SU~GL ~, or g~n~r~c algorith~s would have to be provid~d, which may not accuratQly size the ~nti~y Th~ f~nal step in th~ ~r~ to produco a r~port of thQ ~i2Q of the entity -- the quantity of ~ntity co~pon~nts -- for th~ entity ~ngineers r who are r~ 1e ~or acquiring and integrating the compon~nt~

Exi~ting Qntity ~izing tool~ for handling the functlon~ ~QntionQd abov~ hav~ genQr~lly ~pplied a more p~aLiV~ than interactive approach The algorithm~ were usually delivered to the user on saveral pages of printed material A~ mentioned abovQ, they warQ either vQry user-spscific and so generic that the user had a hard timQ int~ eLing them, or wor~ y~t, they produced sizing results that were highly in~r~r~te Although lat~r tools i~.L~o~ r~ int~ractivs cap~biliti~s, they 3 PCT~S94/0210~
~ 21SqO56 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 themsQlves well to a user-adaptable sizing utility. Spreadsheet applicAtions typically provide a f~irly easy-to-learn programming language for end-users.
How~ver, since it is a ~LG~Lamming language, changes (e.g. A~ g a screen) made to a spr~ h~ot application sizing tool would require y~G~Lamming ch~nges and spreA~h~t SAves. Changes made to the ~emantic flow of the interactive end-user sessions would also require ~LG~L~mming changes and spre~h~t Sav~. Finally, in order to run and maintain a ~pr~A~h~t application sizing tool, thQ end-usQr would have to be licénsed to have a copy of the ~oftware package on each machine ~x~L_~ed to ~"'~ th~ tool.

U8e of a functional expQrt shell, such as that disclo~ed in United States patQnt number 4,866,634, is~ued to R~hoh et al., has also b~en ~ u~ Z 7-~. Such a ~y~tQm combines the CQ~ S of eX~CL ~ systems, ~L~adshQ~t systems and relation~l da~AhA~ systems to dr~w conclu~ions bas~d on tha application of encoded 2S knowledg~ (causa/affQct, situational, and the like) to a specific ~t of facts.

It is therefore desirable to have a truly versatilQ entity 5izing tool, one which would include an xecutabl~ ~lG~Lam and a set of text filQs, without the n~ed and overhead of a relational databasa management system. By utilizing text files, all necea~y end-user WO94/19753 PCT~S94/02105 2~~ -4-modlfications can be mAde to the tool without impacting (requiring program changes and/or compilation) the accompanying executable program.

Oi.~clos~-re (~f The ~I.v..~li0n It is ther~fore an ob~ct of the present invention to provid~ a method and systQm for improved interactive data-driven entity sizing.

It is another object of the ~rcs~nt invention to providQ a method and system for interactive screen-oriented data-driven entity sizing, which allow the entry of sizing attributes and parameters in any order dQem~d -r~9-~ry and conveni~nt by the u~r.

It is a further obj~ct of the present invention to provida a mQthod and sy~tQm for interactive data-driven entity sizing, which allow the user to maintain multiplQ s-t~ of sizing attributes and parametQrs for a particular entity so that "sizing studies" c~n be performed.

According to a preferred embodimQnt of the pre~nt tool, the u~er is pr~sented with a high-level menu ~creen which allows th~ ~election of onQ of three ntity ~izing functions. The us~r may input a part~c~lar s~t of attribute~ and par~mQt~rs for an ~ntity, perform the nec~ssary sizing calculations based on thQ spQcified ~et of attribute~ and parameters, or produc~ a ~yO~L of the results of thQ c~lculations performed using the specified sQt of attributes and parAmeter~.

WO94119753 PCT~S94/02105 ~ 215~05~

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 S data quantity. The text, presentation sequence, and format of each screen are prefera~ly determined primarily by a user-adaptable ~c~n~ definition file and ~:c..darily by the user re~ponsQs entered on prior screens. Each scr~en data item is assigned a unique data item number in the screen definition file. The us~r ha~ the ability to escap~ 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 ~eries, the user is preferably LeLuL,.ed to the lS fir~t ~cre~n.

If the usQr selects the calculation function, the u~er remains on the high-level menu screen while the following is performed. A predefined user-adaptable calculation definit$on file is read and ~-v~3~ed. It cont~in~ a list of working variables and a series of decision making and computational algorithms. These algorithms reference by number the data items entered during th~ input function. The working variables are u~d to ~tore the interim and final results of the 2S r~ ation~ defined by the algorithms. Upon s~cc~ssful completion of pLC_~ -ing, a completion msssage is di~played. Otherwise, an a~L G~L iate error message is displayed.
,.
If the user selects the Le~OL ~ing function, - 30 the user remains on the high-level menu screen while the following is performed. A predefined user-adaptable L~L ~ definition file i~ road and procesLed. It PCT~S9410210 2 ~S 6~ 6 -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 entriQs on the report. The carriage control characters enable the user to tabularize the output. Lastly, the working variables ars tho~e created during the calculation function. Upon 6"'~ ul completion of ~o~ssing, the LEyoL- output is ~nt to the loc~l printer. Otherwise, an appropriate error message is displayed.

In carrying out the above objects and other ob~ect~ and featur~s of tho pres~nt invention, a method is provided, for USQ with ~ communications network and a computcr, for sizing th~ network. The method lS comprises def ining an input screens text file, a calculation ~L._s~sing text file and a report format text fil~, each of which arc user modifiable. The method al o comprises inputting by a user network sizing data to the comput-r in raspons~ to predefined input queries relating to network require~ents contained in th~ input ~creens f ile, and calculating by the computer the numb~r of n~tt~h components according to the proce~ c~ tion fil~ utilizing th~ inputted network ~zing data so as to detQrmine the 5iZQ of the network.
2S The m~thod also comprises generating a network sizing ~VL ~ of the number of network com~G ~nts according to the report for~at file and configuring tho network ba~ed on the "c~ k sizing L~O~.

A system is also provided for carrying out the mcthod.

~ 21~560~

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 abov~ o~jects and other objecta, 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 thQ accompanying drawings Rrief ~escription of the nra~in~s FIGURE 1 is an illustration of a system for carrying out th~ methodology of interactive, data-driven entity ~izing of a packet switch~d network according to the pre~nt invention;

FIGURE 2 is a flowchart illustrating the methodology of a fir~t entity sizing function associated with int~ractive, data-driven entity sizing of a packet ~witched n~ 3~k according to the present invention;

FIGURE 3 i~ a functional ~e~lc3entation of the input s~7~n~ module utilized by thQ pre3ent invention;

FIGURES 4a-4c are r~La3~ntations of logical scr~Qn type~, quantitativ~ scrQen types and protocol quantitativQ screen types, re~pectively, for use with th~ nt invention;

wog4/1s753 PCT~S94/02105 5~

FIGURE S is a flowchart illustrating the methodology of a second entity sizing function associated with interactive, user-adaptable, data-driven entity sizing according to the presQnt invention;

FIGURE 6 is a functional representation of the calculAtion module utilized by th~ ~L~ ~nt invention;

FIGURE 7 is a flowchart illustrating the methodology of a third entity sizing function associated with interactive, user-adaptable, data-driven entity ~izing according to the ~ s~nt invention; and FIGURE 8 is a functional L~L.--~tation of the r-port module utilized by the pre~ent inv~ntion.

I~est Mo~e For ~rryin~ t The ~n~ention RQferring now to Figur~ 1, th~re is shown a sy~t-m 10 for implementing the methodology for int-ractiv , u~r-adaptable, data-drlvQn entity sizing o~ a packet ~witch~d n~twork of thQ presQnt invention.
A~ ~hown, the ~ystem 10 includQs a p~ o~Al computer 12 for p~rforming nQces~ry comput~tion~, an input means, uch ~ a k~yboard 14, a mousQ 16 or the like, through whi~h a us~r interacts with and provides information to the comput~r 12, a di~play 18 through which thQ computer com~unicatas with the user and an output/storage means, such a- a printer 20 or thQ lik~.

Most preferably, the computer 12 includes a hard di~k, A~ WQll a-~ random acce~s memory (~AM) and read-only memory (ROM). The pre~ent invention cont~mplates USQ of an executable ~-o~Lam, which could wo94ll97s3 PCT~S94/02l05 ~ ~IS~56 _9_ b~ 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 cour~Q, any suitable programming language can be used coupled with an appropriate window interface software package (e.g. X-Windows). Instead of a relational dat~ba~e, the present invention al~o contemplate~ use of "fl~t file~" which pref~rably can b~ modified with a simple text editor, such that the data structures can be e~sily tuned by an end-user without the need and ovQrh~ad of ~ relational d~taba~Q managemQnt system.

The present invQntion providQQ a method and sy~tem, or tool, for performing an entity sizing function in an interactive, user-variable fashion, as illu~tr~ted by tha flowchart~ ~hown in Figures 2, 5 and 7. In the prQferred Qmbodiment, th~ entity is a packet switched communication network and the tool utilizes thrQe basic module~, i.Q. an input module, a calculation modul~, and a r-port module, which ar~ implemented as function~ to p~rform entity ~izing. As, ~hown in Figure 2, at step 40 thQ u~er i~ inv$t~d to ~elcct one of the threQ functions to begin thQ ~L~ for sizing the packet ~witched network. At step~ 42, 44 ~nd 46, the computer determine~ which function wa~ selected and execut~ the ~p~.o~iate module, as d-~cribed in greater det~$1 b~low. If th~ u~er ~elect~d the "Quit" option in~tead of ~ cting a ~izing function, at step 48 ent$ty s,izing i~ ~e~s~

~ut Mod~le With con~ ing r~fQrence to Figur~ 2, if the u~er sslected the Input function, wherein the input modul~ xecute~ by the computer beginning at step 50.

WO94/19753 PCT~S94102105 ~ &~5 -lo-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 relatinq to network requirements To collect the large amounts of data nee~e~ to configure a given entity, a large number of input scree~s would be n~:f ~-ry. In some ca~es, the number of screens reguired could c~c_es~ one hundrcd Screen definitions and ~reQn handler code would have to b~ created for each of thasQ screens, and each would haYe to be compiled with the input module A minor change to one screen would result in the need to recompile and/or r-map th~ input module Sinca th~re are often quita a fQw variation~ in entity configuration from one site to another, ~ite depQndQnt screen softwarQ would have to be d-v-lop~, making release~ of the tool site dependent Accordingly, thQ present invention utilize~ a flexible S~ n manag~ment approach to eliminate the above-noted probl-m~

~ t ~ ~c F~
In the preferred ambodim~nt, three (3) basic screen categories are defined and used to design six (6) generic ~cre~n types, rather than defining individual screen~ for each set of input data The first category con~i~ts of logical screens which require a true or false (- g yes/no) response The -qcon~ category con~i~ts of quantitative screens which require specific numeric values, and the third category consists of W094/19753 PCT~S94/02105 ~ 6056 protocol quantitative screens which require specific numeric values for a group of protocols. Screen types one and two correspond to categories one and two, respectivQly, and screen types three through six correspond to category three. Each of the screens is considFsred generic becau~e the text portions of the scrQen3 are entry-protected softwa.e yv~ulated fields.
In the prcsferred embodiment, the text display~d in these ficslds~ is extracted from a ufSer-def$ned and populated input s~ n~ file (ISF). A typical ISF i5 as follows:

5s24,5,NUNB~R OF 9.6 KBPS TRUNXS;25,5, NUMB~R OF 56 KBPS TRUNXSs 5s26,5,NUNB~R OF 9.6 XBPS TRUNXS PER ~NTERFACE UNrT527,5,NUMBER OF
56 bBPS TRUNXS P~R ~h~nrACE UNrT
ls28,1,CAN 9.6 XBPS AND 56 XBPS TRUNXS B~ CONBSN~D ON T~E SANE
lS ~h~nFAC~ uNrT (Y~s OR No)t29~l~cAN ACC~:S~ LrNJ-~ AND SRUNXS BE
CONBrN~D ON T~E SAN~ FEP ~Y~S OR NO)5S2~1~CAN D~rrr~n~n~ PRO~OLS
B~ CONBIN~D ON SHE SAME ~P (Y~S OR NO) 4s30,4,SRANSNrS PACX~T~ PER S~COND ~OAD P~R 9.6 KBPS DA$A 3ASE
ACC~SS BrN~531,4,~r,-V~ PACXETS PER S~COND BOAD PER 9.6 XBPS DATA
BASX ACC~SS rrNX
4s32,4,TRANSMST PACX~TS P~R S~COND ~OAD P~R 56 XBPS DATA BASE
ACCESS ~rN~s33,4,~v~ PACX~TS PER S~COND BOAD PER 56 KBPS DATA
BAS~ ACC~SS I.rN~.

Each screen type allows a ~pecific maximum number of input valu--. Screen Type 1 allows a maximum of four "yes/no" input values. Figure 4a illustrate~ a ~mple cr~en Type 1 including two possible logical inputs. Scre~n Type 2 allows a maximum of six (6) nuceric input values. Figure 4b illustrates a sample scr~en Type 2 including two possible inputs. Screen types 3 through 6 allow a maximu~ of two protocol sections each of which accepts either six or seven num~ric input values. Figure 4c illustrates a sample protocol quantitative screen including two protocol 3S sections, each with four input values.

In the preferred embodiment, an original sequential number is assigned to each input. The need WO94/19753 PCT~S94/02105 .., i--to be able to define composite type screens in the future has been anticipated in the input module design.
A new screQn type could be defined (typ~ 6 + n) and a type assigned to each input field of the new screen.
The input type will have a value between l and 6 ~a~ nting values co~e_~,on~ing to the screen types d~scribed earlier. The scrQen type and input type will be identical for types l 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 question~) for each screen i5 preferably contained in the ISF, previously described and ~hown abov~. Each ~creen i~ defined in the order in which it is to be pre~ent~d to the end-u~r. On~ screen i~ defined per file entry, or record. As shown above, the form~t of each entry is scrQen type followed by a colon and at least one input ~egment, which includ~s an input number, ~n input type, and the input text string separatQd by commas. All input segm~nts consisting of number, type, ~nd text are terminated by a semi-colon except the last segment, which is terminated by a new-line charactQr. A predetermined maximum number of character~ (-.g. 160) may be specifi~d for the text of each input ~egm-nt.

In addition to the screen entries, the present invention allows conditional construct~ to be placed in th~ ISF. A typical conditional con~truct is a~ follows:
IF tll 3:2,3,NU~ R OF DIR~CT ACC15SS - r~ ~; 3,3,NUMB~:R OF DIAr,--UP ACCESS
TlSRMINALS
3:4,3,DIAL-UP ACCESS USAGE PER ~ r- ~r I ~ ~T- ( Ccs /TER~)~5,3, P-~ ALL
~ r.~ T.5 BUSY IN BUSY PERIOD
3:6,3,SP~YrT PACXET PER SECOND EOAD PER ~ r. ~ 5- ~ 7 ~ 3 ~ RECEIVE
PAC~ET PER 8ECOND EOAD PER ~ MlP~T
3s8,3,T~Y~T AVERAGE PACKET SIZE;9,3,RECEIVE AVERAGE PACXET SIZE

W O 94/19753 PCTrUS94/02105 ~ 2I~6~6 3slO,3,CALL AT$EMPTS PER TrR~T~r;11,3,NUMBER OF TERMINATIONS PER
PORT
3:12,3,NUMBER OF PORTS PER ~NTERFACE UNIT;13,3,NUMBER OF INTERFACE
UNITS PER (AC) FEP
5 2:16,2,uv~n~AD PACXET LOAD AS A PERCENT OF DATA PACXLTS;17,2,PACKET
OAD AD~u~ PER CALL SES-UP

4sl8,4,FORLCASS OF 9.6 KBPS DA~ ACCESS LINES519,4,FORECAST OF

10 4:20,4,FORECAST OF 9.6 KBPS NETWORX ACCESS L~NES (INCLUDING
LANS);21,4,FORLCAST OF 9.6 XBPS NEIWORX ACCESS LINES (INCLUDING

4:22,4,NUHBER OF 9.6 XBPS ACCLSS L~NES PER ~NTERFACE
UNST;23,4,NUMBER OF 56 KBPS ACCESS LINES PER ~h~ ACE UNIT
lS 5:24,5,NUMBER OF 9.6 XBPS TRUNKS;25,5,NUMBER OF 56 KBPS TRUNRS.

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 "IF" (starting at column 1) followed by at lQast one blank space, an open bracket n t ~ ~ an input number, ~ closQ bracket "]", a blank 2S spaCQ, and a skip argument. The construct is terminated by a new-line character.

The conditional construct is preferably int~y.~ed $n the following manner. If the response to the input identified by the input number is affirmative t~Ye~" for type 1 or non-zero for all others], the screen(~) immediately following the construct are di-Dplayed. If, however, the Lc~ .De to tha input is not af irmative, a skip of the specifiQd number of S~L'_~n~ iD performed. If the skip argument is omitted, a default skip of one screen is performed. It should ~e appreciated that this design allows for blank lines to be interDpersed with the screen entries and conditional cG..D~ct-D to increase readability.

WO94/19753 PCT~S94/02105 ~ G -14-~ut ProceS~in~
Referring once again to Figures 2 and 3, at step 50 ths 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 ~creen population of a prior invocation of the entity sizing tool. In the preferred embodiment, th~ entity data file also includes the que~tions asked and the an~wers 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 ~emory at step 52a. As shown in Figur~ 3, this includ~s allocating screen con~ ol tablss and associat-d data structures at step S2b, and allocating an a~ ,at~ data structure for each ~S input at tep 56c.

ScrQen control tables contain information which dictat~ th~ order in which input screens are pra~ented to the us~r. The screen control tables are user-d~finod and creat~d from the ISF itsalf. More specifically, th~ scr~en control tables ar~ created from tha cond1tiQnal con~tructs of an ISF. The data structure i~ referred to a~ "a~L_~-te" in that it contain~ an elament for each of the three input cat~gori~s (i.e. logical, quantitative, and protocol quantitativ-). The data 3tructurQs also contain elemant~ to store the a~sociated input number, input type and input text string.

~ f an entity file does not exist, at steps 54 and 56 the computer creates an entity file and loads a user-dQfined ISF. It should be appreciated that an entity file is created for the specified entity and the information contained in the input ~creens file is WO94/19753 PCT~S94/02105 ~1S6D5~

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 edit~ and validations are performed on the information in the ISF at step 56a. This includes par~ing the input screen records and checking for proper syntax at steps 56b and 56c, re~pectively.
If there are problem~, an a~L G~ iate me~sage can be displayed to the user at step 56d. The input module al~o allocates an ay~.e~ate data structure for eac~
input at step 56e and allocates a set of data structures for the screen UO1~LO1 tables at step 56f. The conditional construct information of the ISF is loaded in the data structures u~ed for the screen control tabl-~.

With continuing reference to Figures 2 and 3, at step 58 the computer examines the screen control table~ to determine which input screen to display to the u~ar. At step 60 the computer dQtQrmines whether or not to di~play the next input screen ba~ed on the screen c6..L~ol tabl~. If the next screen should not be display~d, at step 62 that input screen is skipped and CG~L~O1 ~CLUL~g to step 58, wherein the computer examin-~ th- ~creen control tables to determine the next scre-n to di~play. If the next screen should be d~splay@d, at step 64 the scr~sn is displayed to the u~er. The design then allows the end-user to populate the screen (i.e. answer the questions geared toward site-~pecific variability issues) using stAn~A~rd type, over-type, tab, and erase conventions.

A~ shown in Figure 2, at step 66 the computer ~sses the screen input. As best shown in Figure 3, WO94/19753 PCT~S94102105 -' 6~S ~ -16-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 s the current screen to be placed into the appropriate input data structure. Input processing also includes editing/validating screen entries at ætep 66b, so as to ~nsure that quality data is entered. This can be accomplished by parsing screen entry fields at step 66c and checking syntax at step 66do If improper $nformation has baen entered, the inputted information is re~ected and an appropriate message is displayed to the user at step 66e.

After screen input ~Lo~essing is complete, at step 68 the computer awaits the entry of a defined "E~cape" function key, or some other similar confirm~tory action, to indicate to th~ comput~r that no additional ~creen input is forthcominy. If the key is not de~ s~d, cG.-~ol flow returns to step 58, wherein the computer examines the ~craen ~G--L~ol tables to datermin~ th~ next screen to display. If the key is deprQssed, at ~tep 70 the input on the current screen is preferably storcd in the a~ G~ iate input data structure, the input data and screen co~ ol structures 2S are written to the entity file, and the input module is Qxit~d, with control flow ~e~uLning to ~tep 40 as shown in Figure 2.

Calculat~ o~ Module I~ the user selected the Calculation Module at step 40 o~ Figure 2, at step 44 the computer would executQ the calculation module, a flowchart of which is shown in greater detail in Figure 5. A functional WO94/19753 PCT~S94/02105 ~ ~560~6 repre~entation 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 anothsr. Although som~ commonality would exist in many of the calculation~, there would no doubt be a large number of calculations which would be site dependent.
Thia would also require maintaining multiple versions of a site dependent tool. For these r~AsonC, the present invention utilizes a flexible calculation processing de~ign to compensate for the above-noted problems.

~cc~5 ~1 cul~t~on F~l 1e lS In~t~ad of ~o~in~ each calculation directly into the module, the calculations to be performed are placed in a user-defined and populated procass calcula-tion fil~ (PCF). In addition to calculation entries, conditional constructs may be placed in the PCF. These 20 Co_~L~cts allow the calculations performed to be driven by end-u~er ~ o"ses. The universe of- entity calculations can therefore be defined and only those ~lc~lations pertinent to a particular sizing activity will bQ perform~d, based on the placement of the conditional ~oni~ cts in the PCF. A sample PCF with an associatQd conditional construct is as follows:

VAR -Tl,T2,T3,AA,8B,CC,DD,DD2,EF,FF,GC,HH,II,JJ,MM,NN,OO,PP,QQ,RQ,SS, TT, W-, W,WW,XX,YY,ZZ,AAA,BBB,CCC,DDD,EEF,FFF,GCG,HHH,SII,JJJ,KKK, ~ ,M~M,NNN,OOO,PPP,QQQ,RRR,SSS, m ,U W ,V W,WWW,XXX,YYY,ZZZ,AAAA, BBBB,CCCC,DDDD,FFEE,FFFF,GGGG,HHHH,l~lT,JJJJ,KKK~,LLLL,MMMM, NNNN, oooo,PPPP,QQQQ,RRBR,SSSS,TTTT,UUUU,Xl,X2,X3S
IF ~1]
AA - 131 * ~41 * [5] * .01 8B - AA ~ 1.32S
CC - BB ~ 121 / [11 W O ~4/19753 PCTrUS94/02105 ^r 6 ~ ~ 6 -18-DD -- CC / [121 }
EE - ~18] ~ [20 FF - ~19~ + ~21]
GG - EE / [22 HH - FF / (23]
rI - ~24~ / ~261 JJ ~ ~25] / ~27]
TF ~1]
10 {
MM - ~2] ~ ~3] ~ ~5~ / lOO
10]
00 ' MM ~ ~6]
PP - MM ~ ~71 QQ - ~161 / 100 1 1 ~ 00 ~R - ~16] / lOO ~ 1 ~ PP
SS - ~101 ' ~17] + QQ

TT - 30 ~ 38 * .01 ~ 18 W - 31 ~ 38 ~ .01 ~ 18 W - 32 ~ 39 ~ .Ol ~ 19 WW - 33 ~ 39 ~ .01 ~ 19 XX - 34 ~ 40 ~ .01 ~ 20 YY - ~S ~ 40 ~ .01 ~ 20 zz . ~t ~ 41~ ~ ~al ~ 21 AAA ~ 3~ ~ 4_ ~ .01 * 21 8BB - 42 ~ 46 ~ .01 ~ 2~
CCC - 43 ~ 46 ~ .Ol ~ 24 DDD - 44 ~ 47 * .Ol ~ 25 ~ - 4S` ~ 47 * .Ol ~ 2S

As shown above, the first line that appears in th- PCF i$ the working variables definition .e_o.d As shown above, the format of the dafinition entry is "VAR"
(column 1) followed by a blank space and an equal sign (n~) Im_ediately after the equal sign and any int-rvening blank spaces come3 the list of working variabls names, preferably separated by commas Each variabl- name can be up to three charncters (preferably Alrh~lm~ric) in length and a predefined maximum number of variables (e g 85) may be specifled The variable list is terminated by a dollar sign ("5") and the entry is t~rminated by a new-line charact~r 0~ course, other delimiter~ or symbols may be utili2ed Praferably, calculation entries follow th~ definition entry, and only one calculation is allowed per line WO94/19753 PCT~S94/02105 ~ 6~5~

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 ~;ni~lm of lS the operands should be selected. If the operands are protocol entries or vAriables, the minimum operation is par~ormed individually for each adjacent protocol. When a screen input is ref-renced in a calculation, the preferred format is: blank space, open bracket ("["), input number, clos~ bracket ("~"), and blank space (or new-line character). The results of each calculation are preferably assigned to a working variable by pr~ n~ the operAnds and operator(s) with 'variable The format of the PCF conditional construct is substantially similar to the conditional construct for the ISF ~i~c~ r~ above, i.e. "IF" (column l) 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 WO94/19753 PCT~S94/02105 identified by the input number is affirmative (i.e.
"yes" for type l 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 .

r~lC~ o~ r~c~c~s~
Referring now to Figures 5 and 6, at step 78 the computer begins interpreting the process calculation lS 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 ~LGcel~res. PLG~ssing of the working variabla definition record includes editing/validating the ~_o~ entries at step 80a. This is accomplished by parsing the ~e_old and checking syntax at steps 80b and 80c, respectively. Appropriate messages can be di~played to the user at step 80d if there are errors.

Processing of the working variable definition L~- 0~ al~o includes allocating a variable a~e~ate data ~tructure at step 80e for each variable in the definition list. ~his 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, definin~

W094/19753 PCT~S94/02105 21SGo5~

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, ~e~ectively. 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 proce~s the next record ba~Qd on th~ conditional construct. If the next record ~hot- 1 ~ not be PL OC ~ 6 ' ~ at stQp 88 the computer perform~ a conditional record skip, and control flow returns to step 84, as shown in Figure 5. If, however, the next r~cord should be ~L OC~ 0~ at step 9o the computer edits/validates that calculation record. As with previously described edit/validations, this include~ par~ing the calculation La_O~d at step soa, checking th~ record for proper syntax at step 9Ob and is~uing a~.Gy~iate messages at step 90c if errors are found.

With continuing reference to Figures 5 and 6, thQ computer next processes the calculation record at ~t~p 92. At step 94, the computer performs the WO94/19753 PCT~S94/02105 ~6 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 singlQ value is appliod to each multiple value, and the result is a multiple value. If, however, two multiple va}u~ operands appear in an operation, the op-ration is lS performQd 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 p~rformed using the single values, and the result is a single value. It should be noted th t this design also includes an auxiliary summation operator, which sums the values of a multiple valua operand and produces a single value, which can then bQ assigned to a working variable or u~ed further in the calculation. Each workin~
variable preferably has a value assigned to it before it 2S can bQ u~ed in a calculation.

Some calculations will consist of multiple opQrations. Accordingly, at step 96 the computer detcrmines if the calculation being performed includes multiple operation~. 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 lO0 the WO94/19753 PCT~S94/02105 2I5~056 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.

Re~ort Mo~ule lf 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 i~ shown in greater detail in Figure 7. A functional representation of th~ Report Module is shown in Figure 8. Generally, once the input data has been obtAine~ and the network si2ing calculations have been performed using the data, the results are reported to the u~er. It would not be practical to code the formatting and reporting criteria directly into the module because o~ its site dependent nature. Again, flexibility is employed to allow the calculation r.esults 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.

g~-rt ~qt F~le In the preferred emhoAiment~ the information 25 used to co~ol 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.

WO94/19753 PCT~S94/02105 ., _ , _ ~s6~5~ -24-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 response~. 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 [l]
{

NUMBER OF Mr,GH L~NES~BB
NU~SBYR orTNT~sRFAcE UNITS R~SQu~ED FOR D~AL-UP & DIR~:CS .~rN~rS~DD
MIXED>DD2 ~5 NUM ER OF lh.~nFACE UNITS hkQu~nyv FOR TRUNKS ONr~Y
}

Er,S~
{

NUMBER OF I~nr-ACE UN~TS Rk~urnyv FOR TRUNKS ONrY
9.6 XBPS~IIt 56 KBPS>J~t M~v~GGC
TOT~L~L~L
NUMBER OF INTERFACE UNITS hEQu tRsD FOR ACCESS LINES ONLY
NETWORX ACC~SS I,INES~II$;
DATA BASE ACCESS L~N~S~JJJ~
MIX~:D~
TOT~t - 111111 TOTAL NUMB~R OF ~h~YnYACE UNITS Rkyu~R~v (ADD Ar,r. PRO.OCOLS, SPEEvS, AL- & D$AL
NUNBrR OF F~P- - TRUNXS ONEY~gQQ
CO~IT~n~
IFt29 t NUMBER OF FEP- - LINES ~ TRUNKS COMBINED~SSS
~ r -~ r ~
NUMBER OF M P- ~yu~REv BASED ON EOAD (PPS)~ZZZ
ESTIMAD D N W BER OF FEP- h~yu~v 8ASED ON M~.-OR~EEEE
MAXIMUM N W BER OF FEP- RQuIk~v~FFFF
CPU- k~QulREv BASED ON PHYSICAL LIMITATIONS~&GGC
CPU- R~yu~v 8ASED ON LOAD~KXXK
CPU- ~yu~n~v 8ASED ON MEMORY>QQQQ
MAXIM W NUMBER OF CPU- REQuI~v>RRRR
NUMBER OF PACXET ~w~ S R~QulREv~UUUU

The literal and working variable fields are praferably placed in the RFF positions corresponding to the areas of the report page. Working variable names WO94/197S3 PCT~S94/02105 ~ 2~0~6 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.
QS" for TYPQ 1 or non-zero for all others], the report linets) immediatQly following the construct are output.
I~, howeY~, the response is not affirmative, a skip of the specified number of report lines is performed. If the skip argumant 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.

Pt.,~G~ L~
During report proce~sing, the computer perform~ 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 WO94/197~3 PCT~S94/02105 t o56 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 prore~e~. 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 ~L OC~S the next record in the RFF, ba~ed on the re~p~n~e to the input identified by the input number.
As noted above, if the recponse is not affirmative, at step 116 the specified number of report lines are skipped and control flow returns to step 112 for further ~ocassing of the conditional construct. If, however, the responsQ is affirmative (calculations were performed), the computsr ~ the report line format at step 118. As best shown in Figure 8, this includ~ editing/validating the L~G~ line format at step 118a by parsing the calculation records, checking the records syntax and issuing a~o~iate messages at ~t-ps 118b, 118c and 118d, respectively. At steps 120 and 122 of Figure 7, the computer ~G~e~ses the carriage c~..L~ol functionQ and populates the report output structure with the information to be printed out, re~pectively .

Thus, as the report module reads and interprets e~ch record entry in the RFF, the literal fields are written to the report output file, while the as~ociated carriagQ control ~unctions are pcrformed.

WO94/19753 PCT~S94/02105 ~ ' 2i~o~6 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 ha~ not been encountered, at step 126 the literal fields for that particular page are printed. If there are additional records to be pro~oC-- 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 sed. If there are, control flow skips to step 112 and ~teps 114 through 128 are repeated as described above, i.e., records are proces~ and the report output structure is populated. If there are no more records to be ~L~ at step 132, report ~oce~sing 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 WO94/19753 PCT~S94/02105 605~ --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 neces~ry 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 th~ 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 illu~trate all possible forms thereof~ Tt will also be understood that the words used lS are words of description rather than limitation, and that various change~ may be made without departing from the spirit and scope of the invention as disclosed.

Claims (12)

What is claimed is:

1. A method of operating a computer to size a communications network having site-variable inputs without requiring program changes, program saves or recompiling for the computer, said method comprising the steps of defining a set of text files to enable a user to customize the implementation of the method, said set comprising an input screens text file, a calculation processing text file, and a report format text file, and each of said text files being user modifiable, said input screens text file containing predefined input queries relating to requirements of the communications network, said calculation processing text file containing calculation entries for determining the size and attributes of the communications network components, and said report format text file containing report file entries for indicating the size and attributes of the communications network components;
utilizing said input screen text file to prompt a user to enter to the computer sizing and attribute data of the communications network components in response to predefined input queries;
capturing by the computer the entered communications network sizing and attribute data in at least one data structure associated with said input screens text file;
utilizing said calculation processing text file to cause the computer to calculate the number of network components utilizing the entered communications network sizing and attribute data so as to determine the size of the communications network components; and utilizing said report format text file to cause the computer to generate a communications network sizing report of the number of communications network components.

2. The method of claim 1 wherein the step of defining a set of text files including an input screens text 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 a set of text files including an input screens text 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 a set of text files including an input screens text 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 set of text files including a calculation processing text 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 set of text files including a calculation processing text 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 set of text files including a calculation processing text file includes the step of defining at least two data structures, one of the two data structures 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 text 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 set of text files including a report format text 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. The method of claim 1 wherein the step of defining a set of text files including an input screens text 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.

11. The method of claim 1 wherein the step of defining a set of text files including a calculation processing text 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 structures for storing final calculation results, the other data structure for storing interim calculation results associated with compound calculations.

12. The method of claim 1 wherein the step of defining a set of text files including a report format text 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.