We discussed rather studied about stop-and-wait ARQ, Go-back-N ARQ and selective repeat ARQ. We found another ARQ called HARQ. It is a technique that enables fast recovery from transmission errors in wireless networks by storing defective packets and then combining them with subsequent retransmissions of the same packet.
In standard ARQ, cyclic redundancy check (error-detection information, ED) bits are added to data to be transmitted. In Hybrid ARQ, forward error-correction (FEC) bits are also added to the existing Error Detection (ED) bits (such as Reed-Solomon code or Turbo code). As a result Hybrid ARQ performs better than ordinary ARQ in poor signal conditions, but in its simplest form this comes at the expense of significantly lower throughput in good signal conditions. There is typically a signal quality cross-over point below which simple Hybrid ARQ is better, and above which basic ARQ is better.
The simplest version of HARQ, Type I HARQ, adds both ED and FEC information to each message prior to transmission. When the coded data block is received, the receiver first decodes the error-correction code. If the channel quality is good enough, all transmission errors should be correctable, and the receiver can obtain the correct data block. If the channel quality is bad, and not all transmission errors can be corrected, the receiver will detect this situation using the error-detection code, then the received coded data block is discarded and a retransmission is requested by the receiver, similar to ARQ.
In a more sophisticated form, Type II HARQ, transmits only ED bits or only FEC information and ED bits on a given transmission, typically alternating on successive transmissions.
This ARQ has been used in many areas. Recent one we came across is the Beceem Commmunication.
Beceem Communications has announced that the company has successfully completed HARQ demonstrations exceeding a sustainable throughput of 20Mbps, operating the chipset in ‘Category 4′ HARQ mode (the highest performance HARQ mode in the WiMAX Forum Profile). This milestone was achieved shortly after Beceem established the speed record for Mobile WiMAX when demonstrating 33 Mbps application layer throughput in MIMO mode.
In our presentation, we showed how to stay anonymous using proxy while browsing the internet. This video shows how to detect if the website visitor is using anonymous proxy.
STOP AND WAIT
Design and Implementation
Assumption: Error free communication channel
The sender in this protocol simply retrieves a packet from the network layer, copies it into a frame, and then transmits it. After transmission, the sender busy waits until an acknowledgement is received from the receiver, then the loop starts over again.
The receiver simply busy waits until a frame is received. Once a frame is received it passes the data packet to the network layer and sends an acknowledgement for the frame it just received. It then loops back to busy waiting and the process continues until the End of File is reached.
In this protocol, there can only be one outstanding frame at a time so no sequence numbers are required and the acknowledgement the receiver sends back to the sender is nothing more than an empty frame, as there is no other possibility then acknowledging the only frame sent. Another frame will not be sent until this acknowledgement is received.
Performance
The Stop and Wait protocol was very easy to implement and runs very quickly and efficiently. It solves the problem of congestion, as only one frame is outstanding at any time, frames cannot be lost due to congestion and the receiver will not be swamped by the sender.
Point of failure
The problem with it is that it assumes an error free communication channel and in the real world, such a channel does not exist. It is easy to see that if a frame or an acknowledgement gets lost or damaged, a deadlock situation will occur where neither the sender or receiver can advance, and they will be thrown into infinite loops.
Problem 1: While demonstrating the CC proxy in the lab we needed the wireless connection (we wanted the laptop ethernet port to be empty so dat we connect the client laptop via the ethernet wire) which was not available in the lab.
Solution:
To get the wireless connection, we had to connect the MSRIT server to a router and use the wire less connection provided.
Problem 2: The computer lab server also had a firewall which did not allow us to enter into a few sites.
Solution: Had to search for proxy sites which were not blocked by the MSRIT server (trial and error method)
Problem 3: We worked on many other tools before settling with cc proxy like filezila, allegro surf, cute FTP and delegate. The read me file was of little guidance so could not configure it.
Solution: Still working on the FTP part, will present it along wid part B project.
Recent Comments