EP1195074A1

EP1195074A1 - Improvements in, or relating to, telecommunications systems

Info

Publication number: EP1195074A1
Application number: EP00946635A
Authority: EP
Inventors: David Ahlard; Joakim Bergkvist; István CSELENY
Original assignee: Telia AB
Current assignee: Telia Co AB
Priority date: 1999-06-24
Filing date: 2000-06-22
Publication date: 2002-04-10
Anticipated expiration: 2020-06-22
Also published as: SE516754C2; NO20015881D0; ES2295038T3; NO20015881L; SE9902419D0; EE05120B1; ATE373939T1; EE200100703A; NO326027B1; DK1195074T3; SE9902419L; DE60036473D1; WO2001001728A1; EP1195074B1

Abstract

A telecommunications data transmission system includes a transmission network having a plurality of nodes, a plurality of access nodes and a plurality of subscriber terminals connected to access nodes. The telecommunications data transmission system is adapted to support provision of multimedia telecommunications services and employ a resource reservation protocol. The resource reservation protocol is unique in that it permits users to specify a preference for a multiplicity of levels of QoS and to reserve a plurality of resource types. A user's preference, with regard to QoS, is recorded by elements of a Price Vector, each element of which corresponds to a notional "price" that a user is prepared to pay for a given level of said multiplicity of levels of QoS. A set of possible resource values for each resource type is recorded by the elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types. The Price Vector is merged with the Resource Vector to produce a Downgrade Vector specifying resource levels, supported by a given application, which a user is prepared to accept in a descending order of user preference. The Downgrade Vectors are propagated through the transmission network, from node to node, in resource reservation messages.

Description

Improvements in. or Relating to. Telecommunications Systems

The present invention relates to a telecommunications system employing a resource reservation protocol, a subscriber terminal adapted for use with the telecommunications system and a method of resource reservation for use in a telecommunications system.

Most currently known resource reservation protocols propagate only one specific resource value, for example, peak transmission rate, per reservation trial, even if there are several, distinct, resource values that can be accepted by a scalable application. If the required resource value cannot be reserved, it is up to the end-user application to downgrade the original resource demand and send a new reservation message. Therefore, multiple reservation trials are needed, since the scalable nature of the application is ignored. Even the exceptions, for example, ABR in ATM, handle only two resource values, i.e. mean and peak cell rates. The ability of users to perceive quality in a more granular manner, i.e. the ability of users to differentiate several steps between the two extremes, is ignored.

Multiple reservations clearly result in inefficient network usage. They create long and variable connection setup times and require the network nodes to handle more signalling messages than are really needed in order to achieve a successful connection setup. A further problem is that multiple reservations lead to blocking caused by over-allocated resources in the network.

A common approach is to have policy servers associate only a simple priority to users and applications, e.g. high, medium, or low, see Dynamic-Access Software, 3COM Technical Papers, 1997, although the QoS policy could reflect the capabilities of the application and the preferences of the user.

Multimedia applications with distinct quality parameters, e.g. video frame rate, picture resolution, or audio sampling rate, have a certain set of possible resource values that they require from the network. The set of these resource values can be expressed in a Resource Vector. Moreover, users have different opinions about the different quality settings and assign different price thresholds to each, resulting in a Price Vector. The information represented by these two vectors can be combined in a Downgrade Vector, which can be carried in the reservation message (e.g. RSVP/RESV or IRMA/RING). This enables routers, or ATM switches, to utilise the downgrade vector for intelligent resource reservation.

The present invention utilises Resource Vectors, Price Vectors and Downgrade Vectors to provide an improved technique for resource reservation.

The definition of Resource Vector, Price Vector and Downgrade Vector for generalised resource types and applications, their calculation and usage for policy based resource reservation, is unique to the present invention. A simpler concept using the downgrade vector has been described for the videophone service with four quality parameters and one resource type, namely bandwidth, see R. Szabό, I. Cselenyi, Performance Evaluation of an Intelligent Resource Allocation Scheme for Multimedia Applications, SPECTS'98, Symposium on Performance Evaluation of Computer and Telecommunication Systems, Reno, Nevada, July 19-22, 1998, pp. 302-306.

