The present invention relates to the field of traffic routing, in particular the routing of packets and the provision of Quality of Service, QoS, for packets transmitted over a computer network.

As the volume of traffic transmitted on packet switched networks has increased, and the types of traffic transmitted over such networks has broadened to include traffic types that rely upon low latency transmission over the network, such as voice or streaming media, it has become increasingly important to enable proactive management of the traffic on the network.

Quality of service models have arisen to enable differentiated handling of different types of network traffic. The integrated services, Intserv, architecture is designed to guarantee a particular quality of service for the transmission of a stream of packets across a network. Prior to transmission of a stream of packets, Intserv requires that an originating network component reserves resources in each router through which the stream of packets will pass. This resource reservation, usually requested using RSVP (Resource Reservation Protocol), ensures that each router in the path has the necessary resources to guarantee transmission of the packet stream at a particular QoS prior to transmission of the packet stream. However, the IntServ system does not scale easily, since it quickly becomes difficult for the network components to manage the reservations.

An alternative approach is the differentiated services, Diffserv, computer networking architecture enables the network to classify the traffic into one of a specified and predetermined number of traffic classes. A differentiated services, DS, field is populated in each packet transmitted across the network and the field indicates to the network the quality of service, QoS, that is to be provided to that packet in its transmission between network components. The DiffServ model can be used to provide low-latency transmission of critical network traffic, such as streaming packets or voice-over-IP packets, across a network. Packets not marked with a prioritised packet code, such as email and web traffic, can be transmitted when the network components have capacity to do so. According to one aspect, there is provided a method of managing a plurality of QoS models for traffic flows in a network, the method comprising:

storing the plurality of QoS models;

analysing at least one of the plurality of QoS models to determine whether the at least one QoS model satisfies a suitability test;

selecting one or more QoS model from the plurality of QoS models based on the analysis offering the one or more selected QoS models to a client for use with a traffic flow in the network.

A network implementing flexible and adaptable QoS models can be provided, in particular by developing the DiffServ Classes of Service model into a system of multiple time-variant QoS models that are discovered dynamically and can also include softer policy-related routing options, such as network resilience, energy usage and cost. However, such a system can result in a single network holding a large number of QoS models at a single time. By way of non-limiting example, some of these can be internal and layered over other QoS models. Other models might not be suitable for a given client request if they do not meet the client's mandatory QoS request. Some models might not suit network policy at a given time for a given client. It might therefore be unnecessary or indeed inappropriate to expose all the available QoS options to a client. The present system and method therefore enables filtering to take place in deciding which QoS options should be exposed to a single client request at a specific time. This can be implemented to prune the number of options the client has to evaluate to decide the best QoS option for the given traffic by offering only selected QoS models or options to the client.

Optionally, the method further comprises analysing at least two, optionally each, of the plurality of QoS models to determine whether the at least two, or each, QoS model satisfies the suitability test. While it is desirable in some implementations to offer only a single QoS model to a requesting client, analysis of multiple QoS models by the network can enable the network to offer a plurality of QoS model options to a requesting client. The method may further include receiving a query from a client requesting reservation of network resources for a traffic flow, preferably wherein the query is received prior to the step of analysing. The query from the client optionally specifies at least one QoS metric for the traffic flow. The QoS metric may include a QoS Desired, QoS_D object, including parameters such as data rate, bucket size, peak rate, minimum policed unit and maximum packet size. The QoS metric may further include a min_QoS object that specifies minimum thresholds of traffic treatment that the client expects.

Optionally, the analysis is based on the query received from the client, for example based on an identifier of the client or an identifier of the source or destination of the traffic flow. Hence the analysis may be client-dependent and/or traffic-flow dependent which can enable the analysis to take into account factors such as past preferences or behaviour of the client, and expected attributes of the traffic flow as described in more detail below.

Optionally, the analysis is based on the at least one QoS metric specified in the query.

In some embodiments, the analysis is time-dependent or is dependent on conditions in at least a portion of the network. Hence the analysis can take into account the time of day and/or day of the week that the query is received. This can assist for example in predicting expected traffic capacity on the network, or on a portion of the network, at a particular time and can also add to the assessment of the expected characteristics of the traffic flow for which a request has been made, for example a query may correspond to an equivalent query sent by the same client at the same time in the previous week. Furthermore, the analysis can take into account factors such as network load in particular on different routes or different topological areas of the network and avoid further burdening congested network regions.

Optionally, the method further comprises ordering the selected QoS models prior to offering the selected models to the client. Ordering, prioritising or ranking the selected models can provide the network with further influence or control over the QoS model selected by a client following a query. In particular, the client may be configured to consider the models in order and select the first appropriate model offered by the network. The method may further include receiving a response message from the client to request reservation of network resources based on a QoS model selected from the offered QoS models.

Each QoS model may have a plurality of associated parameters, optionally the parameters comprise at least one of jitter, loss, delay and resilience.

Optionally, the method further comprises deleting QoS models that do not satisfy the suitability test. For example, if a QoS model is not deemed to be suitable over an extended period, such as throughout a period of a week, or is not deemed to be suitable for any one of a plurality of client requests, the QoS model can be deleted from the store or marked as no longer active. This can provide a mechanism to reduce the number of QoS models that the network needs to store to avoid a build-up in number of models over time. However, in an alternative embodiment, a separate process may be used to prune QoS models from the store.

In some embodiments, the analysis is based on at least one of:

a characteristic of the or each QoS model

- a characteristic of the client

a characteristic of a query received from the client requesting reservation of network resources for the traffic flow

a characteristic of the network or an operator of the network

