# Kiến trúc phần mềm Radio P4

Chia sẻ: Tien Van Van | Ngày: | Loại File: PDF | Số trang:59

0
70
lượt xem
7

## Kiến trúc phần mềm Radio P4

Mô tả tài liệu

Systems-Level Architecture Analysis The objective of this chapter is to give the reader practice in addressing software-radio architecture issues at the systems level. The study of systemslevel software-radio architecture is first motivated with a realistic case study. The case study includes the critical parameters of most radio architectures. The analysis focuses on those aspects that are significant for software-radio architecture. The balance of the chapter develops the issues raised in the case study. I. DISASTER-RELIEF CASE STUDY This case study considers a mobile communications capability for disaster relief....

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Kiến trúc phần mềm Radio P4

1. Software Radio Architecture: Object-Oriented Approaches to Wireless Systems Engineering Joseph Mitola III Copyright !2000 John Wiley & Sons, Inc. c ISBNs: 0-471-38492-5 (Hardback); 0-471-21664-X (Electronic) 4 Systems-Level Architecture Analysis The objective of this chapter is to give the reader practice in addressing software-radio architecture issues at the systems level. The study of systems- level software-radio architecture is first motivated with a realistic case study. The case study includes the critical parameters of most radio architectures. The analysis focuses on those aspects that are significant for software-radio architecture. The balance of the chapter develops the issues raised in the case study. I. DISASTER-RELIEF CASE STUDY This case study considers a mobile communications capability for disaster re- lief. The capability includes mobile infrastructure, mobile nodes, and handsets. The design emphasis is on defining an open architecture for the infrastructure. Architecture defines components at such a high level of abstraction that one needs a concrete sequence of specific implementations20 in order to assess the contributions of the architecture. Architecture insight seems to develop with implementation practice. It seems to take a half-dozen design and implemen- tation cycles to develop the intuition necessary to make strong contributions to architecture. This case study therefore should be designed and redesigned by the serious student as the text progresses. A. Scenario The case study addresses the fact that medium-sized urban areas may be deci- mated by a natural disaster. As illustrated in Figure 4-1, the disaster area may be largely obliterated. The destruction of the Holmstead area in South Florida by hurricane Andrew is a practical example of such a disaster. The populace has enjoyed the use of cellular telephone, but the disaster is assumed to have wiped out the wireless network. At the periphery of the disaster area, connec- tions are available via fiber and/or microwave to the core telecommunications network. 20 To address future implementations, one must often substitute a sequence of designs for the “sequence of implementations” that have not yet been built. 112
2. DISASTER-RELIEF CASE STUDY 113 Figure 4-1 Disaster-relief scenario. Two software radio problems arise. The first is the design of an SDR prod- uct that will meet the need given current technology. The second and more important problem is to define a software-radio architecture within which a family of backwards-compatible SDR products may evolve. This architecture should meet the designer’s need for product differentiation and protection of intellectual property. But it also has to entice the rest of industry to partici- pate. The product supplier’s first goal in industry participation is to establish product leadership. This includes motivating potential hardware and software suppliers to support the architecture. It must meet customer needs for afford- able upgrade paths. To motivate the design of a radio system, assume that an appropriate na- tional authority has decided that it would like to acquire a capability to rapidly reconstitute communications in such disasters in the future. Sample customers include the U.S. Federal Emergency Management Agency (FEMA), the Eu- ropean Community (EC), and the government of China or Japan. In order to obtain support from these national-scale authorities, a disaster must be of major proportions. Consequently, numerous local, state, and federal institu- tions converge on the disaster area to look for survivors, set up temporary shelters, prevent crime, and reconstitute the necessities of life. To motivate those who are oriented toward the military sector, mobile infrastructure is the essence of tactical military communications. The exercises explore the possi- bility of communicating while on the move. Although not strictly a need of the disaster-relief application, communications while infrastructure is moving is a simple extension of the case study. To motivate those who are oriented toward the commercial sector, consider rapid build-out of a developing nation like Thailand of a few years ago.
3. 114 SYSTEMS-LEVEL ARCHITECTURE ANALYSIS TABLE 4-1 Disaster-Relief System Communications Needs Needs Questions Illustrative Answers Physical Area? 3–5 local areas of 2–10 km radius each Classes of Subscriber? Police, fire, rescue, local populace, National Guard Numbers of Subscribers? 10–20 local and/or national police agencies 20–100 fire and rescue squads (10 helicopters) 50,000 local populace (including 20 light aircraft pilots) 500–3000 National Guard troops with 20–50 aircraft Information Services? Core: voice, e-mail, tasking/scheduling, databases, fax Growth: video-teleconferencing, telemedicine External Interfaces? Network: T/E-1 to T/E-3 SDH (microwave, fiber), SS7 Cost? Price? “A few million dollars” To motivate the analysis of architecture, assume that the customer has de- cided that conventional approaches are too expensive, both in terms of initial acquisition cost and in terms of life-cycle support. The buyers therefore want open-architecture software radio or SDR. They also request concrete evidence that the expected advantages of SDR architecture will be realized in their system. B. Needs Analysis Needs analysis establishes the intuitive relationships among radio system func- tions, components, design rules, and costs. Systems-level communications needs for a disaster-relief system are summarized in Table 4-1. The answers to the needs questions define the top-level requirements of the system. Physical area and numbers of subscribers are first-order deter- minants of the technical needs of wireless infrastructure. There should be design latitude about how many infrastructure nodes are provided. This buyer has specified the physical size and overall communications capability. The fundamental measure of voice traffic is the Erlang [137]. An Erlang is the international unit of traffic intensity that represents an average of one circuit busy out of a group of circuits. Wireless infrastructure provides capacity in Erlangs per square km, at a given Grade of Service (GoS) and Quality of Ser- vice (QoS). In this case, there are four major classes of subscriber. Each class brings its own indigenous vehicular and handheld radios and wireless PDAs. These radios establish radio bands and modes that must be supported by the disaster-relief infrastructure. In addition, those people who are providing the communications services will also need local communications. Call these the organization-and-control (OC) users. Needs analysis examines the general scenario by generating a variety of use-cases. The existence of the OC users as an additional class of users is
4. DISASTER-RELIEF CASE STUDY 115 derived by examining use-cases, detailed vignettes that force one to think about significant details of the application. The analysis of use-cases may be accomplished effectively with few software tools. One might use a database system to record details of entities participating in the scenario. One might use a geospatial information system (GIS) to visualize the distribution of the entities. A spreadsheet tool (e.g., Excel) can perform parametric analysis. A discrete event simulation can characterize queuing delays of message traffic needed to support the e-mail, scheduling, and database services (e.g., OPnet). In addition, UML simplifies some aspects of use-case analysis. UML’s use- case view keeps track of external and internal actors and kind of forces one to push through the sometimes-tedious details of a use-case. The needs analysis for an SDR-based product attempts to limit the needs so that the complexity of the SDR software is minimized. This is because typically over half of the cost of developing an initial SDR product is in the software. To limit the needs is to limit the software complexity. The needs analysis for a software-radio architecture, on the other hand, attempts to define the limits to which the needs could grow in the foreseeable future. This is because architecture is oriented toward providing a growth path, while product design is oriented toward short-term profitability. When customers say they are interested in reaping the benefits of open architecture, they generally have some short-term goal in mind. Some can take a longer-term view, but a course of action that has long-term impact often consists of a sequence of short-term success stories. The U.S. DoD expresses needs as requirements. Through a formalized pro- cess, military organizations express, coordinate, and validate their needs. They attempt to prune the needs to the minimum that is operationally acceptable; these are the requirements. In the modernization of the procurement process, the DoD has begun to express requirements in terms of a minimal set (thresh- old requirements), plus a prioritized set of additional needs. There are now laws that encourage the U.S. military departments to acquire products and services more like commercial organizations. Thus, some parts of the DoD acquire commercial communications products, and negotiate warranties in lieu of conformance to military specifications (MIL-SPECs). This evolution drives requirements toward general statements of need as suggested in Table 4-1. In addition, however, military users are continuously striving to balance actual needs (regardless of what the formal requirements specify) against affordabil- ity. Thus, as capabilities become affordable, the formal requirements finally embrace what could be recognized as needs all along. Focusing software-radio architecture on needs insulates medium- and long-term architecture evolution from the shorter-term push and pull of the formal requirements process. The requirements are rarely defined as precisely as a systems designer might like. Consider the cost goal of a few million dollars, for example. The notional buyers of the system are the service providers. They have a top-down sense of the value of the capability. Beyond that, they have to justify budgets based, for example, on cost estimates from industry. The definition of cost,
5. 116 SYSTEMS-LEVEL ARCHITECTURE ANALYSIS therefore, is an iterative process between the buyer who sets the value and the developers who characterize price as a function of capability. One generally must be satisfied with a rough-order-of-magnitude (ROM) cost goal. Low cost can be a market differentiator. Another competitor might offer a feature-rich product, or one that is more reliable, that costs more. Yet another competitor might offer a product that is compatible with the customer’s installed base, or that makes it easier to expand. Any of these approaches can change the cost by 20 to 50% or more. It is therefore essential to adopt a business strategy that can focus on both the short-term SDR design and the participants’ goals for long-term architecture evolution. C. Exercises 1. What radio bands and modes are implicit in the identification of classes of user? What ambiguities must be resolved before a meaningful design could begin? If discrete radios are packaged with one band/mode per unit, how many units are needed at a base station? If you cannot write an equation for this, what additional assumptions are needed? Make those assumptions and write an equation for the number of units at a base station. 2. Assume SDR units are packaged by RF band. That is, there may be an HF SDR unit covering the band from 2 to 30 MHz, a LVHF SDR unit (30–88 MHz), a VHF aeronautical SDR (100–225 MHz), etc. What is the upper frequency limit of the SDR family for the disaster-relief application? Assume that all modes within a band are defined in baseband software. How many bands must be supported? Which bands could be packaged into a contemporary SDR? Which COTS products might provide the RF coverage needed for such a multiband SDR? 3. Suppose now that you want to define a software-radio architecture that will accommodate an evolution path from the answer to question 2. What are the architecture implications of consolidating multiple RF bands into a single wideband RF? Think of the consolidation of RF bands over time as a design rule for the architecture. What other design rules might one need for architecture that would conflict with this architecture design rule? What technology and marketplace forces will shape the resolution of the conflict(s)? What process might one put in place to assure that an industry- driven SDR architecture evolves to track the realities of these forces? 4. What top-level needs are missing from those provided in this section? For each need you can think of, state an assumed requirement. How might you go about validating your assumption? What computer-based models could you use to explore the requirement? What kinds of short-term implications should be examined for SDR implementation? What longer-term implica- tions should be examined for software-radio architecture? 5. How long should it take to set up or tear down the mobile infrastructure? If this were a military application, would setup and tear-down time be more
6. RADIO RESOURCE ANALYSIS 117 critical or less critical? Suppose this were a rapid build-out of wireless infrastructure? What are the implications for software-radio architecture? 6. How many people should be in direct support of the communications ca- pability? That is, how many nonrelief personnel will be needed to staff the mobile infrastructure? Is completely unmanned operation feasible once the system has been set up? If not, what operations must be automated for completely unmanned operation? 7. Analyze the information services. Could the buyer have specified commu- nications capabilities (e.g., numbers of voice channels, packets per second of data)? Would this be more or less helpful to the systems engineer? What degrees of freedom are provided by specifying communications capabil- ities in terms of information services versus communications parameters such as number of voice channels? What further analysis is required for systems design? 8. Analyze the external interfaces. What further analysis is required for sys- tems design? 9. Outline a strawman design of the disaster-relief system using conventional radios, switches, patch panels, etc. II. RADIO RESOURCE ANALYSIS This section develops the process of needs analysis further. It first reviews well-known methods for analyzing radio resources, but from a software-radio perspective. These include spectrum allocation, geographical area coverage, and subscriber distribution over the geographic area. Software-radio resources also include the traffic presented to the radio, the degree of mobility afforded to a subscriber, and the quality of the communications services. To optimize the use of these resources in the pursuit of cost and revenue-generation goals of the service provider, the software radio engineer must quantitatively address several issues. Spectral access, power generation efficiency, and waveform purity complement spatial access. GoS characterizes the availability of the traffic channel to the subscriber. QoS characterizes the expected parameters of that radio channel. All these are necessary in the analysis of software-radio architecture. A. Radio Resource Management Radio resources consist primarily of the RF channels. These channels may bear traffic only, control information (signaling), or a mix of both. In a ter- restrial mobile cellular network, the RF channels are reused spatially. Obsta- cles, Fresnel zones, and locations with excessive interference subtract from the nominal radio resources. These artifacts impart greater than square-law
7. 118 SYSTEMS-LEVEL ARCHITECTURE ANALYSIS Figure 4-2 Radio resource parameters. losses, with path loss exponents of 2.8 to 4 in some urban areas. In addition, the received signal strength may vary randomly due to environment changes by 10 to 20 dB, and by 30 dB or more due to small changes in multipath reflections and frequency. Thus, there is a time-varying spatial distribution of radio resources as a function of mobile location, obstacles, and infrastructure density and location. These resources may be characterized further in terms of the parameters illustrated in Figure 4-2. Total traffic offered to the network is a resource in the sense that the number of attempts to use the system represents the max- imum available revenue stream. The evolution of software-radio architecture provides opportunities to leverage this resource. 1. Total Traffic Early cellular networks measured offered traffic by moni- toring attempts registered in the control channels. Although this is the largest share of lost calls in a well-designed network, it does not measure attempts made from disadvantaged propagation locations where the subscriber cannot access the control channels. Software radio handsets can keep track of such attempts and report them to the network. In addition, they can characterize the offered demand in terms of voice, data, and multimedia traffic that would have been offered. Since the size and frequency of data traffic can be fractally distributed [138], its statistics are more difficult to judge than voice traffic. Thus, specific details on offered video-teleconference opportunities, e-mail traffic, large attachments, etc. gathered at the source by SDR handsets will be of particular help in provisioning 3G networks. 2. Radio Link Quality The mobile traffic supported at a given level of quality (e.g., at a specific BER) is also a resource. In conventional cellular radio,
8. RADIO RESOURCE ANALYSIS 119 this traffic supplies revenue streams based on voice and data traffic. With a multiband, multimode SDR, this traffic occupies a specific band and mode. If the type of traffic is movable to other available bands or modes, then the SDR network may reassign the traffic to some other band or mode. Third- generation wireless pursues this approach within a specific IMT-2000 band by providing multiple data rates as a function of SNR. With multiband radio, access opportunities are multiplied. A multiband SDR could move the traffic to spectrum rented from the police [425] if the link quality on the cellular networks is not satisfactory. It could also delay the traffic (e.g., a large e-mail attachment) for delivery later to a corporate LAN. In a military setting, this means selecting a different waveform from a library, as a function of traffic, security needs, and dynamic network structure. The useful radio resources, then, include all those bands and modes with sufficient link quality in a specific geographic location that fall within the fundamental limitations of the radio platform: RF coverage, digital access bandwidth, and processing capacity. Although one would like to measure BER directly, this is often not possi- ble. Service technicians can measure BER under specific conditions, but these conditions may not fully reflect the customer’s experience. Future SDRs will have the memory capacity to log BER faults as a function of time and location. Uploading and analyzing logs of fault conditions may then identify causes of low call quality. In applications where revenue generation is of primary im- portance, this knowledge can be used to selectively enhance the infrastructure. One may manually adjust a beam pattern or introduce a repeater in a Fresnel zone. Smart antennas may adapt to such conditions autonomously, smoothly accommodating minor propagation problems in addition to accommodating increased subscriber density. If network loading is more important than rev- enue generation (e.g., in military applications), one may redistribute users across bands and modes (e.g., get the right data to the right person at the right time). 3. Mobile Traffic Profiling The mobile traffic that is serviced also must be measured. Standard telephony metrics include arrival rates, call duration (hold time) and class of traffic such as voice, fax, or data. Progress of the channel state-machines may be monitored so that the network operator can identify problem areas. An inordinately large number of handoff failures versus at- tempts, for example, can signal the need for a gap filler, or improved handoff (to another cell site). A multiband SDR might measure the traffic density in other RF bands when the primary network is lost (e.g., in a deep fade zone). This out-of-band traffic profiling gives the SDR network the information it would need, for example, to plan spectrum rental [425] in lieu of additional build-out of infrastructure. Multichannel SDR nodes have the potential to relay calls on unused channels. Military networks may use this approach to dynam- ically connect subnetworks that have been cut off in their primary RF band. Amateur radio networks use this polite, inexpensive approach to networking as well. As multichannel SDR nodes proliferate, this mode (sometimes called
15. 126 SYSTEMS-LEVEL ARCHITECTURE ANALYSIS Figure 4-8 Efficiency supporting offered traffic in an area. 4. Spatial Efficiency Spatial efficiency may be quantified using the approach illustrated in Figure 4-8 [143]. The spatial efficiency of supporting offered traffic, ´, is the ratio of the offered traffic, A (in Erlangs), to the product of RF spectrum employed and geographic area. RF spectrum employed is the product of the number of subscriber channels supported, Nc , times the effective bandwidth required per channel, Wc . Geographic area is the product of the effective area per cell, Z, times the number of cell sites, N. From one perspective, the system designer’s goal is to maximize ´ to maximize revenue at minimum cost. The application of this formula must include inefficiencies and overhead. For example, if eight subscribers share one 200 kHz GSM channel, then each user’s effective bandwidth requirement is 200=8 = 25 kHz. In addition, how- ever, if 100 users share four 200 kHz control channels, then there is an ad- ditional (4 $200)=100 = 8 kHz of overhead-bandwidth required for a total ef- fective bandwidth required of (25 + 8) = 33 kHz = Wc . Dividing Wc into the allocated bandwidth, Wa , yields the number of channels available to bear rev- enue. The same kind of analysis applies to software-radio architecture. In this case, however, W is the accessible bandwidth, and Nc is the potential number a of channels accessible in each of the j subbands in W . Efficiency is given by a [spatial efficiency equation]: !" %$ ´=A # (Ncj $W$ Nj \$ Zj )& cj j for each of j subbands in Wa .