The main advantages of using the Downgrade Vector approach for resource reservation, as in the present invention, include:

fewer connection setup trials;

dynamic policy handling; and

more useful and informative network policies, i.e. not only high, medium, low priority.

Because the present invention requires fewer setup trials, the connection setup time is reduced and is fixed, there is a reduced demand for temporary allocation of resources which, in turn, reduces the probability of call blocking. In addition, fewer signalling messages per connection setup are required.

According to a first aspect of the present invention, there is provided a telecommunications data transmission system comprising a transmission network having a plurality of nodes, a plurality of access nodes and a plurality of subscriber terminals connected to access nodes, said telecommunications data transmission system being adapted to support provision of multimedia telecommunications services and employing a resource reservation protocol, characterised in that said resource reservation protocol is adapted to permit users to specify a preference for a multiplicity of levels of QoS and in that said resource reservation protocol is adapted to reserve a plurality of resource types.

A user«s preference with regard to QoS may be recorded by elements of a

Price Vector, each element of which corresponds to a notional •price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

Default values for each element of said Price Vector may be determined from user trials.

A set of possible resource values for each resource type may be recorded by the elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types.

Means for merging said Price Vector with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference may be provided.

Said Downgrade Vector may be carried by resource reservation messages propagated between nodes in said transmission network.

Each of said plurality of subscriber terminals may be adapted to calculate a Downgrade Vector for each application running thereon and said subscriber terminal may be adapted to transmit said Downgrade Vectors to the transmission network.

Said Downgrade Vectors may be calculated from Price Vectors and Resource Vectors retrieved from configuration files stored in said subscriber terminals.

Said Downgrade Vectors may be calculated from Price Vectors and Resource Vectors retrieved by said subscriber terminals from a policy server.

Said Downgrade Vectors may be calculated from Price Vectors, derived directly from requests addressed to a user of said subscriber terminal, and Resource Vectors retrieved by said subscriber terminal.

Said access nodes may be adapted to calculate a Downgrade Vector from a Price Vector stored in a user database and a Resource Vector.

Downgrade Vectors for each application and user, or groups thereof, may be pre-calculated and stored in a policy server from where they can be retrieved by a subscriber terminal, or access node.

A Downgrade Vector may be built into a resource reservation protocol adapted to handle specific resource demands.

A Downgrade Vector may be carried in a RSVP/RESV reservation message.

A Downgrade Vector may be carried in an IRMA/RING reservation message.

According to a second aspect of the present invention, there is provided a subscriber terminal, for use with a telecommunications data transmission system as set forth in any preceding paragraph, and adapted to support a resource reservation protocol, characterised in that said resource reservation protocol is adapted to permit users to specify a preference for a multiplicity of levels of QoS and in that said resource reservation protocol is adapted to reserve a plurality of resource types. A user*s preference with regard to QoS may be recorded by elements of a Price Vector, each element of which corresponds to a notional • price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

Merge means for merging said Price Vector with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference, may be provided .

Said Downgrade Vector may be transmitted to said transmission network by resource reservation messages.

Said Downgrade Vector may be calculated from a Price Vector and a Resource Vector retrieved from configuration files stored in said subscriber terminal.

Said Downgrade Vector may be calculated from a Price Vector and Resource Vector retrieved by said subscriber terminal from a policy server.

Said Downgrade Vector may be calculated from a Price Vector, derived directly from requests addressed to a user of said subscriber terminal, and a

Resource Vector retrieved by said subscriber terminal.

A Downgrade Vector may be carried in a RSVP/RESV reservation message.

According to a third aspect of the present invention, there is provided a method of reserving resources in a telecommunications data transmission system comprising a transmission network having a plurality of nodes, a plurality of access nodes and a plurality of subscriber terminals connected to access nodes, said telecommunications data transmission system being adapted to support provision of multimedia telecommunications services and employing a resource reservation protocol, characterised by said resource reservation protocol being adapted to permit users to specify a preference for a multiplicity of levels of QoS and by said resource reservation protocol being adapted to reserve a plurality of resource types.

A user*s preference, with regard to QoS, may be recorded as elements of a Price Vector, each element of which corresponds to a notional • price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

