Patent Application
20070299746
There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown.
The converged tool 110 can include an infrastructure performance model 112, a QOE model 114, and a finance model 116, which are interrelated to each other. That is, changes made to one of the models 112-116 can have a mathematical effect on the other models 112-116. Concurrent solutions can be performed for the models 112-116, which can provide one or more stable results or solutions 119. Users can input constraints, adjustments, and other user designed settings 128 into the converged tool 110. for example, a user can designate a mathematical algorithm that is to be used to calculate a QOE for a given service. Different services provided via the IT infrastructure can be associated wit different QOE algorithms and values.
To utilize a mechanical analog, the models 112-116 function as a set of meshed gear linked to the other models 112-116. A user of the converged tool 110 can interactively select one of the models 112-116 as a “master gear” that drives results of the system 100. Thus, a user can make adjustments to a selected model 112-116 and can dynamically receive feedback showing the affect of the adjustments on other models 112-116.
In one example, a user can perform adjustments on the QOE model 114, which can alter states of the performance model 112 and the finance model 116. For instance, if an adjustment is made for an increased QOE in the QOE model 114, more infrastructure resources of a fixed information technology (IT) infrastructure can be consumed, which alters a load on the infrastructure, which can result in lower performance metrics 122. Additionally, an increase in QOE can lower a subscriber blocking probability can be a probability that a service will be blocked due to a contention for infrastructure resources. A low blocking probability and a high customer satisfaction level can result in an increased subscriber population, which increases revenue derived from subscribers, as calculated by the finance model 116. An increased subscriber population, however, can also increase subscriber load, which can degrade performance metrics 122. When performance metrics 122 degrade beyond a certain level, it is no longer possible to achieve a desired QOE without upgrading the IT infrastructure to improve performance metrics 122 to a level to achieve target QOE metrics. The finance model 116 can dynamically balance increased revenues for a service against an increased infrastructure cost.
The above example emphasizes that each of the models 112-116 are interdependent. When any of the metrics 122-126 used by one or more of the models 112-116 change, other changes can result. Feedback 118 shows that results from the converged tool 110 can be fed back into the components 132-136 that generate the metrics 122-126.
Components 132-136 can include a performance component 132, a QOE component 134 and a finance component 136, which generate performance metrics 122, QOE metrics 124, and financial metrics 126, respectively. Each of the components 132-136 can be a standalone program that interfaces with the converged tool 110 can be a software module integrated with the converged tool 110.
In one embodiment, the converged tool 110 can be used to forecast values of a simulated IT infrastructure. The converged tool 110 can also be used for dynamically analyzing, adjusting, and planning within an operational environment, such as an autonomic computing environment. For example, the converged tool 110 can be used to selectively and dynamically adjust a QOE for one service in real-time or near real-time to ensure that performance metrics 122 of an operational system stay within previously established boundaries. In another example, the converged tool and/or can suggest infrastructure upgrades within financial constraints imposed by the financial model 116 to achieve a desired QOE based upon real-time, historic, or estimated infrastructure metrics.
System 200 can include a computing device 205 having a simulated infrastructure component 222, an infrastructure performance component 224, a QOE component 226, and a financial modeling component 228.
Computing device 205 can represent a standalone computing device or a series of communicatively linked and cooperating computing devices. Computing device 205 can, for example, include a desktop computer, a server, a cluster of services, a group of cooperating network elements and/or network devices, a virtual machine or virtual computing environment formed from a variety of allocated computing resources, and the like. Similarly, each of the components 222-228 can be implemented as stand-alone software applications and/or as cooperating software modules that form an integrated software solution.
The simulated infrastructure component 222 can be any IT infrastructure simulation tool. The simulated infrastructure component 222 can specify components that together are arranged to form an IT infrastructure. The simulated infrastructure component 222 can specify the quantity of computing resources available at different points within the IT infrastructure. The simulated infrastructure can provide at least one service to subscribers communicatively linked to the simulated infrastructure at designated connection points. Services can include, but are not limited to, VOD services, IPTV service, Internet services, phone services, wireless services, and the like. Different services can place different loads on a system and can have different performance requirements.
In one embodiment, component 222 can use a baseline model that represents an existing telecommunication infrastructure. This infrastructure information and accurate usage and performance metrics for the same can be automatically obtained using analysis tools. For example, infrastructure analyzer 240 can analyze network 230 and network 232 metrics which can be imported to the simulated infrastructure component 222 and used during simulations. The simulations can be used for planning and forecasting purposes and/or for adapting an operational environment.
In yet another embodiment, the simulated infrastructure component 222 can build a model of an infrastructure as a set of analytic equations that characterize the resulting capacity, throughout, and reliability characteristics of the infrastructure. Such analytic equations can be derived from queuing models used to represent devices in the simulated infrastructure.
The simulated infrastructure component 222 can combine different infrastructure assets, such as a coaxial infrastructure, a fiber infrastructure, a twisted pair infrastructure, and wireless components. Hybrid infrastructures are common for service providers, which have acquired one or more competing companies and their associated infrastructures. The simulated infrastructure component 222 can also combine computing infrastructure components at different points in the infrastructure, such as the number of video head-ends, the number of video-on-demand servers, the numbers of proxy servers, and the like. The simulated infrastructure component 222 can further suggest an upgrade pathway that combines the assets of the hybrid infrastructures to minimize overall costs.
The performance component 224 can be configured to compute performance characteristics of a simulated infrastructure. Performance characteristics can include delay occurring between a subscriber 218 or 219 and a server 215, transmission errors, and the like. Components 222 and 224 can be combined into a single infrastructure simulation tool, shown by interface 210.
Using interface 210, a series of graphical tools 211 can be placed on a canvas to form a simulated infrastructure. Different levels of granularity or abstraction can be presented. At high granularity level, a service server 215 linked to a network 216 can provide a service to market 212 and market 214. Multiple service subscribers, such as subscriber 218 and subscriber 219 can be members of the markets 212 and/or 214. The performance component 224 can determine jitter, packet delay, and other performance factors experienced by subscriber 218 and/or 219, by market 212 and/or 214, and by service subscribers in general.
Interface 210 can also include user customizable 213, which can affect load on the simulated network and resulting network characteristics. For example, the constraints 213 can include constraints for infrastructure capacity, QOE of a simulated service, and financial return data. Each of the constraints 213 can be dependent on one another.
It should be appreciated that numerous software tools exist simulating infrastructures and for determining performance characteristics of these infrastructures. In one embodiment, components 222 and 224 can be formed in part using the Telecom Web Services Toolkit and/or the Teleprocessing Network Simulator (TPNS) by International Business Machines (IBM) of Armonk, N.Y. The invention is not limited in this regard, however, and other simulation tools and technologies, such as OPNET based simulators, Ns-2 based simulators, GloMoSim base simulators, SemSim based simulators, and the like are contemplated for components 222-224.
QOE component 226 can be configured to determine a QOE for a service that is provided to different subscribers, sets of subscribers, or markets based at least in part upon subscriber location and infrastructure configuration elements. Many standards and tools exist for predicting a QOE for a provided telecommunication service. For example, the International Telecommunications Union (ITU) has proposed standards for delivering VOD, such as ITU-R B.500. Additionally, many commercial products exist for determining QOE values, such as Agilent's N2× QOE tool.
Regardless of technologies used by QOE component 226, a QOE of a subscriber in any market can be determined as a function of performance characteristics (obtained from component 224) a link between the market and the server from which service is received and as function of a load upon a server. In general, if a market is served by k servers (1, . . . k), the QOE can be estimated as an amount of time needed for a service to begin an amount of errors that can be estimated from that site.
The QOE can be estimated by a variety of functions. For example, a formula for UDP oriented traffic using RTP type flow control can be QOE=e−1/sqrt(d), where d is a delay between a market and a server, and 1 is the loss rate. Of course, other formulas depicting the QOE using other types of low control and based upon other services can be incorporated into the QOE component 226.
The financial modeling component 228 is configured to predict an impact for a QOE on an expected subscriber population, which affects a Return on Investment (ROI) since ROI is a function of cost of service and a number of service subscribers. The mapping from QOE to the financial workload of subscriber can be computed by a utility function model, such as one involving a blocking probability of subscribers on a market due to a shift in the QOE. A high QOE will indicate a low blocking probably or subscriber loss rate. In fact, a high QOE can be linked to a positive subscriber growth. A low QOE can result in a high blocking rate, which can decrease a subscriber base.
In one embodiment, the blocking probability can be quantified by means of the equation:
blocking probability=QOE/(QOE+e(C1−C2*QOE))
where C1 and C2 are constants of the model that can be adjusted to help fit the blocking probability function to a desired curve, such as one based upon real world consumer data.
It should be appreciated that a complex part of constructing an integrated solution incorporating factors and constraints of components 222-228 relates to the fact that the components are interrelated. That is, blocking probability can be a function of QOE, which is determined by a load from each market, which is in turn determined by the blocking probability. Thus, instead of any of the computations being simple linear equations, a number of concurrent solutions based upon interrelated models must be determined. System 200 focuses upon determining one or more stable solutions that simultaneously satisfies an infrastructure performance model, a QOE model, and finance model.
Interface 300 can include a performance section 310, a QOE section 320, and a finance section 330. Each section 310, 320 and 330 can specify an algorithm used for constructing a model, upper constraints, lower constraints, optimal values, and the like. Each of these sections 310, 320 and 330 can be configurable. For instance, an authorized user can replace a model algorithm with a different selectable algorithm or with a user developed or imported algorithm.
In one embodiment, the performance section 310 can specify a market workload algorithm. The model can be abstracted to a market level, where the algorithm determines performance characteristics (delay and loss rate) experienced by a packet as it traverses a network from a given market to a given server and back. For example, if there are K markets and M servers, a workload, W, from each market can be characterized as W(i) through W(K). The performance section 310 can set an optimized level at seventy percent, an upper constraint at one hundred and ten percent, and can have no lower constraint.
The QOE section 320 can set an optimized level for high definition video, a lower constraint for low definition with low jitter, and can have no upper constraint. Additionally, a model algorithm for QOE can be set to a formula for UDP oriented traffic using RTP type flow control. For example, the QOE algorithm can be QOE=e−1/sqrt(d), where d is the delay between the market and the server and 1 is the loss rate. Of course, other algorithms known in the art can be selected in section 320.
The finance section 330 can be set for an optimized a ROI of three years, and a lower ROI of ten years with no upper constraint for a ROI. The algorithm for computing financial return can include a blocking probably calculation, which alters a subscriber population based upon QOE.
Further, interface 300 can include a weighting section 340 that permits a user to emphasize or weigh a relative effect of each of the models on concurrent solutions. Using section 340, a weight of thirty percent can be set for both the performance and QOE models and a weight of forty percent can be set for the finance model. Accordingly, solutions can be selected to emphasize financial returns over QOE and performance.
Interface 400 can include a solution constraints section 410 and a solution section 440. Section 410 can include a market section 415, interrelated constraint section 420, and a service constraint section 430. Market section 425 can be used to specify one or more markets for which constrained solutions are to be provided. A market selected in section 415 can represent a subscriber population and a sub network over which one or more services are provided. Markets can be defined by an infrastructure simulation tool, such as simulated infrastructure component 222.
Section 420 can include adjustable parameters related to infrastructure capacity or performance characteristics, QOE characteristics, and financial characteristics. Each of the parameters in section 420 can be related to each other and to interdependent model solutions in some fashion. Particular ones of the parameters of section 420 can relate to a infrastructure performance model, a QOE model, and a finance model. Each of the parameters of section 420 can affect variables of multiple models.
As shown in section 420, a network upgrade cost parameter can be set for costs between $400 million and $300 million. These costs can be allocated to infrastructure components used to upgrade an infrastructure serving Market ABC (from section 415). A service quality parameter can target a moderate quality of service. The financial returns timelines parameters can indicate that an infrastructure upgrade investment is to be recovered within four years.
The service section 430 can specify one or more services, target subscriber level, and expected service level for the service. Multiple services can be specified in section 430, each of which impacts a subscriber load on an IT infrastructure. Although four services are shown in section 430, any number of services can be specified.
In section 430, a standard definition version of a VOD service can be provided to 10,000 subscribers at an average service level. A high definition version of the VOD service can be provided to 2,000 subscribers at an optimal service level. A phone service can be provided to 20,000 subscribers at an average service level. Finally, a broadband internet service ac be provided to 30,000 subscribers with an average service level of 4 MPS.
Solutions section 440 can provide one or more solutions that concurrently satisfy the constraints established in section 410. Each of the solutions can consist of a discrete set of attributes, such as equipment cost, an expected upgrade lifecycle, a proposed network configuration, an number of subscribers, service costs, a quality of service, a service load on the infrastructure, a blocking rate, and expected monthly revenue for the specified services. Clicking on the attribute for the proposed infrastructure configuration can bring up an infrastructure simulation tool and suggested placements of upgraded infrastructure components. Selecting other report attribute can present details showing how the selected attribute was calculated,
It should be noted that parameters presented in the solutions section 440 can be customized by an authorized user. Further, the solutions can be automatically adjusted when weights applied to underlying models (such as weights applied in section 340) are altered.
Method 500 can begin in step 505, where a converged tool can be instantiated, In step 510, a configuration for an IT infrastructure can be identified. For example, a graphical network simulation tool can be used to construct a simulated IT infrastructure. The simulation tool can be designed to be viewed/modified at any number of granularities, including a network/market granularity level, a network/subscriber granularity level, and a network/service granularity level. Information from lower level granularity levels can be aggregated in the higher levels. In one embodiment, network configuration information related to an existing IT infrastructure can be imported as a foundation for a simulated IT infrastructure boundaries.
In step 520, values for a parameter model, a QOE model, and a financial planning model can be set. These models can be interdependent on each other. User configurable parameters can adjust algorithms used, relative model weights, target threshold, and solution boundaries.
In step 525, a simulated workload or subscriber load can be set so that the system begins in an overload state. In this state, at least one subscriber, set of subscribers, or market can utilize an IT infrastructure at a greater than one hundred percent capacity. Starting with a fully utilized infrastructure permits a maximum utilization of deployed resources and a maximum return on an investment. In step 530, infrastructure characteristics can be computed for the infrastructure state. In step 535, QOE values can be determined for the subscriber population for the infrastructure state. In step 540, ana approximate ROI can be computed for the infrastructure state.
In step 545, a blocking probability can be determined for the infrastructure state. It can be assumed that since the infrastructure is initially overloaded, QOE experience by a portion of the subscribers will be relatively low causing the blocking probability based upon low QOE to be relatively high. A subscriber population can be recomputed in light of the blocking probability.
In one embodiment, an adaptation of the Newton-Raphson method for solving numeric equations can be used to concurrently solve the infrastructure performance, QOE, and ROI models. In the adaptation, a solution can be adopted that spans infrastructure capacity planning, financial models, and QOE. The invention is not to be construed as limited in this regard, however, and other mathematical techniques and methods can be utiltized.
In step 550, a determination can be made as to whether the solution is relatively stable. If so, the method can proceed to step 555, where the solution can be reported as a possible simulation solution. Otherwise, the method can proceed from step 550 to step 560, where workload can be reduced based upon the new subscriber population. A new infrastructure state can be computed for this new subscriber population and related load. In step 565, the reduced workload can be compared against a minimum workload threshold. If the workload is above the theshold, the method can loop from step 565 to step 530, where infrastructure performance characteristics, QOE values, and ROI values can be computed for the new infrastructure state. If the workload is below the minimum theshold, the method can be end at step 570.
Method 600 can begin in step 605, when a customer initiates a service request. The service request can be a request for a service agent to establish a converged tool having interdependent performance, QOE, and ROI parameters.
In step 610, a human agent can be selected to respond to the service request. In step 615, the human agent can analyze a customer's current system and can develop a solution. The solution can result in a system 200, or any system that performs the steps of method 500.
In step 620, the human agent can configure the customer's system so that a converged tool has interconnected performance, QOE, and ROI parameters. In step 625, the human agent can optionally configure customer specific constraints and reports. The human agent can perform steps 620 and 625 and/or can configure a computing device of the customer in a manner that the customer or clients of the customer can perform steps 620 and 625 using the configure system in the future. For example, the service agent can load and configure software and hardware so that client devices will automatically be able to simulate IT infrastructures as described herein. In step 630, the human agent can complete the service activities.
The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
An embodiment of the invention can link the integrated converged tool with online network monitoring systems to provide a continuously planning module for telecommunication services. In such an embodiment, a network monitoring system can collect statistics of requests received from various sources, an amount of bandwidth used at different points in the network, an amount of computing resources used at different points in the network, and the origination points of requests in the network. The collected statistics can be analyzed to determine a distribution of users into several geographies and to estimate network capacity. The analyzed information can be provided to the converged tool. The converged tool can then predict when the existing capacity can be expected to run out, and can recommend suitable infrastructure upgrades that are required for continued operation of the system at desired QOE levels. In another alternative embodiment, the converged tool can be linked to a resource provisioning system so that different points in the network can be provisioned to be upgraded with more capacity automatically as a need for additional capacity operationally emerges, as automatically determined by algorithms of the converged tool.
The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form.
