PHAL-OE Concept and Motivation

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 applications, 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 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. Due to these and the previously stated objectives, a multi-platform software abstraction layer and execution environment, PHAL-OE (Platform-Hardware Abstraction Layer Operating Environment), has been defined and designed to provide such features.

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 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) 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

PHAL-OE Concept & Layers

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 {
 sample=read(MY_INPUT,BYTES_PER_SAMPLE);
 result=process_sample(sample);
 write(MY_OUTPUT,BYTES_PER_SAMPLE,result);
}

The process_sample function of the previous example can be written using any kind of portable programming language (C/C++ or VHDL for example) that can be compiled and translated to processor specific binary files. On the other hand, the read and write operators closely depend on the platform and must be specifically designed for it. Thus, when porting this code to another platform, the read and write specific PHAL-OE library implementation will be used.

Now the question is: would this simple P-HAL be enough to build Software Radio signal 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 single 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 previous figure, a representation of the abstraction layers involved in PHAL-OE 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 PHAL-OE 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 PHAL-OE functionalities) are under it.

The P-HAL Architecture

3.5. P-HAL Architecture In order to join multiple platforms providing support to the application with the previ-ously seen set of functions, P-HAL has defined an underlying structure for both, inter-operability of independently developed P-HAL software and portability of P-HAL rou-tines from one platform to another.

In this section, the different layers inside P-HAL and their functions are focused. First of all, it is necessary to identify the roles and players within a P-HAL context. Applica-tion modules are well known and benefit from the described API to exchange informa-tion. But under the modules there are a set of tasks and functions that must implement the requests from the first.

In order to achieve the purpose of P-HAL, it is possible to identify a large number of tasks that do not change from platform to platform, while there are other tasks that are platform dependant. Larger is the number of functions that can be included in the first set, easier is the portability of P-HAL from one platform to the other. Conversely, larger is the platform dependant part, lower is the flexibility to adapt the services to a new platform. This is because the offered services become more complex when with increas-ing software sizes. Then, the P-HAL platform dependant part will define elemental ser-vices that can potentially be implemented with a low cost and software depth.

Error: Macro Image(PHALOEH4.gif) failed

Attachment 'wiki:PHAL-OE_Concept: PHALOEH4.gif' does not exist.

In previous figure, we can find a schematic view of the different P-HAL components and librar-ies. At the top-left level of the stack there is application software represented here by a single P-HAL application object, which only uses P-HAL functions to interact with its environments. These P-HAL functions are called inside the different objects in the ap-plication and their implementation is found within the P-HAL Software Library, which is a platform independent library. These interactions with the environment and the rest of the operations done by the framework are executed by the P-HAL Software Daemons (on the top-right of the stack). These are a set of stand-alone entities each of them in charge of a few operations (see section 3.5.2 for a short summary).

Until here, all the implementations of such functionalities are platform dependant. To interact with the hardware, these software pieces use the platform-dependant P-HAL Hardware Library (accessed through the Hardware Library API). This enables the pre-viously stated portability of P-HAL functions. The implementation of the Hardware Library may require, in some platforms, the use of an underlying Operating System (OS) or may access directly to the platform Hardware if, although an OS is present, no support for certain device is provided.