Note: Descriptions are shown in the official language in which they were submitted.
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
.; . ~
2-
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
WO94/19753 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
WO94/19753
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.
WO 94/19753 PCT/US94/02105
~ 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--
12-
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
-13-
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
56 RBPS DATABASE ACCESS LINES
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~
-15-
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
-17-
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~
--19--
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
-20-
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~
-21-
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
-22-
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
-23-
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
-25-
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
-26-
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
-27-
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~ --
-28-
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.
