Towards generic satellite payloads: software radio

Towards generic satellite payloads : software radio

C.Morlet

, M.-L.Boucheret

, V.Calmettes

, B.Paillassa

, T.Perennou

Alcatel Space, 26 av.JF.Champollion, BP1187, 31037 Toulouse cedex 1, France

TéSA, 2 rue C.Camichel, BP7122, 31071 Toulouse cedex 7, France

Abstract:

Satellite payloads are becoming much more complex with the evolution towards multimedia applications. Moreover satellite lifetime increases while standard and services evolve faster, necessitating a hardware platform that can evolves for not developing new systems on each change. The same problem occurs in terrestrial systems like mobile networks and a foreseen solution is the software defined radio technology. In this paper we describe a way of introducing this concept at satellite level to offer to operators the required flexibility in the system. The digital functions enabling this technology, the hardware components implementing the functions and the reconfiguration processes are detailed. We show that elements of the software radio for satellites exist and that this concept is feasible.

1. Introduction

Communication systems are characterized by their rapid evolution in term of components and applications. This is particularly the case when mobile telecommunication systems are addressed: the third generation (3G) is not yet developed and the fourth generation (4G) is already under consideration. The global trend observed is the introduction of new data services while mobile communication prior service was voice. In a few years, voice traffic should represent less than 20% of the global traffic. New data applications were first text data (SMS) and are/will be slowly replaced by video data. Thus the required bandwidth to transport these streams increases rapidly as well as the mandatory quality of service (QoS) gets higher. Moreover we are going toward a fully IP-based transport fluxes. All these considerations show that the network supporting all these applications should be designed in a way to be able to accept new services with their new characteristics without any change of the implemented network expensive to modify. New services should be viewed as a simple plug and play action for the end-user.

In this context, the software defined radio as emerged. This concept covers a lot of techniques: hardware configurable platforms, fast hardware design from software tools, network architectures, multi-mode terminals … Major achievements have been realized under ACTS or IST projects such as SINUS [1], TRUST [2] or ARROWS [3].

3G will incorporate a satellite network that should be able to evolve towards 4G. To cope with these constant evolutions, the best satellite system seems to be made of transparent satellites just acting as a relay on the signal. But to improve the budget link, the QoS and delay transmissions, regenerative payloads are preferred (the signal is demodulated and packet switching can be performed at the satellite level). The main disadvantage of such payloads is its lack of flexibility because all digital

hardware equipment’s are realized with ASICs. The emergence of FPGAs could be a solution to introduce flexibility at the satellite level for regenerative systems. The software defined radio concept for satellite applications can be viewed as: reconfiguration of hardware device through software processes.

In this paper we describe how the software radio concept can be applied to regenerative satellite payloads. In section 2 we explain functions of the payload that can be considered for software defined radio implementation and we focus of the reconfiguration of the demodulation process in case of waveform evolution for mobile access. In section 3 we develop the reconfiguration mechanisms to be shared between the network control center on ground and the satellite payload. In section 4 the hardware requirements for implementation of software defined radio functions are described and consequences on the design of the payload are given.

2. Flexible functions for software radio implementation on-board a satellite 2.1 Global satellite structure

Satellites are divided into two main parts: - the platform,

- the payload.

Equipment’s located at the platform level are mainly antennas, solar panels and processors controlling the satellite payload (generation of clock and frequency references used by equipment’s) and interpreting commands (TC) given to the satellite by an operation center and transmitting information through a telemetry channel (TM).

Equipment’s located in the payload are dedicated to the transmission process (analog and digital) including radio-frequency (RF), intermediate frequency (IF) and base-band (BB) processing’s. In

Fig. 1 the interaction between the platform and the payload is shown. payload platform RF, IF and BB processing’s TC TM clock frequency controller

Fig. 1. Global satellite architecture

Two kind of payloads can be distinguished : transparent and regenerative ones. The main role of the satellite is the amplification of the signal, acting as a relay and routing the communications (for example at circuit level). Evolution of technologies tends to the use of more and more equipment’s on-board often digitally implemented while benefiting from technology’s improvements. The satellite becomes a key element of the communication system, acting for example as the packet level as a router. When processing’s performed on-board the satellite require to work at the packet level, demodulation of the signal is mandatory and the

payload is called regenerative (in other cases it is called transparent). Moreover regeneration of the signal on-board improves the global budget link of the system which is of great interest when small and not powerful transmitting user terminals are addressed. As most of the processing’s are implemented on-board the satellite, the terrestrial segment can be reduced both in quantity and in cost (three geostationnary satellites are enough to cover the earth).

