Document details: Functional Description Document: NGN Project: NGN Service Resiliency Model

Transcription

1 Functional Description Document: NGN Project: NGN Service Resiliency Model Document details: Authors: Professor Richard Harris Approved By: Issue: 66 Date: Sunday, 9 April 2006 Status: For comment Security Classification: NGN Project Copy Number: Online Document (hardcopies are uncontrolled)

2 Table of Contents 1 INTRODUCTION FORMULATION OF THE RESILIENCY MODEL DEFINITION BASIC REQUIREMENTS OF THE MODEL THE MINIMAL SET OF 5 PARAMETERS REQUIRED FOR THE MODEL DEFINITION MATHEMATICAL MODELS FOR RESILIENCY SAMPLE FORMULA BASED ON THE MINIMAL SET COMMENTS ON THE PROPOSED MODEL WITH THE BASE SET SOME ISSUES AND QUESTIONS Computation of path resiliency Taking Variation into Account EXPLICIT MODELLING OF DELAY VARIATION OBTAINING A DISTRIBUTION FOR THE R-FACTOR COMBINED SERVICE RESILIENCY AND PHYSICAL RELIABILITY SUMMARY CONCLUSIONS REFERENCES APPENDIX 1 JITTER TERMINOLOGY JITTER JITTER BUFFER TIMING JITTER:... 16

3 NGN Service Resiliency Model Definition 1 Introduction We consider the problem of defining an NGN Service Resiliency model for voice services. In the initial stages of this project, Massey University and Canterbury University undertook surveys of the available literature to determine what models existed for service resiliency. A Watching Brief [1] was prepared on the basis of reviewing a list of approximately 200 references. A selection of 13 papers was made to illustrate the current state of the art in this area of research. It was found that most of the papers were based around a well-known ITU model which is referred to as the E-model and is described in ITU document G.107 [3]. This model incorporates some 20 different parameters and attempts to derive a formula that can be used to give a measure of transmission performance for voice traffic. In recent years, many researchers have focused their attention on service resiliency or service degradation models that employ the E-model as their base. Whilst this E-model is seen to be controversial by many people, it has been difficult to find workable alternatives. Among the most popular methods for describing service resiliency for voice services we find many different modifications of the E-model. The basic approach used is to reduce the set of parameters from 20 down to a more manageable number of parameters by substituting typical values for those cases that are possible and identify those remaining parameters that can be objectively measured. At the same time, verification studies are performed that involve human subjects to produce a Mean Opinion Score (MOS) so that it reflects a typical user s perception of the voice service. Statistical curve fitting approaches are then used to calibrate this modified E-model so that it matches the MOS more precisely. In the studies discussed in the Watching Brief [1], we identified a large number of different parameters that had been used to compute voice service resiliency. These parameters were extracted from the 13 surveyed papers and summarized in a further project document [2]. Approximately 38 different parameters have been used by authors of research papers to compute voice service resiliency. Nearly all papers took the E-model and then applied a subset of key parameters and assumed typical values to develop simplified formulae for the R-factor. (The R-factor is a scalar quality rating value, R, which varies directly with the overall conversational quality. The quantity R is known as the transmission rating factor. Numerically it ranges from 0 to 100, but this can be interpreted as a percentage and scaled by 100 to provide a number in the range [0, 1].) At the conclusion of our Watching Brief [1] we made the following comment: It is clear that there are many researchers involved in searching for appropriate models on which to base their design and management systems. For our purposes, it would seem that the ultimate goal is to develop some form of resiliency factor that can be applied to a link or sequence of links in order to establish a weight that represents the service resiliency of that link or path. Ultimately, we would wish to identify those paths that had good resiliency with respect to an identified service type. Once these have been identified, they can be used in both network management and planning to identify first choice and backup paths so that Prepared by: Professor Richard Harris Page 3