Further details of each of these factors and how they may be applied to influence the analysis is set out below. The skilled person will appreciate that more than one, optionally all, of these characteristics may be taken into account as part of the analysis and that the analysis may take the characteristics into account in any order. In particular, as described in more detail below, the order in which the characteristics are taken into account in the analysis can be varied in order to make the analysis more efficient, for example by excluding from the analysis at an early stage large numbers of QoS models that, for example, will never be appropriate for a particular client. A plurality of routes is usually associated with each QoS model, wherein each route associated with a QoS model is capable of carrying a traffic flow using QoS parameters corresponding to those of the QoS model. Once a QoS model has been selected, any one of the routes may be used to transmit the traffic flow through the network.

In the methods described above, both QoS models developed based on policy considerations and QoS models developed based on performance considerations can be taken into account. In one embodiment, the analysis is based on a characteristic of the or each QoS model and the analysis comprises determining a measure of stability of the QoS model over time. Stability may be considered to be a measure of the length of time over which a QoS model is expected to remain within range of its advertised QoS parameters. Alternatively, but equivalently, stability may be considered as a measure of the likelihood or probability of a QoS model straying away from the advertised QoS parameters within a fixed time period.

Optionally, determining a measure of stability comprises: identifying a plurality of routes for traffic flow through the network having parameters with values corresponding with values of parameters associated with the QoS model at a time, t; and determining, for each of the plurality of routes, a duration T over which the values of the parameters for the route are expected to continue to correspond with the values of the parameters associated with the QoS model. With results for multiple routes within the QoS model aggregated, this can provide an indication of the length of time during which the QoS model as a whole will remain stable.

Alternatively, or as an additional measure, determining a measure of stability comprises: identifying a plurality of routes for traffic flow through the network having parameters corresponding to parameters associated with the QoS model at a time, t; and determining a number of routes, n, for which the parameters are expected to correspond with the parameters of the QoS model throughout time t+T. This provides an alternative or additional mechanism for determining a measure of stability of the QoS model as a whole. Optionally, a parameter associated with the QoS model has a range of values and the corresponding parameter of a route is considered to correspond with the parameter of the QoS model if the value of the route parameter remains within the range of values.. Alternatively, in particular for a different parameter, a parameter associated with the QoS model comprises a parameters each having a value and wherein the corresponding parameter of a route is considered to correspond with the parameter of the QoS model if the value of the parameter of the route remains within 20%, preferably within 10%, of the value of the corresponding parameter in the QoS model. As the skilled person will appreciate, some parameter associated with a QoS model may be assessed against a range of values for that parameter and other parameters may be assessed based on how close they remain to a fixed value.

Values of the parameters associated with the routes for traffic flow through the network may be recalculated periodically. Different routes can then be assigned to different QoS models periodically, based on the recalculation.

Optionally, the analysis is based on characteristics of the or each QoS model and the analysis comprises determining a measure of deviation of the QoS model over time. The deviation of a QoS model may be determined alternatively or additionally to the stability of a QoS model. Deviation provides a measure of how far from QoS parameters a model is likely to stray in a particular time period.

In particular, determining a measure of deviation of the QoS model comprises determining a measure of the extent to which parameters associated with each route for traffic flow through the network deviate from parameters associated with the QoS model within a predetermined time period. The measure of deviation may be presented as an aggregate figure calculated based on the deviation of each QoS parameter. However, the deviation of particular parameters within the QoS model may also be determined and presented separately to the analysis step.

Optionally, the stability or deviation of a QoS model is based on measures of stability or deviation of each of a plurality of routes associated with the QoS model. In some embodiments, the analysis is based on one or more QoS parameters in a query received from the client, optionally wherein the parameters comprise at least one of jitter, loss, delay and resilience. Parameters received from the client may therefore form the basis of the analysis of the suitability of particular QoS models. In particular, the analysis may include assessing how closely the parameters of each available QoS model match the parameters defined by the client in the query.

Optionally, the analysis is based on characteristics of the client or traffic flow, wherein the characteristics include at least one of: past behaviour of the client, for example the timing and type of past requests; past preferences of the client or of a population of clients connected to the network, for example previous QoS models selected by the client or client population; past impact of traffic from the client on the network, in particular the extent to which previous traffic flows from a particular client have remained within the bounds of QoS parameters selected by the client to handle those traffic flows; the expected traffic type within the traffic flow; the client type.

The characteristics of the client or traffic flow can be determined based on the time of day or the time of week. Hence the analysis may be time-varying.

Optionally, the method further comprises analysing and profiling a client query based on at least one of: a traffic flow source, a traffic flow destination, a traffic flow traffic type, requested QoS parameters in the query, application type for the application originating the traffic flow, time of day, time of week, an indicator of the client type.

Past behaviour of a client can include a measure of the likelihood of deviation of the traffic flow from traffic flow characteristics sent by the client in a query for the traffic flow.

Optionally, the analysis is based on characteristics of the network or an operator of the network and the analysis comprises assessing the one or more QoS models against criteria defined by the network operator. The criteria defined by the network operator may include one or more of: a cost associated with the QoS model; a maximum threshold on the number of offered models; maximum performance boundaries which may be in place for specific clients; revenue; time of the query; and network load at a particular time or in a particular portion of the network.

According to further aspects, there are provided apparatus, a system, a computer readable medium or computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any method as set out herein. Any feature in one aspect may be applied to other aspects, in any appropriate combination. In particular, method aspects may be applied to apparatus and computer program aspects, and vice versa. Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. Brief Description of the Figures

Embodiments will be described in more detail with reference to the figures in which:

Figure 1 is a schematic diagram of a network in which the systems and methods described herein may be implemented;

Figure 2 is a schematic diagram of the development of a number of QoS models over time; Figure 3 illustrates a signalling procedure according to one embodiment;

Figure 4 is a schematic diagram of hardware that may be used to implement the analysis methods described herein according to one embodiment.

Figure 1 illustrates a typical scenario in which a client 102 wishes to send a data flow to a given destination 108. The data flow is conceptually represented by arrow 110. Note that the terms "client" and "destination" are used merely to refer to the originator and recipient of the data flow respectively, such that the client is in the role of acquiring and consuming network resources, and do not imply a client/server type relationship. For example, the client could be a media streaming system and the destination could be a user device such as a media player.

