Two-level scheduling scheme for integrated 4G-WLAN network

ABSTRACT


INTRODUCTION
Nowadays, obvious development of wireless networks such as Wireless Local Area Network (WLAN) and the Fourth-Generation network (4G) serve the humanity. WLAN provides high-speed wireless data over a small area based on the IEEE 802.11 standard and it is considered one of the main means to connect to the Internet [1,2] In contrast, 4G has adjusted for high-speed cellular networks with up to 300000 Kbps data rate over 20000 KHz bandwidth in a long distance radius and a low delay network less than 5 milliseconds [3,4]. WLAN is available in most offices, houses, cafés, etc while the 4G network is offered in most areas of cellular coverage. In the latest version of standards of WLAN and 4G, such as the IEEE 802.11ac/ad and 3GPP-Rel 12, numerous common strategies are applied to improve the performance of the system such as the use of Orthogonal Frequency-Division Multiple Access (OFDMA) and Multiple-Input and Multiple-Output (MIMO) [5]. The Quality of Service (QoS) support for a variety of applications is a common feature employed by both WLAN and 4G. QoS is defined as the ability of a network to offer distinguished services to a certain network traffic over others [6]. Scheduling scheme is one of the major factors to improve the QoS. The rapid increase in the number of end users burdens a network with more congestion and to solve this problem, a variety of techniques are required to manage resource distribution among different types of traffic. The 4G-WLAN converged network is an encouraging solution to accommodate the increased number of users in the Fifth Generation (5G). The 5G is composed of different network technologies: 4G, WLAN, Ethernet, Worldwide Interoperability for Microwave Access (WiMax), and so on. PQ has been modified to serve AT applications in a better way that ensures processing flows in short delay by adding rate control, which enables configuring the ratio of each priority queue. This modified queuing discipline is called controlled Priority Queuing (CPQ), which is presented in more details in Section IV. Deficit Round Robin Queuing (DRRQ) is a scheduling algorithm used to process the traffic in queues based on their weights, packet size, and counter. It supports the arbitration of output port bandwidth on high-speed interfaces in both the core and at the edges of the network. In this type of queuing, each queue is configured with various parameters: A weight is the ratio of the output port bandwidth assigned to the queue. A Deficit Counter specifies the number of allowed bytes for the queue to transmit when is visited by the scheduler. It permits the queue that was not allowed to transmit in the previous round because the value of DeficitCounter was smaller than the packet at the head of the queue to save transmission "credits" and use them in the next round [9,10]. A quantum of service is related to the weight of the queue and is expressed in terms of a number of bytes. The Deficit Counter for a queue is reduced by the quantum each time the scheduler visits the queue. If quantum [i]= 2* quantum[x], then queue i will get twice the bandwidth as queue x in case both queues are active.
IP Quality of Service (QoS) : Internet Engineering Task Force (IETF) has offered two approaches to provide the end-to-end QoS on IP: Integrated Services (IntServ) and Differentiated Services (DiffServ) [11]. IntServ has some limitations, so Diffserv has been projected to solve these limitations [12]. Four standards of Per Hop Behavior (PHBs) in Diffserv were identified by the IETF to offer different levels of classes in order to guarantee the QoS [13,14]. PHB is defined as the forwarding behavior that is identified to a Differentiated Services Code Point (DSCP), and states to packet scheduling and queuing or shaping the behavior of a node on any given packet. The four standards PHBs are Default Per Hop Behavior, Class-Selector Per Hop Behavior (CS), Assured Forwarding (AF), and Expedited Forwarding PHB (EF). Default PHB has characteristic of Best Effort service and it is dedicated to any packets that do not achieve the requirements of any other standards.

2635
CS PHB is used to maintain backward compatibility with network devices which still uses the Precedence field. AF is used to ensure a certain bandwidth, and there are four classes: AF1, AF2, AF3, and AF4. Each class has three possibilities of drop levels: high, medium, and low. EF is the last standard and it is used to offer low packet loss, low jitter, a minimum delay, and certain bandwidth service. Therefore, it is typically used for delay sensitive applications, such as Voice over IP (VoIP) [15,16].

