ABSTRACT Radio Access Definition Language (RADL) high level language for Software Radio ter

Radio Access Definition Language (RADL): high level language for

Software Radio terminal reconfiguration

Luca Bertini(1), Enrico Del Re(2), Luca Simone Ronga(1)

(1)CNIT – University of Florence Unit

Via di S.Marta 3, I-50139 Florence (Italy)

(2)LENST – Department of Electronics and Telecommunication

via di S. Marta 3, I-50139 Florence (Italy)

ABSTRACT

In the last years one of the main technological effort in satellite communications is the integration of digital broadcast services with two-way communications: this is justified by the research of new business perspective and in the increase of technological efficiency.

Traditionally, common air interface (CAI) standards have been rigorously defined in great detail to ensure optimized operation for specific application and to permits the interoperability between the equipment of different manufactures devices. In this context, Software Radio is a possible technology that will facilitate the implementation of adaptive and flexible transmission schemes and protocols of the present and future standard of communications. A relevant element to the development of SR terminals is the remote configuration capability. It represents a complex tradeoff between two elements: the level of details in the description of radio components and the level of abstraction required for a hardware independent remote reconfiguration. The paper presents a SW/HW architecture for SR terminals along with the essential elements of a descriptive language used for the remote configuration process. Tests on a real DSP platform have shown the real feasibility of a remote definition of the physical layer.

INTRODUCTION

The main two access technologies for satellite systems are a Multi Frequency Time Division Multiplex Access (MF-TDMA) and the Wideband-CDMA (W-CDMA). The former is used, for example, in DVB-RCS technology for two-way communication among the end-user and the satellite. The latter is the access technology adopted for the Satellite UMTS (S-UMTS).

In the last years one of the main technological effort in satellite communications is the integration of digital broadcast services with two-way communications. The reasons are found in the new business perspective and in the research of an improved technological efficiency. This is justified by the need to offer a particular service in a region with high density end-users using a particular customed type of communication. The adopted communication standards depend on several parameters, such as the type of propagation that require to use a specific signal waveform.

Traditionally, common air interface (CAI) standards have been rigorously defined in great detail to ensure optimized operation for specific application and to permits the interoperability between the equipment of different manufactures devices. In this context, Software Radio is a possible technology that will facilitate the implementation of adaptive and flexible transmission schemes and protocols of the present and future standard of communications.

The flexibility of a terminal in Software Radio technology consists in the capacity to operate in multi-standard environment, without being forced to replicate hardware resources. Rapid deployment is an important feature of the software radio. In wireless applications where different standards might be deployed, user’s roaming can be a great issue in existing platform. In addition to that, it is also ready for modification in the signal processing structure in order to correct bugs in existing standard implementation and eventually to transform itself into a completely radio device.

In a “ideal” software radio, practically all the function shown in Figure 1 would be implemented in a general purpose processor [1]. Transmitter functions ranging from the source encoder to the upconversion of the baseband signal to the final carrier frequency would be performed by this processor. Likewise, the converse functions in the receiver would

also be accomplished by the processor, including carrier phase recovery and symbol or pseudonoise (PN) code timing recovery in a spread-spectrum application. In principle, this would allow the same hardware platform to support any physical layer imaginable as well as the higher layers of the protocol stack. This ideal radio would only be limited by the capabilities of the analog components (e.g., ADC’s, DAC’s, power amplifiers, low-noise amplifiers, antialiasing filters, and antenna subsystems), and by the capacity of the processor [2]. For example, in the SR mobile terminal the antenna should be able to cover the whole of the radio spectrum that is very strict for the current technology. In the Analog to Digital converter high performance are requested. To ensure resuming the original information from digitized signal, A/D conversion should meet the Nyquist law: this can be traduced with a sample rate at least of 2.5 times of the input signal’s bandwidth. The sample rate is more than 2 times to avoid aliasing interference.

Fig 1- Ideal scheme of Software Radio.

A relevant element to the development of SR terminals is the remote configuration capability [3] [4]. It represents a complex trade-off between two elements: the level of details in the description of radio components and the level of abstraction required for a hardware independent remote reconfiguration. This paper presents a SW/HW architecture for SR terminals, reconfigured by a satellite network, with the essential elements of a descriptive language used for the remote configuration process. The compiler and its language grammar rules developed are described in the last chapter where a test-bed on a real DSP platform have shown the real flexibility of a remote definition of the physical layer. HARDWARE ARCHITECTURE

