Comp [34]49 Week 6, Oct 2, LT 412 Week 6: Block code: k data bits => n-bit block. Sometimes we can identify n-k check bits, separate from the data bits. Syndrome word: n-k check bits as received XOR n-k check bits as recalculated Cyclic codes nature of cyclicness use of CRC: have k data bits and get n-k code bits using mod2 division D = message, P = divisor polynomial of length n-k+1 D/P = Q + C/P, C = check bits of length n-k T = transmitted message = D ^ C = D<<(n-k) + C Suppose what we receive is Z = T + E Syndrome S = Z mod P (that is, the remainder upon division by P) Fundamental fact (p 211-212): ** S depends only on E ** Proof: Z/P = B + S/P = T/P + E/P = Q + E/P We have S/P = E/P + polynomial single-bit rule: n <= 2^(n-k) - 1 double-bit rule: n + n*(n+1)/2 <= 2^(n-k) - 1 (what are we counting?) Example 8.8: divisor polynomial P = 1101 = x^3 + x^2 + 1 Table (a): data => codeword = data^000 + (data^000 mod P) Table (b): for each of the seven error patterns E, find the syndrome S = E mod P This is 1-1, so given a Syndrome we can look up E, and use E to correct T. This is optimal, in that there are only seven *possible* nonzero syndromes, and we do get them all. ============================ BCH: overview Establish result for row 2: all Sn = En/P are distinct, P=10011 Homework: Rows 3 and 4. For row 3, t=2, there are 15*14/2 = 105 possible E. For row 4, t=3, there are 15*14*13/3*2 = 455 possible E. You are to calculate E/P = S for all possible E in each case, and establish that no two S's are the same. All possible E: all length-15 bitstrings with: row 3: either 1 1-bit (15) or 2 1-bits (105) row 4: Number of 1-bits: 1 (15), 2 (105) or 3 (455). There is a sample method for generating all E with three 1-bits in tester.java. To verify that all the S are unique, you can create an ascii file of them, sort it, run the unix command uniq on it, and verify that the file is the same. Program 2 outline: Do row 2 of Stallings Table 8.5, p 214: n=15, k=11, t=1, P=X^4 + X + 1, or 10011 E 000000000000001 000000000000010 000000000000100 000000000001000 000000000010000 000000000100000 000000001000000 000000010000000 000000100000000 000001000000000 000010000000000 000100000000000 001000000000000 010000000000000 100000000000000 E, S sorted by S: 000000000000001 0001 000000000000010 0010 000000000010000 0011 000000000000100 0100 000000100000000 0101 000000000100000 0110 000010000000000 0111 000000000001000 1000 100000000000000 1001 000001000000000 1010 000000010000000 1011 000000001000000 1100 010000000000000 1101 000100000000000 1110 001000000000000 1111 syndrome == 0: no errors 2^(n-k) - 1 >= n LHS = # of syndrome values indicating error RHS = # of possible bit-positions in error Note that in the above example 2^(n-k)-1 = 2^4-1 = 15 = n Try with the following polynomials: 10011 11001 10001 10101 Mathematically, we're saying all the Ei - Ej (Ei xor Ej) are not divisible by P =========================================================================== Block interleaving: Fig 8.8 example: Choose m = "interleaving factor" Collect k*m bits. put in table by rows. Extend each row to lenght n by using the (n,k) block code Now transmit n transmit-blocks, each of length m: the COLUMNS Burst errors will be spread out. Big m: burst errors are spread way out, BUT we have a significant "buffer delay" ====================================================================================== ====================================================================================== MAC protocol Last time: basic p-persistent backoff algorithm slot times backoff range: 0<=backoff<=15 Diagram: AbsPg 89 Retry backoff: 15, 31, 63, 127, 255, 255, 255 Used whenever we want to send and find the medium busy! Even on first try! When we suspend the backoff clock, we wait for a full DIFS idle after the transmission before resumption slot times SIFS, PIFS, DIFS, EIFS SIFS: minimum "turnaround" time from transmit to receive mode use of EIFS: when a corrupted frame is detected To send an ACK (all frames): wait SIFS, then send Applies only to frames addressed specifically to you; you should be the only ACK sender NAV: each station, on detection of any frame, sets a timer for when the medium *should* next be idle. This works even if part of the reason for non-idleness can't be received directly. Estimate of non-idleness can be length of current frame, or sometimes much longer (eg RTS/CTS, next; NAV is set to end of frame the other sender has just requested to send) RTS/CTS: RTS is sent as a regular packet All other stations hold off for EIFS (this is the NAV period) Receiving station sends CTS after SIFS Physical v Virtual carrier sense when a station transmits, maybe not all others can hear it! But when a RTS or CTS is seen, stations ASSUME that someone else will be transmitting. Hidden node problem: =================== A AP B A and B cannot see each other. What if A wants to send? B can't hear A's transmission in progress. RTS/CTS solution: A sends RTS; B can't hear it AP sends CTS, B *can* hear this RTS and CTS both contain estimated length. Once RTS is sent, if it is received reliably (no collision) then the transmission will follow immediately. Use of RTS/CTS and packet size threshold PCF v DCF Above is "Distributed Coordination Function" There is also "Point Coordination Function", in which the AP manages who gets to send when. Deferred for now. Create notion of "superframe": interval between beacons superframe begins with Contention-Free Period (CFP), followed by the usual Contention Period (CP). See IEEE, AbsPg 102 During CFP, the AP polls "registered" stations for traffic, which they send. AP uses PIFS (medium IFS interval) Before CFP can start, the AP must gain access, using the usual contention process. Note that AP gets to use PIFS though, so all it really has to do is wait for the end of the current transmission Beginning of CFP: AP sends Beacon Frame (possibly without ESSID) Beacon Frames perform time synchronization Problems: (some addressed in 803.11e) no standard prioritization of frames beacon delays are unpredictable contention period is not of fixed length; timing in CFP may not be precise CFP can be several beacon-frame times IEEE 9.3.3.2: mechanisms to allow overlapping BSS's 9.3.3.3: CFPMaxDurationLimit ================================================================================== How else might you reduce contention? Token passing brief outline IEEE gave up on this in 1990! One problem is that, while you can define ways for stations to join the network, overlapping BSSes can mean that each BSS sees lots of "unregistered" traffic. Another problem (always) is that someone has to monitor for stations that disappear. Another problem is that, with lots of stations and light loads, the waiting-for-a-token latency is high. ==================================================================================