Advanced coexistence technologies for radio optimisation in licensed and unlicensed spectrum (ACROPOLIS) Document Number D5.2

Transcription

1 Advanced coexistence technologies for radio optimisation in licensed and unlicensed spectrum (ACROPOLIS) Document Number D5.2 Report on the Analysis of OpenAirInterface and its Distribution in the Consortium Contractual date of delivery to the CEC: 30/09/2012 Actual date of delivery to the CEC: 30/09/2012 Project Number and Acronym: Editor: Authors: ACROPOLIS Raymond Knopp (EURECOM) Raymond Knopp (EURECOM) Carina Schmidt Knorreck (EURECOM) Dominique Nussbaum (EURECOM) Navid Nikaein (EURECOM) Bassem Zayen (EURECOM) Participants: EURECOM Workpackage: WP5 Security: Public (PU) Nature: Report Version: 1.0 Total Number of Pages: 44 ICT-ACROPOLIS Deliverable D5.2 1/42

2 Abstract: This document provides an overview of the current status of OpenAirInterface.org both in terms of its hardware and software elements. Details on the newest hardware platform, ExpressMIMO2, developed for experimentation in cognitive wireless networking are provided. The LTE SDR implementation, OpenAir4G, is described in addition to a new SDR implementation, OpenAirITS. Information on OAI Training activities undertaken in 2012 and those planned for early 2013 are provided. Keywords: Hardware/Software Platforms, OpenAirInterface, Platform training Document Revision History Version Date Author Summary of main changes EURECOM Initial structure of the document EURECOM editing EURECOM Delivery to EC ICT-ACROPOLIS Deliverable D5.2 2/42

3 Table of Contents 1. Introduction Role of WP5 in ACROPOLIS Purpose of D Evolution of OAI Hardware Platforms in ExpressMIMO ExpressMIMO2 motherboard characteristics Examples of ExpressMIMO2 RF performance Multi-band RF front-end characteristics SDR Architecture Exploration on ExpressMIMO Brief Overview of ExpressMIMO Control Choice of the Operating System for LEON Baseband Design and Emulation Generic DSP Shell Overview of the different DSP engines Processing Times Receiver Emulation using the Library for ExpressMIMO baseband (libembb) Development Methodology ASIP Implementation of FEP Motivation Conclusions from the study Softmodems and protocol stack implementations Overview of OAI LTE Implementation (OpenAir4G) OpenAir4G Protocol Stack NAS RRC MAC PDCP RLC Specific Extensions of OpenAir4G in the context of Acropolis Support for Carrier Aggregation and distributed interference management protocols Overview of Carrier Aggregation in Release-10 LTE Overview of OAI extensions for Carrier Aggregation Advanced Signal Processing in Support of Cognitive Overlay Networks OpenAirITS and DAB Intel x86-based OpenAirITS implementation Training and Teaching Activities on OAI OAI Training activities in OAI Labs Envisaged OAI Training activities in Conclusion References ICT-ACROPOLIS Deliverable D5.2 3/42

4 List of Tables Table 1: Frequency Bands and Duplexing (below 4GHz) Table 2: ExpressMIMO Cycle Counts (T should be read in clock cycles) Table 3: Physical Channel Support in OpenAirInterface.org (3GPP ) Table 4: Coding and Multiplexing (36.212) Table 5: Physical Layer Procedures (3GPP ) ICT-ACROPOLIS Deliverable D5.2 4/42

5 List of Figures Figure 1: ExpressMIMO2 Motherboard... 9 Figure 2: ExpressMIMO2 Embedded System Figure 3: RX Constellation, LTE 5MHz 35dB SNR Figure 4: RX Spectrum (LTE 5 MHz, 35 db SNR) Figure 5: ACLR at the TX output of ExpressMIMO2, at 750 MHz Figure 6: Constellation at the TX output of ExpressMIMO2, at 750 MHz Figure 7: External RF/Antenna modules for ExpressMIMO2 (one of 4) Figure 8 : ACLR of RF 750 MHz, for 16 dbm Figure 9: ACLR of RF 2600 MHz, for 14 dbm Figure 10: ExpressMIMO Baseband Engine Figure 11: OAI standardized IP Shell Figure 12: Illustration of the Basic (De)Interleaver Functionality Figure 13: libembb Processing Flow Figure 14 OpenAir4G protocol stack Figure 15: Carrier Aggregation Protocol Replication at enb Figure 16: PHY replication for aggregated CCs Figure 17: Cognitive Overlay Scenario Figure 18: Integration of OpenAirITS with mac ICT-ACROPOLIS Deliverable D5.2 5/42

6 1. Introduction OpenAirInterface.org (OAI) is an open source hardware/software development platform and open forum for innovation in the area of digital radio communications. It was created by the Mobile Communications Department at EURECOM based on its experience in publicly funded R&D carried out in the context of collaborative research projects (French national and European Framework programs). Its main objective is provide such collaborative projects with an open architecture platform, including both the constituent hardware and software elements, which can be enhanced by the scientific community at large. The initiative provides tools for experimentation with real time radio resources and scalable simulation/emulation environments for wireless communications. At the same time it strives to demonstrate innovation in high performance embedded computing architectures based on open source design tools. The development made available (both hardware and software) should not be considered to constitute a complete system solution, in the sense that an operator could download the software, purchase the hardware, and subsequently deploy a large scale network. It can be used to deploy reduced scale test networks in order to demonstrate innovative ideas in a realistic radio propagation and application scenario. Thanks to the open development policy, it is hoped that some parts may influence the evolution of industrial wireless stacndards such as LTE. As such, it currently supports a subset of the 3GPP LTE specifications (the majority of Release 8 and up to some aspects of Release 10) as well as the p WIFI standard for vehicular communications. 1.1 Role of WP5 in ACROPOLIS The objective of WP 5 is to analyze various existing hardware and software platforms that are available to the ACROPOLIS consortium and can be used for R&D purposes. The work began by a critical analysis of different platforms (so that it heavily interacts with WP 7) and described how best practices are shared between partners to accelerate work in this area. The latter was described in D5.1. In order to integrate and to enhance the available knowledge and expertise of the participating partners, a network for exchanging software modules and hardware experiences has been set up. Furthermore, several training activities on the available platforms have been organized and more are planned for 2013, so as to increase the awareness of the participating partners on the available platforms and to stimulate coordination among them. One central activity in WP5 is also the analysis and valorisation of the European OAI platform, which will be made available for consortium members by EURECOM. The software tools are provided under open source policy and the newest hardware elements will be offered to consortium members along with support services. To this end, a significant effort has been made in with respect to the design of the most recent hardware elements (ExpressMIMO2) of OAI platforms to provide a low cost solution for ICT-ACROPOLIS Deliverable D5.2 6/42