The data flow is to be carried across a network 106, which includes a number of interconnected edge nodes C1-C4 and internal nodes N1-N4 (the number of nodes and interconnections depicted are chosen purely for example purposes). The network can thus provide various routes between pairs of edge devices, which can carry data flows, such as C1-N1-N2-C2, C1-N1-N2-N4-C4 etc. Each of these routes may have different performance characteristics, for example in terms of packet loss or delay.

The network is configured to provide data transmission in accordance with various distinct Quality of Service (QoS) models. Each QoS model in effect defines a Class of Service (CoS) that may be applied to traffic transported on the network. QoS models define bounds on various QoS metrics, such as packet loss. For example, one QoS model may define a particular maximum value for packet loss whilst another may specify a maximum packet delay. A single model may also combine multiple QoS metrics.

The network is configured to provide data transmission in accordance with various distinct Quality of Service (QoS) models. Each QoS model in effect defines a Class of Service (CoS) that may be applied to traffic transported on the network. QoS models define bounds on various QoS metrics, such as packet loss. For example, one QoS model may define a particular maximum value for packet loss whilst another may specify a maximum packet delay. A single model may also combine multiple QoS metrics. In a simple example, the available QoS models may be predefined and largely fixed. For example, the network may provide a standard set of DiffServ classes of service such as Default PHB (typically best-effort traffic), Expedited Forwarding (EF) PHB (low-loss, low- latency traffic) and Assured Forwarding (AF) PHB (where PHB denotes per-hop- behaviour). However, preferred embodiments operate in the context of a system which monitors performance characteristics of the network and dynamically identifies classes of service that the network can support. This is based on an iterative learning process, in which various metrics are measured for actual flows traversing the network. For example, a given flow may be associated with a performance metric vector p=<m_l,m_2,...m_n>. Each metric corresponds to a different feature of the flow (e.g. packet latency, packet loss, jitter etc.)

A learning algorithm then performs a clustering analysis on the measured metric vectors to identify representative metric vectors that indicate distinct network behaviours (these are referred to as prototypes). The representative metric vectors then form the basis of a dynamic set of QoS models that can be made available for use. For example, if the clustering algorithm identifies a number of flows that achieve similar levels of packet loss and similar levels of packet latency, a QoS model can be defined specifying the given loss and latency levels (e.g. as bounded ranges, or just upper limits). This QoS model can be made available for use by future packet flows, since the system knows from the observed prior behaviour that the network can support traffic with those characteristics.

When "learning" a QoS model, the system keeps a record of all routes that support the model (i.e. the routes carrying the data flows which were the basis for the model). Thus, in addition to the model definitions themselves, the learning process produces a mapping that maps QoS models to routes. For example, a low packet loss QoS model may be associated with route C1-N1-N2-N4-C4, whilst a low packet delay model may be associated with route C3-N3-N4-C4. Later, when routing a data flow tagged for a given Class of Service corresponding to one of the QoS models, the network (e.g. the gatekeeper) selects a route associated with that QoS model to carry the data flow.

Referring back to Figure 1, the learning algorithm is implemented in a QoS learning module 116, which may be part of the gatekeeper 104 or may be implemented separately, e.g. in a dedicated server. In a preferred embodiment, the QoS learning module 116 continues to monitor data flows in the network, and repeats the described learning process at periodic intervals. As a result the set of available QoS models may evolve over time, adapting to resource availability and demand in the network. However, such a dynamic system can make it more difficult for clients wishing to reserve resources for data flows to know what performance characteristics can be supported by the network at any given time. Furthermore, it may be the case that no single QoS model accurately represents the service characteristics desired by the client at that time.

In this way, a dynamic QoS model may be provided in which the network generates one or more route options that meet particular QoS requirements and hence provides differentiated classes of service, CoS. The network, optionally in conjunction with the requesting or originating client device, can then determine the CoS to use for particular network traffic and select an appropriate route or routes. In a first implementation, traffic routes are generated and profiled by network components in order to offer particular CoS to service providers and client devices. These traffic routes, and the associated CoS that are offered, change over time due to factors such as network congestion, availability of nodes within the network and soft-routing policies such as the energy-impact or cost of particular routes.

In a further implementation, the client may also interact with a gatekeeper entity in order to influence the available routes and selected CoS. The purpose of this interaction is to:

1) Enable a client to query the network about currently available QoS models in the dynamic QoS environment (QUERY message)

2) Enable the network to respond with currently available QoS models, performance- driven and optionally also relating to softer routing features, and communicate some of the properties associated with a given model (RESPONSE message)

3) Enable the client to query the response and/or respond with one or more QoS models it desires which can be a mixture of performance driven models and policy-based models (RESERVE message)

4) Enable the network to establish an order of importance for each of those models

5) Enable the network to determine the best possible route to the destination given the priorities communicated by the client

6) Enable the network to mandate policies that are considered important and introduce priorities of its own in choice of route

A signalling exchange for the negotiation process is illustrated in overview in Figure 3.

The exchange starts in step 302 with the client 102 sending a query to the gatekeeper 104, specifying one or more requirements for the data flow. The requirements are specified in terms of one or more QoS metrics. In step 304, the gatekeeper identifies QoS models matching the identified requirements, and provides information about the matching models in a response to the client (step 306). If required, the query and response may be repeated one or more times (steps 308, 310, 312), for example based on revised requirements. In step 314, the client sends a reservation message, identifying one or more of the available QoS models as the basis for a resource reservation. In step 316, the gatekeeper identifies and reserves (if possible) network resources for the data flow based on the selected QoS model(s). This may involve identifying suitable network routes and allocating bandwidth on those routes. The gatekeeper also allocates a distinct CoS identifier for the data flow, representing the negotiated QoS metrics and allocated resources. In step 318, the gatekeeper sends a response indicating the allocated resources and CoS identifier.

