Qos support of collaborative virtual environments ...

1 downloads 0 Views 532KB Size Report
levels as a vector {QoS, ,QoS2 , ...,e OS,,,) whcrc .... X = E{X} = IIp andX2 = E{X2} = 2/p2, thcn we get: .... [5] Michael P. Wellman, William E. Walsh, Peter R.
QoS Support of Collaborative Virtual Environments Applications in Multiservice Wireless Networks through Pricing Ognian Kabranov, Abdulsalam Yassine, Dimitrios Makrakis Broadband Wireless and Internetworking Research Laboratory School of Information Technology and Engineering, University of Ottawa B308 Colonel By Hall, P.O.Box 450 Stn A, Ottawa, Ontario, Canada, K I N 4N5 Eniails: kubrc~noi~(ii~.sile. riottar~~tr. ca, a):~i.(..~ini~(~~norte/nc?ti~i~ork~. coni, diriiitri.(.~~;!,sitL’. iiottortu.cu

enabled CVEs. Not only the mobility is not supported conceptually, but the often numerous audio and video feeds overwhelm the dcviccs‘ limited resources [9]. This paper rcports on the scrvice differentiation in wireless nctworks using pricing policy bascd on “auctioning” [3,4]. The objective is to control the bchavior of a DIVE application, its intcraction with othcr traffic strcams to achicvc a satisfactory QoS pcrfonnancc. Wc inanage the QoS perforinance by introducing pricing principles for a resource allocation applied on wireless networks [4]. We assume that the wirelcss network is working in “ccntralized mode” i.e. there is a network controller managing the wircless resource.

Abstract In this paper we discuss the deployment of Distributed Interactive Virtuul Environnzent (DIVE) applications over wireless Internet. Our goal is to understand the behavior of a DIVE application, its interaction with conipeting tragic strearns (Video, Data, Voice, etc.), as well as its network resource requirements f o r a sutisjiucfory petforrnunce in te1~nisof Q~inlityof Service (QoS). We manage the QoS petforniance by introducing pricing principles for wireless channel resource allocation based on price “aiictioriing” or “bidding”. The network coiit1.oller udvertises the available QoS levels and the mobile users are competing for them by placing bid requests. Based on the variability of the wireless channel, the aniount of the available bandwidth shut-ed between the mobile iisers and the bid requests. the network controller exercises QoS niatiugenient. The QoS levels assigned to e i w y ciistonier are dynaniically chunged depending on the network controller optiniizution c ~ ~ i t o ~ i(in o i i this paper the iiehvork controller revenue). A queuing theory model ,for QoS levels deter.niiriution, based on bidding is presen~ed,showing the aIii1it.v ?f the pricing policy to psovide the desired QoS j b r sensitive applicutions such as DIVE in U conipetitive erivironnient.

2. Pricing Principles in Wireless Networks Let us considcr thc following architecture: the Network Controllcr advcrtiscs different levels of Quality of Service (QoS) and thc mobilc users arc conipcting for wircless channel rcsourccs by placing bid requests (sec Fig. 1, Fig. 2a,b,c ). Based on thc variability of the wircless channel, thc amount of the availablc bandwidth sharcd bctween thc mobilc L I S C ~ Sis decided by thc nctwork controllcr which cxerciscs thc QoS nianagenient based thc bid requests. The QoS managcmcnt is performed through dynamic change of thc QoS lcvel offered to cvery customer. Thc assigned QoS lcvcls arc dccided through an optimization (maximization of rcvcnuc) critcrion. In ordcr to givc more light on thc QoS nianagenient by pricing, wc will first list some of the basic cnd-user custoincr rcquireinents for a network service provider, as presented in [2], [3], [4] and [5],namely: - The value of thc packets sent by a custoincr has to be defined by the customer (by price bid) - Control over Service and Price Selection: the network scrvice provider can differentiate the services offered and allow their customers to choose the desired class of service and pricing. - Usage bascd pricing: it is a more appropriate means of allocating scarce resources between end-users who value the service more. If end-users are charged on a usage-based fee for network usage, only thc information that is of higher utility for the custoincr will be sent to the network.

1. Introduction Collaborative Virtual Environments (CVEs) [SI enablc inultiple users in different physical locations to share a single “virtual space” to communicate and collaborate as if thcy actually shared the same physical space. Such environments provide rich, interactive audio-visual contcnt to foster a feeling of presence between remote participants. Because of their conveniencc and costeffectiveness, CVEs are emerging as a dominant communication paradigm that finds applicability in numerous domains of strategic importance to such as remote teaching, telemedicine, public safety etc.[9]. One limitation of such virtual environments is that they are not mobile-friendly in the sense that “non-wired” mobile dcvices are difficult to integrate into broadband-

0-7803-7635-8/02/$17.00 02002 IEEE

31

- Very

consider: (1) wireless link quality (capacity) change, (2) Mobile Station joins/leaves the network. We can consider the QoS as set of different parameters {rate, packet loss, delay, jitter, etc.}, offered by the Base Station to the customers (see as example Table 1). The auctioning itself is assumed to be one-step process. That means: for a single auction, the mobile users send only once their bids and the wireless channel resource allocation decision is met by the Base Station only once for this round, immediately after the bids are received. Further it is assumed that the customers are acting in non-cooperative and selfish manner: the customers are not aware of the bids and requested bandwidth by the rest of the users. They are concerned about maximizing their own utility only.

important design aspect of the QoS network is the predictability of the prices offered. This is done best by giving the user direct access to the price/QoS selection a service offers at a price that varies only over long time scales. The channel variability happens in the time scale of milliseconds, and the user (in case he is interacting directly with the system) cannot react immediately. In such case the user bids price/QoS have to be recorded in userpreference tables. - Another important aspect is the frequency of price changes: it can be classified [2] as: network time scale (changing every second and faster), user time scale (changing hourly daily or weekly), and long-term time scale (changing only every month or year).

QoS level QoSl QoS2

, ,i'% \:

%*

Loss

Delay (ms) 5 10 25

0.00025 0.0005 0.001

QOS3

2.3 User QoS preferences As mentioned in Section 2, the preference tables express the bids for QoS levels and bandwidth. After bccoming aware of the advertised QoS Icvcls, the users respond with their preferences (see Fig 2a, b, c, d). Let us take into consideration the different mobile users:

Figure 1. The Wireless network model and the traffic streams (DIVE, VIDEO, Best Effort)

2.1 I m p l e m e n t a t i o n scenario As dcscribcd in Section I , a Network Controller manages thc nctwork. A ccntralizcd access protocol is natural for a configuration in which a numbcr of wirclcss stations interact with the Network Controllcr, known also as a Basc Station (see fig.]), attachcd to a (wired or wireless) backbone nctwork; it is cspccially useful in case that time scnsitivc or high-priority data has to be transmitted [l]. The price cliarzges occur in iietivork t i i m scule, thus the uscr bids are rccordcd in so called preference tables. Thc implementation scenario might look as follows: - The Base Station advertises the available QoS levels, which is seen as auction (bidding) initiation for both uplink and downlink. - After joining the wireless network, the mobile users send bids to the Base Station, containing the bids for the advertised QoS levels (See Section 2.2 and 2.3) - Based on the bids, the Base Station decides how to distribute the network resources and assign the advertised QoS levels among the mobile users.

1

Bandwidth ~

~~

.

-

-

~

Figure 2a. QoS preference table for Vidco users Fig 2a. rcprcscnts the preference table for Video users. In [9] thc traffic is an MPE2 trace. MPEG2 is defined for transmission rates in the range of lor 2 to 60 Mbps, however, for bit-rates higher than 8-10 Mbps the improvement in visual quality is very small. The end-toend delay requirement is dependent on the nature of the application. For video on demand, jitter is of concern, not end to end delay. For applications of interactive nature (i.e. tele-operation, teleconferencing etc.) quality is asymptotic and acceptable delay 200-250 ins. [l 11.

2.2 QoS levels advertisement a n d auctioning In the wirclcss network the Base Station determines the time for an auction. As auction initiating events we

32

is the lowest level. In that QoS, is the highest and Q ~ S M our work we assume that the QoS levels advertised by the network controller (See Sections 1; 2) are in the form of a 4w / l---I l vector of the maximuin acceptable delays for the different QoS levels{D,,D, ....,D,}. The mobile user i responds to the QoS advertisement with the following bid vector: Proferoncai

0andwidlh (hbps)

Figure 2b. Downlink QoS preference table DIVE users

where ;lik is the bandwidth the user i is willing to request at QoS level QoS k.and bik is the QoS level bid i.e. the price the customer i is willing to pay for the indicated amount of bandwidth, having QoS level QoS k.

for

Fig 2b shows the preference table for on the downlink for DIVE users. It is assumed to be dominated by a slow motion video. According to [ 131 the bandwidth requirements arc 200 Kbps to 1 MBps and the allowed maxiinuin cnd to end delay about 140-250 ins. -

r-

-~

3. Design Objective The dcsign objectivc is to cxcrcise QoS levels management for rcvenuc maximization of thc Network Controller (rcspcctivcly the service provider). In ordcr to clarify the objective Ict us takc as exaniplc the Network configuration from fig. 3. For every QoS level thcre is onc queue forcsccn and the queuing discipline deployed is a non-prccinptive priority queuing. Ultimately, wc would like to acconimodatc all traffic on queue 1 in order to achieve maximum revenue, as the highest QoS is paid the highest. But in reality wc cannot accommodate all traffic streams on one queue, since it is not possible to keep all thc delays within their respective QoS levels. As the wireless channel capacity (understood also as service rate) changcs, the distribution of traffic streams over the priority queues will change. The revenue from the reallocation of the traffic streams ovcr the priority queues will change as well. Our objective is to maximize the revenue of the Base Station by proper re-assignment of the QoS levels (priority qucucs) to thc uscr traffic streams. In casc that thc Network controller can kccp none of thc QoS levels for a uscr its rcquest is rcjected. As can be seen from Fig. 3, we allocate the uplink requests in the priority qucues, that incans the uplink is trcatcd in the same way as the downlink. Esan~ple: We consider a scenario with 4 traffic streams, DIVE uplink, DIVE downlink, Video and Best Effort traffic, and 3 QoS levels: QoSI, QoS 2, QoS 3 (see Table I , Fig. 3 to Fig. 7). As QoS parameter we chose only the delays, as they are crucial for DIVE applications. The DIVE uplink traffic is a measured CVE application traffic trace from a test-bed described in [ 9 ] . The average packet lcngth is 92 bytes (sec fig.4a). The low motion video is inodclcd as Poisson distributed traffic with average packet length 1500 bytes, the Video traffic is a measured MPEG2 traffic trace from the same test-bed and with average packet length 1500 bytes (see fig.5) and the Best Effort (BE) traffic is Poisson distributed traffic with average packet length 1000 bytes (see fig.5). From these traces we can see that DIVE is “thin” traffic (kBps), compared to Vidco (MBps), and BE (MBps). The wireless channel

~~~

Preferences

I

Bandwidth (kbps)

Figure 2c. Uplink QoS preference tablc for DIVE users The uplink DIVE bandwidth, rcqucstcd is bctwccn 5- I O kbps and the dclay allowcd for the collaborativc update messages is 100-200 ins. [ 121. However we assign strict delays as QoS ( 5 ins) (sce Fig 2c) as this rcfcrs thc jitter can have ncgativc effect on the tiansmission [ 121 ~~

Preferences

I

Bandwidth (hbps)

Figure 2d. QoS preference table for Best Effort users Finally for Best Effort traffic we assume that it accepts any delay for rates more than 10 kbps (see Fig 2d)..

2.4 Bid format The Network Controller advcrtiscs the available QoS levels as a vector {QoS, ,QoS2 , OS,,,) whcrc 1,2,...., A4 arc the available QoS levels. It is assumed

...,e

33

4. Non-Preemptive Priority Queuing Analysis

variability is modeled using a Markov Chain Model as described in [7], (see fig. 7). The business goal of the base station is to tnaxiinize thc rcvenue from the traffic in the wireless network. The question here is: is it worth of accommodating the DIVE uplink traffic (respectively traffic with high QoS requirements) on the highest priority queue, taking into consideration that the traffic is tiny and the revenue from it is vcry small compared to the Video traffic? Another question to be answered is: what should the DIVE traffic user pay in order to keep the highest QoS (in this case QoS,)?

The QoS levels are achieved by assignment of priorities to the packets based on bidding (in the form of preference tables). Thc scheduling is performed using non-preemptive priority queuing. First we will present the queuing discipline and then the bidding based priority assignment.

4.1. Queuing Discipline For non-preemptive M/G/1 priority queue the average waiting time is [6]: Wk =

,=I

2 '(1 - P I -."- Pk-1 )'(I -PI

1 TI =-+Wk

-"'-

pk

)

(21,

pk

where WLis avcragc waiting timc in the queue k, Th is the avcragc waiting timc per customcr, ,oL is the system utilization for priority k and p h is the avcrage service ratc for priority k. X,'is the second nioincnt of the service time for priority i. Taking into considcration that the service rate [ I is exponential distributed as wcll - here understood as wireless channel capacity, the average packet length is lk. For the exponentially distributed service time X the following the follwing is valid:

I

Figure 3. Traffic streams distribution and priority qtlcucs

X

4 I'

a n d X 2 = E { X 2 }= 2 / p 2 ,thcn we get:

I I 4-

*.

' k I I." Fig 4n DIVE traffic (uplink) Fig 4b DIVE traffic .I!

-

= E { X }= I I p

"

-

%

,. ," ".

,I ( . I

I.

I ,

" ,. ,. ,. *

I.

,.,'-

:

(downlink)

v

I., ' li2 ,=I

That means thc total dclay per packet for priority k is:

Figure 5 . Video Traffic

Figure 6. BE traffic In case that we aggregate k Poisson traffic strcams (put in the same priority queue) with arrival rates A,,A2,,,,, jlk, and average packet lengths I, ,12 ,. . .,I, , then we have to use in (3) the resulting aggregate traffic, having arrival rate k

Figure 7. Wireless Channel

34

fixed and the dynamic priority assignment scheme (proposed in this paper) as well.

4.2. Bidding and Maximizing the Network Controller Revenue

Optlmal Prlorltles vs. Wireless Capaclty

The bids arc expressed in the fonn of amount of money offered (willingness to pay) by the customer for certain QoS level and certain amount of bandwidth to be assigned to his traffic stream (sce fonnula (1)):

I

10

*

I12

bidTrojlicStream (QoSLevel,bandwidth) (4) Having these bids in mind, if we want to maximize the revenue, we need to select the appropriate QoS levels for each bid. Now the revenue maximization can be seen as an Optintization Problem, its fortnulation appearing as follows:

Figure 8. Optimal Priority allocation vs. Wireless Capacity Fig. 8 shows thc optimal priority allocation according to the rcvcnue maximization optimization criterion depending on thc wireless channcl capacity. Wc SCC that the uplink DIVE traffic always gcts the highest priority as his bid cxcecds the bids froin the othcr traffics. Froiii fig. 9 we can SCC that thc traffic dclays comply with thc dclays from thc QoS dclay vector. Fig. 1 1 shows thc rcvcnuc dcpcnding of the wireless channcl capacity.

Find the QoS Lcvlcs QoSLeveli which, Maxiin izes: Tro/ficS/reurrts

revenlie =

~hidi(QoSLevelj,Ai) i=O

Under the constraints: total - delay(Traf~cStreaiiii)