7 experimentation in cognitive networking. The existing earlier hardware elements, ExpressMIMO, were deemed too costly by most partners for networking experimentation and thus serve primarily for the purpose of software defined radio (SDR) architecture exploration studies in WP7, such as those described in section 3. Moreover, the low end and low cost CBMIMO1 platform used in many past projects lacks sufficient RF agility to be used for cognitive networking and suffers for various reasons from the age of its constituent RF components and bus interface. In the context of the Network of Excellence WP5 aims at enhancing the existing OAI implementation to provide more support for distributed interference management and cognitive wireless networking. It interacts with WP 8 and WP 9 and with ongoing FP7 projects further developing this technology by federating techniques emanating from these sources around OAI. To this end, the fact that OAI is primarily LTE oriented allows for demonstrating the impact that research in cognitive radio has mainstream wireless technology. This is primarily of interest in the context of distributed network management for small cells or opportunistic spectrum access in remote areas. Another potential application are for the ideas explored using this technology in the context of the Network of Excellence is for rapidly deployable networks in support of public safety. The latter has become of paramount importance due to the fact that since the onset of the Network, industry and government agencies have adopted LTE radio access for the future publicsafety radio networks around the globe. These target scenarios are explained in more detail in D Purpose of D5.2 First and foremost, this document is intended to provide an overview of the current status of OAI both in terms of its hardware and software elements. Section 2 provides an overview of the newest hardware platform, ExpressMIMO2, developed for experimentation in cognitive wireless networking. Architecture exploration studies using ExpressMIMO are reviewed in Section 3. We describe the current status of the LTE SDR implementations, OpenAir4G, in Section 4 in addition to a new SDR implementation which is integrated with the new mac80211 development provided with up to date Linux distributions. OAI Training activities undertaken in 2012 and those planned for early 2013 are described in Section 5. The document ends with a concluding section. ICT-ACROPOLIS Deliverable D5.2 7/42

8 2. Evolution of OAI Hardware Platforms in ExpressMIMO2 The newest platform which can target OAI software, whose latest version is described in Section 4, was given the code name ExpressMIMO2 since it follows its predecessor ExpressMIMO. The key target for ExpressMIMO2 was to reduce its cost so as to make it accessible for other laboratories wanting to experiment with OAI using a reasonable number of nodes (i.e. normally greater than 2). The board was designed to allow for stand alone operation at low power levels (maximum 0 dbm transmit power per channel) simply by connecting an antenna to the board. The chosen RF technology covers a very large part of the available RF spectrum (250 MHz 3.8 GHz) with channels up to 20 MHz bandwidth. ExpressMIMO2 is designed to be used with off the shelf PCs running standard Linux distributions and potentially a real time extension (RTAI/Xenomai or PREMPT RT) in order to make use of open source development tools and open source networking tool suites and applications, both stable and experimental. EURECOM has successfully tested the board with regular laptops through a readily available (and cheap) conversion cable in order to connect through the ExpressCard slot which also uses PCIexpress technology. Today OAI supports RTAI but the other options may become available for ExpressMIMO2, as a function of partners and projects interest. The PCIexpress bus interface allows existing drivers from its predecessors (CBMIMO1 and ExpressMIMO) to be used as is. Similarly the OAI OCTAVE interfaces for non real time experiments can also be used with changes only related to configuration of the new RF components. The cost of the board is approximately 1500 euros, depending on quantities ordered with the company fabricating the board, and could actually be less in time. EURECOM will provide information to partners in the Network of Excellence wishing to acquire such equipment. 2.1 ExpressMIMO2 motherboard characteristics The board is shown in Figure 1 and is built around a low cost Spartan 6 FPGA (150LXT) with native PCIexpress on the FPGA fabric and coupled with 4 high performance LTE RF ASICs onboard, manufactured by Lime Micro Systems (LMS6002D). The combination allows for four 20 MHz full duplex or half duplex radios to be interfaced with a desktop or laptop PC without the need for external RF. External RF is, however, required if high power output, antenna duplexing or standard compliant channel filtering are required. Another board currently under test at EURECOM designed to be interfaced with ExpressMIMO2 is described in Section0. ICT-ACROPOLIS Deliverable D5.2 8/42

