Changes between Version 13 and Version 14 of PHAL-OE_Concept

Timestamp:

11/11/08 16:10:27 (16 years ago)

Author:

antoni (IP: 147.83.105.182)

Comment:

--

PHAL-OE_Concept

@@ -1 +1 @@
 
-First and basic step to advance in the process of defining a common framework to de-velop and deploy software radio applications is to eliminate platform (hardware and support software) dependencies. Next step is making simpler to specify radio applica-tions, worrying only about algorithm description.  
+First and basic step to advance in the process of defining a common framework to develop and deploy software radio applications is to eliminate platform (hardware and support software) dependencies. 
+Next step is making simpler to specify radio applica-tions, worrying only about algorithm description.  
 
-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 with 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, as-signed tasks impose restrictions on the integration of different hardware to construct software radio platforms. Due to these and the previously stated objectives, a multi-platform software abstraction layer and execution environment, P-HAL (Platform-Hardware Abstraction Layer), has been defined and designed to provide such features.
+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, as-signed tasks impose restrictions on the integration of different hardware to construct software radio platforms. Due to these and the previously stated objectives, a multi-platform software abstraction layer and execution environment, P-HAL-OE (Platform-Hardware Abstraction Layer Operating Environment), has been defined and designed to provide such features.
 
-The context within the applications will run is a matter to take into account because this strongly determines the framework. Signal processing applications are most of process-ing input signals and deliver output signals. Thus, the first step would be as simple as provide the mechanism to the application to deal with these input/output signals. These entities can be software or hardware entities, but in any case, abstracted from real im-plementation. The particularity of such interfaces between several entities is that is un-known at develop time, and only during execution time all the entities will be unified and the entire application will be build. 
+The context where the radio applications will be executed influences strongly the system performance. Radio appliactions are built by signal processing blocks most of them adquiring input signals and delivering output signals. Thus, the first step would be as simple as provide the mechanism to the application to deal with these input/output signals. These entities can be software or hardware entities, but in any case, abstracted from real implementation. The particularity of such interfaces between several entities is that is unknown at development time, and only during execution time all the entities will be unified and the entire application will be build. 
 
-These and more ideas should be implemented in the framework. In the following lines we define in terms of functionalities where the design must support on:
-•       First and most important, flexibility. The framework must efficiently implement the flexibility concept required by SDR.
-•       Execution control management.
+These and more ideas should be incorporated to the framework. In the following lines we define the main list of functionalities where the PHAL-OE must support on:
+•       Flexibility. The framework must efficiently implement the flexibility concept required by SDR.
+•       Execution control management. 
 •       Hide the platform heterogeneity to the radio application. Abstraction layers are required.
 •       Computing resource management.
-•       Computing objects data packet oriented messaging. Not processor (device) ori-ented.
-•       Parameter or variable (signals) evolution capture during the execution of the ap-plication. 
-•       Processing resource parameters evolution capture for its autonomous manage-ment or control.
-•       Auto-learning/cognitive capabilities for the internal resource management.  
+•       Computing objects data packet oriented messaging. Not processor (device) oriented.
+•       Parameter or variable (signals) evolution capture during the execution of the application. 
+•       Processing resource parameters evolution captured for autonomous management or control.
+•       Auto-learning/cognitive capabilities for the internal resource management. 
+•       Support to the Cognitive Radio strategies
 
 
 [[Image(PHALOEMedium.gif)]] 
-Figure 3 1 – P-HAL Layers Schematic
+
+P-HAL Layers Schematic
 
 
-To illustrate the concept of P-HAL as a simple mechanism of information exchange lets consider, for example, the following simple piece of code of an execution thread of a general radio application:
+To illustrate the concept of PHAL-OE as a simple mechanism of information exchange lets consider, for example, the following simple piece of code of an execution thread of a general radio application:
 
 for ever {
@@ -33 +36 @@
 Now the question is: would this simple P-HAL be enough to build Software Radio sig-nal processing applications? The answer is yes. Only a short specification of an origin and a destination of a data flow is enough to build any kind of application. Similar to the Turing Machine computing theory, any kind of processing machine based on a sin-gle operation of moving data from one origin to a destination is able to execute any kind of processing task. Thus, porting this concept to signal processing tasks is trivial.
 
-In Figure 3 1, a representation of the abstraction layers involved in P-HAL is drawn. On the top we see the connection graph of the object pieces building the radio application, this is the Abstract Application Layer. On the next level, objects are mapped into real Processing Elements (PE), they physically need a place to be executed or located on (the mapping pattern is not important by now). The P-HAL Layer is the abstraction layer found between the real application processes and the Hardware Layer. An overall P-HAL Platform is represented although three PE (each of them enabling the P-HAL functionalities) are under it.  
+In previous figure, a representation of the abstraction layers involved in P-HAL is drawn. On the top we see the connection graph of the object pieces building the radio application, this is the Abstract Application Layer. On the next level, objects are mapped into real Processing Elements (PE), they physically need a place to be executed or located on (the mapping pattern is not important by now). The P-HAL Layer is the abstraction layer found between the real application processes and the Hardware Layer. An overall P-HAL Platform is represented although three PE (each of them enabling the P-HAL functionalities) are under it.