Improved quality of service control in a mobile telecommunications network

0001This invention relates to a method of improved quality of service control in a mobile telecommunications network, such as the Universal Mobile Telecommunications System (UMTS) or the Global Packet Radio Service (GPRS) Enhanced Data-rate GPRS Evolution (EDGE), and to apparatus for carrying out the method.

0002Enhanced second generation and third generation of mobile systems will provide different services to end users, extending the scope of second generation mobile systems from simple voice telephony to complex data applications, for example voice over IP, video conferencing over IP, web browsing, email, file transfer, etc. The use of circuit switched services for Real Time (RT) applications guarantees a high Quality of Service (QoS) but uses the system capacity in a consuming and wasteful manner. This is due to the fact that a dedicated link is maintained throughout the entire lifetime of a connection. On the other hand, packet switched services provide a flexible alternative for RT data traffic over a radio interface as set out by B. Jabbari, E.H. Dinan, W. Fuhrmann, in "Performance Analysis of a Multilink Packet Access for Next Generation Wireless Cellular Systems", PIMRC 1998, in the sense that they use the system capacity more efficiently, allow for user idle time, and adopt a volume charging policy. Moreover packet switching may be more appropriate in scarce resource environments such as that found at the radio interface in mobile communications. This is since additional system capacity may be realized over the air interface by taking advantage of the statistical multiplexing gain inherent in packet switched systems. However maintaining the QoS comparable to that of circuit switched system for RT services is an interesting challenge.

0003This invention addresses the problems centered on Admission Control of packet data flows with Quality of Service (QoS) requirements. Traditional packet transmission systems operate as queuing systems, where each packet is transmitted at any time. This results in a user perceived system behavior with a low Quality of Service, as the transport network does not maintain certain delay bounds on the data. Novel scheduling mechanisms overcome these limitations, by assigning guaranteed minimum bandwidth to individual flows. Provided that the offered data of one flow does not exceed this guaranteed rate within a given time interval, the user may assume no congestion related delay in such QoS scheduling systems. These assumptions only hold as long as the total offered load associated with QoS enriched flows is lower than the total output capacity of the shared link. Therefore it is necessary to have a system entity which controls the admission of new flows to the system. This entity is called Connection Admission Controller (CAC) and it decides on the admission of new flows. Traditional CAC Algorithms are not designed to handle flows in a highly dynamic environment as found in wireless transmission systems. The present invention specifically addresses these issues.

0004Broadly speaking, it is possible to divide the types of service of third generation mobiles into two main classes: Real Time services (e.g., voice, video conferencing, etc.), and Non Real Time services (e.g., database applications, web browsing, email, etc.). The UMTS QoS Technical Report, ITU-R (source: Nokia), January 1999 defined four distinct traffic classes , for Universal Mobile Telecommunication Systems (UMTS): • Real Time classes (Conversational and Streaming) • Non Real Time classes (Interactive and Background) <tables id="tabl0001" num="0001"><table frame="all"><title> Table 1</title><tgroup cols="5" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="31.50mm" /><colspec colnum="2" colname="col2" colwidth="31.50mm" /><colspec colnum="3" colname="col3" colwidth="31.50mm" /><colspec colnum="4" colname="col4" colwidth="31.50mm" /><colspec colnum="5" colname="col5" colwidth="31.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col5" align="left">describes each one of these classes along with their characteristics:</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b>Class</b> No</entry><entry namest="col2" nameend="col2" align="left"><b>Traffic Class</b></entry><entry namest="col3" nameend="col3" align="left"><b>Class Description</b></entry><entry namest="col4" nameend="col4" align="left"><b>Example</b></entry><entry namest="col5" nameend="col5" align="left"><b>Relevant QoS Requirements</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>1</b></entry><entry namest="col2" nameend="col2" align="left">Conversational</entry><entry namest="col3" nameend="col3" morerows="1" align="left">• Preserves time relation between entities making up the stream</entry><entry namest="col4" nameend="col4" align="left">-Voice over IP</entry><entry namest="col5" nameend="col5" align="left">- Low jitter</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col4" nameend="col4" morerows="1" align="left">- Video conferencing</entry><entry namest="col5" nameend="col5" align="left">- Low delay</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">• Conversational pattern based on human perception</entry><entry namest="col5" nameend="col5" /></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">• Real-time</entry><entry namest="col4" nameend="col4" /><entry namest="col5" nameend="col5" /></row><row><entry namest="col1" nameend="col1" align="left">2</entry><entry namest="col2" nameend="col2" align="left">Streaming</entry><entry namest="col3" nameend="col3" align="left">• Preserves time relation between entities making up the stream</entry><entry namest="col4" nameend="col4" align="left">-Real-time video</entry><entry namest="col5" nameend="col5" align="left">- Low jitter</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">• Real-time</entry><entry namest="col4" nameend="col4" /><entry namest="col5" nameend="col5" /></row><row><entry namest="col1" nameend="col1" align="left">3</entry><entry namest="col2" nameend="col2" align="left">Interactive</entry><entry namest="col3" nameend="col3" align="left">• Bounded response time</entry><entry namest="col4" nameend="col4" align="left">- Web browsing</entry><entry namest="col5" nameend="col5" morerows="1" align="left">- Round trip delay time</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">• Preserves the payload content</entry><entry namest="col4" nameend="col4" morerows="1" rowsep="1" align="left">- Database retrieval</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /><entry namest="col5" nameend="col5" align="left">- Low BER</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>4</b></entry><entry namest="col2" nameend="col2" align="left">Background</entry><entry namest="col3" nameend="col3" align="left">• Preserves the payload content</entry><entry namest="col4" nameend="col4" align="left">- Email</entry><entry namest="col5" nameend="col5" align="left">- Low BER</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /><entry namest="col4" nameend="col4" align="left">- File transfer</entry><entry namest="col5" nameend="col5" /></row></tbody></tgroup></table></tables>