For multimedia applications, the authorized frequency band on the up-link is around 30GHz and the working bandwidth is 500MHz large. Specific payload equipment’s have then to be developed.

2.2 Digital functions on-board a satellite

The software defined radio concept is interesting when considering a regenerative payload. Different structures and functions can then be implemented, depending on the required applications and specifications of the system. An example of a regenerative payload is given on for a multiple frequency time division multiplex access (MF-TDMA) scheme. R F Sig n a l A D C A D C dem o d dem o d dem o d dem o d d eco d d eco d d eco d d eco d D A F D A F D B FN + D E M U X H alf-ba n d filte r H alf-ba n d filte r LO 2 b LO 2 a LO 1 IF2a IF2 b Tx p a rt B a seb a n d p ro cessin g s R x p a rt D B FN + D EM U X D A C C lo ck

g en era tio n F req u en ciesgen era tio n

TM TC D C /D C Po w er b us C o m m an d s used b y R x, Tx an d ba seb a n d p roce ssin g s’ co n tro l

Fig. 2: An example of a MF-TDMA regenerative payload

The main functions of the receiving part (Rx)concerned by the software defined radio implementation are the DBFN (digital beam-forming network), DEMUX (demultiplexer), DEMOD (demodulator) and DECOD (decoder) functions. In the baseband processing’s part and transmitting part (Tx), functions like packet switching and coding are also digitally

implemented and can be the object of a software defined radio implementation.

2.3 Software radio digital function examples

We consider under the term reconfiguration a static configuration of the equipment because for dynamic configuration (which can be assimilated to parameterization) solutions using ASICs are

already implemented and does not require a flexible design.

Possible static reconfigurations are the change of the decoder algorithm or of the waveform on the transmitted link.

• In the UMTS standard [4], different coding schemes are proposed, depending on the application considered and the required quality of service (QoS). Some transmissions can accept a non-coded mode while other ones require a convolutional code or a turbo-code. In each case the decoding algorithm is different and the architecture of the decoding process has to be reload when a change occurs if using the same hardware. As the traffic evolution can be important in the life time of an equipment, this kind of reconfiguration is a not utopian idea.

• In the case of mobile multimedia applications (for example S-UMTS and its evolution), the access scheme considered for low bit rates is actually CDMA (data rates not exceeding 144 or 384kbps). With the introduction of higher bit rates applications (the goal is 2Mbps), this access scheme could be too much limited and a TDMA scheme could be an interesting replacing mode. Then the demodulator functions and architectures have to be modified in such a way that the design has to be uploaded. In a CDMA modem, acquisition and tracking of the spreading code as well as despreading have to be implemented while they are replaced by a timing recovery in a TDMA mode (see Fig. 3). Other functions of the modem can remain the same if input data rates are compatible. In the case of S-UMTS, the CDMA link has a data rate of 2,048 Mcps (for an effective binary rate of not exceeding 144 kbps or 384 kbps) and the goal for improved links is a 2 Mbps data rate; working frequencies of both modes are then fully compatible. For a TDMA link, the timing recovery can be either the detector detailed in [5] or the estimator of [6] depending on the stream to be demodulated (length of the bursts in the TDMA frame). For CDMA, the acquisition algorithm presented in [7] and the tracking algorithm of [8] can be used. In term of complexity of implementation the CDMA demodulator requires more surface. A first complexity estimation we have realized gives the following results:

- timing recovery for MF-TDMA with 6 carriers: 200000 gates

- CDMA with one user: 200000 gates < complexity with several users.

Thus a change to a TDMA demodulator is compatible with the existing hardware profile.

Timing recovery Acquisition Tracking despreading To carrier recovery To carrier recovery From matched filter From matched filter

Fig. 3: Reconfiguration from CDMA modem to TDMA modem

3. Reconfiguration mechanisms 3.1 Strategy of reconfiguration

As seen previously the satellite can be divided into two parts: the platform and the payload. The software receiving orders from a network control center (NCC) and sending back telemetry is located on the platform. Hardware equipment’s (in particular those to be uploaded) are located in the payload. The software does not address directly the equipment’s. When complex payloads are used (i.e. regenerative), a specific controller is implemented, called on-board processor controller. This equipment is able to exchange with the controller on the platform and also to address each equipment separately. It can then distribute commands to individual hardware equipment’s. It is thus well suited to the management on-board the satellite of a reconfiguration process. The configuration process can be detailed as follows: - load of the binary file representing the new

