230 14 ESTIMATING AIRLINK CAPACITY: PACKET SYSTEMS 14.1 INTRODUCTION The number of variables in a packet switched data radio system are virtually endless. This does not mean that the task of estimating user capacity is hopeless. Directionally accurate but labor-intensive results can be derived if one knows the basic conditions under which the data transfers occur. This most assuredly includes assumptions about the communications software being employed. Examples of the necessary effort are shown here by comparing ARDIS RD-LAP to CDPD. The all-important application example will be the 30-character inbound message whose CDPD component was captured in Appendix C. It does not take much imagination to know that the TCP/IP impact will have a very detrimental effect on CDPD; thus a demonstration of what can be done to minimize that impact is also included. 14.2 ILLUSTRATIVE SINGLE-BASE-STATION COMPARISON Assume that a small town exists with only a single base station. This is a fairly infrequent case, especially for CDPD, but this fictitious town permits the establishment of a performance baseline relatively free from practical arguments. In this special situation the ARDIS infrastructure will employ a continuously keyed forward channel, greatly improving its outbound capacity. Since the voice cellular demand is also small town, CDPD will install a dedicated-channel, unsectored base station. The ARDIS devices will be evaluated as half duplex (HDX). While the protocol does not require that restriction, all of todays RD-LAP devices are HDX in order to 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) minimize device product cost. CDPD will be evaluated as full duplex (FDX) since that is by far its dominant modem type. 14.2.1 ARDIS If there are no other users on the inbound channel, RD-LAP will dispose of our strawman message quickly. There is no handshaking. If a message is ready, it goes! The initial sequence is portrayed in Figure 14-1. The device, which is listening to the outbound channel, believes the inbound path to be idle. It then commits, irrevocably, to an inbound transmission. The device switches off its receiver and can no longer hear channel status information. The frequency synthesizer is reprogrammed, and the device locks on to the channel of choice. Within 5 milliseconds of the decision to switch, the device transmitter is keyed and begins sending symbol synchronization characters. When the base station senses symbol synchronization at full power, just after microslot 3 is completed, it could theoretically set busy at the end of microslot 4. In fact, ARDIS RD-LAP only sets busy every five microslots. The frame synchronization, and then the control information, begins transmitting inbound. At the next slot boundary, the first new opportunity for competition from another device, the channel status indicator is solidly busy. Following the frame synchronization is the SID, a very compact 30-bit station ID field that has its own 6-bit CRC. Next in sequence is the RD-LAP header, also quite terse: 12 bytes, including its own protective 2-byte CRC. The SID/header bytes identify the format and content of the information to follow (e.g., data, response, idle) as well as the source or destination address (a link layer address, not a TCP/IP format), the packet length, and sequencing information. The user data follows immediately, also in 12-byte blocks. Since our strawman message has additional RadioMail overhead, it is 46 bytes long. This happens to be a very poor fit. Two bytes of the 4-byte CRC spill, forcing an entire 12-byte block to be added. The complete message is then expanded with error correction information. For its own design convenience, Motorola chose to have the format of the inbound message be exactly that of the outbound. Thus, space for meaningless busy/idle information is retained in the input stream, wasting 45% of the capacity. The 46-byte message has now grown to 924 bits, including frame synchronization, control overhead, padding, and error correction/detection information. After transmitting these bits, RD-LAP breaks off the transmission and the device ramps down its power in less than a millisecond. Because of slot boundaries, there is a delay in which the channel is really free, but no one knows it. This particular message causes an 80-bit, 4.2-millisecond busy hang time. Under light-load conditions, that would be the end of it. If RD-LAP were compelled to handle a string of such 46-byte user messages, it could theoretically push through 16.7 per second on the inbound channel if there were no contention . Alas, the real world is rife with channel clashes. Using the digital sense multiple access (DSMA) formula given in Chapter 13, realistic inbound throughput at this short 14.2 ILLUSTRATIVE SINGLE-BASE-STATION COMPARISON 231 Figure 14-1 RD-LAP inbound message: 45–56 user bytes. 232 message length is about 2540% of the channel capacity, as shown in Figure 14-2. Note that if 40% throughput is achieved, each message will, on average, make two attempts to get in. Our strawman scenario includes an application ACK returning from RadioMail. This message must, in turn, be acknowledged by the device on the inbound channel. Fortunately, RD-LAP is a reasonably good ACKer. It is up and down in two slot times, as shown in Figure 14-3. The relationship between the inbound user message and an ACK are shown in Figure 14-4. If one selects the peak-hour design maximum to be, say, 60% offered traffic, then more than 12 ACKs per second can be handled if that were the only message mix. In contrast, less than 6 messages per second of the 46-byte user message can be handled. If the two must be combined in equal measureone ACK for every user message as they are in this scenariothen the combined message rate drops to four per second. Note that all of these calculations assume no errors are present that will force retransmissions. It is possible to estimate the RD-LAP message rate for a range of message lengths as long as one settles on the offered traffic percentage. Figure 14-5 is the message rate with a G of 80%two attempts for every success. With a fully loaded packet of 512 bytes, RD-LAP can sustain a rate of 1.3 messages per second. 14.2.2 CDPD The TCP/IP profile experienced with the BAM transaction uses 15 inbound messages to participate in the handshaking that ultimately delivers the 30 user bytes. Twelve of those 15 are short two-block sequences carrying 3756 bytes of address and control information. This is an oddly fortuitous match to the RD-LAP user byte message. Figure 14-6 depicts this most common handshake message. Unlike ARDIS, most CDPD devices are full duplex and the airlink protocol exploits this fact. Busy/idle indicators come with 60-bit spacing. The devices do not Figure 14-2 RD-LAP inbound efficiency: 45–56 user bytes. 14.2 ILLUSTRATIVE SINGLE-BASE-STATION COMPARISON 233 Figure 14-3 RD-LAP inbound ACK. 234 enter a dark interval while they switch from receive to transmit. They respond within 8-bit times to the idle indicator and ramp up more quickly than RD-LAP units. The frame synchronization interval is much shorter, and no capacity is thrown away by reserving space for meaningless channel status information. However, one of the limitations of Reed-Solomon coding now makes itself felt. Because of this choice of error protection schemes, CDPD cannot be very granular. The smallest block must be 385 bits long; RD-LAP can get an entire encoded message, with SID and header, into 184 bits. The most granular CDPD block can carry ~32 bytes. Since the TCP/IP addressing demands are greater than that, a second 385-bit block is forced. Thus, the maximum repetition rate that CDPD can handle is 900 bits. This is better than RD-LAP, of course, but vaguely disappointing when one considers the elegance of the contention design. Figure 14-4 RD-LAP inbound message rates: 46 user bytes + ACK. Figure 14-5 RD-LAP inbound message rate: offered traffic G = 80%. 14.2 ILLUSTRATIVE SINGLE-BASE-STATION COMPARISON 235 Figure 14-6 CDPD inbound: two-block handshake message. 236 As shown in Figure 14-7, CDPDs very short collision window pays off in better throughput if the offered traffic rises above ~40%. The minimal effect at lower offered loads should be no surprise. If there is little contention, skillful design techniques to avoid it are of little avail. But at the 80% offered load used in the RD-LAP example, CDPD achieves ~10% greater throughput at the two-block length. This enhanced throughput leads to a better message-per-second rate, shown in Figure 14-8. With G = 80%, CDPD can move more than 9 two-block messages per second; RD-LAP can only manage 6.5. However, because of TCP/IP, CDPD has to transmit 12 two-block messages, 2 more three-block messages, and the final 471-byte magilla, which contains the 30 user bytes. At G = 80%, the number of transactions of this length that CDPD can move is 0.44 per second. RD-LAP can transmit 4.43 transactions per second, including the response Figure 14-7 Inbound efficiency: CDPD vs. RD-LAP (RD-LAP: 46 user bytes; CDPD = 2 blocks). Figure 14-8 CDPD inbound message rates. 14.2 ILLUSTRATIVE SINGLE-BASE-STATION COMPARISON 237 to the RadioMail application ACK. It thus has 10 times the transaction processing capability, essentially for two reasons: 1. The ghastly inefficiency of TCP/IP in short-message environments 2. The assumption that RD-LAP is operating in a continuously keyed environment that permits its inbound channel to always operates in DSMA mode 14.3 MULTICELL CAPACITY 14.3.1 Base Station Quantity Mismatch The capacity calculations for a single base station are of little value in large metropolitan areas with many supporting channel locations. In early 1994 Ameritech brought up 200 CDPD stations in Chicago, a geographic area 1 extending well into northwestern Indiana. 2 In mid-1994 ARDIS had a total of 68 stations on two different frequencies covering its smaller definition of the Chicago CSMA. 3 Thus, Ameritech had already deployed ~2.9 times more data infrastructure than ARDIS, albeit over a somewhat larger physical area. By June 1995 the total number of voice cellular base stations installed in the United States reached nearly 20,000, 4 but only a fraction were equipped for data. At year-end 1996 there were 30,000 voice base stations installed, and an interesting percentage were CDPD capable. But many of the national voice sites are owned by carriers who simply do not participate in CDPD. Others are in rural/suburban areas where, even if the carrier has enthusiastically embraced CDPD, it is unlikely to be deployed. The Greater New York City metropolitan area is one in which CDPD is richly employed and competes directly with ARDIS. CDPD deployed relatively late in the New York/New Jersey area. NYNEX, before its absorption by BAM, had 30 trisectored CDPD base stations in place by the second quarter of 1994, growing to 95 by the end of the year, and advancing to 176 during the first half of 1995. By contrast, a decade earlier ARDIS had deployed 70 MDC4800 base stations in the New York/New Jersey area, which grew to more than 80 locations in mid-1995. Both ARDIS and BAM have continued their enhancement programs, but with a different focus. BAM spreads its footprint. All of Long Islandpotato farms, vineyards, fishing villagesis covered, for example. ARDIS provides only partial coverage in Suffolk County. There is no North Shore presence east of Northport and the central part of the island is only covered as far as SUNY Brookhaven. In north Jersey, BAM pushes westward beyond Sussex County to the Pocono Foothills; ARDIS tends to cover only the main highways in that region. The ARDIS enhancement effort, by contrast, has been focused on modernization to RD-LAP and vertical capacity improvements. The 80+ locations have had more and more base stations and channels added, but there has been little geographic expansion. 238 ESTIMATING AIRLINK CAPACITY: PACKET SYSTEMS In areas where head-to-head competition is encountered, a CDPD discrete base station location edge of 3.5 to 1 over ARDIS probably represents an upper limit. It has already been established that, in an error-free environment and ignoring TCP/IP impact, CDPD and RD-LAP are nearly equivalent technical alternatives from a capacity viewpoint. Simplistically (and inaccurately), if each CDPD carrier employed one dedicated channel in each trisectored cell, their overall capacity potential would be more than 10 (3.5 × 3) times greater than a single-frequency ARDIS layer at 19.2 kbps. The TCP/IP short-message inefficiencies would be offset at one stroke! But in a multicell, single-frequency case the ARDIS capacity potential is actually greatly reduced. Recalling Section 12.5.3, if ARDIS deploys five single-frequency base stations, with perfect user distribution, their effective outbound capacity yield is equivalent to 1.67 stationsone-third rated capacity. The inbound side suffers as well. When a base station is not keyed for transmission, the inbound devices cannot hear busy/idle information and resort to pure ALOHA input. 5 ALOHA is an unstable technique. Using the formula derived in Section 13.5.1, it is possible to show that offered traffic G should be held below 50% or the resulting contention will actually reduce throughput. A best case practical inbound throughput is probably ~15% when the output channel is off, restabilizing as the outbound channel is keyed and presents busy/idle information again. In a multicell environment, if CDPD deploys 18 independently operating base stations for every five that ARDIS places on the same frequency, the crude capacity difference is 3 × 18 1.67 = 32 to 1 This is a very noticeable capacity potential in favor of CDPD. It is no wonder that ARDIS has installed several channel layers to provide comparable capacity, gaining a building penetration edge at the same time. 14.3.2 CDPD Sector Impact Voice cellular sites are commonly outfitted with three sectors (or faces). If CDPD is deployed in every voice site, it will follow the voice footprint, crudely tripling base station data capacity. But smaller base station diameters, with the coverage area broken into sectors, greatly increases the handoff rate. In the past there were severe inefficiencies in CDPD sector/cell hand-off. Assume a metropolitan area with contiguous cells each having a 1/2-mile radius. Then an arbitrary vehicle moving at a 30-mph metropolitan speed through the midst of these cells will encounter a hand-off about every 36 seconds. Half of these will be sector hand-offs; half will be cell hand-offs. The principle is illustrated in Figure 14-9. CDPD hand-off times can be captured by the end user. Appendix Q is a partial edited log of cell hand-offs. It was created by using an IBM ThinkPad to execute the following program, the core repeating every 2 seconds: 14.3 MULTICELL CAPACITY 239