The future mobile terminals are designed to support high bit rate traffic and they will be probably equipped with high computational capacities [5] [6]. Presently, in the market, there are high performance DSPs with clock frequency up to 600MHz and computational power of 4800MIPS. Third generation mobile terminals will use more than one microprocessor to increase the global computational capacity of the device.

To manage this hardware is envisaged the presence of a generic dedicated microprocessor like the Texas Instruments OMAP [7] or the Intel StrongARM [8]. These microprocessors present good performances and low power consumption, the latter being a fundamental prerogative of mobile systems.

Inside this device an Operating System (OS) performs all the control functions required by the terminal. In a SR mobile terminal, the OS can be also used to generate the firmware to be inserted into the reconfigurable strata of the hardware. The SR terminal is subdivided into an analog section and a baseband processing digital section [9] [10]. The first one includes the antenna, the RF-to-IF conversion stages and the Analog-to-Digital converters.

A feasible architecture of the baseband digital signal processing section is represented in figure 2.

Fig 2 - Main constitutive elements of the beseband architecture for the SR device

It is constituted by the following blocks:

? General Purpose microprocessor;

? multiple DSP/FPGA blocks, depending on the required

? functional target of the devices;

? FIFO memories for both the RX and TX branches;

? ROM/FLASH memories, for storing the resident parts of the OS;

The FIFO memories in the receiver branch (FIFO RX MEMORY) are used to store symbols from A/D stage while the FIFOs in the transmitter branch (FIFO TX MEMORY) store the data generated by the baseband processing engine directed to the DAC device. The ROM banks are used to store the Operating System (OS) and the firmware which will be loaded into the DSPs and FPGAs. The reconfigurable hardware, the FIFO Memories and the general purpose CPU are interconnected by an high speed bus.

SOFTWARE ARCHITECTURE OF THE SR TERMINAL

The device operating in SR technology acts as a node in the hosting network architecture both for control functions control plane and for the communication functions traffic plane (see figure 3).

The analyzed entities of the suggested network architecture in Software Radio technology are basically two: the Configuration Manager and the SR mobile terminal. The Configuration Manager is the one that gives instructions to the SR wireless terminals about its configuration and we suppose located in the earth gateway for a satellite network.

In this paper the SR terminal is the hand held device with high computational capacity able to translate the setup informations sent by the Configuration Manager into assembler instructions for the chosen DSP/FPGA.

Fig 3 - Software Architecture.

The protocol stack of the proposed architecture derives from the well known TCP/IP suite. The main difference is in the physical layer of the SR mobile terminal which is split into two sub-layers: the reconfigurable hardware (realized in DSP or FPGA technology) and the microcode (the firmware) which implements the target communication protocol. The SR terminal has two different states: an operative and a setup mode. The OS assists the device in its normal functions during the operative mode and performs the hardware reconfiguration during the setup mode. The RADL Compiler operates in this last state; its task is to analyze the setup instructions downloaded from the network and to produce the corresponding microcode to be loaded on the programmable devices.

Figure 4 – Different roles of the SR terminal in the hosting network

The present work focuses on the definition of the physical layer since the remaining layers are inherently defined in software and their reconfiguration can be easily accomplished by the CPU included in the device.

In figure 3 a generic mobile terminal has just received a complete reconfiguration and with its new set of layers (namely Layer2',..., Layer 5') can establish an Ad Hoc communication with another SR terminal.

Referring to this scenario the Configuration Manager has two main tasks:

? it performs the remote configuration of the communication stack for the mobile terminal,

? it provides access control of the mobile terminals to the network;

The software modules involved during a reconfiguration process are shown in figure 5:

Fig 5 - Software modules involved in the reconfiguration process of the SR terminal.

The setup file can be downloaded directly from the base station or from another SR terminal. This file, called config.radl, contains the setup instructions to permit the reconfiguration of the previously described layers.

