Kiến trúc phần mềm Radio P5 docx

Softwar e Radio Arc hitecture: Object-Oriented Approac hes to Wireless Systems Engineering Joseph Mitola III Copyright c !2000 John Wiley & Sons, Inc. ISBNs: 0-471-38492-5 (Hardback); 0-471-21664-X (Electronic) 5 Node-Le vel Ar chitecture Analysis This chapter analyzes node-level software radio architecture. Attention turns to the internal functions, components, and design rules within a radio node. The canonical node architecture partitions software-radio functions into seg- ments within which functions are functionally cohesive, and between which the segments are data-coupled. T his approach conforms to well-established principles of structured design [183, 184]. SD has been superseded in contem- porary practice by object-oriented technology (OOT) [185]. SDR precursor systems to which the author contributed were organized according to the SD principles of functional cohesion and data coupling. Message passing was a necessity for distributed processing among multiple minicomputers and micro- processors. These high-end military command-and-control systems employed federated parallel processing. Full-custom ASICs and s pecial-purpose digi- tal signal processing boards were integrated with a dozen minicomputers and over 100 Intel-8080-class microprocessors to create early cutting-edge signal processing capacity. This progenitor technology anticipated the emergence of commercial DSP chips and boards by about ten years. The design principles of functional cohesion, data coupling, and message passing developed then apply to software-radio architecture today. The military progenitor systems, however, prioritized mission effectiveness, maximizing technology insertion with cost as a relatively unconstrained variable. In the application of SDR technology to both military and commercial domains today, cost is a highly constrained input-variable. Therefore, the node-level architecture analysis treats cost and other externally imposed design constraints (e.g., standards) as explicit design rules. OOT has matured the foundation principles of SD, adding features that pro- mote software reuse. For example, UML, as an OOT computer-aided software engineering (CASE)-tool, integrates complementary views of a collection of objects. Use-case scenarios, logical structure, components, and deployment aspects may be developed independently, but UML assures that they are con- sistent for the set of objects being defined. This chapter develops the SDR node-level application of OOT and UML. This is not merely another treatment of object-oriented design. Instead, architecture emerges as an object-oriented framework for the peaceful coexistence of o therwise mutually incompatible (structured, object-oriented, and ad-hoc) designs. As DSP technology has 171 172 NODE-LEVEL ARCHITECTURE ANALYSIS Figure 5-1 Aspects of architecture. developed, available processing capacity has increased according to Moore’s Law. Radio functions have been packaged into analog RF, digital hardware, and software many times. A slow ly evolving set of functions has been re- peatedly rehosted into a rapidly evolving set of (hardware-intensive) compo- nents. Node-level design principles have evolved through this process into the software-radio architecture strategy defined in this chapter . I. ARCHITECTURE REPRESENTATION As illustrated in Figure 5-1, an architecture is a framework in which a specified family of functions may be accomplished via specified classes of components according to specified design rules. In this figure, architecture is represented as a collection of associated concepts with little obvious structure. The node-level analysis of software radio architecture begins with the organization of hard- ware components so as to maximize software flexibility. The hardware com- ponents include wideband antennas and RF/IF processing, wideband ADCs, DACs, parameter-controlled ASICs, FPGAs, DSPs and general-purpose pro- cessors. The software components consist of data structures and procedures organized into software objects. The analysis process begins with an exami- nation of consistency and conflicts among functions, components, and design rules. Consider the static hierarchies illustrated in Figure 5-2. These functions, components, and design rules characterize a top-level radio function. In this case, the function is to “transduce voice from [auditory] compression waves to radio waves.” This function may be implemented via a processing thread that ARCHITECTURE REPRESENTATION 173 Figure 5-2 Radio architecture map. begins with the microphone. The ADC component converts the signal from the microphone into a sampled baseband signal. A DSP algorithm vocodes the voice waveform efficiently, and another imparts the channel coding. A baseband DAC converts the signal to analog so that analog IF/RF stages can up-convert and impart it to a carrier. In this representation o f architecture, the mapping between the “voice trans- ducer” function and the hardware and software components are more explicit than in Figure 5-1. In addition, the relationship between components and de- sign rules has been made explicit. During the design stages of a project, the emphasis is on allocating functions to components. The components also are subject to the constraints of design rules. During the integration stages, the emphasis shifts to the verification that components implement functions while adhering to the design rules. Business considerations create another dimension of design rules. A need to control costs may be met through the reuse of a (notional) “Sanyo enclo- sure.” That module brings packaging constraints. These may violate thermal design rules. Many subsystems will be overspecified or overconstrained. One must therefore sacrifice some performance constraint or violate some design rules slightly to achieve a realizable, affordable design. During development, the components must be verified to accomplish the allocated functions. They must be tested to assure compliance t o type-certification design-rules, such as radiated power and EMI limits. Continuing with Figure 5-2, the middle series of boxes (e.g., “Acquire Voice,” “Microphone,” etc.) shows how one might hierarchically decompose the top-level functions. The resulting sequence of subordinate functions may be associated with other subordinate components. These are associated with other design rules. Reading across the figure, the subordinate function “acquire voice” is allocated to a microphone component. This notional component has a 174 NODE-LEVEL ARCHITECTURE ANALYSIS Figure 5-3 View of a traditional function hierarchy. built-in analog compander. The notional VCELP codec complies with the de- sign rule “avoid banjoman.” Th ere is a condition in GSM when the RPE-LTE algorithm resonates due to bit errors in a way that sounds to Americans like someone is playing the banjo, making a twanging sound. VCELP avoids this sound under severe BER conditions. The associated design rules encompass power, packaging, design, and performance issues. This yields an interlocking web of constraints that can easily become tangled unless subjected to rigor- ous engineering discipline. One simple but reliable engineering discipline sug- gested in the figure is the identification of one-to-one relationships between functions, components, and design rules. One-to-one (1 : 1) relationships lo- calize the issues associated with tradeoffs. With 1 : 1 relationships, the steps needed to meet specific technical, performance, or schedule goals are clearly allocated a specific subsystem or component. This greatly simplifies the trade space, reducing the time and effort required to reach design decisions. A. Functional Design Hierarchies The structure of a representative functional design hierarchy is illustrated in Figure 5-3. This is a three-dimensional view, with input on the left, output on the right, and higher levels of abstraction organized vertically. The top-level function “transduce voice” is hierarchically partitioned into the subordinate ARCHITECTURE REPRESENTATION 175 functions “acquire voice,” “code voice efficiently,” and “impart to carrier.” These three functions accomplish the isochronous signal flow as shown in the bold arrows. The user interface and the packaging of control data is accom- plished in the companion flow of control messages. The structured design (SD) concepts of cohesion and coupling provide con- crete criteria for partitioning the software into modules. Cohesion is the rela- tionship among elements within a module. Functional cohesion is the tightest and hence most desirable kind, representative of the relationship b etween a function and its arguments. Yourdon defined other types of cohesion ranging from functional as the tightest to incidental as the loosest. In incidental co- hesion, functions in a module share little or no relationship with each other. Modules may be coupled to each other through passing data (e.g., message passing), the loosest form of coupling. They may call each other, which is a tighter form of coupling. If they exercise internal control over each other’s internal functions, or cause unanticipated side effects, they are maximally cou- pled. Data-coupled modules may be changed independently with no side ef- fects. Data coupled, functionally cohesive modules are the ideal. Techniques for getting to well-structured designs include the creation of functional flow diagrams and descriptions (F2D2). In Figure 5-3, the lowest level is represented in F2D2. A sequence of rigorous descriptions of the func- tions and interface are included in a formal F2D2 product. One also must examine the interfaces among the resulting modules (e.g., the coupling of the modules) by creating an N 2 diagram. This is a matrix with modules listed on the rows and columns. The values in the matrix represent the interfaces among the modules. The analysis process should yield interfaces that are well defined, complete, and consistent. To go beyond design into architecture, one must consider a collection of dif- ferent designs. The collection of designs should include designs produced by different teams a t the same time, and designs that evolve over time. Consider the reuse of the software components that resulted from the functional decom- position above. A serious difficulty in the reuse of such software components becomes evident trying to map a functional component, the voice processing thread, into the hardware and software configuration hierarchies (Figure 5-4). The configuration hierarchies express packaging for configuration manage- ment. The figure shows a configuration hierarchy within which the notional handset’s voice transducer could be configuration-managed. The Mobile Sta- tion (MS) hierarchy includes hardware and software components. As illus- trated, the voice processing functional thread is distributed across codec, pro- grammable RF IC, and TMS320 DSP chip. Which software functions are al- located to which components? This is not clear because the functional compo- nents are distributed in dedicated hardware and in software algorithms. A high- quality architecture framework therefore should help one express the func- tional components in an intuitively appealing, but implementation-independent way. That framework must also map these slowly evolving functional compo- nents to the rapidly evolving hardware and software components. 176 NODE-LEVEL ARCHITECTURE ANALYSIS Figure 5-4 Configuration hierarchies obscure functional relationships, increasing the cost of component reuse. Figure 5-5 Design rule hierarchies further complicate design t radeoffs. Design rule hierarchies complicate matters further as suggested in Figure 5-5. Design rules may be driven by customer-centric marketplace values in- cluding quality and aesthetics. Competition-centric values such as adherence to standards for compatibility and reuse of components for low cost may take on a central role in some design tradeoffs. ARCHITECTURE REPRESENTATION 177 Figure 5-6 Design rules from complementary disciplines feed a design-rule reposi- tory. When design rules are in harmony, the design tradeoffs are straightforward. Keeping subjective quality high, adherence to standards, and low cost harmo- nize in the narrow choice of a voice-coding algorithm. They are often not in harmony, however. There may be a conflict between reusing components and driving the form factor to a reduced thickness. Algorithm tradeoffs often in- fluence size, weight, and power in a handset. The robust algorithms generally require more processing capacity and hence more powerful, power-hungry chips. It is thus helpful to find a design framework within w hich the entire set of issues related to functions, hardware and software components, and design rules are most manageable. The open-architecture framework should impose the minimum design rules necessary to insure that architecture objectives are met. The objectives of open- architecture are often mutually contradictory. For example, open-architecture needs to both promote commonality and encourage competition. Commonal- ity means buying components of one design, while competition requires one to buy components from multiple suppliers. The solution to this technical quandary invariably rests on a social process of letting competing interests pull in opposite directions until everyone is equally unhappy, but still willing to participate in the architecture. Architecture analysis facilitates that process by making the tradeoffs clear . It can also facilitate the process by providing mechanisms that allow one to hide or safely ignore contentious issues. For ex- ample, the banjoman phenomenon applies only to a particular GSM vocoder. The avoid-banjoman rule may be hidden as a vocoder-specific constraint in a multistandard open-architecture framework. Once the banjoman phenomenon becomes known, however, that knowledge should be retained for future use in appropriate circumstances. An enterprise-architecture repository of design-rules can serve this pur- pose. The design-rules repository of Figure 5-6 illustrates such a knowledge 178 NODE-LEVEL ARCHITECTURE ANALYSIS repository. An enterprise may maintain its own repository of s uch rules, com- prising part of its own intellectual property and competitive advantage. With the growth of open taxonomies on the World Wide Web, an open design-rule repository for software radio could emerge as a network of web- accessible domain-specific design rules. Industry bodies seeking to promote open soft- ware-radio architecture could adopt the minimum set of design rules neces- sary to insure the benefits of the open-architecture framework. It could defer the majority of the design rules to (centralized or distributed) design- rule repositories. Those developers with a vested interest in sustaining the knowl- edge required to successfully integrate hardware and software components into functioning systems that obey all relevant design rules would cooperate to maintain shared design rule repositories, e.g., in a users’ group. B. Object-Oriented Approaches Object-oriented design incorporates the core strengths of SD, while increasing the cohesion among data and algorithms. Objects encapsulate functionally cohesive components. SD criteria assist one to decide which software functions should be coalesced into an object. There are incidentally cohesive objects, as well as functionally cohesive objects. The incidentally cohesive objects built in C++ can be as hostile to reuse as spaghetti-coded FORTRAN. One mayuseOOTasawaytomoveforward,buildingonestablisheddesign principles including SD and message-passing. One may then build on the principles of functional cohesion and data coupling in defining SDR object boundaries. OOT makes significant progress beyond the basics, however, as illustrated in Figure 5-7. Objects encapsulate data and associated procedures, called meth- ods, into a single software entity. Object classes are reusable by definition. Objects are instantiated from classes and new classes are d efined i n terms of existing ones. The figure illustrates the reuse case in which three existing object classes are merged to quickly create a vocoder. The assumption is that the developer has experience with voice coding, having developed a general vocoder class and other voice processing algorithms. The general voice-codec class, first of all, would define primitive digitized-signal flows. This could in- clude double buffering and clock-synchronous delivery of speech data to the modem stream. SDR applications of OOT emphasize the isochronous opera- tion of such multi-object processing threads. A more specific class, the RPE-LTP algorithm of GSM, may be based on this general-purpose voice codec class. A notional Regular Pulse Exciter (RPE) vocal tract modeling algorithm is then combined with a Long-Term Predictor (LTP) analysis/synthesis and filtering algorithm. The new algorithm inherits the properties of each of these existing algorithms. This includes slots for data embedded in the objects. It also includes attached methods that define object behaviors. Newly created classes may override behavior from ancestor classes by declaring their own local methods. ARCHITECTURE REPRESENTATION 179 Figure 5-7 Object hierarchies promote software reuse. Objects are coupled by message passing, institutionalizing as it were the good practice of data-coupling software modules. Message passing is a gen- eralized form of remote procedure call since most messages need a response. The response may be regarded as a value returned from a procedure call. Mes- sage passing that requires the sending object to wait is, in fact, equivalent to a procedure call. Threaded message passing, however, does not require the sending object to wait for the response. Java’s threading facility [186], for example, implements this aspect of OOT. Messages may invoke public methods and may access public data struc- tures, which the object makes available to the outside world. Objects may also use private data structures and methods, promoting reuse in another di- mension. In the example, the “convolve” operation has been defined earlier. Convolution is a common operation that may be useful in both RPE-LTP and a channel demodulator. Convolve( ) 23 is not a public method of RPE-LTP, but it is an internal operation from which the class is composed. The demodulator also employs Convolve( ). Thus the Convolve( ) operator may be drawn from a general-purpose library and used in both objects as a private method ac- cessible only by members of the RPE-LTP (or demodulator) class itself. This approach effectively reuses the existing Convolve( ) code. 23 Methods and function calls are indicated by the notation MethodName( ), by OOT convention. 180 NODE-LEVEL ARCHITECTURE ANALYSIS Figure 5-8 Radio platform model integrates hardware and software characteristics. There are several perspectives from which one may define objects like the vocoder or Modem. Some constraints on the vocoder may be evident from a use-case vignette that characterizes Q oS. Working through such scenarios allows one to define objects in terms of their interactions with external enti- ties. T his is called use-case analysis . Other constraints m ay become evident in packaging the vocoder for deployment in an ASIC. This brief introduction highlights aspects of OOT that are relevant to soft- ware-radio architecture. OOT provides the analysis and system design frame- work for software design de veloped in later chapters. The core notions of OOT include the encapsulation of objects by defining public slots and meth- ods. Property inheritance allows specific objects to inherit slots and methods from more general classes of objects. OOT facilitates message passing as a generalized procedure call. It then couples object instances into a cooperative distributed processing framework, including support for multiple independent execution threads. Polymorphism a lso helps software developers gracefully extend existing functions to new data structures and behaviors. Related OOT literature includes introductory texts [31] and in-depth treatments of object- oriented design for real-time systems [187]. C. Reference Platform Integration OOT is readily extended from software design to hardware, software, and systems integration. Figure 5-8 illustrates an object-oriented way to define the relationship between hardware and software. The software provides the per- [...]... analysis of software -radio architecture, without making this a text on UML 3 Radio Classes, Subclasses, and Instances The example of Figure 5-10 shows the attributes of the class Voice Radio, as well as the specific values of those attributes at some point in time on My Radio and Your Radio At some point, it will become clear that My Radio is just an AM/FM broadcast receiver, while Your Radio is a push-to-talk... notation in the model of Figure 5-10 The legend shows that the solid box represents a class, a generic object that embodies the concept of a voice radio The dotted boxes, in this case, are instances So My Radio “is a” voice radio, and Your Radio “is a” voice radio The lines connecting the boxes represent relationships among objects In this case, the IS-A relationship is useful The arrow points from the... push-to-talk (PTT) transceiver If that difference is important, two subclasses of Voice Radio could be created The creation of subclasses makes it easier to recognize members of the class For example, My Radio has no microphone, so its Transmit() function is null One can represent My Radio as an instance of Voice Radio that has a null Transmit() function If it is clearer or more helpful to the architecture-definition... conversion, and IF processing determine the radio node’s access to the RF environment A radio design would specify the parameters of each of these segments Architecture, on the other hand, specifies the absolute minimum necessary to assure that a specific radio function will be supported by the RF platform It is convenient to encapsulate a consistent set of radio functions that implement an air interface... 5-18 In this model, all radio nodes provide functions that are delivered via components 198 NODE-LEVEL ARCHITECTURE ANALYSIS Figure 5-18 UML model of the canonical form (simplified) that obey the appropriate design rules The arrows all show inheritance relationships from the generic radio node class of object The domain (e.g., handset, cell site, vehicular radio) property of the radio node is therefore... and/or communications security According to the best INFOSEC practice, there should be as much physical separation as possible between the black and red bitstreams Therefore, many radios, including most military radios, divide the radio hardware into a black half and a red half, joined by the INFOSEC module (Figure 5-17) The antenna, RF, IF, baseband, and encrypted bits fall on the secure or black side... capabilities and default values of slots and behaviors Figure 5-12 UML-like representation of a voice radio E A Topological Model of Architecture24 The need to efficiently map radio functions to hardware configurations leads to the study of the mathematical foundations of system architecture There are few When two radio systems engineers with different backgrounds approach a systems-level design problem, they... industrystandard open architecture hardware like PCI, however 2 Refined Radio Reference Platform The analysis of this section may be consolidated into a refined radio reference platform that extends the simple platform introduced in Chapter 1 (Table 5-4) This introductory treatment pro- 206 NODE-LEVEL ARCHITECTURE ANALYSIS TABLE 5-4 Refined Radio Reference Platform Parameter Specification Remarks System Level... architecture-definition objective, a Broadcast Receiver class may be defined, as illustrated in Figure 5-11 4 Components in UML The structure of the components of the radio may also be expressed in UML, as in Figure 5-12 From one’s knowledge of radio, it should be clear that the arrows represent the way in which one object is a component of another The intervening classes are not populated, but the leaf... delay) are the behaviors of the composite radio that are defined through balancing the demands of the personality against the capacities of the host components ITU-T recommendation H.320 [188] for video-teleconferencing and Microsoft’s TAPI [189] plug-and-play specifications both incorporate the capabilitybased approach for plug-and-play Since the implementation of radio platform capabilities strongly influences . a voice radio. The dotted boxes, in this case, are instances. So My Radio “is a” voice radio, and Your Radio “is a” voice radio. The lines connecting the boxes represent relationships among objects node-level software radio architecture. Attention turns to the internal functions, components, and design rules within a radio node. The canonical node architecture partitions software -radio functions. of software -radio architecture, without making this a text on UML. 3. Radio Classes, Subclasses, and Instances The example of Figure 5-10 shows the attributes of the class Voice Radio, as well