Chapter -6 IMPROVED CONGESTION CONTROL MECHANISM FOR REAL TIME DATA TRANSMISSION

Transcription

1 Chapter -6 IMPROVED CONGESTION CONTROL MECHANISM FOR REAL TIME DATA TRANSMISSION

2 Chapter 6 IMPROVED CONGESTION CONTROL MECHANISM FOR REAL TIME DATA TRANSMISSION 6.1 Introduction Supporting Quality of Service (QoS) is a very important parameter during message transmission in real time scenario. Many routing protocols for Mobile Adhoc Network (MANET) Supporting Real Time Applications have been developed that uses improved Real time framework for optimization of delay and power techniques, basic intention being extreme utilization of resource in resource limited environment, minimum power consumption using restricted residual battery power of the highly transferrable mobile stations. Here we discuss the issue of queuing delay during routing in the MANET and propose an improved technique to minimize delay based on congestion control by presenting an enhanced leaky bucket algorithm called Real-time Leaky Bucket (RLB) that avoids congestion at a node by regulating the burst flow of incoming packets using separate queues for real time and best effort packets. In case of congestion real time packets are given higher priority than the general packets hence avoiding congestion. 6.2 The Proposed Design In this research work, we have designed a QoS platform for congestion control at the transport layer which maintains handshaking approach with optimized Power and Delay AODV Protocol called PDO AODV at the network layer. A superior channel access mechanism has also been designed in the MAC layer for real time application prioritization and resource reservation that interacts with the improved AODV protocol based on a cross layer design foundation. Fig.6.1 shows the basic architecture of our proposed QoS platform with congestion control mechanism at the transport layer. In this paper we have elaborated functionality of the improved congestion control algorithm for real time applications. 99

3 Fig.6.1: Basic architecture of our proposed QoS Platform. While sending a video file during a multimedia application, the corresponding audio and video frames after being converted to packets and sent to the destination over a network. In a packet switched network, some packets sometimes get delayed due to congestion at various nodes. Therefore queuing delay takes place while the packets traverse through various routes. If the packets traverse through the same route, then also at specific nodes delay occurs depending on routing strategy of those nodes and sometimes due to processing complexity. Fig.6.2: Real time platform for video file transmission Fig.6.2 describes the new QoS mechanism employed in our scheme at every intermediate node during transmission of video file from a source to destination. At the intermediate node to control the congestion of traffic and to reduce the queuing delay an 100

4 enhanced RLB algorithm has been proposed which is explained in the next section. When a particular frame is being played during which few preceding frames arrive to the destination, that recently arrived frame is unnecessary so it will be discarded. Therefore, if a frame gets delayed by few seconds, then it is deleted by the receiver side instead of any processing done on it. Hard real time task provision is applicable on computer games, which are not safety critical, as a result of which if the time constraint is not satisfied, due to time mismatch of few nanoseconds, the game gets halt. 6.3 Queuing Delay in Real Time Transmission According to queuing theory, each node or station or router is called a queue and each packet is known as a job. A queue has a processing location and a memory buffer (or queue) where all the jobs wait before getting processed. According to the queuing policy (algorithm such as FIFO, FIFO etc) adopted by the queue and the packet execution time, the performance of that queue can be known. Throughput and delay performance can be measured by parameters such as type of packet, length of the packet, queuing policy and memory size at the queue Sources of Packet Delay Fig.6.3: Four sources of packet delay [181] As the figure 6.3 shows there are basically four sources of packet delay. Nodal processing delay At the node, the error bit pattern is checked for possible corruption of bits in the received data. The output link is checked as per the QoS requirement if it suits for specific bandwidth or not. Queuing delay This is the time taken by the packets to wait for their turn to come to be transmitted by the router. This delay is directly proportional to the congestion status of the router. Transmission delay If L is the length of the packet and 101

