# 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
69
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

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.
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,
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 .