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 receiver object interface functions. Receiver Object Interface Functions • CReceiver(.) – This constructor (and derived-class constructors) sets up the initial state of the object and the hardware to which it is connected. • Configure(.) – Sets the state of the receiver object based on the user’s input. This method defines which configuration options are presented to the user based on the hardware type with which the class is associated. • Initialize(.) – Prepares the hardware by setting up the hardware with the desired configuration and confirming that hardware has been set up successfully. • GetSignal(.) – Retrieves raw signal data from the hardware, scales the data with calibration constants, and obtains the sample rate of the data snapshot. The hierarchical relationships among the receiver object classes are illustrated in Figure 3-6. The CReceiver class handles the generic methods for all classes that are derived from CReceiver. CReceiver and CGpibDevice are abstract classes and therefore cannot be instantiated alone. The CGpibDevice class handles GPIB (IEEE-488) interface functions; the GPIB interface is used for communications with the oscilloscope that samples the IF channels. The CGpibDevice class handles opening the connection to the GPIB device, checking for errors, and managing GPIB addresses. Any GPIB device can use an object derived from this class for communications. The CTekScope class is derived from the CGpibDevice class and provides methods specific to interface with a Tektronix oscilloscope. The CTekScope class has been tested with the Tektronix TDS 580 and TDS 520 oscilloscopes. Specific routines for communicating with the TDS oscilloscopes are encapsulated in the CTekScope object and are far removed from the software radio processing code, relieving the signal processing programmer from the need to fully understand the hardware interface software. The measurement receiver software uses a pointer to a CReceiver object, so that through polymorphism any object of a class derived from CReceiver can be used transparently, and the correct methods for the appropriate class will be called. CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 62 CReceiver CGpibDevice CTekScope Handles generic methods for all receiver objects. Handles methods for GPIB devices. Handles methods for Tektronix devices. Figure 3-6. Class hierarchy of hardware-specific receiver objects. 3.7.2 Radio Receiver and Processing Functions The radio receiver and processing modules perform all of the signal processing on the acquired signal data. The modules exist in the form of objects in the measurement receiver, and multiple processing objects can be instantiated simultaneously to operate on data in parallel. Radio receiver functions are classified as operations that are performed on raw signal data at the modulation or waveform level. Processing functions are categorized as operations that require processed data to perform statistical characterization or symbol-level decoding. These objects together implement both simple and complex operations such as narrowband receivers, directsequence spread-spectrum receivers, channel characterization algorithms, and antenna diversity algorithms. Radio receiver functions and processing functions can be combined into a single object depending upon the complexity of the operations. Generally, functionally complex algorithms should be compartmentalized to facilitate design and maintenance of the software. 3.7.3 Display/File Interface Functions After processing, the data generally needs to be displayed or stored to disk. The interface objects are responsible for this task, and multiple objects can operate on the same processed data. The interface objects take the processed data and display it on a graph or table, or alternatively the processed data can be stored to disk. Existing display interfaces include plots of power-delay profiles, histograms, cumulative distribution functions (CDFs), and frequency spectra. Displays also include tables of computed signal data (for example, received power). A data logging object has also been developed that stores raw IF samples, sample rates, time stamps, and calibration parameters to disk continuously as the measurement receiver is running. CHAPTER 3 – A MULTI-CHANNEL, SOFTWARE-DEFINED MEASUREMENT RECEIVER 63 3.7.4 Multithreading and Inter-Object Communications Objects in the measurement receiver communicate through messaging and shared memory space. An illustration of the communication paths within the receiver software is shown in Figure 3-7. The RF hardware of the measurement receiver is represented by the box on the left side of the figure, and the display and storage media is represented by the boxes on the right side of the figure. In between these components is the software of the measurement receiver, with each oval representing an object or module of the system. The operations of the entire system are either controlled or launched by the System Exe object at the top of the diagram. This object is responsible for accepting instructions from the user for configuring the receiver, launching processing objects, logging data to disk, and overall control of the measurement receiver. The System Exe object is the central point in the software through which all objects can communicate. Matlab Applications Data Logging System Exe