0005The traffic classes have QoS attributes associated with them and these attributes include the following facets: <ul id="ul0001" list-style="none" compact="compact"><li>1. The traffic characteristics specified in terms of bandwidth: <ul id="ul0002" list-style="bullet" compact="compact"><li>The peak rate (bit/sec),</li><li>The minimum acceptable rate (bit/sec),</li><li>The average rate (bit/sec),</li><li>The maximum burst size (the maximum number of consecutive bits sent at the peak rate.)</li></ul></li><li>2. The reliability requirements of the connection. These include: <ul id="ul0003" list-style="bullet" compact="compact"><li>The Bit Error Rate (BER) or Frame Error Rate [FER],</li><li>The maximum loss ratio (the proportion of received packets to undelivered packets),</li></ul></li><li>3. The delay requirements including: <ul id="ul0004" list-style="bullet" compact="compact"><li>The maximum tolerated delay (ms),</li><li>The maximum tolerated jitter (ms) (the variation in delay).</li></ul></li></ul>

0006This top-level of traffic class classification can support many QoS decisions without the need to examine closely the set of QoS attributes. For example conversational traffic could get no backward error correction assigned exclusively based on its traffic class characterization.

0007Each traffic class is characterized by a set of QoS requirements that needs to be satisfied in an end-to-end mode. That is, both the wireless and the fixed subsystems that make up a mobile environment (see figure 1) need to implement structures responsible for providing and maintaining the required QoS.

0008Many QoS requirements such as guaranteed bandwidth can be achieved for individual data flows by appropriate scheduling strategies. These systems make one major assumption, which is: <i>"The total offered traffic load to the scheduling system is lower than the output capacity."</i> Thus the amount of accepted load in the system has to be controlled and is critical for the successful implementation of QoS scheduling. For wireless systems there are two special problems. Mobility of users among different radio cells results in dynamic load patterns in individual cells, and changing radio propagation conditions result in varying capacity for individual links. Thus the amount of offered load (of already accepted calls) and the output capacity vary. Besides these technical problems there is usually the economic desire to achieve high network utilization. A conservative CAC will possibly reject more load than what might have been acceptable.

0009It is an object of the invention to provide a method and apparatus which permits more efficient use of bandwidth, improvement of end to end service quality, and improvement of load balancing in the network.

0010According to the invention, in a wireless mobile telecommunications network, a method of call acceptance in a telecommunications cell characterized by providing for a requesting call a quality of service descriptor specific to that call, and accepting that call only when the required quality of service can be provided and the required quality of service of existing calls will not be unacceptably affected.