9 RF TX (4 way) RF RX (4 way) PCIexpress (1 way or 4 way) 4xLMS6002D RF ASICs Spartan 6 LX150T 250 MHz 3.8 GHz 12V from ATX power supply GPIO for external RF control Figure 1: ExpressMIMO2 Motherboard The embedded system on the ExpressMIMO2 FPGA is shown in Figure 2. Similarly to ExpressMIMO and CBMIMO1 it is based on a LEON3 microcontroller. In the current design the LEON3 and the on chip bus are clocked at MHz which is sufficient for the throughput of the 1 way PCIe bus (62.5 MHz 32 bit). The embedded system is augmented by a data acquisition and framing unit which interfaces with the 4 LMS6002D and controls both the sample input output and the serial programming busses (SPI) for RF and sampling configuration parameters. The LEON3 has a large DDR3 memory for data and program storage. An on board Ethernet PHY is also provided, although it is currently not used. The embedded software for the FPGA is booted via the PC or can reside entirely in the boot ROM which is part of the FPGA design. The current software, however, is booted by PCIexpress dynamically under control of the PC device driver. A typical application, therefore, is a combination of PC software dialoguing with the card via driver configuration of shared PCI memory space and a program in the local memory on the embedded system. This program can be dynamically loaded from the PC. The basic design does not include any on-fpga signal processing and consumes approximately 10-15% of the FPGA resources. There is significant room left for additional processing on the FPGA, for instance Xilinx FFT processors or turbo-decoders to offload some processing from the host PC if required. ICT-ACROPOLIS Deliverable D5.2 9/42

10 DP-RAM AMBA BUS DCMs MHz TCXO PCIe Bus LEON3 CPU AHBPCIe Standard x86-based PC INTR CNTRL JTAG JTAG CONN GPIO RF CNTRL + Expansion DAQ /DSP Unit DDR3 CNTRL S6LX150T DDR3 128Mbyte LMS6002 x4 Config EEPROM Figure 2: ExpressMIMO2 Embedded System 2.2 Examples of ExpressMIMO2 RF performance In order to test the RF capabilities of the LMS6002D RF ASICS initial testing was performed using laboratory testing equipment attached to ExpressMIMO2. An example of the receiver performance on a 5 MHz LTE waveform driven by a Rohde&Schwarz SMBV100 is shown in Figure 3. Similarly the RX spectrum (with spectral nulls clearly visible) of an LTE PDCCH channel with 35 db SNR is shown in Figure 4. Both clearly show the excellent dynamic range of the receiver. ICT-ACROPOLIS Deliverable D5.2 10/42

11 Figure 3: RX Constellation, LTE 5MHz 35dB SNR Figure 4: RX Spectrum (LTE 5 MHz, 35 db SNR) Two examples of the TX performance of ExpressMIMO2 are shown in Figure 5 and Figure 6. The transmit waveform is clearly spectrally pure at 750 MHz (TV white space) and can be pushed to approximately 0dBm output with acceptable linearity. Similary, the received constellation on a Rohde&Schwarz FSQ clearly shows the high dynamic range and linearity of the transmitter. ICT-ACROPOLIS Deliverable D5.2 11/42

12 1 RM * AVG Ref 10 dbm Att 15 db * RBW 100 khz * VBW 1 MHz SWT 20 ms 3 Marker 1 [T1 ] dbm MHz Delta 2 [T1 ] db MHz Delta 3 [T1 ] 0.99 db MHz A 3DB Center 750 MHz 5 MHz/ Span 50 MHz Tx Channel E-UTRA/LTE Square Bandwidth 4.5 MHz Power dbm Adjacent Channel Bandwidth 4.5 MHz Lower db Spacing 5 MHz Upper db Alternate Channel Bandwidth 4.5 MHz Lower db Spacing 10 MHz Upper db Figure 5: ACLR at the TX output of ExpressMIMO2, at 750 MHz EUTRA/LTE Freq: 750 MHz Meas Setup: 1 TX x 1 RX Ext. Att: 0 db Mode: DL FDD, 25 RB (5 MHz), Normal (C P ) Sync State: OK Capture Time: 20.1 ms CONTINUOUS TRG : FREE RUN B Constellation Diagram Points Running... Date: 17.SEP :48:44 Figure 6: Constellation at the TX output of ExpressMIMO2, at 750 MHz 2.3 Multi band RF front end characteristics EURECOM has also sub contracted the design of a higher power RF front end (21 dbm) per channel in all common bands from 250MHz 8 GHz. Additional upconverter (TX) and downconverter (RX) stages are added to allow for higher frequency operation in TDD mode (above 4 GHz). A picture of the RF front end module is shown in Figure 7. The board is configured for operation as a UE in most cellular FDD bands, but can also be configured for enb as well in this bands with small component modifications. The current spectral configuration are shown in Table 1. Note that they are useful for TVWS operation. ICT-ACROPOLIS Deliverable D5.2 12/42

13 Band Duplex 1 TVWS ( MHz) TDD 2 DD ( MHz) TDD 3 DD ( MHz) FDD Mhz TDD 5 2,4 Ghz TDD 6 2,6 GHz FDD 7 2,6 GHz TDD 8 3,5 Ghz TDD GHz TDD 10 3,5 GHZ FDD Table 1: Frequency Bands and Duplexing (below 4GHz) RF Front End board Antenna connector (SMA) LO board Figure 7: External RF/Antenna modules for ExpressMIMO2 (one of 4) ICT-ACROPOLIS Deliverable D5.2 13/42

14 The RF front end boards comprise three parts: - a RF conversion circuit which aims at transpose the signal in the appropriate frequency band. This circuit includes contains filters, amplifiers and frequency mixers. - a filter bank part used for band selection and duplexing - high power (21 dbm) and low noise amplifiers The following figures illustrate the high power output spectrum at 750 MHz and 2.6 GHz. Note that these plots are below the specifications of the components and thus require some passive component value adjustements to achieve the maximum output power Ref 30 dbm Att 35 db RM * AVG * RBW 100 khz * VBW 1 MHz SWT 20 ms Delta 2 [T1 ] db MHz Marker 1 [T1 ] dbm MHz 3 Delta 3 [T1 ] db MHz 2 A 3DB Center 750 MHz MHz/ Span MHz Tx Channel E-UTRA/LTE Square Bandwidth 4.5 MHz Power dbm Adjacent Channel Bandwidth 4.5 MHz Lower db Spacing 5 MHz Upper db Alternate Channel Bandwidth 4.5 MHz Lower db Spacing 10 MHz Upper db Figure 8 : ACLR of RF 750 MHz, for 16 dbm ICT-ACROPOLIS Deliverable D5.2 14/42

