A QoS Management Architecture for Packet ... - Semantic Scholar

A QoS Management Architecture for Packet Switched 3rd Generation Mobile Systems $

$

+

+

+

O. Lataoui , T. Rachidi , L. G. Samuel , S. Gruhl , and Ran Hong Yan + Bell Laboratories, Lucent Technologies $ Al Akhawayn University in Ifrane, Morocco

Abstract The third generation of mobile systems will provide different data services (Real Time, and Non Real Time) to end-users. In this context, the use of packet switched services is inevitable because system resources are particularly scarce over a radio interface, and the need for Quality of Service (QoS) Management is undeniable in order to meet end users’ expectations. In this paper, we will define the different components making up a QoS Management Structure that is responsible for providing and maintaining QoS requirements for various types of connections in a packet switched mobile environment, while taking into consideration the inherent characteristics of wireless systems. We will describe the functional specifications of a non-reservation based Connection Admission Controller, a Policer, and a Radio Block Scheduler, and state the contribution of each in maintaining specific QoS requirements. We will also motivate the need for introducing two new QoS parameters, namely, the “Seamless Service Descriptor” and the “Service Degradation Descriptor.” These are used to improve the efficiency of Admission Control and to optimize adoption to the QoS requirements. Keywords: QoS management, Wireless Systems, Connection Admission Control (CAC), Policer, Radio Block Scheduler, Seamless Service Descriptor and Service Degradation Descriptor. I. Introduction The third generation of mobile systems will provide different services to end users, extending the scope of second generation mobile systems (e.g., GSM, PHS, IS-95, etc.) from simple voice telephony to complex data applications including 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 are desirable for the radio interface [1] in the sense that they use the system capacity more efficiently, allow for user idle time, and adopt a volume charging policy. Because of the scarcity of system resources over a radio interface, it is desired to take advantage of the statistical multiplexing gain of packet switched services while providing a QoS level comparable to that of circuit switched services, especially for RT data applications. We first categorize the different classes of service that are to be provided by third generation mobile systems. Broadly speaking, we can 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.) In this context, the 3GPP defined four distinct traffic classes [13], for Universal Mobile Telecommunication Systems (UMTS): • Real Time classes (Conversational and Streaming) • Non Real Time classes (Interactive and Background) Table 1 describes each one of these classes along with their characteristics: Each traffic class is characterized by a set of QoS requirements that need 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.

1

Class Number 1

Traffic Class Conversational

2

Streaming

3

Interactive

4

Background

Class Description

Example

Preserves time relation between entities making up the stream Conversational pattern based on human perception Real-time Preserves time relation between entities making up the stream Real-time Bounded response time Preserves the payload content

-

Voice over IP Video conferencing

-

Relevant QoS Requirements Low jitter Low delay

-

Real-time video

-

Low jitter

-

Web browsing Database retrieval

-

-

Email File transfer

Round trip delay time Low BER Low BER

Preserves the payload content

Table 1: The Four UMTS Traffic Classes Defined by 3GPP[13]

Fixed Network Subsystem

BS MS Wireless Network Subsystem

Figure 1: The General Structure of a Mobile System However, in this paper we will focus only on the wireless part of the mobile environment since it constitutes the system bottleneck in terms of link capacity, and we will view the fixed network part as a single logical entry point. rd

In UMTS terms, the 3 Generation Partnership Project (3GPP), presented in [13], a functional decomposition of the end-to-end concept in a QoS architecture. In fact, QoS is viewed as a series of “chained” services operating at different levels of a mobile environment (see figure 2.) The scope of this paper, in UMTS terminology, is restricted to the “Radio Bearer Service” (the interested reader is referred to [13] for more details concerning the different levels of QoS in UMTS.) In addition to this, we will restrict the different traffic classes for a wireless mobile system to the four classes described earlier. UMTS TE

MT

EDGE NODE

UTRAN

CN Gatew ay

TE

End-to-End Service Local Bearer

External Bearer Service

UMTS Bearer Radio Radio Service Bearer UTRA FDD/TDD Service

Bearer Iu Bearer Service

CN Bearer Service Backbone Bearer Service

Phy. Bearer Service