0011Also according to the invention, a wireless mobile telecommunications network comprising a core network, a plurality of base stations, and a plurality of mobile terminals, there also being a connection admission controller, a policing unit and a scheduler, characterized in that there is also provided means to provide at least one quality of service descriptor specific to a requesting call, and in that the connection admission controller is arranged to accept the requesting call only when the quality of service in the descriptor can be provided and the quality of service descriptors specific to existing calls will not be unacceptably affected.

0012The invention will now be described by way of example only with reference to the accompanying drawings in which:- <ul id="ul0005" list-style="none" compact="compact"><li>Figure 1 illustrates schematically a UMTS network;</li><li>Figure 2 illustrates Quality of Service architecture in the UMTS system;</li><li>Figure 3 illustrates a Seamless Service Descriptor and Service Degradation Descriptor values;</li><li>Figure 4 illustrates a sample loss profile;</li><li>Figure 5 illustrates Quality of Service management structure components in the arrangement of the invention;</li><li>Figure 6 illustrates a sample connection status table;</li><li>Figure 7 illustrates the general structure of a connection admission controller</li><li>Figure 8 illustrates the decisions made in a connection admission controller according to the invention;</li><li>Figure 9 illustrates the interaction of a scheduler with standard Quality of Service management components, in addition to the inventive arrangement;</li><li>Figure 10 illustrates the time intervals between RLCs and packets of the same connection.</li></ul>

0013In Figure 1, a mobile telecommunications network 10, specifically the UMTS, comprises a Mobile Terminal (MT) 12 which communicates over an air interface 13 with a Base Station (BS) 14 which has a fixed connection 16 to a fixed network subsystem 18, which may be either an IP (Internet Protocol) network or the PSTN (Public Switched Telephone Network).

0014The QoS (Quality of Service) architecture can be represented as in Figure 2, as a functional decomposition; QoS can be treated as a series of "chained services" operating at different levels; such an approach is suggested in Technical Specification Group Services and System Aspects, QoS Concept version 1.1.0, 3GPP, 1999.

0015In UMTS, Terminal Equipment (TE) 20 can be connected to an MT 12; the BS 14 forms part of a UTRAN (Universal Terrestrial Radio Access Network) 22 which is connected through an Edge node 24 and Core Network (CN) Gateway 26 to a further TE 28.

0016The end to end QoS service 30 can be regarded as made up, at a first level, of a Local Bearer Service 32, between the TE 20 and MT 12; UMTS Bearer Services 34 between MT 12 and CN Gateway 26; and External Bearer Service 36 between CN Gateway 26 and TE 28.

0017At a second level, the UMTS Bearer Services 34 are made up of Radio Bearer Services 40 between the MT 12 and the Edge Node 24, and a CN Bearer Service 42 between the Edge Node 24 and the CN Gateway 26. At a third level the Radio Bearer Service 40 is made up of a Radio Service Bearer 50 between MT 12 and UTRAN 22, and Iu Bearer Services 52 between UTRAN 22 and Edge Node 24. At this level, the CN Bearer Service 42 is a Backbone Bearer Service 54.

0018At a fourth level there is a UTRA (U... T... R... A...) FDD/TDD (F... D... T.../T... D... D...) Service 60 between MT 12 and UTRAN 22, and a Physical Bearer Service QoS 62 between the UTRAN 22 and Edge Node 24.

0019In this specification, most of the QoS terms used are based on Traffic Management Specification, Version 4.0, The ATM Forum, Technical Committee, aftm-0056.000, April 1996; in addition the term "loss profile", a wireless-specific QoS parameter, is described by S Singh, "Quality of Service Guarantees in Mobile Computing, Computer Communications", Vol 19, pp 359-371, 1996. However, in contrast to QoS for ATM (Asynchronous Transfer Mode) systems, in the arrangement according to the invention, QoS maintenance is not only adaptive, but it is maintained throughout the lifetime of a connection.