15 Ref 20 dbm Att 25 db * RBW 100 khz * VBW 1 MHz SWT 20 ms Marker 1 [T1 ] dbm GHz OVTRC 1 RM * AVG A DB Center 2.6 GHz MHz/ Span MHz Tx Channel E-UTRA/LTE Square Bandwidth 4.5 MHz Power dbm Adjacent Channel Bandwidth 4.5 MHz Lower db Spacing 5 MHz Upper db Alternate Channel Bandwidth 4.5 MHz Lower db Spacing 10 MHz Upper db Figure 9: ACLR of RF 2600 MHz, for 14 dbm ICT-ACROPOLIS Deliverable D5.2 15/42

16 3. SDR Architecture Exploration on ExpressMIMO 3.1 Brief Overview of ExpressMIMO The OpenAirInterface ExpressMIMO platform [1] was developed jointly by Eurecom and Télécom ParisTech. Its hardware potentially supports a wide range of different standards like GSM, UMTS, , DAB, LTE as well as their multimodal processing and Time / Frequency Division Duplex (TDD / FDD) modes. It should be noted that to date the only considered air interfaces for which a subset of the air interface procedures have been implemented are LTE, p and DAB. The platform is used primarily for architecture exploration in SDR studies. The platform is capable to process up to eight different channels simultaneously (four in reception, four in transmission) by reusing the same HW resources. As each channel may support a different wireless communication standard, the main design challenge is the synchronization of these resources by providing a maximum accuracy and by meeting all the real time requirements. ExpressMIMO is used for experimental purposes only. Therefore the chosen target technology are FPGAs which come with a reduced design time, higher runtime flexibility, simple ease of use and lower costs for small quantities when compared to other solutions. Nevertheless ASICs are considered in a future version once the whole baseband design has been validated. In contrast to the previously presented solutions, the current design of the ExpressMIMO platform is split over two different FPGAs from Xilinx: (1) a Virtex 5 LX330 for the baseband processing and (2) a Virtex 5 LX110T for interfacing and control as shown in Figure 10. To simplify testing on the platform, the two FPGAs can run stand alone if required. Another difference is that the baseband processing which is responsible for the signal processing of the transceiver is split over different DSP engines. The underlying hardware architecture further allows to process four receive and four transmit channels in parallel by using the same resources. The interface and control FPGA transfers the signal coming from / going to the MAC layer and contains the main CPU (SPARC LEON3 processor) being responsible for the main control flow of the system. The two FPGAs are connected via an AMBA / AVCI DSP bridge while the different DSPs on the baseband side are connected via an AVCI crossbar. As only seven DSPs plus the VCI RAM and the main CPU are connected with each other, the performance of this crossbar is sufficient for the design of the ExpressMIMO platform. The available memory space is distributed in a non uniform way. Each DSP engine has its own memory space that is also mapped onto a global memory map. This global map is provided to the main CPU and to the DSPs and is consulted in case of DMA transfers between the DSPs or between the two FPGAs. For internal processing, the DSPs apply a local addressing scheme. In addition, an external DDR memory is available for mass storage on the baseband side and a DDR2 memory (size 16 MByte) contains the LEON3 program code and can be used for mass storage on the control side. Currently the whole design is running at a frequency of 100 MHz but the target is to increase this frequency to the maximum possible one of the main CPU (133 MHz) in the future. It is ICT-ACROPOLIS Deliverable D5.2 16/42

17 now likely that the entire embedded system will be ported to the new Xilinx ZYNC technology which will allow for much higher processing speeds. Figure 10: ExpressMIMO Baseband Engine Control The interface and control FPGA connects the ExpressMIMO platform with the external host PC by a JTAG and a PCIexpress connection (8 way when connected to a desktop PC, 1 way when connected to a laptop). The FPGA is further connected to a DDR2 memory available for mass storage of samples. Main component on the FPGA is the 32 bit SPARC LEON3 processor from Gaisler Aeroflex [2] that serves as main CPU for the baseband processing. In the future it is considered to replace it by a multiprocessor solution. An interesting candidate is the Xilinx Zynq [3] which includes an ARM Cortex A9. In contrast to LEON3 running at a maximum possible frequency of 133 MHz, Xilinx Zynq can be processed up to 800 MHz. Currently, all DSPs are controlled by the LEON3 processor who can program them by writing into or reading from the memory mapped control registers and the memorymapped local memories inside the DSPs. Data transfers between DSPs and from / to LEON3 can be established by either writing directly at corresponding global memory addresses or by DMA transfers. Observed programming latencies are related to the bridge connecting the two FPGAs. To minimize these latencies, it is planned to investigate in the effects of a distributed control flow on the platform. From the software point of view, the platform includes three different kinds of possible execution nodes: (1) the main CPU LEON3, (2) the microcontroller (UC) that can be included in each of the DSPs and (3) the DSPs itself. It is obvious that when splitting the control flow the design of the C application code running on LEON3 will become more challenging. But on the other side a distributed control flow will result in a more efficient transceiver processing, especially when executing multiple standards in parallel. ICT-ACROPOLIS Deliverable D5.2 17/42