configuration in an on-board memory,

- switch off the FPGA to be reconfigured (and so also of services through this FPGA),

- load of the new configuration on the FPGA through a specific interface (e.g. JTAG) - send back telemetry to attest the new

configuration (e.g. CRC of the new configuration of the FPGA)

- switch on the FPGA and services.

This scenario authorizes services interruption; a real-time reconfiguration is not mandatory for our application.

Assuming that processes can be implemented in a reconfigurable technology, the software defined radio feasibility consists also in studying techniques enabling the data to be loaded.

We propose an internet based architecture with existing standard protocols (see Fig. 4) organized around three levels.

- N1: the lowest level, named transfer system, is the underlying IP technology that includes functions for data transfer to satellite from network control center.

- N2: the intermediate level named data system is in charge of packet processing.

- N3: the upper level, named reconfiguration, manages the reconfiguration application

IP COPS Directory Service Channel TC/TM TFTP UDP TCP SPCS_FT or FTP N2: Data System N1:Transfer System Control System N3 Reconfiguration System

Fig. 4: Communication architecture for reconfiguration

3.2 Services

The on-board software for a reconfiguration process can be specific or a part of the existing payload controller (it depends on the calculation power required). Services are activated by a telecommand or a message received through a ad hoc protocol. Two main services can be distinguished:

- the reconfiguration service that loads a binary file on a FPGA

- the validation service that tests the current configuration of a FPGA.

The reconfiguration service enables a binary file to be uploaded on a FPGA. It is then necessary to reference the binary file located in a memory on-board the satellite and to identify the FPGA to be reconfigured. Four steps are necessary to realize this service:

- transfer of the binary file from the NCC to an on-board memory,

- load of the binary file from the memory to the FPGA configuration memory,

- switch on the FPGA,

- unload the binary file in the on-board memory. Optionally a binary files library can be managed on-board; this allows to reduce time transfers between the ground and the satellite but requires a lot of available memory on-board.

The validation service of the new configuration of the FPGA is linked to the equipment importance. A generic interface is thus difficult to define. Nevertheless, at least one auto-test of the new configuration will be realized (e.g. CRC applied on the configuration). The result of this test is transmitted to the NCC through the telemetry channel. Notice that the system should be able to come back to the previous configuration in case of failure of the process.

3.3 Protocols

The reconfiguration subsystem N3 comprises set-up, loading, test and validation. Each phase is characterized by various communication needs that may be satisfied either by set-up protocols or by file transfer protocols. A set-up protocol facilitates the reconfiguration, but if this process rarely occurs it is simpler to adopt a file handling protocol that will also be used for the reconfiguration uploading. Setup protocols IETF BootP protocol is based upon a client initiator model, thus as expressed before it is not adapted to satellite application. Concerning the management protocols, they could be used to configure some resident test through a CMIS interface, but they are based on an object design leading to complexity of implementation. Moreover the independence of the satellite operator they offer is not required since the satellite operator is equally in charge of the reconfiguration. Another set-up protocol appears very interesting: COPS. It may be employed to send reconfiguration policies (transmitted at the client or at the server initiative). File transfer protocols IETF TFTP protocol based on UDP, is used by a client asking a server for reading or writing a file. As TFTP sends just one block up to 512 bytes and then stops until the reception of the acknowledgement, it has to be used only for small transfer for efficiency reason, during the set-up or the test phases. For large transfer, FTP protocol, or SCPS-FP recommended by CCSDS yielding to efficient transfer across the space link, may be employed.

At the data system level, internet protocols are available on almost all devices that have to communicate. Their implementation is well known and they have been optimized in order to be fast and reliable. Different versions are proposed: FPGA, ASIC, or operating system kernel. With TCP/IP stack, reconfiguration of satellite is done by sending / receiving standard packets from a standard equipment. Packets must be addressed, formatted, controlled and secured. We propose to use the basics IETF products.

• IP: addresses are assigned to satellite devices (IP address are reserved for satellite use).

• TCP, UDP: according to the upper protocol either TCP (for a controlled transfer) or UDP (for an express transfer) is needed. Specific versions for satellite context have been already defined (they concern the segment size, the window mechanism…)[8].

• Ipsec: defined for IP security purposes, a ciphering code is performed on-board (it may be realized with FPGA and so possibly itself reconfigurable).

Concerning the more recent CCSDS internet standards, from the Space Communication Protocol