0020In the description of a specific embodiment of the invention which follows, the assumptions made are that:- <ul id="ul0006" list-style="none" compact="compact"><li>1. All QoS transmissions have to be embedded into a data flow. A data flow is a sequence of data packets from the same source to the same destination in the network, for which the user has certain QoS requirements. Each radio bearer is related to a single data flow. Because multiple radio bearers might be established for a single user, multiple data flows could exist simultaneously that are related to a single user, too. In the following all data flows are handled separately.</li><li>2. Each Connection Request (CR) contains QoS requirements. The QoS requirements contain three parts. The first part (A) is a top-level classification. If not explicitly given this classification can be derived from actual values from B, e.g. from the delay requirements. The quantification of such conversion table is out of scope for this proposal. Part B contains basic traffic specifications in means of bandwidth, delay and reliability. The third part (C) is wireless specific and deals with the question of how to deal with the flow in case of network congestion situations, mostly due to link degradation. It is assumed that each CR is specified with the parameters for B and C. If these are not explicitly notified in a CR, it is assumed that it is possible to assign appropriate values to the unspecified fields.</li><li>3. The variable link is assumed to be part in a multi-hop packet routing architecture and to be the only bottleneck, where potentially congestion situations may occur. This is justified by the assumption that a fixed link backbone network with the same bandwidth capacity compared to a wireless network is relatively cheaper to build. Therefore in our expected application field the network operator will make sure during the network planning that enough (cheap) backbone capacity is available to support the relatively expensive wireless network.</li><li>4. Because a rate conserving scheduling strategy is used in the scheduler, the scheduler guarantees the required data rates, as long as the scheduling system is not congested. This is the case as long as the total offered load is lower or equal than the available effective throughput within a given monitoring interval.</li></ul>

0021According to the present invention, two novel service descriptors are required, both of which permit the description by a user of a requested service in terms suited to the characteristics of a wireless interface.

0022The first descriptor is a Seamless Service Descriptor (SDD) by which a user specifies the level of service which the user requires during a handover from one telecommunications cell to another. For simplicity this may be exemplified by integer granularity on a scale of 1 to 5; an SSD value of 5 means the highest quality of seamless service, such as that required for video handover; for video a service of quality 4 may be tolerable but an SSD value of 3 or less would render a video service unwatchable.

0023For a voice service, an SSD value of 3 will probably be acceptable, because the human brain is capable of interpolation to smooth out errors of transmission.

0024For a service such as file transfer, when real time transfer is not essential, an SSD of 1 would be acceptable.

0025Figure 4 illustrates the three examples just given.

0026Naturally, a user will be required to pay more for the higher SSD levels.

0027A second descriptor, a Service Degradation Descriptor (SDD) allows a user requesting a new link also to specify the level of service degradation, and the type of degradation, which a user is prepared to permit. On the integer scale of 1 to 5 the descriptor defines the level by which the user will tolerate degradation; for example, the voice user may not be prepared to tolerate any loss, so SDD = 5, see Figure 4.

0028The SDD is based on a loss profile, such as that set out by S Singh," Quality of Service Guarantees in Mobile Computing, Computer Communications", Vol 19, pp 359-371, 1996.

0029Suppose there is resource deterioration, e.g. a decrease in the quality of the air interface so that radio link capacity is reduced. The question may be asked, should payload be preserved at the expense of jitter requirements?

0030Figure 4 shows a typical loss profile for a connection and specifies that, as a first step, jitter may be increased from ten milliseconds to twenty milliseconds, then as a second step in degradation, BER (Bit Error Rate) may be increased from 10^-5 to 10^-3.

0031Thus SDD specifies how, when a resource insufficiency occurs, the QoS requirements of that particular call may be degraded.

0032A fourth element which is specified is the Policer Flag by which the user indicates how the system may react if that user exceeds his allocated bandwidth; the concept of a Policer Flag is known in ATM systems.

0033The four elements Seamless Service Descriptor, Service Degradation Descriptor, Loss Profile and Policer Flag are all specified in a Connection Request (CR) which is issued for each application which is requesting a wireless link, in both the uplink and the downlink, and regardless of the transport scheme used, which may be TCP (Transport Control Protocol), UDP (User Data Protocol) etc.

0034On the basis of the Connection Request, the network makes a decision whether to accept or reject the request, depending on whether sufficient capacity is available to provide the service, and on whether supplying the requested service will affect current connections to an unacceptable degree, i.e. to go beyond the SSD and/or SDD descriptors of these current connections.

0035Also, when a service to be handed over is not robust, such as a video service, a request may be made for bandwidth within the target cell; the SSD functionality allows an incoming, high value SSD service to "borrow" bandwidth from a lower value SSD service already within the cell, so that quality can be maintained on handover.