The CoS identifier (e.g. in the form of a DSCP as described herein) is subsequently used by the client to label traffic for the data flow. The gatekeeper or another network component (e.g. edge router) receiving data packets for the flow labelled with the CoS identifier, can then identify the agreed QoS metrics and/or allocated resources for the packets from the CoS identifier and can process and route them accordingly.

Described below is a series of three tests that can be used to determine the suitability of a model for a client request at a specific time. Typically, these tests are applied by a gatekeeper 104 in response to a query from a client 102, however, the skilled person will appreciate that the tests may equally be implemented by another network component, which may be a dedicated network node. Furthermore, as will be appreciated by the skilled person, any single test or combination of two or more tests may be applied within an implementation in any order and different numbers and combinations of the tests may be used within a particular network at different times.

Factors that are taken into account can include one or more of:

• the performance of one or more currently available QoS models (using one or more factors such as forecasted stability, confidence in adherence to QoS model);

• the contents of the initial request (for example, contained in the Initiator QSPEC of the QoS NSLP message);

• the nature of the client (their historical behaviour in both QoS models chosen for types of traffic as well as the impact of such choices on the network itself); and

• policies from the operator.

The evaluation can be categorised into three stages or tests:

1) Model-related tests 2) Client-related tests

3) Operator-related tests

As noted above, there is no prescribed order to these stages and any subset of these can be chosen for a given embodiment. In a particular, comprehensive embodiment, however, a model must pass all three sets of tests before being offered to a client. Each of the tests or stages of evaluation is described in more detail below before a worked example describes a particular implementation in more detail.

Model-related tests

A model-related test can be categorised into two parts: the first relates to stability of a QoS model over time, the second relates to deviation of the routes from the QoS model. If a QoS model is represented by cluster members centred around a cluster centre, where the cluster centre is the model specification itself and the cluster members are the routes that have been considered to exhibit performance 'close' to the cluster centre, an imaginary tunnel can be drawn in the third dimension representing time.

Figure 2 shows a group of routes, represented as dots on the left 210, around the cluster centre represented as a cross, which has been formed at time T when the principal learning component discovers this QoS model (T represents the First iteration of principal learning component and Time of cluster formation). The cluster in this example has been made based on two dimensions, hence the ellipse 212 within which the cluster members can lie and still be classified with the cluster centre. The circular two dimensional space where the routes lie has been rotated around the cluster centre to its side to add a third dimension of time in the horizontal axis. The performance of each particular route is represented by a line 214 showing the trajectory of its behaviour as it evolves over time and it can be seen that some routes deviate from the cluster centre, i.e. their distance to the cluster centre increases with time. In fact, it is evident that route X 216 breaches the acceptable outer boundary of this cluster, and hence the limit of acceptable QoS, at time T2 which is not identified by the principal learning component until time 2T when the next iteration of the principal learning component is executed to re-discover the next set of QoS models. At the time of the admission request, Tl, the gatekeeper can forecast the behaviour of route X 216. It can determine both a forecast the duration for which route X is likely to remain within this cluster as well as the extent of deviation until this time T2. The conformance of a cluster member (route) to its cluster over time, in terms of distance to cluster centre and when this becomes unacceptable, is referred to as route stability.

Route stability is forecast for the routes within a QoS model collectively to determine when the model is no longer suitable to be offered as an option. A model only qualifies this test if it is deemed to be stable for a period of time following the session request. This period of time can be a set duration or dependent on the duration of the session (or aggregate of sessions), if known. With reference to Figure 3, in one implementation, the client 102 can choose a subset of these bands in a RESERVE message 314 to specify the desired band of performance within the QoS model. This further band specification takes place in the RESERVE message, after the initial RESPONSE offer 306 of QoS models has been made. Since the system relates to generating the initial RESPONSE 306 message following the first QUERY 302 message from the client, the specification of desired bands of performance within the chosen QoS model is not yet known by the gatekeeper 104 and therefore the stability of a given QoS model being offered can potentially only be done over the entire model itself and all the routes that support this model rather than over a desired band within the overall model. Optionally, further stability tests might be undertaken in a similar fashion once the client responds with a more granular band of performance within the QoS model in later stages of negotiation, for example as part of the RESERVE 314 message or in further QUERY 308 messages.

Client-related tests

Tests may alternatively, or additionally, be implemented to prune QoS models to offer to a client based on client behaviour itself. This can include either or both of two aspects.

The first is about profiling a client' s behaviour in the past and weighting the available QoS models according to models they might prefer, optionally further taking into account the circumstances of admission request. For example, a client might choose to send different types of traffic at different times of day/week. Therefore, it might be possible to discover this periodicity over time and offer QoS models that relate to the type of expected traffic at that time. Information about incoming traffic might also be known in advance and can be used to filter out QoS models that do not support expected traffic features. The client profiling aspect can be done at any granularity. For example, the operator can choose to profile requests only across time and not by client type. This results in the operator offering 'popular' QoS models to all clients irrespective of specific client behaviour. Further features can be added to the profiling as well. Historical requests can be profiled in terms of type of traffic and desired QoS features in initial QSPEC (an object carrying QoS Signalling Policy, QSP,- specific information, which may be sent as part of the QUERY 316 message), destination and application type as well as time of day/week. The client itself can be part of a larger group of similar clients which therefore exhibit similar behaviour to each other. The focus at this stage is to determine what models best suit the current conditions for the specific client, and the more features and patterns discovered, the better the pruning will be. Whilst some of these features that can influence client behaviour in a specific instance are suggested below, further implementations can take into account other known behaviour or perform a feature selection step in advance to determine which features characterise client behaviour at a given time and therefore improve the selection of models for a specific client request.