Figure 2: UMTS QoS Architecture [13] II. Existing Work Extensive research has been undertaken in the area of QoS management for fixed networks, in particular those based on ATM. As a matter of fact, a set of QoS parameters are defined for various multimedia applications [4], and different traffic classes are established in the ATM model, each corresponding to specific QoS requirements [5]. The problem of maintaining QoS for a given connection in an ATM network is also addressed, by defining different functions for traffic management (i.e., Connection Admission Control, Usage Parameter Control,

2

Resource Management, etc.) The reader is referred to [6] for a complete specification and description of all the functions of traffic management in ATM networks. QoS specification is also addressed in [7] where a QoS Architecture is defined to provide integrated flow management at the transport layer. In addition to this, many scheduling/queuing algorithms are proposed in order to guarantee some QoS requirements. [8] presents a queuing service for jitter reduction in ATM networks, and [9] proposes a fair scheduling algorithm for QoS guarantees in packet switched networks. On the other hand, there has been relatively little work done on QoS management for wireless mobile environments. Most of the existing work in this area has been limited to hand-off for circuit switched services. [3] identifies two new QoS parameters for mobile systems and proposes a “conceptual” architecture to overcome the problems of both link degradation and handoffs. In [10] different wireless-specific QoS parameters are identified, and an “abstract” QoS management structure is proposed. In [11] a Connection Admission Control Algorithm, based on inter-cell resource reservation and a mathematical model, is proposed for third generation mobile systems, and guarantees two QoS parameters: delay jitter and delay constraints. In this paper, we will address the problem of QoS management in packet switched mobile networks as a whole, by defining all the components that intervene in guarantying and maintaining QoS for the wireless part of a mobile environment. We will also define the functional specifications of the following modules: Connection Admission Controller, Policer, and Scheduler, and we will show the contribution of each module in enforcing specific QoS requirements. Most of the QoS terms that we will define in this paper are based on the ATM traffic management specifications [6], while taking into account considerations introduced by the intrinsic properties of wireless systems, specifically the mobility of users and the unpredictable state of the radio link. We will detail one wirelessspecific QoS parameters described in [3], namely the loss profile, and introduce two new QoS parameters: the Seamless Service Descriptor and the Service Degradation Descriptor. In addition to this, unlike QoS for ATM, the proposed QoS Management Structure provides adaptive QoS maintenance throughout the lifetime of a connection. That is, in case of a resource shortage, QoS parameters are dynamically degraded according to a specified loss profile, without having to go through a new connection setup procedure.

III. The QoS Management Structure We will start with an introduction of our proposed QoS attributes and from there draw a sketch of our architecture. This is followed by a detailed description of the components. In the proposed QoS Management Structure, each application needs to issue a Connection Request (CR) before using the wireless link, in both the Uplink and the Downlink, regardless of the transport scheme being used (TCP, UDP, etc.) The Connection Request contains the necessary information that will be used by the different components of the QoS Management Structure in order to accept/reject the connection, maintain the QoS requirements in case the connection is accepted, and monitor/police the traffic characteristics of an active connection. Inline with most QoS approaches we deploy the CR to allow applications to do their QoS requirement notification. For this framework we foresee the following QoS parameters, which are specified on a per1 2 application basis : A. Traffic Class The traffic class number 1, 2, 3, or 4 corresponds to the conversational, streaming, interactive, and background classes respectively. This top-level classification can support many QoS decisions without the need to closely examine the set of QoS attributes. For example conversational traffic could get no backward error correction assigned exclusively based on its traffic class characterization. B. Classic QoS attributes: 1. The traffic characteristics specified in terms of bandwidth: • The peak rate (bit/sec), • The minimum acceptable rate (bit/sec), 1

If the application opens many flows (e.g., data and control signaling), then a Connection Request is to be specified for each flow. 2 Some fields in the Connection Request may be void depending on the traffic class. For example, the jitter requirement for non real time classes will not be specified in the Connection Request.

3

• •

2.

3.

The average rate (bit/sec), The maximum burst size (the maximum number of consecutive bits sent at the peak rate.) The reliability requirements of the connection. These include: • The Bit Error Rate (BER) or Frame Error Rate [FER], • The maximum loss ratio (the proportion of received packets to undelivered packets), The delay requirements including: • The maximum tolerated delay (ms), • The maximum tolerated jitter (ms) (the variation in delay),