5 R is the bandwidth of the link in bps (bits per second), then transmission delay = L/R Propagation delay: Let d= length of the physical link, and s = propagation speed in the medium, then propagation delay = d/s Packet Loss Fig.6.4: Packet Loss in Queue Overflow [181] Fig.6.5:Packer drop due to queuing delay [181] Fig.6.4 explains that a buffer at a router has limited capacity, when many packets from different sources and different traffic reach at the buffer, and if the buffer is full at that time, then the packets are simply discarded resulting in packet loss. These lost packets are again re-transmitted upon request by the receiving side or as per the congestion control algorithm regulation. Therefore we have reduced the queuing delay of the real time frames at the node entry point using load shedding technique.fig.6.5 describes that When the rate of arrival of packets to the queue of the receiving node exceeds the rate of transmission of the link, for a particular period of time, the packets are queued while waiting to get transmitted and gradually when it gets late start to drop, lost in the medium without being received by any receiver, as their memory is already full. Fig.6.6: Queuing delay due to waiting [181] 102

6 As the above fig.6.6 shows when the incoming packets from the source arrive to the router memory buffers, if the rate of packets arrival, is more than the output link capacity, then the left out packets remain in a queue waiting their turn to come. In such case, queuing delay occurs. When a satellite captures pictures of an opponent territory and beams it to a ground station computing device sequence of frames, the base station computer executes all the frames to search the positional difference of objects that comes across in the preceding frames to examine the activity of the opponent enemy. In this case if the base computer gets overloaded, then while processing task of current frame is not over, another frame has already reached to the buffer. In such firm real time task, the associated time bounds typically ranges from a few mili seconds to several hundred mili seconds. 6.4 Real Time Leakey Bucket Algorithm with Congestion Control When number of packets sent to a particular network or sub-network is higher than the network capacity then it exceeds the link capacity, hence congestion takes place in the network. It is very much similar to a congested traffic scenario on a rushed road, as a result of which the performance of network slows down. The leaky bucket algorithm for congestion control has a bound on output flow through a bucket which has a hole, hence the water leaks in constant rate irrespective of the burst heavy incoming water flow. When there is no input, the system remains idle. The source inputs one packet per a single clock tick to the network. As in case of ATM (Asynchronous Transfer Mode) cells in case where the packet size are all same. In case of different packet size, it allows fixed number of bytes at a time, it may be fraction of a packet. This maintains uniformity in output traffic without heavy congestion. Fig.6.7: Functional Block diagram of proposed congestion control 103

7 Fig.6.8: Block diagram of RLB(Realtime leaky bucket ) But to have prioritized flow for real time applications we have designed improved congestion control mechanism, the functional block diagram of which has been presented in fig Detailed block diagram of our proposed Real time Leaky Bucket Algorithm has been presented in fig.6.8. Instead of a single burst flow of traffic coming to the bucket buffer, we have two parallel incoming flow, one for Real time and the other one for Best effort packets. When the queue at the router is full, the Best effort packets from the corresponding queue will be discarded and not the real time packets. Similarly there are two separate output flows for real time and best effort packets. The output bit rate remains constant but high constant rate for real time traffic and low constant rate for normal traffic. In this way prioritization of video files and other multimedia data traffic has been done ensuring improved real time data throughput in the network. This section of the research work focuses on one of the vital issues during real time data transmission in Mobile Adhoc Network. It solves the the challenging problem of queuing delay at the intermediate nodes and the congestion control strategy during multi-hop communication by offering an improved algorithm called Real Time Leaky Bucket for smooth control of incoming as well as outgoing traffic at the entry point of nodes. Using simulation results in a highly mobile environment, we have justified that the proposed scheme performs better in terms of congestion control and reducing queuing delay and in our future work we have planned 104

8 to implement our algorithm in real platform and to check the other related issues such as reliability and security while implementing the new proposal. 6.5 Improved Real Time Token Bucket Method Under open loop congestion control policies the re-transmission policy is important which is used when the sender feels that a sent packet is lost or its bits have been corrupted, and then it re-transmits the packets. This is one of the conventional ways which faces the issue of delaying in data transmission in window policy. The selective repeat window flow control policy is used than the go-back n windows policy for congestion control. Then there is an acknowledgement policy, in which a receiver may send an acknowledgement only if it has packet to be sent or a specially programmed timer gets expired, other cases it will not send an acknowledgement. It prevents congestion by not sending too many acknowledgement packets which create congestion in the traffic. In discarding method, the routers discard some packets randomly without any basic criteria simply to avoid congestion that can be retransmitted at a later stage. In admission method, there are different switches that regulate the flow by checking the resource requirements before admitting it to the network. Hence this way avoiding chance of congestion in future. The provision of back pressure technique is a controlling mechanism of congestion in which a congested node does not receive any data from its immediate upstream node. The provision of back pressure technique is a controlling mechanism of congestion in which a congested node does not receive any data from its immediate upstream node. Another Choke Packet method is used in which a package sent by a node to the source regarding the event of congestion, so that the source pauses for some time without continuously sending the packets, and it starts when the congestion at that particular node is under control. When there is no communication between the congested source node of the data transmission, the source assumes that a congestion event has occurred, so it stops sending more packets in this path and does not wait for receiving acknowledgement. This method is called implicit signalling. Similarly, in explicit signalling concept, the congested node explicitly sends a signal to the source computer. Congestion control also influences the Quality of Service during transmission which is a set of services that should be supported by a network, while transporting a packet from source to destination. By controlling and maintaining the flow characteristics of traffic, QoS can be achieved. The basic 105