The second testing aspect relates to determining the impact of a client on the network in the past in a 'what-if type of analysis. The network can profile a client (or aggregate) according to the likelihood of adherence to initial admission request over the course of the session. A client that has a higher likelihood of exceeding the initial request can be treated in one of two ways. The first is to not offer QoS models where the client can cause detriment beyond acceptable limits to other clients using the same model or sharing the same route. The second is to offer a QoS model but limit the bands within to prevent such detriment to other services. For example, if QoS NSLP (Next Steps in Signalling, NSIS, Signalling Layer Protocol) is being used, the incoming request, QUERY 316, will have in its Initiator QSPEC a list of features about the incoming traffic. If QoS negotiation takes place, the initial QSPEC can be updated in the RESERVE 332 message following negotiation. Information in the QSPEC object can include data rate, peak rate, bucket size, minimum policed unit of traffic and maximum packet size.

These features can be used to filter out QoS models that do not meet the required QoS features (if a min_QoS object is sent). Furthermore, this can be extended to record the initial request and corroborate it against actual performance once data transmission is complete, especially if the operator chooses to deliver out-of-contract packets when possible. This allows the operator to estimate the likelihood of deviation from the initial request from historical data. Once this is known, the operator can choose to use the 'worst case' scenario to estimate the impact on other services and limit the offering to the client if the impact is decided to be undesired. For instance, if a client is likely to exceed average data rate, a smaller throughput can be offered in a given QoS model to take into account potential deviations during transmission. Evidently, this depends on whether or not the resources are currently being shared for a given QoS model with other traffic, i.e. whether the route carries other traffic in the same or different CoS at the time of admission or over the course of data transmission. If a route is uncongested or the client is unlikely to breach initial requested QoS, network impact need not be taken into account.

Even if the client is unlikely to breach initial requested QoS, it is possible that in-contract data can still act to detriment existing services. This can be evaluated as well by correlating past requests to route behaviour after admission and determining the likelihood of detriment if admission is granted.

Offering minimum cost models can be done in two ways. The first is to offer the absolute minimum cost model without taking into account any QoS associated with the routes that support the low cost. This can be done if the client does not mandate any other metrics or if the network operator wishes to offer a model that is guaranteed to be lowest cost but does not offer performance in any way. This might be suitable for some types of traffic. The second is to take into account the specific QoS request from the client, if one is mandated using a min_QoS model, to determine minimum cost after filtering out routes that do not satisfy the min_QoS parameters. This can be done by sorting the routes according to performance first, applying the mandated QoS features to filter out routes that do not satisfy the requested performance and then sorting the remaining routes into ascending cost to offer the lowest cost route. In order to offer an appropriate minimum cost model, we can make min_QoS the first priority and compute the minimum cost after taking into account the QoS mandated by the client rather than simply offering the minimum cost model without taking into account the performance of the corresponding route(s). Nevertheless, the operator can still offer the minimum cost route irrespective of QoS performance as one of the other QoS model options.

Operator-related tests

The operator can specify a set of models that are always offered by default. For example, the operator can choose to offer classic DiffServ-related models with the DiffServ DSCP values in every service request. The operator can alternatively also offer the lowest cost model, with or without taking into account the QoS requested in the Initiator QSPEC object. A maximum threshold can be set on the number of QoS models offered in response to a single admission query. Alternatively, the operator can specify maximum performance boundaries within a given QoS model for specific clients depending on external factors such as a contractual agreement. Such boundaries of acceptable deviation from the QoS model are taken into account in the same way as described in the "Model Related Tests" section above.

Alternatively, an operator can choose to offer a set of models based on revenue. If two models offer similar performance, the operator can choose to offer the one that brings more revenue, or reduces the cost. The same logic can be extended to an entire set of models. The operator can choose to do this at certain times of day to maximise revenue at those times (either peak traffic or periods of low usage). The operator can also mandate policies and layer them into other QoS models. This can be done before the models are offered to the client with information about layered models in the feature specification, if desired, or alternatively after negotiation as described above. Worked example

The example set out below demonstrates some of the features of one implementation.

Note also that only some session requests might have pruned QoS models offered to them. Alternatively, this pruning mechanism can be done periodically at less granularity for a set of session requests that are prototypes representative of real-time requests and therefore pre-select a set of QoS models against a set of potential prototypes session requests. In such an embodiment, when a session request arrives in real-time, the gatekeeper must only determine which of the session prototypes the current session is most similar to and therefore offer the associated pre-determined set of QoS models in response to this request without incurring computation on the fly and therefore a longer delay in responding to clients. Determining the set of prototype sessions can be done periodically by clustering client requests over a number of features when the principal learning component completes its iteration.

In the implementation set out below, we assume that such session prototyping has not been done and therefore, we describe how the invention responds to a single client request. This provides an accurate method of determining the optimal set of QoS models for a specific client request as it does not approximate the session to the session prototype and therefore introduce cause for errors. For the remainder of this example, we assume that the set of QoS models offered to the client is computed directly from the client request itself.

With reference to Fig. 1, consider a client request, sent using NSIS (QoS NSLP and GIST, General Internet Signaling Transport) to the gatekeeper 104 for a session SI of throughput 5 Mbps from the client's IP address CI 112 to destination C2 114 and QoS parameters as follows: jitter = 3ms, Loss = 0.1%, delay = 25ms. Assume that the client 102 makes this request at 11:00AM. There might be other parameters that describe this session request as well, such as bucket size, burst rate, peak rate, maximum policed unit and minimum policed unit. Some of these features can be used for policing the session post-admission. The task for the gatekeeper 104 is now to determine which QoS models currently available would be best suited for this request. We have proposed three sets of tests to determine this result.

The first is model-related tests. This has to do with establishing whether a model is expected to be stable for a time in the future for its QoS offering. We therefore consider each available model and perform the following test. The degradation of QoS is assessed on a model-basis. Note that this component can be triggered potentially on a session-by- session basis as the admission requests arrive.