0036The decision is made by a QoS management structure, the components of which are shown in Figure 5. The components are viewed as logical entities, that is, the location is not indicated. The structure may be located in the MT 12, in a BS 14, or in both.

0037The Connection Request CRi is supplied to a Connection Admission Controller (CAC) 70 which accepts or rejects the request, as set out above. For an accepted request, the CAC 70 generates a "create flow queue" message 72, and a queue 74 of variable size is set up in the network layer for each CRi. Each queue comprises a variable size leaky bucket VBi with variable flow rate Fi.

0038The output Oi of the bucket is monitored by the policer 76. Subsequently, as illustrated at 74', the RLC (Radio Link Control) protocol is initialized, as indicated at 78, and RLC blocks are passed to a scheduler 80 which also receives input from a Radio Resource Manager (RRM) 82. The scheduler 80 serves each flow queue depending on its QoS requirements, setting up Transport Frames (TF) 84.

0039Referring again to the queue 74, flows with BEC (B... E... C...) find that their ARQ (Automatic Repeat Requests) is set up and this is used for retransmission of lost or erroneous blocks. (The ARQ process for real time traffic classes will, in general, be void).

0040The components comprising the QoS management structure are the CAC 70, the policer 76 and the scheduler 80.

0041Considering now the CAC 70, the basic principle of a CAC is to collect a certain number of Connection Requests (CRi) from flow i, i=1..n, where n constitutes the total number of already accepted and living flows. A flow is alive until the network or the user has terminated an established flow.

0042A CR contains a set of QoS requirements, which builds the basis for the CAC algorithm to decide how much system resources this flow will potentially require. The CAC decision upon acceptance is thus driven by the question, if system resources will be sufficient to satisfy all existing plus the newly considered flow. Conservative CAC algorithms will do so if the probability of this decision is 100% proof. To increase link utilization many approaches aim for a CAC behavior which achieves probabilistic guarantees, such as guarantees which hold for 55 minutes during an operating hour. These schemes are also referred to as over-reservation schemes. Given that the inventive usage of the parameter Loss Profile and the novel parameter SDD are probabilistic metrics, it is assumed that over-reservation is used and/or temporarily accepted during operation.

0043From a service provider point of view, the main goal of the CAC module is to admit a maximum number of CRs, and, at the same time, maintain the QoS requirements of existing connections. That is, the CAC module should avoid congestion in advance. In addition to this, independent from its actual implementation, the final output of the CAC module must be a Boolean value indicating whether the CR should be admitted or not.

0044The CAC module receives a Connection Request (CR) from an application, network measures (multipath, path loss, and interference) from the Radio Resource Manager (RRM), and the traffic characteristics along with the QoS requirements of all existing connections from the serving Base Station. It then decides, based on the previous information, whether the CR can be accepted or not. The CR can be originated either from a new call or from a handoff. The CAC module should prioritize handoff CRs over new call CRs because, in general, interrupting a service in an active connection is more annoying to users than rejecting a new call.

0045Besides local capacity estimates, CAC for wireless traditionally focuses on resource reservation for hand-off calls, which can lead to both extensive signaling overhead between base stations and low link utilization due to pessimistic admission strategies. The Connection Admission Controller of the invention is not based on intercell resource reservation to guarantee a seamless service. Rather it uses the two new QoS parameters that are introduced (the SDD and the SSD) to either accept or reject an incoming request. In this model, each BS needs to maintain a table (a Connection Status Table) containing the connection identifier, SDD, SSD, and the total virtual bandwidth used by each connections within the current cell. Figure 6 shows an example of a Connection Status Table.

0046The general structure of the CAC 70 is shown in Figure 7. It has two main parts, a Connection Impact Evaluator (CIE) 86 and a Boolean Decision Maker (BDM) 88.

0047The CIE: takes as input the following parameters: <ul id="ul0007" list-style="bullet" compact="compact"><li>The actual Connection Request,</li><li>The available system resources (bandwidth and memory), of both the current cell and the neighboring cells, form the RRM,</li><li>The Connection Status Tables, of both the current cell and the neighboring cells.</li></ul>

0048Obviously, a protocol for exchanging information on existing connections between neighbor BSs at regular intervals needs to be specified.

