Kiến trúc phần mềm Radio P15

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

0
48
lượt xem
7
download

Kiến trúc phần mềm Radio P15

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

This chapter develops illustrative applications, including the design of a contemporary SDR infrastructure product, the disaster-relief system. I. THE DESIGN PROCESS The implementation of SDR applications can be structured into an SDR design process. This process begins with the definition of a concept of operations (CONOPS), in which functions of the product are identified. The next stage, system definition, includes rapid prototyping and benchmarking. The third stage, system development, includes the implementation of hardware-software components. ...

Chủ đề:
Lưu

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

  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) 15 Applications This chapter develops illustrative applications, including the design of a con- temporary SDR infrastructure product, the disaster-relief system. I. THE DESIGN PROCESS The implementation of SDR applications can be structured into an SDR de- sign process. This process begins with the definition of a concept of operations (CONOPS), in which functions of the product are identified. The next stage, system definition, includes rapid prototyping and benchmarking. The third stage, system development, includes the implementation of hardware-software components. Acquisition and integration of COTS components and/or system- on-a-chip IP characterizes this stage. The expense of coding and documenting software for reuse also may be borne in this stage. The final stage, system de- ployment, includes platform upgrades and software downloads, with multiple incremental enhancements. The CONOPS provides the foundation for the development of use-cases of object-oriented design with UML. The top-level design constraints must be expressed as an initial set of design rules. The design rules include the degree of openness of the architecture. If the design has an open architecture that supports industry standards, then there may be third-party suppliers of hardware and/or software for the product. If the design is proprietary, the product should be unique, because it will not have the value-added features of a robust third-party supplier program. The functions then must be allocated to hardware and software components that can be procured or developed within a market-driven timetable, and within the design rules. The node design process is illustrated in Figure 15-1. Physical design addresses the choice of components from the antenna to the user in- terface. These components may be hardware intensive in one implementation (e.g., in a handset) and software-intensive in another (e.g., in a base station). The CONOPS establishes a list of RF bands and modes that the product has to support, both initially and over its life cycle. The state of RF technology determines how many parallel antenna-RF-IF-conversion chains of hardware have to be included in order to support these bands. The maximum number of simultaneous subscribers in each RF band and GoS define the number of traffic channels supported per band. The number of channels plus the 482
  2. THE DISASTER-RELIEF SYSTEM DESIGN 483 Figure 15-1 From functional design to node design. allocated bandwidth and other parameters of the air interface define the mini- mum bandwidth of the RF or IF ADC. Over time, ADC technology continues to advance, so one ADC may cover multiple RF bands. If the design de- cisions include the use of wideband ADCs (e.g., with hundreds of MHz or GHz sampling rates), then digital interconnect of the ADC data streams to the processing channels becomes a high-visibility design issue. Air interfaces and services define the software that has to be supplied. Once the software components have been identified, the digital processing architec- ture of ASICs, FPGAs, DSP chips, and/or general-purpose processors may be defined. In addition, the designer must balance the need to satisfy com- putational demands of the software against the competitive pressures of cost- effective design. Computational demands argue for larger DSP pools while competitive pressures tend to argue for smaller ones. The design example illustrates the development of a CONOPS. It then describes the methods of selecting hardware and software components, and sizing them for a well-engineered SDR design. Subsequent analysis highlights those features of the design necessary for it to be part of a robust software- radio architecture. II. THE DISASTER-RELIEF SYSTEM DESIGN Consider the disaster-relief case study introduced previously. This section elab- orates that case study into an SDR development project. The first step in the
  3. 484 APPLICATIONS Figure 15-2 Concept of operations. applications development process is to establish a vision or top-level concept that motivates the creation of SDR applications. The vision may be a high- level statement of a challenge (e.g., “Put a man on the moon by the end of this decade”). Or it may be a statement of an abstract goal (“We want to own the night”). The vision for disaster relief might imply notions like “connecting diverse relief organizations,” “reconstituting communications,” “assisting the stricken,” etc. To provide the foundation for a technical approach, one should support the ideas behind the vision with a CONOPS as illustrated in Figure 15-2. The CONOPS should identify: " The customer for the product, system, or service " The scenarios in which the system will be employed " The benefits of the system in those scenarios " The people who will benefit The following is an illustrative CONOPS. A. FEMA Concept of Operations (CONOPS)26 In addition to the material provided previously a CONOPS could include the material in Exhibit 15-1. 26 Any relationship between this concept and any actual project is purely coincidental.
  4. THE DISASTER-RELIEF SYSTEM DESIGN 485 The U.S. Federal Emergency Management Agency (FEMA) provides a national-level pool of resources that come to bear on major disasters like the destruction of much of Holmstead, Florida by Hurricane Andrew a few years ago. FEMA would like to acquire a mobile system that is capable of reconstituting local cell phone service while enhancing communications among emergency relief personnel. The assumption is that the wireless service has been wiped out in the disaster area.27 In a typical scenario, disaster relief comes from 50 or more teams drawn from dozens of federal, state, and local organizations, including police, fire, and rescue. These groups have a diverse set of communications capabili- ties. The Federal Bureau of Investigation (FBI) has speech-privacy radio technology as do a few of the largest municipalities in the United States. Special operations groups such as the Florida Department of Law Enforce- ment (FDLE) also employ special systems which, of course, tend to be incompatible with almost everyone else. If the U.S. National Guard or re- serves are called upon, the Army uses the SINGCARS system discussed earlier. The Air Force components are typically equipped with Have Quick (I and/or II) in addition to simultaneous VHF and UHF transmission for air traffic coordination. In addition, airlift of equipment and supplies to the disaster area requires the use of aeronautical mobile bands such as the 100 MHz air traffic control band, and the 225–400 MHz military band. Figure 15-2 illustrates the organizations that may participate in the disas- ter-relief operation. Several scenarios are contemplated as follows. The sys- tem must flexibly support all the scenarios. In the Hurricane/Tornado scenario, a large area has been ravaged by a category 4/5 hurricane, or a series of simultaneous tornadoes. There is one large damage area in which a population center (e.g., a small city) is located, and up to three additional smaller areas (e.g., towns or hamlets). Large fractions of the population are victims. The terrain is flat to hilly, presenting few serious natural obstructions to radio propagation. In the Mud-Slide/Avalanche scenario, the disaster occurs in very hilly or mountainous terrain, breaking the disaster area up into a dozen or more isolated valleys in which relatively small numbers of victims and bystanders are located. The terrain provides natural impediments to radio propagation. Populations range from a few thousand distributed in a rural setting to 50,000 or more in densely a populated area. Assume that 10% of the population are victims and that 50 organizations send relief workers. Exhibit 15-1 National FEMA CONOPS. 27 The author apologizes to any mobile phone companies offended by this notion. To set the record straight, wireless is generally very reliable, even in natural disasters. But in order to make this design study interesting, and relevant to both military and commercial markets, we need a motivation for designing mobile infrastructure. This happened in the earthquake in Turkey because of the lost power grid.
  5. 486 APPLICATIONS Figure 15-3 Illustrative project requirements. B. Requirements Analysis A notional list of requirements for such a system is provided in Figure 15-3. A service provider such as FEMA must decide on the RF bands and modes, maximum number of subscribers, and services to be provided. In addition, the mobile radio equipment must fit in a mobile vehicular platform. For the sake of this example, assume that each radio node is to be configured in a commercial four-wheeled sport-utility vehicle (SUV). This SUV may be equipped with a kerosene-powered electric generator and an electric or hydraulic mast with a limited maximum height (e.g., 10 meters). The number of SUVs should be decided analytically based on GoS, Erlangs of traffic offered per subscriber, and spatial area covered by the mast-based antenna. On the other hand, one may focus on the reconstitution of cellular service and derive a number top-down through similarities and differences. Typical cell sites support 100 simultaneous subscribers. If an arbitrary mix of VHF/UHF, HF, and cellular subscribers is envisioned, then there might be 100 to 200 potential subscribers in each of the two major bands for a total of 200 to 400 users. The peak capacity of each van could then be set at some number between 100 and 400 parallel voice or data channels. The lower the number, the lower the cost of the system. Consider each of the additional requirements in turn. RF bands are selected based primarily on the requirement for “seamless interoperability” of the emergency teams. LVHF is required for SINGCARS, while VHF and UHF are needed for federal, state, and local law enforcement push-to-talk radios and for Have Quick. HF was not explicitly called out. However, if the emergency occurs in a mountainous region, one of the most effective ways of connecting teams operating in adjacent mountain valleys is
  6. THE DISASTER-RELIEF SYSTEM DESIGN 487 HF near vertically incident (NVI) skywave. HF will therefore be included. In addition, the restoration of the cellular telephone service in the United States requires UHF modes in the 850–900 MHz band, as well as PCS modes from 1700 to 2500 MHz. An additional driver for RF coverage is the need to link vans to each other efficiently. Suppose two vans are operating 10 miles apart, each supporting 100 local users. Some fraction of these users will need to communicate with users supported by the other van. The choices include HF, fiber, VHF/UHF, satellite communications, and SHF point-to-point radio relay. HF may provide the connectivity for a small number of channels. But if on the average there will be 20 to 30 calls between the two vans, T-1 (24 channel) or E-1 (30 channel) service is warranted. This level of cross-connect capacity is at the limits of viable HF communications. Suppose we have 10 vans, raising the cross-connect traffic to 200 to 300 channels? HF clearly is not viable in this case. Although it is possible to lay field fiber, this mode is subject to breakage, especially in emergencies. The dynamics of a forest fire, for example, render fiber impracticable. If the system simply allocates VHF/UHF channels for cross-connect (which is possible), the number of subscribers supported in these RF bands at each node decreases proportionally, This may not be a problem for a small number of users, say, 100 per node. Satellite communications historically is expensive, costing from $1 to $3 per minute. At a rate of $1,000 per minute for 300 satellite channels, even the smallest disaster could accrue a large satcom phone bill. Terrestrial microwave, on the other hand, is essentially free (especially to the government who owns the allocated spectrum). It also easily provides T-1 to T-3 levels of service with relatively modest bandwidths and subsystem complexity. For the sake of this example, assume that SHF in the 4, 6, or 11 GHz microwave bands is the high-capacity cross-connect mode. Satcom, on the other hand, might be best for a widely distributed disaster where SHF LOS connectivity cannot be maintained. The subscribers must also be connected to the PSTN. In some areas, the PSTN may employ SHF microwave to protect primary fiber infrastructure. But most service providers in the United States now protect (back up) fiber with other fiber paths. So the vans should have a fiber interconnect port compatible with the SDH and SS7 for interoperability with the PSTN. Since the design of such interconnect is not central to software radios, the sequel will reflect the assumption that the physical interconnect and the necessary driver software are available as commercial off the shelf (COTS) products. The SDR node will have to deliver isochronous streams to the interface and route streams from this interface to radio users. But the design of the interface itself is not central to the SDR. Instantaneous bandwidth, sensitivity, and dynamic range (near–far ratio) are driven by the commercial standards. Most state and local police, fire, and rescue units employ push-to-talk VHF/UHF AM/FM radios. The instantaneous bandwidths range over the set #4, 8 1/3, 12.5, 25, 50, 100$ kHz. Commercial cellular standards, on the other hand, now include the IS-95 CDMA system
  7. 488 APPLICATIONS with its 1.2288 Mchip/second spreading rate with 1.25 MHz bandwidth. GSM only requires 200 kHz of instantaneous bandwidth per burst, but the FH modes can hop over 25 MHz. A software radio implementation of the FH mode requires 25 MHz bandwidth on transmit and on receive. This drives the DAC and ADC requirements. In addition, the dynamic range is set by the 90 dB near–far ratio. To complete the design, each of the areas listed in Figure 15-3 must be analyzed in detail. Chapters 6–15 refer to this example to motivate the discus- sion. C. System Description The system description expresses design decisions. An exemplar for the disas- ter-relief system is as follows. 1. Communications Services The UMC-2000 mobile infrastructure system will integrate the communications capabilities of diverse police, fire, and res- cue organizations. In addition, it will bridge communications of national and international relief agencies with disparate communications equipment into the local disaster-recovery operations. Finally, it will integrate military and national guard communications. Services consist of voice, data, and video-telemedicine. Voice services in- clude voice mail with Enhanced TalkDialTM [443] (ETD) capabilities. Rescue personnel therefore need know only the name of the person or the general cat- egory of function in order to get the right person on the line. The UMC-2000 system manager assigns a virtual telephone number to each participant, and then tracks that participant’s location and communications mode for seamless connectivity. Data services include wireless e-mail. In addition, UMC-2000 establishes a gateway to the PSTN via microwave LOS T- or E-carrier SDH interfaces. It also can link to a local office via fiber. The most important contribution of UMC-2000 is the reduction of confu- sion. Since each UMC-2000 van is equipped with a 30-foot mast, it estab- lishes a cell within which commercial cellular handsets (e.g., of the victims) can operate even when local cellular service has been interrupted by the dis- aster conditions. Organic radios of disaster support teams talk to the local UMC-2000 van for bridging, and they obtain frequency assignments for lo- cal communications from the spectrum management authority using UMC’s SmartSpectrum spectrum management tool suite. 2. RF Bands and Modes UMC-2000 has capabilities in HF, LVHF, VHF, UHF, and SHF. HF AM and ALE provide voice and data circuits using NVI modes in mountainous regions. LVHF coverage integrates contributions of military and national guard units. VHF coverage of the 100 MHz air traffic control band permits coordination with aircraft and the reconstitution of com- munications at an airfield. VHF/UHF push-to-talk AM, FM, and TETRA dig-
  8. THE DISASTER-RELIEF SYSTEM DESIGN 489 Figure 15-4 UMC-2000 hardware block diagram. ital radio modes are supported in all bands, subject to frequency coordination with the UMC-2000 spectrum managers. Additionally UHF cellular coverage includes 1G, 2G, and 3G air interface modes. The RF LANs operate on the 2.5 MHz ISM band so that wireless laptops can be used in the vicinity of the UMC-2000 vans for status monitoring and coordination displays. Telemetry modes permit UMC-2000 to uplink patient status data via wireless and PSTN links to remote medical personnel. Streaming video supports telemedicine. Switching of voice channels is accomplished in software under the control of ETD. The interface to the PSTN employs SS-7 and SDH Levels 1, 2, or 3 trunking through microwave or fiber optic media. 3. Capacities UMC-2000 supports 2000 emergency personnel per node, with up to five vans. The internal capacity of each van is 200 Erlangs of traffic. Band coverage consists of ten subbands from six antenna channels. D. Illustrative Design The design of UMC 2000 includes hardware and software components. 1. Hardware Components An illustrative hardware design is provided in Fig- ure 15-4. HF supports a 6 MHz subset of the HF band, with that 6 MHz tunable between the LUF and MUF. LVHF is accessed in parallel using a 150 MHz ADC. This limits near–far, but this can be operationally controlled by place- ment of the 5 vans within the disaster area. There are three tunable subbands in the VHF range from 88 to 400 MHz. The low subband would access com-
  9. 490 APPLICATIONS mercial broadcast and air traffic. The medium and high subbands are placed for maximum support of emergency personnel, given the capabilities of their equipment. Operationally, to reduce cochannel interference, emergency units are assigned separate uplink and downlink bands to the UMC-2000 nodes, but can communicate among each other using conventional push-to-talk TDD. The two lower UHF subbands are tunable to 1G and 2G allocations; 3G bandwidths of 20 MHz are supported, but only for one CDMA overlay, traded off against the 2G capacity. The upper UHF band supports one PCS band and one RF LAN band. The 11 GHz SHF band was chosen because it minimizes antenna size on the mast for van–van trunking at E1 or E2 rates. The high-speed digital interconnect, in a current implementation, would re- quire three separate SCI-equivalent gigabyte per second buses to interconnect ADC streams to the 200 channel-isolation filters. These are organized into three shelves with the wideband ADCs. Medium-speed Raceway-class inter- connect switches these signals to appropriate C67 DSPs. GSM-class voice and data traffic requires 30 MFLOPS (MF) per Erlang or 6000 MFLOPS. As- suming 60% efficiency of deliverable MFLOPS, 10 C67 DSPs could provide this capacity. The operating point of 50% capacity used then requires 20 C67 chips. Since there are ten bulk streams, two chips (one dual C67 board with local and global memory) are nominally associated with each bulk stream, for 10 Erlangs of traffic per chip. These 10 boards are organized into one DSP pool shelf. For simplicity, the bus hosts are not shown. The DSP pool requires one shelf, and the bulk storage, LANs, hosts, etc. require an additional shelf. In addition, the transmission facilities (DSP pool, up-conversion, etc.) are sized as requiring 25% of the capacity of the receivers, or 4 C67 chips. The dig- ital up-conversion could be based on Intersil/Harris HSPs or Graychip GC4114 quad digital up-converter chips. A shelf of 8 octal boards provides 64 trans- mission channels switched to 10 RF amplifier boards. The system is configured into the van with a control rack (CTL) in the front, the receiving rack (RX) on the left side, and the transmission rack (TX) on the right side of the van. One operator position is provided on the CTL rack for local technical control and mission planning. Five additional wireless laptops are packed for use near the van via RF LAN. Shelf allocations are as follows. Shelf Number Rack Rx ADC, filter 3 RX DSP pool 1 RX Bulk storage 1 CTL Tx DAC, filter 1 TX Tx amplifiers 2 TX The back of the van has a swingaway auxiliary power unit kerosene- powered UPS to supply the substantial power requirements of the DSPs and
  10. EXERCISES 491 RF transmission system. Antenna-mast design minimizes EMI/RFI with phys- ical separation, insulators, etc. This is one of the highest-risk areas of the system. 2. Software Components Software consists of AM, FM, and vocoder algo- rithms for voice, AMPS for 1G cellular, Digital AMPS and IS-136 licenses, and a GSM suite for the cellular bands. TETRA, DECT, and PHS/PDC mod- ules have been identified that are compatible with the DSP platforms, and are licensed as needed. HF ALE, GPRS, and V.xx modem software provide data connectivity. MS Office with Access and Outlook provides word pro- cessing, database, and e-mail. Netscape and Internet Explorer are included for Internet services. WAP and the default SDR services recommended in the layered virtual machine architecture are provided as COTS packages as well. RF CAD [444] is used for propagation prediction to site the vans and to assist in managing spectrum allocations. III. ARCHITECTURE IMPLICATIONS The above reference design is just one of a family of designs ranging from much more conservative to very aggressive. It is representative of the level of technology available in the 1999–2000 time frame. Given the extensive tradeoffs associated with each aspect, this brief treatment cannot do justice to the design of such a system. It is provided as an integrated example of one point in the large, complex evolutionary path of software radio technology. In order to support an enterprise architecture, the hardware components of Figure 15-4 need to be identified with a migration plan. The 200 discrete digital isolation filters, first of all, could be replaced with multi-channel ASICs within 2–3 years. The digital interconnect and ADCs/DACs could be upgraded in 3–5 years. To support industry-standard open architecture, the software components could be based on CORBA, following the SDR Forum. Since the C6 does not yet support CORBA, one might work with a third-party software supplier and/or TI toward this goal. IV. EXERCISES 1. Work through a use-case scenario with the design of Figure 15-4. What questions arise that would revise the design substantially? 2. Address question 1 using a UML tool such as Rational Rose. What were the benefits of UML? Of the tool? 3. Develop the rack elevations for the design of Figure 15-4. What engineering issues arise? What bus did you choose (VME, PCI, other)?
  11. 492 APPLICATIONS 4. Represent the waveforms of II.D.2 as objects. Can the performance of II.C be achieved? If not, how can this be fixed? 5. Re-do the ADC tradeoffs for 90 dB near-far in all bands without loss of RF coverage. How many parallel channels are needed? What is the impact on rack elevations? On software?
Đồng bộ tài khoản