The performance prediction can be done on several levels of granularity: On a per model basis, on a per destination point and model basis, and on a per route and model basis. On any level of granularity a performance prediction provides a time-based estimation of the performance parameters jitter, loss and delay and an estimate of the amount of traffic that is likely to be assigned to at that time.

The simplest prediction model is to record the performance over a number of time intervals and then simply use them to predict the performance in the equivalent future time interval. For example, the operator could build a 24 hour model with hourly performance statistics. The values from each hourly slot would then become the predictions going forward, e.g. the recorded performance today between 14.00 and 15.00 will become the prediction for tomorrow's corresponding time slot. The values for each time slot get updated once every 24 hours. Such a type of model is appropriate for networks with regular traffic patterns and where the network operator is not worried about breaching performance of a model once and then making a decision if the model can be advertised again in the future. Such a model learns if a QoS model is expected to perform as expected and what the average demand would be for each time slot. For a time slot where the estimate shows that a model would not perform well it would subsequently no longer be advertised for this time period until the operator decides to withdraw the model altogether because it does not perform well enough in a sufficient number of time slots. Time slots that show a high demand for a model can be managed by changing the policy relating to which client gets offered which QoS model. Additionally, the gatekeeper can withdraw models in real-time if they are oversubscribed.

The information from such a predictive model can be stored in a predictive model features table PMF. The following table shows a peak demand for QoS Model ID P_l on route R_l at lunch time which results in slightly worse confidence profile compared to the time around midnight, where demand is low and performance is high. The QoS model still performs in an acceptable manner at lunch time, but the expected demand can prompt the network operator to not offer the QoS model to all clients at this time but implement some policy that restricts the offer to certain clients only.

Route Model Time Route Confidence Profile Demand [Mb/s]

ID Ri 1 00.00 (0.028, 0.0015, 0.2193) 20

12.00 (0.035, 0.002, 0.2357) 100

23.00 (0.0280, 0.0015, 0.2193) 30

The drawback of this method is that once a model has performed badly in a time slot, it will no longer be offered at this time and therefore data can no longer be collected about this model in this time slot. A more flexible predictive model would take different factors into account and try to predict future performance in dependence to a number of attributes like amount of traffic, type of traffic and traffic distribution in addition to the past performance of a QoS model. This way a QoS model can "recover". For example, the prediction could be that a model is not going to perform well in the next hour because of the current amount of traffic. However, the prediction for the same time slot next day can look different, because there may be less traffic at that time.

Such a predictive model /can be built from historic data collected per QoS model and from network monitoring data using methods like regression analysis or neural networks, for example. The predictive model /predicts a future confidence vector c _£ for a QoS model P _£ : i = f(p _i , c _i , T, F, B, C, C, ... ) Where T is time distance we want to predict into the future, F is the number of traffic flows on the current route, B is the available bandwidth, C is the current throughput, and C is the expected future throughput, and there can be other variables describing the current traffic behaviour on the route such as rate of change of congestion (Explicit Congestion Notification markings on the route). Other data sources and features can also be considered in this analysis. The model /has been built such that it predicts c _£ at a certain time in the future, e.g. 1 hour ahead. If required, it is possible to build several predictive models for different time horizons. In this example, the predictive model is generic and can be applied to any route and any QoS model P _£ because it receives the QoS model parameters p _£ and c _£ as well as the current route conditions as input. If such a generic model is not accurate enough, it is possible to build predictive models per QoS model, per route or per QoS model/route combination etc. The expected future throughput C, can be obtained from a dedicated predictive throughput model or from a historic profile, or it can be a projection of traffic to be admitted in order to predict the impact of this traffic. Additional parameters like maximum packet size, likelihood of clients to send more traffic than agreed etc. can also be used. The network operator will decide which factors are considered to have an impact on the performance of QoS models and include them into the predictive model. The historic data used to build such a predictive model /, is the same data used for the clustering analysis plus additional data about the traffic conditions in the network collected at the same time as the data about individual flows. The predictive model is rebuilt in regular intervals, e.g. every 24 hours to take changes in network traffic into account. Using this method, the network can refrain from offering models that are considered to be unstable in the near future and therefore not risk service degradation at a later stage. Some available models will be filtered out in this step. In the example below, model M7 is filtered out due to instability issues. The second is client-related tests. In the embodiment, three sets of information are used for this step:

1) A repository of past requests from this client recording QoS features requested (potentially not just jitter, loss and delay).

2) The admission decision taken in the past in response to the QoS request. This also includes the QoS features agreed upon (following negotiation if applicable or as described by the published QoS model on the 'scoreboard').

3) A characterisation of the actual data sent by the client following admission.

4) Expected network conditions such as current/projected throughput for each of the CoS on offer.

We use this information as follows:

The first sub-component of this aspect is to determine whether or not there are any similar QoS models that can be proposed from the current set that also coincide with the client's past requests. Consider that this client has had 5 past requests as shown in the table below: Session ID Source Destination Time of QoS features QoS features

day requested used

S2 CI C2 Tl = {J1, L1, D1 } {J1, L1, D1 }

10:00

S3 CI C2 Tl = {J1, L1, D1, {J1, L1, D1,

10:00 Rl } Rl }

S4 CI C3 T2 = {J2, L2, D2, {J2, L2, D2,

16:00 Rl } Rl }

S5 CI C4 T3 = {L3, E1 } {L3, E1 }

20:00

S6 CI C2 T4 = {J1, L1, D1, {J1, L1, D1,

12:00 Rl } Rl }

It can be seen that the client has requested two sessions to C2, at two distinct times Tl (twice, perhaps on different days) and T4 with a set of QoS features characterised by jitter = Jl, loss = LI, delay = Dl, resilience = Rl. The client has also made other requests to other destinations at different times and requested different QoS features including an energy-related feature of El in S5. Note that some of these features are softer policy- related. In this case, it is assumed that the client was granted what they had requested. This could be due to a successful negotiation or indeed because the client chose from a published scoreboard relating to the QoS models. Other features that characterise the client requests can also be recorded. The task undertaken based on this data is pattern mining and this is extensible for as many features as considered useful. Further steps in advance of this stage can be undertaken to determine which features best represent a client request and the operator might choose to include, for example, geographical location of destination.