PROPOSED METHODOLOGY
The proposed scheduling scheme is built to enhance the performance of the WLAN-4G integrated network. The object of this framework is to optimize network by getting acceptable packet loss and delay for AT applications and a reasonable ratio of packet loss for NRT applications. It is important to clearly define AT and NAT traffic or applications before presenting the details of this scheme. The AT traffic is the traffic that is very sensitive to time and delay, so time and delay play important role in using AT application successfully.
There is a precise required value for the delay and beyond this value, the traffic will not deliver properly. For example, Voice over IP (AT applications) has a specific value of delay, so in case of this value become higher than the rated level, the users might not be able to comprehend the communication. On the other hand, the NAT traffic doesn't care much about time or delay, therefore users can successfully use the NAT applications even if it takes a longer than predictable time. For instance, Email is an example of NAT traffic, the important point for users is to deliver and obtain the email and delay is not critical, as long as the e-mail successfully delivers to the destination. The proposed method is done by separating incoming traffic into AT and NAT through the classifier, and further using a different queuing scheme to split those traffic based on the type of service in two stages. In the first stage, Deficit Round Robin (DRR) queuing and Class-Based Queuing (CBQ) are used to deliver AT and NAT traffic themselves, respectively. Then to schedule and differentiate AT and NAT flows based on their category and the relevant assigned ratio of bandwidth for each class. To distinguish AT from NAT traffic classes, Control-Priority Queuing (CPQ) is used as the second stage by giving the AT flows an appropriate weight and higher priority as presented in Figure 2. Based on kind of traffic, packets are categorized into AT and NAT flows. Therefore, there are two queues, AT queue which includes sensitive to delay applications, such as interactive online gaming, voice, video while NAT includes low or non-sensitive to delays application. Then, each class is assigned diverse ratios of bandwidth to be scheduled. A higher ratio of AT bandwidth (Y %) is given to Average Sensitive Actual Time Traffic (ASATT) as shown in Figure 2. While the lower ratio of bandwidth (X %) is assigned to Extremely Sensitive Actual Time Traffic (ESATT) as compared with Y % since the ESATT class includes voice applications that need less bandwidth than do video applications. In case of AT traffic, Deficit Round Robin (DRR) is used in the first stage to differentiate and schedule AT flows based on their type and allocated ratio of bandwidth for each class. Both AT classes (ESATT, and ASATT) have many requirements, one of them is to be transmitted within a specific range of delay. Therefore, each AT class is set a certain weight of bandwidth, and these given bandwidths depend on traffic's characteristic that it serves and range of packet sizes. In DRR, weight for bandwidth in each class is represented by the number of bits instead of packets and a deficit counter is used to count precisely the assigned number of bits to be scheduled for each queue. The mechanism of DRR is to allocate weight for flows, represented as bits in the deficit counter. Thus, the deficit counter conducts a comparison between the head packet size in bits in flow with the assigned numbers of flows in the counter. The packet will be moved if the head packet's bit number is less than or equal to the number in the counter. If not, the packet will process in the next cycle. Since there are differences in flow weights and packet sizes, some flows are sent before others in each cycle. For example, the ESATT flow may be processed before the ASATT flows because ESATT flows process voice while ASATT flows process video application packets, which has large packet sizes [17].
The NAT applications are considered as non-sensitive to delay applications and include many types such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Email, .etc. Although NAT traffic is not sensitive to delay, each application has its own requirements. Therefore, a Class-Based Queuing (CBQ) is used to distinguish among different NAT traffic and to give each group of traffic an appropriate ratio of bandwidth. In this mode, NAT traffic is divided into two forms: Minor Sensitive Traffic (MST) and Non-Sensitive Traffic (NST). MST traffic preserves the higher ratio of bandwidth (A %) while NST traffic takes the lower one (B %). The object of allocating a higher bandwidth to the MST class is because it serves a number of NAT applications and many of them have a large packet size. In CBQ, each type of class will be provided by a minimum ratio of bandwidth in case of congestion [18]. For instance, if we assign A% and B% of bandwidth ratio for MST and NST, respectively, then A% of MST packets and B% of NST packets will be scheduled through the output port in each round of scheduling. In the last stage (second stage), Control-Priority Queuing (CPQ) is used as the gateway scheduler for NAT and AT flows. The CPQ is a developed scheduling scheme of PQ. In CPQ, packets are scheduled according to the priority level and a controller, which might be a percentage of bandwidth. The mechanism of CPQ is giving each AT application an appropriate level of priority to be scheduled over NAT application which depends on the ratio of given bandwidth and priority level. For example, ESATT has a superior chance to transmit and deliver over the other classes (ASATT, MST, and NST) because ESATT has a higher priority level. Nevertheless, if the ratio of bandwidth Y% is completely occupied, the scheduler will change to other types of traffic and goes back to HSATT. The scheduling scheme is illustrated in detail in Algorithm 1, and its flowchart is presented in Figure 3. In brief, the proposed scheme can provide the QoS requirements of the integrated 4G-WLAN network and make outstanding improvements for AT traffic (VoIP, video conferencing, etc.) and suitable changes for NAT traffic The weights percentage for bandwidth is adaptive to achieve the requirements of network customers [19].