4 demand can be overlaid on the path in order to compute the required capacity. On the basis of our studies in this area, we have concluded that among the most practical methods of determining the required resiliency factor is to use the R-factor, approach as discussed by the many authors investigating this problem. The actual modification of the E-model that we should choose has to be simple and have objectively measurable parameters. We have found a number of authors who have developed models that would suit our purposes but, in each case, we have found that they use the same base set of 5 objectively measurable parameters. This is convenient for this feasibility study as the final decision concerning the best version of the model can be delayed somewhat until some further subjective study data can be evaluated in a following phase of the project. In addition to these 5 parameters, our discussions with Telecom NZ suggest that a model that includes the variability of some objectively measured parameters is also required in order to provide a meaningful measure of service resiliency. This issue will be considered as the definition of the model is further developed in the following sections of the document. 2 Formulation of the Resiliency Model Definition 2.1 Basic Requirements of the Model In the introduction, we have noted that there are a number of practical uses for the Service Resiliency Model Definition. The two main applications for the model are: (1) Network monitoring/management: where we want to know on a minute-byminute basis an answer to the question: "How well is the network performing for this service?" and/or "Will subscribers be complaining about the service that we are providing?" (2) Network planning and design: where we want to know how should we lay out the network (topology and protocol architectures etc) and what routing and capacity allocations should we make in order to meet quality of service requirements for loss, delay and all things related to network reliability and service resiliency? There is kind of a third "application" which is usually part of (2) but can be separated out and made much more detailed from an analytical point of view. (3) Performance analysis: where we want to know answers to questions like: "If we have the following resources, traffic levels, arrival and service distributions, MTBF statistics and so forth; what performance could be expected to be achieved for services X, Y and Z? The above ideas are displayed in a diagram, presented below, that shows how the above applications of the Model Definition are central to the way in which Telecom NZ and Alcatel will benefit from the outcomes of this project. Prepared by: Professor Richard Harris Page 4

5 Although the first stage of this project is focussed on voice services, it will be important to note that the project is intended to extend its applicability to many other types of services such as video and audio streaming, gaming etc. We can briefly summarise the requirements of our Service Resiliency Model Definition as follows: The model must provide a meaningful measure of service resiliency as assessed by a human subject. Parameters of the model must be simple to measure. Parameters of the model must be objectively determined, but the model must be appropriately aligned to MOS or similar subjective measures of service quality. It is highly desirable that the measure be a single value and represented as either a percentage or numerical value in the range [0, 1]. It should be possible to perform simulation studies using appropriately chosen simulation tools in order to provide estimates of the required parameters and potentially relate them to the Model Definition. Similar measures should be possible with other service types such as video and audio streaming, gaming, video conferencing and similar multimedia services. The figure below shows a block diagram of a typical voice service communication over the NGN network. The user speaks into a microphone which is processed by an Prepared by: Professor Richard Harris Page 5

6 appropriate codec device before transmission into the network. Once in the network, the VoIP packets traverse various network elements until they reach the destination point where, once again, they are passed through a decoding phase to the loudspeaker or earpiece of the destination user. As there are numerous network elements in this path which can impact on the packets being transmitted, the Network Service Resiliency Model Definition needs to include parameters that reflect the potential impairments that could occur to packets traversing them. Such impairments include loss and delay as a result of processing activities, transmission over long distances and queueing for resources. Network Figure 1: VoIP Service Network Path In the following section we shall identify the 5 key parameters that we believe are the minimum requirement for defining our Resiliency Model. It should be noted that a number of different authors have identified the same subset of parameters but they have often developed different formulae to compute R. It remains an issue for further study to ascertain which (if any) of these formulae provides the most accurate model. 2.2 The Minimal Set of 5 Parameters Required for the Model Definition As previously noted, the main E-model required some 20 parameters. However, many of these parameters can be regarded as having typical values or values that can be directly computed or estimated. Hence the total number can be reduced quite significantly. We are recommending that the following base set of 3 delay parameters and 2 loss parameters should be used in the computation of the resiliency measure. To illustrate where these parameters fit the network service path shown in Figure 1 above, we have drawn a new diagram, Figure 2. Delay Parameters: Figure 2: Network Delays and Losses 1) Codec delay d codec 2) Network delay d Network 3) Jitter buffer delay d Jitter Loss Parameters: 1) Network loss probability e Network Prepared by: Professor Richard Harris Page 6

