Terminal components and API architecture for reconfiguration

2.1 Terminal components and API architecture for reconfiguration

2.1.1 Definition and requirements of API

– A set of definition of ways in which one piece of software communicates with another.

– A method of achieving abstraction, usually (but not necessarily) between lower level and higher level software.

– Often consists of sets of functions, procedures, variables, structures, etc.

An API can then be seen as an abstract interface definition, which is a description of the relationships among related software and/or hardware modules, such as bidirectional flow of data and control information. It describes the relationship of modules, not the implementation of those relationships. The interfaces should be independent of the implementation.

2.1.2 Terminal components

APIs:

– Core API: Interface which supports and enables the reconfiguration process between the radio configuration layer and the core software layer.

– Hardware abstraction layer API: Interface which allows a computer operating system (OS) to interact with a hardware device at a general or abstract level.

– (RT)OS API: Interface, controlling and monitoring any kind of running applications as well as device status and terminal capabilities.

Layers:

– Radio configuration layer.

– Radio hardware abstraction layer.

– (RT)OS layer.

Figure 20

The radio configuration layer includes all software components, which are responsible for any interaction with the “outside world”. So mode negotiation and switching module (MNSM), software download module (SDM), bandwidth management module (BMM) and mode identification & monitoring module (MIMM) are used to communicate to network server of service provider or network operator, also to the lower core software layer supported by lookup tables, profiles and reconfiguration management module (RMM). So the terminal API enables interfaces to the outside actors like user, network, provider or local area connection (e.g. Bluetooth, RLAN, etc.). A proxy configuration manager (PRM) should reduce bandwidth, terminal resources and connection time by supporting autonomous services and negotiations in the manner of WebService or information broker. A personalized user interface helps the user to interact with complete terminal functionality, he is allowed to access. This includes handling of user applications (e.g. PIM, Office, …) as well as editing of preferences and configurations for network communication and services.

The SDR core framework layer (SDR-CF) contains the CMM responsible for instantiating, monitoring and controlling of core radio software components. The core API supports and enables the reconfiguration process between radio configuration software layer and the core software layer.

The OS layer controls current/future terminal configurations, supports domain managers and terminal agents, provides access between SDR-CF and lower layers as well as data and resource management (lookup tables, capabilities, profiles ...).

For simple visualization the following two figures reflect the above-mentioned API architecture in a compressed form. Only the terminal API was unattended because this API contains a lot of standardized interfaces, which do not leave much scope for new development elements. Both figures, the first one using a radio hardware abstraction layer whereas the second one does not, are taken as a basis to explain the process and interactions between APIs, interfaces and participated components (software and hardware) in an abstract way.

Starting at the bottom of the Figure and working up, the first item is the terminal hardware itself. Examples include processing hardware such as DSPs and microcontrollers, function specific hardware such as ASICs, mixers and oscillators, reconfigurable hardware and input/output devices. Everything above the hardware is some form of software. There are four software packages; the three shown horizontally are software layers, whilst the fourth is shown vertically and may be thought of as a software slice. This slice is the operating system. In an embedded real-time system, it will be a real-time operating system (RTOS). The (RT)OS provides standard services (e.g. task scheduling, memory management, interrupt handling, …) to all of the software layers. Implementation of these services varies from one (RT)OS to another whether it be commercially sourced or developed in-house. To preserve a common interface to these standard services, for any given (RT)OS. This API is shown on the Figure as the vertical bar sandwiched between the software layers and the (RT)OS.

Figure 21

An (RT)OS may also support other services; in particular it may support device I/O using device drivers for standard hardware devices. In a reconfigurable terminal many of the hardware devices will be associated with radio functionality; e.g. mixers and oscillators in the RF domain and ASIC accelerators in the baseband domain. In addition reconfigurable-hardware devices will enable flexible radio hardware accelerators. Since the number and type of these devices will vary from one class of terminal to another it is unlikely that generic operating system support for these will be possible. Direct radio hardware access will be supported through a dedicated radio hardware abstraction layer, shown in Fig. 21 as the first software layer above the hardware.

This layer contains a library of radio hardware drivers, each of which publishes a software interface to the services of the radio hardware for which it is supplied. Software applications in higher layers access these services through the radio hardware abstraction layer API (RHAL API). This mechanism for direct access to radio hardware, without an intermediate operating system, is also essential for optimum speed and power performance.

It can be seen that the RHAL API will be dependent on the class of terminal because of variations in supported hardware. One might therefore argue that it is not an API; that it is not general at the conceptual level of a reconfigurable terminal. Taken to the extreme we obtain an alternative architecture shown in Fig. 22. This architecture does not contain a radio hardware abstraction layer and API; the radio hardware drivers are accessed directly from a library contained within the terminal. The former architecture is preferred however, because of the possibility that some hardware components may be standardized at the level of a generic reconfigurable terminal and also because the actual software mechanism for accessing hardware drivers may also need to be standardized.

Figure 22

Continuing to move up the architecture of Fig. 22 we come to the core software layer. This layer contains the core radio software components for the current radio configuration. Typically this would include RF, baseband and protocol stack components. In addition the configuration management module (CMM) is responsible for instantiating, monitoring and controlling the core radio software. An API, the core API, is provided so that next layer up, the radio reconfiguration software layer, may access the services provided by the core layer.

The radio reconfiguration layer is concerned with all aspects of reconfiguration and contains the following components:

– Reconfiguration management module (RMM)

– Software download module (SDM)

– QoS manager

– Mode negotiation & switching module (MNSM)

– Mode identification & monitoring module (MIMM)

– Bandwidth management (BMM)

Both the MNSM and the RMM would invoke services of the CMM through the core API; the former to modify the core software configuration, the latter to obtain resource usage figures. In an open-layered architecture it would also be possible for one layer to access the services of any layer below if it is necessary. For example it might be desirable for the RMM to obtain resource usage figures directly using the RHAL API.