Standards project [9] they seem not very interesting in the context study.

• SCPS-TP (Transport protocol) is not really required because we consider a geostationary satellite (where propagation time is fixed) that is an end system (so the link delay is reduced). Thus TCP appears sufficient.

SCPS-NP (Network Protocol) has been specified to resolve IP problems in 1998 (like multicast, QoS) and it takes in count the space inter-link routing. In our case, firstly the transfer is between two adjacent points (satellite and network control center) without routing, and, secondly, IETF has developed studies upon IP problems [10], so that it seems preferable to use the real IP.

At the transfer system level N1 TMTC components can be used. Since, the processes we identified do not require real time configuration, the speed criteria has not to be considered. Usable telecommand services of TM/TC architecture are: Channel service for the establishment of an error-controlled data path to he spacecraft.

Data routing service: data unit received from upper layer are, if needed, segmented, or multiplexed to form routable pieces that are encapsulated into data transfer structure. These ones are transferred over virtual channel. Some virtual channels may be dedicated to the reconfiguration procedure. There are two modes of operation. The express mode is adapted to the transfer of small test in the question/response mode. The controlled mode is well suited to the reliable transfer of data configuration, or for a long test.

Note that, since an IETF approach is adopted, IP stack replaces the data management service of the TC architecture.

4. Hardware platform 4.1 Hardware families

Satellite digital functions are generally developed using ASICs due to rapidity and consumption considerations. Actual ASIC space qualified developed by ATMEL (named MH1RT) has characteristics summarized in Table 1 [9].

Table 1: MH1RT characteristics

Number of gates 1.2 million

Voltage 2.5 to 5V

TID 200 Krads

SEU for GEO sat. 1.10-7 err/bit/day

For future developments in 0.25µm and 0.18µm the acceptable TID should increase and reach 300Krads while the number of SEU per bit and per day remains constant.

Processors are used for telemetry and telecommands processes requiring only a few tenth of bits per seconds of processing speed.

The FPGA technology is emerging and still under development and growth.

4.2 Space components’ constraints

Components used for space applications have to be adapted in order to cope with a highly radiant environment. Three main phenomenon’s caused these radiation’s:

• Planetary magnetic fields generate protons and electrons belts of high energy and subject satellites to large fluxes of these particles when they pass through the radiation’s belts.

• Galactic cosmic rays are highly energetic particles occurring everywhere in space but with smaller fluxes comparing to magnetic fields. However one unique ray can modify a memory state or induce a non-desired circuit behavior when high integrated circuit technology is considered.

• Solar flares produce an important number of electrons, protons and low energetic particles which presence and activity varies a lot. Important fluxes appear during high solar activity over time periods from few hours to several days.

Two main kinds of effects due to radiation’s impact CMOS circuits:

• Total Ionizing Dose (TID): high-energy electrons and protons pass through the device and induce electrons’ holes in gates or field oxides of MOS structures. Electrons generated by ionization are characterized by a high mobility in the oxide while the holes have lower mobility. Parts of the holes can be trapped thus changing some characteristics of the component: the threshold voltage of the gate or the mobility level. These long-lasting effects on devices are permanent or semi-permanent. Nevertheless a large number of electrons’ holes is necessary to induce a degradation of the circuit considering actual technologies because the total charge of one particle is too low to change anything. The total dose corresponds to the aggregation of interactions of a large number of protons and electrons within a part of the device.

• Single-Event Effects (SEE): High energy particles like cosmic rays produce a more important ionization than protons and electrons. Thus a short time charge can be sufficient to induce states changes introducing random errors (single-event upsets (SEU)) in logical circuits and/or memories. To suppress a SEU it is mandatory to reinitialize the logical device or to rewrite memory.

Other effects can appear: latch-up, burnout … which are more difficult to recover from or impossible.

Generally speaking, devices are more sensitive to SEE as they are reduced in size because a switching state requires less energy. Thus new devices are sensitive to protons as well as heavy ions, increasing the SEE rate.

4.3 Space components’ radiation tolerance

Conventional techniques for detection and/or correction of SEU are implemented in the design of the function to be realized. They are adaptable to all kind of hardware. Two main techniques are used:

• Tripling the function: to protect the result, it is determined by a majority vote over three repetitions of the operation. Assuming a probability of simultaneous erroneous results, the probability of false event is equal to (pe)2

where pe is the probability of one erroneous

result (i.e. SEU probability).