0049The CIE then outputs a set of probabilistic values predicting the impact of admitting the requesting connection on all existing active connections in the current and neighboring cells. Those probabilities are divided into two categories: <ul id="ul0008" list-style="bullet" compact="compact"><li>The probability values of <i>blocking n</i> other active connections P_B(<i>n</i>) in the current and neighboring cells. For example, a P_B(1) = 0.3 means that there is a probability of 0.3 of blocking one active connection.</li><li>The probability of <i>degrading</i> the QoS <i>of n</i> other active connections in neighboring cells: <ul id="ul0009" list-style="bullet" compact="compact"><li>Probability of exceeding the delay requirement P_d(<i>n</i>)</li><li>Probability of exceeding the jitter requirement P_j(<i>n</i>)</li><li>Probability of exceeding the BER requirement P_b(<i>n</i>)</li><li>Probability of exceeding the loss requirement P_l(<i>n</i>)</li></ul></li></ul>

0050The <i>BDM</i> is the module that decides whether or not the CR is to be accepted. It is regulated by the probabilities issued from the CIE and a set of congestion metrics (the number of connection blocking N₁, the number of QoS degradation due to congestion N₂, and the length of queues and buffers at the edge of the network N₃.) One of the goals that the BDM needs to achieve is that its blocking and service degradation probabilities should be less than the natural blocking and degradation probabilities if no CAC is implemented.

0051Figure 8 shows in detail the decisions made by the CAC 70.

0052The input from the RM 82 and the other connections into the CIE 86 can be regarded as taking into account the Radio Bearer Services 40 and 50 in Figure 2, and the Link Congestion metric inputs can be regarded as taking into account the Iu Bearer Services 52, the Backbone Bearer Service 54 and the CN Bearer Service 42 in Figure 2. Thus the whole breadth of the UMTS Bearer Service 34 is covered and in effect the end-to-end service 30 can be improved.

0053On receipt of a call request CR, and with input from the RRM 82, in step 100 the decision is "are system resources available?". If yes, connect; if no, the SDD is checked in step 102; in step 104 the decision is made whether accepting the new CR would degrade other connections; if yes, ie if the existing connections are prepared to accept degradation to allow the new call, then connect. If no, in step 106 the loss profile of the CR is checked. In step 108, if this CR can be served according to its loss profile, connect; if not, the SSD is checked in step 110. In step 112, if it would block other connections to accept this CR, but the other connections can be stopped and restarted without ill effect, ie if we can "steal" bandwidth, then the CR is accepted; if not, the CR is rejected and the application is informed that the network is unable to accept the request.

0054On acceptance, a new flow queue is created and a connection identifier is assigned to all packets which are issued for that connection.

0055As an example, a CR can be rejected, even if system resources are available, if the CIE 86 outputs a high blocking probability value, and the congestion metrics indicate an increasing number of blocked connections.

0056Although a specific CAC entity has been described, a distributed version would beneficially spread the required computational power to several units, and lower the response time to a request.

0057Consider now the policer 76 in Figure 5. In a network where different connections are competing for resources, a policing mechanism is suited to monitor traffic sources, if they behave in compliance with their own specifications. Furthermore a policer can interact and alter the offered load in order to make it flow compliant. In the present approach both actions are foreseen, while it is left to the user to select the operation mode.

0058In this application, a simple policer operating at the data link layer of the BS is described. Obviously its location can also be shifted e.g. to the gateway entry of the core network. The policer monitors and enforces the traffic characteristics (peak rate, average rate, and burstiness) of a given flow queue based on a token-based leaky bucket algorithm.

0059The peak rate of a flow is controlled by simply comparing the bit inter-arrival time with the inverse of the peak rate specified when the Connection Request was issued. The bit inter-arrival time must be less than the inverse of the peak rate for a conforming traffic. The average rate is enforced by setting the leaky bucket's token arrival rate to the agreed upon average rate. Note that "bit inter-arrival time" underlines that this is a volume dependent view and not done on a per packet basis.

0060It can easily be shown that the burstiness can be controlled by adjusting the size of the leaky bucket. Burstiness is the maximum number of consecutive bits sent at the peak rate. The size of the token-based leaky bucket can be set in order to enforce the agreed burstiness: For a given traffic, the size of the leaky bucket should be set to:<maths id="math0001" num=""><img file="EP1154663A1_D0001.tif" /></maths>    provided that the Average Rate is strictly smaller than the Peak Rate. If the average rate is equal to the peak rate, then the burstiness is not defined. This makes sense since the definition of the burstiness is the maximum number of consecutive bits that can be sent at the <i>Peak</i> rate.