9 characteristics of a flow are Reliability, Delay, Jitter and Bandwidth. Bandwidth is an important parameter which is considered during video and multimedia data transmission. Different applications need different bandwidths. In video conferencing we need to send millions of bits per second to refresh a color screen while the total number of bits in an e- mail may not reach even a million. 6.6 Improved Congestion Control In this section the congestion control technique has been discussed with prominence on shaping the traffic with improved token bucket based technique for real time applications. Fig.6.9: Basic architecture of our proposed policy Fig.6.10: Functional Block diagram This method checks the incoming traffic flow and streamlines it before inflowing to the network. The proposed method controls the rate of sending flow of traffic by introducing a set up time ( t) decided by negotiation among the sending station and the carrier which decide a traffic pattern. In Real Time Token Bucket (RTB) algorithm, there are two types of tokens generated by the system and the bucket holds the token. To transfer a packet, a station has to seize one token of its application type and delete it. As shown in fig. 4, the tokens are produced by the system at a rate of one token in every t second. 106

10 Fig.6.11: Token Bucket Mechanism According to our proposed Improved RTB (Real Time Token Bucket), in every alternative unit time, real time token and best effort tokens are produced. Stations which currently do not have anything to send, can capture the tokens and preserve for future transmission purpose when they have higher bursts of flow. But it is limited to extreme size of the bucket. Fig.6.12: Block diagram of RTB (Real Time Token Bucket) Leaky bucket discards the packets, but packets are not discarded in our proposed method RTB.Using RTB, a packet can only be communicated only if there is sufficient tokens to shelter its length. Leaky bucket directs the packets at an average constant rate. But improved RTB permits for bigger bursts to be sent quicker by more rapidly sending up 107

11 the output. RTB allows redeeming the tokens (authorizations) to send bulky bursts, which are not allowed in Leaky Bucket. 6.7 Performance Improvement in the Proposed Approach Leaky bucket algorithm has some limitation such as it does not profit a host that does not have anything to send. When a station has nothing to send, then its bucket turn into empty. In such case, if a station has burst data, there will be average data flow in leaky bucket. But the idle period in which the station was silent, will not be taken into account. But in token bucket algorithm, it is allowed for the silent stations to gather the acclaim for future in the means of token. For every clock tick, the system transmits n token to the bucket. This method eliminates one token for every bite of data transmitted. It can be understood that a station can transmit burst data s long as the bucket is not empty. As shown in fig. 6.4, the token bucket method can use a counter for implementation. As per our improved proposal in Token Bucket Algorithm for real time applications, there are three components, i.e. Interface Queue Real Time Token Queue and Release Queue.The Interface Queue receives the packets at a fixed rate, stores then as per SJF (Shortest Job First) scheduling method, and waits for the token bucket to fulfil the required tokens. When there are many tokens for one packet, it sends them to release queue and deletes those tokens which are already used. The server processes the received packets from the release queue in its own fixed rate. Every queue and the buckets have their own processing rate and the bucket of tokens has a fixed rate to store the tokens without overflow. Functionality of our Improved Real Time Token Bucket Method is explained in following algorithm. The algorithm consists of a bucket with a maximum capacity of N tokens which refills at a rate R tokens per second. Each token typically represents a quantity of whatever resource is being rate limited (network bandwidth, connections, etc.)this allows for a fixed rate of flow R with bursts up to N without impacting the consumer. 108