A set of possible resource values for each resource type may be recorded as elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types.

Said Price Vector may be merged with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference.

Said Downgrade Vector may be propagated between nodes in said transmission network in resource reservation messages.

Each of said plurality of subscriber terminals may calculate a Downgrade Vector for each application running thereon, and said subscriber terminal may transmit said Downgrade Vectors to the transmission network.

Said Downgrade Vectors may be calculated from Price Vectors and

Resource Vectors retrieved from configuration files stored in said subscriber terminals.

Said Downgrade Vectors may be calculated from Price Vectors and Resource Vectors retrieved from a policy server.

Said access nodes may calculate a Downgrade Vector from a Price Vector stored in a user database and a Resource Vector.

Downgrade Vectors may be pre-calculating for each application and user, or groups thereof, and said Downgrade Vectors may be stored in a policy server from where they can be retrieved by a subscriber terminal, or access node.

A Downgrade Vector may be carried in a RSVP/RESV reservation message.

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a flow chart for calculating a Downgrade Vector by merging a Resource Vector and Price Vector.

Figure 2 illustrates a resource reservation scheme according to the present invention.

Multimedia applications with distinct quality parameters, e.g. video frame rate, picture resolution, or audio sampling rate, have a certain set of possible resource values that they require from the network. The set of these resource values can be expressed in a Resource Vector. Moreover, users have different opinions about the different quality settings and assign different price thresholds to each resulting in a Price Vector. These two kinds of information can be combined in a Downgrade Vector, which can be carried in the reservation message, e.g. RSVP/RESV, or IRMA/RING. Routers, or ATM switches, can utilise the downgrade vector for intelligent resource reservation.

Multimedia applications usually have several parameters which influence the quantity of network resource, e.g. bandwidth, or multiplexing buffer size, required for a given QoS. For instance, by altering the video coding parameters of a scalable MPEG application, its bandwidth requirement scales from 2.7, 3.085, 3.6, 4.32, 5.4, 7.2 up to 10.8 Mbps, see CAMVision-2 7615, User Guide, Litton Network Access Systems, Inc., October 1998. For describing the general case, the following terminology can be used:

the number of independent quality parameters of the multimedia application is denoted by N;

the number of values which can be taken by the nth parameter is denoted by Xn, where n=1 ,2...N;

the number of independent network resource types, e.g. bandwidth, token bucket size, route, priority, ..., which are demanded by the application is denoted by K; and

the set of possible resource values for the kth resource type, given in a set is denoted by

Φ * = K,ι ,₂ r_ktLk ] fr - 1.2... K

where Lk denotes the number of elements in the i ^h resource set, i.e. the number of combinations of every parameter influencing how much the application requires from the k¹*¹ resource type and U is given by:

The elements of each Resource Vector can be sorted in descending order yielding K Resource Vectors:

= |/*.i' ^r*.2--- u ^r< ^{≤ r}ϊ » i > /> U = L_k; k = 2,.... K

This represents the special information that can be determined in accordance with the capabilities of the multimedia application. It should be noted that some combinations of the N parameters result in the same resource requirement, thus neighbouring elements of a Resource Vector can be equal.

The second task is to describe how much the user prefers the different application's qualities which result from different parameter settings. The simplest way to achieve this task is to establish a vector describing the maximum price that the user is prepared to pay for the different settings of the parameters. Price is simply considered as a type of metric for ranking purposes. In this context • price * relates to a user*s preference and does not represent an absolute value and has nothing to do with real charge, cost, or price. If the user does not want to accept a certain parameter combination, he may give 0 as a threshold, in other words he states that he does not wish to pay anything for the quality resulting from this setting. There is a Price Vector for each resource type, namely:

Pκ = Pk.vPw-P k,L_k _{Pk l} e {0,X.. P), i = \2...L_k k = X2,...K

where P denotes the maximum price in the system (e.g. 65535 or 255).

Default prices can be determined from user trials and can be individually adjusted for each user.

The information about the application and user behaviour, i.e. the Resource and Price Vectors, can be merged into the Downgrade Vector. This vector specifies the resource amounts which the application supports and the user is ready to accept, in a descending order, and can be expressed as: d_k = " k,1 ' " )f,2 > ' ... Of u. C 'L k.i, e Φ i = \2, .. J_k\ Λ- = 1.2... ^"

where Jk denotes the number of elements in the Downgrade Vector belonging to the kth resource type. This can be equal, or less than, L_k, because all resource values which are not unique, or for which the price is zero or not unique, may be omitted from the Downgrade Vector. It should be noted that the price is not unique if the user does not perceive any difference in the application quality when a quality parameter is changed. Therefore, different parameter combinations, i.e. resource values may be equally preferred, (priced), by the user. The merging algorithm is illustrated by a flowchart shown in Figure 1.

The Downgrade Vector, d_k, expresses the information that the network nodes consider during the reservation of the k^h resource.

There are many ways of calculating the Downgrade Vector, including:

by the terminal sending the reservation request;

at the policy enforcement point, e.g. access routers; and

- by the policy server using the Resource and Price Vectors stored in the policy database.

The three scenarios referred to above will now be described.

Consider the use of an intelligent terminal. In this scenario, the terminal has the Resource and Price Vectors. Both can be retrieved from a configuration file, or from the policy server, or the latter can also be directly requested from the user. The Downgrade Vector can be calculated for each application demanding QoS in advance, or just before sending the reservation message. A simple scenario is depicted in Figure 2 in order to illustrate a possible reservation scheme for this case. The caller sends the Downgrade Vector, which has three elements, in this example, in the reservation message. The nodes perform CAC and if the largest element of the vector can be admitted, they allocate resources according to that and forward the reservation message onward.

The penultimate node cannot accept the largest resource value, thus it takes the second element, which fits in well with the available resource. It allocates resources, forwards a new reservation message which does not contain the largest resource value, i.e. the new Downgrade Vector starts with the original second element, and sends back a tear message to the previous nodes, in order to release the resources beyond element two. When the reservation message reaches the callee, the connection is established with guaranteed resources.

In the case of policy enforcement in the access node, the user requesting resource reservation is first authenticated to the access node, i.e. the user starts a user session. The access node can look up the Price Vector belonging to the identified user in its user database, or that of the ISP. After authentication, the user specifies the service session by giving some reference to the service, the other parties and the required quality. The access node uses this information to find the right policy for the user and the service, e.g. by contacting the policy server. This policy information contains the proper Price Vector, or at least a part of it, if the user is not allowed to take all resource values. The access node can then calculate the Downgrade Vector and initiate the reservation by sending the Downgrade Vector in a reservation message (e.g. IRMA/RING).

In the case of a static handling policy, the policy server stores pre- calculated Downgrade Vectors for each application and user, or application group and user group. The host, or the access node, retrieves these preexisting Downgrade Vectors before initiating a reservation.

The Downgrade Vector can be built into any resource reservation protocol, which handles explicit resource demands, e.g. ATMF/UNI, ITU/Q.2931 ,

IETF/RSVP and IRMA/RING. The network nodes are then able to perform downgrading based on the Downgrade Vector.

The Resource and Price Vectors can be built into policy servers, which store the relationships among users - applications - and network policy. Instead of a simple high/low priority mapping, a complete Preference Vector can be stored in this table. The policy can be obtained by the policy enforcement point, or the sending host, and merged together into a Downgrade Vector.

The advantages of using the Downgrade Vector, as outlined above, include:

fewer connection setup trials yielding:

shorter and fixed connection setup time;

less demand for temporarily allocated resources, leading to a reduced probability of call blocking; and

fewer signalling messages per connection setup;

dynamic policy handling; and

- more useful and informative network policies, i.e. not only high, medium, low priority.

Known signalling protocols for resource reservation specify only one, or two, bandwidth values, while the downgrade vector describes the full range of possible resource levels for several resource types which can be taken by the application and which are preferred by the user.

The definition of Resource Vector, Price Vector and Downgrade Vector for generalised resource types and applications, their calculation and usage for policy based resource reservation, is unique to the present invention. A simpler concept using the downgrade vector has been described for the videophone service with four quality parameters and one resource type, namely bandwidth, see R. Szabό, I. Cselenyi, Performance Evaluation of an Intelligent Resource Allocation Scheme for Multimedia Applications, SPECTS'98, Symposium on Performance Evaluation of Computer and Telecommunication Systems, Reno, Nevada, July 19-22, 1998, pp. 302-306

The present invention has particular application to the IRMA (Intelligent Resource Management Architecture) project, an ongoing internal project conducted by Telia Research. A new, hop-by-hop resource reservation protocol, called RING, has been implemented in the IRMA Router prototype. The current prototype will be extended by:

- the use of a QoS User Interface on the user's terminal which can connect to the policy server, retrieve the Resource and Price Vectors and calculate the Downgrade Vector for the applications for which the user wants to reserve resources;

- the RING reservation message being extended with a field carrying the Downgrade Vector; and

RING-aware nodes performing downgrading using the Downgrade Vector.

Claims

1. A telecommunications data transmission system comprising a transmission network having a plurality of nodes, a plurality of access nodes and a plurality of subscriber terminals connected to access nodes, said telecommunications data transmission system being adapted to support provision of multimedia telecommunications services and employing a resource reservation protocol, characterised in that said resource reservation protocol is adapted to permit users to specify a preference for a multiplicity of levels of QoS and in that said resource reservation protocol is adapted to reserve a plurality of resource types.

2. A telecommunications data transmission system, as claimed in claim 1 , characterised in that a user*s preference with regard to QoS is recorded by elements of a Price Vector, each element of which corresponds to a notional •price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

3. A telecommunications data transmission system, as claimed in claim 2, characterised in that default values for each element of said Price Vector are determined from user trials.

4. A telecommunications data transmission system, as claimed in any previous claim, characterised in that a set of possible resource values for each resource type are recorded by the elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types.

5. A telecommunications data transmission system, as claimed in claim 4, characterised in that there is provided merge means for merging said Price Vector with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference.

6. A telecommunications data transmission system, as claimed in claim 5, characterised in that said Downgrade Vector is carried by resource reservation messages propagated between nodes in said transmission network.

7. A telecommunications data transmission system, as claimed in claim 6, characterised in that each of said plurality of subscriber terminals is adapted to calculate a Downgrade Vector for each application running thereon and in that said subscriber terminal is adapted to transmit said Downgrade Vectors to the transmission network.

8. A telecommunications data transmission system, as claimed in claim 7, characterised in that said Downgrade Vectors are calculated from Price Vectors and Resource Vectors retrieved from configuration files stored in said subscriber terminals.

9. A telecommunications data transmission system, as claimed in claim 7, characterised in that said Downgrade Vectors are calculated from Price Vectors and Resource Vectors retrieved by said subscriber terminals from a policy server.

10. A telecommunications data transmission system, as claimed in claim 7, characterised in that said Downgrade Vectors are calculated from Price Vectors, derived directly from requests addressed to a user of said subscriber terminal, and Resource Vectors retrieved by said subscriber terminal.

1 1. A telecommunications data transmission system, as claimed in claim 6, characterised in that said access nodes are adapted to calculate a Downgrade Vector from a Price Vector stored in a user database and a Resource Vector.

12. A telecommunications data transmission system, as claimed in claim 6, characterised in that Downgrade Vectors for each application and user, or groups thereof, are pre-calculated and stored in a policy server from where they can be retrieved by a subscriber terminal, or access node.

13. A telecommunications data transmission system, as claimed in any previous claim, characterised in that a Downgrade Vector is built into a resource reservation protocol adapted to handle specific resource demands.

14. A telecommunications data transmission system, as claimed in any previous claim, characterised in that a Downgrade Vector is carried in a RSVP/RESV reservation message.

15. A telecommunications data transmission system, as claimed in any of claims 1 to 13, characterised in that a Downgrade Vector is carried in an

IRMA/RING reservation message.

16. A subscriber terminal, for use with a telecommunications data transmission system as claimed in any of claims 1 to 15, and adapted to support a resource reservation protocol, characterised in that said resource reservation protocol is adapted to permit users to specify a preference for a multiplicity of levels of QoS and in that said resource reservation protocol is adapted to reserve a plurality of resource types.

17. A subscriber terminal, as claimed in claim 16, characterised in that a user*s preference with regard to QoS is recorded by elements of a Price Vector, each element of which corresponds to a notional • price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

18. A subscriber terminal, as claimed in either claim 16, or 17, characterised in that a set of possible resource values for each resource type are recorded by the elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types.

19. A subscriber terminal, as claimed in claim 18, characterised in that there is provided merge means for merging said Price Vector with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference.

20. A subscriber terminal, as claimed in claim 19, characterised in that said Downgrade Vector is transmitted to said transmission network by resource reservation messages.

21. A subscriber terminal, as claimed in claim 20, characterised in that said Downgrade Vector is calculated from a Price Vector and a Resource Vector retrieved from configuration files stored in said subscriber terminal.

22. A subscriber terminal, as claimed in claim 20, characterised in that said

Downgrade Vector is calculated from a Price Vector and Resource Vector retrieved by said subscriber terminal from a policy server.

23. A subscriber terminal, as claimed in claim 20, characterised in that said Downgrade Vector is calculated from a Price Vector, derived directly from requests addressed to a user of said subscriber terminal, and a Resource Vector retrieved by said subscriber terminal.

24. A subscriber terminal, as claimed in any of claims 16 to 23, characterised in that a Downgrade Vector is carried in a RSVP/RESV reservation message.

25. A method of reserving resources in a telecommunications data transmission system comprising a transmission network having a plurality of nodes, a plurality of access nodes and a plurality of subscriber terminals connected to access nodes, said telecommunications data transmission system being adapted to support provision of multimedia telecommunications services and employing a resource reservation protocol, characterised by said resource reservation protocol being adapted to permit users to specify a preference for a multiplicity of levels of QoS and by said resource reservation protocol being adapted to reserve a plurality of resource types.

26. A method, as claimed in claim 25, characterised by recording a user»s preference with regard to QoS as elements of a Price Vector, each element of which corresponds to a notional • price* that a user is prepared to pay for a given level of said multiplicity of levels of QoS.

27. A method, as claimed in claim 26, characterised by determining default values for each element of said Price Vector from user trials.

28. A method, as claimed in any of claims 25 to 27, characterised by recording a set of possible resource values for each resource type as elements of a Resource Vector, each element of which corresponds to an available resource level for a given one of said plurality of resource types.

29. A method, as claimed in claim 28, characterised by merging said Price Vector with said Resource Vector to produce a Downgrade Vector specifying resource levels supported by a given application which a user is prepared to accept in a descending order of user preference.

30. A method, as claimed in claim 29, characterised by propagating said Downgrade Vector between nodes in said transmission network in resource reservation messages.

31. A method, as claimed in claim 30, characterised by each of said plurality of subscriber terminals calculating a Downgrade Vector for each application running thereon, and by said subscriber terminal transmitting said Downgrade Vectors to the transmission network.

32. A method, as claimed in claim 31 , characterised in that said Downgrade

Vectors are calculated from Price Vectors and Resource Vectors retrieved from configuration files stored in said subscriber terminals.

33. A method, as claimed in claim 31 , characterised by calculating said Downgrade Vectors from Price Vectors and Resource Vectors retrieved from a policy server.

34. A method, as claimed in claim 31 , characterised by calculating said Downgrade Vectors from Price Vectors, derived directly from requests addressed to a user of said subscriber terminal, and Resource Vectors retrieved by said subscriber terminal.

35. A method, as claimed in claim 30, characterised by said access nodes calculating a Downgrade Vector from a Price Vector stored in a user database and a Resource Vector.

36. A method, as claimed in claim 30, characterised by pre-calculating Downgrade Vectors for each application and user, or groups thereof, and storing said Downgrade Vectors in a policy server from where they can be retrieved by a subscriber terminal, or access node.

37. A method, as claimed in any of claims 25 to 36, characterised by building a Downgrade Vector into a resource reservation protocol adapted to handle specific resource demands.

38. A method, as claimed in any of claims 25 to 37, characterised by carrying a Downgrade Vector in a RSVP/RESV reservation message.