0061Concerning the action to be taken by the policer with regard to connections not conforming to the agreed upon traffic characteristics, the policer examines the "Policer Flag" specified within the connection request. If the Policer Flag is ON, this means that the user is willing to pay extra charges (according to a billing policy defined by the service provider) for the transmission of non-conforming packets (provided enough system resources are available). If, however, the Policer Flag is OFF, then the policer discards all non-conforming packets.

0062On connection of a call, the network guarantees the user requirements as to delay, jitter and a bandwidth. The ease with which these requirements can be met depends on external conditions, primarily the air interface. The network may need to vary the proportion of data and protection if the interface deteriorates, i.e. it may need to vary the bandwidth. Similarly, deterioration of the air interface may cause a concertina effect, ie the proportion of raw data within a packet is decreased.

0063It is the scheduler 80 (see Figure 5) which takes these factors into account.

0064Considering first the arrangements in the prior art, for the application to UMTS a scheduler is responsible for the order of transmission of different RLC blocks within a transport frame. It is configured from Radio Resource Manager (RRM), located at the BS, with a set of Transport Format Combinations (TFC) which have been assigned during resource allocation to the flow. Each Transport Format (TF) is characterized by at least a coding scheme and its corresponding number of bits that can be transmitted. The scheduler chooses one TF that would optimize the link utilization and, at the same time, satisfy the QoS requirements of all flow queues belonging to different traffic classes.

0065Different scheduling schemes may apply, depending on the traffic direction. For wireless systems, as e.g. UMTS, there is one scheduling method on the dedicated shared channel, where the MS transmits in the uplink direction over the air interface whenever it has data to send. In GPRS the MS has to perform an access procedure and its UL data is actively scheduled and signalled to the MS from the central BS. In the downlink for all known system the BS synchronises all RLC blocks and sends data at regular intervals.

0066In the present invention, the scheduler is applied in a rate conserving manner to implement the QoS bandwidth requirements, that is, the scheduler monitors and grants access to the shared link to the individual data flows in proportion to their specified bandwidth requirements. The actual scheduling scheme is not relevant.

0067Figure 9 illustrates the interaction with standard QoS management components. The inventive arrangement with a variable queue 81, a CR 83 and an ARQ 85 interacts with the scheduler 80. The scheduler 80 also interacts with standard queues j and k each having a Connection Request CRj, CRk. The output of the scheduler is a stream of RLC blocks 84, which may be PDUs or ARQs.

0068For the scheduler to meet all existing flow queues (the performance requirements of the scheduler), the QoS requirements are: <ul id="ul0010" list-style="bullet" compact="compact"><li><i>RT Traffic Classes</i>: characterized by the following QoS requirements (relevant to the scheduler): <ul id="ul0011" list-style="bullet" compact="compact"><li>The maximum tolerable delay: <i>Dmax</i>, which is the maximum tolerable time it takes for a Network Layer Packet to be transmitted,</li><li>The maximum tolerable jitter: <i>Jmax,</i> which is the maximum tolerable variation in packet delay, and</li><li>The Packet Loss Ratio.</li></ul></li></ul>

0069Assumption 3 above focuses on delay issues for the particular scheduling system. It is assumed that there is no significant additional delay caused by the backbone network. Of course this influence may be estimated or signaled by some future QoS mechanism. If the influence of the backbone is available it will be subtracted from the flow requirements first and the new constraints will become tighter for our scheduler.

0070In Figure 10, let <i>t</i>_<i>inter</i> be the time interval between two consecutive RLC transmissions 84 belonging to the same packet, and let <i>T</i>_<i>inter</i> be the time interval between the last RLC of packet <i>i and</i> the first RLC of packet <i>i+1</i> for the same connection.

0071Also let <i>D</i>_<i>i</i> be the packet delay for a given packet <i>i</i>. So, <i>D</i>_<i>i</i><i> = T</i>_<i>inter</i> + <i>Σ</i>^<i>t</i>_<i>inter</i>. That is, in order to meet the delay requirement for a RT flow, the scheduler 80 must maintain the following inequality true: <i>T</i>_<i>inter</i><i> + Σ</i>^<i>t</i>_<i>inter</i><i> ≤Dmax</i>.