18 Choice of the Operating System for LEON3 The SPARC LEON3 processor is supported by various Operating Systems (OS) like ecos [4], RTEMS (Real Time Executive for Multiprocessor Systems) and freertos (free Real Time Operating System) which are all free and VXWorks which is not free. The main similarity between them is that they all use function calls (or static links) instead of system calls to reduce their internal latencies. For single processor systems, all of them achieve a very good performance which would make them ideal candidates for the current version of the ExpressMIMO platform. However, a future version of ExpressMIMO will include a multiprocessor system. To avoid a time consuming software redesign it is therefore recommended to choose a free OS with multiprocessor support. A disadvantage of RTEMS is that it needs to run one instance of the OS per processor in the system. FreeRTOS has no multiprocessor support at all and the ecos multiprocessor support is still limited [4]. Therefore we decided to opt for MutekH ([5],[6]) which was originally designed to support multiprocessor heterogeneity of modern platforms. In contrast to the mentioned OS, MutekH provides a shared memory multiprocessors support and has been designed with strong multiprocessor support in mind. It further provides optimized function calls by using an appropriate set of inline functions. This reduces the latency of calls to the kernel which are frequent in parallel applications that are split in multiple threads to take advantages of several processors. For SPARC processors, unlike other kernels, MutekH uses the flat function call convention. This improves the interrupt latency and makes the function call time far more deterministic. Usually, SPARC comes with 32 general purpose registers that are always visible by the program. 24 of them are organized in a register window that is split over three different groups of eight registers. They are stated as out, local and in. The visible window per time instance is determined by the so called Current Window Pointer. Using save and restore instructions that can be found at the beginning and at the end of each function, this pointer is moving. The register windows are overlapping, so the out registers are renamed when save is called and become the in registers. In addition to that, the Window Invalid Mask (WIM) register indicates if a window is invalid which results in copying the whole stack to the memory. All the mentioned processing operations sometimes result in a huge overhead which is very critical when processing standards with strong latency requirements. Therefore, MutekH has been optimized by a flat registers model where the compiler does not use save and restore instructions. The extra register windows which are not needed by the regular code can then be used to implement really fast interrupts context switching for free. All of these improvements reduce the latency significantly and make the ExpressMIMO platform also suitable for the processing of standards with short data sets. For multimodal processing, MutekH supports POSIX threads so that different transceivers can be executed on LEON3 simultaneously Baseband Design and Emulation Generic DSP Shell The architecture of the different DSP engines is based on a standardized DSP Shell shown in Figure 11 which is composed of ICT-ACROPOLIS Deliverable D5.2 18/42

19 a Control Sub System (CSS): The CSS is common to all DSP engines and is specialized through parameters. It optionally contains a local 8 bit UC (6502) and a 64 bit DMA engine as well as a set of control and status registers plus several arbiters and FIFOs for input output requests and responses. Furthermore, the CSS acts as a gateway with the surrounding host system by using two 64 bit wide AVCI compliant interfaces. The first one is a slave (target) interface through which read and write requests to the internal control and status registers and to the Memory Sub System (MSS) are received. The second one is a master (initiator) interface required by the DMA to perform data transfers between the MSS and external memory areas. In addition, a set of input and output interrupt lines is used for signaling and synchronization with the host system. The architecture of the UC inside the CSS is based on a Complex Instruction Set Computer 15 (CISC) with 6 internal registers. Its address bus has a width of 16 bit and the reserved UC address space in the MSS has a size of 2 kb. Processing Unit (PU): The PU is custom defined and depends on the functionality of the DSP. It is the main component of each DSP engine. The instructions required for the PU processing are received through the CSS and are stored in the control registers. So programming a DSP just means writing the parameters into the right registers. a Memory Sub System (MSS): Like the PU, the MSS is custom defined and depends on the functionality of the DSP. The MSS contains the address space for the program and data memory of the UC with a size of 2 kbyte and the input output data space with a variable memory size. To increase the maximum achievable frequency after place and route, the number of registers before and after the actual RAM inside the MSS is variable and may differ between the different DSP ICT-ACROPOLIS Deliverable D5.2 19/42

20 Figure 11: OAI standardized IP Shell From the LEON3 point of view, all DSP engines are seen as a memory block mapped onto the global memory map. The size of each of these memories is set to 1 MByte and is aligned on a 1 MByte boundary. The UC and the DMA access memory spaces inside this memory but without having access to the global memory map. For the time being, the UC has not been integrated in the CSS yet. The current version of the receiver is thus orchestrated by a centralized control flow where the whole transceiver program is running on the main CPU. In the future a global control flow including the UC will be applied to reduce the interrupt rate and the communication overhead to the main CPU. Currently, the latter starts a DSP by writing a value in the so called igost (Ip GO and STatus) register. Once the operation is finished an interrupt is raised. Each DSP unit has three different interrupt lines used for signaling to the host system when the scheduled task is finished: (1) UIRQ (UC), (2) DIRQ (DMA) and (3) IIRQ (PU). As an alternative, the main CPU can poll the ibsy flag of the igost register to get to know about the end of the PU processing. An important CSS feature is that one new command can already be prepared in the command registers. Once this happens the ipend flag is set to one to indicate that no more command can be prepared. The same ICT-ACROPOLIS Deliverable D5.2 20/42