7 2) Jitter buffer loss probability e Jitter 3 Mathematical Models for Resiliency 3.1 Sample Formula Based on the Minimal Set Using the minimal set of five parameters discussed above, a number of authors have successfully created formulae that can be used to compute the R-factor. To give an example of one of the more regularly cited papers, we give the formula adopted by Cole and Rosenbluth (AT&T Labs) [4] (which is equation (13) in their paper) that we discussed in our Watching Brief [2]. Their formula for R is as follows: R α β d β ( d β ) H( d β ) γ γ ln(1 + γ e) (1) Where α = 94.2 β 1 = 0.024ms -1 β 2 = 0.11ms -1 β 3 = 177.3ms γ 1 = 11 (G.729a) γ 2 = 40 (G.729a) γ 3 = 10 (G.729a) γ 1 = 0 (G.711) γ 2 = 30 (G.711) γ 3 = 15 (G.711) d = d Codec + d Network +d Jitter e = e Network + (1 e Network )e Jitter H(x) is the Heaviside function: 0 if x < 0 Hx ( ) = 1 if x 0 The results for the G.729a codec assume a 20 msec packet size, while the G.711 results are for a 10 msec packet size. The results for both G.729a and G.711 listed above are limited to random packet loss. Other values need to be derived for other combinations of coders; packet size and error mask distributions. [4] The Mean Opinion scores and the corresponding R-factor values are shown on the following diagram which has been adapted from the G.107 specification document. It shows that users are basically satisfied when the R-factor is >80 and for values below this level we can expect significant user dissatisfaction with the level of service that is being achieved. Figure 3: Mean Opinion Score and User Satisfaction Levels - G.107 Prepared by: Professor Richard Harris Page 7

8 3.2 Comments on the Proposed Model with the Base Set Formula (1) presented in the previous section is based on five easily measurable quantities and it appears to represent the best way forward at this time. It clearly has parameters that can be measured or simulated. It is also evident that it could be calibrated further to match new codecs and further human trials of service quality that might depend on newer technology or cultural factors. To evaluate the various delays such as the network delay d Network, we break it into components as suggested in Figure 4 below: Figure 4: Modelling Delays in the NGN Network Thus, the network delay will be computed by adding together the node processing delays and propagation delays along the path. At the two ends of the connection we need to determine the Codec processing delay - by finding the time required to process a talking period into a packet and the jitter delay at the play-out buffer for the receiver. These two end delays seem to be a function of the codec standard being utilised at these points. In a similar way, the two loss probabilities can (in principle) be determined as suggested in Figure 2 of the previous section. If we look at the formula, we observe that the α-term is positive and equal to 92.4 for this case. The remaining terms are being subtracted from α and the individual terms are all positive or zero (when multiplied by the Heaviside function). Thus, we conclude that the maximum value of R is 92.4 (or less), in other words, a value of R=100 is not possible using this formula. The codec delay is obviously dependent on the type of codec used. In [4] there is a table of values for the estimated size of d Codec where N is the number of 10msec frames per IP packet. This table is reproduced below for the cases of G.711 and G729a codecs: Table 1: Estimated d Codec values for various codec types [4] Codec type Encoding delay estimate (msec) G x N G.729a x N If we now consider the network delay which is made up of propagation and node delays added across the network, it is clear that, for New Zealand, the propagation delays are likely to be quite small unless the packets are travelling from Stewart Island to the northern tip of the North Island. Hence such delays are probably not likely to have any significant impact on the overall value of R. For the nodes in the Prepared by: Professor Richard Harris Page 8