If session SI has an associated QoS request as described above, the similarity of SI to the historical set of requests can be computed to determine which session it is closest to. A request can be represented as a set of numbers. Comparing requests can therefore be done by computing Euclidean vector distance between the current request and the past requests. If there are missing components, this component can be left out from the comparison. One can also place a threshold on the minimum number of times a request must be made before it qualifies to be compared. Also, alternatively, the past history of requests need not be maintained in their entirety but only as an aggregation against a set of features that characterise the request. For example, the above request can be summarised further by time of day and filtered by number of requests of the same type so that fewer records are maintained of the past. Such alternatives are only about data management and are variations of the embodiments described herein. Note that the operator can place as many restrictions in the comparison as necessary. For example, a client request might only be compared to other client requests to the same destination. Alternatively, a client request can only be compared to other requests based on similarity in QoS features, rather than source-destination combination. In the present example, source-destination combinations are not restricted, but a restriction is placed on QoS features being most similar and also time of day being within a specific window of 4 hours. This could be to take into account hourly variations in traffic type sent from a client entity. Using this comparison method, we find that SI is most similar to requests S2, S3 and S6. The system then looks at which QoS models were offered for S2, S3 and S6. One possible option is to choose {Jl, LI, Dl, Rl } as well as {Jl, LI, Dl }. Alternatively, the QoS model with more features can be chosen. Alternatively, a pre-defined number of QoS models can be chosen, in decreasing order of session similarity to the current request. Assume that the system chooses up to three QoS models in decreasing order of session similarity and therefore, both of these QoS model features will be selected for the next step.

It will be understood that the QoS features {Jl, LI, Dl, Rl } and {Jl, LI, Dl } were offered in the past, possibly as QoS models Ml and M2 respectively. It is possible that Ml and M2 do not exist at the current time and therefore, the next step is to determine which QoS models currently exist that can support QoS features {Jl, LI, Dl, Rl } as well as {Jl, LI, Dl } previously offered by Ml and M2. Note that the agreed QoS models are taken into account rather than the client request because it is possible that client negotiation has taken place and therefore the agreed QoS model was considered to be the better option in the past and the session request was amended. It is also possible that the agreed model is different to the requested model because of stability concerns on behalf of the network for the requested model and therefore the agreed model was offered in preference instead. Therefore, it is preferable to compare previous QoS models offered to current QoS models available to determine the best suitable set of models for the current request rather than directly working from the requested features.

The task now is to determine which of the current QoS models are most similar to Ml and M2. This is once again done using vector similarity of features. In this case, the outcome of this step is that models Ml and M2 are most similar to a different set of models M3 and M4. Note that it is possible that more than one model is offered with each option. Therefore, Ml can be most similar to M3, M5 and M6 in decreasing similarity whereas M4 is most similar to M7 and M8 in equal similarity. Therefore, the operator can choose to offer any subset of M3, M5, M6, M7 and M8 in response to the client request SI.

The second sub-component of this test is to evaluate whether M3, M5, M6, M7 and M8 are likely to experience degradation as a consequence of admitting SI. This depends on determining the risk associated with the client and SI and also the likelihood of this risk to impact the models.

The risk of a client to deviate from requested QoS behaviour can be calculated by observing the client's behaviour in the past and computing the number of times the client has sent more traffic than agreed and the average amount of extra traffic that was sent at those times. This profiling can be done at any level of granularity, e.g. Class of Service, application type (if available) and/or time of day. It can also take into account a number of traffic descriptors like peak data rate, maximum policed unit, burst size, etc. in addition to average throughput over session duration. The historic time period that is used for this computation is set by the network operator. The shorter this time period, the faster the network 'forgets' that a client has deviated from requested QoS behaviour. Alternatively, instead of comparing actual traffic with agreed traffic, the network can use the number of ECN (Explicit Congestion Notification) markings applied to the client source address to determine how often the client traffic has been marked as being likely to be dropped. Alternatively, the network can use other policing mechanisms already in place in order to determine how much traffic the client typically sends out-of-band - such policing is typically done at BRAS (Broadband Remote Access Server) elements.

In this example, the ratio of out-of-band traffic to in-band traffic is used as the metric that describes the extent of deviation from agreed SLAs (Service Level Agreements). The frequency of this occurrence in comparison to the total number of times the client has sent traffic of this profile is the probability of this breach occurring in the future. This then quantifies the extent of deviation as well as the likelihood of this happening for a specific client under the current conditions.

Assume that this client has been profiled in such a manner and it has been determined from historical behaviour that the client is 30% likely to send 20% more traffic than agreed at this traffic band of 5 Mbps. In order to make a decision, we enhance the QoS model performance forecasting method used in the model-related test described above to determine if the QoS Model is likely to perform worse if the client is admitted. In order to make this prediction the predictive function / that the PM (predictive model) uses to predict future QoS model performance is used with a set of inputs that take the current client request into account. The period that is predicted into the future can depend on what is known about the type of request and experience the network operator has with impact analysis. The inputs for / are the same as for predicting model performance in general, but the inputs about expected traffic are modified with the details from the client request. If the prediction shows that the admitting the client leads to an unacceptable deterioration of the QoS model, this QoS model will not be offered to the client. The network operator decides what is deemed unacceptable, e.g. if the predicted performance would lie outside the agreed confidence interval for at least on component of the QoS model.

