Radio Channel Measurements and Modeling for Smart Antenna Array Systems Using a Software Radio Receiver

data types: Abstraction is the act of representing something without including background or inessential detail [p.10 Gra94]. An abstract data type is an abstraction that encapsulates the components of a set of objects. Abstract data types are defined by the programmer rather than being specified in the particular programming language. The abstract data type defines both attributes and methods for objects, and hence the programmer can completely define the behavior of objects. Hierarchical Organization (Inheritance): Classes of objects are organized in a hierarchical fashion, where one class can inherit the methods and attributes from other classes. If Class D (a derived class) is derived from Class B (a base class), then some or all of the methods and attributes of Class B can be made available for use by Class D. This allows derived classes to become more specific in their abstraction while maintaining commonality with the base class and other classes derived from the same base class. Inheritance provides a method of distinction between the general properties of an entity and the properties of a specific entity [p.21 Str91]. Polymorphism: Polymorphism allows selection between redundant methods or attributes using the context in which the methods or attributes are referred [p.70 Sul94]. This concept allows software modules to be developed separately and provides a mechanism for forward compatibility software. With polymorphism, calls to methods that do not yet exist can be handled, and those methods can be added or modified in the CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 57 future. Polymorphic references are resolved within a particular class hierarchy, allowing a base class to handle references that are not resolved in the derived classes, and permitting derived classes to override the methods and attributes in their own base classes. Message-passing mechanism: Generically defined in the context of object-oriented programming, a message is a query given to an object that requests execution of one of the members of that object [p.23 Kri96]. A message consists of a selector and arguments, which specify which method should be called and the parameters to be passed to the method. Objects can use messages to perform an operation or to transfer information, between two objects or among multiple objects. 3.6.3 Application of Object-Oriented Methods to Software Radios The overhead of object-oriented design and programming makes object orientation appropriate only for large software systems. Because of the multifaceted complexity of software radio programming, it is a probable candidate for object orientation, especially if the software is developed by a group of programmers, or if the software is intended to be reusable and have a long life with multiple revisions. The following list summarizes the more important benefits of using object-oriented programming for software radio projects, adapted from the generic object orientation benefits [p.31 Gra94]: • Classes designed for object-oriented software radios form a library of reusable modules that can be used by future projects, resulting in a reduction of redundant effort and an increase in development productivity. • As reusable software modules become mature through use, the quality and reliability of the modules increases, resulting in fewer software deficiencies and a more useable library of software radio blocks. 14 For generic object-oriented design, it is implied in [Kri96] that passing messages is the only method of communication among objects. However, in practice, programming languages such as C++ and development environments such as those using Microsoft Foundation Classes distinguish between calling of methods and passing of messages. Methods of an object can be called directly using the function name and associated parameters, while messages are received by an object’s message handler methods, which may call other methods of the object. CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 58 • Using object-oriented programming allows software radio modules to be developed independently or in parallel through inheritance. Developers can interface with functionally incomplete classes until such time in development or testing where the objects need to perform a required operation or provide required data. • The message passing mechanism of object orientation provides a straightforward interface to software modules and defines a clean break between modules for minimal coupling and interdependency. • Encapsulation inherent in object orientation naturally divides a complex programming task into manageable subtasks, increasing the likelihood of successful completion and yielding modules that are scalable for other projects of more or less complexity. The benefits of object orientation come at the cost of planning time, development speed, and software overhead: • Variable referencing and function calling are context-sensitive, requiring overhead embedded in the program [p.5 Sul94]. • Reliance on a compiler to be efficient in minimizing processor instruction cycles and occupied code space. • Increased effort required for planning, organization, and preparation at the beginning of the software development cycle. • Reduction in upfront development speed when attention is devoted to the architecture rather than signal processing functionality [p.5 Sul94]. As more functionality is integrated in to the software of radios, and as additional radio communication standards need to be handled by a single device, the size and complexity of software radio projects will continue to increase. Because of this trend, the benefits of objectoriented programming techniques will progressively outweigh the costs, an assertion supported by case studies of other large scale software applications and their migration to object technology [p.50 Gra94]. CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 59 The applicability of object technology to the growing complexity of wireless communications is evidenced by emerging wireless architectures. In [Moe99], the network entities rather than internal radio entities are abstracted to objects. The same methodology applies, however, in that the functionality of a network object is encapsulated, and external entities are separated from the object’s workings and behavior. An interface is defined for use by outside objects and is the means by which communications occur. While [Moe99] defines objects to be wireless network nodes between which network traffic is passed, the measurement receiver described here defines objects to be radio modules between which signal data is passed. In another reference [Dav99], concepts of abstraction, encapsulation, messaging, and object-orientation in general are used in the communication architecture of a software radio to allow portability of software radio applications and dynamic instantiation of objects. In both references cited, object orientation is aimed at organizing the components of complex radio systems and facilitating scalable and maintainable architectures. 3.7 Measurement Receiver Software The architecture of the measurement receiver software was designed in such a way as to allow implementation of a variety of radio applications. The functionality of the software can be broken into several stages as shown in Figure 3-1. This figure shows a data flow representation of the measurement receiver, where signal data is distributed and processed successively through the software modules, beginning at the hardware receiver object and ending at the user interface that displays processed results. In this section the following topics are covered to explain the measurement receiver software: • Signal acquisition with the hardware-specific receiver object • Radio receiver and processing functions • Display/file interface functions • Multithreading and inter-object communications • Automatic gain control • Example of measurement receiver software application CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 60 The architecture described here, including the logical division of functionality into objects and the method of inter-object communications within a software radio, was originally developed for the research presented in this dissertation. SW Receiver 1 SW Receiver 2 . . . SW Receiver n Signal Acquisition Radio Receiver Functions SW Processor 1 SW Processor 1 SW Processor m HardwareSpecific Receiver Object R eciver H ardw re Hardware Software Display/File Functions Interface 1 Interface 2 Interface k . . . . . . Processing Functions • Oscilloscope-based acquisition • Multi-channel PC acquisition card • DS-SS receiver • Narrowband receiver • Channel characterization • Wideband diversity • Narrowband diversity • DOA algorithms • Impulse responses • Diversity metrics • DOA displays . . . R eciver H ardw re . . . . . . Figure 3-5. Flow of signal data through the processing of the measurement receiver software. 3.7.1 Signal Acquisition with the Hardware-Specific Receiver Object The hardware-specific receiver object is responsible for communications between the external hardware and the measurement receiver software. Hardware configuration routines and signal acquisition functions are encapsulated by the receiver object in order to sever coupling between the radio processing objects and the RF hardware. This means that the processing objects can work independently and without knowledge of the type of RF hardware to which they are connected. To exploit the benefits of polymorphism, the hardware object is defined in a hierarchical class structure, and a standard set of interface methods are defined. These standard methods allow new hardware to replace old hardware without breaking code downstream in the data flow. CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 61 Table 3-8. Description of the generic hardware-specific recei