C. Advanced QoS attributes for our wireless context: The loss profile [3] specifies the way how data should be degraded gracefully in case of resource deterioration. This explicitly addresses the wireless intrinsic problem of potential quality drops in the radio link. It provides application preferences towards potential recovery methods. As an example for a Real Time connection we consider that the radio link capacity is reduced. Should payload be preserved at the expense of jitter requirements? In other words, the loss profile shows what/how QoS can be “sacrificed” in case of link degradation. Figure 3 shows a loss profile for a connection, which specifies, in case of a resource insufficiency, the QoS requirements to be degraded with the scheme:

Jitter

10

20

BER

10-5

10-3

Figure 3: A sample loss profile This means that for this connection, the jitter requirement is to be degraded first, from 10 ms to 20ms, then, if -3 resources are still limited, the BER can be increased to 10 . The Seamless Service Descriptor (SSD) describes the type of seamless service the user is requesting. For the sake of simplicity we choose an integer granularity for this value between 0 and 5 throughout this paper. An SSD value of 0 means the worst seamless service, whereas an SSD value of 5 means the best seamless service. We will describe how this QoS parameter is used in a later section. The Service Degradation Descriptor (SDD) describes how much the user is willing to get a degraded service according to his/her loss profile. As above we apply the same sample granularity from 0..5 and we will describe the SDD in detail later. The Policer Flag indicates the user's preference how the system should deal with packet's that arrive in an unspecified manner. This is typically associated with bandwidth excess.

CRi

CAC

Accept Create a Flow Queue

Reject

Variable Size Leaky Bucket i

Variable Size Leaky Bucket j

Flow j

CRi

CRj

ARQ

ARQ

Policer Retransmission

RRM

…

RLC Block

Scheduler

PHYSICAL LAYER

Transport Frame (TF)

Figure 4: QoS Management Structure Components (shown in gray)

4

Once a connection request is issued (see figure 4), it is examined by the Connection Admission Controller (CAC) which decides on either accepting or rejecting the CR depending on the available resources, the required QoS, and the status of existing connections in the serving cell. Upon admission, a network layer, variable size flow queue is created for the requesting application, which is then monitored by a policer. The RLC-protocol gets initialized. For example flows with BEC find their ARQ set up, which will be used for retransmission of lost or erroneous radio blocks (note that the ARQ process for Real Time traffic classes will, in general, be void.) Finally, the scheduler serves each flow queue depending on its QoS requirements. Figure 4 shows the general functioning of our proposed QoS Management Structure. The components illustrated in figure 4 are viewed as logical entities. That is, the figure does not show the location (MS, BS, or both) of a given module. Details of each component will be discussed later. We now define each component of the QoS Management Structure separately: 1) Connection Admission Controller (CAC) From 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. The 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, then it 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. Besides 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 that we are proposing is not based on inter-cell resource reservation to guarantee a seamless service. Rather it uses the two new QoS parameters that we have 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 5 shows an example of a Connection Status Table: connection i j k

SDD 4 0 3

SSD 3 5 3

BW X Y Z

Figure 5: A sample Connection Status Table The proposed CAC module is made out of two distinct subparts (see figure 6): a Connection Impact Evaluator (CIE) and a Boolean Decision Maker (BDM). Connection Status Tables

CR CIE

System Resources from RRM

Probability values (impact on all existing connections) : PB, Pd, Pb, Pl, and Pj,.

Accept/Reject

BDM

Link Congestion metrics N1,, N2, and N3

Figure 6: The general structure of the proposed CAC module

5

The CIE: takes as input the following parameters: • The actual Connection Request, • The available system resources (bandwidth and memory), of both the current cell and the neighboring cells, form the RRM, • The Connection Status Tables, of both the current cell and the neighboring cells. Obviously, a protocol for exchanging information on existing connections between neighbor BSs at regular intervals needs to be specified. The 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. We divide those probabilities into two categories: • The probability values of blocking n other active connections PB(n) in the current and neighboring cells. For example, a PB(1) = 0.3 means that there is a probability of 0.3 of blocking one active connection. • The probability of degrading the QoS of n other active connections in neighboring cells: • Probability of exceeding the delay requirement Pd(n) • Probability of exceeding the jitter requirement Pj(n) • Probability of exceeding the BER requirement Pb(n) • Probability of exceeding the loss requirement Pl(n) The BDM 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 N1, the number of QoS degradation due to congestion N2, and the length of queues and buffers at the edge of the network N3.) 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.