9 core network, it would seem that they are typically well provisioned and so the delays, although traffic-dependent, are not likely to be a problem from a planning perspective and may only have an influence if there is a significant physical network failure or event that causes massive increases in the traffic carried by these nodes. This leads to the conclusion that the key area of influence on service resiliency will be in the access network. Here the link speeds, processor speeds and presence of various different types of codec will most likely be the principal cause of service degradation effects. Not withstanding the above remarks, it should still be possible to develop routing plans, dimensioning algorithms and such like to cover both the core and access networks to ensure these resiliency standards can be met; as well as ensure measurement schemes are in place to evaluate the R-value (however computed) for an end to end connection involving both the access and core networks. 3.3 Some Issues and Questions Computation of path resiliency One important question remains: Should this resiliency number be applied on a link by link basis or must it only be used across an entire path? Also, is R applied on a link by link basis using multiplication - as is done with typical reliability computations (product of reliability probabilities?) or should it be done by taking a minimum value along the path? For the product example, Figure 5 illustrates the procedure; hence, R = R 1 x R 2 x R 3 would be the required resiliency for the path. Figure 5: End to End Resiliency by multiplying Link by link Resiliencies Alternatively, it can be done by finding the minimum value along the path rather like finding the smallest constriction along a pipe? Thus, R = min {R 1, R 2, R 3 } as illustrated in Figure 6 below: Figure 6: End to End Resiliency by Minimum of Link by Link Resiliencies If computations are being done on a link by link basis and multiplicative computations are required, then it is often the case that routing algorithms built around this requirement end up being NP-hard problems. (Multiplicative computations can be replaced by taking logs and adding these metrics but it does not alter the NP-hard outcome.) For many algorithms that seek an optimal path through combining resiliency and physical reliability, it would be convenient to be able to take a product on a link by link basis but this is not mandatory and the other approach can be made to work in with proposed algorithms. Prepared by: Professor Richard Harris Page 9

10 3.3.2 Taking Variation into Account The basic 5 parameter model discussed above has potential limitations that have been identified by Telecom NZ. In particular, there is an expectation that geography, different client and traffic type mixes (aggregation) can lead to considerable variations in the associated R-Factor. Among the 5 parameters it is clear that the network delay component (in particular) may be subject to considerable variation as it will be influenced by traffic fluctuations in the network. If routing decisions change the paths taken by packets during a user call, then the variation in propagation delay may result in unacceptable performance for a user as it will affect the R factor. Below the call level, we can also observe that the packets traversing the network will also be subject to variations in end to end delay. The above discussion highlights the need for a way to include delay variation in the modelling process. Two possible options can be identified to take this variation into account, viz: Include delay variation as an explicit parameter in a modified version of the R factor formula. It is clear that as the delay variation increases, the R factor should decrease in value as this variation is detrimental to the performance observed by a voice customer. To do this requires a re-calibration of the formula for R. We discuss this option in a following section. Retain the basic 5 parameter model as described above, but wrap this basic model into a stochastic model that computes the distribution of R in response to variations occurring in the network delay. This would produce a distribution model for the R factor from which it would be possible to extract percentile information that could be used for design and network management purposes. We also discuss this option in section 3.5 of this document. 3.4 Explicit Modelling of Delay Variation A simple approach to taking delay variation into account involves the addition of a new term which reduces the R factor as the delay variation increases. In principle, this new term actually includes 3 new parameters, together with calibration coefficients (constants) which we have labelled as θ i, for I = codec, network, jitter. R α β d β ( d β ) H( d β ) γ γ ln(1 + γ e) θv (2) Where the coefficients and variables remain the same as for equation (1) but with the additional term θv appended. The additional term θv that has been appended is an acknowledgement that delay variation also impacts on the customer perception of service. V is the total delay variation across the network (Assuming that the variances involved are independent) and θ is a parameter that must be calibrated against Mean Opinion Scores etc. We assume θ and V are both positive quantities, so that as v increases so the customer perception of the service will diminish. The actual term θv may be more precisely defined as: θv = θ V + θ V + θ V (3) codec codec network network jitter jitter Prepared by: Professor Richard Harris Page 10

