250 likes | 482 Views
More DLC Topics: ARQ and Framing. Wade Trappe. Lecture Overview. ARQ SW-ARQ GBN-ARQ SR-ARQ Framing Character Framing Bit Stuffing. Automatic Retransmission Request (ARQ).
E N D
More DLC Topics:ARQand Framing Wade Trappe
Lecture Overview • ARQ • SW-ARQ • GBN-ARQ • SR-ARQ • Framing • 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… • 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 • 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 0 0 1 Time RQ0 ACK1 0 0 1
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 0 1 2 3 4 5 1 2 3 4 • 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) Time ACK0 ACK1 RQ1 ACK2 0 1 2 3 4 5 1 2 3 4 t1 X X X X t2 t3
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 0 1 2 3 4 5 1 6 3 7 • 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: Time ACK0 ACK2 RQ1 RQ3 0 1 2 3 4 5 1 6 3 7 t1 t2 t3
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