• Doubling the logical circuit: the presence of a SEU is detected through a XOR operation with two replica of the same logical function. The correction of the result is not performed. In both cases a large amount of gates is necessary to protect the device. For space applications where power and mass are critical, such techniques have to be avoided. They are used only for critical designs like fundamental memory states.

Special processing techniques implemented by the manufacturer are preferred to solutions gates consuming and improve both SEE and TID hardness. For ASIC technology, library cells hardening or specific processing steps associated to oxide growth are used. For FPGA, the re-programmable type of the component is exploited. Xilinx uses the FPGA architecture and two major functions: “read-back” and “partial configuration” [10]. The FPGA is divided in configurable logic blocs (CLB) which can be identified through two addresses (on in column and one in row). All CLB are interconnected via one global routing matrix. Each CLB can be read or written independently without interrupting operations performed. Two main methods have been developed to protect devices against SEU:

• SEU detection is realized with the read-back function and some additional operations and correction with the partial configuration one. To detect a SEU, the contain of a cell can be memorized and compare to the initial file used for configuration; the SEU corresponds to a difference between the two files. Another method consists in calculating a CRC for each cell and comparing CRC values which is less gate consuming than memorizing the file.

• No detection of SEU is performed and each cell is regularly re-programmed using the partial configuration function. The time

between two programmations is defined by the mission and application sensitivity. This technique is called SEU scrubbing; it is the most interesting solution for satellite applications.

4.4 Payload structure

Reconfiguration of a hardware device for some digital functions requires to access easily each of the functions and to be able to change some elements while respecting some interfaces constraints due to environing functions not reconfigurable.

Let’s take the example of the waveform change from CDMA to TDMA mode. The reconfiguration concerns the digital modem which communicates with the demultiplexer and the decoder. Different strategies of realization of the payload can be used: the three equipment’s on one single chip, separated chips for each equipment, separated chips for functions of the modem.

In the last case, the function to be reconfigured is the unique element of the chip. The change from one function to another requires to have a sufficient hardware capacity on the chip whatever the function and to have common interfaces with the chips located before and after the reconfigured function (quantification of the signals, clock, …). In the two other cases, only a part of the chip needs to be changed. Unfortunately major FPGAs are not partially configurable and only a global reload is possible. Thus only interfaces with chips before and after needs to be considered as well.

Notice that the increase of electrical power required by a FPGA payload instead of a ASIC payload has not been analyzed yet and could be a constraint for developing this technology.

5. Conclusion

In this paper we have described the different elements of the software defined radio applied to satellite systems : the functions to be implemented in this technology, the reconfiguration mechanisms and the hardware platform required. It is shown that a lot of elements already exist to realize generic satellite payloads enabling to support any change of service and standard during the lifetime of the satellite.

References

[1] L.Lundheim, “Reconfigurable hardware for UMTS prototypes and terminals”, Mobile

Summit’97, Aalborg, Denmark, 7-8 Oct. 1997.

[2] M.Mehta, M.Wesseling, “Adaptative baseband sub-system for TRUST”,

PIMRC’00, London, UK.

[3] http://www.arrows-ist.upc.es

[4] 3GPP, 3G TS 25.212 v3.1.1 (1999-12) [5] F.M.Gardner, “A BPSK/QPSK Timing Error

Transactions on Communications, vol COM34, N°5, pp423-429, May 1986.

[6] M.Oerder, H.Meyr, “Digital Filter and Square Timing Recovery”, IEEE Transactions on

Communications, vol COM36, N°5, pp605-611, May 1988.

[7] R.De Gaudenzi, F.Giannetti, M.Luise, “Signal Recognition and signature code acquisition in CDMA mobile packet communication”, IEEE

Transactions on Vehicular Technology, vol 47, N°1, February 1998.

[8] R.De Gaudenzi, M.Luise, R.Viola, “A Digital Chip Timing Racovery Loop for Band-Limited Direct Sequence Spread-Spectrum Signals”, IEEE Transactions on

Communications, vol 41, N°11, November 1993.

[9] RFC 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms M. Allman, D.Glover, L. Sanchez January 1999. [10] CCSDS 710.0-G-0.4 Space Communication

Protocol Standard Draft Green Book, August

1998.

[11] RFC: 2990 Next Steps for the IP QoS

Architecture G.Huston, , November 2000.

[12] http://www.atmel.com

[13] C. Carmichael, E. Fuller, P. Blain and M. Caffrey (1999). SEU Mitigation Techniques for Virtex FPGAs in Space Applications.