PROPOSED SOLUTION
The Optimized Network Engineering Tool (OPNET) Modeler is a very common commercial product among the family of OPNET. It provides network modeling and simulation. In this paper, we used OPNET version 18.0-PL2. In order to represent the proposed modules, four applications were used in the simulation model: Voice over IP for HSATT; video conferencing for MSATT; File Transfer Protocol (FTP) for LST; and Hypertext Transfer Protocol (HTTP) for NST. PCM quality speech with G.711 encoder scheme was used for Voice over IP. To increase the congestion in the network, video conferencing parameter was configured at 30 frames/Sec with 2400 bytes for each frame. Also, to create further congestion in the network, a full load with a file size of 1.7 MB and an Inter-request Time of 5 sec were configured for the FTP application. For HTTP, heavy browsing with a page interval time of 65 Sec was set. Eight large images and 8 short videos were configured for HTTP. The default of buffer size in OPNET was set as 500 packets. The purpose of increasing the congestion in the network was to assess the network's performance in the worst case scenario. The converged 4G-WLAN network is composed of two networks, the 4G network, and the WLAN network, connected through an IP cloud as shown in Figure 4. In 4G side, four UEs were used, one of UE was set as a source call, another one has used a source of video calling, and the two others were assigned for HTTP and FTP. The eNodeB is connected to the backbone and gateway router through the 10 BaseT link. The gateway router is connected to the HTTP and FTP servers through the same type of link (10 Base T link). The LTE network was configured using following parameters shown in Table 1. While the WLAN side consists of four devices and one Access point (IEEE 802.11n ). Four UEs were used, one of them was set as VoIP client and connected to the VoIP calling in the 4G network and the second one was assigned as video client and connected to the video calling in 4G. The rest of UEs were assigned for HTTP and FTP. These devices were configured with the same parameters as devices on the 4G side. The access point was connected to the gateway router through the backbone. The network also connected to the FTP and HTTP servers through a gateway router to provide HTTP and FTP services Figure 4. In this summation, we conducted a comparison between two scenarios in order to test the proposed converged 4G-WLAN network. Scenario1was the baseline scenario, which is the well-known QoS scheme for AT applications; Diffserv with Priority Queuing. In, this scenario, different priority levels were assigned to different applications: the highest level of priority is given to VoIP (EF), then Video Conferencing (AF41), and then FTP (AF21), and finally the lowest priority was given to HTTP (CS0). For the 4G network (LTE), the Gold bearer (highest priority), the Silver, Bronze were assigned to VoIP, video conferencing, and the FTP and HTTP, respectively. Scenario 2 was the implementation of our proposed scheduling scheme, that included implementation in the converged 4G-WLAN network. In this scenario, we set the same priority level of Diffserv and QCI as in Scenerio 1 [20]. However, the proposed scheduling scheme was implemented based on allocated bandwidth ratios. The ratios of bandwidth were 16% for HTTP, 24% for FTP, 35% for video conference, and 25% for voice traffic. The simulation was run for 10 mins.