21 rules apply as well when programming the DMA engine included in the CSS. In this case, the register dgost provides the main CPU with the status information Overview of the different DSP engines In general, the baseband design takes place between the RF front and back end and the decoded signal samples. It represents the implementation of the physical layer while MAC layer operations are performed on the host PC. As mentioned earlier the baseband processing of the Express MIMO platform is structured in independent DSP engines which allow an easy upgrade to future standards. Other advantages include the effective use of spectrum, mobility, increased network capacity, maintenance of cost reduction and a faster development of new services. The DSPs have been designed in such a way that they support the most computationally intensive tasks in an efficient way. Prior to that, a detailed analysis of the commonalities between the standards has been carried out to make sure that the platform supports all current wireless communications standards by minimizing the resource consumption without the lack of high accuracy. The final designs are programmable, reconfigurable at runtime and can be processed in parallel which is of a significant importance for multimodal applications. In the context of different studies throughout the past years, seven different DSPs have been identified: Preprocessor (PP): The Preprocessor connects the external RF with the baseband system. The four A/D and four D/A converters (AD9832) provide 2x14 bit at 128 Ms/s in TX and 2x12 bit at 64 Ms/s in RX. Besides, the Preprocessor is used for basic signal processing functions including sample rate conversion, an NCO (Numerically Controlled Oscillator), I/Q imbalance correction as well as framing, (re)synchronization and sample synchronous interrupt generation. Front End Processor (FEP): The FEP is responsible for the different air operations like channel estimation, synchronization, etc. A detailed analysis of the required operations and a first FEP design have already been carried out in [7] and have further been detailed and optimized in the past years. The resulting design contains a vector processing unit as well as a DFT/IDFT unit. The supported input and output data types are 8 or 16 bit integers (real or complex valued) with a size of 16 or 32 bit. The FEP comprises five vector operations. The two input vectors are denoted as X[i] and Y[i], the result vector is denoted as Z[i]. Component Wise Addition (CWA): Z[i] = X[i]+Y[i] Component Wise Product (CWP): Z[i] = X[i] Y[i] Component Wise Square of Modulus (CWSM): Z[i] = X[i] 2 MOVe (MOV): copies a vector from one MSS location to another Component Wise Look up Table (CWL): Z[i] = Y [X[i]] Input vectors can further be modified by applying force to zero, negate or absolute value operations to the real and imaginary part while the output vector Z[i] can be rescaled or saturated. In addition to Z[i] the FEP can provide some more results (sum/max, min/argmax, argmin of Z[i]) if required. These values are further denoted ICT-ACROPOLIS Deliverable D5.2 21/42

22 as SMA values. Another important feature of the FEP is its flexible Address Generation Unit (AGU) that can be used for address skipping or address repetition and that allows an easy realization of circular buffers inside the FEP MSS. The latter is split in four different banks each with a size of 16 kb. For vector operations, the two input vectors and the output vector have to be stored in different memory banks. More details about this DSP are provided in Section 3.2 where an ASIP implementation of the FEP developed in the context of the Network of Excellence is presented. (De)Interleaver ((DE)INTL): This DSP is a block (De)Interleaver with a throughput of one sample per cycle. Its MSS is split over three different memories: input and output memory space have a size of 64 kb, the permutation table memory has a size of 128 kb. Further operations supported are puncturing, value repetition and value insertion by using the zero or one forcing option. All operations can either operate on bit or on byte. The basic functionality of the (De)Interleaver is illustrated in Figure 12. The address of the output buffer is directly correlated to the address of the permutation buffer containing the related input buffer address. Figure 12: Illustration of the Basic (De)Interleaver Functionality Channel Decoder (CHDEC): The Channel Decoder implements trellis based decoding algorithms more specifically a Viterbi (< 256 states, traceback algorithms) and 8 state Turbo decoders (max log map / sliding window algorithm) for binary convolutional codes to cover almost all current systems. Turbo decoding is limited to 3GPP UMTS/LTE interleavers. There are no restrictions concerning the choice of the generator polynomial. Accepted code rates are 1/2 and 1/3. The size of the traceback window is 5 x k with k as the constraint length. Supported constraint ICT-ACROPOLIS Deliverable D5.2 22/42

23 lengths are 7 and 9 for the Viterbi decoder and 4 for the Turbo decoder. For the latter the number of iterations can be programmed from 1 to 8. To increase the performance of standards with short data sets, a tail biting option has been added to the Viterbi decoder. The MSS of the Channel Decoder is split over three different sections: (1) input data memory (32 kb), (2) output data memory 16 kb) and (3) intermediate data memory (40 kb). Mapper: This DSPs perform a set of different modulation schemes which are BPSK, QPSK, 8PSK, 16 QAM, 32 QAM, 64 QAM and 256 QAM. The input memory of the mapper has a size of 8 kb, the output memory a size of 16 kb. Each input symbol is considered as an address of a Look Up Table (LUT) with a size of 4 kb from where the related output value is read. All DSPs and the VCI RAM are connected via a generic Advanced Virtual Component Interface (AVCI) crossbar ([8],[9]). The VCI RAM is used for temporary sample storage on the baseband side. It is mapped onto the global memory map and has a size of 16 kb. The resource allocation of all connected devices is handled by a Round Robin policy Processing Times The processing time of all DSPs and DMA transfers is deterministic and can be precalculated if required. Tab. 2.1 illustrates how to compute these times for the DSP engines and DMA transfers when considering the performance of algorithms implemented on the platform. FEP DFT/IDFT (vector length L samples) FEP Vector Operations (vector length L samples) L T 2 (13 ) * 8 n 1 2 n L 2 L 1 T 11 2 x y x 4 for CWL y 1 if SMA value computation x y 0 for others DE(INTL) number of samples + 16 CHDEC (Viterbi) number of samples + 16 DMA: LEON DSP (number of bytes/4) + 24 Direct: LEON3 DSP 7 Direct: DSP LEON3 10 DMA: DSP DSP (number of bytes/8) + 24 Direct: DSP DSP 18 Table 2: ExpressMIMO Cycle Counts (T should be read in clock cycles) Memcopy transfers denoted as direct correspond to transfers where LEON3 reads / writes directly in the baseband memory locations by using the global memory map. ICT-ACROPOLIS Deliverable D5.2 23/42