The prediction can be checked for a number of QoS models on route level or globally depending on the network operator's preferences and the compute power and time available to process these predictions. More finely grained predictions reduce the risk for the network operator, but will take more time and resources for the negotiation phase. Consider model M6 as an example. Assume that according to the current prediction that does not yet take the traffic of the requesting client into account the performance of M6 is stable for 11 :00AM, i.e. it is predicted that it will operate within expected parameters (not more than 10% deviation from model prototype in any QoS component). The predicted performance confidence interval for M6 is (0.25, 0.01, 2).

The client asks for a throughput of 5Mb/s and it has a likelihood of 30% to send 6Mb/s as the PM knows from analysing past traffic from this source. The predictive model / can be used to predict the future confidence vector c ₆ for M6 assuming the traffic is admitted into the network:

t ₆ = f(p ₆ , c ₆ , T, F, B, C, C, ... )

and C = 6 (= 5 + 20%) is used and the likelihood to send more traffic as agreed and the expected amount of traffic that is not agreed are also provided as parameters (iff is used to predict the QoS performance without considering a session to be admitted these two parameters are simply set to 0). T is the time we want to predict into the future and we apply/three times with T=l, T=2 and T=3 to obtain a three hour prediction window.

Assume that / returns (0.5, 0.01, 2) for 11 :00. M6 has the prototype (3.0, 0.1, 25) and the predicted performance at 11 :00AM is now outside the acceptable deviation of 10%. Whilst M6 is expected to perform in a stable manner without taking into account S I, the new session has been deemed to cause an unacceptable detriment to M6. Therefore M6 will not be offered to this client request. Note that it is also possible that the subset of currently available QoS models is done based on the projected stability of these models (model-related tests). Therefore, it is possible that only M3, M5 and M8 are considered stable and offered in response to the client and M7 is considered unstable and filtered out. The third set of tests relate to operator preferences. This is a set of default models that are always offered. One of these models can be a lowest cost model. This is determined by sorting the cost model in ascending order of cost and determining which of the routes can support the desired QoS requested in the initial request. Alternatively, the lowest cost model can be offered without consideration of QoS performance desired. Note that the cost model can be time-dependent and therefore a different low cost route can be chosen at a different time for the same request. Choice of route and sorting of routes has been covered in an earlier invention. We only propose here to use the desired QoS performance in the initial request received for SI to filter out routes that do not perform as desired and subsequently determine the lowest cost from the routes that do perform as desired. If the lowest cost model is offered as an option, then the cost value itself (or bands of cost vs. bands of QoS operation/time of day) can be signalled in the associated parameter information for the cost-related model.

Additionally, the operator can choose to offer, by default, models that are closest to classic DiffServ. These can be models M9 for EF and M10 for AFx in the current iteration of the principal learning component. Note that the same applies in a non-dynamic QoS environment. Such a system would in fact be simpler to implement as the offered models will not change over time. Stability of non-dynamic models can still be evaluated in the same way prescribed here and operator-related constraints can still be incorporated in the same way.

Therefore, the outcome of the evaluation is that models M3, M5, M8, M9 and M10 are offered in response to client request for SI instead of a much larger and potentially less relevant set of QoS models without knowledge of client behaviour.

Note that the three sets of tests can be performed in any order. The task is to reach the smallest set of models as quickly as possible. If there are many unstable models, then this step can be performed first. If there are only a few client requests from the past, the client- related tests can be performed first. It is also possible to skip some of these tests entirely. For example, if no past client requests are recorded, recommendations of QoS models cannot be made and the other two tests take precedence. Alternatively, if no requests have been recorded from this client, requests of similar nature from similar clients can be used instead. Similarity to other clients can once again be determined based on a comparison of their requests to the current client' s request in the local geographical region, time of day or indeed any set of characteristics that are considered to be representative of the clients' behaviour. Figure 4 illustrates hardware architecture that may be provided to implement the analysis described herein, which is illustrated as a server 1500. The server may be implemented as part of a gateway component in the network. The server includes one or more processors 1602 together with volatile / random access memory 1606 for storing temporary data and software code being executed.

A network interface 1604 is provided for communication with other system components (e.g. client, database 1506 and core network components) over one or more networks (e.g. Local or Wide Area Networks, including the Internet). The database 1506, which may be implemented within or external to the server 1500, may be used to store information such as QoS models and their associated parameters and data relating to the past preferences and behaviour of clients and the network. Persistent storage 1608 (e.g. in the form of hard disk storage, optical storage and the like) persistently stores analysis software for performing the functions, including an analysis process 1610, a selection process 1612 and a process for communicating with a client 1614. The persistent storage also includes other server software and data (not shown), such as a server operating system.

The server will include other conventional hardware and software components as known to those skilled in the art, and the components are interconnected by a data bus (this may in practice consist of several distinct buses such as a memory bus and I/O bus). A client device 1502 may also be provided, including one or more processors 1702 together with volatile / random access memory 1704 for storing temporary data and software code being executed.

A traffic flow for which the client is requesting a path through the network may originate at the client 1502 or may be received by the client via the network interface 1706. Communication is also provided to the server 1500 via the same or a separate network interface 1706 (but is illustrated herein as a single interface). The network interface communicates over one or more networks (e.g. Local or Wide Area Networks, including the Internet).

Persistent storage 1708 (e.g. in the form of hard disk storage, optical storage and the like) persistently stores software for performing the functions of the client, including a QoS query process 1710, a reserve process 1712 and a traffic flow management process 1714.

The client will include other conventional hardware and software components as known to those skilled in the art, and the components are interconnected by a data bus (this may in practice consist of several distinct buses such as a memory bus and I/O bus).

While a specific architecture is shown by way of example, any appropriate hardware/software architecture may be employed.

Furthermore, functional components indicated as separate may be combined and vice versa. For example, a database 1506 may be stored at the server 1500 (e.g. in persistent storage 1608) or may be provided as a separate database server. Furthermore, the functions of server 1500 or client 1502 may in practice be implemented by multiple separate server devices. The client 1502 may also store or have access to a database.