RESULTS AND DISCUSSION
In order to evaluate the effect of scheme on the converged 4G-WLAN network, different metrics were collected and analyzed such as Mean Opinion Score (MOS), end-to-end delay, jitter, and packet loss.

End-to-end delay
The end-to-end delay is one of the essential factors to evaluate the performance of the network. Each type of AT applications (VoIP, Video Conferencing, etc) requires the specified range of end-to-end delay which has to be less than the threshold assigned by Cisco and ITU. The threshold value of end-to-end delay for video and voice is 150 ms [21]. If the value of delay becomes higher than the threshold, the end user will notice a degradation in service. In this work, the end-to-end delay was collected for AT applications: video and VoIP.
The average end-to-end delay for Voice over IP and video interactive application for the PQD and the TLSS scenario are presented respectively in Figure 5 (a and b). Although the two lines of voice over IP are within the suitable range delay, the delay is decreased from 135 to 120 msec when the proposed scheme is implemented as explained in Figure 5 (a). The end-to-end delay line started with 129 msec and continue increased to stabilize around the 138 msec from the 300th second until the end of the test time. However, the line graph continued stable around 120 msec value along test time in the Voice over IP TLSS scenario. Values of delay are more stable in TLSS rather than PQD , and there is a slight decrease in delay was observed. This is expected result because the EF class granted a high priority for the VoIP application in the case of PQD and higher priority with certain bandwidth in case of TLSS (the proposed scheme). Figure 5 (b) demonstrates the average end-to-end delay (E2E) lines for video interactive application for both scenarios. It is obvious there was a major improvement in the average packet end-to-end delay for video. The value of E2E delay moved from the non-acceptable range (160 msec in the second 350 and 180 msec in the second 450) in case of the PQD scenario to an acceptable value (60 msec in the second 350 and 63 msec in the second 450) in the proposed scheme (TLSS). In summary, the E2E delay for the video was reduced by 61%. This is because a certain weight of bandwidth (35%) was assigned and given to the video packets by

2639
DRR and CPQ in case of the proposed scheme. In contrast, video packets in the PQD scenario were not guaranteed because the highest priority was given to voice over IP through the EF class while the video packets were given the second priority level through AF41. Therefore, the video can be sent through the queue only in case there is no voice packet in a queue. That means video packets might wait a long time in the PQD scenario [22].