24 Receiver Emulation using the Library for ExpressMIMO baseband (libembb) The emulation environment of the ExpressMIMO platform called library for ExpressMIMO baseband (libembb) allows an easy validation and verification of the design in a pure software environment. It is developed by the System on Chip Laboratory of Télécom ParisTech and is an open source C++ library that has already been applied in different European projects like SACRA [11] or PLATA [12]. The functions included in libembb are bitaccurate and represent all functions on the baseband side. The API of libembb provides basic commands for the main CPU and the local UCs as well as synchronization and signaling including error messages. In the future the design will be extended by a cycle accurate SystemC model. Currently, two different implementations are provided: (1) a C++ emulation layer and (2) C language hardware dependent drivers. In case of the so called synchronous application, no parallelism is supported. The application is designed with the libembb C API and the code that is run in emulation and on the hardware target is the same. The parallelism of the different DSPs on the platform is not exploited in emulation using a synchronous application. In contrast parallelism has been added for the asynchronous application. The emulation code running on the desktop PC is now multi threaded and can be used unmodified for hardware processing where it exploits the parallelism of all resources. Figure 13 illustrates this general processing flow. Figure 13: libembb Processing Flow Development Methodology The transceiver design methodology applied for any design developed for the ExpressMIMO platform can be divided in several steps. ICT-ACROPOLIS Deliverable D5.2 24/42

25 Step one is the development of a purely functional model which is the common starting point for all transceiver designs. The goal of this step is to analyse the algorithmic part of the transceiver, to identify the required resources, the data flow and data dependencies. Thus, it is already possible to identify bottlenecks when processing several transceivers in a multimodal way on the platform. The considered models are typically sequential and do not yet fully exploit the parallelism of the target platform. For the design of the ExpressMIMO platform, the presented libembb library is used for the functional model design. Step two is the cycle accurate HW/SW co simulation. This step allows to fully exploit the parallelism on the platform. A common approach is the HW/SW co simulation in discrete event simulators such as Modelsim. The parallelism on the platform includes simultaneous processing of the DSPs, data transfers using the DMAs as well as the preparation of commands in the standardized DSP shell. Results of this step are cycle accurate performance figures of the developed transceiver to get to know the actual performance of the design. Unfortunately the usage of Modelsim is only appropriate for standards with short data sets as the initialization time of a standard like DAB for example is already in the order of 105 cycles. The final step is the transceiver validation on the hardware platform where the design is tested and validated on the real hardware platform. For this step first known snapshots are applied before the signal received through the RF is decoded. 3.2 ASIP Implementation of FEP The ExpressMIMO architecture was extended in a joint work with RWTH in the context of WP7 in order study a different processing architecture for the front end processor (FEP). We briefly overview the main results here. More detail can be found in [10] Motivation The primary aim of the collaboration was to overcome the original or C FEP drawbacks for vector operation processing on short data vectors (e.g. those characteristic of systems like ) by removing the DFT / IDFT unit from the standardized DSP shell and by replacing the vector processing unit by an ASIP solution called A FEP. Following this approach, the A FEP can easily be embedded in the baseband processing engine of the ExpressMIMO platform and FEP tasks can be split and scheduled on the two FEP solutions simultaneously. For design evaluation, the A FEP is not only compared to the C FEP but also to other ASIP solutions from academia in terms of architectural differences and processing time. The key question addressed by the study is to determine key advantages of ASIPs when compared to other technologies using a case study based on the ExpressMIMO architecture. This provides an existing implementation using more traditional Application Specific Integrated Circuits (ASIC) design approaches. Important factors to be considered for SDR platform design are area and power consumption as well as production costs. One major target is to decrease the area and to minimize the power as much as possible by maintaining the performance. In [13], a detailed overview of the different System on Chip (SoC) implementation techniques is provided. The technologies of interest are ICT-ACROPOLIS Deliverable D5.2 25/42

26 General Purpose Processors that can be divided into two categories, GPP proper for general purpose applications and microcontrollers for industrial applications. Digital Signal Processors which are a subcategory of Application Specific Processor (ASP). DSPs are programmable microprocessors used for extensive numerical realtime applications that are specialized for the digital signal processing domain. Application Specific Integrated Circuits (ASIC) which are also a subcategory of ASPs. They are implemented in hardware, usually with a Hardware Description Language (HDL) like VHDL or Verilog. Application Specific Instruction set Processors which are a subcategory of ASPs as well. They can be seen as a class of microprocessors coming with a specialized Instruction Set Architecture (ISA). The authors of [13] conclude that ASIPs tend to be suitable candidates as they are meant to fill the gap between GPPs and ASICs. Being tailored to a specific application, ASIPs offer a higher flexibility than ASICs by exhibiting a lower energy consumption than GPPs or DSPs at the same time. Or in other words, ASIPs allow to tradeoff the performance of ASICs against the flexibility of GPPs. By additionally taking the advantage of high level tools, the prototyping is facilitated whereas the generated design is not hardware optimized and may not fit the dedicated resource (e.g. FPGA). On the other hand, VHDL allows a resourceefficient FPGA design although the implementation requires a lot of time and resources. This drawback is overcome by tools like System Generator from Synopsis which speed up the VHDL design process by a high level block design and by the support of fast design modifications Conclusions from the study The A FEP can be included as an additional block in the baseband engine for the execution of latency critical tasks while DFT / IDFT and latency non critical tasks can be executed by the C FEP. Observed timing differences are due to the reduced communication overhead of the A FEP which results in a significant performance gain when operating on standards with short data sets, and which results in a simplified algorithm design. Another key point is that the RTL description of A FEP version was completely tool generated and performance, even for the algorithmic component, is comparable if not better than the hand coded description of C FEP. This is clearly an important conclusion. Besides the comparison between these two solutions solutions in the ExpressMIMO architecture, the A FEP has further been compared to recent ASIPs from academia. For an a/p packet detection algorithm its performance is similar to the ASPE A a design tailored to the processing of the IEEE a/n standard. As expected, the performance is worse than the one of a specialized ASIP for synchronization and acquisition described in [13]. The complete analysis can be found in and to a lesser extent in [10]. ICT-ACROPOLIS Deliverable D5.2 26/42

