A Differentiated Services Approach using CBQ
for 3G Communication
András Császár
1, Csaba Lukovszki
1, Róbert Szabó
11
Department of Telecommunications and Telematics
Budapest University of Technology and Economics
Sztoczek 2, Budapest 1111, Hungary
Abstract
Current 2nd generation GSM systems are living their golden ages. The 3rd generation of mobile communication systems is called Universal Mobile Telecommunication System or UMTS, which has a vision of providing every service available in wired networks to the mobile end-user, especially focusing on Internet applications. An IP solution requires the enhancement of IP’s traditional best-effort service to be capable of providing QoS to applications that need it, for example Voice over IP (VoIP) applications. The Differentiated Services (DiffServ) architecture offers a scalable method to provide Quality of Service to applications in IP networks.
This paper focuses on applicability issues and simulation of a DiffServ based IP solution to access networks of mobile communication systems, where the offered services are based on Class Based Queuing (CBQ) schedulers. Our goals were twofold. First, we wanted to create a system, where delay -critical voice packets receive forwarding priority above data packets to provide adequate voice service but data services are not neglected either. That is, we studied a possible service differentiation among the three service types mentioned above. Secondly, we wanted to give all voice packets a fair chance to arrive as expected. Norma lly, short distance voice packets have greater probability to arrive within a low delay bound opposed to long distance packets. Therefore, we studied two methods for intra voice differentiation.
Keywords : VoIP, Differentiated Services, CBQ, UMTS Access Net work
1 Introduction
Europe has witnessed in recent years a massive growth of mobile subscribers. Nowadays, the engineers of mobile telecommunication have to face wider expectations from users than ever. From the user’s perspective, the new generation will strive to ensure that the current mobile services are extended to include multimedia as well as yet undefined services, where access to these services is possible without regard to the underlying networks. The convergence of mobile services to the wired services is inevitable [1][2]. Unfortunately, the main part of currently developed services cannot be assured with 2nd generation (2G) technologies. To address the question of generation evolution, tremendous importance is given in Europe to the development of Third Generation (3G) Mobile Telecommunications Systems. The definition of the Third Generation of Mobile Systems, known as Universal Mobile Telecommunication System (UMTS) in Europe and International Mobile Telecommunication at 2000 MHz (IMT-2000) elsewhere, is one of the most urgent tasks [3][4][5].
The vision of UMTS is to support all those services, facilities and applications that customers presently enjoy, and to have the potential to accommodate, yet undefined, broadband multimedia services and applications with quality guarantees.
technologies such as 2G mobile systems. The trend in this decade is the parallel process of UMTS design and 2G enhancements. Consequently, there is global need to deploy a packet-based carrier to support a wide range of requirements and services because packetization allows for more efficient usage of bandwidth and cost-effective utilization of networks. The most potential candidate from many aspects for packetization is the IP protocol [3][6], that is the key driver for the All-IP trend.
The All-IP’s major challenge is how to integrate mobile systems with the Internet because Internet applications are unbelievable popular, and mobile systems represent the most attractive access form for the end user.
The issue of convergence, meaning the same end user services over different access forms, is vital in the IP environment. Presently, a lot of end user values reside in the already established wired Internet; thus, it is essential that these services can also be made available to the wireless user.
The problem of how wireless or radio systems could adapt to IP is not the only one. There are also questions how IP could adapt to support different services, especially real-time non-data services. Probably, the most important challenge is to provide a certain level of quality assurance for voice calls over an IP network.
Realizing this, IETF started researching alternative solutions from over-provisioning, which modify the current Internet to be able to support new services that require higher QoS than traditional best-effort service [7][8][9].
One of the proposals is the Differentiated Services (or DiffServ or DS) approach. The goal of the IETF Differentiated Services Working Group was to define a lightweight architecture for “scalable service differentiation in the Internet”, where a service is a unique mode of packet transmission “across a set of one or more paths” [9], and a service is available for a branch of connections with some common requirements. Packet transmission modes may be characterized by parameters like throughput, delay, jitter and/or loss ratio, or with relative priority to access to a group of network resources.
The DiffServ architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network. Within the core of the network, packets are forwarded according to agreed service level.
The smallest autonomic unit of DiffServ is called a DiffServ domain, where services are assured by identical principles.
A possible candidate scheduler that could assure services in nodes of a DiffServ domain is Class Based Queuing [11]. The service approach of CBQ is very simple: every class wants to receive a guaranteed share of the link bandwidth during congestion but where bandwidth that is not being used by one of them should be available to the others. This leads to a hierarchical link sharing structure associated with an individual link in the network, with each class in the structure corresponding to some aggregation of traffic. Figure 1 shows such a structure.
Root 100% Agency A 60% Agency B 40% Class 1 25% Class 2 35% Class 3 10% Class 4 30%
Our objective in this paper is to model a Radio Access Network (RAN) that is capable of simultaneously providing different services to the end-user using Internet Protocol. The required services are traditional best-effort data service, an enhanced web browsing data service and voice telephony. We studied the feasibility of the Differentiated Services provided by a CBQ scheduler without admission control algorithms at boundary nodes.
First, we wanted to create a system, where delay-critical voice packets receive forwarding priority above data packets to provide adequate voice service but data services are not neglected either. That is, we studied a possible service differentiation with CBQ among the three service types mentioned above. Second, we wanted to give all voice packets a fair chance to arrive in time. Normally, short distance voice packets have greater probability to arrive within a low delay bound opposed to long distance packets. Therefore, we studied two methods for intra voice differentiation, which take the length of the path-to-travel into account.
2 Network Model
The basis of 3rd generation UMTS research lies in the 2nd generation GSM system and in its enhancements like GPRS. Therefore, a model of a UMTS Terrestrial Radio Access Network (UTRAN) should be built using the GSM counterpart, the Base Station Subsystem (BSS). The investigated BSS topology is shown on Figure 2.
The Base Transceiver Station (BTS) or simply Base Station (BS) in UMTS terminology houses the radio transceivers that define a cell and handles the radio-link protocols with the Mobile Station. In the limited area of a cell, there can be multiple subscribers, and it is possible that more of them are phoning at the same time, which means that a single BTS must be able to handle more speech flows simultaneously.
The Base Station Controller (BSC) (Radio Network Controller (RNC) in 3rd generation terminology) manages the radio resources for one or more BTSs. An important point is that the BSC is the connection between the BTSs and the Mobile service Switching Center (MSC) in circuit-switched GSM or Service GPRS Support Node (SGSN) in packet-switched GPRS and GPRS-based UMTS.
Figure 2: The investigated BSS topology.
performs the switching of calls between the mobile users, and between mobile and fixed networ k users. In GPRS, packets are switched by the SGSN. Although it is not part of the RAN, we included it in simulations because every single packet (be it voice or data) must go through this special node.
From traffic point of view, the simulated RAN+SGSN ne twork has the following properties. Voice traffic is generated on the base stations. In reality, the source is of course the mobile terminal, but voice frames enter the network through the air interface in the BS. The frame is then packed into an UDP/IP da tagram; this is consistent with the backbone network, since the UMTS core network bearer service is based also on UDP/IP datagram delivery [13]. Voice packets travel in the RAN’s tree topology up to the BSC, which forwards them to the SGSN, which then re-addresses the IP packet to its final destination. Note that we modeled voice traffic only, which stays within the cellular network. Thus from network aspect, the sinks of traffic are also the base stations. The two data services (web and best-effort) have their entry into the simulated network at the SGSN because the core network is connected to the Internet with a gateway. Thus, data traffic generators are on the SGSN, and they also generate UDP/IP packets i) because of consistency with the core network, and ii) because this paper focuses on IP quality, for example IP drop ratio, therefore the TCP error -correction would have led to unneeded behavior.
When going up in the tree network, more and more traffic share the links’ bandwidths. To counteract the aggregating traffic, link capacities also have to increase accordingly. Every BTS is assigned a bit -rate of 384000bps = 384kbps. Thus, links to leaf nodes have right 384kbps bandwidth. The link between the SGSN and the BSC equals to three E1 links of , since it aggregates traffic of 16 nodes. Besides, every link’s propagation delay is 5ms that involves every low -level delay incurred below the IP layer: it is the sum of processing and conversion delays on both the data connection layer and the physical layer and the propagation delay on the link.
3 Traffic Models
3.1 Voice Traffic Generation
The widely accepted method to model phone call arrivals, is the Poisson-process, with parameter l. l is the mean value of the number of calls generated during a time unit (e.g.: 5 calls/minute). We modeled call holding times using exponential distribution with 60s mean value.
We used a two state on-off model to model one voice mobile user, where during speech, the CBR generator is switched on, but in silence, it is switched off. With a silence detection mechanism, the call does not occupy bandwidth during silence that may be very important in some cases. For example, this mechanism is used in GSM networks to minimize interference in the radio interface and it is also a good way of decreasing the probability of congestion in non-circuit-switched networks, like the Internet. Further, we used the GSM Full Rate coding, which divides speech in 20ms pieces and digitizes them using 260 bits, which leads to 13kbps
ms 20
bit 260 = bit rate.
distributions for speech bursts and speech pauses. For short speech bursts, the distribution is rather irregular, probably due to the Voice Activity Detector (or VAD).
This model defines traffic generated on a single base station, and – to get a network-wide traffic model – every BTS generates traffic according to this single-node model independently. The destination of the calls is drawn from a uniform distribution among all available BTSs.
The 260 bits GSM voice frame has to be transformed into an IP packet, which normally means at least an 8 bytes UDP header and 20 bytes of IPv4 header (40 bytes in IPv6), plus – depending on the application – a 12 bytes long RTP header. [15] Together, these lead to a 40 bytes long overhead vs. the 33 bytes of raw GSM data. This causes not only inefficient usage of network resources but increases transfer delay by more than 50%, which is unacceptable on slower links. The solution is the IETF proposed IP Header Compression [16][17]. With this procedure, the header can be compressed to 2-4 bytes, which is an acceptable overhead.
3.2 WEB Traffi c Generation
We chose the web traffic model defined in reference [18]. This model tries to catch a typical WWW browsing session (Figure 3), which consists a sequence of “packet calls”. Packet calls are initiated when users request an information entity. During a packet call, several packets are generated by the server, which means that the packet call constitutes of a bursty sequence of packets, which reference [18] has found very important to take into account in the traffic model because the burstiness during the packet call is a characteristic feature of packet transmission in the network. After a packet call when the requested document entirely arrived at the terminal, the user spends some time reading the information, therefore, this time interval is called “reading time”. This is similar to the on-off model described previously. Note, that this model is only about downstream traffic, while upstream traffic is not modeled. The volume of this traffic is so small that it is considered negligible.
In a WWW browsing session, a packet call corresponds the downloading of a document (e.g.: HTML and some graphics). The next packet call is initiated when the user finished studying the document, and for example clicks a hyperlink or enters a new WWW address to request a new document.
Figure 3: A www browsing session.
The session arrival process is again a Poisson-process. And again, the mean value of this process (l) determines what population of users surf the web parallel. Other parameters of the model are the number of packet call requests per session, the reading time between packet calls, the number of datagrams in a packet call and the inter arrival time between packets. Packet sizes are modeled by a Pareto-distribution with cut-off at 66666 bytes. For mean values, paper [18] defines more numbers corresponding to the available UMTS data rates from 8kbps up to 2048kbps. We chose the 32kbps data rate because it gives an acceptable surfing experience and in the initial deployment of UMTS, it is unlikely that users will be offered very high bit rates.
Every base station generates traffic independently according to this model. Actually, traffic is generated in the SGSN – as if it got the data from an outside server. BTSs are only the sinks of the data streams.
smaller than the 66666 bytes maximal application level packet size. Thus, segmentation may be needed.
3.3 Best-Effort
We modeled Best-Effort traffic generated by two typical applications that use best-effort forwarding in nowadays wired networks. The first one is a terminal application. The second traffic type tries to model file downloads (e.g.: FTP). For both applications, the previously described Web model is applicable – with other parameters, of course.
3.3.1 Telnet
Here, we tried to catch typical server responses to commands typed in a terminal. The modeled behavior is the following: a user types a command and receives characters as response (“packet call”). The received amount of data ranges from a few characters or few lines to screens full of information. For example, the command “ls -l“ in Unix compatible platforms returns a detailed list of directory contents, the length of which depends on the directory. The response to the command “pine” is a single full screen with the user interface of the e-mail reader program.
When the user receives the response, he/she takes some time to study the information (“reading time”). To model this behavior we adapted the model parameters to simulate an average value of 20 commands/session. The reading time is 30 seconds in average. The average amount of information received in a packet call is 1920bytes. A conventional terminal screen has 80 characters in 25 lines, which is equal to 2000 bytes, so the above mean value is quite good. The inter arrival time of packets is unchanged to suite the 32 kbps UMTS service rate.
3.3.2 FTP
A typical file transfer behavior contains few but large packet calls, where a packet call is the downloading of a file. The model was set up to allow a user to download two files in average in a session with about a 10 minutes gap between the two consecutive file downloads. The average size of downloaded files is 75kB, which is appropriate for smaller compressed files or PDF documents.
4 Multi-service Support of CBQ
We considered the previous IP-BSS architecture as being a single DiffServ domain. Every BTS is a boundary node for voice calls generating or terminating on it. On the other hand, BTSs are also core routers of the domain, since voice packets pass through these nodes. In this aspect, the BSC is only a core node because it just forwards packets. The SGSN is virtually a core router from the aspect of voice packets because it routes these packets back to their destination BTSs. From the view of data packets (web and best-effort) however, the SGSN is an (ingress) edge node.
The major part of every DiffServ node is a queuing structure and its scheduler, which are to support the required per-hop behaviors of all service classes. A simple Static Priority Queuing could differentiate between the three classes: voice would receive highest priority, web middle priority and best-effort would be mapped to the lowest priority. This way, voice packets would be transmitted as fast as possible and web traffic would get higher QoS than best-effort traffic, but data services might be starved depending on the actual load of the voice class. A CBQ solution would be to use three queues for the three service classes with appropriate (fair) CBQ link shares for every class. Link shares should be set considering expected load levels of classes and the following guidelines:
ii) Web class should get a higher link share to provide subscribers the service they paid for, i.e. the enhanced, better than best-effort behavior.
iii) Be it ever so little requirements against the best-effort forwarding, this class should still get some minimal resources to avoid starvation, although when other classes don’t fully utilize their assigned bandwidth, the BE class could transmit packets in these periods even with 0% link share.
Figure 4 plots this solution. The realized PHBs are this way the Default Best-Effort PHB [19] and two PHBs from the Assured Forwarding PHB group [20] with two different assured bandwidth values. This realization should differentiate between the three service types fairly good.
The previous model however, does not differentiate between voice packets based on the length of their paths. That would need the voice class to be segmented to sub-classes and each sub-class to receive its own queue, as in Figure 5.
As every packet in a call travels across the same path, the next step is to decide how many sub-classes should be used and how voice calls are classified to sub-classes. In the following, let’s suppose, we will use N different voice classes and that every packet is expected to be transferred from the ingress to the egress node within a maximal delay of Dnet. Dnet is the sum of
propagation and transmission delays of all links and queuing delays in every node [21]. Formally:
∑
∈+
+
=
Path h h h h netP
T
Q
D
(
)
Propagation delay (Ph) is the amount of time needed for individual bits to arrive at the end of the link from the beginning, and it depends on the distance between the source hop and the receiver hop (Ph º 5ms in my model). Transmission delay (Th) is the amount of time needed to
take a packet out of its queue at a specified bit-rate. These two values are fix and schedulers cannot influence them, as opposed to queuing delay (Qh), which is the amount of time a packet
waits in its queue for transmission. The longer a path is, the smaller queuing time is left in each node.
Therefore, a simple classification rule could be to watch the number of hops the call will pass.
A classification method could classify calls depending on the spare time (SPath) their
packets can wait in queues, specifically the classifier index will be:
∑
∑
∈ ∈+
−
=
=
Path h h h net Path h h PathQ
D
P
T
S
(
)
. Voice 85% Web 10% Best - Eff. 5% Root 100% Priority 1 AF11 PHB Priority 2 AF 21 PHB Priority 3 Default PHBFigure 4: A CBQ structure for three services
Root 100% Voice 85% Voice 1 35% Voice 3 10% Web 10% Best-Eff. 5% Voice 2 25% Priority 1 AF 11 PHB Priority 2 AF 21 PHB Priority 3 AF 31 PHB Priority 4 AF 41 PHB Priority 5 Default PHB
Figure 5: An advanced CBQ structure1
1
Since the number of available classes (N) may be smaller than the number of different spare times possible, SPath is quantified, so actually a spare time range is classified to a single
DiffServ class. It is possible that the same spare time range is the result of more different hop number paths coming – again – from the possible differences in Ph and Th. A yet more advanced
classifier could make a decision depending on the average spare time that can be spent in a single queue, thus the classifier index would be the per-hop spare time:
Path Path
H S
, where HPath is the
number of hops of the specific path. I used this classification mode for intra-voice differentiation.
Intra-voice classes could be realized again with SPQ, where smaller per-hop spare times are mapped to classes with higher priority. CBQ can implement SPQ as a special case, where no link share is guaranteed to any class.
5 Delay of Voice Connection
To be strict with the network, we chose a maximal end-to-end delay (De2e) value of 100ms,
although ITU-T recommends a maximum of 150ms. End-to-end delay consists of the following delays:
i) Encoding delay: the time it takes to encode the analog signal, which is the sum of the following parts:
a) Frame size f : the size in ms of a speech clip that is encoded to a voice frame. In the GSM codec, this is 20ms.
b) Look-ahead delay l is the time some codecs watch into the future of the analog signal to get some extra encoding and compressing information. The GSM FR codec does not look ahead, so this value is zero.
c) Processing delay is the delay incurred during the encoding process. The more complex the encoding algorithm is, the larger this time is. With today’s hardware, the processing delay of the GSM codec is negligible.
ii) Packetization delay is a function of the number of frames k included in a single packet, specifically: Dpack=
(
k−1)
f. In our case, k = 1: a UDP/IP packet is built from one frame.iii) Network delay (Dnet) is the time needed to transport the packet through the network,
per-hop spare time, one has to divide it by 8: 7.5ms / 8 = 0.9375ms is the average time-va lue such a critical voice packet can spend in a queue. The shortest paths have 4 hops from which the highest link bandwidth gives the smallest transmission delay (blue path), totaling to about 20.4ms minimal network delay. The path's spare time is thus 29. 6ms, and the per-hop spare time is 29.6ms / 4 = 7.4ms. There is indeed a huge difference compared to the longest path: least critical packets can wait almost 8x longer in queues than most critical packets.
Figure 6 shows the distribution of per-hop spare times. One can see that there are actually five distinct groups of per-hop spare times, which is not accidental. It would be possible to further differentiate these classes, however we confined ourselves with this level of differentiation. 0 0.02 0.04 0.06 0.08 0 1 2 3 4 5 6 7 8
Per-hop spare time [ms]
Occurance
Voice 1 Voice 2 Voice 3 Voice 4 Voice 5
Figure 6: Grouping voice traffic based on the per-hop spare time distribution
Therefore, the CBQ link-sharing tree is similar to that on Figure 4 and Figure 5 but there are five sub-classes below the Voice class. In a simple case, these sub-classes are differentiated only by priorities. That is, the highest priority (most critical) Voice1 class can use all the bandwidth available to the voice class (85% or more when excess bandwidth from web or best-effort classes is ava ilable) as long as it has waiting packets in its queue. When its queue is empty, the whole bandwidth is offered to Voice2 and so on. Since this solution leads to starvation of low priority classes as described later, we used CBQ’s ability to rate-limit classes or to be precise: to guarantee some minimum bandwidth for low priority classes as well. The previous priority-only solution will be called on the diagrams as “5 classes”, and the priority plus CBQ rate-limiting solution will be called as “5 classes (Fair)”.
When analyzing the network performance, we wanted to know how many packets were actually transferred in-time that is, within 50ms. To get a session-level quality metric, we defined call acceptance. A call is accepted if at least 90% of its packets arrived and was not late! 60% 65% 70% 75% 80% 85% 90% 95% 100% 60% 70% 80%
Offered voice load
Call acceptance 1 class
5 classes
5 classes (Fair)
Figure 7: The effect of offered voice load on call acceptance ratio 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Voice1 Voice2 Voice3 Voice4 Voice5 Voice classes
Call acceptance
1 class 5 classes 5 classes (Fair)
In our previous article ([23]), we showed that the usage of a priority-only intra voice differentiation (“5 classes”) pays off in terms of call acceptance ratio compared to the case when only a single voice class is. You can see that on Figure 7: the call acceptance ratio of the “5 classes” solution is always higher than that of the “1 class” solution. In the “5 classes (Fair)” simulations, CBQ guaranteed some minimum bandwidth for all classes.
There is however one more factor, which we didn’t study in our previous article. This factor is fairness. “Fair” means that the quality metrics in all voice classes are the same. To study fairness, we decomposed the call acceptance ration to the different voice classes.
When all five groups are classified to a single voice class, every voice packet is offered the same per-hop behavior, because every packet has the chance to be the first or the last in the FIFO queue. A Voice1 packet that traverses the longest path has not enough spare time to wait the transmission of several voice packets before itself, as opposed to a Voice5 packet, which travels through a the shortest path. Offering the same environment to all packets, this “1 class” method is similar to nature: the stronger survives. Here, a packet (or call) is “stronger” when it has more per-hop spare time. The results confirm this in every aspect (Figure 8: “1 class”). You can see how unfair the “1 class” method is, especially to Voice1 and Voice2 packets, which have a much lower call acceptance ratio.
You saw that more calls are accepted if intra-voice service differentiation is applied. That is, instead of using a single voice class for every voice packet, one could use five classes for the five voice groups. The “5 classes” results were collected, when these five classes were simply prioritized, so that Voice1 has highest priority and Voice5 has lowest, as in paper [23]. Although when summarized, more packets arrive in time and so more calls are accepted, this solution turns around the fairness question: it enables a much better quality for urgent packets than for others (Figure 8: “5 classes”). However, when measuring the difference between the highest and lowest points of the individual results, the absolute difference between these points is smaller compared to the “1 class” case.
The conclusion from Figure 8 is the service parameters would be set up according to meet the fairness criteria. The previous solution only prioritizes the classes, that is, the highest priority class could use all the 85% bandwidth assigned to the voice service, when it had something to send. The last (Voice5) class could only transmit packets, whenever all the higher priority queues were empty. That is why this solution was unfair: the service of lower priority classes depends on actual traffic of high priority classes because low priority classes were not granted a minimum bandwidth. The fair solution overcomes this problem by granting every class a minimum link share with CBQ to avoid starvation. Compared to the priority-only case, with this method low priority classes perform somewhat better in the expense of high priority classes, which perform worse.
7 The Effects of MTU onto Voice and Data Metrics
bytes. When MTU is set too low, another problem appears on the scene: overhead of data packets. The higher the overhead is, the higher the load of the network is, and the more queue length has to be reserved. For example, when MTU is 100 bytes, then there is only 72 bytes space left for data, besides the 28 bytes UDP/IPv4 header, meaning a 39%
bytes 72
bytes
28 ≈
overhead, which seems too much. From the aspect of voice, this MTU is very favorable, since on the slowest 384kbps link it takes only 2.1ms
kbps 384
bits 8
100⋅ ≈
to transmit such a packet, which is an acceptable delay. Closer to the SGSN on a higher speed link, transmission time is less, however it occurs more often. With MTU=200 bytes, the overhead would decrease to 16%
bytes 172
bytes
28 ≈
but the transmission time would double to about 4.2 ms. Thus, a network operator would have to find a balance, which is acceptable from both sides, and the usage of simulations is a good tool to investigate the effects of different data packet sizes.
The simulation scenario was the following: the load of voice traffic was in average about 60%, and the load resulting from data traffic was 20%. The 20% data load was shared equally between web and best-effort traffic (10% + 10%). That is, the average network utilization was about 80%. The MTU setting effects voice forwarding only through the residual transmission time of da ta packets, since voice packets are 37 bytes long, so they need not be segmented in any of the studied MTU cases (100, 200, 500 and 1000 bytes).
The influence of MTU to the call acceptance ratio of voice calls is shown on Figure 9, and they are very interesting although they were expected. With smaller MTUs, the residual transmission time is less, however, CBQ will send smaller packets more often in order to reach the same link-share. Even so, this phenomenon does not balance the serious effects of transmission times to voice forwarding. When changing the MTU from 100 bytes to 200 bytes, voice packets are barely affected. An MTU = 500 bytes setting however, considerably influences the properties of voice. As you can see, the percentile of accepted calls decreases with around 10 percent. Doubling the MTU to 1000 bytes triples the ratio of unaccepted calls from 10 percent to 30 percent.
Additionally, the advantage offered by classifying voice calls and prioritizing longer paths turns to a handicap with high MTUs, since the priority scheduler chooses the most critical voice packets for transmission first, when the transmission of the data packet is finished. A Voice1 packet for example, would require waiting maximally 0.8 ms in a queue (on the average through the path).
We showed the effects of increasing MTU size from the aspect of voice, where the major challenge was the increasing transmission time of bigger and bigger data packets. In the following, we approach the MTU problem from the aspect of data services.
60% 65% 70% 75% 80% 85% 90% 95% 100% 100 200 500 1000
MTU size [bytes]
Call acceptance 1 class 5 classes
Figure 9: The effect of MTU on voice calls' acceptance ratio 0 % 2 % 4 % 6 % 8 % 10% 12% 100 200 5 0 0 1 0 0 0
MTU size [bytes]
Drop ratio of data packets
Web Best-Effort
Figure 10: The effect of MTU size on the drop ratio of data packets
8 The Effect of Offered Data Load onto Voice Metrics
In this section, we look into the simulation results to learn what impact the increase of data load has to voice traffic. We showed how seriously large data packets affect voice quality. In this case, the MTU is fixed to 200 bytes, and voice load is in all cases 60%, while data load increased from 0% to 40% with 10% steps. The question is, how CBQ protects voice traffic from data traffic.
On Figure 11, you can see that CBQ can shield voice traffic from data packets fairly good. A little degradation can be still be followed on the diagram, but it has a rational explanation: With the increase of data load, more and more data packets are transmitted on links, thus, voice packets have to wait more often the remaining transmission times of data packets. As we saw previously, a 200 bytes MTU setting is quite fair against voice, nevertheless, “little strokes fell great oaks”. That is, the increasing number of 200 bytes long data packets still has some limited effect onto voice forwarding. Thanks to CBQ, these “oaks” are not so great at all.
The second reason is a consequence of the CBQ setup (Figure 4). When data load is zero percent, there is no data traffic at all. The whole 15% bandwidth allocated to the two data services can be used – as excess bandwidth – by the voice class. When increasing the data load to 10 percent, only 5 percent excess bandwidth remains for the voice class. Further raising data load, all excess bandwidth is gone from the voice class.
The usage of five voice classes has positive effects: this solution is even less sensitive to the increased data load than the single voice class solution. The latter solution has only 5 percent less calls accepted when raising data load from zero to forty percent! That is already a very good result, with five classes however, the increasing data load affects only less than 2 percent of the calls!
90% 91% 92% 93% 94% 95% 96% 97% 98% 99% 100% 0% 10% 20% 30% 40%
Offered data load
Call acceptance 1 Class
5 Classes
9 Conclusion
In this paper, we investigated how a CBQ scheduler could provide different QoS levels for different service types in a Differentiated Services context. The goal was to implement an IP-based bearer service to the radio access network of a 3rd generation UMTS system that supports multiple services (voice, web and best-effort).
We showed that CBQ can protect voice traffic from data traffic if data packets are segmented to appropriately small sizes. Further, we showed a method for intra-voice differentiation. This method differentiates voice flows to classes based on the length of their paths. We showed that when there is no such differentiation, voice calls through longer paths have lower quality than to closer paths, so it is unfair against traffic having to pass a longer path. When using intra-voice differentiation, we studied the properties when the classes are only prioritized. With this solution, more calls were accepted overall, and it was fairer than the single class case. However, it was a little too generous for high priority classes, and it was a bit unfair against traffic that has to go through a short path because this traffic was classified to low priority classes, and low priority classes may get starved under certain load conditions (for example in a period when high priority classes are highly loaded). Therefore, we showed that with an appropriate CBQ link-sharing setup, one can reach an almost perfectly fair setup, where phone calls having to traverse longer paths have the same quality as phone calls through shorter paths because CBQ could assign a minimum link share for low priority classes too.
Further, we brought concrete results on the effects of MTU size on data traffic as well as on voice traffic.
10 References
[1] B. E. Fernandes: “Towards 3rd-generation mobile systems”, IEEE International Conference on Personal Wireless Communications, 1996, pp. 307-312
[2] C. Testman, L. Eriksson: “Mobile e-commerce”, Ericsson-White Paper, 1998
[3] L. Bos, S. Leroy: “Toward an all-IP-based UMTS system architecture”, IEEE Network, Volume: 15 Issue: 1, January/February 2001, Pages: 36-45
[4] Schwarz da Silva, B. Arroyo-Fernandez, B. Barani, J. Pereira, D. Ikonomou: “Evolution Towards UMTS”, European Commission – DG XIII-B.4.
[5] “The European Path towards UMTS”, Special Issue of the IEEE Personal Communications Magazine, February 1995.
[6] Attila Takács, András Császár: “Voice Traffic Control Study over IP -Based GSM Backbone”, Scientific Student Conference, BUTE, 2000
[7] R. Braden, D. Clark and S. Shenker: “Integrated Services in the Internet Architecture: an overview”, Internet RFC 1633, June 1994
[8] Y. Bernet, et. al.: “A Framework for Differentiated Services”, Internet Draft, February 1999, Work in Progress [9] S. Blake, et. al.: “Architecture for Differentiated Services”, Internet RFC 2475, December 1999
[10] Y. Thomas Hou et. al.: “QoS-Enabled Voice Support in the Next-Generation Internet: Issues, Existing Approaches and Challenges”, IEEE Communications Magazine, April 2000
[11] Sally Floyd and Van Jacobson: “Link-sharing and Resource Management Models for Packet Networks”, IEEE/ACM Transactions on Networking, Vol. 3 No. 4, August, 1995, pp. 365-386
[12] S. Dixit, Y. Guo, Z. Antoniou: “Resource Management and Quality of Service in Third-Generation Wireless Networks”, IEEE Communication Magazine, February, 2001, pp. 125-133
[13] Rajeev Koodli and Mikko Puuskari: “Supporting Packet-Data QoS in Next-Generation Cellular Networks”, IEEE Communication Magazine, February, 2001, pp. 180 -188
[14] Tord Westholm, Birgitta Olin: “A Model for GSM Speech”, Proceedings of Symposium on Performance Evaluation of Computers and Telecommunication, July 16-20, 2000, Vancouver, British Columbia, Canada
[15] Katsuyoshi Iidia: “Performance Evaluation of the Architecture for End-to-End Quality-of-Service Provisioning”, IEEE Communication Magazine, April 2000
[16] M. Degermark, B. Nordgren, S. Pink: “IP Header Compression”, Internet RFC 2507, February 1999
[17] S. Casner, V. Jacobson: “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links”, Internet RFC 2508, February 1999 [18] “Traffic models”, Universal Mobile Telecommunications System (UMTS); Selection procedures for the choice of radio
transmission technologies of the UMTS (UMTS 30.03 version 3.2.0) – ETSI Technical Report TR 101 112 V3.2.0 (1998-04); pp. 33-35
[19] Nichols, et. al.: “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, Internet RFC 2474, December 1998
[20] J. Heinanen et. al.: “Assured Forwarding PHB Group”, Internet RFC2597, June 1999
[21] M. J. Karam, F. A. Tobagi: “Analysis of the Delay and Jitter of Voice Traffic Over the Internet”, Proceedings of the IEEE Infocom 2001 Conference, Anchorage, Alaska, USA; April 2001
[22] Kevin Fall and Kannan Varadhan: “The ns Manual”, http://www.isi.edu/nsnam/ns/ns-documentation.html