Jitter
Jitter or Delay Variation is a major metric for AT applications because it plays an important role to determine the size of the best buffer for applications. The value of jitter for video and voice applications should be less than 30 ms, and 25, respectively [23]. Average packet jitter for voice over IP and video applications for the PQD and TLSS scenarios are presented in Figure 6. The figure shows that the values of Jitter for voice over IP in both scenarios are within the acceptable range. In the case of PQD scenario, the value of jitter delay was around 10 ms along the test time, but in case of TLSS scenario, the value started with 15 ms and then started to increase until reach to the value 23 ms at the second 180 and then stable at around this value throughout the test time. Even though the Voice over IP is assigned high priority level in both scenarios, but there was an increase in jitter values in case of TLSS. This increase is predictable because in case of PQD the scheduler will process all voice packets as long as there is a packet in the queue but in case of TLSS (proposed scheme), the scheduler is moved to schedule other applications when the whole assigned voice bandwidth is occupied as explained before. The packet jitter of the video interactive application for both sceneries is shown in Figure 7. In the case of the baseline scenario, jitter values increased gradually until it reached the value of 162.5 ms in the 400th second and then continued around this value along the rest of the test time. This happens because there is a positive relationship between the values of delay and test time, the number of packets is increased by forwarding the simulation time. Therefore, the delay variation of interactive video will increase, especially if a queue contains on voice packets. Yet, there is a significant improvement when the proposed scheme is applied. The delay reduced from 150 to 6 ms in the 300th second. When the proposed scheme is implemented, the delay was improved and moved from a non-acceptable to an acceptable range. The reason behind this remarkable improvement is because, in the PQD Scenario, the video packets has a chance to be delivered only if there are no voice packets in 6the queue while in TLSS Scenario, the chance for video packets to send is higher since the ratio of bandwidth is booked for video application. The quality of voice is measured by mea tric called Mean Opinion Score (MOS). The MOS is sca ale that starts with scale 1 and scscales. One means the lowest quality while five represents the highest quality [21].
If the value of MOS becomes lower than 2, then the voice becomes useless and the value is considered unacceptable by end users [24]. Figure 7 (b) shows the values of MOS for Voice over IP in case of the proposed scheme. In this simulation, G.712 codec scheme was used for the Voice over IP application. Based on the standard for G.712 codec, the desired value of MOS is 4. In TLthe SS scenario, the desired value was achieved as shown in Figure 8. The MOS value starts with 4 at the initial simulatino time, and then stable around 4.1 during simulation time.

Traffic loss for at applications
Traffic loss is the amount of lost traffic from the source to the destination. It usually measured in ratio, so the amount of lost traffic is divided on sent traffic according to (1).
Traffic Loss %= Source traffic-received traffic / Source traffic.× 100% (1) The average voice over IP traffic sent/received lines for the PQD and TLSS scenario in the WLAN-4G network are shown in the Figure 8 (a). It is obvious there is no traffic loss happened in both scenarios, the reason behind that because voice application has been given the higher priority in both scenarios. One of the voice application's requirements is that the traffic loss should be zero, so the proposed scheme achieved this main requirement. Average Traffic Sent/ Received of interactive video for PQD and TLSS scenarios are presented in Figure 8 (b). In the use of PQD scenario, traffic loss occurs for in stand, in the 700th second the value of sent traffic was around 108 Kbytes/sec while received traffic was around 80 Kbytes/sec. In other words, the traffic loss ratio of interactive was around 26% in the use of PQD scenario. This loss ratio is in the acceptable range for video applications based on Cisco and ITU [25]. This loss is because the interactive video was given the second priority level and it has not given any specific ratio of bandwidth, so the video packets are sent if and only if there are voice packets in the queue according to the mechanism of priority queening scheduler. In contrast, in case of TLSS scenario, traffic loss ratio is zero, so there is no drop in traffic because interactive video traffic has been assigned the highest ratio bandwidth (35%) with an assured priority level. That means the video packets are guaranteed to be delivered even if there is a ingestion in the network.   Figure 9-a shows the average FTP traffic sent/received per second for the PQ and the TLSS scenarios. As shown in Figure 8 (b), the values of traffic sent dropped at the receiver side throughout all the test time in case of PQ scheme. For example, the value of traffic sent were around 480 and 570 Kbytes/sec in the second 300th and 700th respectively, while the traffic received 365 and 490 Kbytes/sec at the same mentioned seconds. The traffic loss ratio was around 15-22%. However, the traffic loss ratio reduced remarkably when the proposed scheme is implemented. As presented in the Figure 9 (a), there is no major drop in traffic sent/received, the loss ratio was almost zero. For example, in the 700th second, traffic sent was around 490 h, however, the receivedraffic was around 488, so loss ratio was around 0-1%. The HTTP traffic sent/received for both PQD and TLSS scheme is shown in Figure 9 (b). In the case of the PQD scenario, there is a noticeable traffic loss during the test time. For example, the traffic sent were 50 and 62 Kbytes/sec in the 300th and 700th seconds, while the traffic received were 37 and 48 Kbytes/sec, in the 300th and 700th seconds, respectively. Therefore, the ratio loss was around 22-26%. Nevertheless, (TLSS), an improvement happened in traffic loss in case of the proposed scheme. For instance, in the 300th and 700th seconds, the traffic sent was 35 and 42 Kbytes/sec while the traffic received was 32 and 41 Kbytes/sec, respectively. That means, the drop range became approximately 7-9 % instead of 22-27%. This improvement occurred because this application was assigned certain bandwidth for this application to schedule the packets. Although there is a slight improvement in the traffic loss in the proposed scheme, the traffic was not stable and also traffic loss was not with acceptable value because this class was given the lowest level of priority and a small weight for the bandwidth. In case of increased congestion in the network, the higher priority is going to RT applications such as Voice and Video.