11 From the above discussion, it is clear that there would now be 8 items that need to be included in the model and Figure 2 should be altered as follows: Figure 7: Modified parameter requirements for resiliency model In order to use this version of the model, it will be necessary to perform user testing to find the required coefficients for the delay variation variables and match them to the Mean Opinion Scores of human subjects involved in the test. Such a process is currently not within the scope of this part of the project and would need to be deferred until Stage Obtaining a Distribution for the R-Factor The model described in section 3.4 above introduces three new variables and 3 new calibration constants in order to take delay variation into account. Whilst this may be an option for future work, we are not able to provide even approximate values for these items at this stage of the modelling process. An alternative approach is to obtain the delay variation through the use of analytical modelling, simulation or measurement and determine an appropriate probability distribution that fits the delay and delay variation. From such a distribution it is possible to infer the distribution function for the R-Factor. This process can be performed in a numerical way once the distribution function has been identified for the delay distribution with specified mean and variance. The R-Factor can be plotted as a function of the total delay and total loss as indicated in the following charts. We show two curves on each chart, viz: the case for the G.711 codec and the G.729a codec, based on values provided in reference [4]. It will be seen that the R-factor is higher for the G.711 case than for the G.729a codec for the range of values considered. The first chart shows the effect on the R-Factor as a function of delay whilst keeping the loss probability fixed over a range of delays from 5msec to 250msec. The second chart keeps the delay fixed at 20msec whilst the loss probability ranges between 10-6 and approximately The first chart is seen to be piecewise linear over two ranges. The first range is between 0 and approximately 177msec and then it becomes linear with a steeper gradient beyond 177msec. The second chart follows a logarithmic curve as delay is fixed and the loss probability is contained within the term ln(1 + γe) as indicated in equation (1). Prepared by: Professor Richard Harris Page 11

12 R-Factor (Loss = 10-6 ) R-Factor G.711 G.729a Delay (ms) Figure 8: R-Factor for fixed loss probability and variable delays R-Factor (Delay = 20ms) R-Factor E E E E E E E+00 Loss Probability G.711 G.729a Figure 9: R-Factor for fixed delay and variable probability of loss We conclude from the second chart that if network losses become excessive, then the quality of the connection will decrease rapidly. The first chart tends to suggest that, providing the loss is not high, the R-Factor is not strongly sensitive to the network delay. Long international connections would, of course, suffer significantly if G.729a was used for the voice codec and there were large packet losses. Once the distribution for the delay is known, together with its variance, we can plot the resulting distribution for the R-Factor and determine, for example, the 95 th percentile of this distribution and determine whether it meets a specified performance objective. Furthermore, this can also be done for different routes in the Prepared by: Professor Richard Harris Page 12

13 network in order to determine which routes are acceptable and which routes would lead to unacceptable R-Factors. 3.6 Combined Service Resiliency and Physical Reliability In the foregoing discussions, we have kept service resiliency separate from the physical reliability of the network. Ultimately it is necessary to join these two entities together to produce a combined measure especially for network planning applications. The objective is to ensure that paths chosen to carry the primary flows as well as any associated backup paths will be optimal in the sense that they simultaneously provide the best service resiliency and follow reliable paths to the destination. Depending upon whether resiliency factors are link or path based, we need to compute this combined measure and develop path selection procedures based on this measure. The following diagram illustrates the process for link by link resiliency and reliability calculations: Figure 10: Schematic Representation of Combined Service Resiliency and Physical Reliability 3.7 Summary In the preceding sections we have reported on a simple model of voice service resiliency based on work published in reference [4]. Through various discussions it has been established that the simplified model fails to capture important variation information and thus, in sections 3.4 and 3.5 we proposed methods for introducing such information into the model. The following diagram provides a generic overview of the process of determining a suitable resiliency and reliability model. On the left of the figure, we have real or test NGN topologies where the model is to be applied. Traffic data may be measured or forecasted values for any of the test networks under consideration. Based on the topology and traffic data, we can generate the key parameters either using analytical methods, simulation techniques or direct measurements. These key parameters become the input to our R-Factor model. Based on sections 3.4 or 3.5 we may produce an R-Factor value or distribution from which we can determine whether the traffic streams are within specification or outside of this specification. We would Prepared by: Professor Richard Harris Page 13

