Cẩm nang dữ liệu không dây P13 doc

IV SOME PRIMITIVE TECHNICAL CONSIDERATIONS The Wireless Data Handbook, Fourth Edition. James F. DeRose Copyright © 1999 John Wiley & Sons, Inc. ISBNs: 0-471-31651-2 (Hardback); 0-471-22458-8 (Electronic) 203 13 UNDERSTANDING AIRTIME PROTOCOLS 13.1 THE PACKET REVISITED A packet is the information unit formed when a message is partitioned into more manageable sections for transmission and recovery. Most landline packets have three logical subsections created when control information is added to user data (Figure 13-1). Packets are not required to travel only on packet switched networks. They function quite nicely on circuit switched systems as welloften a source of confusion for persons first encountering adaptive packet assembly in Microcoms protocols sent over circuit switched facilities. Since February 1997 GTE Wireless has offered CS-CDPD 1 (circuit switched CDPD), which enables CDPD users to transmit packet data over existing circuit switched networks. 2 To grasp the principle of the packet, the most common form of landline implementation will be discussed first. It is possible to transmit landline packets over radio links, as is routinely done in data over cellular. As bit rates rise, however, error- checking codes become less satisfactory and are usually augmented with error correction codes. These differences will be explored second. 13.1.1 Message Segmentation: The Flag When the user message is partitioned into packets, a reserved separation character called the flag marks both the beginning and the end of the packet (Figure 13-2). The most common flag implementation, found in such diverse protocols as SDLC/HDLC, MNP, and CDPD, is the 8-bit sequence 01111110. In these protocols the flag is one of three reserved patterns. The flag can also be manipulated in hardware by a technique known as bit stuffing, which permits data transparency. These special variations will be discussed shortly. The Wireless Data Handbook, Fourth Edition. James F. DeRose Copyright © 1999 John Wiley & Sons, Inc. ISBNs: 0-471-31651-2 (Hardback); 0-471-22458-8 (Electronic) 13.1.2 Address Field The field following the flag is the address. Its minimum size is 8 bits, which yields only 256 unique addresses. In practice, address fields are very much larger, leading to the use of complex surrogate techniques to reduce the associated transmission overhead. One trivial technique is to uniquely identify the source or destination address depending upon the function being performed. Using balanced address rules (unbalanced rules also exist), the field specifies the destination for commands; the same field specifies the source for responses (Figure 13-3). 13.1.3 Control Field Following the address is a tightly packed field that defines the functions to be performed (Figure 13-4). The information format controls the transmission and Figure 13-2 The flag. Figure 13-1 The packet. 204 UNDERSTANDING AIRTIME PROTOCOLS Figure 13-3 The address field. Figure 13-4 The control field. 13.1 THE PACKET REVISITED 205 acknowledgment of end-user data, along with a poll to solicit a status response. The supervisory format controls requests for retransmission; the unnumbered format controls initialization and disconnection. In the single-octet implementation there is room enough for the information format to track the sequence numbers of seven separate packets on both the send and receive sides. When the inbound response is unpredictable, as in CDPD, this field is expanded so that 128 packets may be outstanding in each direction. 3 13.1.4 Information Field User data is optional and is only associated with the information format. The information field follows the control field and can be variable in length up to a defined system limit. The greater the length of the information field, the more vulnerable the packet is to error and subsequent retransmission. CDPD defaults vary by carrier. ARDIS (RD-LAP) and BSWD have 512-octet maximums. This does not imply that the message length is limited to 512 bytes. It simply defines the maximum size of each segment of a multisegment message. Figure 13-5 Bit stuffing. 206 UNDERSTANDING AIRTIME PROTOCOLS Usually the information format is transparent: Any format is legal, which puts user data into potential conflict with the flag and the other two reserved patterns. This problem is solved by bit stuffing, as shown in Figure 13-5. 13.1.5 Frame Check Sequence Field The final field, occurring just before the ending flag, is the frame check sequence. Usually called the CRC, or cyclic redundancy check, this field is used for error detection . In its most common form the CRC is two octets long, quite useful for lower speed (~2400-bps) transmission. As transmission speeds rise, this simple code begins to let a small number of undetected errors slip past. With the Mobitex protocol employed by BSWD, noise bursts greater than 16 bits (2 milliseconds at 8000 bps) will very occasionally permit undetected errors to occur. Modern implementations for the RD-LAP protocol employed by ARDIS use four-octet CRCs. Naturally there is an overhead penalty, but the undetected error rate in the presence of noise is infinitesimal. These trade-offs, as well as the use of error correction will be discussed next. 13.2 ERROR-HANDLING APPROACHES 13.2.1 Philosophy A key distinguishing characteristic between airtime protocols is their particular philosophy of error handling. Nearly all vendors claim to have error correction protocols. In the very strictest sense many do not. Instead, their protocols actually feature error detection and retransmission to (finally) produce a clean copy. Well-known examples of vendors that claim this form of error correction are Microcom, with its MNP defacto standard, or any vendor using the V.42 standard that is present in virtually all circuit switched cellular modems. There will be more about V.42 in Chapter 15. A true error correction protocol is one that transmits enough redundant data, in a particular mathematical way, to permit faulty information to be corrected upon receipt without retransmission. All Motorola protocols, Ericssons Mobitex, as well as CDPD fall into this category. Some protocols mix techniques; the combinations are endless. It is possible to use error detect mode until the retransmissions become onerous, switch to forward error correct mode, and back that up with yet another level of detect/retransmit. All protocols, detection or correction, have breaking points. The power of the error correction technique is usually expressed as the UBER, the undetected bit error rate. This is the frequency with which a bit in error escapes unnoticed into the data 13.2 ERROR-HANDLING APPROACHES 207 processing system. The less often this happens, the better, but good UBERs have a practical cost that may not be justified in some applications. 13.2.2 Error Detection Versus Correction Basics Assume an artificial world in which no more than one bit in 100 would ever be in error (there are such environments, though not in data radio). The protocol designer might then enforce a maximum block size of 10 octets. Since the single-bit error is not frequently encountered, the designer might settle on a detect/retransmit scheme. Each octet could be assigned, say, a single odd parity bit. The detection of the single-bit error in the transmitted letter d could be represented as in Figure 13-6. Since the error is detectable, the message will be retransmitted and likely will be fine on the second attempt. Thus, one bit in nine is redundant, yielding a pure protocol efficiency of ~89%. Now assume the single-bit-in-100 rule holds but that the occurrence is expected to be unpleasantly frequent at times. In the worst case every retransmitted block would be contaminated. Retransmission could occur endlessly, but no useful information would ever reach the destination. The designer could now elect to add forward error correction to the block by adding an LRC, or vertical parity, code. The transmitted block would then look like Figure 13-7. Now 18 bits in every 99 is redundant for a pure protocol efficiency of ~81%. But retransmissions have been stopped since the location of the error is knowncaught in the crossfire of the two paritiesand can be corrected. The designer trade-off is thus reasonably straightforward. If only a few blocks in 10 will have an error, use error detect/retransmit. If many blocks, including all 10, will contain a single error, expend the overhead and use forward error correction. For a 100-octet message with exactly one bit error every 10 blocks, this can be demonstrated as follows (TRIB means transfer rate of information bits): User Octets Bits/Block Number Blocks Bits Sent Bits Resent TRIB Efficiency Detect 100 90 10 900 90 800/990 = 80.8% Correct 100 99 10 990  800/990 = 80.8% Although real-world scenarios are fiercely more complex than this trivial drill, it is exactly this kind of trade-off, on a far grander scale, that eternally faces the protocol designer. 13.2.3 Error Detection Versus Correction: Vendor Examples In data radio environments bit errors rarely occur in isolation, a phenomenon usually associated with miscellaneous transmission impairments such as Gaussian noise. 208 UNDERSTANDING AIRTIME PROTOCOLS Scattered errors are ever present, of course, but are accompanied by troublesome bursts associated with Rayleigh fading (and other problems). This error profile makes simple parity techniques quite impractical. There are four general methods of attacking real-world problems, all of which are combined with ARQ (retransmission) techniques in different ways by different vendors: 1. Error Detection via CRC . The most common CRC is 16 bits, specified by CCITT, and used in the V.42 approach. It detects all possible single-error bursts not exceeding 16 bits and 99.9984% of all possible longer bursts. 4 When bit rates are low, say 2400 bps as once used on Millicoms cellular CDLC devices, 5 burst errors of 16/2400 = 6.7 milliseconds could always be detected. For reference, note that the AMPS design assumes that deep fades [15 dB carrier-to-noise ration (C/N)] of an average duration of 2.5 milliseconds occurs about 6 times per second at 20 mph. 6 As bit rates rise, the message becomes vulnerable to Figure 13-7 Error correction example: parity with LRC Figure 13-6 Error detection: simple parity 13.2 ERROR-HANDLING APPROACHES 209 these long burst errors. There are now many cellular modems rated at 14,400 bps. The guaranteed fade duration protection at this bit rate is only about 1 millisecond. Errors this long will occur 10 times per second at 20 mph. How can this be endured? There are two crude methods: (a) The modem slows down. Field tests 7 have revealed that 14,400-bps cellular modems operate at 7200 bps (2.2-millisecond fade protection) 70% of the time and 4800 bps (3.3-millisecond protection) another 10% of the time. (b) The user sits still. One is usually unable to read, type, and drive at the same time (although we have all seen examples of people trying to do exactly that). However, there are users who take commuter trains. But if the key application is, say, E-mail, does it hurt if 16 out of every 10,000 packets has a spelling error? But suppose this is a financial transaction? One answer: The 32-bit CRC discussed in category 3 has begun to appear in some protocols. 2. Weak Error Correction; Interleaving; CRC . A simple, low-cost, fast-response but weak and inefficient error correction technique is employed. For a fixed data block, 1- or 2-bit errors are always correctable. The blocks bits are interleaved prior to transmission; if a burst error causes damage, the errors are scattered upon reassembly; they are then attacked by the weak forward error correction (FEC). This approach is employed in Ericssons Mobitex protocol employed by BSWD. Data is organized in a series of 160-bit blocks. Each block includes a 16-bit CRC. The users 144 bits (18 octets) and the CRC are expanded to 240 bits (60% efficiency) with the addition of a weak (can correct single errors) Hamming code. The protected data and CRC is then interleaved to scatter the bits so as to be able to withstand a 20-bit (2.5-millisecond) burst error. Motorolas MDC4800 protocol employed by ARDIS also uses this technique. The Motorola example is representative: a rate 1 2 (50% of bits transmitted are parity), k = 7 convolutional encoding algorithm is used in a 112-bit block. The block code has a minimum distance of five; there are patterns of three or more errors within the block for which the decoder output will be incorrect. 8 A 16-bit CRC guards against an undetected packet (which may be many blocks) error. Interleaving is used to reduce the susceptibility to burst errors. All 112 bits of every block are placed in a 7 × 16 matrix in column order and read out in row order, as shown in Figure 13-8. Detailed simulations 9 show that the decoder is sometimes overwhelmed by short burst errors whose placement is simply not optimum; other error placement sometimes permits even longer bursts (~20 bits) to be corrected. Typically the interleaving approach permits correction of ~16-bit (3.3-millisecond) burst errors about 90% of the time; the CRC detects nearly all the balance. 3. Good Error Correction; Interleaving; Strong CRC Backup. This philosophy is employed in Motorolas RD-LAP protocol. Obviously there are major technical improvements over MDC4800. FEC is achieved via a rate 3 4 trellis-coded modulation (TCM) technique, which is discussed in Chapter 15. Interleaving is organized to permit correction of ~32 bit errors; there are cascaded CRCs with a final CRC-32 to detect uncorrectable packet errors. A burst error as long as 32/19200 = ~1.7 210 UNDERSTANDING AIRTIME PROTOCOLS milliseconds can always be safely handled, and very few longer bursts escape detection. The CRC-32 detects all bursts of 32 bits or less, 99.99999995% of bursts of length 33, and 99.99999998% of bursts longer than 33 bits. 10 There is still a miniscule error possibility but one most people dont worry about. RD-LAPs published undetected bit error rate is 1.4 × 10 11 , an astonishingly low 1.4 errors in 100 billion bits. 4. Strong FEC; No Interleave; No CRC . The objective is to exploit the processing power of new engines so that virtually all errors can be corrected without retransmission. The most common technique used is Reed-Solomon coding, developed in 1960 and initially used in large file controllers capable of bearing the processing expense associated with this technique. By 1982 microprocessors permitted Reed-Solomon codes to be used in MDIs (now absorbed by Motorola) MMP-based vehicular terminals. The practical results were outstanding, with a published UBER of 1 in 10 billion characters. 11 Reed-Solomon codes are also used for CDPD. The implementation is very similar to the MDI approach, including the absence of a backup CRC (see Table 13-1). CDPD fade duration protection reads well in comparison to RD-LAP. With a fade duration of, say, 2.4 millisecondstypically encountered at very low velocities such as human walk speedRD-LAP may be forced to retransmit while CDPDs message makes it on the first try. But if the errors are scattered, perhaps a few small fades combined with random bit errors, CDPDs eight-symbol error correction capability can be overwhelmed. This is a more serious problem. Under these conditions CDPD has a weak undetected block error rate of only 1.2 × 10 5 (1.2 in 100,000), 12 significantly weaker than RD-LAP. CDPD has an implementation-dependent way out (your carrier may or may not use it). The fade duration protection is reduced to seven symbols (2.2 milliseconds) but yielding an undetected block error rate of 2.75 × 10 8 (100 million). 12 Figure 13-8 MDC4800 interleaving technique. 13.2 ERROR-HANDLING APPROACHES 211 [...]... of Mobile Radio Propagation above 400 MHz,” IEEE Transactions on Vehicular Technology , Vol VT-23, pp 143–159, 1974 16 JFD Associates, MDC4800 Performance Analysis 17 Motorola, “As Is” public protocol document, 3-30-92 18 JFD Associates, CDPD Airlink Capacity Analysis, Version 1.0 19 JFD Associates: ARDIS/RAM Coverage Analysis, 3-1-95 20 JFD Associates simulation: motosync.pas 21 H M Hafex et al., “Experimental