The RADL Complier has been defined using a lexical analyzer and a parser generator in the UNIX platform. The choice of the OS platform derives from the large availability of open-source software modules. In a real SR terminal is envisaged the use of a specific OS optimized for the device to be controlled.

In particular we have chosen the FLEX [11] and BISON [12] applications available for the Linux Operating System. The FLEX analyzes lexically the text of the source file segmenting it into “tokens'' which are passed to the BISON for syntax analysis.

The RADL compiler, like any other compiler, uses some libraries available on the wireless SR terminal to implement the required functions into a machine dependent program. The Configuration Manager, aware of the libraries available in the terminal during the configuration process, generates the setup file accordingly.

The libraries in the mobile terminal can implement a wide range of signal processing functions, from simple operations to complex sections of existing communication standards (i.e. GSM and 3GPP framing, modulation and coding). As an example, functions like digital filtering, coding and decoding, modulation, pulse shaping, carrier recovery, timing acquisition are defined by a set of parameters provided by the Configuration Manager and implemented locally by the SR terminal using its libraries.

There is also the opportunity to replace partially or totally the terminal libraries; this allows upgrades of existing communication protocols but also the definition of new standards. The direct definition of a new library is written in a specific section in the config.radl; the RADL Compiler interprets this section and builds the code corresponding to the new library, making it available for future applications.

The complete communication standard implemented in the SR terminal is described, in the configuration file, as a single block with a set of inputs and outputs and several system-wise parameters.

This top-level block is composed by other blocks interconnected to create the specific system to be developed. The goal of the RADL compiler is to translate this block structure into a code executable by the hardware.

The configuration file is constituted by the following sections:

? PARAMETER DEFINITION, contains the definitions of the system configuration parameters;

? LINK, that expresses the topological connection scheme between the blocks;

? RUN SEQUENCE, defines the execution sequence of the blocks.

In the PARAMETER DEFINITION section are declared the configuration parameters that could be modified for each block (for example the roll-off factor for a pulse shaping filter). These parameters belong to a specific block but they influence the behavior of the whole system. It is also possible to defines several instances of the same block with different parameters values.

A typical parameter section follows:

PARAMETER_DEFINITION:

[block name1]:

[parameter_name1= value1];

[parameter_name2= value2];

[block name2]:

[parameter_name1= value1];

......

[block nameN]:

[parameter_name1= value1];

....

[parameter_nameN= valueN];

%%

In the LINK section we define the connections between the output and the input gate of each block in order to obtain the desired structure. Since the type of information flowing through a specific port of a block is defined in the corresponding library, the LINK section does not report it explicitly.

The declaration has a form like this:

LINK:

[block_name1].OUTstream1 >>> [block_name2].INstream1;

.....

.....

[block_nameN].OUTstream1 >>> [block_nameM].INstream1;

%%

Where the symbol “ >>> “ is translated by the RADL compiler as a connection operation between the out gate of the block1 and the input gate of the block2.

In the RUN SEQUENCE section is declared the execution order of the blocks in the system. This operation is carried out simply listing the names of the blocks present in the system in the desired order. The structure of this section is: RUN_SEQUENCE:

[block_name1];

[block_name2];

....

[block_nameN];

%%