Throughput in the network
The throughput of the network is defined as the quantity of data rate that is produced by a network [26]. We collected two types of throughput: 4G Downlink Throughput and WLAN Throughput. The throughput of LTE and WLAN for both scenarios is shown in Figure 10. Based on this figure, the throughput of LTE and WLAN has been improved when the proposed scheme (TLSS) is implemented. For LTE Side, throughput increased from 3150 to 3420 Kbits/Sec in the 700th second as shown in Figure 10. Like throughput for LTE, throughput for WLAN side has also increased from 1650 to 1910 Kbits/Sec in the 700th. We notice also the throughput of WLAN in case of TLSS has not been improved in the first 50 seconds of the test time while it is increased and improved instantly for the LTE side.

Figure 10. Average throughput (Kbits/sec) for LTE downlink and WLAN for both scenarios
This occurs because there is no congestion in the first 55 seconds for WLAN while the congestion occurred at the beginning in the LTE network. The configuration of most applications was set to increase as the time passed. The scheduling in the PQD scenario could not reduce the congestion; on the other hand, the proposed scheme (TLSS) tried to alleviate the congestion. In other words, when the packet loss and delay are reduced, the throughput is increased. As a result, the throughput increased by 8.5% in (4G) LTE and 15% for WLAN. The improvement in throughput resulted from reducing in delay and packet loss when the proposed scheme was implemented. There is a relation between the throughput and traffic loss and delay. The (2) explains the relationship between and the data rate.
Where: R is data rate (bytes/sec), t is time (sec), is available Packets in queue multiplied by their size (bytes) According to (2), the relationship between P and R is in inverse e-relationship when assumed constant. Ideally, if the arrival rate equal to the data rate (R= ), it means there is no queue or there is no packets stored, in other words, the delay of packet queuing is equal to zero. Substituting (2) Based on (3), the data rate is in an inverse relationship with the queuing delay, meaning the service data rate increases when the queuing delay decreases.

CONCLUSION
In this paper, a scheduling scheme for a 4G-WLAN converged network have been proposed. The mechanism of this scheduling is to separate traffic based on their types into AT and NAT. The traffic crosses through the DRR in case of AT applications and CBQ for NAT. CPQ then transports the packets based on the allocated bandwidth and priority level. The proposed scheme has been applied in the 4G-WLAN converged network in order to improve its performance. Several metrics (end to end delay, MOS, Jitter, Packet loss, and throughput) have been collected to evaluate the performance of this converged network. Simulation results have presented obvious improvements for AT applications. The delay of ESATT traffic (e.g. VoIP) is in an acceptable range, and the value of MOS is in the "very good" score range. The packet loss of video applications (MSRTT) was reduced and became almost zero, so the delay improved by 61%. For NAT, the packet loss ratio changed from 15-22% to 1-zero for FTP and 22-26% to 7-9% for HTTP. Finally, throughput increased by 8.5 % for 4G and 15% for WLAN networks.