Connection Request (Handoff or new call) Link Congestion metrics N1,, N2, and N3

BDM Are system resources available ?

Yes (connect)

No Check SDD

Degrading other connections to accept CR ?

Connection Status Tables

QoS degradation probability values

Yes (connect)

No Check CR’s loss profile

CIE Connection Blocking probability values

Serve this CR according to its loss profile ?

Yes (connect)

No Check SSD

Blocking other connections to accept CR ?

No

Yes (connect)

Reject and inform the application of what the network is able to accept

Figure 7: Detailed structure of the proposed CAC module

6

When a CR is received (see figure 7), available system resources are compared to the requested resources. If the requested resources are available, the CR is accepted and a new entry is added in the Connection Status Table. Otherwise, the existing connections are ranked according to their SDD values and compared with the SDD value of the incoming CR. Doing so, allows the BDM to determine if some existing connections can be degraded according to their loss profile in favor of the incoming CR. If not, the BDM checks the loss profile of the incoming CR itself and determines if the connection can be accepted with a degraded service. If not, the existing connections are then ranked according to their SSD values, and the BDM determines if other connections can be blocked (connections with SSD value smaller than the CR’s SSD) in favor of the incoming CR. If this is not the case, the CR is finally rejected and the CAC informs the requesting application of what the network is able to accept. It is important to note, however, that the decision of the BDM is also determined by both the probability values from the CIE, and the congestion metrics. For example, a CR can be rejected (even if system resources are available) if the CIE outputs a high blocking probability value and the congestion metrics indicate an increasing 3 number of blocked connections. Upon admission, a new “flow queue” for the connection is created , and a connection identifier is assigned to all packets issued from that connection. 2) Policer In a network where different connections are competing for resources, a policing mechanism is necessary in order to prevent some sources from exceeding their traffic characteristics in an “illegal” way, i.e. exceeding their specifications. In our context, we propose a simple policer operating at the data link layer of the BS. Obviously its location can also be shifted e.g. to the gateway entry of the core network, but for the sake of simplicity we assume it to be part of our (limited) scope. 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. The 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 we speak of bit inter-arrival time to underline that this is a volume dependent view and not done on a per packet basis. It can easily be shown that the burstiness can be controlled by adjusting the size of the leaky bucket. We have already defined the burstiness as being the maximum number of consecutive bits sent at the peak rate. We now show how the size of the token-based leaky bucket can be set in order to enforce the agreed burstiness: Let B be the burstiness of the traffic, S the size of the leaky bucket, A the average rate, and P the peak rate. S represents the number of tokens that the leaky bucket can hold, and A the token arrival rate (that is, we set the token arrival rate to the traffic’s average rate.) If at t=0 the leaky bucket is full (i.e. it has S tokens in it), then the sender can send S consecutive bits at the peak rate P in

S seconds. During this time, P

s⋅

A tokens arrived P

A A bits in s ⋅ 2 seconds. Again, during this P P 2 A A2 time, s ⋅ 2 tokens arrived to the leaky bucket allowing the sender to send s ⋅ 2 consecutive bits at the peak P P

to the leaky bucket so that the sender can send consecutively

s⋅

rate P. Following the same reasoning, the burstiness can be expressed in the following terms:

A A2 An + S ⋅ 2 + ⋅ ⋅ ⋅ ⋅ ⋅ + S ⋅ n (where n goes to infinity) P P P 2 n æ A A A ö B = S ⋅ çç1 + + 2 + ⋅ ⋅ ⋅ ⋅ ⋅ + n ÷÷ P ø è P P B=S+S⋅

3

Other computing resources are also created for a newly admitted connection, but these are not relevant to QoS management.

7

So:

æ æ A ö n +1 ö ç1− ç ÷ ÷ ç ÷ P B = S ⋅ ç è ø ÷ , but A ç 1− ÷ ç ÷ P è ø

So:

æ ö ç 1 ÷ ÷ B = S ⋅ç ç1− A ÷ ç ÷ Pø è

æ Aö ç ÷ èPø

n +1

→ 0 since n → ∞ and 0