0072In addition to this, the scheduler 80 must also meet the jitter requirement for a RT flow. That is, <i>D</i>_<i>i+1</i><i> - D</i>_<i>i</i><i> ≤Jmax</i>. Note that <i>D</i>_<i>i+1</i><i> - Di</i> can be negative, assuming that a given packet can be buffered at the destination to maintain a small delay variation. Consequently, the scheduler needs to adjust the values of <i>t</i>_<i>inter</i> in order to meet both delay and jitter requirements.

0073The loss ratio specified in the flow queue specifies the fraction of packets that can be delayed over the maximum tolerable delay (considered lost.) <ul id="ul0012" list-style="bullet" compact="compact"><li><i>NRT Traffic Classes</i>. Characterized by the following QoS requirements (relevant to the scheduler): <ul id="ul0013" list-style="bullet" compact="compact"><li>Maximum tolerable delay: <i>Dmax</i> (class #3 only), and</li><li>Bit Error Rate: BER (classes #3 and #4)</li></ul></li></ul>

0074By adopting the previous terminology, the scheduler needs to maintain the following inequality true for traffic class #3 flows: <i>T</i>_<i>inter</i><i> + Σ</i>^<i>t</i>_<i>inter</i><i> ≤Dmax</i>.

0075In order to meet the BER requirement, the scheduler needs to choose a TF having a coding scheme that maintains the required BER. Note that lost packets for NRT classes are retransmitted using an ARQ process, making the PHY-link BER requirements an optimisation process, not covered here.

0076The scheduler 80 may find itself in congestion situations due to several reasons. The system may be overloaded by aggressive CAC strategies or unexpected Handoffs into the cell under consideration. Also the estimated transmission capacity might be overestimated. This can happen when links degrade in quality and more systems resources are required to achieve the former effective throughput.

0077Several stages of load balancing in case of a congestion situation are proposed: Firstly marked packets by the policer from flows with non-flow compliant behaviour are discarded. Then if the system resources are still limited, the scheduler initiates a RRM procedure to alter some flow requirements. The exact procedure is out of scope here. Basically it will base its decision on the loss profile of individual flows and find a flow that is suited to be degraded. This degraded parameters will then be notified back to the scheduler. This is repeated until the scheduler find itself in not congested anymore. When the situation is stable the former degraded flows are restored in a reverse manner. If possible this mechanism also informs (via a control plane) the corresponding application of the changes in QoS terms.

0078In the invention the inherent characteristics of the air interface of a mobile wireless packet switched transmission system are taken into account when considering the QoS for traffic flows across the air interface. This is since the SSD, SDD and LP together realistically reflect the achievable QoS for a wireless service. There are specifically two occasions where the achievable QoS temporarily alters. During normal operation with no handover scenarios the available capacity may change substantially due to altered radio conditions for individual links. This reduced link capacity may yield scheduling congestion situations. For handover/handoff scenarios there might be additional load, which cannot be easily rejected by Admission Control mechanisms, as it is generally not desired to cut of existing flows. These additional load may also cause congestion situations. In the case of Handoffs this amounts to an improvement on existing solutions because existing solutions reserve bandwidth in neighboring cells in order that handovers/handoff are smooth for RT services. This method while robust reduces the capacity of the system moreover in Third Generation (3G) systems there is the added complication of having ongoing variable bandwidth demands at the time of handover. Under this circumstance the overhead of reserving bandwidth to guarantee the QoS at handover becomes costly in terms of cell capacity. Therefore having a method which takes into account the demands of new connections in a highly flexible manner would be highly desirable since cell capacity would be used in a more effective manner. Moreover the invention can be applied in a general sense to packet switched services since the policing and scheduling elements take care of the traffic behavior either side of a handover/hand -off. Finally the invention allows for more aggressive over-reservation of system resources hence a higher network utilization, because it is possible to overcome potential congestion situations in such manner, that the affected services are degraded in such way that this is still acceptable for the users.

0079While the invention has been described with reference to the UMTS, it is applicable to any enhanced second generation or third generation mobile telecommunications system.