14 couple this process with reliability information using a process similar to that described in section Conclusions Figure 11: High Level View of Resiliency Model Development This document has focussed on developing a model definition for Service Resiliency for voice services. Three models have been discussed, viz: A simple model based on reference [4] that uses five basic parameters three average delays and two loss probabilities. A model that includes delay variation (jitter) in the formula. It has not been calibrated and the required coefficients are unknown although a methodology to determine these can readily be derived from observing the work of other authors in the field. A model that retains the formula of reference [4] but generates a distribution for the R-Factor based on the delay variation calculated or measured for the voice service. It remains for us to determine the shape of the delay distribution associated with the mean and jitter that has been obtained, although several sample distributions with appropriate properties can easily be thought of in this context. As the first model is believed to be inadequate, the remaining models need to be investigated further and evaluated against alternatives proposed in the literature see reference [1], for some examples. In a separate document, we shall consider the impact of choosing one of the above resiliency models on the measurement plan. An analytical model is possible for this problem. A paper by R. Harris and I. Atov [5] demonstrates an approach to computing the mean and variance of the packet delay in an IP-based network, using advanced queueing theory. The model can be used to calculate the required capacity on links in the network based on desired QoS. It Prepared by: Professor Richard Harris Page 14

15 assumes MPLS and DiffServ is implemented in the core of the network. This model will also be described in a separate document. 5 References 1) A. Haider and R. Harris, Network and Service Resiliency, Massey NGN Project Watching Brief #1, January ) A. Haider and R. Harris, List of resiliency Parameters, NGN Project document [List of Resiliency Parameters.doc], 14 th March ) ITU Document G.107, The E-model, a computational model for use in transmission planning 4) R. G. Cole and J. H. Rosenbluth, "Voice over IP performance monitoring", ACM Computer Communication Review, April 2001, Volume 31, Issue 2, Pages: ) I. Atov and R. Harris, QNA-Inverse Model for Capacity Provisioning in Delay Constrained IP Networks, SATNAC 2004, Spier, South Africa, September (Invited paper) 6 Appendix 1 Jitter Terminology The following definitions can be found in a variety of different locations and forums across the Internet. 6.1 Jitter 1) In Voice over IP (VoIP), jitter is the variation in the time between packets arriving, caused by network congestion, timing drift, or route changes. A jitter buffer can be used to handle jitter. 2) Jitter is the deviation in or displacement of some aspect of the pulses in a high-frequency digital signal. As the name suggests, jitter can be thought of as shaky pulses. The deviation can be in terms of amplitude, phase timing, or the width of the signal pulse. Another definition is that it is "the period frequency displacement of the signal from its ideal location." Among the causes of jitter are electromagnetic interference (EMI) and crosstalk with other signals. Jitter can cause a display monitor to flicker; affect the ability of the processor in a personal computer to perform as intended; introduce clicks or other undesired effects in audio signals, and loss of transmitted data between network devices. The amount of allowable jitter depends greatly on the application. 6.2 Jitter buffer In voice over IP (VoIP), a jitter buffer is a shared data area where voice packets can be collected, stored, and sent to the voice processor in evenly spaced intervals. Variations in packet arrival time, called jitter, can occur because of network congestion, timing drift, or route changes. The jitter buffer, which is located at the receiving end of the voice connection, intentionally delays the arriving packets so that the end user experiences a clear connection with very little sound distortion. There are two kinds of jitter buffers, static and dynamic. A static jitter buffer is hardware-based and is configured by the manufacturer. A dynamic jitter buffer is software-based and can be configured by the network administrator to adapt to changes in the network's delay. Prepared by: Professor Richard Harris Page 15

16 6.3 Timing jitter: Timing jitter refers to the short-term variations of significant instants of a digital signal from their ideal positions in time. Here short term implies phase oscillations of frequency greater than or equal to 10 Hz. Timing jitter may lead to crosstalk and/or distortion of the original analogue signal and is a potential source of slips at the input ports of digital switches. It may also cause slips and resultant errors in asynchronous digital multiplexes. [T ]. Prepared by: Professor Richard Harris Page 16