More DLC Topics: ARQ and Framing Wade Trappe

Lecture Overview ARQ Framing SW-ARQ GBN-ARQ SR-ARQ Character Framing Bit Stuffing

Automatic Retransmission Request (ARQ) The error correction discussed earlier might not be able to correct all errors and it is often reasonable to just detect a frame error and use ARQ to compensate for errors. The idea: Detect a frame error and “somehow” ask for the source to try again ARQ uses some error detection method (usually CRC), where a packet of k bits is turned into a n-bit vector “packet” So, there are 2k codewords but 2n possible n-bit messages Hence, there are 2n – 2k detectable errors Now, it is possible for errors to occur still a codeword can experience enough errors to turn it into another “wrong” codeword

ARQ, continued When looking at how to evaluate the performance of an ARQ protocol, there are several issues to evaluate: Correctness: Does the protocol actually release each packet once and only once (without errors? Technically without errors is not possible) Accepted packet error rate: P(E) = percentage of packets that are acceptable by the receiver that contain an error. (function of probability of undetected error) Throughput (efficiency): Average number of encoded data packets accepted by the receiver in the time it takes to send a single data packet (function of the # of retries).

P(E) Calculation Let us take a look at P(E) A packet is erroneously accepted if it contains an undetectable packet error pattern. Let Pe be the probability of an undetected error for a single transmission. Define q to be the probability of detecting an error. So, now we need to calculate the probability of an erroneous packet getting through Note: Pe is not 1-q. Why? Because q captures the probability there being an error AND detecting it. There is a third term (the probability of no errors) Pe Pe q Pe q q

Try… try… again… How do we finish this??? Thus, even though the probability of an undetected error is fixed, the probability of a packet error increases as we have more retransmissions Now, let us look at the average number of times that a packet must be sent before it is accepted: This gives us a sense for how a generic ARQ protocol will react to various noise levels. However, throughput is also strongly affected by “how” the protocol handles retransmissions How do we finish this???

Stop and Wait ARQ The Stop and Wait ARQ protocol involves the transmitter sending out a packet and waiting for an acknowledgement Once the transmitter sends out the packet, the receiver processes what it receives and responds with an ACK if the packet is error free, or sends a retransmission request (RQ) if it contains a detectable error Additionally, there may be issue that the packet may never arrive In this case, some form of “time-out” mechanism must be employed To begin, let us assume that all packets arrive

SW-ARQ t1 t2 t3 1 1 Idle time consists of three factors: 1 Time RQ0 ACK1 1 Idle time consists of three factors: Forward propagation delay t1 Error detection/processing time t2 Receiver response, back propagation time t3 Suppose transmission rate is D bits/sec, then the fact that we had a total time of (t1+t2+t3) seconds, this corresponds to D(t1+t2+t3) bits

SW-ARQ continued Now, let Ib= D(t1+t2+t3) bits Suppose that transmissions are necessary before the receiver accepts the transmitted packet. Each transmission involves (1) sending n bits (for k bits of information); (2) an idle period Then “bits”/ “efficiency” are needed in order to send k bits of actual information The total throughput is then Since the rate of an error detecting code is R=k/n, we have

SW-ARQ Wrapup This is the throughput when the packets always arrive Observations about SW-ARQ: Does not require extensive buffering at the transmitter or receiver A lot of time is wasted in idleness. Before we discuss how to handle issues of packets not arriving, or error-free feedback channels, lets look at the ideal cases of two other ARQ protocols

Go-Back-N-ARQ 1 2 3 4 5 1 2 3 4 1 2 3 4 5 1 2 3 4 t1 X X X X t2 t3 1 2 3 4 5 1 2 3 4 Time ACK0 ACK1 RQ1 ACK2 1 2 3 4 5 1 2 3 4 t1 X X X X t2 t3 Suppose the transmitter has the ability to perform some buffering The GBN-ARQ protocol has the transmitter sending packets continuously (trying to avoid idle time). When the receiver detects an error in a packet, it sends a RQ asking for a copy of that packet. All subsequent packets are ignored untul that packet arrives The transmitter “goes back” into its buffer and starts retransmitting from the lost/corrupted packet (i.e. all packets after the corrupted packet are also sent)

GBN-ARQ continued Observe that, in this picture, the sender was sending packet 5 when it received RQ1. Thus, there is a delay and a certain amount of buffer space is needed at the sender. The amount of buffer (N packets) is a function of forwarding delay, detection processing delay, and back propagation delay N is the smallest integer number of packets that contain Ib bits, i.e. Every retransmission causes a retransmission of N total packets: the required packet and the following (N-1) packets that were ignored by the receiver

Throughput of GBN-ARQ Let be the # of transmissions for a packet. Suppose we send a packet P and it goes through, then we get 1 packet of n bits However if p does not go through on the first time, but the second, then we have to send N packets for waste and an additional 1 packet, and so on… In general, we have is the number of packets sent on average to get 1 packet through.

GBN-ARQ Wrapup GBN-ARQ assumes buffering at the source, but not at the receiver. It is wasteful of resources at the receiver why ask for packets that have been received ok all over just because they arrive after a corrupt packet? The Selective Repeat ARQ (SR-ARQ) Protocol addresses this by introducing buffering at both the sender and the receiver.

Go-Back-N-ARQ 1 2 3 4 5 1 6 3 7 Time ACK0 ACK2 RQ1 RQ3 1 2 3 4 5 1 6 3 7 t1 t2 t3 Transmitter sends a continuous stream of packets, and responds to RQ by sending the requested packet. It then returns to the point at which it stopped and resumes transmission of new packets Each RQ deals only with one packet Throughput can be calculated as:

SR-GBN Wrapup SR-ARQ and GBN-ARQ use transmitter and/or receiver buffers. Clearly, the operation and size of these buffers is an issue You could select a large buffer size (but would be wasteful most of the time) You could try to switch to a back up protocol when buffer overflow approaches (e.g. use SR with GBN as a backup) Reading assignment: M.J. Miller and S. Lin, “The analysis of some selective repeat ARQ schemes with finite receiver buffers,” IEEE Trans. Comm., pg. 1307-1315, Sept 1981.

Errors and ARQ If the feedback channel is noisy, then an ACK may become an RQ or an RQ may become an ACK, or nothing might arrive Additional mechanisms that can be added to handle such problems: Each time the transmitter sends a packet, a timer for that packet is initialized. If a response does not arrive from the receiver in time (for that packet) it is assumed that the response is an RQ When the receiver sends an RQ back to the transmitter, the receiver initializes a timer. If a new copy of the packet is not received after a time, an RQ is sent again. If the receiver receives a packet that has already been accepted, an ACK is sent back to the transmitter and the packet is discarded ACKs or RQs are protected with their own CRC.

ARQ Reading Assignments Read Bertsekas and Gallagher’s discussion on Completeness and Correctness of ARQ protocols. Note: Bertsekas and Gallagher uses slightly different conventions Rather than return an ACK for the frame received, instead respond with a request for the next packet. That is, if we are dealing with packet n, then don’t send ACK-n, but instead send RQ-(n+1).

Framing Overview We return to the issue of framing. Recall that the PHY layer is providing a continuous stream of bits to the DLC. The period between packets still produces some effect on the PHY layer… the MODEM still tries to decide what bits were sent, even if nothing was sent Framing deals with the issue of demarking the boundary of a packet for the DLC to process. There are 3 types of framing: Character Based Framing: Uses control characters to fill idle time between packets, and to indicate the beginning/end of frames Bit Oriented Framing: Use bit strings (called flags) for idle fill and to indicate start and stop Length Fields: Use an above method, but include frame length in the packet

Character Based Framing ASCII: 7 bits plus 1 bit parity often parity is stripped in favor of CRC SYN is a communication control character A string of SYN characters provides fill for idle periods between frames when a single DLC has no data to send STX = Start of text. Indicates the beginning of a frame ETX = End of text. Indicates the end of a frame Basically, what results is the following SYN SYN SYN STX Header Packet ETX CRC SYN SYN The Frame

Character Based Framing, continued Seems pretty simple: you just look for STX and ETX But there is a problem!!! This only works if the data bits in the packet never include ETX. But what if the application is providing raw bits? You would stop early! In order to handle more general scenarios, character based framing operates in a special mode called transparent mode. Transparent mode uses a special control character called DLE. A DLE is inserted before the STX to indicate the start of a frame in transparent mode. A DLE is also inserted before intentional use of control characters (e.g. STX, ETX) in a frame, but not before data occurrences of such a bit sequence

Character Based Framing, pg 3 OK, so what if a DLE occurs as part of the bit sequence itself? Answer: If a DLE occurs in data bits then add a DLE in front of the “DLE” So, if you see a DLE… remove it to get what control character comes after it… if you see a pair of DLEs, remove one. Example 1: DLE ETX  ETX = End of Frame Example 2: DLE DLE DLE DLE  Data of “DLE DLE” Example 3: DLE DLE ETX  Data of “DLE ETX” Problems with this approach: Overhead: requires lots of DLEs in header Frames must be integer multiples of type char

Character Based Framing, pg. 4 Now look at what might happen in the presence of errors The CRC will check header and packet of a frame and will take care of those errors. But, what else may happen? Error on a DLE ETX (or just ETX if not transparent mode): no detection of end of frame and CRC will not be checked. Or, you go to next DLE ETX of next frame and the result is frame is lost. Error creates a fake DLE ETX: Result is following bits are interpreted as CRC and CRC will likely fail. Highly likely the frame will be dropped.

Bit Oriented Framing In transparent mode for CBF, the DLE ETX indicated the end. In bit-oriented framing, a “flag” will indicate the end of a frame. A flag is a known bit stream that ends a frame. Just like in CBF, where we doubled DLE’s, bit-oriented framing uses a technique called bit-stuffing to avoid confusion between appearances of the flag as data bits, and appearance of the flag as the true end of a frame. Here’s how it is done: 0160 = 01111110 is the flag When you get data: insert a “0” into the data string after each appearance of 5 consecutive 1’s Result: there is never more than 5 consecutive 1’s in data, and the flag is “unique” At the receiver: if we see 5 consecutive 1’s followed by a 0, drop the 0 At the receiver: if we see 5 consecutive 1’s followed by a 1, end the frame

Bit-Oriented Framing Example: Data in: 101111110 Data out: 1011111 0 10 What if we had 5 ones followed by a 0? 111110  11111 0 0