EP0686287A1 - Procede et systeme de determination des dimensions d'un reseau a commutation par paquets - Google Patents

Procede et systeme de determination des dimensions d'un reseau a commutation par paquets

Info

Publication number
EP0686287A1
EP0686287A1 EP94909821A EP94909821A EP0686287A1 EP 0686287 A1 EP0686287 A1 EP 0686287A1 EP 94909821 A EP94909821 A EP 94909821A EP 94909821 A EP94909821 A EP 94909821A EP 0686287 A1 EP0686287 A1 EP 0686287A1
Authority
EP
European Patent Office
Prior art keywords
defining
network
file
data
report
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP94909821A
Other languages
German (de)
English (en)
Other versions
EP0686287A4 (fr
Inventor
Reginald Eugene Saunders
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Iconectiv LLC
Original Assignee
Bell Communications Research Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bell Communications Research Inc filed Critical Bell Communications Research Inc
Publication of EP0686287A1 publication Critical patent/EP0686287A1/fr
Publication of EP0686287A4 publication Critical patent/EP0686287A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network

Definitions

  • the present invention relates generally to communications networks and, more particularly, to a method and system for the sizing of a packet switched communications network.
  • the sizing process usually begins by first obtaining the necessary entity requirements or specifications.
  • entity requirements or specifications For example, in the case of the communication or data switching network, it would generally consist of a list of attributes and parameters such as traffic characteristics, response time expectations, and protocols to be supported.
  • the information needed to perform the .sizing function may not be intuitively obvious to the end-user of the entity, thus increasing the amount of pre- installation support needed by the end-user.
  • the final step in the process is to produce a report of the size of the entity — the quantity of entity components — for the entity engineers, who are responsible for acquiring and integrating the components.
  • the user is presented with a high-level menu screen which allows the selection of one of three entity sizing functions.
  • the user may input a particular set of attributes and parameters for an entity, perform the necessary sizing calculations based on the specified set of attributes and parameters, or produce a report of the results of the calculations performed using the specified set of attributes and parameters.
  • a series of data entry screens are displayed. These screens contain textual inquiries requesting the entry of specific data items, such as a "yes" or "no," or a data quantity.
  • the text, presentation sequence, and format of each screen are preferably determined primarily by a user-adaptable screens definition file and secondarily by the user responses entered on prior screens.
  • Each screen data item is assigned a unique data item number in the screen definition file.
  • the user has the ability to escape at any point to the high- level menu screen and resume on any screen in the series or start with the first screen. After the last screen in the series, the user is preferably returned to the first screen.
  • a predefined user-adaptable calculation definition file is read and processed. It contains a list of working variables and a series of decision making and computational algorithms. These algorithms reference by number the data items entered during the input function. The working variables are used to store the interim and final results of the calculations defined by the algorithms. Upon successful completion of processing, a completion message is displayed. Otherwise, an appropriate error message is displayed.
  • a predefined user-adaptable report definition file is read and processed. It -6-
  • the report contains a series of text strings (literals) , carriage control characters, and working variables.
  • the text strings are used to produce the heading and keyword entries on the report.
  • the carriage control characters enable the user to tabularize the output.
  • the working variables are those created during the calculation function. Upon successful completion of processing, the report output is sent to the local printer. Otherwise, an appropriate error message is displayed.
  • a method for use with a communications network and a computer, for sizing the network.
  • the method comprises defining an input screens text file, a calculation processing text file and a report format text file, each of which are user-modifiable.
  • the method also comprises inputting by a user network sizing data to the computer in response to predefined input queries relating to network requirements contained in the input screens file, and calculating by the computer the number of network components according to the process calculation file utilizing the inputted network sizing data so as to determine the size of the network.
  • the method also comprises generating a network sizing report of the number of network components according to the report format file and configuring the network based on the network sizing report.
  • a system is also provided for carrying out the method.
  • the advantages accruing to the present invention are numerous.
  • the present invention employs flexible entity sizing functions to support a complicated engineering process with a practical user programmable tool.
  • FIGURE 1 is an illustration of a system for carrying out the methodology of interactive, data-driven entity sizing of a packet switched network according to the present invention
  • FIGURE 2 is a flowchart illustrating the methodology of a first entity sizing function associated with interactive, data-driven entity sizing of a packet switched network according to the present invention
  • FIGURE 3 is a functional representation of the input screens module utilized by the present invention.
  • FIGURES 4a-4c are representations of logical screen types, quantitative screen types and protocol quantitative screen types, respectively, for use with the present invention
  • FIGURE 5 is a flowchart illustrating the methodology of a second entity sizing function associated with interactive, user-adaptable, data-driven entity sizing according to the present invention
  • FIGURE 6 is a functional representation of the calculation module utilized by the present invention.
  • FIGURE 7 is a flowchart illustrating the methodology of a third entity sizing function associated with interactive, user-adaptable, data-driven entity sizing according to the present invention.
  • FIGURE 8 is a functional representation of the report module utilized by the present invention.
  • the system 10 includes a personal computer 12 for performing necessary computations, an input means, such as a keyboard 14, a mouse 16 or the like, through which a user interacts with and provides information to the computer 12, a display 18 through which the computer communicates with the user and an output/storage means, such as a printer 20 or the like.
  • a personal computer 12 for performing necessary computations
  • an input means such as a keyboard 14, a mouse 16 or the like
  • a display 18 through which the computer communicates with the user
  • an output/storage means such as a printer 20 or the like.
  • the computer 12 includes a hard disk, as well as random access memory (RAM) and read-only memory (ROM) .
  • RAM random access memory
  • ROM read-only memory
  • the present invention contemplates use of an executable program, which could be written in the C programming language, with a window interface supported by an appropriate software package, such as the Beechwood Screen Generator software package.
  • an appropriate software package such as the Beechwood Screen Generator software package.
  • any suitable programming language can be used coupled with an appropriate window interface software package (e.g. X-Windows) .
  • window interface software package e.g. X-Windows
  • the present invention also contemplates use of "flat files" which preferably can be modified with a simple text editor, such that the data structures can be easily tuned by an end-user without the need and overhead of a relational database management system.
  • the present invention provides a method and system, or tool, for performing an entity sizing function in an interactive, user-variable fashion, as illustrated by the flowcharts shown in Figures 2, 5 and 7.
  • the entity is a packet switched communication network and the tool utilizes three basic modules, i.e. an input module, a calculation module, and a report module, which are implemented as functions to perform entity sizing.
  • the user is invited to select one of the three functions to begin the process for sizing the packet switched network.
  • the computer determines which function was selected and executes the appropriate module, as described in greater detail below. If the user selected the "Quit" option instead of selecting a sizing function, at step 48 entity sizing is ceased.
  • the end-user is presented a series of input screens which request the entry of specific information relating to network requirements.
  • a large number of input screens would be necessary. In some cases, the number of screens required could exceed one hundred.
  • Screen definitions and screen handler code would have to be created for each of these screens, and each would have to be compiled with the input module.
  • a minor change to one screen would result in the need to recompile and/or remap the input module. Since there are often quite a few variations in entity configuration from one site to another, site dependent screen software would have to be developed, making releases of the tool site dependent. Accordingly, the present invention utilizes a flexible screen management approach to eliminate the above-noted problems.
  • IBM* gcrunt rilt In the preferred embodiment, three (3) basic screen categories are defined and used to design six (6) generic screen types, rather than defining individual screens for each set of input data.
  • the first category consists of logical screens which require a true or false (e.g. yes/no) response.
  • the second category consists of quantitative screens which require specific numeric values
  • the third category consists of protocol quantitative screens which require specific numeric values for a group of protocols.
  • Screen types one and two correspond to categories one and two, respectively, and screen types three through six correspond to category three.
  • Each of the screens is considered generic because the text portions of the screens are entry-protected software-populated fields. In the preferred embodiment, the text displayed in these fields is extracted from a user-defined and populated input screens file (ISF) .
  • ISF input screens file
  • Each screen type allows a specific maximum number of input values.
  • Screen Type l allows a maximum of four "yes/no" input values.
  • Figure 4a illustrates a sample screen Type l including two possible logical inputs.
  • Screen Type 2 allows a maximum of six (6) numeric input values.
  • Figure 4b illustrates a sample screen Type 2 including two possible inputs.
  • Screen types 3 through 6 allow a maximum of two protocol sections each of which accepts either six or seven numeric input values.
  • Figure 4c illustrates a sample protocol quantitative screen including two protocol sections, each with four input values.
  • an original sequential number is assigned to each input.
  • a new screen type could be defined (type 6 + n) and a type assigned to each input field of the new screen.
  • the input type will have a value between 1 and 6 representing values corresponding to the screen types described earlier.
  • the screen type and input type will be identical for types 1 through 6.
  • there are three attributes associated with each screen screen type, input number, and input type.
  • the text (i.e. the questions) for each screen is preferably contained in the ISF, previously described and shown above.
  • Each screen is defined in the order in which it is to be presented to the end-user.
  • One screen is defined per file entry, or record.
  • the format of each entry is screen type followed by a colon and at least one input segment, which includes an input number, an input type, and the input text string separated by commas. All input segments consisting of number, type, and text are terminated by a semi-coIon except the last segment, which is terminated by a new- line character.
  • a predetermined maximum number of characters (e.g. 160) may be specified for the text of each input segment.
  • conditional constructs In addition to the screen entries, the present invention allows conditional constructs to be placed in the ISF.
  • a typical conditional construct is as follows:
  • 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.
  • the format of the conditional construct is M iF" (starting at column 1) followed by at least one blank space, an open bracket "[”, an input number, a close bracket "]", a blank space, and a skip argument.
  • the construct is terminated by a new-line character.
  • conditional construct is preferably interpreted in the following manner. If the response to the input identified by the input number is affirmative ["yes" for type l or non-zero for all others], the screen(s) immediately following the construct are displayed. If, however, the response to the input is not affirmative, a skip of the specified number of screens is performed. If the skip argument is omitted, a default skip of one screen is performed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability.
  • the computer determines whether or not an entity data file, which is stored on the hard disk, exists.
  • the entity data file includes the results of a screen population of a prior invocation of the entity sizing tool.
  • the entity data file also includes the questions asked and the answers provided by the user. If an entity data file does exist, at step 52 the computer loads the contents of the entity file into the RAM memory at step 52a. As shown in Figure 3, this includes allocating screen control tables and associated data structures at step 52b, and allocating an aggregate data structure for each input at step 56c.
  • Screen control tables contain information which dictates the order in which input screens are presented to the user.
  • the screen control tables are user-defined and created from the ISF itself. More specifically, the screen control tables are created from the conditional constructs of an ISF.
  • the data structure is referred to as "aggregate" in that it contains an element for each of the three input categories (i.e. logical, quantitative, and protocol quantitative) .
  • the data structures also contain elements to store the associated input number, input type and input text string.
  • the computer creates an entity file and loads a user-defined ISF. It should be appreciated that an entity file is created for the specified entity and the information contained in the input screens file is loaded into the data structures during the first invocation of the input module. As best shown in Figure 3, the loading of the ISF includes several steps. First, a series of edits and validations are performed on the information in the ISF at step 56a. This includes parsing the input screen records and checking for proper syntax at steps 56b and 56c, respectively. If there are problems, an appropriate message can be displayed to the user at step 56d. The input module also allocates an aggregate data structure for each input at step 56e and allocates a set of data- structures for the screen control tables at step 56f. The conditional construct information of the ISF is loaded in the data structures used for the screen control tables.
  • the computer examines the screen control tables to determine which input screen to display to the user.
  • the computer determines whether or not to display the next input screen based on the screen control table. If the next screen should not be displayed, at step 62 that input screen is skipped and control returns to step 58, wherein the computer examines the screen control tables to determine the next screen to display. If the next screen should be displayed, at step 64 the screen is displayed to the user.
  • the design then allows the end-user to populate the screen (i.e. answer the questions geared toward site-specific variability issues) using standard type, over-type, tab, and erase conventions.
  • step 66 the computer processes the screen input.
  • input processing includes managing keyboard entry at step 66a, e.g., such that striking the "Enter" key, or some other confirmatory action, causes the inputted information on the current screen to be placed into the appropriate input data structure.
  • Input processing also includes editing/validating screen entries at step 66b, so as to ensure that quality data is entered. This can be accomplished by parsing screen entry fields at step 66c and checking syntax at step 66d. If improper information has been entered, the inputted information is rejected and an appropriate message is displayed to the user at step 66e.
  • step 68 the computer awaits the entry of a defined
  • step 70 the input on the current screen is preferably stored in the appropriate input data structure, the input data and screen control structures are written to the entity file, and the input module is exited, with control flow returning to step 40 as shown in Figure 2.
  • the computer would execute the calculation module, a flowchart of which is shown in greater detail in Figure 5.
  • a functional representation of the Calculation Module is shown in Figure 6.
  • PCF process calcula ⁇ tion file
  • conditional constructs may be placed in the PCF. These constructs allow the calculations performed to be driven by end-user responses. The universe of entity calculations can therefore be defined and only those calculations pertinent to a particular sizing activity will be performed, based on the placement of the conditional constructs in the PCF.
  • a sample PCF with an associated conditional construct is as follows:
  • the first line that appears in the PCF is the working variables definition record.
  • the format of the definition entry is "VAR" (column 1) followed by a blank space and an equal sign (" ⁇ ")•>
  • VAR definition entry 1
  • the design supports the full range of arithmetic operations (i.e. addition, subtraction, multiplication, division and exponentiation) .
  • the operands of each calculation are the screen inputs and/or the working variables described above.
  • the PCF can contain numerous operators. For example, the '&' operator is valid only for protocol quantitative entries and variables. It indicates that a summation of the individual protocol quantities is to be performed. The '>' operator indicates that the maximum of the operands is to be determined. If the operands are protocol entries or variables, the maximum operation is performed individually for each adjacent protocol. Another operator is the ' ⁇ ' , which indicates that a minimum of the operands should be selected.
  • the operands are protocol entries or variables, the minimum operation is performed individually for each adjacent protocol, when a screen input is referenced in a calculation, the preferred format is: blank space, open bracket ("[”), input number, close bracket ("]"), and blank space (or new-line character) .
  • the results of each calculation are preferably assigned to a working variable by preceding the operands and operator(s) with 'variable
  • the format of the PCF conditional construct is substantially similar to the conditional construct for the ISF discussed above, i.e. "IF" (column 1) followed by a blank space, an open bracket, an input number, a close bracket, a blank space and a skip argument.
  • IF conditional construct 1
  • the construct can be terminated by a new-line character.
  • the PCF conditional construct is interpreted in the following manner. If the response to the input identified by the input number is affirmative (i.e. "yes" for type 1 or non-zero for all others) , the calculation(s) immediately following the construct are performed. A skip of the specified number of calculations is performed if the response is not affirmative. If the skip argument is omitted from the construct, a default skip of one calculation is per ⁇ formed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability.
  • the computer begins interpreting the process calculation file. As shown, this includes reading and interpreting the working variables definition record of the PCF at step 80. As best shown in Figure 6, this process entails several procedures. Processing of the working variable definition record includes editing/validating the record entries at step 80a. This is accomplished by parsing the record and checking syntax at steps 80b and 80c, respectively. Appropriate messages can be displayed to the user at step 80d if there are errors.
  • Processing of the working variable definition record also includes allocating a variable aggregate data structure at step 80e for each variable in the definition list.
  • This data structure is substantially similar to the data structure described above with reference to the ISF, with the exception of the inclusion of a screen text element.
  • the working variable definition record is user-defined and is basically a string of valid variable names, defining the names to be used in subsequent calculations to be performed.
  • the computer allocates at least one temporary aggregate data structure within which interim computational values associated with compound computations and the like are stored.
  • the computer continues its interpretation of the PCF, by processing the conditional constructs. As shown in Figure 6, this includes editing/validating the conditional constructs at step 84a by parsing the construct and checking the construct for proper syntax at steps 84b and 84c, respectively. Appropriate messages can be displayed to the user at step 84d if errors are found in the construct contents.
  • step 86 the computer determines whether or not to process the next record based on the conditional construct. If the next record should not be processed, at step 88 the computer performs a conditional record skip, and control flow returns to step 84, as shown in Figure 5. If, however, the next record should be processed, at step 90 the computer edits/validates that calculation record. As with previously described edit/validations, this includes parsing the calculation record at step 90a, checking the record for proper syntax at step 90b and issuing appropriate messages at step 90c if errors are found.
  • the computer next processes the calculation record at step 92.
  • the computer performs the calculation operation.
  • 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.
  • this design also includes an auxiliary summation operator, which sums the values of a multiple value operand and produces a single value, which can then be assigned to a working variable or used further in the calculation. Each working variable preferably has a value assigned to it before it can be used in a calculation.
  • step 96 the computer determines if the calculation being performed includes multiple operations. If so, at step 98 interim results are stored in the temporary data structure and control returns to step 94 for further calculations. If there are no more operations to perform, at step 100 the computer stores the end result in the appropriate variable aggregate data structure. At step 102, the computer determines whether the interpretation of the PCF is complete. If it is not, control flow skips to step 84, and steps 84-102 are repeated, as described above.
  • the computer would execute the report module, a flowchart of which is shown in greater detail in Figure 7.
  • a functional representation of the Report Module is shown in Figure 8.
  • the input data has been obtained and the network sizing calculations have been performed using the data, the results are reported to the user. It would not be practical to code the formatting and reporting criteria directly into the module because of its site dependent nature. Again, flexibility is employed to allow the calculation results to be formatted and reported in a manner that best meets the needs of the user. The following describes the design approach used to accommodate the above.
  • the information used to control the production of each report is placed in a user-defined and populated report format file (RFF) .
  • RFF report format file
  • conditional constructs may be placed in the RFF. These constructs allow the reporting performed to be driven by end-user responses. The universe of report output lines can therefore be defined and only those report lines pertinent to a particular sizing activity will be output, based on the placement of the conditional constructs within the RFF.
  • a typical RFF with a conditional construct is as follows:
  • the literal and working variable fields are preferably placed in the RFF positions corresponding to the areas of the report page.
  • Working variable names which have been defined in the PCF become reserved words and, therefore, are preferably not used within literal fields. If a working variable does appear within a literal field, the variable's numeric value will be substituted at the time the report is generated. Literal fields and working variables may appear on the same line.
  • the format of the conditional construct is substantially similar to the conditional constructs previously described above with reference to the ISF and the PCF. Accordingly, the preferred format is "IF" (column 1) followed by at least one blank space, an open bracket, an input number, a close bracket, at least one blank space, and a skip argument.
  • the construct is terminated by a new-line character.
  • the response to the input identified by the input number is affirmative (i.e. "yes" for Type 1 or non-zero for all others]
  • the report line(s) immediately following the construct are output. If, however, the response is not affirmative, a skip of the specified number of report lines is performed. If the skip argument is omitted from the construct, a default skip of one report line is performed. It should be appreciated that this design allows for blank lines to be interspersed with the screen entries and conditional constructs to increase readability.
  • the computer performs two basic functions: interpreting the RFF 108 and writing the report output structure. As shown in
  • the computer first allocates the report output structure at step 110.
  • the report output structure is a data structure which will contain the report line(s) and results which make up the report.
  • the RFF conditional construct is processed. This includes editing/validating the conditional construct at step 112a by parsing the construct at step 112b and checking for properly syntax at step 112c. Appropriate messages can be displayed to the user at step 112d if errors are discovered.
  • the computer determines whether or not to process the next record in the RFF, based on the response to the input identified by the input number. As noted above, if the response is not affirmative, at step 116 the specified number of report lines are skipped and control flow returns to step 112 for further processing of the conditional construct. If, however, the response is affirmative (calculations were performed) , the computer processes the report line format at step 118. As best shown in Figure 8, this includes editing/validating the report line format at step 118a by parsing the calculation records, checking the records syntax and issuing appropriate messages at steps 118b, 118c and 118d, respectively. At steps 120 and 122 of Figure 7, the computer processes the carriage control functions and populates the report output structure with the information to be printed out, respectively.
  • the report module reads and interprets each record entry in the RFF, the literal fields are written to the report output file, while the associated carriage control functions are performed.
  • the variable value is written to the report output file, while the associated carriage control functions are performed.
  • 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.
  • the computer determines whether or not a new report page should be started.
  • the page break carriage control character is associated with the first literal field (e.g. header) of each report page. If a page break character has not been encountered, at step 126 the literal fields for that particular page are printed. If there are additional records to be processed at step 128, control flow returns to step 112.
  • step 130 the computer determines at step 130 whether or not there are additional records in the RFF to be processed. If there are, control flow skips to step 112 and steps 114 through 128 are repeated as described above, i.e., records are processed and the report output structure is populated. If there are no more records to be processed, at step 132, report processing is complete, and the literal fields are printed. Control flow returns to step 40 of Figure 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé et système de détermination des dimensions d'une entité telle qu'un réseau de communication. Selon le mode préféré de réalisation, le système constitue un instrument de calcul interactif, commandé par données et piloté par ordinateur individuel (10), destiné à la détermination des dimensions de réseaux à commutation par paquets. Le procédé consiste à définir un fichier texte se rapportant aux écrans d'entrée, un fichier texte de traitement de calcul et un fichier texte de format de rapport, dont chacun est modifiable par l'utilisateur. Le procédé comprend également l'introduction (42) dans l'ordinateur, par l'utilisateur, de données relatives aux dimensions du réseau en réponse à des interrogations d'entrée prédéfinies (62) associées aux impératifs du réseau contenus dans le fichier des écrans d'entrée, après quoi le nombre d'éléments du réseau est calculé (44) en fonction du fichier de calcul de traitement et à l'aide des données de dimensions de réseau introduites, afin de déterminer les dimensions du réseau. Le procédé consiste également à générer un rapport (46) de détermination de dimensions de réseau (46), relatif au nombre d'éléments du réseau, selon le fichier de format de rapport, et à configurer le réseau en fonction de ce rapport.
EP94909821A 1993-02-22 1994-02-14 Procede et systeme de determination des dimensions d'un reseau a commutation par paquets Withdrawn EP0686287A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US2052193A 1993-02-22 1993-02-22
PCT/US1994/002105 WO1994019753A1 (fr) 1993-02-22 1994-02-14 Procede et systeme de determination des dimensions d'un reseau a commutation par paquets
US20521 2001-12-14

Publications (2)

Publication Number Publication Date
EP0686287A1 true EP0686287A1 (fr) 1995-12-13
EP0686287A4 EP0686287A4 (fr) 1996-01-17

Family

ID=21799066

Family Applications (1)

Application Number Title Priority Date Filing Date
EP94909821A Withdrawn EP0686287A1 (fr) 1993-02-22 1994-02-14 Procede et systeme de determination des dimensions d'un reseau a commutation par paquets

Country Status (4)

Country Link
EP (1) EP0686287A1 (fr)
JP (1) JPH08507397A (fr)
CA (1) CA2156056A1 (fr)
WO (1) WO1994019753A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5902453A (en) * 1995-09-29 1999-05-11 Mohawk Paper Mills, Inc. Text and cover printing paper and process for making the same
US8516099B1 (en) 2009-01-26 2013-08-20 Hewlett-Packard Development Company, L.P. Scaling management tasks performed by a management system according to a determined size of a managed environment

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04279975A (ja) * 1991-01-08 1992-10-06 Nec Corp 通信装置の電子回路カードの搭載位置決定システム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NZ224848A (en) * 1987-07-15 1995-07-26 Computer Associates Internatio Application software created from defined modules of code
US5115501A (en) * 1988-11-04 1992-05-19 International Business Machines Corporation Procedure for automatically customizing the user interface of application programs
US5270919A (en) * 1990-06-04 1993-12-14 At&T Bell Laboratories Network planning tool

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04279975A (ja) * 1991-01-08 1992-10-06 Nec Corp 通信装置の電子回路カードの搭載位置決定システム

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
IBM TECHNICAL DISCLOSURE BULLETIN, vol. 31, no. 5, October 1988 NEW YORK, US, page 449 ANONYMOUS 'Configurator Method to Define the Options That Can Be Configured' *
IBM TECHNICAL DISCLOSURE BULLETIN, vol. 35, no. 1A, June 1992 NEW YORK, US, pages 368-371, ANONYMOUS 'Visual Configurator System for Configuring and Ordering IBM Products.' *
PATENT ABSTRACTS OF JAPAN vol. 017 no. 076 (P-1487) ,16 February 1993 & JP-A-04 279975 (NEC CORP) 6 October 1992, *
See also references of WO9419753A1 *

Also Published As

Publication number Publication date
JPH08507397A (ja) 1996-08-06
CA2156056A1 (fr) 1994-09-01
EP0686287A4 (fr) 1996-01-17
WO1994019753A1 (fr) 1994-09-01

Similar Documents

Publication Publication Date Title
US5450545A (en) Generation of rules-based computer programs using data entry screens
EP1643387B1 (fr) Réalisation des fonctions d'un tableur pour travailler avec des tables de données
Standish An essay on software reuse
US8387025B2 (en) System and method for dynamic business logic rule integration
US20020129059A1 (en) XML auto map generator
CN110543303B (zh) 一种可视化业务平台
CN112650766A (zh) 数据库数据操作的方法、系统及服务器
US20070079247A1 (en) User interface having quick views and full views
KR970702673A (ko) 통신 네트워크용 서비스 제작 시스템(service creation apparatus for a communications network)
NZ273983A (en) Data storage and retrieval comprising key field that includes numeric concatenation of at least two identifiers
Benbasat et al. A structured approach to designing human-computer dialogues
US5649113A (en) Method and system for translating an optimization problem for use in efficient resource allocation
CN108573171A (zh) Greenplum数据脱敏方法、装置、设备及介质
US20050086044A1 (en) System and method of identifying a translation resource
US6075529A (en) GUI automatic generating system for inputting data of a manufacturing process
EP0686287A1 (fr) Procede et systeme de determination des dimensions d'un reseau a commutation par paquets
US8364781B2 (en) Content targeting with audiences
US5592656A (en) Method and apparatus for processing messages having arbitrary message structures witha message processor that is conditioned with a graphical user-defined message structure
US20030158856A1 (en) Profile integrator and method thereof
Jehn Hapax Legomenon II: Theory, a thesaurus, and word frequency
WO2006052878A2 (fr) Methode et appareil pour une interface destinee a un affichage graphique de donnees
US20050080608A1 (en) Simulator for request/response systems
EP0676111B1 (fr) Procede et agencement permettant de tester les services d'un systeme de telecommunications
CN115858907A (zh) 语句处理方法、装置、设备和介质
CN116974560A (zh) 基于json串建模的通用业务实现方法及系统

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19950811

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB NL SE

A4 Supplementary search report drawn up and despatched

Effective date: 19951205

AK Designated contracting states

Kind code of ref document: A4

Designated state(s): DE FR GB NL SE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Withdrawal date: 19960320