If a new release of a library is available from the Configuration Manager, its definition can be inserter in a optional section of the setup file called EXTERN LIBRARY. In this section are declared the inputs and the outputs of the new block (in the “Input Output'' subsection), its configuration parameters (“Parameter definitio”' subsection), the calling syntax of the C function associated to the new block (“Function Calling” subsection) and the source code in C language of block implementation (“Body Function” subsection).

As a possible evolution a metalanguage could replace the C language in the library definition to increase the level of abstraction from the underlying hardware.

RADL COMPILER IMPLEMENTATION AND SR TERMINAL TEST-BED

In the experimental test-bed we developed the transmission branch of a CDMA wireless terminal.

The test has been conducted on a custom hardware platform (see figure 6) equipped with two high performance DSPs: two Texas Instruments TMS320C6202 running at a clock speed of 250MHz.

Fig 6 - Hardware platform used for SR terminal emulation.

The software radio terminal in the figure 6 is controlled by an external PC which emulates the high level layers of the SR architecture, including the RADL compiler.

In the tests the CDMA transmitter can not be completely defined by the libraries present in the terminal so a library upgrade operation is requested by the configuration manager. For this purpose, in the EXTERN LIBRARY section of the config.radl there is the definition of a custom block following the described syntax; the downloaded block performs a Spreading operation on the processed signal.

In the CDMA transmitter under test there are five blocks referenced in the setup file:

? system_initialize: it contains the main variables, the initialization instructions and the DSP register setup, ? data_generation: it generates the traffic data to be transmitted using a random generator,

? qpsk_mapping: it performs the QPSK signal generation from separate I \& Q bit-streams to a single complex symbol,

? spreading: the block downloaded from network that produces a 63 chips direct sequence spreading using a Gold spreading code,

? dsp1tx: used for accessing the FIFO memory;

The LINK section is reported below:

LINK:

system_initialize.OUTstream1 >>> data_generation.INstream1;

system_initialize.OUTstream2 >>> spreading.INstream2;

data_generation.OUTstream1 >>> qpsk_mapping.INstream1;

qpsk_mapping.OUTstream1 >>> spreading.INstream1;

spreading.OUTstream1 >>> dsp1tx.INstream1;

%%

The first instruction creates a connection between the output port ``1'' of the \verb#system_initialize# block and the input port ``1'' of the \verb#data_generation# block. The language keywords used in the LINK section are the symbols \verb# >>> # and \verb# %% #. When the RADL Compiler finds a \verb# >>> # symbol , it connects the output gate of the first block to the input gate of the second block. The operand to the left and to the right of the \verb#>>># symbol are the output and input port respectively. The \verb# %% # symbol terminates the LINK section.

The latest section in the config.radl is the RUN SEQUENCE. The syntax is:

RUN_SEQUENCE:

system_initialize;

data_generation;

QPSK_mapping;

spreading;

dsp1tx;

%%

The test has been conducted emulating the transmission of the configuration file from the Configuration Manager to the SR terminal. The RADL compiler succeeded in the generation of the target communication technology without any human interaction in the DSP code production process. The software defined radio components have been checked to verify any possible anomaly in the management of the signal flow across the blocks. The test have shown the real feasibility of a microprocessor based definition of the physical layer.

CONCLUDING REMARKS

This paper presents an HW/SW architecture for the remote configuration of Software Radio enabled wireless terminals. The remote physical layer definition is operated through an high level descriptive language, the RADL. The level of abstraction of RADL permits a compact representation of known communication standards, but it proves itself extremely powerful in the ability to define new functional signal processing sections. The SR terminal has been implemented in a custom DSP board, and a set of configuration tests have been conducted with success. Several additions to the proposed structure of the language are in the course of implementation and will be published shortly. REFERENCE

[1] J. E. Gunn, K. S. Barron, W. Ruczczyk, “A Low-Power DSP core-based software radio architecture”, Selected

Areas in Communications, IEEE Journal, Volume: 17 Issue: 4 , Apr 1999 Page(s): 574 –590.

[2] P. Leppanen, J. Reinila, A. Nykanen, V. Tapio, M. Isohookana, J. Pyhtila, T. Kokkonen, J. Sillampaa, “Software

Radio – An Alternative for the Future in Wireless Personal and Multimedia Communication“, Personal Wireless Communications, pp.364-368, 1999.

[3] W.H. W. Tuttlebee, “Software Defined Radio Enabling Technologies” Wiley Ed. 2002.

[4] J. Mitola III, “The Software Radio Architecture”, IEEE Communications Magazine, pp. 26-38, March 1996

[5]J. E. Gunn, K. S. Barron, W. Ruczczyk, “A Low-Power DSP Core-Based Software Radio Architecture”, IEEE

Journal an Selected Areas in Communications, vol.17, NO. 4, April 1999.

Springer Ed., September 2000.

ICCT ’98, October 1998.

[10] W.H. W. Tuttlebee, “Software-Defined Radio: Facets of a Developing technology”, IEEE Wireless

Communications, Vol. 12 Issue: 6, pp. 245-248, December 2000.

[11] V. Paxson, “Flex version 2.5: a fast scanner generator”, March 1995.

[12] Free Software Foundation, “Bison Manual, version 1.35”, February 1995.