2. LITERATURE REVIEW
2.3 Q UEUEING
2.3.7 Weighted Fair Queueing (WFQ)
WFQ is proposed to solve the variable size packets issue with a more complicated algorithm than DRR. It is based on Generalized Processor Sharing (GPS)[12] to deal with flows packet by packet and each packet would be assigned a tag (finish time) to determine which packet is delivered. The finish time is the time period that a packet in a flow will have been transferred and a packet with a lowest finish time will be sent.
The finish time could be calculated by the following equation:
/ Wi round number (virtual time), it is updated at each arrival and departure. Where R(0)=0 and R(t+τ)=R(t)+τ /
∑
Wi,∑
Wi is sum of weights of active flows. P(i, k, t) is the size of packet k that arrives in a flow i at time t. The pseudo code of WFQ is shown in Figure 2.12.Q = # queues // packet arrival for (i=0; i<Q; i++){
Queue[i].finish_time = virtual_time + pkt_size / queue[i].weight //packet extract
min_finish_time = Min (Queue[i].finish_time) for (i=0; i<Q; i++) {
packet_send(queue(i)) = Min (queue(i).finish_time) }
Figure 2.12 A Pseudo Code of WFQ 2.3.8 A Summary of Queueing Schemes
Several queueing schemes have been discussed in the above sections. Each queueing scheme has its strength and weakness. With the different packet forward
of these queueing schemes are listed in Table 2.3.
Table 2.3 Comparisons of Scheduling
Queueing scheme Advantage Disadvantage Complexity
FCFS • Easy to
implement
• Long delay time
• No flow isolation
O(N)
Priority Queueing • Easy to implement
• Lack of flexibility
• Limitation for variable packet size
DRR • Effective fairness with variable
• Complex algorithm O(N)
SFQ • Bandwidth
fairness
• large packets make long delay time
• Increasing FIFO queues
O(N)
3. A Preemptive Queueing Scheme for UMTS Background Traffic
3.1 System Overview
3.1.1 Basic Concept
This study wants to aim at the UMTS background application to propose a queueing scheme. With the proposed queueing scheme, differentiated services could be supported among the background applications within an UMTS core network. An important or emergent background application could always receive a better transmission performance and QoS than other applications that might not be important or emergent. In this study, the proposed queueing scheme would preempt the bandwidth that allocated to the lower priority applications to the higher priority applications. With the preemptive queueing scheme operating, the proposed queueing scheme could provide the QoS for the important/emergent applications.
In this study, the preemptive queueing scheme would base on the role of mobile network user to assign the different priority to the UMTS background applications.
Therefore, the proposed preemptive queueing scheme is called the role based queueing (RBQ) scheme. With this role-based idea, UMTS users in different situation who need diverse service requirements; they can change their role of using mobile services on demands and received the required QoS provided by RBQ. Each predefined role will get a different level of priority. An UMTS user could pay cost to promote his role to get a higher priority for his UMTS background application. In this study, three type roles of UMTS users are defined, they are Emergency, VIP and Member. Emergency has the first priority; VIP has the second priority; and Member
has the third priority. According to the defined roles in UMTS background
applications, the different priority would be assigned to UMTS background applications. The RBQ would base on the priority to support the required QoS for UMTS background applications.
3.1.2 Assumptions
Since UMTS is a sophisticated mobile communication system, there are some assumptions should be defined for the RBQ scheme to ensure effectiveness in this study. First, the RBQ scheme would be implemented in gateways within an UMTS core network. The operation domain of RBQ scheme is the UMTS core network.
Second, an UMTS mobile network would support four type applications that defined by 3GPP. The RBQ scheme would provide differentiated services among UMTS background applications. There have been many researches discussing about QoS of delay-sensitive applications and this study would expect that non-delay-sensitive applications like e-mail or file transferring (non-voice application) can be overwhelmingly coming with 3G [21].
3.1.2 UMTS QoS Criteria for RBQ
3GPP has defined the QoS attributes of UMTS bearer service that are the essential criteria to evaluate distinct traffic class [17]. The UMTS core network bearer service attributes are shown in Table 3.1. Since UMTS background application services cover all non-time critical applications such as E-mail, SMS, and FTP. The preemptive behavior among UMTS background seems allowable and can be manageable.
Therefore, in the proposed queueing scheme, only background applications are chosen as the regulation targets. According to QoS bearer service attributes defined by 3GPP, the proposed RBQ scheme would follow those attributes to meet the QoS criteria required for UMTS background applications. Therefore, some core network bearer service attributes would be taken into consideration, such as maximum bitrate,
delivery order, maximum SDU (Service Data Unit) size, SDU error ratio, residual bit-error ratio, delivery of erroneous SDU and allocation/retention priority.
Table 3.1 UMTS bearer QoS attributes defined for each traffic class [17]
Traffic class Conversational Streaming Interactive Background
Maximum bitrate X X X X
Traffic handling priority X
Allocation/Retention priority X X X X
Sources statistics descriptor X X
Signaling indication X
Why these seven core network bearer service attributes would be considered to evaluate the performance of the proposed RBQ scheme? The reasons are described as the following:
• Maximum bitrate (kbps):
It is a maximum number of bits that a UMTS bearer can deliver into service access point (SAP) in a specified interval.
• Delivery order (y/n):
This attributes determines whether the bearer sequences SDUs in the correct order.
• Maximum SDU size (octets):
The maximum allowed SDU size in admission control and policing.
• SDU error ratio:
It is the fraction of SDUs. It is mainly used in UTRAN to configure protocols, algorithms, and error detection schemes.
• Residual bit error ratio:
It indicates the BER that is undetected. BER is specified for each subflow over the radio access bearer.
• Delivery of erroneous SDUs (y/n/-):
It indicates whether erroneous SDUs are delivered.
• Allocation/Retention priority:
It is used to discriminate between bearers when allocating or retaining scarce resources.
After reviewing the definitions of core network bearer service attributes, this study selects the “bit rate”, “allocation/retention priority”’ and “max SDU size” bearer service attributes as the evaluation criteria for the RBQ scheme. Since the RBQ scheme would operate in the IP layer within an UMTS core network, other core network bearer service attributes about packet deliver sequence control and error control would be handled by the upper layer protocol, TCP. Therefore, those core network bearer service attributes should not be considered as the evaluation criteria for the RBQ scheme. These attributes include “delivery order”, “residual BER”,
“delivery of erroneous SDU” and “SDU ratio”.
3.2 RBQ Scheme
3.2.1 Queueing Scheme Architecture
A queueing scheme can be divided logically into two parts, ENQUEUE and
DEQUEUE. The ENQUEUE would process the arriving packets from the upstream gateway and the DEQUEUE would take care of the departing packets that should forward to the next downstream gateway. The architecture of RBQ scheme would be also divided into two parts, the ENQUEUE and DEQUEUE. Figure 3.1 shows the architecture of RBQ scheme. The detailed components of RBQ scheme will be described at the next section.
Figure 3.1 Role Based Queueing Scheme Architecture
The ENQUEUE of RBQ scheme provides two functions, role selector and preemptive packet switcher. The role selector would examine the header of coming IP packet from the upstream gateway to identify a role that assigned to the packet. After examining the role identification of an IP packet, the role selector would base on the role identification to assign a QoS priority to the coming IP packet. Table 3.2 shows the mapping relationship between role identifications and QoS priority.
After a QoS priority setting in an UMTS background application packet, the ENQUEUE preemptive packet switcher would be activated to handle the coming
packets and enqueued packets into the logical queues. After a QoS priority setting in an
Table 3.2 A mapping between role identification and QoS priority Priority Level Role Identification
High Emergency Medium VIP
Low Member
UMTS background application packet, the preemptive packet switcher would depend on the QoS priority in the coming packet to enqueue the packet into the corresponding logical queue with the different QoS priority. The packets with the same QoS priority would be enqueued in the same logical queue. The logical queues for the different QoS priority are first-come-first-serve (FCFS) queues. Moreover, the preemptive packet switcher would perform a preemptive enqueue operation if the queue has no buffer size for a high QoS priority packet to enqueue the corresponding logical queue.
The packet switcher would base on QoS priority of the arrival packet to determine whether the arrival packet would have the privilege to release a buffer size from a logical queue with a lower QoS priority. If there is an enqueued packet in the lower QoS priority logic queue, the tail packet would be removed to release a buffer size for the arrival packet with a higher QoS priority. Otherwise, the arrival packet would be dropped. With the preemptive enqueue operating, high QoS priority packets could always have privileges to enqueue the logic queues. The detailed description of ENQUEUE scheduling is presented at section 3.2.3.
In the DEQUEUE part of BRQ scheme, a preemptive packet forwarder function is used to dequeue the packets form each logic queue. A round robin mechanism is adopted in the preemptive packet forwarder function. According to QoS priority
precedence, the packet forwarder function would forward the enqueued packets in the first QoS priority logic queue first. After finishing the packet forwarding in the first QoS priority logic queue, the packets in the second QoS priority logic queue would be forwarded. The packets in the third QoS priority logic queue would not be forwarded until there is no packet in the first QoS priority logic queue and the second QoS priority logic queue to be forwarded. With the preemptive packet forwarder function operating, the packets with high QoS priority always get precedence to be forwarded in the logical queue. Therefore, background applications with an emergent / important role could always receive better QoS.
3.2.2 The Logical Queue Operations in Role Based Queueing Scheme
In the proposed RBQ scheme, there are three logical queues (LQ1, LQ2 andLQ3) to construct one physical queue (PQ), the RBQ. Each logical queue has its precedence QoS priority and would handle the different types of role-based packets. UMTS background application packets with the “member” role identification would be enqueued into the LQ1 which is the third QoS priority queue in the RBQ. Packets with the “vip” role identification would be enqueued into the LQ2 with the second QoS priority. Packets with the “emergency” role identification would be enqueued into the LQ3 with the first QoS priority. Figure 3.2 shows the logical queue in the RBQ.
Figure 3.2 RBQ Elements
Each of these three logical queues is a drop-tail queue (FIFO). The total buffer size of these three logic queues is equal to the buffer size of physical queue, i.e. LQ1 + LQ2 + LQ3 = PQ. In other words, when the buffer of physical queue (PQ) is full, the packet switcher function in RBQ scheme would be activated to execute a preemptive enqueue operation. The enqueued packet in the LQ1 or LQ2 would be removed to release the buffer space of PQ. Then, a packet with high QoS priority could be enqueued into the LQ3 or LQ2.
With the RBQ scheme operating, the total buffer of physical queue is shared with each logical queue dynamically. Therefore, packets with the “emergency” or “vip”
role identification could always be enqueued into the LQ3 or LQ2 logical queue. The buffer space of physical queue would be preempted by the packets with higher role identification. Table 3.3 shows the relationship among logical queues, relative packets types and priority.
Table 3.3 Logical Queue Elements Logical Queue # Scheduling
Discipline
Role of packets Priority
LQ3 Drop-tail Emergency High
LQ2 Drop-tail VIP Medium
LQ1 Drop-tail Member Low
3.2.3 Preemptive Packet Switcher Function
In the ENQUEUE part of RBQ scheme, the preemptive packet switcher function would switch the packets into the logical queue according to the QoS priority assign by the role selector function. If the buffer of physical queue is full, the preemptive packet enqueue operation would be activated by the preemptive packet switcher function to ensure the packet with high QoS priority could be enqueued into the corresponding logical queue. The process of ENQUEUE preemptive packet switchers is illustrated in Figure 3.3.
Figure 3.3 ENQUEUE Preemptive Packet Switchers Process Diagram
As a packet coming, the role selector function would base on the role identification in a packet to assign a value to variable K to the packet. The preemptive packet switcher would check whether the used physical queue buffer excess the maximum buffer size or not? If it does not excess the maximum buffer size, the preemptive packet switcher function would enqueue the packet into the corresponding logical queue. Otherwise, if there is no buffer space available to enqueue a packet into the corresponding logic queue, the preemptive packet switcher function would activate the preemptive packet enqueueing operation. First, the preemptive packet switcher function would check the QoS priority of a coming packet. If the QoS priority is lower, then the coming packet would be dropped. Otherwise, the preemptive packet switcher function would try to remove an enqueued packet from the tail of LQ1 or LQ2 to release the queue buffer space. If there is one packet removed from LQ1 or LQ2, then the coming packet would be enqueued into the corresponding logical queue.
If no packet could be removed from LQ1 or LQ2, the coming packet would be
dropped. The preemptive packet switcher function always let packets with high QoS priority have a privilege to enqueue into the corresponding logical queue. The pseudo code of the preemptive packet switcher is shown in Figure 3.4.
K = role of packet, LQ = Logical Queue, PQ = Physical Queue
if (Packets_k){
allocate Packet_k into relative LQ enqueue Packet_k
} } else
Figure 3.4 Preemptive Packet Switcher Function Pseudo Code 3.2.4 Preemptive Packet Forwarder Function
The DEQUEUE preemptive packet forwarder function uses round robin mechanism to forward packets from each logical queue in turn. According to the QoS
priority precedence, the preemptive packet forwarder would forward the packets in LQ3 first. When there is no packet in LQ3, the packets in LQ2 would be forwarded.
Finally, if there is no packet in LQ3 and LQ2, the packets in LQ3 could be forwarded.
With the preemptive packet forwarder function operating in the RBQ scheme, the packets with higher QoS priority could be always forwarded first. The packets with lower QoS priority would not be forward until there is no higher QoS priority packet needs to be forwarded. Figure 3.5 is the diagram of DEQUEUE preemptive packet forwarder function.
Figure 3.5 Preemptive Packet Forwarder Function Diagram
4. Simulation Results Analysis
4.1 Simulation
It is impossible to implement the proposed RBQ scheme in a real UMTS core network gateway to obverse the performance of RBQ scheme. Simulation is a possible way to understand the operations of the RBQ scheme. Several simulation scenarios are simulated to illustrate the operations of the RBQ scheme in an UMTS core network. With the different RBQ scheme simulation scenarios, some transmission performance of UMTS background applications with the different role identifications could be obtained. Some simulation results would be analyzed in this study.
4.1.1 Simulation platform
The Network Simulator - ns (version 2.26) is used as the simulation tool. It is implemented on a PC based environment with an Intel pentium-III-1.3G CPU, 512MBytes RAM and a Linux RedHat 9 with kernel 2.4.x operating system. In order to simulate the RBQ scheme operations for background applications in an UMTS core network gateway, several C++ programs are coded to simulate UMTS background applications with different role identifications in ns2 simulator. Moreover, the RBQ scheme is implemented with a C++ program in ns2 simulator also.
4.1.2 Simulation topology
The topology of simulation is the same as the simulation in the section 3.1 (see Figure 3.1). A number of TCP/UDP traffic flows are simulated to transmit packets from the S1 and S2 source nodes, all traffic flows have the same routing path and share the same bandwidth from N1 node to N4 node, then reach the D1 and D2
The simulation topology is shown in Figure 4.1. There are three source nodes (S1 – S3) that are the senders of the UMTS background applications. Each source node would deliver packets of background application with different role identification to the corresponding destination (R1-R3). Two gateway nodes are implemented to set up a connection between the source nodes and destination nodes. The RBQ scheme is implemented in G1 gateway to regular the packets for UMTS background applications.
Figure 4.1 RBQS Simulation Topology 4.1.3 Simulation Scenario
Several simulation scenarios are proposed to simulate the RBQ scheme operations in different operation situations. With these scenarios, this study tries to understand the performance of the RBQ scheme. The simulation scenarios are described as the following.
z Scenario one: emergent event
This scenario describes an assumption that when UMTS users are in an emergent situation and they must deliver e-mail or transfer files immediately with an UMTS
background application. In such situation, an “emergency” role identification should be assigned to the packets of this background application. For example, a journalist wants to use his UMTS mobile device to e-mail his emergent and the latest news back to newspaper office as soon as possible.
z Scenario two: all-time overloaded traffic
This scenario would assume that there exists a heavy UMTS application traffic load in a department stores or a celebration party. In this situation, there is no queue buffer in an UMTS core network gateway. No packet would be allowed to enqueue the queue in an UMTS core network gateway. For example, people want to send SMS to each other to celebrate the New Year is coming in the Eve of New Year but the UMTS network system is overloaded and could not deliver the SMS for UMTS users at the time. In this simulation scenario, all background applications with different role identifications would keep sending packets during the 10 seconds simulation period.
4.1.4 Bandwidth settings
Since UMTS available bandwidth would depend on the moving speed of an UMTS user [11, 17], several bandwidth settings, such as 2Mb, 384Kb, 144Kb, are simulated between the two gateways (G1-G2). The bandwidth settings are listed in Table 4.1:
Table 4.1 Flow Bandwidth Configuration Table
(1) (2)
Note: (1) Total bandwidth of gateway, (2) Sets of simulation,
(3) Traffic type
4.2 Simulation result analysis
4.2.1 Definitions of Throughput and Packet Drop Rate
According to the proposed scenarios, several simulations were executed with ns2 simulator and several groups of data were also collected from the trace files generated by the ns2. This study tries to use throughput and packet drop rate as the evaluation criteria to the RBQ scheme. In order to understand the performance of RBQ scheme, this study codes several string process programs with UNIX awk utility to process the data in the trace files and get the information about the transmission throughput and packet drop rate that could be used to evaluate the performance of RBQ scheme.
About the two evaluation criteria, throughput and packet drop rate, their definitions
About the two evaluation criteria, throughput and packet drop rate, their definitions