Multi-protocol telecommunications routing optimization
Abstract
A telecommunications switching system employing multi-protocol routing optimization which utilizes predetermined and measured parameters in accordance with a set of user priorities in determining the selection of a telecommunications path to be utilized for transmitting a data file to a remote destination. The switching system has a first memory for storing the data file to be transferred, a second memory for storing predetermined parameters such as cost data associated with each of the telecommunications paths, a third memory for storing a set of user priorities regarding the transmission of data files, and means for measuring the value of variable parameters such as file transfer speed associated with each of the telecommunications paths. Processor means are operatively associated with the second and third memories and the variable parameter measuring means for determining which of the plurality of telecommunications paths should be utilized for transferring the data file in accordance with the set of user priorities, the predetermined telecommunications path parameters, and the measured variable parameters. The switching system further comprises input means for allowing a user to change the user priorities in the third memory prior to transmitting a file.

Term
Term ended
Expired 30 October 2017, 8.9 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
24 claims: 11 independent, 13 dependent
- 1A method of determining which one of a plurality of telecommunication paths is to be utilized for transferring a data file from a first memory (30), said method being performed by a telecommunications switching system (10) comprising a plurality of interfaces (12-20), each of said interfaces interconnected with an associated telecommunications path capable of transferring a data file to a remote destination, each of said telecommunications paths having predetermined parameters associated therewith and variable parameters associated therewith, wherein the values of said predetermined parameters associated to each path are stored in a second memory (22) within said switching system, said method comprising the steps of:a) obtaining values of said variable parameters for each of said paths;b) analyzing each of said paths based at least on the values of said variable parameters and of said predetermined parameters for each of said paths;and c) determining, based on said analysis and on a property of the data file, which of said paths provides an optimal set of characteristics for transferring the file to the remote destination, the method being characterised in that the values of said variable parameters are obtained by performing measurements on each of said paths at or about the time the data file is to be transferred.
- 8The method of any preceding claim, in which said telecommunications path predetermined parameters comprise the cost per unit time of utilising said path.
- 11The method of any preceding claim, in which said telecommunications path predetermined parameters comprise a measure of data transfer reliability of said path.
- 12The method of any preceding claim, in which said telecommunications path predetermined parameter comprises a measure of data transfer bandwidth of said path.
- 13The method of any preceding claim, comprising the additional step of first ascertaining if any interface among the plurality of interfaces is available prior to performing said analyzing step b).
- 14A telecommunications switching system comprising:a) a first memory (30) for holding a data file to be transferred to a remote destination said data file having at least one associated data file property;b) a plurality of interfaces (12-20) coupled with said first memory, each of said interfaces interconnected with an associated telecommunications path capable of transferring the data file to the remote destination;c) a second memory (22)for storing values of predetermined parameters associated with each of said telecommunications paths;d) obtaining means (24) for obtaining values of variable parameters associated with each of said telecommunications paths;and e) processor means (26) operatively associated with said first and second memories (30, 22) and said obtaining means (24), said processor means arranged to determine which of said plurality of telecommunications paths is to be utilised for transferring the data file, said determination being in accordance with said associated data file property and with an analysis based at least on the values of said predetermined parameters and of said variable parameters for each of said paths, said telecommunications switching system characterised in that the obtaining means is arranged to obtain the values of said variable parameters by performing measurements on each of said paths at or about the time the data file is to be transferred.
Independent claims11
49 paragraphs, as filed
<u style="single">TECHNICAL FIELD</u>
0001This invention relates to telecommunications, and in particular to a method and apparatus for dynamically selecting an optimal telecommunications path from a plurality of available paths in accordance with an analysis of both static and dynamically changing variables and user priorities.
<u style="single">BACKGROUND ART</u>
0002The telecommunications industry has changed rapidly in recent times from the simple analog connection of telephones for voice communications to the present systems for transmitting and receiving data, facsimile, e-mail, video, audio, as well as voice in both analog and digital formats (referred to herein collectively as data). Data may be transmitted in any of various formats, such as a data file, data packets, encapsulated packets, or data streams (referred to herein as a data file). Various types of telecommunications systems have been and continue to be installed, which function as the backbone systems for transmission of data over numerous media. For example, data may be transmitted from one user to another by POTS (plain old telephone system), leased lines, mobile cellular networks, digital links, fiber optics, satellite links, and private and public packet switching networks such as the Internet.
0003In addition, there exists a great amount of pricing competition among service providers employing various types of these transmission media. For example, so-called long distance service providers such as AT&T and MCI offer rates in competition with each other in order to gain greater market shares of consumer, business, non-profit organizations, and governmental users. As a result of the numerous types of telecommunications services available, as well as the competition between providers of these services, users are often faced with difficult choices regarding the selection of a service which will provide them with the best value.
0004Often, more than one telecommunications service providers are available at a given time to a user for selection as a carrier of the data to be transmitted. For example, a user may subscribe to two or more long distance service providers, and may access either one a given time by first dialing the service provider's code, and then dialing the destination phone number. In addition, a user may have various types of media available for selection; i.e. the connection may be made via the Internet, satellite, etc. This is especially true in a business environment, where economic considerations allow numerous telecommunications resources to be available for use.
0005The prior art generally recognizes low cost as being the factor upon which routing decisions are made for the transmission of data. As such, so-called "least cost routing" facilities proliferate, allowing a call to be placed with a service provider that provides the least cost a given time. PBX (private branch exchange) systems may employ such a least cost routing facility that automatically connects the calling party to the destination number along the cheapest route available.
0006The present invention recognizes that the best value for a telecommunications medium at a given time is not necessarily the lowest cost of the choices available. That is, the optimization of routing selection encompasses not only a low cost, but also takes into account other factors such as transmission bandwidth of the medium, its availability at the specific time the user needs to use it, its security, and its reliability. In addition, a user's priorities may change from time to time, and the requirements regarding the transmission of one data file may be different than the requirements of another file. That is, a user may want to transmit one file in an emergency situation at the fastest speed, regardless of its cost. Other files may need high security from being illicitly intercepted, and yet other files may only need to be transmitted at the lowest cost at any time in the near future, with no speed concerns.
0007Thus, the present invention recognizes that the selection of the optimal route for data transmission at a given time is a dynamic analysis that must be done in real-time, and must take into account various factors regarding the available media as well as the priorities of the user and of the file to be transmitted.
0008<patcit id="pcit0001" dnum="US5337352A"><text>U.S. Patent No. 5, 337 352</text></patcit> discloses a PBX system servicing a plurality of tenants, wherein each tenant may specify which of a plurality of routes should be selected as having the highest priority, then second highest priority, etc. The routing selections are predetermined by each tenant in accordance with their requirements and available resources, and the selections are stored in a table in the PBX. Once a tenant desires to place a call, the PBX looks in the table to determine the highest priority route for that particular tenant, and connects the call accordingly. If that route is not available, then the next priority route, according to the predetermined tenant tale, is connected. Thus, a predetermined pecking order is established by each tenant and stored in the PBX. This system is static and not changeable on a real-time basis since each tenant must predetermine the priority of specific providers to utilize. Although the system of this patent checks the availability of the highest predetermined priority route and uses the next highest priority if it is unavailable, such analysis is only a discrete yes/no inquiry and does not take into account the current amount of traffic over the route to analyze the route's availability on a relative basis.
0009<patcit id="pcit0002" dnum="US5317562A"><text>US-A-5317562</text></patcit> discloses a method for rerouting connections in a cell switching network having a multiplicity of nodes. Connections needing to be rerouted from a master node to a selected slave node are firstly selected e.g. on the basis of hop count and maximum available bandwidth and then validated e.g. on the basis of availability of additional bandwidths on the route and maximum allowable queuing delay.
0010An article titled 'NBBS path selection framework published in <nplcit id="ncit0001" npl-type="s"><text>IBM Systems Journal, Vol 34, No. 4, 1995</text></nplcit>', describes a system of bandwidth computation based on traffic characteristics of the connection and reservations levels in the network.
0011<patcit id="pcit0003" dnum="US5274625A"><text>US patent 5,274,625</text></patcit> describes the characterisation of traffic offered to packet communication networks to accurately capture all of the distributional and correlational effects of complex traffic with a few acquired traffic parameters which can be readily used in bandwidth management procedures.
0012The present invention relates to a method of determining which of a plurality of telecommunication paths should be utilised for transferring a data file from a memory, said method being as defined in claim 1 of the accompanying claims. The invention also relates to the telecommunications switching system of claim 14.
0013Embodiments of the above method and system provides a method for selecting an optimal telecommunications path for connecting a call to a remote location for the transfer of a data file thereover by analyzing on a real-time basis a set of multiple protocols, and which may, for example, analyse various factors regarding the route on a real-time basis in determining the optimal route for the call.
0014Preferred embodiments of the method and system provide for multi-protocol route optimisation which analyses the priorities of a user regarding the transmission of a particular data file in determining the optimal route for the call.
0015Such embodiments may, for example, allow a user to override present default values and specify critical transfer parameters on a file-by-file basis.
0016A telecommunication switching system is provided comprising a first memory for holding a data file to be transferred to a remote destination and a plurality of interfaces coupled with the first memory, wherein each of the interfaces is interconnected with an associated telecommunications path capable of transferring the data file to the remote destination. The switching system comprises a second memory for storing predetermined parameters associated with each of the telecommunications paths and means for measuring the value of variable parameters associated with each of the telecommunications paths. A third memory stores a set of user priorities regarding the transmission of data files. Processor means is operatively associated with the second and third memories and the variable parameter measuring means for determining which of the plurality of telecommunications paths should be utilized for transferring the data file in accordance with the set of user priorities, the predetermined telecommunications path parameters, and the measured variable parameters. The switching system further comprises input means for allowing a user to change the user priorities in the third memory prior to transmitting a file.
0017For example, the variable parameter measuring means performs a measurement of the data transfer speed of each of the telecommunications paths, for example by a so-called ping test. The predetermined parameters stored in the second memory comprises the cost per unit time of utilizing each of the telecommunications paths, which may be a function of the current time of day and/or current day of week. The predetermined parameters stored in the second memory also comprises a measure of data transfer reliability of each of the paths as well as a measure of data transfer bandwidth of each of the paths. The switching system may also comprise means for ascertaining if an interface is available for data file transfer at a particular time.
0018In a method aspect utilizing the switching system of the present invention, provided is a method of determining which of a plurality of telecommunications paths should be utilized for transferring a data file in accordance with a set of user priorities, the method comprising the steps of measuring variable parameters for each of said paths, analyzing the measured variable parameters and the predetermined parameters in relation to the user priorities; and determining which of the paths provides the characteristics desired by the user for transferring the file in accordance with the user's priorities.
<u style="single">BRIEF DESCRIPTION OF THE DRAWING</u>
0019<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">Figure 1</figref> is a functional block diagram of the switching system of the present invention utilizing multi-protocol routing optimization;</li><li><figref idref="f0002">Figure 2</figref> is a flowchart of the main routine carried out by the present invention; and</li><li><figref idref="f0003">Figure 3</figref> is a flowchart of the interface analysis subroutine carried out by the present invention.</li></ul>
<u style="single">BEST MODE FOR CARRYING OUT THE INVENTION</u>
0020<figref idref="f0001">Figure 1</figref> illustrates a block diagram of the telecommunications switching system 10 of the present invention, which may be implemented for example on a personal computer platform, personal digital assistant (PDA), dedicated system such as a PBX, or the like. The switching system 10 is connected to various telecommunications media in accordance with the user's resources. In particular, the switching system 10 may be configured to a high speed digital link via a T1 interface 12, to a local area network (LAN) via LAN interface 14, to a wide area network (WAN) via a WAN interface 16, to a local loop in a plain old telephone system (POTS) via POTS interface 18, and to a wireless communication network via wireless interface 20. The interfaces 12, 14, 16, 18 and 20 are exemplary and are provided for the purposes of illustrating the preferred embodiment of the present invention. Thus, in practice, any number of the aforementioned interfaces may be used alone or in any combination as required by the user. For example, a number of common carriers such as MCI, AT&T and SPRINT may be configured to the switching system 10 such that the user may take advantage of the relative benefits of each carrier via the multi-protocol routing optimization to be described herein. In addition, the wireless interface 20 may be configured for communications by any of various types of electromagnetic means, such as infrared, radio frequency, and the like.
0021Each of the telecommunication media connected to the various interfaces of <figref idref="f0001">Figure 1</figref> has certain parameters associated therewith which are implemented by the routing methodology of the present invention. These parameters are classified by the routing methodology as being either predetermined (fixed) or measurable (variable). Data regarding the predetermined parameters are stored in a memory 22 in the switching system 10, while data regarding the measurable parameters must be collected by path analysis block 24 from each interface in real-time at or about the time the data file is transferred in order for the routing methodology to make a proper analysis.
0022Predetermined parameters stored in memory 22 include, but are not limited to, the following: <tables id="tabl0001" num="0001"><table frame="top"><tgroup cols="2" colsep="0"><colspec colnum="1" colname="col1" colwidth="31mm" /><colspec colnum="2" colname="col2" colwidth="135mm" /><thead><row><entry namest="col1" nameend="col2" align="center" valign="top">TABLE A</entry></row></thead><tbody><row rowsep="0"><entry>$makbandwidth(i):</entry><entry>maximum amount of bandwidth available for interface(i).For example, a 28.8 kbs modem would have a $maxbandwidth variable set to 28.8</entry></row><row rowsep="0"><entry>Sreliability(i):</entry><entry>an indication of the reliability of interface(i) according to the following scale:</entry></row><row rowsep="0"><entry /><entry>10 = non-reliable transfer (wireless)</entry></row><row rowsep="0"><entry /><entry>50 = moderately reliable (e.g. modem)</entry></row><row rowsep="0"><entry /><entry>75 = very reliable (e.g. T1, WAN)</entry></row><row rowsep="0"><entry /><entry>100 = ultra reliable (e.g. Ethernet LAN)</entry></row><row rowsep="0"><entry>Seconomy(i):</entry><entry>the currency expenditure of interface(i) for a period of time, normalized so that a high cost interface yields a low measure of economy:</entry></row><row rowsep="0"><entry /><entry>$economy(i) = 100 - cost/minute</entry></row><row rowsep="0"><entry>$availability(i)</entry><entry>the availability of interface(i) to a particular user. Not all users of the system will have access to each interface; e.g. in a shared PBX environment only certain subscribers may have access to the T1 interface.</entry></row><row rowsep="0"><entry /><entry>$availability = 0 Not available</entry></row><row rowsep="0"><entry /><entry>$availability = 1 Available</entry></row><row rowsep="0"><entry>$security(i)</entry><entry>an indication of the relative data security of the path, which may for example be a function of the number of bits in an encryption key (e.g. 1024)</entry></row></tbody></tgroup></table></tables>
0023Measurable parameters include, but are not limited to the following: <tables id="tabl0002" num="0002"><table frame="top"><tgroup cols="3" colsep="0"><colspec colnum="1" colname="col1" colwidth="32mm" /><colspec colnum="2" colname="col2" colwidth="67mm" /><colspec colnum="3" colname="col3" colwidth="68mm" /><thead><row><entry namest="col1" nameend="col3" align="center" valign="top">TABLE B</entry></row></thead><tbody><row rowsep="0"><entry>$presentstate(i)</entry><entry namest="col2" nameend="col3" align="left">the present state of interface(i), indicating if the telecommunications path is presently operational.</entry></row><row rowsep="0"><entry /><entry>$presentstate = 0</entry><entry>Not operational</entry></row><row rowsep="0"><entry /><entry>$presentstate = 1</entry><entry>Operational</entry></row><row><entry rowsep="0" /><entry rowsep="0" /><entry rowsep="0" /></row><row rowsep="0"><entry>$avgstate(i)</entry><entry namest="col2" nameend="col3" align="left">average of $presentstate(i) over prior five minute window</entry></row><row><entry rowsep="0" /><entry rowsep="0" /><entry rowsep="0" /></row><row rowsep="0"><entry>$datasize(i)</entry><entry namest="col2" nameend="col3" align="left">the size in KB of the data file to be transmitted.</entry></row><row><entry rowsep="0" /><entry rowsep="0" /><entry rowsep="0" /></row><row rowsep="0"><entry>$latency(i)</entry><entry namest="col2" nameend="col3" align="left">measure in msec of delay through path(i). This is based on a real-time test on the interface such as by a so-called ping to the remote host.</entry></row><row><entry rowsep="0" /><entry rowsep="0" /><entry rowsep="0" /></row><row rowsep="0"><entry>$time</entry><entry namest="col2" nameend="col3" align="left">time of day/ day of week; this is the same for all interfaces.</entry></row><row><entry rowsep="0" /><entry rowsep="0" /><entry rowsep="0" /></row><row rowsep="0"><entry>$availbandwidth(i)</entry><entry namest="col2" nameend="col3" align="left">available bandwidth of interface (i) at a given time of file transfer</entry></row></tbody></tgroup></table></tables>
0024Rather than simply relying on preprogrammed "least cost" routing criteria, the present invention utilizes all or a logical subset of the variables set forth in the Tables A and B above to arrive at a routing decision for a data file to be transmitted. That is, by employing the multi-protocol routing optimization of the present invention, the path chosen for transmission of a data file takes into account parameters which vary in real-time, thus not relying on a simple preprogrammed look-up table of low cost providers as in the prior art. In addition, the user can specify his priorities as to the parameters which are critical in transmitting a particular file, i.e. low cost, high speed, reliability, security, etc., in making the routing determination.
0025The methodology employed by the present invention is processed by routing optimization block 26 (which may be implemented in a microprocessor) and utilizes two main components comprising the parameters set forth in the Tables A and B above in varying combinations. The first component is a measure of an inherent efficiency and desirability of a particular telecommunications path, and is given by the following equation: <maths id="math0001" num="(1)"><math display="block"><mi>$prevalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">=</mo><mi>$maxbandwidth</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$reliability</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$economy</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$security</mi><mfenced><mi mathvariant="normal">i</mi></mfenced></math><img file="EP0931408B1_D0001.tif" /></maths> The variable $prevalue is a linear value that increases with a high bandwidth, a high reliability, a high measure of economy (low cost) and/or a high degree of security of a particular path. This variable is essentially unchanging for a given path, except for the fact that the $economy parameter is based in part on the $time variable (cost of the path is a function of the time of day/ day of week) which is derived from a real-time clock 28.
0026The second component utilized by the routing methodology of the present invention is based in part upon real-time parameters that may exhibit a wide variance due to numerous reasons, some of which may be beyond the control of the user: <maths id="math0002" num="(2)"><math display="block"><mi>$currentvalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">=</mo><mi>$economy</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mi>$speed</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$avgstate</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mn mathvariant="normal">10</mn></math><img file="EP0931408B1_D0002.tif" /></maths> where $speed(i) - = 10,000 - ($datasize(i) x $latency(i) x 100) so that: <maths id="math0003"><math display="block"><mi>$currentvalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">=</mo><mi>$economy</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mrow><mo mathvariant="normal">(</mo><mn mathvariant="normal">10</mn><mo mathvariant="normal">,</mo><mn mathvariant="normal">000</mn><mo mathvariant="normal">-</mo><mfenced><mi>$datasize</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mi>$latency</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mn mathvariant="normal">100</mn></mfenced><mo mathvariant="normal">+</mo><mi>$avgstate</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mn mathvariant="normal">10</mn></mrow></math><img file="EP0931408B1_D0003.tif" /></maths> Thus, the $currentvalue(i) for a given path (i) will be higher for the path having a greater economy (low cost), a low data file size, and/or little latency through the path (high speed).
0027The selection of the optimal route to use is then a combination of the values calculated above in equations (1) and (2): <maths id="math0004" num="(3)"><math display="block"><mtable columnalign="left"><mtr><mtd><mi>$finalvalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced></mtd><mtd><mo mathvariant="normal">=</mo><mi>$prevalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$currentvalue</mi><mfenced><mi mathvariant="normal">i</mi></mfenced></mtd></mtr><mtr><mtd><mspace width="1em" /></mtd><mtd><mo mathvariant="normal">=</mo><mi>$maxbanwidth</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$reliability</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$economy</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mi>$security</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">+</mo><mrow><mo mathvariant="normal">(</mo><mi>$economy</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mfenced><mn mathvariant="normal">10</mn><mo mathvariant="normal">,</mo><mn mathvariant="normal">000</mn><mo mathvariant="normal">-</mo><mfenced><mi>$datasize</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mi>$latency</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mn mathvariant="normal">100</mn></mfenced><mo mathvariant="normal">+</mo><mi>$avgstate</mi><mfenced><mi mathvariant="normal">i</mi></mfenced><mo mathvariant="normal">×</mo><mn mathvariant="normal">10</mn></mfenced></mrow></mtd></mtr></mtable></math><img file="EP0931408B1_D0004.tif" /></maths>
0028The routing optimization methodology block 26 then takes the highest $finalvalue(i) for each path in the system that is available, operational, and meets a threshold ($avgstate x 10) value of 25 or above as shown in the flowcharts to be described below. This methodology thereby allows the optimal selection based on an analysis of multiple protocols employed by the system, rather than simply a least cost routing decision.
0029Path analysis function block 24 obtains the value $latency(i) for each path(i) by any means known in the art for obtaining the latency of an IP addressable path, such as by well known software utility known as "ping." The ping routine sends a packet onto the network and obtains a value of the average delay encountered by that packet in reaching the destination and returning. Other techniques which allow the system to obtain a measure of the latency of the path are also encompassed by the present invention.
0030A user may customize the relative weights given to each of the variables set forth in Tables A, B in accordance with his specific requirements as stored in user priorities memory 32. These fixed weighting values would be stored in a memory in the switching system and used in conjunction with the routing methodology for all files transferred in accordance with the invention. The weighting values are used as multipliers for the variables in the algorithm in order to allow the user to customize the algorithm as desired. For example, a user may want to emphasize the $security(i) parameter in the analysis, and may then specify a weight multiplier of (for example) two so that the $security(i) parameter is weighted twice as much as if the $security(i) parameter were left in the default state.
0031In addition, a user may override via input to a user interface 34 the fixed parameter weights preprogrammed in memory for any given file transfer with temporary values. The user interface may be any type of device for allowing the user to input data, such as a keyboard, mouse, etc.
0032In another form of parameter weighting, the user may also force the program to ignore certain parameters and focus on one parameter only in arriving at a routing decision. For example, if a user wants to transmit a data file 30 to a remote location via the fastest path, regardless of cost or any other factor, then the user specifies this requirement to the routing optimization block 26 via the interface 34. The routing optimization block 26 will then cause all variables except for $latency to a predetermined factor, so that the path with the smallest value for $latency (i.e. the smallest routing delay) will be chosen by the routing optimization block 26 as being the fastest route.
0033Other permutations and variations of the above example can be easily derived by one skilled in the art to allow the user to specify his priorities as to data transfer of a file at any given point in time, e.g. the analysis may be forced to look at any two variables, etc.
0034In addition, a user may store certain sets of parameter weighting to be used in different situations, and then select the set when desired. The set of weights would then be applied as above described. Furthermore, the program may be configured to automatically apply certain weighting sets as a function of the data type. For example, the user may specify that all facsimile messages be given a high economy factor, while all video files be given a low security factor, etc.
0035<figref idref="f0002">Figures 2</figref> and <figref idref="f0003">3</figref> illustrate flowcharts of the methodology employed by the present invention in arriving at the optimal choice for routing a data file amongst a plurality of available paths in accordance with the present invention. First, as shown in <figref idref="f0002">Figure 2</figref>, the fixed user priorities are fetched so that the parameters used in the analysis may be weighted accordingly. The user is then allowed to enter his temporary priority override values for the file transfer. Assuming for this example that no fixed weighting or temporary override values are entered, then the $finalvalue parameter is determined for each of the paths(i) in the switching system 10 in the following manner.
0036First, with reference to <figref idref="f0003">Figure 3</figref>, the routing optimization block 26 checks with memory 22 to determine if that interface(i) has been programmed as being available to be used by that user be observing the variable $availability(i). For example, if the switching system 10 is embodied in a PBX system, then not all users will have access to all paths(i) due to their economic resources. This information is contained in memory 22 and checked as a first step in the process of <figref idref="f0003">Figure 3</figref>.
0037If $availability(i)=0, then $finalvalue(i) is set to zero and the routine is exited. If, however, the interface(i) is avialable, the $availabilty(i) is set to 1 and the process proceeds. The routine then checks the to see if the path(i) is operable at that time, and the $presentstate variable is returned from the $interface(i) accordingly. If $presentstate(i)=0 (path inoperable or down), then $finalvalue(i) is set to zero and the routine is exited. If $presentstate(i)=1 (path operable or up), then the routine proceeds.
0038The variable $avgstate is then checked to ensure that it is greater than a predetermined threshold value, e.g if $avgstate x 10 > 25. If this is true, then the interface(i) is considered to be essentially in operable condition. If false, then the interface(i) is considered to be in essentially non-operable condition, notwithstanding the fact that the $presentstate indicates operability at that particular time.
0039The routine then proceeds to obtain the $latency(i) value via path analysis block 24. Using $latency(i), the variable $speed(i) is calculated as shown in the flowchart and explained above. The variable $economy(i), which is a function of the $time variable, is obtained from the memory 22. Then, the variable $currentvalue(i) is calculated as a function of $economy(i), $speed(i), and $avgstate(i).
0040The variable $prevalue(i) is then calculated as a function of the variables $maxbandwidth(i), $reliability(i), and $security(i), which are obtained from the memory 26, as well as $economy(i) which was previously determined. Finally, the variable $finalvalue is obtained as shown in the routine, and this is stored in a register pending calculation of $finalvalue(i) for the remaining interfaces as shown in <figref idref="f0002">Figure 2</figref>.
0041After all the interfaces have been analyzed in the above manner, then the routing optimization block 26 makes a determination as which interface(i) should be selected in accordance with the highest value for $finalvalue(i). The data file is then routed from the memory 30 to the selected interface for transmission.
0042The routines shown in <figref idref="f0002">Figures 2</figref> and <figref idref="f0003">3</figref> may be supplemented by the user priority override features described above, which allow the user to specify the fastest route, the least cost rout, the most reliable route, etc.
0043The measurable parameter $availbandwidth(i) may also be utilized in the algorithms presented herein to provide a real-time indication of the desirability of selecting a particular interface(i) at a given time. Although the fixed parameter $maxbandwidth(i) provides a measure of the maximum bandwidth that may be available for a given interface, the interface can be tested if desired in order to determine what portion of that bandwidth is actually available for use. One test known in the art for accomplishing this measurement is the so-called "show interface serial zero" test, which may be performed by measuring the amount of packets received in the last n seconds as well as how many packets have been transmitted on the interface in that time. Thus, the parameter $availbandwidth may be used instead of, or in conjunction with, the measured parameter $latency to perform the analysis herein.
0044In addition, while the system and method of the present invention has been shown in conjunction with the transmission of one data file (as defined herein), it may be also applicable to the transmission of multiple data files in either a serial or parallel (interleaved) basis, by modification of the algorithm and routines as may be appropriate.
0045The choice of particular variables and parameters used herein is the preferred embodiment; it is anticipated that other variables may be used in conjunction with the present invention to arrive at the optimal route in a given situation. In addition, the particular algorithm, while determined to provide a requisite relative weighting of the fixed and measured variables, may also be supplemented in accordance with the requirements of the user in order to arrive at the optimal routing choice.
7 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| US5233604A | Cites | United States of America |
| US5274625A | Cites | United States of America |
| US5317562A | Cites | United States of America |
| US5337352A | Cites | United States of America |
| TEDIJANTO T E ET AL: "NBBS PATH SELECTION FRAMEWORK" IBM SYSTEMS JOURNAL, IBM CORP. ARMONK, NEW YORK, US, vol. 34, no. 4, 21 September 1995 (1995-09-21), pages 629-639, XP000542403 ISSN: 0018-8670 | Non-patent | – |
36 members in 13 offices
Priority claims3
| Document | Office | Kind | Date |
|---|---|---|---|
| 741130 | United States of America | – | |
| 74113096 | United States of America | A | |
| 9719624 | United States of America | W |
Members36
| Document | Office | Kind | |
|---|---|---|---|
| CA2263099A1 | Canada | A1 | |
| WO9819439A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP0931408A1 | European Patent Office (EPO) | A1 | |
| BR9712399A | Brazil | A | |
| BR9712399A | Brazil | A | |
| EA199900396A1 | Eurasian Patent Organization (EAPO) | A1 | |
| CN1235729A | China | A | |
| US6016307A | United States of America | A | |
| IL129537A0 | Israel | A0 | |
| IL129537D0 | Israel | D0 | |
| YU21299A | Yugoslavia, later Serbia and Montenegro (until 2006) | A | |
| KR20000052946A | Republic of Korea | A | |
| US6144641A | United States of America | A | |
| JP2001503578A | Japan | A | |
| EA001507B1 | Eurasian Patent Organization (EAPO) | B1 | |
| EP0931408A4 | European Patent Office (EPO) | A4 | |
| US6456594B1 | United States of America | B1 | |
| US6473404B1 | United States of America | B1 | |
| CA2263099C | Canada | C | |
| US2002186701A1 | United States of America | A1 | |
| IL129537A | Israel | A | |
| YU49151B | Yugoslavia, later Serbia and Montenegro (until 2006) | B | |
| CN1166159C | China | C | |
| KR100506244B1 | Republic of Korea | B1 | |
| JP2006157939A | Japan | A | |
| US7307956B2 | United States of America | B2 | |
| US2008225832A1 | United States of America | A1 | |
| EP0931408B1This record | European Patent Office (EPO) | B1 | |
| AT426995T | Austria | T | |
| ATE426995T1 | Austria | T1 | |
| DE69739324D1 | Germany | D1 | |
| US8400926B2 | United States of America | B2 | |
| US2013272299A1 | United States of America | A1 | |
| US9036499B2 | United States of America | B2 | |
| US2015256444A1 | United States of America | A1 | |
| US9806988B2 | United States of America | B2 |
47 legal events, as 7 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Notification of lapseLapsedST | ST | FR | |
| Gb: european patent ceased through non-payment of renewal feeCeasedGBPC | GBPC | EP | |
| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal feeWithdrawnR119 | R119 | DE | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent ceasedCeasedPL | PL | CH | |
| No opposition filedOpposition26N | 26N | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents actLapsedNLV1 | NLV1 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Party data changed (patent owner data changed or rights of a patent transferred)RAP2 | RAP2 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Corresponds to:REF | REF | EP | |
| European patents granted designating irelandGrantedFG4D | FG4D | IE | |
| European patent takes effect as a national patent in ch/liEP | EP | CH | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedFG4D | FG4D | GB | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Applications withdrawn, deemed to be withdrawn, or refused after publication in hong kongWithdrawnWD | WD | HK | |
| First examination report despatched17Q | 17Q | EP | |
| Supplementary search report drawn up and despatchedA4 | A4 | EP | |
| Designated contracting statesAK | AK | EP | |
| Information provided on ipc code assigned before grant7H 04M 7/00 A, 7H 04M 3/42 B, 7H 04L 12/56 BRIC1 | RIC1 | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 0931408
- Application
- 979138583
Titles3
- German
- MEHRFACHPROTOKOLL-TELEKOMMUNIKATIONS-WEGLENKUNGSOPTIMIERUNG
- English
- MULTI-PROTOCOL TELECOMMUNICATIONS ROUTING OPTIMIZATION
- French
- OPTIMISATION D'ACHEMINEMENT DE TELECOMMUNICATIONS MULTIPROTOCOLE
Classification
- CPC, 9
- H04L45/123
- H04M7/00
- H04L12/5692
- H04L43/0852
- H04L45/124
- H04L69/18
- H04L9/40
- H04L41/08
- H04L12/64
- IPC, 11
- H04M7 00
- H04M3 42
- H04L12 56
- H04L12 28
- H04L29 06
- H04M3 00
- H04M11 00
- H04W28 00
- H04W48 16
- H04W48 18
- H04W88 14
Designated states18
- Contracting states, 18
- Austria
- Belgium
- Switzerland
- Germany
- Denmark
- Spain
- Finland
- France
- United Kingdom
- Greece
- Ireland
- Italy
- Liechtenstein
- Luxembourg
- Monaco
- Netherlands (Kingdom of the)
- Portugal
- Sweden