27 4. Softmodems and protocol stack implementations 4.1 Overview of OAI LTE Implementation (OpenAir4G) The OAI initiative develops open source MODEM and protocol stack implementation for the ExpressMIMO baseband engine and x86 PC targets. These implementations currently target LTE and p air interfaces. The LTE implementation, OpenAir4G, provides a standardcompliant LTE Rel 8 implementation of PHY and MAC for a subset of the specifications (36.211[16],36.212[17],36.213[18],36.321[19],36.322[20],36.323[21]36.331[22]). The gnu C implementation (with x86 SIMD hardware acceleration) can be made to run under any GNU environment, although x86 Linux and RTAI based targets have only been considered. An overview of the currently supported physical/transport channels and transmission modes is given in the following tables. Compliance of the implementation is being validated in conjunction with various industrial partners and is summarized here. Basic compliance at the PHY is determined using standard LTE test and measurement equipment from Rohde Schwarz and partners industry grade equipment. ICT-ACROPOLIS Deliverable D5.2 27/42

28 Physical Channel Functionality LTE Compliance PSS TX/RX Validated for 1 antenna port at enb (implemented for 1,2) SSS TX/RX Validated for 1 antenna port at enb (implemented for 1,2) Cell specific Reference signals PBCH PCFICH/PDCCH PHICH PDSCH TX/RX, Modes 1,2,3,4,5,6 1 2 antenna ports at enb TX/RX 1,2 antenna ports at enb TX/RX 1,2 antenna ports at enb All 5 MHz DCI Formats TX/RX 1,2 antenna ports at enb TX/RX 1,2 antenna ports at enb TX Diversity, 2 antenna Precoding (Mode 4/5/6)) Validated for 1 antenna port at enb (implemented for 1,2) Validated for 1 antenna port at enb (implemented for 1,2) Validated for 1 antenna port at enb, DCI Format 1,1A (TDD/FDD), (implemented for 1,2) Validated for 1 antenna port at enb (implemented for 1,2) Validated for 1 antenna port at enb (implemented for 1,2) PUSCH + UCI TX/RX Validated 1,2 antennas ports at enb PUCCH TX/RX formats 1,1a,1b Validated DRS TX/RX, 1 2 antenna ports at Validated enb SRS TX/RX, 1 2 antenna ports at Not validated yet, implemented enb PRACH TX/RX, 1 2 antenna ports at enb Validated (formats 1 3) Table 3: Physical Channel Support in OpenAirInterface.org (3GPP ) Coding Methods Functionality LTE Compliance Tail biting C. code,, TX/RX validated Turbo code TX/RX validated rate matching (C. code) TX/RX validated Rate matching (turbo) TX/RX validated segmentation TX/RX validated CRC 24 bit TX/RX validated CRC 16 bit TX/RX validated CRC 8 bit TX/RX validated BCH TX/RX Validated DCI TX/RX, 5 MHz TDD/FDD Validated (format formats 1,1A,1D,1B) DLSCH TX/RX Validated ULSCH/UCI TX/RX Validated (subset of UCI formats) ICT-ACROPOLIS Deliverable D5.2 28/42

29 CQI TX/RX Validated CFI TX/RX Validated HI TX/RX Validated Table 4: Coding and Multiplexing (36.212) ICT-ACROPOLIS Deliverable D5.2 29/42

30 Procedure Functionality LTE Compliance Random Access TX/RX, full procedure, Validated Connection Establishment, handover, data transfer Random access response TX/RX, full procedure Validated PDCCH procedures TX/RX Validated DL/UL HARQ procedures TX/RX, TDD, no PHICH Not validated CQI/PMI/RI reporting TX/RX, HLC and Not validated Subband PMI on PUSCH PUCCH Implemented (formats 0,1a,1b) Table 5: Physical Layer Procedures (3GPP ) OpenAir4G Protocol Stack OpenAir4G provides a full real time protocol stack for a gnu gcc environment implementing a subset of LTE Rel. 8/9 of access stratum as shown in Figure 14 and includes the following blocks: Linux Network device driver (kernel) MAC/RLC/PDCP/RRC and IP PHY procedures Can be integrated with openair4g MODEM or abstraction of physical channels, MODEM is abstracted along with propagation Can be vectorized for multiple instances (multi enb, multi UE, combined enb/ue, multiple component carriers for carrier aggregation) ICT-ACROPOLIS Deliverable D5.2 30/42

31 Figure 14 OpenAir4G protocol stack NAS The direct inter connection between LTE and IPv6 is performed using an inter working function, located in the NAS driver and operating in both the Control Plane and the Data Plane. This function provides the middleware for interfacing IPv6 based mechanisms for signalling and user traffic with 3GPP specific mechanisms for the access network (e.g. for mobility, call admission, etc.). It is developed as an extension of a standard IPv6/IPv4 network device driver. It implements the EPS bear association with the one RB, which is associated with the one PDCP entity RRC The RRC layer, shared between the UE and the ENB, performs the control of the radio interface. It is based on 3GPP v The control procedures available in the LTE platform are the following: System Information broadcast RRC connection establishment Measurement configuration and reporting the signalling data transfer Connection reconfiguration (addition and removal of radio bearers, connection release) the measurement collection and reporting at UE and enb EUTRA handover is under integration These procedures are being extended to support MBMS for multicast and broadcast MAC The MAC layer implements a subset of the 3GPP release v8.6 in support of BCH, DLSCH, RACH, and ULSCH channels. The enb MAC implementation includes: RRC interface for CCCH, DCCH, and DTCH ICT-ACROPOLIS Deliverable D5.2 31/42