12 Fig.6.13: Code for consuming tokens Fig.6.14: Code for checking bucket capacity In this approach the output rate from release queue varies depending on the size of the burst flow. The bucket holds the token to transmit a packet, The clock timer produces the tokens one token in every t second. Silent stations with nothing to send currently, can capture and save in a later stage for transmitting large bursts. This method is Real Time token dependent. If the bucket becomes full, then the RT Tokens are discarded, and not the packets. When number of tokens is more, then the packets can transmit. Large burst flow can be sent quicker. Leaky bucket and token bucket concepts are merged in our approach. The two techniques have been combined to credit an idle host and at the same time regulate the traffic. The leaky bucket is applied after the token bucket; the rate of the leaky bucket needs to be higher than the rate of tokens dropped in the bucket. This part of the research work focuses on one of the vital issues during real time data transmission in Mobile Adhoc Network. It solves the challenging problem of queuing delay at the intermediate nodes and the congestion control strategy during multi-hop communication by offering an improved algorithm called Real Time Token Bucket for smooth control of incoming as well as outgoing traffic at the entry point of nodes. Using simulation results in a highly mobile environment, we have justified that the proposed scheme performs better in terms of congestion control and reducing queuing delay and in our future work we have planned to implement our algorithm in real platform and to check the other related issues such as reliability and security while implementing the new proposal. 109

13 6.8 Simulation and Results Network Simulator NS 2 is used for simulation and the and the simulation parameters are as given in Table1.We have simulated our approach with Optimized AODV protocol as part of the QoS architecture. Table 1 shows the network parameters considered during the simulation. Table 6.1: Simulation Parameters Parameter Name Parameter Value Channel Type Wireless Channel Radio Propagation Model Two Ray Ground Network Interface Type Wireless Phy Type of Traffic V B R Simulation Time 2 Minutes MAC Type Mac/802_11 Max Speed 50 m/s Network Size 1600 x 1600 Mobile Nodes 120 Packet Size 512 Kb Interface queue Type Queue/Droptail Protocol PDOAODV with RTB Simulator Ns2 Jitter can be termed as the variation is delay during packet arrival from source to destination. For real time packet delivery if there is non-uniform delay during packet arrival time, then the video streaming problem occurs during a video display. Fig.6.8 shows the comparison of jitter in video file transmission during packet arrival which has been calculated considering packet arrival time for different segments during the simulation process. Awk script has been used to extract the delay information from the output trace file that is generated after the simulation. 110

14 Fig Comparison of Jitter From fig it can be depicted that our proposed congestion control approach RT2B with PDO AODV protocol exhibits lesser delay between packet arrival with better jitter performance than the TBTS (Token Bucket Traffic Shaping) with AODV protocol in MANET. Fig.6.16 shows the comparative graph between the Token Bucket Congestion Control with Traffic Shaping and Our Proposed Improved RTB in terms of Packet Delivery Ratio(PDR) It clearly shows that our approach has a higher PDR percentage in a highly mobility scenario. Fig.6.16: Comparison of Packet Delivery Ratio(PDR) 111

15 Fig.6.17: Delay Comparison Fig.6.17 depicts that due to improved congestion control mechanism in our approach, the average delay in packet transmission reduces up to a greater extent in our approach. The above part of our research work concentrates on one of the dynamic concerns in real time data transmission in Mobile Adhoc Network. It resolves the stimulating difficulty of congestion due to queuing delay at the router interface during routing by proposing an enriched process called Real Time Token Bucket for fascinating control of inward as well as outbound traffic at the access point of the stations. This mechanism performs fantastically when embedded as a part of our original Multi-Layer Communication based QoS architecture. In our future work we have scheduled to device this procedure in real podium and to focus on the other related technical issues including performance appraisal under variable parameters. 6.9 Summary This research article focuses on one of the vital issues during real time data transmission in Mobile Adhoc Network. It solves the challenging problem of queuing delay at the intermediate nodes and the congestion control strategy during multi-hop communication by offering an improved algorithm called Real Time Leaky Bucket for smooth control of incoming as well as outgoing traffic at the entry point of nodes. Using simulation results in a highly mobile environment, we have justified that the proposed scheme performs better in terms of congestion control and reducing queuing delay and in our future work we have planned to implement our algorithm in real platform and to check the other related issues such as reliability and security while implementing the new proposal. 112