Changes between Version 33 and Version 34 of PHAL-OE_Concept
- Timestamp:
- 01/29/09 22:32:37 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PHAL-OE_Concept
v33 v34 1 1 2 == PHAL-OE Concept and Motivation ==2 == ALOE Concept and Motivation == 3 3 4 4 5 The PHAL-OE concept tries to address the main issues related with the Software Radio technology. It assumes the need of supporting, partial or total, reconfiguration of the radio processing chain, the need to deploy the radio application onto a heterogeneous hardware platform capable to assume the high computing requirements of modern wireless systems, the need to assure strong real-time execution constraints, the need to easily develop and integrate software modules and the possibility to execute them in different types of processors assuming an easy portability.5 The ALOE concept tries to address the main issues related with the Software Radio technology. It assumes the need of supporting, partial or total, reconfiguration of the radio processing chain, the need to deploy the radio application onto a heterogeneous hardware platform capable to assume the high computing requirements of modern wireless systems, the need to assure strong real-time execution constraints, the need to easily develop and integrate software modules and the possibility to execute them in different types of processors assuming an easy portability. 6 6 7 One of the most relevant objectives in the process of defining a common framework to develop and deploy software radio applications is to eliminate platform (hardware and support software) dependencies. In this context, the possibility to add as much processing resources as required for a given application, making not necessary to change it at all, is of must importance. The possibility of (re)configuring the radio terminal and/or the base station built by using different hardware from different providers requires the capability of adding (and removing) plug-and-play hardware to (from) the system. Different hardware topologies, configurations and, above all, assigned tasks impose restrictions on the integration of different hardware to construct software radio platforms. All these objectives have pushed us to define and develop a multi-platform software abstraction layer and execution environment, PHAL-OE (Platform-Hardware Abstraction Layer Operating Environment), capable to provide such features.7 One of the most relevant objectives in the process of defining a common framework to develop and deploy software radio applications is to eliminate platform (hardware and support software) dependencies. On the other hand, radio applications are built through a set of software modules (hardware or software based) that communicates among them. The common used terms denominates such modules as “objects”. Therefore each one of such objects are signal processing blocks, some of them with important requirements in terms of computing resources, that needs to acquire/deliver information from/to other objects through proper interfaces. Nevertheless, one of the most relevant assumptions of PHAL-OE is that such interfaces between objects are unknown at object development time. Only at execution time all the required objects will be integrated and the entire radio application will be built. 8 8 9 On the other side, from the point of view of radio application, it is commonly assumed hat such radio application is built based on a set of software modules (hardware or software based) that communicates among them. The common used terms denominates such modules as “objects”. Therefore each one of such objects are signal processing blocks, some of them with important requirements in terms of computing resources, that needs to acquire/deliver information from/to other objects. Thus, the first step would be as simple as provide the mechanism to the application to deal with these input/output interfaces. Nevertheless, one of the most relevant assumptions of PHAL-OE is that such interfaces between objects are unknown at object development time. Only at execution time all the required objects will be integrated and the entire radio application will be built. 9 [[Image(ALOEV0.png, 400px, align=right)]] 10 10 11 With these ideas in mind we initiated the development of the PHAL-OE concept. The list of the main functionalities where the PHAL-OE must provide support on includes:11 All these objectives have pushed us to define and develop a multi-platform software abstraction layer and execution environment, ALOE (Abstraction Layer & Operating Environment), capable to provide such features. The list of the main functionalities where the PHAL-OE must provide support on includes: 12 12 13 13 • Flexibility. The framework must efficiently implement the flexibility concept required by SDR. It is assumed to be based in the capacity to facilitate the reconfiguration as the basic mechanism providing flexibility. … … 30 30 31 31 32 [[Image(ALOEV0.png, 400px, align=right)]]33 34 32 == PHAL-OE Concept & Layers == 35 33 36 37 34 Previous figure tries to illustrate the PHAL-OE concept. On the bottom we can see the Hardware Layer where we can found several processors or Processing Elements (PE) physically interconnected among them. On top of the figure we can see the Abstract Application Layer where a graph of a radio application tries to define the required tasks (objects) and the data flow among them. In the Real Application Layer we can see the previous tasks but using the services or functionalities provided by PHAL-OE to build coherently the radio application. On th PHAL-OE Layer we observe that from the point of view of the tasks (objects) conforming the radio application all them only see the same platform, the PHAL-OE Platform, not being aware of any detail related with the hardware. On such layer, but from the hardware point of view, we can find the specific implementation of the PHAL-OE functions for each one of the processors used to build the entire Hardware Layer.
